Frage zu mod_security rules

[ghoster1970]

Guten Tag,

ich möchte demnächst mod_security auf unserem Rootserver installieren und die Auswahl zwischen 2 Rulesets von
a)gotroot
b)von der Produktanbieterseite selbst.
Folgendes läuft auf dem Server und mehr Dienste sind soweit nicht vorgesehen:
Apache2 mit php4/php5
Postfix+MySQL
Webpages in PHP zzgl. MySQL Datenbankunterstützung
verschiedene Subdomains, darunter eine wo phpmyadmin usw per Passwortabfrage (htpasswd) gesichert liegt.

Nach der Modulinstallation muss der Zugriff auf MySQL Datenbanken (Datensätze verändern, löschen oder bearbeiten) auch per Skript und phpmyadmin möglich sein.

Auf welche Rules aus beiden Rulesets könnte ich eurer Meinung nach bei unseren Anforderungen, s.o., verzichten aus Performancegründen?

http://www.modsecurity.org/projects/rules/
http://www.gotroot.com/downloads/ftp/mo ... y/apache2/

Über Ratschläge von Euch würde ich mich sehr freuen, habe mod_security bisher nicht im produktiven Bereich eingesetzt.

[caput]

Ich kann noch nen paar Rulesets anbieten: http://www.rootforum.org/forum/viewtopic.php?t=35865 :oops:

Ansonsten spiele ich grade mit nem neuen Ruleset von gotroot.com rum, welches auf das Minimum reduziert wurde. Allerdings würde ich dies auch noch als sehr experimentell einstufen.

Nach der Modulinstallation muss der Zugriff auf MySQL Datenbanken (Datensätze verändern, löschen oder bearbeiten) auch per Skript und phpmyadmin möglich sein.

Wird schwer. Nach eigenen Erfahrungen lohnt sich der Aufwand nicht, die Rulesets dahin zu optimieren, dass sie damit laufen. Sinnvoller und Pflegeleichter erscheint es dann doch bei der Subdomain ModSecurity zu deaktivieren und 'nen Auge auf eine aktuelle phpMyAdmin-Version zu legen.

Code: Select all

<IfModule mod_security.c>
  SecFilterEngine Off
</IfModule>

Viel Spaß beim frickeln. :P

[ghoster1970]

<IfModule mod_security.c>
SecFilterEngine Off
</IfModule>

hmmmm, darauf hätte ich auch selbst kommen können :oops:

Werde heut Nacht mal das Modul kompilieren und mit den neuen gotroot Rules. Die sind abgespeckt sagst du? Hab nämlich noch die alten irgendwo verstaubt auf der Platte zu liegen.

Mein Server ist eigentlich entsprechend abgesichert, auch ohne mod_security... sagen wir mal zumindest gegen Skript-Kiddies.
In den letzten Tagen hab ich vermehrt Zugriffsversuche wie http://URL/?cmd... usw usw usw in den logs gefunden.
Alle erfolglos aber kann ja mal einer kommen der wirklich Ahnung hat!
Ob dann mod_security greift wenn "real Hackers" kommen?

Mir fehlt jedenfalls die Erfahrung mit dem Teil :o

[caput]

Die sind abgespeckt sagst du? Hab nämlich noch die alten irgendwo verstaubt auf der Platte zu liegen.

Nunja der offizielle gotroot.com Klumpen hat sehr viele definierten Regeln, welche zwar zum Teil die "false detection"-Rate auf ein gewisses minimum zurückschraubt. Allerdings musst du bedenken, dass das ganze Ruleset bei jeden Request abgearbeitet wird. Wie sich das ab einer gewissen Menge von Hits/Requests verhält kannst du dir nun selbst ausmalen.

Das gestrippte Ruleset von mir deckt die allgemeinen und gängigen "Angriffe" ab und das ohne Performanceverlust. Und in Kombination mit 'nem sauberem Setup mit php-fcgi denke ich, ist ein guter Weg durch die Mitte. Falls dir das zu wenig ist, bietet sich ja noch die Möglichkeit von [chroot|jails], SELinux oder gleich den Webserver zu virtualisieren. ;)

[malo]

Die sind abgespeckt sagst du? Hab nämlich noch die alten irgendwo verstaubt auf der Platte zu liegen.

Nunja der offizielle gotroot.com Klumpen hat sehr viele definierten Regeln, welche zwar zum Teil die "false detection"-Rate auf ein gewisses minimum zurückschraubt. Allerdings musst du bedenken, dass das ganze Ruleset bei jeden Request abgearbeitet wird. Wie sich das ab einer gewissen Menge von Hits/Requests verhält kannst du dir nun selbst ausmalen.

Das gestrippte Ruleset von mir deckt die allgemeinen und gängigen "Angriffe" ab und das ohne Performanceverlust. Und in Kombination mit 'nem sauberem Setup mit php-fcgi denke ich, ist ein guter Weg durch die Mitte. Falls dir das zu wenig ist, bietet sich ja noch die Möglichkeit von [chroot|jails], SELinux oder gleich den Webserver zu virtualisieren. ;)

magst deine rules dann mal hier posten?`wäre super!

[caput]

magst deine rules dann mal hier posten?`wäre super!

Siehe Links auf dem zweiten Beitrag aus diesem Thread. :roll:

[sledge0303]

Hi caput,

ich experimentiere auch gerade ein wenig mit den neuen Rules von gotroot rum.
Aber nichtsdertrotz, werde mal gucki-lucki in deine vorgeschlagenen Rules machen :)

