Vlákno názorů k článku
Akamai odrazil rekordní útok, přicházelo při něm 809 milionů paketů za sekundu od František Ryšánek - Mě spíš zaujalo UDP :-) *UDP* na port 80?...

  • Článek je starý, nové názory již nelze přidávat.
  • 28. 6. 2020 7:42

    František Ryšánek

    Mě spíš zaujalo UDP :-)
    *UDP* na port 80? To já už bych posílal radši TCP SYN :-) A popravdě... na portu 80 poběží nejspíš jenom nějaký jednořádkový redirect na HTTPS na portu 443... Velmi energické plácnutí do vody... nebo ne? Žeby někdo testoval konkrétně QUIC?
    https://en.wikipedia.org/wiki/QUIC

  • 28. 6. 2020 7:52

    František Ryšánek

    Nojo, ale kdyby šlo o QUIC (UDP na portu 80) tak 1 bajt payloadu by byl stejně asi málo i na počáteční handshake...
    To vážně vypadá spíš jako stress-test infrastruktury switchů a routerů.

  • 28. 6. 2020 11:49

    Křišťan Surname

    Proti SYN flood útoku už dlouho existují velmi účinné ochrany prakticky všude po cestě k cíli (např. stateful firewally to rozpoznají a zaříznou), zatímco ten UDP flood proleze bez omezení.

    28. 6. 2020, 11:50 editováno autorem komentáře

  • 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.

  • 29. 6. 2020 12:06

    František Ryšánek

    Hm tyjo... tak jsem si přečetl takové povrchní overview, co všechno umí Cisco Nexus v rámci "Inband Network Telemetry" a trochu mi klesla čelist :-)