Re: apache 2.2 slots freigeben

Marian Hettwer wrote:
> Oliver Fromme schrieb:
> Die Angriffe kommen zwar immer auf die selbe URL (das ist schonmal gut),

Ja, Glück gehabt; die Bots könnten auch einfach zufällige
Requests generieren.

> aber von bis zu 700 unterschiedlichen IP Adressen.

Naja, 700 ist ja noch relativ überschaubar. Wenn Du diese
inzwischen alle kennst, was spricht dann dagegen, sie per-
manent per Paketfilter zu blocken?

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

Damit blockst Du natürlich auch die RST-Pakete, sofern ir-
gendmal eins kommen sollte. OK, wenn Deine Beobachtungen
stimmen, dann schicken die Angreifer eh nie eins, insofern
ist es wohl wurscht.

Ich weiß grad nicht ausm Kopf, ob PF es unterstützt, aber
IPFW hat die Möglichkeit, selbst ein RST-Paket auszulösen
(Regeln mit "reset"-Action). Wenn Du eine Regel hinzu-
fügst (am besten sowohl für outgoing als auch incoming),
die ein RST-Paket schickt anstatt einfach nur zu blocken,
sollte der Apache eigentlich die Verbindung sofort beenden.

> 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.

Warum lässt Du sie nicht drin?

> 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 :(

Ja. Wie gesagt, ich würde als Notfallmaßnahme den Apache
patchen. Das verschafft zumindest erstmal Luft, um sich
in Ruhe etwas Besseres zu überlegen. Ich kann aber auch
verstehen, dass Du den Source lieber nicht anrühren magst.

> Der Apache benutzt das accf_http Modul.

Gut.

> 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...

Meine nächstbeste Idee wäre gewesen, ein kleines Divert-
Modul zu schreiben, das ein simples Pattern-Matching nach
dem "GET /..." macht und ggf. ein RST erzeugt. Wäre ca.
eine Seite C-Code gewesen. Aber es erfordert leider schon
ein wenig mehr als rudimentäte Kenntnisse, fürchte ich.

Die drittbeste Idee wäre, einen Reverse-Proxy vor Deinen
Apache vorzuschalten, der die Angreifer wegfiltert und
alles andere nur durchreicht. Man muss aber mit der Kon-
figuration vorsichtig sein, wenn man das Problem nicht nur
verlagern will.

> 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 ;)

Es sollte möglich sein, ein Apache-Modul dafür zu schrei-
ben, oder eine Direktive in ein bestehendes Modul einzu-
bauen.

> 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.

Jein ... er entfernt sie nur aus seiner State-Table. Die
Apache-Children würden vernmutlich weiterhin herumhängen.

> 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

Das ergäbe keinen Sinn, weil die Block-Regel ja keinen
State-Eintrag erzeugt (im Gegensatz zu "overload").

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.
"A language that doesn't have everything is actually easier
to program in than some that do."
        -- Dennis M. Ritchie
To Unsubscribe: send mail to majordomo(at)de.FreeBSD.org
with "unsubscribe de-bsd-questions" in the body of the message