Angriffe auf Drupal Website
Eingetragen von SWMH (7)am 29.09.2009 - 13:11 Uhr in
Hallo,
ich hatte in letzter Zeit jetzt schon mehrmals das Problem, dass meine Drupal Website wohl mutwillig angegriffen wird (?? bzw. das da irgendein wild gewordener Robot drüberrennt ??). Da dies jedes Mal meinen kompletten Server lahmlegt, suche ich nun eine Möglichkeit, wie ich das Problem in den Griff bekommen kann. Zuerst mal ein paar Infos:
Website:
Jobbörse mit ca. 70.000 Jobs. Läuft unter Drupal 5. Die Jobs (Nodes mit CCK erweitert) werden über Views aufgelistet (jeweils 25 pro Seite, präsentiert als Teaser). Von der Performance her sind diese Job-auflistenden Views die Schwachstelle meines Systems (bezüglich Anzahl der Datenbankabfragen und Ladezeit). Im normalen Betrieb (ca. 500 – 1000 Besucher pro Tag) gibt es keine Probleme, durchaus aber bei mehreren 100 Anfragen pro Sekunde. Genau auf diese Job-auflistenden Views zielt immer der externe Angriff.
Der Angriff:
Zur exakt gleichen Zeit werden ca. 100 – 150 Verbindungen auf verschiedene Unterseiten meiner Job-auflistenden Views aufgebaut (jede Verbindung ruft eine andere Unterseite auf). Jede Sekunde werden dann neue 100 – 150 Verbindungen aufgebaut. Der Angriff dauert ca. 2 – 10 Minuten.
Der Angriff läuft über mehrere unterschiedliche IPs, wobei jede IP ca. 10 – 20 Verbindungen pro Sekunde aufbaut. Die IPs, die ich überprüft habe, liegen wohl alle auf dedicated.hosteurope.de – Systemen.
Obwohl es unterschiedliche IPs sind, haben alle die gleiche Betriebssystem / Browser Kennzeichnung:
"Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9.0.1) Gecko/2008070208 Firefox/3.0.1"
Was passiert auf meinem Server:
- max. Anzahl an Apache Servern laufend
- Alle möglichen MySQL Verbindungen (max. 200) werden ausgenutzt
- Warnung: [error] server reached MaxClients setting, consider raising the MaxClients setting
- Mehrmalige Warnung: [notice] child pid XXXXX exit signal Segmentation fault (11)
- Server Load steigt von üblichen 0,2 – 0,5 auf 100 – 200
- Sehr hohe CPU IOWait Werte
- Server unerreichbar, komme selbst über SSH nur ganz schwer drauf
Die große Frage nun:
Was kann man machen um solche Angriffe (sofern es einer war) automatisch abzuwehren?
Gibt es eine Möglichkeit, die Anzahl der ausgelieferten Drupal Views oder die Anzahl der Datenbankverbindungen für Views zu limitieren?
Ist übrigens ein eigener Rootserver, kann also am System beliebige Änderungen durchführen.
Was ich schon gemacht habe:
- Generelle Einstellungen Apache2: KeepAliveTimeout sehr niedrig gesetzt.
- IPTables recent: Clients sperren, die pro 30 Sekunden mehr als 25 Zugriffe haben (bringt wenig, weil die Angreifer ja über mehrere IPs agieren, außerdem kann dies Besucher sperren, die über große Proxys ins Internet gehen)
- Generelle Server Absicherung: mod_security2, Suhosin für PHP
- Server Debian 4 auf dem aktuellsten Stand
- Drupal 5 und alle Module auf dem neuesten Stand
- Anmelden oder Registrieren um Kommentare zu schreiben
Schon einen Abuse Report an
am 29.09.2009 - 13:58 Uhr
Schon einen Abuse Report an Hosteurope geschickt?
--
mortendk: everytime you use contemplate... Thor is striking down from above with his mighty hammer - crushing and killing a kitten!
webseiter.de
Cache
am 29.09.2009 - 14:03 Uhr
Moin.
Wir haben das Thema gerade mal kurz im IRC diskutiert: wie siehts denn bei Dir mit Caching aus? Das sind doch alles nicht angemeldete Benutzer, also sollte da eigentlich die komplette Seite zu cachen sein. Notfalls noch XCache oder MemCache dahintergepackt und schon sollte der Server spürbar weniger zu tun haben.
Nichtsdestotrotz würde ich auch den von Alex vorgschlagenen Report bei HostEurope machen.
hth,
Stefan
--
sei nett zu Deinem Themer
@ Alexander Langer Habe ich
am 29.09.2009 - 14:35 Uhr
@ Alexander Langer
Habe ich noch nicht gemacht. Werde es gleich mal machen.
Seit einer Woche waren das jetzt 3 Angriffe.
@ stBorchert Der Angriff
am 29.09.2009 - 14:41 Uhr
@ stBorchert
Der Angriff läuft über die Gast-Ebene von Drupal.
Aktuelle Caching - Funktionen:
Bei Drupal ist aktiviert:
- Caching-Modus: Normal
Auf dem Debian-System läuft:
- APC Alternative PHP Cache
- MySQl query_cache
Werde mir die anderen vorgeschlagenen Sachen mal anschauen.
Wie gesagt im normalen Zustand läuft alles super und sehr performant. Nur bei den extremen Zugriffszahlen wärhend des Angriffs wirds eng...
Views-Cache
am 29.09.2009 - 14:43 Uhr
Ich weiss jetzt nicht genau, wie das bei D5 und Views1.x aussah, meine jedoch, dass es auch dort schon die Möglichkeit gab, die Ergebnisse des Views zu chachen.
Somit wären zumindest die "grossen" SQL-Abfragen ein wenig entschärft.
hth,
Stefan
--
sei nett zu Deinem Themer
Daran habe ich auch schon
am 29.09.2009 - 15:02 Uhr
Daran habe ich auch schon gedacht. Bei Views2 gibt es auf jeden Fall einen Cache, bei Views1 habe ich das bisher allerdings noch nicht gesehen. Ich werde mal danach suchen (oder das für Ende Oktober geplanten Update auf Drupal 6 etwas vorziehen).
Ansonsten schaut auch memcached noch sehr interessant aus.
Ups, sorry für die doppelte
am 29.09.2009 - 15:11 Uhr
Ups, sorry für die vorherstehende doppelte Antwort.
Komischerweise war Drupalcenter gerade beim Schreiben meiner Antwort (genau wie einer meiner anderen Server bei Hetzner) für einige Sekunden nicht erreichbar.
Wenn, wie du schreibst, jede
am 29.09.2009 - 15:34 Uhr
Wenn, wie du schreibst, jede von einer einzelnen IP pro Angriff und Sekunde 10-20 Verbindungen aufgebaut werden und noch dazu der User Agent stets gleich ist, kann man mit verschiedenen Mitteln den Angreifer detektieren und aussperren.
Es gibt z.B. mod_evasive, ich weiß aber nicht, ob das auch in aktuellen Apache Versionen läuft, das DDOS Deflate Script, etc. Man kann sich auch was selbst stricken mit etwas Geskripte und fail2ban und / oder mod_security2.
Im Grunde muss man nur das Log autom. überwachen lassen (macht z.B. fail2ban) und wenn im Zeitraum x von einer einzelnen IP y Verbindungen aufgemacht werden wird autom. über die Firewall die IP für einen Zeitraum z gesperrt. So lange ist dann Ruhe und irgendwann kapiert auch der dümmste Bot, dass kein Anschluss unter dieser Nummer ist.
Das ist eingentlich schon das komplette Grundprinzip von fail2ban, nur die entsprechende Regel muss man sich einmal selbst schreiben.
--
mortendk: everytime you use contemplate... Thor is striking down from above with his mighty hammer - crushing and killing a kitten!
webseiter.de
SWMH schrieb Ups, sorry
am 29.09.2009 - 15:36 Uhr
Ups, sorry für die vorherstehende doppelte Antwort.
Komischerweise war Drupalcenter gerade beim Schreiben meiner Antwort (genau wie einer meiner anderen Server bei Hetzner) für einige Sekunden nicht erreichbar.
Ja, war ein kurzer Ausfall, entweder intern im Routing, oder seitens T-Com...
--
mortendk: everytime you use contemplate... Thor is striking down from above with his mighty hammer - crushing and killing a kitten!
webseiter.de
Danke für die Tipps.
am 29.09.2009 - 21:03 Uhr
Danke für die Tipps. Momentan herrscht schon seit Stunden wieder Ruhe und meine Websites laufen normal. Einen akuten Notfallbedarf gibt es also momentan nicht mehr.
Für die Zukunft werde ich in den nächsten Tagen wohl noch etwas an der Performance optimieren (bessere Cache Lösung) und eine der oben genannten Log-basierten Sperren einbauen.
Hosteurope.de hat auch schon geantwortet und will sich die entsprechenden Server mal genauer anschauen ...
Erreichbar sind diese übrigens nicht mehr ;)