sysctl net.inet.icmp.icmplim

[Zbyněk Burget]

Dne 19. 4. 2015 v 13:48 Dan Lukes napsal(a):
> On 04/19/15 13:22, Zbyněk Burget:
>>>> +Limiting icmp unreach response from 252 to 200 packets/sec
>>>> +Limiting icmp ping response from 211 to 200 packets/sec
>>>> +Limiting closed port RST response from 301 to 200 packets/sec
>> Nedokazu odhadnout, jak dalce neco takoveho zatezuje sit.
>
> Prave jsi to udelal. Evidentne ji to zatezuje natolik zanedbatelne, ze 
> te to nikdy nevyburcovalo ke zkoumani veci alespon natolik 
> povsechnemu, ze bys dopad dokazal odhadnout lip.

No jo, ale to, ze jsem se tim zatim nezabyval neznamena, ze to nejaky 
dopad treba i na vykon routeru mit nebude. Zatim jsem to prechazel s 
tim, ze to tak proste je, jen se mi to nelibi. Dnes jsem si rekl, ze se 
na to zkusim podivat, jen poradne nevim, jak realne zjistit, jestli to 
nejaky dopad muze mit. Proto jsem se nejdriv ptal, jestli to nekdo nejak 
resi (proto, ez to realne vliv na vykon/propustnost ma/muze mit/ma 
obcas/utocnik pozna, ze timhle smerem neco pokazi) a nebo to nikdo 
neresi, protoze je to zanedbatelna cast provozu, resp. snaha o likvidaci 
takoveho provozu by byla nakladnejsi, nez reseni mozne vznikle skody.

>> Jsem rad, ze se dozvim, ze se deje neco neobvykleho. Jenze to, co se
>> deje, se bojim, ze neobvykle neni :-( Takze by asi bylo nejjednodussi
>> proste tu hlasku vypnout (zajistuje jine sysctl). Na druhou stranu bych
>> se rad dozvedel, kdyby se nekdo snazil o nejaky DoS utok, kdyby mi
>> konkurence skenovala porty (bohuzel dva lidi v mem okoli jsou toho
>> schopni) apod.
>
> Ty dve vety si proste protireci. Az se pro jednu rozhodnes, zarid se 
> podle toho ;-)

No prave - a ted, jestli to dilema resit a nebo prijmout stavajici stav, 
jako fakt a neresit...

>> kdyz se divam na vnejsi iface, vidim, ze (prakticky) vse jde z 
>> venkovni verejne
>
> Coz neni az takovy prekvapeni, tak to, s vyjimkou situace, kdy je 
> ovnitr site jeden nebo vice zavirovanych stroju, obvykle byva.

Jj, jasne - ja to myslel tak, ze diky NATu nepoznam, jestli jde o provoz 
z vnitrni site nebo ode mne samotneho.
Pri kontrole vnitrniho provozu ale vidim, ze RST / ICMP unreach packetu 
putuje obousmerne pomerne vysoke mnozstvi. Tedy odpovidaji takto klienti 
na vnitrni siti na pozadavky zvenci = pozadavek prosel NATem a rovnez 
prichazeji takto odpovedi zvenci na pozadavky mych klientu.
Moje otazka se tedy ted otaci smerem, jak dalece regulerni je tento 
provoz. Tedy vim, ze regulerni je, ale jak bezny by mel byt. TCP RST je 
prece "nasilne" ukonceni spojeni, ktere by se asi bezne dit nemelo. TCP 
spojeni by melo spravneji koncit FIN packetem, ne? Dival jsem se, ze 
tyhle RST packety jsou nejcastejsi z/na nejaky facebookovy server (ten 
facebook je opravdu mor). Tech RST packetu je ale nejak moc. Takze bud 
jsem presne nepochopil jejich uplny vyznam nebo nechapu, co se u celkem 
dost vysokeho poctu klientu deje.

