Re: apache 2.2 slots freigeben

Hi Olli,

endlich antwortet mal einer :-)

Oliver Fromme schrieb:
> 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.
>
ACK.
Die Angriffe kommen zwar immer auf die selbe URL (das ist schonmal gut),
aber von bis zu 700 unterschiedlichen IP Adressen.

> 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.
>
Leider kann ich keine Gemeinsamkeiten erkennen, aber mit diesem fiesen
Konstrukt blocke ich die IP's die ärger machen dennoch:
pfctl -t www-spammers -T add $(grep ${PHP1} ${LOGFILE} | grep -Eiv
"google|gigabot|inktomi|msnbot|yahoo|slurp" | grep -E "2006:$(date
+\%H:\%M)" | awk '{ print $1 }' | sort -u)

und in der pf.conf
block quick on $ext_if proto tcp from <www-spammers> to $ext_if port 80

soweit so gut. Der pfctl Aufruf kommt via cron 1 mal pro Minute. Die
Einträge im table www-spammers werden via expiretable alle halbe Stunde
bereinigt.

Das Problem bleibt aber, dass die entsprechenden Angreifer scheinbar
ihre http Verbindung nicht ordentlich beenden.
Der Apache Slot bleibt also bis zum TimeOut belegt... das ist halt
unschön :(

> 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.)
>
Der Apache benutzt das accf_http Modul.

> > 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).
>
Genau. Und das ist die eigentliche Sauerei...

> 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").
>
verstanden...

> 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!
>
Sowieso. Aber danke für die Infos.
Derzeit hält der Apache die Last aus... MaxClients ist bei 1024 und
entsprechende Angriffe belegen maximal 800 slots für maximal 1 Stunde...
Ich glaube ich möchte nicht direkt in den apache sourcen patchen...
nicht mit meinen rudimentären C Kenntnissen...

> > 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.
>
Schade. Aber endlich mal eine klare Ansage. Google und die Apache docs
konnte mir genau das leider nicht sagen.
Wäre doch mal ein Feature Request ;)

> > 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).
>
Ich würde den KeepAlive gerne wieder auf 5 Sekunden setzen... das
verstärkt aber mein Problem...

> 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.)
>
Da kann ich zustimmen. Mir ist bekannt das der mpm-event noch "neu" oder
"experimentell" ist. Und mod_ssl brauch ich auf der Maschine ein Glück
nicht...

Letzte Frage:
Bei pf(4) gibt's ja im overload feature die Möglichkeit zu sagen "flush
global", woraufhin pf die bestehenden Verbindungen von dieser IP beendet.
Irgendwie kann ich scheinbar nicht sowas in der block regel sagen:
block quick on $ext_if proto tcp from <www-spammers> to $ext_if port 80
flush global

Es sieht so aus, als würde es ein flush global nur bei overload geben.
Irgendeine Idee?
Ansonsten frage ich mal auf openbsd-misc@ nach...

Thx für den Input,
Marian

To Unsubscribe: send mail to majordomo(at)de.FreeBSD.org
with "unsubscribe de-bsd-questions" in the body of the message
Received on Tue 12 Dec 2006 - 12:30:12 CET