ICMP és a tűzfal

 ( nandorsoma | 2017. február 12., vasárnap - 21:00 )

Sziasztok!

A neten különböző érvek/ellenérvek találhatóak, hogy mely icmp üzeneteket kell vagy érdemes átengedni. Sajnos abból adódóan, hogy túl sok az eltérő cikk ezzel kapcsolatban, tudnátok nekem segíteni összeállítani egy listát arról, hogy mit kell, illetve mit érdemes és miért átengedni? Ha esetlen egyiket csak az egyik irányban érdemes, kérlek azt is jelezzétek.

Egyelőre így néz ki a listám:


Echo request                    Type0
Echo reply                      Type8
Fragmentation Required (IPv4)   Type3 Code4
Time Exceeded                   Type11
Traceroute                      Type30

Type3-ból érdemes esetleg inkább mindent engedni?

Korábban a pinget és tracerouteot mindenképpen le akartam tiltani biztonsági okokból, de azóta már meggyőztek róla, hogy ez nem feltétlenül igaz.

A kérdés előzménye pedig itt található: http://hup.hu/node/151995, csak nem igazán kapcsolódott az eredeti kérdéshez, ezért inkább indítottam neki egy új témát.

Hozzászólás megjelenítési lehetőségek

A választott hozzászólás megjelenítési mód a „Beállítás” gombbal rögzíthető.

Egyszerű, érdemes a LEDE ICMP beállítást majmolni.

Azt elfelejtettem, írni, hogy alapvetően ipv4-ről van szó. Mindenesetre elteszem ezt a linket későbbre, mert még biztos, hogy jól fog jönni.

én ezt szoktam használni:

-A INPUT -p icmp --icmp-type 0 -j ACCEPT
-A INPUT -p icmp --icmp-type 3/4 -j ACCEPT
-A INPUT -p icmp --icmp-type 3/3 -j ACCEPT
-A INPUT -p icmp --icmp-type 3/1 -j ACCEPT
-A INPUT -p icmp --icmp-type 4 -j ACCEPT
-A INPUT -p icmp --icmp-type 8 -m limit --limit 1/s -j ACCEPT
-A INPUT -p icmp --icmp-type 8 -j LOG --log-prefix "FW-ICMP-IN-8 Excessive: "
-A INPUT -p icmp --icmp-type 8 -j DROP
-A INPUT -p icmp --icmp-type 11 -j ACCEPT
-A INPUT -p icmp --icmp-type 12 -j ACCEPT
-A INPUT -p icmp -j LOG --log-prefix "FW-ICMP-BAD-TYPE-IN: "
-A INPUT -p icmp -j DROP

http://www.nthelp.com/icmp.html

a --icmp-type 8 -j LOG-ra is tennék egy --limit-et, másképp a network stack helyett a logot nyomja telibe, ami feltehetőleg méglassabb device-on van :)

~~~~~~~~
deb http://deb.uucp.hu/ wheezy yazzy repack

bár helyileg nem sok szerveren van nagyméretű logpartíció (elég csak kevés history megtartani lokálisan) viszont a központi log kapkodhatott volna :)
amúgy ha a /var/log betelik az adott szerveren, akkor legalább már nem tekeri a disket, haha, a monitorozó, meg visít, hogy baj van, de amúgy jogos, köszi az észrevételt, szét is küldtem a szerverekre :)

Köszönöm a választ!

Amatőr módon szeretném megkérdezni, hogy ezeket kifelé is kell engedélyezni igaz? Például az én szerverem is produkálhat másoknak mondjuk 3-as icmp üzenetet nem?

én kifele mindet szoktam engedni.
ha kolátozni akarom az általam felügyelt gépen, azt nem tűzfal szinten teszem. pl normal user nem is tud csak úgy icmp csomagot kiküldeni. tehát vagy egy privilégizált folyamat teszi, vagy az ip stack.
ha routerről/gatewayről van szó, ahol a mögötte lévő hálózat gépeit nem mindet felügyeled, akkor jobban bele lehet gondolni, kifele mit és hogyan engedsz. (btw a "hálózatból kifele" csomagok is először a gateway PREROUTEING lancába fognak érkezni)

