Fragen zu diversen Anti-DDoS-Maßnahmen mittels iptables

  • Thread starter Thread starter Deleted member 11625
  • Start date Start date
D

Deleted member 11625

Guest
Schon seit Wochen sammle ich allerhand Tipps&Tricks zur Absicherung meines Root-Servers gegen DDoS-Attacken aller Art. Bisher habe ich nur einen Teil aller Tipps umgesetzt, weil viele doch zuviele Nachteile bieten. Jetzt sind nur noch ein paar iptables-Anweisungen offen, bei denen ich mich frage, ob diese Sinn machen. Hier erstmal die Anweisungen:

Code:
#1 Limit bietet Schutz vor "Syn-Flood-Attacken":
iptables -A FORWARD -p tcp --syn -m limit --limit 1/s -j ACCEPT 

#2 Schutz vor "Ping of Death":
iptables -A FORWARD -p icmp --icmp-type echo-request -m limit --limit 1/s -j ACCEPT

#3 Portscanner ausschalten:
iptables -A FORWARD -p tcp --tcp-flags ALL NONE -m limit --limit 1/h -j ACCEPT 
iptables -A FORWARD -p tcp --tcp-flags ALL ALL -m limit --limit 1/h -j ACCEPT

#4 alle TCP-Sessions müssen mit einem SYN beginnen, sonst werden sie verworfen
$iptables -A INPUT -p tcp ! –syn -m state –state NEW -j LOG –log-prefix “Stealth Scan”
$iptables -A INPUT -p tcp ! –syn -m state –state NEW -j DROP

#5 ungewöhnliche Flags verwerfen
$iptables -A INPUT -p tcp –tcp-flags ALL FIN,URG,PSH -j DROP
$iptables -A INPUT -p tcp –tcp-flags ALL ALL -j DROP
$iptables -A INPUT -p tcp –tcp-flags ALL SYN,RST,ACK,FIN,URG -j DROP
$iptables -A INPUT -p tcp –tcp-flags ALL NONE -j DROP
$iptables -A INPUT -p tcp –tcp-flags SYN,RST SYN,RST -j DROP
$iptables -A INPUT -p tcp –tcp-flags SYN,FIN SYN,FIN -j DROP

#6 SYN-Flood-Schutz
$iptables -N syn-flood
$iptables -A INPUT -p tcp –syn -j syn-flood
$iptables -A syn-flood -m limit –limit 1/s –limit-burst 4 -j RETURN
$iptables -A syn-flood -j DROP

#7 Setzt die MMS (Maximum Segment Size) auf weniger 40Bytes für SYN,RST SYN Packete
$iptables -A FORWARD -p tcp –tcp-flags SYN,RST SYN -j TCPMSS –clamp-mss-to-pmtu

Die Fragen:
1.) Gibt es davon was, was meinen "guten" Besuchern schadet (langsamer Seitenaufbau, Abbruch der Verbindung usw.)? Das ist nämlich immer der Faktor, bei dem ich abwäge, ob sich so eine Maßnahme lohnt.

2.) Bei 1, 2 und 3 steht "FORWARD". Ist das aber nicht Quatsch? Muss es nicht INPUT sein?

3.) Sind 1 und 6 nicht dasselbe? Wobei bei 6 noch "limit-burst" steht.

4.) Wie starte ich so ein Skript beim Systemstart? Ich habe mal was von /etc/rc.local gelesen. Wenn dort, was trage ich ein? Einfach den Namen meines Skript, z.B. /pfad/antiddos.sh?
 
Last edited by a moderator:
2.) Bei 1, 2 und 3 steht "FORWARD". Ist das aber nicht Quatsch? Muss es nicht INPUT sein?
Hmm ich glaub eigentlich schon.
Allerdings ist #2 kein Schutz gegen Ping of Death sondern gegen Ping Flood. Mir ist spontan kein heutzutage eingesetztes Betriebssystem bekannt welches gegen Ping of death noch nicht immun ist ;)
Beachte allerdings dass ICMP Spoofing in vielen Netzen moeglich ist sofern die Border Gateways die Pakete nicht analysieren und somit die Regel kein wirkliches Hinderniss darstellt. Zumals ein Slowloris oder andere Angriffe bedeutend effektiver bei aktueller Hardware sind ;)

