Re: apache 2.2 slots freigeben

Marian Hettwer wrote:
> Oliver Fromme schrieb:
> > Naja, 700 ist ja noch relativ überschaubar. Wenn Du diese
> > inzwischen alle kennst, was spricht dann dagegen, sie per-
> > manent per Paketfilter zu blocken?
> Bis zu 700 in 24 Stunden... ich müsste mir über die Tage mal angucken ob
> es auch andere IPs sind, oder jeden Tag die selben 700.

Wenn's wirklich bei den 700 bleibt (oder nicht nennenswert
mehr), dann ist es wirklich das Einfachste, diese permanent
im PF zu blocken.

> > 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.
> hmmm... also quasi:
> Wenn incoming from <www-spammers> dann RST an apache port 80 from
> <www-spammers>
> Mal schauen ob man so ein Konstrukt mit pf hinbekommt.

Ich dachte eher an "wenn outgoing to <www-spammers>". Von
den Angreifern kommt ja nach dem "GET" ohnehin nichts mehr.
Aber Dein Apache wird auf ACKs warten und ggf. Retransmits
machen, und dann sollte er ein RST bekommen.

Wie gesagt, bei PF müsste ich nachschlagen. Bei IPFW sähe
die Regel so aus: reset tcp from me 80 to table(y)

> > > 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?
> >
> Aus der üblichen "Angst" irgendwann das halbe Internet geblockt zu haben.

700 ist zum Glück noch nicht das halbe Internet.
Du kanst sie ja drinlassen und ab und zu beobachten, wie
sich ihre Anzahl entwickelt. Mit hinreichend viel Spiel-
trieb kann man's in einen MRTG-Graphen reinfüttern. :-)

> > 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.
> >
> Ebend. Wenn der Reverse Proxy beim evaluieren schon zuviel Last erzeugt
> habe ich damit nichts gekonnt.
> Nen Apache mit mod_proxy dafür zu nehmen wäre vermutlich eine schlechte
> Wahl.
> Kennst du spontan einen _kleinen_ Reverse Proxy der auch Pattern
> Matching kann?
> Mir würde pound einfallen...

Ich würde Squid ohne Caching nehmen (dann wird er auch
nicht so groß). Squid forkt keine Children und verwendet
unter FreeBSD das kqueue()-Interface für die Descriptoren,
sollte daher hinreichend effizient sein. Lediglich das
Limit an Descriptoren könnte ein Problem werden, aber das
kann man ja nötigenfalls auf 10000 oder so setzen. Beim
Squid kann man auch die diversen Timeouts problemlos kon-
figurieren.

Wie gesagt: Ob's was bringt oder das Problem nur verla-
gert, kann ich nicht mit Sicherheit sagen. Aber ich glau-
be, es wäre einen Versuch wert, wenn man keine besseren
Optionen wahrnehmen kann. Es wäre natürlich vorteilhaft,
den Reverse-Proxy auf einer separaten Maschine laufen zu
lassen, sofern eine verfügbar ist.

> > > 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.
> >
> und wen bittet man in diesem Falle ganz lieb?! :) (Wenn mans selbst
> nicht kann...)

Keine Ahnung. Bei Open-Source-Software werden meistens nur
dann Dinge implementiert, wenn ein Entwickler selbst daran
ein Interesse hat. Oder wenn er dafür bezahlt wird, natür-
lich.

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.
"When your hammer is C++, everything begins to look like a thumb."
        -- Steve Haflich, in comp.lang.c++
To Unsubscribe: send mail to majordomo(at)de.FreeBSD.org
with "unsubscribe de-bsd-questions" in the body of the message