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