~~~~~~~~
deb http://deb.uucp.hu/ wheezy yazzy repack

visszatalálós subscribe

+

Ezt sajnos nem tudom értelmezni. :(

Feliratkozott a szalra. Ha megnezed a profilodat, itt van egy tracker azokkal a topikokkal, amikhez hozzaszoltal. Mivel az oldalon maskepp nincs feliratkozaskezeles, ezert ezt egy - ertektelen - hozzaszolassal szoktuk elintezni.
--
Blog | @hron84
Üzemeltető macik

Ez mókás. :)

had fordítsam meg a kérdést (nem feltétlenül a posztolónak címezve, hanem bárkinek, aki tud értelmesen válaszolni):

Melyik ICMP üzeneteket kell vagy érdemes blokkolni vagy korlátozni? És melyiket miért?

Ha jól emlékszem, az ICMP az a hálózat működéséhez kapcsolatos üzeneteket takarja.

Azt tudom, hogy lehet pingeléssel gondot okozni: túl sok üzenetet küldeni és ezzel erőforrást lefoglalni, túl nagy üzenetet küldeni (úgy emlékszem, régen ezzel meg is lehetett borítani gépeket).
Emiatt pl. lehetne írni, hogy ping max. x méretű max. y gyakoriságú lehessen (vagy tiltott, bár az azzal jár, hogy nehezebb tesztelni)

Szóval ilyen válaszokra gondoltam.

Én eddig minden ICMP üzenetet engedtem mindkét irányba.

Például a "Redirect" ICMP üzeneteket nem célszerű elfogadni boldog-boldogtalantól.
Ráadásul a 41-255 type-ok jelenleg reserved, de később kaphatnak funkciót és ki tudja mit, ezért célszerű azokat is tiltani.

Ilyen például az IPv6-os kapcsolatok is, nem egyszer láttam, hogy IPv4-es tűzfal be volt állítva, de az IPv6-on semmi, tárva nyitva minden, miközben a gépnek volt is IPv6-os címe, az összes szolgáltatás bind-olt rá.

Mindennek fényében szerintem célszerű mindent tiltani (IPv4, IPv6) és engedni csak azt ami kell, így később nem érhet meglepetés, vagy legalábbis kisebb az esély rá.

"nem egyszer láttam, hogy IPv4-es tűzfal be volt állítva, de az IPv6-on semmi, tárva nyitva minden, miközben a gépnek volt is IPv6-os címe, az összes szolgáltatás bind-olt rá."

Ilyenem volt mar nekem is, amikor a szolgaltato suttyomban engedelyezte az IPv6-ot (vagy ha jeleztek is, hogy lesz ilyen, hozzam mar nem jutott el a hir) aztan valamikor veletlenul randomban raneztem a gepre komolyabban, akkor lattam, hogy whoa, van IPv6 cimunk.

Szoval az ilyen nem feltetlen a rendszergazda sara.
--
Blog | @hron84
Üzemeltető macik

"Szoval az ilyen nem feltetlen a rendszergazda sara."

Azért IPv6-ot bekapcsolva hagyni és nem foglalkozni vele, mondván hogy úgysem működik... erről azért nem jelenteném ki, hogy nem a sara. Ha elfogadjuk azt, hogy nem működik, akkor tegyünk is róla! Az IPv6 is tiltható...

Egyébként ilyen suttyomban bekapcsolós móka legszebb az volt, amikor kugli kezdte el visszadobálni a leveleket, mert gondja lett a reverz feloldással. Naná, mert a jelzés nélkül bekapcsolt IPv6 miatt a kugli felé IPv6-on indult a levél, viszont az IPv6 reverz meg persze hogy nem volt rendben, tehát jogos is volt. Csak a levelezés ezt annyira nem szerette.

