Re: apache 2.2 slots freigeben

* Oliver Fromme (olli(at)lurza.secnetix.de):

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

Erst ab 2.6, also www/squid26 statt www/squid nehmen (ich werde die
Ports die Tage umbenennen lassen, so dass 2.6 der Default-Squid ist und
2.5 als www/squid25 für konservative User erstmal weiter verfügbar
lassen).

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

Deskriptoren sollten sich zur Kompilierzeit entsprechend hoch setzen
lassen, vorausgesetzt, dass dem nicht noch User-Limits entgegen stehen:

# make SQUID_CONFIGURE_ARGS="--with-maxfd=N", N hinreichend groß.

Alternativ wäre vielleicht als vorgeschalteter Accelerator auch
www/varnish interessant (oder sogar geeigneter als Squid).

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 - 20:35:44 CET