Sind 1 und 6 nicht dasselbe? Wobei bei 6 noch "limit-burst" steht.
Eigentlich schon. Wobei ein Burst nicht schlecht ist.
(Dazu spaeter mehr)

Wie starte ich so ein Skript beim Systemstart? Ich habe mal was von /etc/rc.local gelesen. Wenn dort, was trage ich ein? Einfach den Namen meines Skript, z.B. /pfad/antiddos.sh?
Distro-spezifisch. Unter Debian legst du ein Start-Skript unter /etc/init.d/ ab und legst die Runlevel mit "update-rc.d <SKRIPTNAME> defaults" fest.
Alle Distributionen verstehen den Cronjob-Befehl "@reboot" (angegeben statt Uhrzeit/Datum, also @reboot /bin/meinskript.sh)

Gibt es davon was, was meinen "guten" Besuchern schadet
Ja. Und zwar die synflood-Begrenzung. SYN ist das initiale Paket des 3way-Handshakes beim Verbindungsaufbau einer TCP/IP Verbindung. Da oft/meist bei Webseiten fuer jedes einzelne Element (Bild, CSS-Datei, Javascript-Datei, ...) eine neue Verbindung aufgebaut wird, kann man bei ueblichen Templates von locker 20 Verbindungen ausgehen. Mit deiner Restriktion dauert es somit mindestens 20 Sekunden bis zum kompletten Aufbau einer 20-Elemente Webseite (uncached) wenn fuer jedes Element eine neue Verbindung aufgebaut wird. Ich sage mindestens da der Timeout des Browsers oft frueher greift und somit das Element erst beim x-ten Besuch der Seite angezeigt wird.
Da TCP-SYN genau wie ICMP und UDP spoofed werden kann, ist die Begrenzung ebenfalls einfach zu umgehen. Ich setze die Werte meist auf 30 je 2 Sekunden und lebe damit gut.

Ich empfehle ausserdem -sofern nicht bereits aktiviert- die Syncookies.
Auch wenn nicht exakt im RFC spezifiert so sind diese (soweit ich beim Lesen desselben verstanden habe) entgegen teilweise verbreiteter Meinung RFC-konform.

Ein ebenfalls interessantes Skript ist hier:
 
Last edited by a moderator:
Erstmal vielen Dank für die ausführliche Antwort.

Du bist gar nicht mehr auf den Burst eingegangen. Müsste das so aussehen?
Code:
#1 SYN-Flood begrenzen:
iptables -A INPUT -p tcp --syn -m limit --limit 30/m --limit-burst 2 -j ACCEPT

Das Einbinden des Skript ist vermutlich am einfachsten mit dem Cronjob und der Angabe @reboot. Das werde ich testen.

Ich liste nochmal eben meine anderen Maßnahmen auf. Vielleicht ist da ja noch was bei, was nicht so optimal ist:

- mod_evasive (mit angepassten Settings)
- DDoS Deflate (mit angepassten Settings)
- fail2ban (mit angepassten Settings)
- Apache: KeepAliveTimeout auf 4 (statt 15)
- Blocken aller Clients auf Webserver-Ebene, die keinen Useragent übermitteln
- Blocken diverser Anonymisierungdsienste mittels iptables
- /etc/sysctl.conf:
tcp_syncookies = 1
net.ipv4.conf.all.rp_filter = 1
net.ipv4.conf.default.rp_filter = 1
net.ipv4.ip_default_ttl = 61
net.ipv4.tcp_fin_timeout = 30
net.ipv4.tcp_syn_retries = 4
net.ipv4.tcp_synack_retries = 4

Ich verwende übrigens Debian 5.
 
