N

o właśnie, co z tymi pakietami SYN? Tutaj ponownie pojawia się problem skalowalności systemu conntrack (tak jak dla stanu listen) dla tworzenia (lub usuwania) połączeń, które spowoduje zalew pakietów SYN. Nawet jeśli uporamy się z blokadą w warstwie conntrack to kolejnym krokiem wędrówki pakietu SYN będzie stworzenie gniazda w trybie “nasłuchu”, czyli kolejną barierą wydajnościową. Normalnym procesem łagodzenia tego typu pakietów w systemie Linux będzie mechanizm SYN-cookies, który również ma ograniczenia.

Podczas warsztatów Netfilter w 2013 roku problem ten zaadresowali Patrick McHardy, Martin Topholm oraz Jesper Brouer powołując do życia moduł “SYNPROXY” dla iptables (od v1.4.21). Rozwiązuje on powyższe problemy – zrównolegla mechanizm SYN-cookies oraz nie tworzy wpisów conntrack zanim pakiet SYN-ACK nie zostanie dostarczony tym samym unikając blokady tworzenia nowych połączeń. Może zostać użyty do ochrony lokalnego systemu, jak i hostów za zaporą ogniową. Raz, gdy połączenie zostanie poprawnie zapoczątkowane dalszą jego obsługę przejmuje system conntrack wykonując wszystkie niezbędne translacje (używając części kodu mechanizmu NAT).

W ten sposób trochę trzeba się napracować, aby za pomocą pakietów SYN zDoSować pojedynczy host. Do implementacji SYNPROXY na swoim serwerze możemy wykorzystać skrypt bash Jespera.

Więcej informacji: Mitigate TCP SYN Flood Attacks with Red Hat Enterprise Linux 7 Beta, Working with SYNPROXY, implement netfilter SYN proxy.