Tak nějak přemýšlím na tím, jak tam mikrotik tlačí jako dočasné řešení omezení počtu nových konexí. To by znamenalo, že minimálně jedna část problému je vyčerpání paměti conntrack tabulkou.
A pokud to tak je, tak mají opravdu omezené možnosti, co s tím. To je problém návrhu IPv6 v kombinaci se stavovým firewallem (a tak nějak obecným stavem internetu). Prostě DoS.
Pokud chce někdo provést útok na conntrack tabulku, tak co má za možnosti? Poslat mi 65536 paketů ze své IP, pokaždé s jiným zdrojovým portem. Může zkombinovat s cílovým portem ... a brzy narazí na svoje vlastní limity (má 2^32 možností, tedy musí zvládnout 4 miliardy spojení). Musí tedy použít nějaké botnety pro DDoS.
Nojo, jenže i scriptkid má pro sebe se vší pravděpodobností 2^64 IPv6 adres (a každou s 2^32 kombinací portů). A nepotřebuje conntrack ... Čili to, co bylo trochu problematické u IPv4 je zde dost zjednodušeno. Prostě posílá pakety ze svých adres.
Pokud budeme posílat 20 paketů za vteřinu velikosti 150B (řekněme plusmínus, náhodně), vygenerujeme 24 kbit/s provozu - všimne si někdo? Ale u cíle to je 72000 nových spojení za hodinu. A teď je otázkou, jak vysoké jsou timeouty toho cíle - za pět hodin to je už 360000 spojení.
Jeden záznam v conntracku zabíral 308B v dobách 2.6 jádra na 32bitech (teď jsem to nehledal, ale pochybuji, že by to bylo méně). Za těch mých hypotetických 5 hodin máme hned 110 MB RAM v čudu ...
A to je to pořád teorie s 24 kbit provozu!
Čili možná ano: IT'S NOT A BUG, IT'S A FEATURE
