Mellékleteink: HUP | Gamekapocs
Elküldve: 2003. 01. 15. 20:22
Idézet
Elküldve: 2003. 01. 15. 21:55
Elküldve: 2003. 01. 15. 22:48
idézet:
Ezt írta Hory:
A homepázsomon van egy labor jegyzőkönyv, ami pont az iptables firewall-okkal foglalkozik. Persze hótgagyi, ahogy tisztességes labor jegyzőkönyvhöz illik, de a lényeg benne van.[/quote]
Megnéztem, van benne pár érdekes dolog... de nem túl részletes...
Idézet
Elküldve: 2003. 01. 17. 01:29
idézet:
Ezt írta NeverGone, a tökös:
...régen pl. úgy tanították, hogy az alapértelmezett szabály DENY legyen. [/quote]
szerintem ezt most is igy tanitjak.
mondjuk esetleg az "output" lanc lehet ACCEPT, ha nem akarsz a belso halora korlatokat.
idézet:
De ha ezt állítom be pl., akkor nem megy az ftp, és irc conntrack. [/quote]
hat mert kulon engedelyezni kell...
idézet:
Másrészt pedig mindenkinek lehetnek jól bevált egyedi ötletei.
Akkor hát hajrá...
- lehet, hogy trivialis de en szeretek sajat lancokat letrehozni. pl. kulon TCP-nek, UDP-nek, ICMP-nek stb. es ott engedelyezni a dolgokat
- fontos meg , hogy a szabalyok elobb lepjenek eletbe, mint ahogy az ethx vagy egyebb csatolo felhuzodik. gondolom egyertelmu.
most igy hirtelen ennyi.
Elküldve: 2003. 01. 17. 09:19
idézet:
Ezt írta NeverGone, a tökös:
Nah, sziasztok...
Először az iptables topicba gondoltam, de az eléggé egy speckó témára koncentrál, másrészt pedig lehet itt ipchains is...
Szóval szerintetek milyen a jó tűzfal szkript...? Mert régen pl. úgy tanították, hogy az alapértelmezett szabály DENY legyen. De ha ezt állítom be pl., akkor nem megy az ftp, és irc conntrack. Másrészt pedig mindenkinek lehetnek jól bevált egyedi ötletei.
Akkor hát hajrá...
A jó tűzfal script valóban olyan, hogy default policy a DENY, legalábbis az input és forward láncoknál (egy output láncon beállított DENY policy eleg nagy konfigurációs pluszmunkát jelenthet, nem éri meg).
Az ftp, irc és a többi hasonló jellegű protokoll csomagszűrővel nehezen szűrhető, mert további portot nyit dinamikusan, ráadásul kintről befelé, amit nem szoktak szeretni a tűzfalak (meg azok, akik konfigurálják őket
Ezért van, hogy tűzfal mögül többnyire passzív ftp-t szokás használni, az az esetek többségében gond nélkül működik még masq-olt hálón is.
Az ipchains és iptables közti különbség egyébként az, hogy míg az ipchains 'mezei' csomagszűrő, az iptables állapottartó csomagszűrő (stateful packet filter, SPF). Ez annyival fejlettebb, hogy az általa ismert protokollok esetén képes a protokoll bizonyos elemeinek figyelésére. Az ftp és irc protokollokra külön van modul (ftp_conntrack, stb), még NAT-hoz is. Ennek használatához mindössze két dolgot kell csinálni: lefordítani a megfelelő modult (és persze betölteni), valamint az iptables scriptjében engedélyezni kell a RELATED szabályt is.
Elküldve: 2003. 01. 17. 09:22
idézet:
Ezt írta Red:
- lehet, hogy trivialis de en szeretek sajat lancokat letrehozni. pl. kulon TCP-nek, UDP-nek, ICMP-nek stb. es ott engedelyezni a dolgokat
- fontos meg , hogy a szabalyok elobb lepjenek eletbe, mint ahogy az ethx vagy egyebb csatolo felhuzodik. gondolom egyertelmu.
most igy hirtelen ennyi.[/quote]
A külön láncok valóban segítik a konfiguráció megértését, de szerintem jobban jársz, ha először a forrás interface alapján bontod szét, utána aztán a bonyolultságától függően lehet további bontást (pl. tcp, udp) alkalmazni.
Elküldve: 2003. 01. 17. 10:12
idézet:
Ezt írta Friczy:
Az ftp, irc és a többi hasonló jellegű protokoll csomagszűrővel nehezen szűrhető, mert további portot nyit dinamikusan, ráadásul kintről befelé, amit nem szoktak szeretni a tűzfalak (meg azok, akik konfigurálják őket
Ezért van, hogy tűzfal mögül többnyire passzív ftp-t szokás használni, az az esetek többségében gond nélkül működik még masq-olt hálón is.
[/quote]
Persze, de vannak helyzetek, mikor a passzív ftp nem megfelelő, ilyenkor kell mindenképpen a conntrack. A RELATED, mint új szabály jelenik meg ilyenkor?
Idézet
Elküldve: 2003. 01. 17. 10:58
idézet:
Ezt írta NeverGone, a tökös:
Persze, de vannak helyzetek, mikor a passzív ftp nem megfelelő, ilyenkor kell mindenképpen a conntrack. A RELATED, mint új szabály jelenik meg ilyenkor?[/quote]
iptables -A input -p tcp -i eth0 -m state --state RELATED -j ACCEPT
Elküldve: 2003. 01. 21. 16:43
idézet:
Ezt írta NeverGone, a tökös:
Persze, de vannak helyzetek, mikor a passzív ftp nem megfelelő, ilyenkor kell mindenképpen a conntrack. A RELATED, mint új szabály jelenik meg ilyenkor?[/quote]
a conntrack modulok nat-olt hálózatokhoz kellenek, nat nélkül nem mégy vele semmire.
a passzív és aktív ftp között a legnagyobb különbség, hogy a passzív az FTP szerveren csak egy privilegizált (tcp 1024 alatti) portot igényel (tcp 21), míg az aktív kettőt (tcp 20,21). kliensoldalon pedig akár aktív, akár passzív, mindig két port kell neki tcp 1024 fölött.
A tűzfalaknál arra kell még figyelni, h hiába van megnyitva az aktív FTP számára a 20-as forrásportról érkező csomagok fogadása, ha van mellette egy ESTABLISHED, RELATED feltétel is.
ugyanis aktív FTP-nél a kliens ugye először csatlakozik a szerver tcp 21-re, a szerver a 21-ről válaszol, és egyből utána 20-ról is megpróbálja felépíteni az adatcseréhez szükséges tcp kapcsolatot, ami nyilván nem lesz se RELATED, se ESTABLISHED. (passzívnál ezt a kliens kezdeményezi, és nem a szerver 20-as portjára)
Elküldve: 2003. 01. 21. 16:57
idézet:
Ezt írta Friczy:
A külön láncok valóban segítik a konfiguráció megértését, de szerintem jobban jársz, ha először a forrás interface alapján bontod szét, utána aztán a bonyolultságától függően lehet további bontást (pl. tcp, udp) alkalmazni.[/quote]
én is az interfészek szerinti láncokra esköszöm, ennél
nincs áttekinthetőbb, illetve ennél már csak az jobb, amikor az intefészek szerint van egy adott kártyához egy bejövő és egy kimenő lánc is.
tehát egy kátkártyás sima átjáró esetén például az INPUT, OUTPUT, és a FORWARD láncokból jóformán csak a megfelelően elkészített KIBE (külső interfészen bejövő), KIKI, BIBE (belső interfészen bejövő), BIKI láncokat kell meghívni
Elküldve: 2003. 01. 21. 17:22
idézet:
Ezt írta Friczy:
A külön láncok valóban segítik a konfiguráció megértését, de szerintem jobban jársz, ha először a forrás interface alapján bontod szét, utána aztán a bonyolultságától függően lehet további bontást (pl. tcp, udp) alkalmazni.[/quote]
En (mi) ugy szoktuk csinalni, hogy "from-to" alapjan csinalunk kulon lancokat (plussz a noise es spoof chain-ek), tehat pl a Lan-bol mesz Internetre, akkor a chain neve "LanInet"
Celszeru irni ra egy sciptet, ami atkonvertalja egy konnyebben ertheto formatumbol (nekunk pl /etc/iptables.Orig file hasznalatos szerkesztes celjara, ez konnyen ertheto define-okkal van teli meg egyszeru formatumu egy iptables sor is >> majd ezt konvertaljuk a betoltheto formatumba )
Elküldve: 2003. 01. 21. 17:26
idézet:
Ezt írta Sniper:
En (mi) ugy szoktuk csinalni, hogy "from-to" alapjan csinalunk kulon lancokat (plussz a noise es spoof chain-ek), tehat pl a Lan-bol mesz Internetre, akkor a chain neve "LanInet"
[/quote]
Ez szvsz azert is celszerubb mint az interface-ek szerinti chain-ezes, mert soklabu tuzfal eseten mar nem biztos, hogy fejbol tudod, hogy melyik labra is esik egy csomag ( PL.: felhiv egy user a egy cegtol, ahol van egy 24 labu fw, hogy szeretne a dmz-bol ftp-zni ide meg ide, akkor egyszerub a DmzInet chaint megtalalni, mint kikeresni, hogy melyik labra is esik stb stb ... nem is mondom, hogy mi van akkor ha 100as nagysagrendben uzemeltetszjo moka, nekem elhihetitek
[ 2003. január 21.: Sniper szerkesztette a hozzászólást ]
Elküldve: 2003. 01. 21. 22:09
idézet:
Ezt írta roberto:
a passzív és aktív ftp között a legnagyobb különbség, hogy a passzív az FTP szerveren csak egy privilegizált (tcp 1024 alatti) portot igényel (tcp 21), míg az aktív kettőt (tcp 20,21). kliensoldalon pedig akár aktív, akár passzív, mindig két port kell neki tcp 1024 fölött.
A tűzfalaknál arra kell még figyelni, h hiába van megnyitva az aktív FTP számára a 20-as forrásportról érkező csomagok fogadása, ha van mellette egy ESTABLISHED, RELATED feltétel is.
ugyanis aktív FTP-nél a kliens ugye először csatlakozik a szerver tcp 21-re, a szerver a 21-ről válaszol, és egyből utána 20-ról is megpróbálja felépíteni az adatcseréhez szükséges tcp kapcsolatot, ami nyilván nem lesz se RELATED, se ESTABLISHED. (passzívnál ezt a kliens kezdeményezi, és nem a szerver 20-as portjára)[/quote]
Én inkább úgy fogalmaznék, hogy ESTABLISHED, RELATED feltétel megadása esetén felesleges külön megnyitni a 20-as forrással a tűzfalat. Az ftp protokollt ugyanis figyeli a tűzfal, és mivel a protokollban benne van az az információ, hogy melyik portra fog nyílni az adatcsatorna, a tűzfal azt meg is fogja nyitni. Szóval aktív és passzív ftp esetén is elegendő az ESTABLISHED, RELATED, nem kell sem a 20-as forrásra, sem másra kinyitni a tűzfalat.
Elküldve: 2003. 01. 21. 22:11
idézet:
Ezt írta Sniper:
En (mi) ugy szoktuk csinalni, hogy "from-to" alapjan csinalunk kulon lancokat (plussz a noise es spoof chain-ek), tehat pl a Lan-bol mesz Internetre, akkor a chain neve "LanInet"
Celszeru irni ra egy sciptet, ami atkonvertalja egy konnyebben ertheto formatumbol (nekunk pl /etc/iptables.Orig file hasznalatos szerkesztes celjara, ez konnyen ertheto define-okkal van teli meg egyszeru formatumu egy iptables sor is >> majd ezt konvertaljuk a betoltheto formatumba )[/quote]
És ha azt is megírod, hogy ipchains-utils annak a scriptgyűjteménynek a neve, amivel ezt csinálod, és hogy alkalmas a tűzfal letesztelésére is a -comit előtt, akkor szerintem kitaláltam, melyik cégnél dolgozol
Elküldve: 2003. 01. 22. 14:14
idézet:
Ezt írta Friczy:
És ha azt is megírod, hogy ipchains-utils annak a scriptgyűjteménynek a neve, amivel ezt csinálod, és hogy alkalmas a tűzfal letesztelésére is a -comit előtt, akkor szerintem kitaláltam, melyik cégnél dolgozol
Elküldve: 2003. 01. 22. 16:10
idézet:
Ezt írta Sniper:
Nem, én másik, hasonló funkcionalitású scriptre gondoltam. Mondhatni, nem jött be
Elküldve: 2003. 01. 26. 17:41
Idézet
Elküldve: 2003. 01. 27. 13:31
idézet:
Ezt írta NeverGone, a tökös:
Két kérdésem lenne:
1.) Van egy hálókártyám, aminek van alias interface is, szal eth0, és eth0:1. Erre a hálózat kialakítása miatt volt szükség. Most tűzfalat készítek a gépemre, és aszerint szeretném saját láncokra terelni a csomagokat, hogy melyik interface -ra érkeztek be. Viszont tesztelésképpen kipróbáltam:
iptables -A INPUT -i eth0:1 -j DROP
...
[/quote]
A logikai interface valoban csak logikai
Csinald a chaint pl igy.: Ha az eth0-ra erkezik, x.x.x.0/x taromanybol, akkor -j "AliasIfChainName"
Esetleg probalj -i eth0:1 helyett -d ipcim
Connection tracking-re hirtelen nincs otletem (nem hinnem, hogy iptables kepes erre... ez egy csomagszuto, nem pedig egy univerzalis karacsonyfa
[ 2003. január 27.: Sniper szerkesztette a hozzászólást ]
[ 2003. január 27.: Sniper szerkesztette a hozzászólást ]
Elküldve: 2003. 01. 27. 13:44
idézet:
Ezt írta NeverGone, a tökös:
Két kérdésem lenne:
Egy másik kérdés: szeretnék a tűzfalon csomagkövetést (connection tracking) alkalmazni ftp-re és irc-re. Viszont nem nagyon találtam hozzá leírást. Valaki fel tudná vázolni, milyen iptables parancsokkal kell ezt létrehozni?[/quote]
Egyszerű. Befordítod a kernelbe (én a netfilter configurations résznél szinte mindent be szoktam fordítani modulként), aztán majd be kell tölteni az ip_conntrack_... modulokat, ha a kliens egy belső hálón van, és maszkolsz neki, akkor az ip_nat_... modulokat is, és az általam már korábban propagált
Elküldve: 2003. 01. 27. 13:45
idézet:
Ezt írta Sniper:
Connection tracking-re hirtelen nincs otletem (nem hinnem, hogy iptables kepes erre... ez egy csomagszuto, nem pedig egy univerzalis karacsonyfa
[ 2003. január 27.: Sniper szerkesztette a hozzászólást ]
[ 2003. január 27.: Sniper szerkesztette a hozzászólást ][/quote]
Bocs. Pontosítsunk. Nem csomagszűrő, hanem állapottartó csomagszűrő (nagyon nem mindegy!). Az pedig támogat connection trackinget.
Súgó
A téma zárva.