DDOS auf Apache


Sanchooo187

New Member
Hallo Leute,

bin seit Wochen am verzweifeln. Wir haben einen Rootserver auf dem ISPconfig läuft. Der hat insgesamt einen "Kunden", wir selbst. Darauf läuft ein Webserver (Apache+PHP), MySQL und FTP. Auf dem wird nur ein Forum betrieben.

Angefangen hat das ganze vor Wochen mit einer DDOS-Attacke auf den gesamten Server. Der hat natürlich alles lahmgelegt. Um diesem entgegenzuwirken haben wir bei unserem Provider eine Hardwarefirewall gegen DDOS-Protection bestellt. Das ganze kostet monatlich soviel wie der Server selbst. Der Schutz sieht wir folgt aus:
Max Clean Traffic : 100Mbps
Max Attack Traffic : 250Mbps

Damit hat der Angriff endlich aufgehört und der Server lief ohne Murren weiter.

Danach kam ein DOS-Angriff (ich vermute slowloris) auf den Apache von einer IP. Die IP konnte ich einfach über Iptables blockieren.

Seit ca. 2-3 Wochen wird der Apache über DDOS attackiert. Der Provider sagt folgendes:
"I am very sorry for the issue your are facing, however the antiddos
will not prevent http flood attacks. The anti ddos will concider http
traffic as ligitim packets and let it trough to your server."

Apache läuft mit mod_evasive, mod_slowloris und mod_security (wobei mod_security nicht richtig konfiguriert ist). Zusätzlich dazu hat der Provider csf als Software-Firewall installiert.

Der Server ist total instabil. Mal läuft es und man kann auf das Forum ganz normal zugreifen, mal ist der Server komplett weg. Der Angriff findet aber weiterhin statt.
Derzeit hat der Server 74 php-cgi-Prozesse am laufen und 259 apache-Prozesse. Wenn ein php-cgi Flood kommt geht auch der Serverload sehr hoch.

netstat auf port 80 ergibt folgendes:
Code:
netstat -ant|grep :80 |awk '{print $5}'|sed 's/:.*$//' |wc -l
2382
Hier hatte ich auch schon mehr als das zehnfache.

und unique ip's
netstat -ant|grep :80 |awk '{print $5}'|sed 's/:.*$//' |sort -u |wc -l
376

Ich bin wirklich am Ende und weiss nicht wo ich noch dran drehen soll/kann oder was ich generell machen kann, um dem Angriff zu entgehen.

Falls noch log-Dateien oder so gewünscht werden kann ich ein Teil davon posten.

Vielen Dank schon mal vorab.
 
Vielleicht mal anti-hack.net derren anti-ddos script benutzen vllt hilft es ja..
und dabei nocht ein /etc/init.d/csf stop machen nach dem installierten anti-ddos script
 
Schau mal in meinem Blog (hier auf SSF) unter "DDOS Methoden".
Ich tippe auf Slowloris, geeignete Gegenmassnahmen sind dort beschrieben.
 
Vielleicht noch ne Info zur Serverausstattung:

CPU: Intel(R) Core(TM)2 Quad CPU Q6700 @ 2.66GHz
RAM: 8GB
Anbindung: 100Mbps port