Van, amikor rossz otlet tiltani az IPv6-ot. Volt mar olyan bugom, amire az volt a megoldas, hogy vissza kellett engedelyezni az IPv6-ot, mert maskepp nem mukodott a rendszer.

Egyebkent meg orokolt belsos gep volt, nulla dokumentacioval, cserebe kritikus appokkal. Orultem, hogy valahogy megy, nem hogy meg bele is piszkaljak.
--
Blog | @hron84
Üzemeltető macik

És hogyan definiálod azt, hogy mi kell?

ICMP! A nevében benne van, hogy management protokoll. Vagyis by default minden kell.

Aminek részemről értelmét látom, hogy ratelimitelve legyen az átengedett icmp mennyiség flood ellen, de nem kompletten eldobálni mindent / néhányat átengedni.

Bejövő irányban nem szükséges minden ICMP a működéshez. Szerintem a LEDE tűzfal jó default. Még nem volt semmi problémám vele.

az SMTP-nél sem fogadsz be minden szemetet, előszűröd
az ICMP is tud sok mindent, vissza is lehet élni vele, ezért célszerű szűrni kintről bizonyos funkciókat

a szervereken is van management port, még sem rakjuk ki publicra őket :)

Jelenleg egyébként nézeteltérésben állok valakivel, aki szerint semmilyen icmp forgalmat nem kell engedni. Az ő véleménye, hogy amíg nincs valamire explicite szükség, vagy nem jelentkezik hiba, addig nem érdemes foglalkozni az engedélyezésével. Amivel egyébként nehéz vitatkozni, míg az ember be nem tudja bizonyítani az ellentétét.

Konkrétan egyébként egy tomcates java alkalmazásról van szó, ami restes kéréseket szolgál ki, látszólag minden probléma nélkül, úgy hogy minden icmp forgalom le van tiltva. Tehát egyelőre úgy tűnhet igaza van, mert nem látunk semmi gyanús dolgot, vagy hibát.

Azonban kicsit zavarban vagyok, mert nem értem, hogyan működhet mégis minden látszólag jól, annak ellenére, hogy a legtöbb helyen azt lehet olvasni, hogy bizonyos icmp typeok elengedhetetlenek a hálózat normális működéséhez.

Ezért kíváncsi lennék, hogy tudok-e generálni valamilyen hiba jelenséget, ami az icmp protokoll blokkolásából adódik.

Vegyük például a type3 fragmentation required-et. Nekem az utóbbi pár nap utánaolvasásai és itteni postok alapján ez tűnik a legfontosabbnak. Elvileg ebben az esetben bizonyos csomagok eldobódnak anélkül, hogy a küldő tudná, hogy csökkenteni kell a méretüket. Hogyan tudok egy olyan helyzetet generálni, amivel be tudom bizonyítani, hogy igenis probléma, ha ezt a konkrét typeot nem engedélyezem?

Tegyel be a pathba a kliens es szerver koze olyan elemet, ahol az mtu <1500. Mondjuk allitsd be 1312-re. (Hasrautottem, es mondtam egy szamot.)
PMTU detection-t a jo eros icmp szuressal mar agyonutotted.

Jah, es indits a kliensrol olyan kereseket, ahol a valaszban burstben akar majd jonni egyszerre jo sok, mondjuk 16k adat.

Majd pislogj! ;)

Nem pont az a lényeg, hogy a szerveren kicsi az mtu? Ha az előtt kicsi már, akkor sokat nem érek vele, hogy van-e type3 vagy sem. Nem?

A szervereteken 1500 bájt az mtu, szépen ki is küldi a nagy pakettot, amire a kliens felől menni fog egy icmp reply, hogy csökkentsétek a csomagméretet, ami ti eldobtok és pislogtok, hogy miért nem megy át az 1500 bájt.

Végy egy routert amin beállítod a lan felőli interfész mtu-ját 1460 bájtra, majd egy lanon lévő gépről küldj egy nagyobbacska http lekérést az api felé s lám.

Most már értem, köszi! Ki fogom próbálni!

Előfizetsz a IPv6-os UPC-re [1] [2] :)