phpbar.de logo

Mailinglisten-Archive

[php] "Server-Attacken" lähmen?

[php] "Server-Attacken" lähmen?

Mario Haßler M.Hassler at gmx.de
Di Mär 30 21:03:01 CEST 2010


Hallo

und danke an alle, die auf meine Anfrage geantwortet haben! Fangen
wir vorne an:


Am 29.03.2010 19:25 schrieb Thomas Koudela:

>> [...] ich würde gerne dem "Angreifer" eins auswischen.
>
> Rache als Motiv? ;-)

Nennen wir es Gegenwehr. :-)

> [...] Du wirst wahrscheinlich in der Summe die gleiche Anzahl an
> Angriffen haben, aber besser verteilt.

Wenn das so wäre, hätte ich nichts gewonnen. Meine Idee ist ja, dass
der Angreifer aufgibt, weil es auf meiner Seite zu lange dauert, um
alle Adressen, die er auf der Liste hat, auszuprobieren.

> Die Header werden erst gesendet, sobald die erste Ausgabe ausgeführt
> wird. Insofern würde die Antwort tatsächlich verzögert.

Sicher? Wie gesagt, ich vermute, dass der Angreifer lediglich die
Header abfragt. Dies kann ihm der Apache-Server beantworten, bevor
auch nur ein PHP-Skript aufgerufen wird, und beispielsweise den
Return-Code 404 liefern, wenn es die angeforderte Seite nicht gibt
(und es auch keine Server-Regel gibt, die für den Fall etwas anderes
vorsieht).

> [...] Diese Anfragen treten normalerweise nicht in einem Umfang auf,
> dass sie einen nennenswerten Anteil der Serverlast ausmachen. Ich
> würde diese "Fehler" aber nicht mitloggen lassen. Erstens übersieht
> man so die wichtigen Fehlermeldungen und zweitens schreibt Dein System
> dadurch dauernd in eine Datei, was unnötig Ressourcen verbraucht.

Das ist im Grunde genommen einer der Beweggründe, warum ich das vor-
habe: Ein Angreifer, der aufgibt, produziert keine weitere Fehler-
meldungen in meiner Log-Datei, die den Blick auf das Wesentliche be-
einträchtigen.

Wie kann ich denn beeinflussen, welche Zugriffe in die Log-Dateien
(access.log, error.log) kommen und welche nicht? (Von der Seite habe
ich das noch gar nicht betrachtet.)

> [...] Während Dein Server mit der Antwort wartet, hat der Angreifer
> auch nichts zu tun... Und kann weitere Anfragen starten.

Naja, der Gedanke war, dass er auch nicht beliebig viele Anfragen
offen haben kann. Am Ende ist er nur noch mit Warten auf Antwort be-
schäftigt, wenn nur genügend viele verzögern.

> Der einzige Schlüssel zum Schutz gegen solche Attacken ist IMO fremden
> PHP-Code immer gegenzulesen. Gerade in beliebter OpenSource-Software
> wird gerne mal ein Trojaner versteckt. (Habe selber vor Jahren mal
> schlechte Erfahrung gemacht.)

Es gibt kein fremdes PHP auf meiner Seite, deshalb kommen ja lauter
404-Fehlermeldungen. Es gibt also keinen wirklichen Schaden außer
die unnötigen Zugriffe und die unnötigen Einträge in den Log-Dateien.


Am 29.03.2010 21:12 schrieb klemens:

 > [...]
 > http://board.gulli.com/thread/1112317-w00tw00t-fail2ban-mit-ispconfig-accesslog/
 >
 > Das macht dir dann gleich die FW für die IP dicht -- von da kommt eh
 > nix gutes :)  (kann natürlich auch nach hinten losgehen...)

Ich habe weder den Text auf der genannten Seite verstanden noch die
Erläuterungen in der E-Mail, insofern ist das wohl nix für mich...


Am 29.03.2010 21:48 schrieb Yannik Hampe:

 > [...] Das nennt sich "teergrubing".

Mmh... von einer "Teergrube" (oder engl. "tarpit") habe ich vor Jahren
mal was gehört, aber das war im Zusammenhang mit Mail-Servern, als
Schutz vor Massen-Mailings (Prinzip: Je mehr Mails pro Zeiteinheit
ausgeliefert werden sollen, desto länger verzögert der Mail-Server).

 >>   [...] Ist es wahrscheinlich, dass weitere Anfragen
 >>      ausbleiben, wenn die erste verzögert wird?
 >
 > Ich vermute, das da nix ausbleibt, weil es immer wieder jemand
 > anderes dahinter steckt. Wer will schon deinen Server im Wochentakt
 > scannen? ^^

Nein, gemeint war: dass der eine Angreifer nach ein, zwei Adressen
aufgibt und nicht seine ganze Liste mit 20 bis 30 Adressen auspro-
biert (das error.log-Beispiel war nur ein kleiner Ausschnitt!).

 >>   2. Geht das überhaupt? Der Angreifer fragt evtl. nur die Header ab
 >>      und nicht den Seiteninhalt. (Er braucht ja nur den Return-Code
 >>      200 oder 404 wissen.) Liefert der Apache-Server diese Header
 >>      bzw. diesen Return-Code bereits aus, bevor mein Skript überhaupt
 >>      dran kommt und die Antwort verzögern kann?
 >
 > Das geht.

Siehe oben: Sicher? Auch wenn nur der Header abgefragt wird? (In PHP
gesprochen: get_headers($url);)

 > http://diveintomark.org/archives/2003/02/26/how_to_block_spambots_ban_spybots_and_tell_unwanted_robots_to_go_to_hell

Dieser Mensch arbeitet mit Regeln, die sich auf die IP-Adresse des
Angreifers, die Vorgängerseite oder die User-Agent-Kennung beziehen.
All das steckt er in Server-Konfigurationsdateien. Mir gefällt dieser
Ansatz in mehrfacher Hinsicht nicht.

 > http://www.devin.com/sugarplum/

Hier werden Seiten mit falschen E-Mail-Adressen erzeugt, damit Adres-
sensammler in die Falle tappen. Das ist nahezu das Gegenteil von dem,
was ich will (falsche E-Mail-Adressen = noch mehr Zugriffe, mehr ver-
schwendete Bandbreite auf meiner Seite; meine Idee = Angreifer los-
werden, Zugriffe und Bandbreite gespart).

 > Wenn alle das machen würden, dann wäre das schon sehr effizient.

Ah. Immerhin.


Ich denke, ich werde mal mit Verzögerungen experimentieren und schauen,
ob sich prinzipiell etwas ändert. Bei der Gelegenheit könnte ich auch
testen, ob bei einer get_headers()-Abfrage verzögert wird oder nicht.
Informationen darüber, wie man steuern kann, welche Einträge in die
Log-Dateien sollen und welche nicht, nehme ich gerne an (auch wenn
dies vermutlich noch stärker Apache berührt).

Danke nochmals.

Viele Grüße,

Mario Haßler

php::bar PHP Wiki   -   Listenarchive