Hier im Forum wird ja oft darauf hingewiesen, wie wichtig es ist einen Server abzusichern.
Meist geht es dabei aber um ssh, iptables etc, also die unteren Netzwerkschichten. Die Absicherung auf dieser Ebene ist unabdingbar, schützt aber leider nicht auf Layer 7, also gegen Angriffe über den Webserver. (SQL-Injections, XSS etc). Dazu ist eine WAF nötig.
Bis vor kurzem habe ich mich da auf die WAF-Plugins der Anwendungen verlassen, nun aber doch mal ModSecurity angetestet, zusammen mit dem OWASP-ruleset
Ich habe schnell festgestellt, dass dies zwar ein gutes und mächtiges Werkzeug ist, man sich aber ein wenig eingehender damit beschäftigen muss, wenn man effektiven Nutzen daraus ziehen will. (Zum Glück konnte ich das wirklich gute "ModSecurity Handbook" von Folini und Ristic günstig abstauben 
)
Einfach nur installieren wird in der Regel nicht ausreichen. Insbesondere wenn man viele verschiedenartige Anwendungen laufen hat, würde das zu viele, nicht tragbare Fehlalarme geben. Man muss also nachsteuern.
ModSecurity im DetectionOnly-mode laufen zu lassen und dann eine Zeitlang die logfiles zu durchforsten (um false positives von echten Attacken zu separieren und dann Ausnahmen erstellen zu können) kann aber eine ziemlich frustrierende Angelegenheit sein. 
Ich habe mir deshalb ein kleines Tool ('pamsel') speziell dafür gestrickt, um mir die Arbeit dabei zu erleichtern.
Evtl. kann ja der eine oder andere, der ModSec verwendet (oder dies vorhat) etwas damit anfangen:
EDIT: Nun auf github:
https://github.com/aranemac/pamsel
Echte Doku gibt es (noch) nicht, aber hier mal die --help Ausgabe von pamsel:
$ ./pamsel --help
Usage: pamsel OPTIONS
field display options:
-d date/time
-u requested url
-i rule id
-m modsec message
-t rule tag (only OWASP_CRS/ tags are extracted!)
-s severity
-r referrer IP
-n consecutive number (for lookup in audit log)
-a unique modsec-id
field output is ordered according to the occurrence of the above options
-v verbose
-l list format (default is csv)
-f ERRORLOG if not given, pamsel reads from stdin/pipe
-x id1,id2,.. to exclude rules from parsing
-A --audit NUMBER[-ABCD..]
lists info from audit-log for given entry (number from -n)
-ABCD.. excludes specified audit-sections
-F --alog AUDITLOGFILE
default is /var/www/apache2/modsec_audit.log
-V --version version info
-h --help this
Some examples:
sudo cat /var/log/apache2/error.log | sudo ./pamsel -dimu
lists all events, one per line, with date, rule-id, message and url
sudo cat /var/log/apache2/error.log | sudo ./pamsel -im | sort | uniq -c
how often a rule is triggered
sudo cat /var/log/apache2/error.log | sudo ./pamsel -dim -x 920350,930130
exclude rules from listing
sudo cat /var/log/apache2/error.log | sudo ./pamsel -nrmu
-n gives every entry an unique number...
...which can be used to show the related info in audit-log:
sudo cat /var/log/apache2/error.log | sudo ./pamsel -A 136
you can exclude audit-sections (A-K) to reduce the amount of information
sudo cat /var/log/apache2/error.log | sudo ./pamsel -A 136-CE
".
Nur dass ich hier (wie immer) Praktikant und Chef in Personalunion bin. 