>> Kdyz se divam na vnitrni iface, tak tam zase samozrejme nevidim utoky
>> zvenci. Bohuzel asi jednoduse nejde nastavit tcpdump tak, abych videl
>> pouze provoz, ktery je urcen pro muj router a nejedna se o provoz, ktery
>> projde NAtem :-(
>
> NATem projde vsechno, co do nej 'divert' pravidlo firewallu zazene. CO 
> se tyce prichoziho provozu, tak obvykle uplne vsechno ...

Ja do natu nestrkam jen provoz pro verejne adresy. Jinak tam jde opravdu 
vsechno.

> Takze muj predpoklad byl spravny a tenhle provoz o nejake vyssi
>> frekvenci bude prakticky jiste neco, co by v siti byt nemelo - tedy pro
>> pripad, ze je to provoz generovany routerem
>
> Nejsem si jisty, jestli si rozumime - ty pakety jsou generovane 
> routerem, ale jsou odpovedi na prichozi paket, ktery routerem 
> generovany neni.

Podstata, jak to funguje, je mi známa :-) Jen nektere podrobnosti mi 
obcas unikaji, resp. mi trva dyl, nez si je uvedomim. V sitarine jsem 
samouk, i kdyz nejakych 15 let celkem a 11 let vlastni site uz nejake ty 
vedomosti prineslo :-)

> A s ohledem na NAT to v nekterych pripadech muze byt odpoved na paket, 
> ktery prisel v souvislosti s drivejsi komunikaci smerovane na nejaky 
> vnitrni stroj - kterazto session uz ale davno zanikla. NAT uz o ni 
> nevi, nevi tedy kam "dovnitr" paket poslat, necha ho tedy nezmemeny, 
> takze paket dostane ke zpracovani jadro routeru - a to ho zamitne jako 
> paket neexistujici session.

Jo - a tohle je presne to, co mi v prvnim okamziku nedocvaklo. Vypada 
to, ze drtiva vetsina tech ICMP unreach je odpoved na nejaky UDP provoz, 
ktery uz neni v NATu a proto na nej odpovi kernel (a nebo se opravdu 
jedna o nejaky utok) a nebo v NATu je, ale uz na nej neodpovida klient 
uvnitr site a pak ty ICMP posila az klient. Bohuzel jsem se v nekolik 
apripadech, kdy jsem to prohlizel, setkal s tim, ze prichazely packety, 
odchazely ICMP unreach a zdroj packetu to evidentne nezajimalo a provoz 
posilal stale dal. V pripade vyse zmineneho facebookoveho serveru to 
bylo dokonce tak, ze od facebooku prisel TCP (https) packet, za 3sec. 
(neni to moc pozde?) klient odeslal ICMP unreach odpoved a facebook za 
dalsich cca 10 sec. poslal dalsi podobny (nebo stejny, obsah jsem 
nezkoumal) TCP (https) packet a opet dostal unreach odpoved. A tohle 
trvalo nekolik minut. Kdyz tech lidi u mne na siti na facebooku sedi 
soucasne 200, tak verim tomu, ze uz to dokaze vygenerovat provoz, ktery 
jsem povazoval za neobvykly.

>> Pokud bych dokazal zjistit IP adresy takovych utocicich stroju, asi 
>> bych je rovnou
>> zarizl na firewallu.
>
> Seznam se pomerne casto meni, v pripade UDP mohou byt zdrojove adresy 
> bez problemu padelane, takze si brzo zablokujes i uzitecny stroje, 
> fireall ti nakonec nabobtna tak, ze ti bude zpomalovat beznou 
> komunikaci ...

Delal jsem to tak, ze se utocici stroje davaly do IPFW tabulky, ktera je 
na firewallu zariznuta a z tabulky se po cca mesici mazou. Takovy seznam 
mel drive kolem 250 polozek, nedavno jich tam bylo kolem 2000 a dnes se 
opet smrskl na 500. Kdyz jich bylo 2000, tak jsem pravidlo z firewallu 
odstranil, aby to pripadne nezpomalovalo, ted nedavno jsem ho tam vratil 
zpet. Zda se, ze to na provoz zadny zasadni vliv nema. Ale tohle jeste 
musim dukladne proverit.

> To se muzes rovnou od site uplne odpojit. Podobny vysledek, min prace. 
> ;-)

Mas recht! Porad rikam, ze se na to vykaslu - cesky lidi jsou vecne 
nespokojeny uz z principu, porad se neco kazi, porad to chce investice, 
porad se ucit neco noveho... Furt si rikam, jak jednoduchy zivot maji 
treba zemedelci nebo popelari - makaj na cerstvym vzduchu, nenici si oci 
u monitoru, nekrivi si zada sezenim... ;-)


Zbyněk Burget
Mlýnská 397
798 26 Nezamyslice

tel: 588 580 000, 739 930 931
http://www.burgnet.cz
IČ:  606 88 220; DIČ: CZ7210184674