Archiv verlassen und diese Seite im Standarddesign anzeigen : DDOS Attacken - iptables Eintrag automatisch?
el_fandios
14.02.11, 15:35
Hallo liebe Linux Freunde,
habe derzeit einige Probleme mit kleineren DDOS Angriffen von vielen verschiedenen IP-Adressen aus.
Die Angriffe laufen über den apache, wie ich sehe.
Habe fail2ban und einen apache2 security mod drauf, schafft aber nicht wirklich Abhilfe.
Habt ihr evtl. ein Skript, welches alle IP-Adressen ab 30 Verbindungen in die iptables einträgt?
Hier mal die aktuellen Verbindungen und IP-Adresse (IP-Adressen zensiert):
11 188.23.xxx
14 77.23.xxxxx
15 95.223.xxxxx
41 85.8.xxxxx
56 91.19.xxxxx
Wenn ich diese IP-Adresse nun mit
iptables -A INPUT -s <IP-ADRESSE> -j DROP
in die iptables eintrage, habe ich 1min später wieder 50 - 200 Verbindungen einer anderen Adresse.
Eine Schleife, die das automatisch macht, wäre super.
Hat jemand eine Idee?
OS: Linux Debian Lenny 5.0
Ist nur ein kleiner vServer.
Hi,
nutze die doch die Idee die "Androw Pollok" mal verbeitet hat für deine Zwecke:
iptables -A INPUT -p tcp --dport 22 -m state --state NEW -m recent --set --name SSH -j ACCEPT
iptables -A INPUT -p tcp --dport 22 -m recent --update --seconds 60 --hitcount 4 --rttl --name SSH -j LOG --log-prefix "SSH_brute_force "
iptables -A INPUT -p tcp --dport 22 -m recent --update --seconds 60 --hitcount 4 --rttl --name SSH -j DROP
Gut du willst nicht ssh, sondern http, aber das Grundsätzliche ist ja identisch, wenn mehr als x neue Verbiungen von einem Client y im Zeitraum t kommen, dann wird y für einen Zeitrum t2 gesperrt.
el_fandios
14.02.11, 15:44
Hi,
nutze die doch die Idee die "Androw Pollok" mal verbeitet hat für deine Zwecke:
iptables -A INPUT -p tcp --dport 22 -m state --state NEW -m recent --set --name SSH -j ACCEPT
iptables -A INPUT -p tcp --dport 22 -m recent --update --seconds 60 --hitcount 4 --rttl --name SSH -j LOG --log-prefix "SSH_brute_force "
iptables -A INPUT -p tcp --dport 22 -m recent --update --seconds 60 --hitcount 4 --rttl --name SSH -j DROP
Gut du willst nicht ssh, sondern http, aber das Grundsätzliche ist ja identisch, wenn mehr als x neue Verbiungen von einem Client y im Zeitraum t kommen, dann wird y für einen Zeitrum t2 gesperrt.
Vielen Dank.
Sprich 22 mit 8080 ersetzen?
Ist eine gute Idee für SSH aber nicht für Apache. Denn jede Datei (HTML, CSS, JPEG, JS, .....) ist eine Verbindung. Da kommen schnell mal einige hundert Verbindungen pro Minute zusammen. Wo willst Du die Grenze setzen um nicht den normalen Surfer auszusperren?
Die Fage wäre welche Dateien abgerufen werden. Vielleicht schafft mod_evasive Abhilfe.
in dem man x groß und t klein macht:
Beispielsweise mehr als 100 neue Anfragen innerhalb von 10 Sekunden...
Abgesehen davon, genau der bzw. die Ports tauschen, die Liste kann natürlich auch anders als ssh heißen, selbiges gilt für den Log-Prefix.
el_fandios
14.02.11, 16:05
Ist eine gute Idee für SSH aber nicht für Apache. Denn jede Datei (HTML, CSS, JPEG, JS, .....) ist eine Verbindung. Da kommen schnell mal einige hundert Verbindungen pro Minute zusammen. Wo willst Du die Grenze setzen um nicht den normalen Surfer auszusperren?
Die Fage wäre welche Dateien abgerufen werden. Vielleicht schafft mod_evasive Abhilfe.
ich will alle ab 40 Verbindungen ausschließen.
Dass einige hunderte Verbindungen zu stande kommen, kann ich nicht bestätigen.
Meine Seite hat einige tausend Besucher am Tag. Pro IP Adresse maximal 7 Verbindungen. Wenn DDOS Attacken reingehen, dann eben teilweise 200 Verbindungen pro IP.
grashuepfer
10.03.11, 09:07
Hi, lieber spät als nie.
Genau mit einem ähnlichen Problem musste ich mich aktuell auseinandersetzen. Dazu habe ich einen kleinen Artikel über DDoS (http://foobar.lamp-solutions.de/howtos/sicherheit/einzelansicht-sicherheit/article/reaktion-auf-ddos-angriffe.html) geschrieben.
Das zweite Beispiel sollte deinem Problem ganz nahe kommen.
derRichard
10.03.11, 09:57
hi!
das hat doch alles mit ddos überhaupt nichts zu tun.
ihr blockt alle nur pakete, die eh schon empfangen wurden.
bei einer richtigen ddos-attacke wird der host mit massenhaft paketen aller art überschüttet, dagegen sind lokale maßnahmen wirkungslos.
euer problem löst ihr am besten mit connlimit von iptables.
hth,
//richard
grashuepfer
10.03.11, 10:08
Hi,
natürlich hat es was mit DDoS zu tun. Unser Lösungsansatz hat ja erfolgreich bei dem Problem funktioniert.
Iptables connlimit haben wir schon ausprobiert, hat aber nicht den gewünschten Erfolg gebracht.
Mit Connlimit kann man den Server zwar vor Überlastung schützen, die Leitung wird dennoch dicht gemacht.
derRichard
10.03.11, 12:21
das glaube ich nicht.
btw. bei deinem skript kann man fremde ips aussperren.
du prüfst SYN_RECV d.h. ich kann ein tcp paket mit falschen absender senden, welchen du dann sperrst...
hth,
//richard
grashuepfer
10.03.11, 13:41
das glaube ich nicht.
btw. bei deinem skript kann man fremde ips aussperren.
du prüfst SYN_RECV d.h. ich kann ein tcp paket mit falschen absender senden, welchen du dann sperrst...
hth,
//richard
Wie ich schon im Artikel geschrieben habe ist es klar eine Frage der Ressourcen die beiden Seiten zur Verfügung stehen. Wenn der Angreifer die Leitung mit dementsprechend vielen Anfragen dicht machen kann, ist der Ansatz nicht mehr ausreichend und man muss eine andere Lösung finden.
Für den aktuell abgewehrten Angriff hat die Lösung perfekt funktioniert.
Sicher kann eine IP-Adresse gespooft werden, was man immer machen kann, auch gegen connlimit von iptables.
Ich bin dankbar für jeden Tipp der unsere Lösung verbessert. Wie genau hast Du connlimit eingesetzt um ähnliche Angriffe abzuwehren?
derRichard
10.03.11, 13:48
Sicher kann eine IP-Adresse gespooft werden, was man immer machen kann, auch gegen connlimit von iptables.
naja, da kann man aber keine fremden ips aussperren...
und man kann auch connlimit mit state mischen um nur aufgebaute verbindungen zu treffen, etc...
Wie genau hast Du connlimit eingesetzt um ähnliche Angriffe abzuwehren?
ich erlaube je nach dienst nur eine begrenzte zahl gleichzeitiger verbindungen pro ip.
aber mein firewall-setup ist komplett anders als deines. ich filtere auch nicht am host selbst, sondern am bordergateway und den zwischen firewalls...
//richard
grashuepfer
10.03.11, 14:03
naja, da kann man aber keine fremden ips aussperren...
und man kann auch connlimit mit state mischen um nur aufgebaute verbindungen zu treffen, etc...
Der einzige Unterschied ist aber, dass die IPs in meinem Fall dauerhaft auf eine Blackliste gesetzt werden.
ich erlaube je nach dienst nur eine begrenzte zahl gleichzeitiger verbindungen pro ip.
aber mein firewall-setup ist komplett anders als deines. ich filtere auch nicht am host selbst, sondern am bordergateway und den zwischen firewalls...
//richard
Ja aber du verlagerst das Problem weiter vor. Auch die davor geschaltete Firewall benutzt den selben Uplink. Wenn jemand die Leitung zuballert ist zwar auf dem Server ruhe, reguläre Anfragen kommen trotzdem verlangsamt oder im schlimmsten Fall gar nicht mehr durch.
derRichard
10.03.11, 14:13
Der einzige Unterschied ist aber, dass die IPs in meinem Fall dauerhaft auf eine Blackliste gesetzt werden.
mit deinem skript kann ich mit ip a, jemanden mit ip b aussperren...
Ja aber du verlagerst das Problem weiter vor. Auch die davor geschaltete Firewall benutzt den selben Uplink. Wenn jemand die Leitung zuballert ist zwar auf dem Server ruhe, reguläre Anfragen kommen trotzdem verlangsamt oder im schlimmsten Fall gar nicht mehr durch.
wenn jemand die leitung zuballert, dann hilft überhaupt gar nichts...
//richard
grashuepfer
10.03.11, 14:29
mit deinem skript kann ich mit ip a, jemanden mit ip b aussperren...
Wie schon gesagt, es ist mir klar, dass IPs gespooft werden können. Das Problem ist aber, dass das für connlimit genauso gilt.
Aber bitte korrigiere mich, wenn ich falsch liege.
wenn jemand die leitung zuballert, dann hilft überhaupt gar nichts...
//richard
Eben, ich habe nichts anderes gesagt. Es ist bloß eine Frage der eingesetzten und gegebenen Ressourcen.
Aber für die Anfragen bleibt das Nadelöhr eben die Internetleitung. Ob die Anfrageflut an der Firewall ankommt, oder am Server, die Serverdienste sind für reguläre Anfragen nicht schneller oder langsamer zu erreichen.
derRichard
10.03.11, 14:30
Wie schon gesagt, es ist mir klar, dass IPs gespooft werden können. Das Problem ist aber, dass das für connlimit genauso gilt.
Aber bitte korrigiere mich, wenn ich falsch liege.
nein, man kann es wie gesagt mit dem state der verbindung verknüpfen...
//richard
grashuepfer
10.03.11, 16:15
nein, man kann es wie gesagt mit dem state der verbindung verknüpfen...
//richard
Du schreibst, dass du die Anzahl der Verbindungen pro IP begrenzt. Wie erkennst Du aber, dass die entsprechende IP nicht gespooft ist?
Im Grunde ist meine Lösung gleich. Nach dem Überschreiten einer vordefinierten Anzahl an Verbindungen wird die IP geblockt.
Verstehe es bitte nicht falsch, mich interessiert wirklich wie dein Lösungsansatz funktioniert und möchte auch diese Methode begreifen.
derRichard
10.03.11, 17:42
Verstehe es bitte nicht falsch, mich interessiert wirklich wie dein Lösungsansatz funktioniert und möchte auch diese Methode begreifen.
du kannst mich fragen was immer du willst. :)
bei iptables kann man ja auch den status der verbindung abfragen.
zb:
iptables -A INPUT -p tcp -m state --state ESTABLISHED --dport 22 -m connlimit ! --connlimit-above 2 -j ACCEPT
so erlaubt man maximal 2 _aufgebaute_ verbindungen.
aufgebaut ist sie erst nach dem tcp-handshare wodurch spoofing nicht mehr möglich ist.
hth,
//richard
Hi,
Frage zu den connlimit, wie ist es mit "genatten" Zugriffen? Liege ich falsch, oder würde IPT die als ein und den selben Client betrachten?
Anmerkung zu der Skript-Lösung:
Was mir spontan nicht gefällt, ist dass ihr die Adressen nie wieder freigebt, ist da wirklich gewollt? Gerade das finde ich bei der hitcount Lösung so genial, für den Zeitraum der Attacke bleibt es gesperrt, danach wird es aber auch ganz von alleine wieder freigegeben. Habt ihr da keinen Vorbehalte, dass so u.U. die falschen ausgesperrt werden? Ich hätte sie jedenfalls.
derRichard
10.03.11, 19:23
Liege ich falsch, oder würde IPT die als ein und den selben Client betrachten?
ja klar.
//richard
okay, das ist schade, da bei uns viele Firmen genau über sowas zugreifen, wenn das dann mehr als 2 (in einer Firma und im geposteten Beispiel) gleichzeitig tun, ist Schluss, oder verstehe ich was falsch?
derRichard
10.03.11, 19:34
ja. 2 ist aber nur das beispiel aus der manpage.
es gehen auch andere werte. :)
und es kommt auch immer auf den dienst an...
//richard
jo das ist wahr, letzte Frage, auch diese Lösung ist dynamisch, erlaubt nach dem "Angriff" also wieder Verbindungen?
derRichard
10.03.11, 19:51
schau dir mal genau an wie das teil funktioniert.
es steht in der manpage. :)
//richard
und wieder was gelernt und einen goodie zum testen gefunden :)
Folgendes Shell-Skript ist super zum prüfen der Regel geeignet
for i in {1..$1}
do
# do nothing just connect and exit
echo "exit" | nc $2 $3;
done
grashuepfer
11.03.11, 08:44
Anmerkung zu der Skript-Lösung:
Was mir spontan nicht gefällt, ist dass ihr die Adressen nie wieder freigebt, ist da wirklich gewollt? Gerade das finde ich bei der hitcount Lösung so genial, für den Zeitraum der Attacke bleibt es gesperrt, danach wird es aber auch ganz von alleine wieder freigegeben. Habt ihr da keinen Vorbehalte, dass so u.U. die falschen ausgesperrt werden? Ich hätte sie jedenfalls.
Wie gesagt ist es ein komplett anderer Ansatz den wir gewählt haben. Die IPs können auch jederzeit von der Blackliste entfernt werden. Man kann natürlich auch das Skript dahingehend erweitern, dass ein Timestamp definiert wird nach dem die IPs wieder freigegeben werden.
Mit Connlimit haben wir zum Zeitpunkt der Angriffe auch experimentiert. Das Problem war, dass bei einem niedrigen Schwellwert die Webseiten träge ausgeliefert wurden, bei einem etwas höher gesetzten Limit an Verbindungen haben aber die Angriffe wieder zugenommen.
Das ist auch der Grund für die Blacklistbasierte Methode, das hat effektiv funktioniert.
Powered by vBulletin® Version 4.2.5 Copyright ©2024 Adduco Digital e.K. und vBulletin Solutions, Inc. Alle Rechte vorbehalten.