Off-Topic

Wie in einem vorhergehenden Beitrag angekündigt, soll fail2ban mod_evasive ergänzen.
Statt nur Apache "403 Forbidden" Fehler ausliefern zu lassen, soll die IP komplett mit iptables geblockt werden.

Dazu brauchen wir:

1. einen fail2ban Filter
2. ein fail2ban jail

Das Problem: Apache auf einem mit wenig Ressourcen ausgestatteten Server (eine VM, Ubuntu lucid) erreicht neuerdings öfter mal das MaxClients Limit.
Nachdem ich die Apache Logfiles durchstöbert habe, stelle ich fest, dass von nur wenigen IP's massiv Anfragen kommen. Der vorgebliche Useragent IE6 ist es mit Sicherheit nicht - so schnell kann sich kein Mensch durchklicken.
Eher ist es ein schleißig programmierter Testbot oder ein Scriptkiddie hat was gebastelt.

In jedem Fall muss gedrosselt werden. Es darf nicht sein, dass eine einzelne IP via Script das normale Ausliefern von Content an echte menschliche Besucher ausbremst.

Der Stromsparmodus meines Laptops hat (mal wieder) die Festplatte ruiniert.
Das viel zu häufige Stoppen/Starten hat die Mechanik stark strapaziert, die Festplatte klickt hörbar.
Da die Werte der Load_Cycle_Count (638223!!) schon bei Weitem die Empfehlungen des Festplattenherstellers übersteigen, besorge ich Ersatz. Ich warte gar nicht erst, bis smartd mir das nahe legt (was mit Sicherheit demnächst der Fall wäre).

Folgendes soll umgesetzt werden:
in einem Webspace soll zum Einen an PHP Files entwickelt werden, zum Anderen soll das Ergebnis auch als normale Website sichtbar sein.
Der Zugang soll nur authentifiziert möglich sein, allerdings soll weder FTP noch SSH als Zugang verwendet werden.
Warum?

1. FTP läuft auf dem Server gar nicht erst und würde das übliche "die Datei / der Ordner gehört nicht dem Apache User" Problem mit sich bringen (da keine fcgi Konstruktion).
2. SSH ist bei Weitem zu privilegiert, dem authentifizierten User soll kein Zugang zum Dateisystem gewährt werden. (und Dateirechte Problem siehe Punkt 1)

Der Lösungsansatz: Zwei VirtualHosts (eigene Subdomain) mit einem gemeinsamen DocumentRoot, einer als normaler Webspace, einer mit Webdav.
Getestet und für gut befunden mit Linux-Server (mit Apache als Webserver) und Linux-Client.

Voraussetzungen:

1. mod_dav und mod_dav_fs sind geladen (Apache)
2. mod_auth_digest ist geladen (da Authentifizierung via Digest)
3. Direktive NameVirtualHost *:80 ist aktiv

Zwar muss man dafür an einem .rb file herum hacken...

Gefunden auf: http://www.drupalcenter.de/handbuch/34182

Bei einem Ubuntu LTS Standard Redmine Paket (Version 0.9.3.stable) wäre der Pfad zur Datei:

Nach dem Wechsel von Firefox 3 auf 3.5 bemerkte ich, dass Farben bzw. Bilder im Browser teilweise total falsch dargestellt werden. Ganz besonders bei manchen pngs. Inzwischen bin ich bei FF 3.6 angelangt, das Problem hat sich aber leider nicht von selbst gelöst. Ich musste etwas recherchieren.
Die gute Nachricht, jetzt stimmen die Farben wieder. Das Problem war die falsche Einstellung bei gfx.color_management.mode.

Eine weitere Regel, die auf den momentan kursierenden Bilderspam (wieder die blauen Pillchen) zutrifft.
Das kann z.B. als Datei susp_jpg.cf im selben Ordner wie local.cf abgelegt werden.

Die Rule trifft zu, wenn
1) die Email von einer dynamischen IP stammt
2) ein einzelnes JPEG angehängt ist
3) das Bild in den Dimensionen zwischen 230 und 440 Pixel (Breite und/oder Höhe) liegt
4) der Anhang inline ist

RDNS_DYNAMIC und __JPEG_ATTACH_1 werden nicht hier definiert, sondern kommen schon mit Spamassassin mit.
Für so ein verdächtiges JPEG gibt es dann 2,2 Punkte dazu.

Eine etwas speziellere Variante: