Hlavní navigace

Názor ke zprávičce Akamai odrazil rekordní útok, přicházelo při něm 809 milionů paketů za sekundu od František Ryšánek - Díky za reakci, zjevně máte přehled. Měl byste...

  • Aktualita je stará, nové názory již nelze přidávat.
  • 28. 6. 2020 23:30

    František Ryšánek

    Díky za reakci, zjevně máte přehled. Měl byste čas to trochu rozvést? Mě totiž překvapuje, že čekáte obranu proti SYN flood "všude po cestě". Já bych to na základě svých reznoucích zkušeností viděl trochu jinak :-)

    Pokud začnu na konci u zombíka = na napadeném počítači u někoho doma nebo v malé firmě, tak první po cestě bude nějaký SoHo router. Ten určitě dělá NAT/maškarádu směrem ven, takže stateful inspection a connection tracking tabulka tam bude určitě. Ale rate-limit na TCP SYN směrem ven? Pochybuju. Ačkoli je možné, že i ten jeden zombík malému SoHo routeru pěkně ucpe conntrack tabulku, zejména pokud bude střídat zdrojové TCP porty = tomu bych rozuměl.

    Pokud není po cestě od zombíka do divokého internetu žádný další NAT, tak už bych tam tím méně čekal box, který bude mít sílu, dělat jednotlivým SoHo koncákům rate-limit proti SYN floodingu. (Možná jsem mimo branži už moc dlouho.) Pokud to neudělá CPE, tak osobně na access vsázím míň. Páteře se tím myslím už vůbec nezabývají (core, provider edge a podobné routery) - ledaže v dnešní době SDN by měly API pro selektivní filtrování příchozího trafficu na konkrétní lokální cíle, na požádání. To si cucám z prstu.

    Jak se blížíme k serverovému konci tak uznávám, že banky a podobné finanční instituce mívají nejeden firewall, a nebývají to firewally levné :-) Ovšem pokud se týče samotného webového "serveru v první linii", tak před ním může být předsunutý cca 1 firewall. Pokud vůbec nějaký. Konkrétně když slyším AKAMAI, tak mi to zní spíš jako nějaký cloud/farma, nájemné paralelizované řešení stavěné na vysokou průchodnost. Tam bych před serverem nečekal předsunutý klasický dýchavičný firewall - ale co třeba content switch? Nějaký load-balancer, patrně postavený na HW akceleraci. A souhlas, ten by asi mohl umět reagovat na SYN flood.

    Takže nakonec, pokud srovnám možnost zaútočit na port 80 TCP, vs. port 80 UDP, tak při použití TCP SYN floodingu aspoň trochu potrápím connection tracking na straně serveru (resp. v předsunutém content switchi) - kdežto UDP na port 80 bude padat rovnou do /dev/null, pokud náhodou není ve firewallu / content switchi explicitně nakonfigurován jako podporovaný. Pokud UDP není podporovaný, tak jeho dropnutí je výpočetně mnohem míň náročné, než reakce na TCP syn flooding na bázi rate-limitu navázaného na connection tracking.