Re: apache 2.2 slots freigeben

Marian Hettwer wrote:
> ich kämpfe hier grade gegen dDoS attacken gegen einen Webserver den ich
> administriere.

In so einem Fall sollte man immer versuchen, den Angriff
auf niedrigstmöglicher Ebene zu bekämpfen. Am besten,
bevor die Requests überhaupt auf Applikationsebene (hier
beim Apache) ankommen. Leider ist das nicht immer möglich.

Ich nehme an, bei den IP-Adressen ist keine Gemeinsamkeit
erkennbar, oder? Dann könntest Du's natürlich per Paket-
filter aussperren. Aber wenn's so einfach wäre, hättest Du
das sicherlich schon getan.

Sind eigentlich HTTP-Accept-Filter in Deinem Kernel einge-
schaltet ("options ACCEPT_FILTER_HTTP" bzw. als Modul mit
"kldload accf_http")? (Siehe die accf_http(9)-Manpage.
Wenn Du das Modul lädst, musst Du den Apache komplett stop-
pen und neu starten.)

> Die Anfragen gehen alle auf den selben File, der so nicht mehr existiert.
> Da 404 werfen auch nicht schön ist, habe ich folgendes in meiner httpd.conf
>
> Redirect permanent /foobar.txt http://127.0.0.1
>
> Getreu dem Motto, nervt euch doch selbst.

Ich fürchte, es ist ziemlich egal, was Dein Apache zurück-
liefert, denn der Angreifer wird es einfach ignorieren.
Vermutlich beendet er seine Seite der Verbindung bereits
unmittelbar nach Abschicken des Requests (ohne ein Reset-
Paket zu schicken, natürlich).

Wäre ich in Deiner Situation, würde ich als schnellste
Notfallmaßnahme direkt im Apache-Code ansetzen. Bei Apache
2.2.3 wäre das in der Datei server/protocol.c die Funktion
read_request_line(). Dort gibt es eine Zeile:

        uri = ap_getword_white(r->pool, &ll);

Unmittelbar danach könnte man folgenden Code einfügen:

        if (strcmp(uri, "/what/ever.php") == 0) {
                r->status = 0;
                return 0;
        }

Beim strcmp() natürlich den entsprechende URI-Pfad einset-
zen (ohne das "http://host.name").

Ich bin jetzt nicht sicher, ob der Apache dann die Ver-
bindung sofort zumacht, oder ob noch seine »SO_LINGER-
Emulation« für einige Sekunden zuschlägt. Muss man im
Zweifelsfall ausprobieren. Hängen die Connections trotz-
dem noch herum, muss man dann in obigem Code wohl noch
die Verbindung explizit schließen. Das müßte wie folgt
gehen (vor dem "r->status = 0" einfügen):

        conn_rec *c = r->connection;
        apr_socket_t *csd = ap_get_module_config(
            c->conn_config, &core_module);
        c->aborted = 1;
        apr_socket_close(csd);

Das ist aber jetzt alles nur Theorie und ungetestet.
Möglicherweise muss man noch ein include-File angeben
(ich habe momentan leider nicht die Zeit, das tatsäch-
lich selbst zu testen). Also: Verwendung auf eigene
Gefahr!

> Kennt jemand eine Möglichkeit das im apachen zu tun?
> Sozusagen: Wenn /foobar.txt, dann Redirect und danach Slot freigeben und
> nicht warten was die gegenstelle dazu sagt.

Das ist vom Apache nicht vorgesehen.

> Und ich weiß auch nicht wie der apache reagiert, wenn pf die
> Verbindungen wegräumt ;)

Wenn Apache kein RST-Paket (Reset) bekommt, dann wartet er
halt seinen Timeout ab.

> Dank mpm-event schafft die Kiste immerhin sportliche 2048 apache slots
> zur Verfügung zu stellen... :)

2048 hatte ich auch schonmal mit einem Apache 1.3. Das
mpm-event ist zwar 'ne clevere Idee, aber ich frage mich,
ob es in Deinem Fall viel bringt, wenn Du Keep-Alives
ohnehin »fast« ausschaltest (nur 1 Sekunde).

NB, ich persönlich finde, mpm-event »riecht« noch ziemlich
experimentell. Killerargument für mich ist aber, dass es
mit einigen anderen Sachen inkompatibel ist, zum Beispiel
mit mod_ssl. (Natürlich gilt, wie immer: YMMV.)

Gruß
   Olli

-- 
Oliver Fromme,  secnetix GmbH & Co. KG, Marktplatz 29, 85567 Grafing
Dienstleistungen mit Schwerpunkt FreeBSD: http://www.secnetix.de/bsd
Any opinions expressed in this message may be personal to the author
and may not necessarily reflect the opinions of secnetix in any way.
"If you think C++ is not overly complicated, just what is a protected
abstract virtual base pure virtual private destructor, and when was the
last time you needed one?"
        -- Tom Cargil, C++ Journal
To Unsubscribe: send mail to majordomo(at)de.FreeBSD.org
with "unsubscribe de-bsd-questions" in the body of the message