Auszug aus access.log (ich weiss nicht ob ich ip's posten darf, deshalb hab ich mal ein teil unkenntlich gemacht)
Code:
85.106.x.x - - [11/May/2011:15:16:49 +0200] "GET /forum.php HTTP/1.1" 400 524 "-" "Mozilla/4.0 (compatible; MSIE 6.0; Windows NT 6.1)"
78.181.x.x - - [11/May/2011:15:16:50 +0200] "GET /forum.php HTTP/1.1" 400 524 "-" "Mozilla/4.0 (compatible; MSIE 6.0; Windows NT 6.1)"
85.106.x.x - - [11/May/2011:15:16:52 +0200] "GET /forum.php HTTP/1.1" 400 524 "-" "Mozilla/4.0 (compatible; MSIE 6.0; Windows NT 6.1)"
85.106.x.x - - [11/May/2011:15:16:52 +0200] "GET /forum.php HTTP/1.1" 400 524 "-" "Mozilla/4.0 (compatible; MSIE 6.0; Windows NT 6.1)"
78.190.x.x - - [11/May/2011:15:16:52 +0200] "GET /forum.php HTTP/1.1" 400 524 "-" "Mozilla/4.0 (compatible; MSIE 6.0; Windows NT 6.1)"
85.106.x.x - - [11/May/2011:15:16:52 +0200] "GET /forum.php HTTP/1.1" 400 524 "-" "Mozilla/4.0 (compatible; MSIE 6.0; Windows NT 6.1)"
78.181.x.x - - [11/May/2011:15:16:53 +0200] "GET /forum.php HTTP/1.1" 400 524 "-" "Mozilla/4.0 (compatible; MSIE 6.0; Windows NT 6.1)"
78.190.x.x - - [11/May/2011:15:16:53 +0200] "GET /forum.php HTTP/1.1" 400 524 "-" "Mozilla/4.0 (compatible; MSIE 6.0; Windows NT 6.1)"
85.106.x.x - - [11/May/2011:15:16:53 +0200] "GET /forum.php HTTP/1.1" 400 524 "-" "Mozilla/4.0 (compatible; MSIE 6.0; Windows NT 6.1)"
78.181.x.x - - [11/May/2011:15:16:53 +0200] "GET /forum.php HTTP/1.1" 400 524 "-" "Mozilla/4.0 (compatible; MSIE 6.0; Windows NT 6.1)"

und hier ein Auszug aus error.log
Code:
[Wed May 11 15:18:31 2011] [error] [client 188.119.x.x] script '/var/www/index.php' not found or unable to stat
[Wed May 11 15:18:31 2011] [error] [client 188.119.x.x] script '/var/www/index.php' not found or unable to stat
[Wed May 11 15:18:31 2011] [error] [client 88.226.x.x] request failed: error reading the headers
[Wed May 11 15:18:31 2011] [error] [client 88.226.x.x] request failed: error reading the headers
[Wed May 11 15:18:31 2011] [error] [client 88.226.x.x] request failed: error reading the headers
[Wed May 11 15:18:31 2011] [error] [client 88.226.x.x] request failed: error reading the headers
[Wed May 11 15:18:35 2011] [error] [client 88.226.x.x] request failed: error reading the headers
[Wed May 11 15:18:40 2011] [error] [client 88.226.x.x] request failed: error reading the headers
[Wed May 11 15:18:40 2011] [error] [client 88.226.x.x] request failed: error reading the headers
[Wed May 11 15:18:40 2011] [error] [client 88.226.x.x] request failed: error reading the headers
[Wed May 11 15:18:43 2011] [error] [client 178.150.x.x] request failed: error reading the headers
[Wed May 11 15:18:43 2011] [error] [client 178.150.x.x] request failed: error reading the headers
[Wed May 11 15:18:43 2011] [error] [client 178.150.x.x] request failed: error reading the headers

hier noch ein Auszug aus einer Datei, welche IP bisher wieviele access Zugriffe hatte (es sind insgesamt über 20000 IP's gelistet. bin über alle access.logs gegangen):
Code:
 603833 88.234.x.x
 612462 82.244.x.x
 740617 58.106.x.x
 756690 95.168.x.x
 867893 193.140.x.x
 891958 212.253.x.x
 975832 212.156.x.x
 
Ich würde mal mit tcpdump die fehlerhaften HTTP-Header ansehen. Dann könntest du mit geeigneten Tools (z.B. mod_security) die Anfragen auf die entsprechenden Header filtern, bevor sie den Web-Server erreichen.

Oder gleich nen Proxy davor, der das Filtern übernimmt und dir gleich noch etwas Luft in der Auslieferung von Content gibt.
 
Ich würde mal mit tcpdump die fehlerhaften HTTP-Header ansehen.
Das ist defintiv ein Slowloris, somit hilft nur Antiloris oder ein alternativer Webserver respektiv Reverse-Proxy.
DIe Header sind nicht vollstaendig weil slowloris sie eben nie ganz sendet bis der Webserver die Verarbeitung nach meist zig Minuten abbricht.
Ich verweise an dieser Stelle abermal an mein Blog welches die geeigneten Gegenmassnahmen erlautert.
 
@d4f: Habe mir deinen Blog angeschaut. Heisst das, wenn ich Apache auf Version 2.4 upgrade, sollte slowloris nicht mehr durchkommen?

@PapaBaer: Gibts irgendwo ne gute Anleitung, um ein Reverse Proxy davorzuschalten (z.B. nginx)?
 
Heisst das, wenn ich Apache auf Version 2.4 upgrade, sollte slowloris nicht mehr durchkommen?
Ich habe meine etwas unglueckliche da nicht vollstaendige Formulierung korrigiert. Ab Apache 2.4 (welcher noch nicht fertiggestellt ist und dessen Entwickler-Version als Apache 2.3 erhaeltlich ist) ist mpm_event als 'stable' markiert welcher nicht Slowloris-anfaellig ist.
Alternative mpm's wie mpm_peruser oder die ueblichen mpm_prefork sowie mpm_worker sind weiterhin anfaellig, koennen aber durch mod_reqtimeout gezaehmt werden.
Fuer die aktuelle Apache-Versionen empfiehlt sich mod_antiloris welcher eben diese Arbeit abnimmt.

Gibts irgendwo ne gute Anleitung, um ein Reverse Proxy davorzuschalten (z.B. nginx)?
http://www.debian-administration.org/article/649/Speeding_up_dynamic_websites_via_an_nginx_proxy
Im Tutorial wird auch auf das zur IP-Korrektur im Apache einzusetzende mod_rpaf eingegangen wodurch es eine "out-of-the-box" Loesung bieten sollte.
 
Heisst das, wenn ich Apache auf Version 2.4 upgrade, sollte slowloris nicht mehr durchkommen?
Ich habe meine etwas unglueckliche da nicht vollstaendige Formulierung korrigiert. Ab Apache 2.4 (welcher noch nicht fertiggestellt ist und dessen Entwickler-Version als Apache 2.3 erhaeltlich ist) ist mpm_event als 'stable' markiert welcher nicht Slowloris-anfaellig ist.

Gibts irgendwo ne gute Anleitung, um ein Reverse Proxy davorzuschalten (z.B. nginx)?
http://www.debian-administration.org/article/649/Speeding_up_dynamic_websites_via_an_nginx_proxy
Im Tutorial wird auch auf das zur IP-Korrektur im Apache einzusetzende mod_rpaf eingegangen wodurch es eine "out-of-the-box" Loesung bieten sollte.

Uebrigens sind in vielen Faellen imho Hardware-Firewalls sinnfrei: der Root kann durch ausreichende Leistung (fast) alles unterhalb seiner Netzanbindung selber bearbeiten sofern richtig konfiguriert und wenn dein Angreifer wirklich "Bandwith eating" durchfuehrt kostet es ihn nicht so viel mehr statt mit 200Mbs nun mit 500Mbs drauf zu ballern so dass auch diese ueberlastet ist.
Nur das Rechenzentrum selbst oder dessen Carrier kann solche Angriffe effektiv stoppen.
 
Habe es zum laufen bekommen. nginx port läuft auf 80 und apache2 läuft auf 81. Allerdings kommt jetzt:
Code:
504 Gateway Time-out

Im error.log (nginx) steht folgendes:
Code:
2011/05/12 12:32:11 [alert] 4075#0: accept() failed (24: Too many open files)
2011/05/12 12:32:11 [alert] 4075#0: accept() failed (24: Too many open files)
2011/05/12 12:32:11 [alert] 4075#0: accept() failed (24: Too many open files)
2011/05/12 12:32:11 [alert] 4075#0: accept() failed (24: Too many open files)
2011/05/12 12:32:11 [alert] 4075#0: accept() failed (24: Too many open files)
2011/05/12 12:32:11 [alert] 4075#0: accept() failed (24: Too many open files)
2011/05/12 12:32:11 [alert] 4075#0: accept() failed (24: Too many open files)
2011/05/12 12:32:11 [alert] 4075#0: accept() failed (24: Too many open files)
2011/05/12 12:32:11 [alert] 4075#0: *17878 socket() failed (24: Too many open files) while connecting to upstream, client: 78.163.x.x, server: myserver.com, reqst: "GET / HTTP/1.1", upstream: "http://127.0.0.1:81/", host: "myserver.com", referrer: "http://www.google.com.tr/search?client=opera&rls=tr&q=myserver.com&sourid=opera&ie=utf-8&oe=utf-8&channel=suggest"
2011/05/12 12:32:11 [alert] 4075#0: *17879 socket() failed (24: Too many open files) while connecting to upstream, client: 78.163.x.x, server: myserver.com, reqst: "GET / HTTP/1.1", upstream: "http://127.0.0.1:81/", host: "myserver.com", referrer: "http://www.google.com.tr/search?client=opera&rls=tr&q=myserver.com&sourid=opera&ie=utf-8&oe=utf-8&channel=suggest"
2011/05/12 12:32:11 [alert] 4075#0: *17883 socket() failed (24: Too many open files) while connecting to upstream, client: 78.163.x.x, server: myserver.com, reqst: "GET / HTTP/1.1", upstream: "http://127.0.0.1:81/", host: "myserver.com", referrer: "http://www.google.com.tr/search?client=opera&rls=tr&q=myserver.com&sourid=opera&ie=utf-8&oe=utf-8&channel=suggest"
2011/05/12 12:32:11 [alert] 4075#0: accept() failed (24: Too many open files)
2011/05/12 12:32:11 [alert] 4075#0: *17885 socket() failed (24: Too many open files) while connecting to upstream, client: 213.153.x.x, server: myserver.com, ruest: "GET / HTTP/1.1", upstream: "http://127.0.0.1:81/", host: "myserver.com", referrer: "http://www.google.com.tr/search?client=opera&rls=tr&q=myserver.com&soceid=opera&ie=utf-8&oe=utf-8&channel=suggest"
2011/05/12 12:32:11 [alert] 4075#0: accept() failed (24: Too many open files)
2011/05/12 12:32:11 [alert] 4075#0: accept() failed (24: Too many open files)
2011/05/12 12:32:11 [alert] 4075#0: accept() failed (24: Too many open files)
2011/05/12 12:32:11 [alert] 4075#0: accept() failed (24: Too many open files)
2011/05/12 12:32:11 [alert] 4075#0: accept() failed (24: Too many open files)
2011/05/12 12:32:11 [alert] 4075#0: accept() failed (24: Too many open files)
2011/05/12 12:32:11 [alert] 4075#0: accept() failed (24: Too many open files)

IP's und Servername wurden verändert (myserver.com)
 
ulimits setzt ein Default-Wert von 1024 Filehandlers auf Benutzer, du willst diesen Wert wahrscheinlich erhoehen ;)
(Beachte: unter Linux ist _ALLES_ von Netzwerkverbindungen ueber Kernel bis zur RAM eine Datei!)
Wenn du aber 1000 offene Verbindungen hast rate ich an die in meinem Blog verlinkten Iptables-Regeln zur Limitierung der offenen Verbindungen je Client-IP ein zu setzen.

Uebrigens wuerde ich Apache nur auf der IP-Range 127.0.0.0/8 und Port 80 horchen lassen, ergibt zwar in phpinfo() interessante Angaben aber dann kann er nicht mehr gezielt angegriffen werden sofern jemand den Port ausfindig macht.
Dazu ist aber natuerlich eine Umaenderung der vHost-IP's notwendig ;)
 
Mit folgenden Skripten und Regeln haben wir den Angriff schlussendlich eingedaemmt gekriegt:
MOD: Ungültigen Link entfernt.
 
Ich muss mal ein großes Lob an d4f aussprechen. Was uns seit langem nicht gelungen ist, hat er innerhalb weniger stunden hinbekommen. Respekt und vielen Dank nochmal.
 
Ich frage (privat) keine Gegenleistung fuer meine im Forum angebotene Hilfe[*],
nur eine Bitte bei Zufriedenheit fuer mein in der Planung/Entwicklung befindliches Projekt zu spenden


[*] Ausser anders angegeben
 
Ein FOSS-lizenziertes Webhosting Cluster Panel.
Aber ich denke wir rutschen hier leicht ins OT, ich diskutiere gern ueber IRC #ssf oder PN darueber weiter :)
 

Back
Top