Definition DoS/DDoS
DoS steht für Denial of Service und bedeutet übersetzt soviel wie Dienstverweigerung.
In beiden Fällen wird versucht, einen Dienst (meistens eine Internetseite) durch massenhafte Anfragen zu überlasten.
Dadurch ist der jeweilige Dienst entweder nur noch eingeschränkt (geringere Geschwindigkeit oder vereinzelte Ausfälle) oder im extremfall gar nicht mehr erreichbar.
Ein solcher Angriff kann von einer einzelnen Quelle (DoS) oder von mehreren (DDoS) kommen.
DoS lässt sich einfach blockieren und mit entsprechenden Regeln bereits im Vorraus verhindern bzw abschwächen.
Bei DDoS-Angriffen werden meist Botnetze, also eine größere Anzahl von PCs die mit einem Schadprogramm infiziert wurden, eingesetzt.
Solche Angriffe können nur schwer bis gar nicht blockiert werden, hier entsteht der Effekt durch die Masse der Clients, die jeweils relativ wenige Anfragen senden.
Vorbeugende Schutzmaßnahmen
Einen Server vor DoS zu schützen ist noch relativ einfach, da wir hier einen einzelnen Client haben, der unverhältnismäßig viele Verbindungen/Anfragen sendet.
Man kann DoS also relativ leicht vorbeugen, in dem man jeweils vernünftige Limits setzt. Alle Clients, die über diese Limits hinausschießen, werden blockiert.
Connectionlimits:
Eine Möglichkeit dafür wäre DoS-Deflate, ein kleines Script, das jede Minute als Cron durchläuft und Clients mit mehr Verbindungen wie in der Config festgelegt blockiert.
Es bietet sich außerdem an, über iptables Regeln festzulegen. So kann man zb Limits festlegen oder unseriöse Adressbereiche direkt aussperren.
Man kann mit der Doc zu iptables selbst sinnvolle Limits setzen. Im folgenden gibt es ein paar fertige Regeln die sinnvoll sind.
Limit für Syn-Flood attacken:
Code:iptables -A FORWARD -p tcp --syn -m limit --limit 1/s -j ACCEPT
Ganze IP-Ranges sperren:
Code:iptables -A INPUT -s 192.168.2.0/24 –j DROP
Damit werden zb alle IPs die mit 192.168.2 anfangen gesperrt (also 192.168.2.0 – 192.168.2.254).
/24 steht als 'Wildcard' für den letzten Block, /16 für den 2. Block und /8 für den 3. letzten (jeweils von rechts).
Ungültige Tcp-Packete loggen und verwerfen:
Code:iptables -A INPUT -p tcp ! --syn -m state --state NEW -j LOG --log-prefix "Stealth Scan"
Für HTTP-Verbindungen kann man auf Port 80 auch ein sinnvolles Limit setzen. Welcher Wert hier Sinn macht und ob das ganze überhaupt sinnvoll ist, hängt von der Config des Webservers ab.
Daher sollte man hier nicht einfach irgendwas setzen ohne vorher die Connections seiner User zu analysieren, sonst kickt man schnell unschuldige User.
Code:iptables -A INPUT -p tcp --dport 80 -m iplimit --iplimit-above 10 -j DROP
Hier werden bei mehr wie 10 Connections die Pakete verworfen.
Ein halbwegs moderner Browser öffnet normalerweise nicht mehr wie 5 gleichzeitige Verbindungen.
Als Alternative dazu bietet es sich in vielen Webservern an, dort ein Connectionlimit festzulegen.
Apache hat z.b. ein Modul mod_evasive, mit dem man das ganze noch genauer festlegen kann (z.B. Mehr wie X seiten in Y Sekunden => Block).
Außerdem kann man Keep-Alive in der Config deaktivieren bzw auf einen niedrigen Wert (1 oder 2) setzen, um den Webserver von offenen Anfragen der Bots zu entlasten.
Sonst wartet er entsprechend dem angegebenen Timeout auf Daten, wofür er natürlich Ressourcen reservieren muss.
Eigene Erweiterungen:
Man kann und soll das ganze natürlich so anpassen, wie es auf dem eigenen System Sinn macht.
Wenn man als Anfänger mit iptables rumexperimentiert sollte man vorher ein Backup der aktuellen Regeln machen
Code:iptables-save > /tmp/iptables-backup
und dies nach einem festgelegten Interval (z.B. 10 Minuten) automatisch wieder einspielen lassen
Code:at now + 5min
iptables-restore < /tmp/iptables-backup
{STRG} + {D}
So wird verhindert, dass man sich beim experimentieren versehentlich selbst aussperrt.
Grundsätzlich sollte man aber aus Performancegründen mit Firewallregeln so sparsam wie möglich umgehen.
Syn-Cookies:
Man sollte unter Linux unbedingt Syn-Cookies gegen Syn-Attacken aktivieren. Da diese nicht auf allen Distributionen standardmäßig aktiv sind, sollte man dies durch
Code:cat /proc/sys/net/ipv4/tcp_syncookies
pr</acronym>üfen.
Wenn man als Ausgabe nicht 1 erhält sind Syn-Cookies deaktiviert.
Man kann sie durch
Code:echo 1 > /proc/sys/net/ipv4/tcp_syncookies
aktivieren.
Sonstiges:
Ein richtig konfigurierter Server ist neben den o.g. Schutzmaßnahmen natürlich ebenfalls wichtig.
Man sollte daher alle Dienste (Webserver/PHP/Perl/Datenbank etc) der Nutzung entsprechend anpassen.
Standard Configs zu nutzen ist meistens keine gute Idee.
Die Standard Config von Apache ist zb nicht sehr optimal. Daher ist ein Server mit einer typische apt-get Installation ohne Anpassen der Configs bei einem Angriff deutlich schneller down wie ein gleichwertiger Server der optimiert wurde.
Abwehrmaßnahmen
Derzeitige Connections einsehen
Wenn man sehen will wieviele Verbindungen alle derzeit verbundenen Clients aufgebaut haben, kann man dafür netstat benutzen.
Folgendes Snippet liefert eine absteigend sortierte Liste aller derzeit verbundenen Clients:
Code:netstat -ntu | awk '{print $5}' | cut -d: -f1 | sort | uniq -c | sort -n
Ausgegeben wird dann zuerst die Anzahl der Connections und anschließend die dazugehörige IP.
Einzelne IP sperren
Code:iptables -I INPUT -j DROP -s CLIENTIP
HTTP-Flood
Wenn es darum geht eine Internetseite (also den Webserver) down zu bekommen wird auch gerne HTTP-Flood eingesetzt.
Hierbei richtet sich die Attacke gezielt gegen den Webserver, der die Seiten ausliefert.
Ist er überlastet, werden keine Seiten mehr ausgeliefert => Seite down.
Diese Technik wird gerne von Kiddys benutzt, da man mit einfachen und kostenlosen Tools wie Hitfaker schon etwas erreichen kann, besonders auf leistungsschwachen und/oder schlecht konfigurierten Servern.
Wenn der Webserver trotz Schutzmaßnahmen bei einem starken Flood überlastet, kann man folgendes tun:
- In der Accesslog die letzten Requests genau analysieren und versuchen etwas zu finden das sie von normalen Requests unterscheidet (z.B. Kein User-Agent, veraltetes HTTP 1.0 Protokoll etc) dann kann man sich ein kleines Script basteln, dass diese Requests filtert und die IPs blockiert
- Wenn man feststellen sollte dass zb alle Bots keinen oder den selben User-Agent senden, kann man diesen auch direkt in der Config des WebServers ausschließen!
- Als Notlösung kann man einen Auth-Schutz aktivieren. Bei Apache geht das zb über die .htaccess, andere Web-Server haben äquivalente Funktionen in der Config.
Bei Apache könnte man einen Auth-Schutz zb so realisieren:
Code:AuthType Basic
AuthName "User = ddos - Passwort = ddos"
AuthUserFile /var/www/bla.de/.htpasswd
require valid-user
ErrorDocument 401 "<center><h3>Wichtig</h3><br>Wir stehen zurzeit unter DDoS.<br>Um unsere Seite nutzen zu können, geben Sie bitte den Benutzername <b>ddos</b> und das Passwort <b>ddos</b> ein.</center>"
In der Datei /var/www/bla.de/.htpasswd müssen User und Passwort im Format
Code:User:crypt(pw)
eingetragen werden.
crypt() kann man zb mit Python nutzen:
Code:daniel@laptop:/# python -c "import crypt;print crypt.crypt('ddos', 'xyz')"
xyMywajww97mg
ddos ist hierbei das Passwort und xyz der verwendete Salt.
Es gibt aber auch Online-Dienste, denen man Benutzername + Passwort übergibt und die dann den kompletten Eintrag für die .htpasswd generieren wie Htpasswd Generator - Create a htpasswd password
Würde ich aber nur im Notfall benutzen und auch dann nur so lange wie nötig, da
- es die User nervt
- alle Crawler von Suchmaschinen ebenfalls ausgesperrt werden während der Auth-Schutz aktiv ist
Wenn man zudem Signaturen oder ähnliches einbindet das User auf anderen Seiten/Foren einbinden landet man bei den jeweiligen Seiten auch gerne mal auf der Blackliste, da sich der Auth-Dialog dann überall öffnet wo zb eine Signatur verlinkt wurde.
Grundsätzliches zu DDos-Protections
Alles was ich oben aufgelistet habe kann natürlich nur begrenzt gegen (D)DoS schützen!
Wenn jemand ein 100k Botnet auf euren Server ansetzt dann helfen weder iptables-Regeln noch sonstige Connection-Limits etwas, weil entweder der Server hardwaremäßig komplett überlastet oder die Leitung dicht ist.
Gerade die Anbindung spielt hier eine wichtige Rolle.
Ich kann den schnellsten Server der Welt mit Spitzenhardware haben, wenn der nur mit 100Mbps angebunden ist und ich mit 1Gbps angegriffen werde nützt es nichts wenn die Hardware mit der Trafficmenge 10x klarkommen würde, weil schlicht und einfach die Leitung dicht ist => Nichts kommt rein oder raus.
DDoS-Protections von Hostern
Da ich öfter mal gefragt werde was ich von einem Hoster halte der für 10€ einen All-In-One DDoS-Schutz anbietet oder ob ich einen Hoster kenne der für 40€ einen dedi mit DDoS-Protection anbietet: Vergesst es.
Ab einer gewissen Stärke kann DDoS nur noch von einer Hardware-Firewall gefiltert werden, und die kosten richtig Geld. Damit meine ich nicht 80€ statt 40€, sondern 500€ aufwärts.
Eine hardwareseitige DDoS-Protection kann sich kein Mensch für irgendein kleines privates Projekt leisten, das ist nur was für größere Firmen.
Wenn ihr doch einen Hoster finden solltet, der für 10 oder 20€ die angeblich ultimative DDoS-Protection verkaufen will, dann zahlt ihr entweder für eine imaginäre HW-Firewall oder euer Hoster setzt grob den Inhalt dieses Threads um und lässt sich das gut bezahlen.
Ich habe dieses Tutorial nicht geschrieben. Ich habe es auf meinem Pc gefunden, und dachte vielleicht könnt ihr was damit anfangen.
