iptables gondok

Linux-security

iptables gondok

  • 894 megtekintés

( mumia | 2003. 12. 27., szo – 13:00 )

Beállítottam egy jó kis firewallt a linuxomban az iptables segítségével. Néha egy egy kérésre mégis válaszolgatott a gép, ezért az INPUT lánc policy-jét DROP-ra állítottam. Ezután még mindíg válaszolgat. Ha az OUPUT lánc policy-jét is DROP-ra állítom, akkor már nem válaszol. Ezután nyomok egy tcpdump-ot, és azt látom kiírva, hogy jött x csomag, ebből eldobva 0. Mi a fenéért nem azt írja, hogy eldobva x, hiszen az INPUT lánc policy-je DROP.

Ha valaki tudja a megoldást, akkor írjon bátran!

Üdv,
Mumia

( Névtelen (nem ellenőrzött) | 2003. 12. 27., szo – 16:15 )

Milyen kérésre adott választ a géped?

A tcpdump azokat a csomagokat is kiírja, amelyeket a tűzfal eldob (most próbáltam ki). A "0 packets dropped by kernel" azt jelenti, hogy a tcpdump minden csomagot időben át tudott venni feldolgozásra, egyiket sem kellett a kernelnek hely hiányában eldobnia.

( mumia | 2003. 12. 27., szo – 23:34 )

Én is azt gondoltam, hogy a kiírás nem lesz szinkronban a valósággal. Ennek ellenére nem értem, miért nincs, hiszen az iptables kernel szinten van megvalósítva, tehát kernel szinten kellen eldobni is, nem? De a lényeg, hogy ettől még műkedhet jól a tűzfalam. Ez megnyugtató. Ugyanakkor az lenne még a kérdésem, hogy milyen paranccsal lehet akkor azt megnézni, hogy a tűzfal mit dobott el?

Köszi a segítséget,
Mumia

( Névtelen (nem ellenőrzött) | 2003. 12. 28., v – 07:40 )

Egyszeru. Csinalsz egy log celpontra iranyitott szabalyt az eldobando csomagok parametereivel es cat /var/log/syslog ;).

( trey | 2003. 12. 28., v – 10:30 )

[quote:0eb02ff273="Anonymous"]Egyszeru. Csinalsz egy log celpontra iranyitott szabalyt az eldobando csomagok parametereivel es cat /var/log/syslog ;).

vagy inkabb tail -f /var/log/syslog

:-)

( Névtelen (nem ellenőrzött) | 2003. 12. 28., v – 11:29 )

iptables -L -v mit mond? Abban megmonnya mennyit dobott el, legalabbis itten nekem. Az hogy nem dobsz el egy csomagot ab ovo, nem jelenti azt hogy valaszol.

( mumia | 2003. 12. 28., v – 12:31 )

Szóval hát elég érdekes a dolog. Ha jön egy echo request, akkor kűd a kis aranyos egy port unreachable icmp üzenetet. De hogy ezt minek aztat én nem értem. Hiszen le kéne generálnia a tcp-nek eztet nemde?

Szóval én nem küldenék a helyében semmit, és ezzel a tcp protolollunk egyértelműen tudná, hogy nem érhető el az adott host a hálózatban. Ha viszont port unreachable üzenetet küldök, akkor azt hiszi, hogy torlódás van vagy efféle, de látszik a gép. Miért jó ez neki???

Mumia

( Névtelen (nem ellenőrzött) | 2003. 12. 28., v – 15:03 )

[quote:770b135567="mumia"]Szóval hát elég érdekes a dolog. Ha jön egy echo request, akkor kűd a kis aranyos egy port unreachable icmp üzenetet. De hogy ezt minek aztat én nem értem. Hiszen le kéne generálnia a tcp-nek eztet nemde?

Szóval én nem küldenék a helyében semmit, és ezzel a tcp protolollunk egyértelműen tudná, hogy nem érhető el az adott host a hálózatban. Ha viszont port unreachable üzenetet küldök, akkor azt hiszi, hogy torlódás van vagy efféle, de látszik a gép. Miért jó ez neki???

Mumia

Hat az ICMP-t szerintem hagyd. Ha valaki nagyon jaccik, akkor idolegesen tiltsad le, de amugy mind1. Azt is nezd meg, hogy honnan jonnek az icmp, a netszolgaltatodtol, mindig engedd :-)

( kecsa | 2003. 12. 28., v – 21:41 )

[quote:5e07adae5e="mumia"]Szóval hát elég érdekes a dolog. Ha jön egy echo request, akkor kűd a kis aranyos egy port unreachable icmp üzenetet. De hogy ezt minek aztat én nem értem. Hiszen le kéne generálnia a tcp-nek eztet nemde?

Szóval én nem küldenék a helyében semmit, és ezzel a tcp protolollunk egyértelműen tudná, hogy nem érhető el az adott host a hálózatban. Ha viszont port unreachable üzenetet küldök, akkor azt hiszi, hogy torlódás van vagy efféle, de látszik a gép. Miért jó ez neki???

Mumia

Az ICMP destiantion unreachable azt jelenti, hogy az adott cim nem elerheto, a port unreach meg azt, hogy az adott port nem. Egyik sem jelez torlodast.

Az iptables-ben a -j REJECT azt jelenti, hogy menni fognak (valamilyen) ICMP uzenetek vissza azutan, hogy a csomag dobva lett, a -j DROP meg azt jelenti, hogy a csomag dobva lesz es kesz.

( mumia | 2003. 12. 29., h – 10:59 )

A tcp csodálatos tulajdonságai közé tartozik, hogy slowstart-al indul, majd az első letörés után multiplikatívan visszavesz, aztán szépen additívan növel, és multiplikatívan csökkent, és ez így a végtelenségig. Ez ha jól tudom a kihirdetett ablakmérettől függően megy. Szerintem itt a destination unreachable üzenet száguldozik, ha a kihirdetett ablakméret 0-ra csökken. Ez pedig nem más mint torlódásvezérlés. Tévednék?

Üdv,
Mumia

( kecsa | 2003. 12. 29., h – 11:52 )

[quote:0349e1a6ae="mumia"]A tcp csodálatos tulajdonságai közé tartozik, hogy slowstart-al indul, majd az első letörés után multiplikatívan visszavesz, aztán szépen additívan növel, és multiplikatívan csökkent, és ez így a végtelenségig. Ez ha jól tudom a kihirdetett ablakmérettől függően megy. Szerintem itt a destination unreachable üzenet száguldozik, ha a kihirdetett ablakméret 0-ra csökken. Ez pedig nem más mint torlódásvezérlés. Tévednék?

Üdv,
Mumia

Attol tartok tevedsz. A TCP flowcontrol (amirol beszelsz) kizarolag a TCP jelzesek alapjan mukodik, amennire en tudom. IPv6-ban szolhat bele az ICMP mivel ott mar van MTU discovery (legalabb is ott kotelezo), abban az esetben megy vissza ICMPv6 uzenet TCP-vel (de massal is) kapcsolatban, ha a beallitott csomagmeretet csokkenteni kell, mivel IPv6-ban a korbenso router-ek nem fragmentalnak IP szinten.