Du bist gar nicht mehr auf den Burst eingegangen.
Ups :)
Burst ist die Anzahl an initialen Paketen bevor die Durchschnittsregel greift. Somit kannst du einen Anfangspuffer bilden und da idR die Clients eh die statischen Dateien cachen (duerfen) kannst du das angesprochene Problem bez. langer Ladezeit einzelner Elemente zwar nicht umgehen aber zumindest in den meisten Szenarien ausser Reichweite setzen. Ein Initial-Burst mit 30 Syn sollte die meisten Faelle locker abdecken.
Bei einer Regel von 30/min hast du das Problem dass -sollte innerhalb von 5 Sekunden dass Limit erreicht sein- die ganze IP (also auch Proxy's, NAT's, Firmennetze, ...) KEINE Verbindungen mehr schicken darf. Willst du das wirklich?
 
Eigentlich wollte ich es so haben, wie du geschrieben hast. ;)
Ich setze die Werte meist auf 30 je 2 Sekunden und lebe damit gut.
 
"Anti-DDoS" auf dem zu schützenden System ist Schwachsinn, das haben wir hier nun wirklich oft genug durchgekaut. Gegen DDoS kann nur der Netzbetreiber effektiv vorgehen, denn nur er kann auf Netzwerkebene filtern. Alles was er nicht filtert, erreicht immer den zu schützenden Host und belastet dessen Kernel. Letzteres wird durch Spielereien wie IPTables noch unnötig verstärkt und sorgt somit dafür, dass das System noch früher aussteigt als ohnehin schon.
 
Letzteres wird durch Spielereien wie IPTables noch unnötig verstärkt und sorgt somit dafür, dass das System noch früher aussteigt als ohnehin schon.
Bei Angriffen wie Synflood ist das System nicht unbedingt hochbelastet sondern einfach das festgesetzte connlimit erreicht, waehrend man zumindest Skript-Kiddy Angriffe mit entsprechenden Regeln locker filtern kann.

Gegen DDoS kann nur der Netzbetreiber effektiv vorgehen
HTTP-DDoS wie LOIC und Botnetze sind kaum ausfilterbar da sie echtem Traffic zu aehnlich sind, hoechstens ueber behaviour-detection und andere deep packet inspections welches in keiner Relation zum Nutzen des Betreibers stehen. Takedown on notice ist nach wie vor fast ueberall statt proaktiver Verteidigung die primaere Wahl.
Spoofing (ausser durch IP's im gleichen Netz) koennen die Border-gateways vieler Rechenzentren und ISP's bereits filtern da der Rechenaufwand vergleichsweise gering ist

Eigentlich wollte ich es so haben, wie du geschrieben hast.
Allerdings beinhaltet die Regel kein burst und sollte nur bei einem Angriff/hohem conntrack (automatisiert) aktiviert werden da es Webseiten spuerbar verzoegert.
Eine sinnvolle Ergaenzung waere das droppen bei zu hohen connlimit's von einer IP, allerdings ist SYN wie bereits gesagt spoof-bar und somit das ganze Absicherungskonzept bereits flawed by design.
 
Last edited by a moderator:
Synfloods begegnet man mit SYNCookies und dafür brauchts kein IPTables. Der ganze Rest ist nunmal kontraproduktiv...
 
Erstaunlicherweise konnte ich nicht gegen alle kleinen DDoS-SYNflood-Angriffe mit syncookies verteidigen, iptables hingegen hat in allen Faellen wo es zumutbar war die Server am Leben gehalten.
 
Danke soweit.

@Joe User: Und welcher Netzbetreiber macht sowas auf Anforderung? Keiner. Vielleicht wenn man tausende von Euros im Monat zahlt...
 
OVH hatte schon mehrmals einkommende kleinere Angriffe auf Machinen geblockt wo ich jetzt in Kenntniss bin, und einmal einen internen.
Ich habe keine Kenntniss darueber wie gut/schlecht deren Absicherung im Vergleich zu anderen Anbieter abschneidet, aber zumindest aus Providersicht kleinere Sachen erkennt sie =)