EDIT:
Lasse mal deine Rules testweise für ein paar Tage auf unserem vServer laufen. Sieht soweit erstmal ausreichend aus, evtl. wird noch aus der Sektion Rootkits 1-2 Nachträge geben.
Mal sehen wie es mit der Performance aussieht, lasse mich mal überraschen.
/EDIT

[derfalk]

@caput
Bis dato laufen deine Rules echt gut! :)

[derfalk]

... vielleicht sollte man die Rulesets hinsichtlich der eigenen Anwendungen auf dem Server optimieren und dann anpreisen?

Also sowas wie:

"joomla/mambo.conf"

oder

"phpbb.conf"

so liese es sich sicherlich noch ein wenig "übersichtlicher" gestalten oder?

[caput]

... vielleicht sollte man die Rulesets hinsichtlich der eigenen Anwendungen auf dem Server optimieren und dann anpreisen?

[..]

so liese es sich sicherlich noch ein wenig "übersichtlicher" gestalten oder?

Das Ruleset von mir ist schon so "generell" wie möglich gehalten, so das keine anwendungsspeziefischen Rules mehr drin sind. Und im allgemeinen Decken diese dann auch die anwendungsspeziefischen Rules ab, welches unter Umstände zu false positives führen kann. Deshalb auch das "experimentell" zwischen den Worten.

[derfalk]

ok, das ist ne Antwort wo ich mit leben kann ;) Mich "verblüffte" nur, das die Rules von z.B. Gotroot so tierisch lang sind und deine so kompackt ;)

[sledge0303]

ok, das ist ne Antwort wo ich mit leben kann ;) Mich "verblüffte" nur, das die Rules von z.B. Gotroot so tierisch lang sind und deine so kompackt ;)

Das kompakte Ruleset von caput richtet sich in erster Linie gegen alle gängigen Angriffsversuche auf einen Rootserver. Wenn man sich damit näher beschäftigen will/soll, muss man auch die Aktivitäten der Gegenseite beobachten, sich die Rootkits ziehen und analysieren.

Sicherer ist es eigentlich noch, wenn der Webserver in einem Käfig landet, dann kann so schnell erstmal nicht das gesamte System kompromitiert werden. Du musst dich erstmal "nur" um den Käfig und dessen Inhalte (Skripte) kümmern.
Was aber nicht heissen soll das keine Schäden entstehen können...

[buddaaa]

a)gotroot

mahlzeit,

erstmal vorneweg: ich wuerde mod_security nicht einsetzen, solange man keine potentiel unsicheren PHP- oder CGI-applikationen auf der kiste hat. ansonsten halte ich das risiko durch einen buffer-overflow in mod_security selber verwundbar zu werden fuer groesser als den nutzen.

das original-pack von gotroot hat bei mir ein paar probleme gemacht:

1. die badips.conf ist nicht terminiert, d.h. wenn 1.2.3.4 als boese in der liste ist, wird 1.2.3.45 auch ausgesperrt. hab das auch schon an gotroot gemailt, hat aber keinen gejuckt. hab dann einfach die liste konvertiert mit etwas perl:

Code: Select all

#!/usr/bin/perl

# convert gotroot.com badips.conf to include ^ and $
# 20060623,ar

# SecFilterSelective REMOTE_ADDR "69.28.242.87"
# SecFilterSelective REMOTE_ADDR 198.161.192.9

while(<>) {
        s/^(SecFilterSelective REMOTE_ADDR )"{0,1}(d{1,3}\.d{1,3}\.d{1,3}\.d{1,3})"{0,1}/$1^$2$/;
        print;
}

aufrufen mit "convert.pl < badips.conf > badips_converted.conf" und dann entsprechend badips_converted.conf in der apache-config einbinden.

2. das plesk-horde konnte keine mails mehr weiterleiten, korrektur in rules.conf 2 zeilen auskommentiert und einmail "webmail" dazu

Code: Select all

# diff rules.conf /tmp/apache2/rules.conf
< #SecFilterSelective REQUEST_METHOD "!^(GET|HEAD|POST|PUT|PROPFIND|OPTIONS)$" "chain,id:340001,rev:1,severity:2,msg:'Restricted HTTP function'"
< #SecFilterSelective HTTP_Content-Type "!(^$|^application/x-www-form-urlencoded$|^multipart/form-data)"
---
> SecFilterSelective REQUEST_METHOD "!^(GET|HEAD|POST|PUT|PROPFIND|OPTIONS)$" "chain,id:340001,rev:1,severity:2,msg:'Restricted HTTP function'"
> SecFilterSelective HTTP_Content-Type "!(^$|^application/x-www-form-urlencoded$|^multipart/form-data)"
179c179
< SecFilterSelective REQUEST_URI "!(/webmail|tiki-objectpermissions|aardvarkts/install/index|/gallery/do_command|banner_click|wp-login|tiki-view_cache|/horde/index|/horde/services/go|/goto|gallery2?/main|ad-?server/adjs)" "chain,id:300018,rev:1,severity:2,msg:'Generic PHP code injection protection'"
---
> SecFilterSelective REQUEST_URI "!(/tiki-objectpermissions|aardvarkts/install/index|/gallery/do_command|banner_click|wp-login|tiki-view_cache|/horde/index|/horde/services/go|/goto|gallery2?/main|ad-?server/adjs)" "chain,id:300018,rev:1,severity:2,msg:'Generic PHP code injection protection'"