SYN-Attacke abwehren (Linux)

  • Per Zufall habe ich bemerkt, dass auf meinem vServer netstat -tuna viele TCP-Verbindungen im Status SYN_RECV zeigte. Eine Überprüfung mit `tcpdump` zeigte, dass mein Server viele TCP-SYN-Pakete empfing. Mein Server war Ziel einer SYN-Attacke.


    Bei der SYN-Attacke werden Verbindungsaufbaupakete (SYN) gesendet, die Bestätigung vom Server (SYN+ACK) wird allerdings nicht beantwortet. Linux wartet normalerweise 60 Sekunden, bis der Verbindungswunsch abgebrochen wird, solange wird sie mit dem Status SYN_RECV in der Tabelle der Netzwerkverbindungen geführt.


    Es ergeben sich 2 Angriff-Szenarien:

    • Linux verwaltet normalerweise max. 1024 Verbindungen, so dass schon 17 (1024/60) SYN-Pakete/sec einen Linux-Rechner lahmlegen können.
    • Linux schickt nicht nur ein SYN+ACK, sondern pro SYN-Paket werden im Laufe der 60 sec Wartezeit 5 SYN+ACK-Pakete geschickt. Damit fungieren die Server als Verstärker bei einem DDoS-Angriff.

    Bei meiner Recherche bin ich auf das folgende Webseite gestoßen. Sie beschriebt, wie man DDoS-Angriffe auf Linux-Server abwehren kann.

    https://javapipe.com/blog/iptables-ddos-protection/


    Ich habe mich auf die Abwehr von SYN-Angriff beschränkt und meinen Server entsprechend konfiguriert. Einerseits kommt der Server nun mit erheblich mehr SYN-Paketen/sec klar, andererseits findet kein Verstärkungseffekt mehr statt. Der Server schickt nur noch ein SYN+ACK-Paket pro SYN-Paket.


    Damit wurde mein Server anscheinend uninteressant für die Angreifer, nach 2 Wochen war wieder Ruhe.

    SYN_attack_PPS.png


    Es folgt nun die Konfiguration von meinem Debian 9 (Stretch) Server.


    Vorweg eine wichtige Warnung:


    Nutzung auf eigene Gefahr.


    Solche tiefgreifenden Änderungen im System können leicht fatale Folgen haben. Ihr müsst sehr gut verstehen, was die Konfigurationsänderungen bewirken und wie ihr etwaige Probleme selber löst. Weder netcup noch ich können euch da groß unterstützen.


    Das Modul nf_conntrack_ipv4 muss frühzeitig geladen werden, damit die Kernel-Parameter für die Firewall gesetzt werden können.

    Code: /etc/modules
    nf_conntrack_ipv4


    Ich habe mich dazu entschieden, die Kernel-Parameter und die Firewall-Einträge in /etc/rc.local einzutragen.


    Die Ports, die von außen erreichbar sein sollen, müssen angepaßt werden. Bei mir sind 22(SSH), 80(HTTP) und 443(HTTPS) erlaubt.

  • Wie alt ist denn Dein OS? Wir haben heute bereits Systemd anstelle der Init-Scripte.

    Ich nutze Debian 9 (Stretch), werde demnächst auf Debian 10 (Buster) updaten. Beide Versionen bieten den Systemd-Dienst "rc-local", der /etc/rc.local beim Start ausführt. Wie üblich unter Linux gibt's viele andere Wege um zum gleichen Ziel zu gelangen, sicher auch welche die besser in die systemd-Philosophie passen.

  • Habe den Server mit Debian 10 (Buster) neu aufgesetzt, mit dem default systemd. Meine Konfiguration musste nur in einem Punkt geändert werden.


    Ab Linux-Kernel v4.19 gibt's das Modul nf_conntrack_ipv4 nicht mehr, es wird durch nf_conntrack ersetzt. /etc/modules sieht also jetzt so aus:


    Code: /etc/modules
    nf_conntrack


    /etc/rc.local funktioniert weiterhin, kann also unverändert übernommen werden.


    Ich hatte als Idee das ganze auf nftables umzustellen und sauber in systemd zu integrieren. Leider ist das nft_synproxy-Modul erst ab Linux-Kernel v5.3 verfügbar. Da werde ich noch einiges warten müssen, bis das bei Debian stable ankommt.

  • Da habe ich doch tatsächlich IPv6 nicht beachtet.


    Die Lösung ist einfach: Ergänzend zu den iptables Kommandos diese durch ip6tables ersetzen und zusätzlich ausführen.


    Alt:

    Code
    # Allow only SSH/HTTP/HTTPS from the outside
    iptables -t mangle -I PREROUTING 1 -i lo -j ACCEPT
    iptables -t mangle -I PREROUTING 2 -p tcp -m multiport \! --dports 22,80,443 -j DROP
    
    ...
    
    # iptables rules for SYNPROXY
    iptables -t raw -A PREROUTING -p tcp -m tcp --syn -j CT --notrack
    iptables -A INPUT -p tcp -m tcp -m conntrack --ctstate INVALID,UNTRACKED -j SYNPROXY --sack-perm --timestamp --wscale 7 --mss 1460
    iptables -A INPUT -m conntrack --ctstate INVALID -j DROP


    Neu:

  • Seit knapp 4 Jahren (Linux 4.4) sollte der synproxy überflüssig sein, weil der Kernel in dem Bereich verbessert wurde und mit Millionen von SYN-Paketen pro Kern umgehen kann.

    Selbst Debian oldstable/9/stretch hat da schon einen viel aktuelleren Kernel, deswegen verstehe ich nicht warum das hier empfohlen wird?

  • elbst Debian oldstable/9/stretch hat da schon einen viel aktuelleren Kernel, deswegen verstehe ich nicht warum das hier empfohlen wird?

    Ganz einfach, ich wusste es nicht besser. Ich habe jetzt erst einmal alle meine Einstellungen rausgenommen und werde den nächsten SYN-Flood abwarten. Wenn sich zeigt, dass man gar nichts machen muss, um so besser.

  • Da der nächste SYN-Flood glücklicherweise auf sich warten lässt, habe ich mit hping3 meinen Server selbst mit SYN-Paketen beschossen. Wie der User "customer" schon mitgeteilt hat, ist Linux ab v4.4 gegen SYN-Attacken gehärtet, nochmals vielen Dank für die Info. Ich habe testweise meinen VPS-200 mit 3500 SYN-Paketen/Sekunde beschossen. Die CPU-Last erhöhte sich marginal um 5-6% und ich konnte weiterhin problemlos mit dem Server arbeiten, als wenn nichts geschehen sei. Also (fast) alles im grünen Bereich.


    Worauf man allerdings achten sollte, ist dass der Server als DDoS-Verstärker dienen kann. Jedes nicht beantwortetes SYN-ACK-Paket wird normalerweise 5 mal wiederholt. Wenn jemand ein SYN-Paket mit einer gefälschten Absende-IP schickt, die den SYN-ACK nicht beantwortet, schickt unser Server sechs SYN-ACK-Pakete. Durch verringern des Kernel-Parameters net.ipv4.tcp_synack_retries kann man die Anzahl der SYN-ACK-Wiederholversuche verringern. Damit verstärkt der Server nicht mehr so stark wie andere Server und wird dadurch weniger interessant. Der Parameter sollte aber auch nicht zu klein sein, sonst werden Paketverluste nicht mehr ausgeglichen.


    Alles was bleibt ist also in einer Konfigurationsdatei in /etc/sysctl.d den Kernel-Parameter net.ipv4.tcp_synack_retries = 2 zu setzen. Meine vorherigen Konfigurationsvorschläge sind glücklicherweise überflüssig.