Limit paketu per zdrojova IP a SYN flood

[Radek Krejča]

Ahoj

> Vam se nejak castejc stava, ze mate problem s timhle typem utoku ?
> 
[Radek Krejča] 
To se tedy stava. Ono to prichazi ve vlnach, nevim sice presne, jak to funguje v praxi, ale muj odhad je, ze si proste nekdo zaplati par dni a behem te doby se do toho busi. Za poslednich 24 hodin mam 3 masivni utoky zvenci (ono je jich mozna vice, ale po kazdem utoku to reze dodavatel, takze pokud nezmeni drobne zadani, tak se k nam uz nedostane). To nicmene operativne resime s dodavateli a rezeme na to na hranicnich routerech, nicmene je to nekonecny boj, meni se porty, adresy, vse. Kazdopadne tohle me az tak netrapi, tam neni zbyti, nez resit to jako vyse. Co me stve a posledni dobou to znacne narusta, je smer od nas ze site, kdy jsou zakaznici evidentne soucasti utoci site, at uz napadenymi pocitaci, ale mame potvrzene nektere settoboxy z ciny a dokonce jsme resili 2 pripady hacknutych firmware routeru (pro zajimavost to byla Tenda v jedne revizi a na ten druhy si za boha uz nemuzu vzpomenout).

> Ja samozrejme vim co je to za utok, ale musim rict, ze jsem se s nim
> snad jeste v praxi nepotkal. Nebo tak davno, ze uz si to ani
> nepamatuju.
[Radek Krejča] No, dobre pro Tebe a zavidim, to je asi tak vse, co k tomu rici :-).

> 
> To si nestezuju, ani se nevytahuju, jen je mi to proste divny.
> 
> To myslis, ze stves nejakou konkurenci az tak, ze si na tebe objednala
> utok ?
[Radek Krejča] Vzhledem k tomu, ze to resime v pomerne caste mire (relativne uspesne, az doted, kdy to nabyva uz neunosnych rozmeru a chtel bych to vyresit nejak "heuristicky"), tak bych rekl, ze je nekolik typu zadani utoku. Jednak si nekdy zaplati utok na nas, tam je to vcelku jasne. Udajne jde takovy utok poridit za par dolaru, tak si holt nekdo od konkurence zaplati. Druhy typ utoku je ale na konkretni ip routeru-NATu. Tam mi trochu unika smysl, zda je to tedy na nas, tak to moc nechapu a pokud je to na klienta, tak zase nechapu, jak by utocnik zjistil (pokud se tedy neznaji natolik dobre, aby ho spravne zaradil do nasi infrastruktury), pres jaky router je dany klient pripojen. No a treti typy utoku jsou na konkretni IP vlastene zakazniky i s jejich dns zaznamy, ci servery. Tam je to jednoduche, nekdo si to zaplati take.

> 
> Protoze druhy mozny vysvetleni je, ze utoky jsou necileny - pak ale
> tezko cekat, ze se nasim sitim vyhejbaj. A pokud se nevyhejbaj, jakto,
> ze to nase stroje ustojej bez nutnosti menit konfiguraci ?
[Radek Krejča] Podle meho jsou jednoznacne cilene. Ty vlny, ktere probihaji par dni, maji stejny prubeh, stejna cilova IP. V nasem objemu trafficu nepozname jednoduse pripadne "ocichavani", ale to je v dnesni dobe pomerne neefektivni a jsou to vyhozene penize.

> 
> Dobre, to jsou tak trochu spis akademicke otazky, takze zpatky k necemu
> praktictejsimu.
> 
> Me az tak divny nepripadalo, ze s timhle potize nemame - SYN Cache
> ochrana, ktera v jadre je se mi jevila dobre navrzena, takze jsme
> predpokladal, ze se s utoky uspesne vyrovnava ona. Ale to porad
> nevysvetluje, proc u tebe problem je a u nas nejsou.
> 
> Napadla me tedy kacirska myslenka - ze za tim je samo PF, ktere ja
> nepouzivam. PF totiz pakety dostane driv nez jadro. A pokud je stavove,
> tak je otazka, kdy si pro nove spojeni alokuje "stavovou informaci" a
> jak se ono samo s takovym utokem vyrovnava. Tedy, hypoteza je, ze s
> utokem nema problem jadro, ale PF.
> 
> Jak u tebe vypada vypis
> 
> sysctl -a net.inet.tcp.syncache
[Radek Krejča] 
% sysctl -a net.inet.tcp.syncache
net.inet.tcp.syncache.bucketlimit: 30
net.inet.tcp.syncache.cachelimit: 15375
net.inet.tcp.syncache.count: 0
net.inet.tcp.syncache.hashsize: 512
net.inet.tcp.syncache.rexmtlimit: 3
net.inet.tcp.syncache.rst_on_sock_fail: 1

Radek