Dank zubuchbarer Hardware-Firewall, rechenzentrum-uebergreifendem vLAN (aka virtual Rack), stuendlich abrechenbaren Hardware-Server sowie router-basierendem Loadbalancing bis 8 Server sollte somit ein mittleres Projekt relativ einfach skalierbar und absicherbar sein.

Habe es allerdings in Ermangeln entsprechender Voraussetzungen bislang nicht getestet ;)
Mir ist leider kein anderer Anbieter bekannt der eine entsprechende Flexibilitaet zu erschwinglichen Preisen anbietet, wenn einer enen kennt bitte PN :)
 
Für weitere als auf dem Server selbst befindlichen Abwehrmaßnahmen fehlen mir die finanziellen Mittel.

Das mit der Syn-Flood-Begrenzung via iptables-Anweisung habe ich leider immer noch nicht ganz kapiert. Wie lautet denn der genaue Befehl?

iptables -A INPUT -p tcp --syn -m limit --limit ?/? --limit-burst ? -j ACCEPT

Was müsste optimalerweise bei den Fragezeichen hin? Oder diese Anweisung doch besser aus dem Ganzen rauslassen?

Edit: Mein aktuelles Skript sieht jetzt so aus:
Code:
#!/bin/sh

set -e

#1 SYN-Flood begrenzen:
/sbin/iptables -A INPUT -p tcp --syn -m limit --limit 2/s --limit-burst 30 -j ACCEPT

#2 Ping-Flood begrenzen:
/sbin/iptables -A INPUT -p icmp --icmp-type echo-request -m limit --limit 1/s -j ACCEPT

#3 Portscanner ausschalten:
/sbin/iptables -A INPUT -p tcp --tcp-flags ALL NONE -m limit --limit 1/h -j ACCEPT
/sbin/iptables -A INPUT -p tcp --tcp-flags ALL ALL -m limit --limit 1/h -j ACCEPT

#4 alle TCP-Sessions muesen mit einem SYN beginnen, sonst werden sie verworfen
/sbin/iptables -A INPUT -p tcp ! -syn -m state --state NEW -j LOG --log-prefix "Stealth Scan"
/sbin/iptables -A INPUT -p tcp ! -syn -m state --state NEW -j DROP

#5 ungewoehnliche Flags verwerfen
/sbin/iptables -A INPUT -p tcp --tcp-flags ALL FIN,URG,PSH -j DROP
/sbin/iptables -A INPUT -p tcp --tcp-flags ALL ALL -j DROP
/sbin/iptables -A INPUT -p tcp --tcp-flags ALL SYN,RST,ACK,FIN,URG -j DROP
/sbin/iptables -A INPUT -p tcp --tcp-flags ALL NONE -j DROP
/sbin/iptables -A INPUT -p tcp --tcp-flags SYN,RST SYN,RST -j DROP
/sbin/iptables -A INPUT -p tcp --tcp-flags SYN,FIN SYN,FIN -j DROP

#6 Setzt die MSS (Maximum Segment Size) auf weniger 40Bytes fuer SYN,RST SYN Pakete
/sbin/iptables -A INPUT -p tcp --tcp-flags SYN,RST SYN -j TCPMSS --clamp-mss-to-pmtu

Nun lese ich gerade, dass man eigentlich nach einer limit-Anweisung, worauf am Ende ein ACCEPT folgt, die gleiche Zeile nochmal mit DROP machen muss. Stimmt das?

Diese ganzen Anweisungen kursieren hundertfach im Internet, immer identisch und meiner Meinung nach immer falsch. Z.B. fehlten enorm viele Bindestriche und dann ist da eben noch die Sache mit FORWARD statt INPUT (beides hier korrigiert).

Beim letzten frage ich mich, ob da FORWARD vielleicht doch richtig wäre.

Fragen über Fragen...
 
Last edited by a moderator:
Back
Top