Weitere Absicherung des Servers mit mod_security

[nikko]

modsecurity schützt den Apache, ist einem IPS ähnlich und kann einen entdeckten Angriff abwehren (z.B. SQL Injection).
Hier ein Tutorial, um den Webserver mit Keyhelp und Ubuntu 14.04. zusätzlich abzusichern. Anwendung - wie immer - auf eigene Gefahr.
Bevor ein Produktivsystem aufgerüstet wird, wird der Test in einer Testumgebung empfohlen.

1.) Vorbereitung: mod_security arbeitet mit Regeln, so genannte Rules. Diese kann man sich qualvoll selbst erarbeiten oder man nutzt
fertige Regeln. Diese gibt es z.B. von Atomiccorp (kostenpflichtig), OWASP (kostenfrei) oder Comodo (kostenfrei). Ich habe mich für
die Comodos entschieden, da OWASP sehr hart regelt und selbst einfache Webseiten nicht mehr aufrufbar waren. Zudem werden auch schon
Regeln für bekannte Webanwendungen (Wordpress etc.) mitgeliefert.
Hier bitte kostenfrei registrieren https://modsecurity.comodo.com/ und im Anschluß bitte hier https://waf.comodo.com/ die Regeln als Komplettdownload in der neuesten Version downloaden. Diese werden bald benötigt.

2.) Login via Putty (o.a.)
3.) modsecurity installieren, Kommando eingeben und ausführen

Code: Select all

sudo apt-get install libapache2-mod-security2

Anschließend sollte modsecurity aktiviert werden und der Apache neu starten -> weiter mit 4.). Falls nicht, gehts hier weiter...
3a) modsecurity aktivieren

Code: Select all

sudo a2enmod security2

3b) Apache neu starten mit

Code: Select all

sudo service apache2 restart

4.) Zur Sicherheit (sollte eiegentlich schon seit der Keyhelp-Installation aktiv sein) bitte mod_headers aktivieren

Code: Select all

sudo a2enmod headers

5.) Jetzt kann geprüft werden, ob mod_security läuft:

Code: Select all

apache2ctl -M

, das Modul sollte in der Liste auftauchen
6.) Jetzt befindet sich modsecurity im Erkennungsmodus, ohne das aktiv eingegriffen wird. Damit geht es jetzt weiter...
7.) Wir kopieren die Konfiguration, da in Kürze Änderungen vorgenommen werden:

Code: Select all

sudo cp /etc/modsecurity/modsecurity.conf-recommended /etc/modsecurity/modsecurity.conf

8.) Jetzt nutzen wir den midnight commander (ok, es geht auch per Befehlszeile) und starten diesen mit

Code: Select all

mc

, suchen uns anschließend im linken Fenster die Datei modsecurity.conf - diese befindet sich in /etc/modsecurity/ . Und auf der rechten Seite werden die bereits mitinstallierten Regeln gesucht - zu finden unter: /usr/share/modsecurity-crs/
9.) Nun wird IM Verzeichnis /usr/share/modsecurity-crs/ ein neues Verzeichnis erstellt: Also Taste F7 - und bennen dieses mit "comodo_rules", allerdings ohne die Anführungszeichen.
10.) Anschließend ladet ihr die Comodo-Regeln aus 1.) (vorher die Datei bitte entpacken) in das neu erstellte Verzeichnis. Ob ihr dafür FileZilla,
Totalcommander, Win SCP oder was auch immer nutzt, bleibt euch überlassen. Jetzt sollten sich alle Comodo-Regeln im Verzeichnis comodo_rules befinden.
11.) Weiter geht es mit der Bearbeitung der Datei modsecurity.conf (Taste F4). Beim ersten Aufruf wird abgefragt, mit welchem Editor gearbeitet werden soll, da wir bereits nano haben, nutzen wir diesen auch.
12.) Die Zeile

Code: Select all

SecRuleEngine DetectionOnly

(der Erkennungsmodus) wird nun angeschaltet (ersetzt ) mit

Code: Select all

SecRuleEngine On

13.) Unter die Zeile "SecRuleEngine On" fügt ihr bitte folgende 4 Zeilen ein:

Code: Select all

#Include /usr/share/modsecurity-crs/*.conf
#Include /usr/share/modsecurity-crs/base_rules/*.conf
#Include /usr/share/modsecurity-crs/optional_rules/*.conf
Include /usr/share/modsecurity-crs/comodo_rules/*.conf

Dieses sind die Regeln, aktiv wären jetzt nur die Comodo-Rules, der Rest ist mit # inaktiv. Hier ist testen angesagt, mit den Comodo-Rules ist aber schon Schutz vorhanden. Speichern mit Alt+X, Yes, Enter.
14.) Den Apachen neu starten mit

Code: Select all

sudo service apache2 restart

Fertig. Bei Problemen bitte Regeln nachbearbeiten, aus- oder einkommentieren mit # in der modsecurity.conf, notfalls wieder SecRuleEngine auf DetectionOnly setzen. Geloggt wird die Arbeit von modsecurity in /var/log/apache2/modsec_audit.log ,die Datei gibt klare Aufschlüsse darüber, welche Regel angeschlagen hat. Das ist wichtig für die Suche nach Falsch-Positiven Abweisungen (Sperren), also die nicht geschehen sollten.

Abschließend nocht der Livetest:

Code: Select all

https://meinedomain.de/index.php?SELECT%20*%20FROM%20mysql.users

hier bitte auf http oder https achten, der Link zu eurer Keyhelp Oberfläche. https://meinedomain.de/index.php?SELECT ... ysql.users ist eine simulierte SQL Gefahr, dieser Befehl sollte nicht ausführbar sein. Anschließend sollte sich im Logfile (also in /var/log/apache2/modsec_audit.log) ein Eintrag befinden.

[ollidroll]

Vielen Dank. Sehr schöne Anleitung.
Wie setze ich denn eine Whitelist? Für z.B. Piwik?

Danke & Viele Grüße
Olli

[nikko]

Habe ich etwas unter 14.) beschrieben. Im Logfile findet sich, welche Regel angeschlagen hat, wenn etwas nicht mehr aufrufbar ist.
Die Angabe ist so konkret, dass die betreffenden Zeilen in den Regeln mit # auskommentiert werden können.
Im Anschluß den Apachen neu starten.

[ollidroll]

ok, Danke.
Schau ich mir mal genau an, auf den ersten Blick kann ich keine Regeln in der Log Datei erkennen.

Mit dem "Detection Modus" passiert ja erstmal nix, wenn ich das richtig verstehe, oder?
Habe mir ansonsten auch die Files vom comodo geholt.

Alles andere in der modsecurity.conf bleibt auf Standard?
Oder hast Du da auch noch Anpassungstips?

Danke & Viele Grüße
Olli

[nikko]

OK, versuche mal folgende Demonstration: (Detection Only)
Lege im Keyhelp als Admin einen User an, logge dich aus der Adminoberfläche in den User ein (vorher nicht ausloggen), und verpasse dem User von mir aus einen FTP Zugang und ne SQL Tabelle. Danach loggst du dich nicht als User aus, sondern schließt einfach diesen Tab, so dass du gleich wieder Admin bist. Fenster auf lassen, rüber zum SSH.
Binde die Comos ein, schalte von Detection Only auf On, Apache Neustart.
Wenn alles OK sein sollte, dürfte es dir (eigentlich) nicht mehr möglich sein, mit den eingebundenen Regeln im Keyhelp jetzt einen User anzulegen, da dieses einen tiefen Systemeingriff bedeutet, der theoretisch abgewiesen werden muss.
(Danach kannst ja wieder auf Off oder Detection Only schalten.)
Nun sollte sich im audit.log ein Eintrag mit Nummer XXXXXXX-A bis XXXXXXX-Z befinden. Unter XXXXXXX-H sollte sich zeigen, welche Regel ausgeführt wurde, sogar mit welcher Zeilennummer (ggfls hat die Session ID nicht gestimmt, oder Cookie war falsch, etc, etc.) Diese Regel kann nun auskommentiert werden.

Der Rest der conf kann so bleiben. Anpassungstips: Naja. Aus meiner ganz persönlichen Sicht zum Thema Sicherheit kann ich sagen, dass Apache zum Beispiel von Hause aus schon sehr sicher ist.
Die Progammierer von Keyhelp leisten ganze Arbeit (Hut ab, immer wieder) und setzen auf lange bewährte Server-OS. Sie verpassen dem Server eine total schicke und vernünftig zu bedienende Oberfläche - und arbeiten permanent auch an der Sicherheit. So werden SPAM und Antivirus mitinstalliert und sogar apparmor habe ich gefunden, welches auch erheblich zur Sicherheit beiträgt.
Ein mehr an Sicherheit geht immer: Daher meine Beiträge zu modsec, modevasive, fail2ban und ArnosIPTable. Traumhaft könnte es jetzt weitergehen, indem du die IPV4 IPV6 Regeln in Fail2ban aktivierst und statt Arno das mitgelieferte iptable verwendest und beide verknüpfst. Dann könntest du via Cron diverse IP Blacklist laden und diese in die Konfigs von iptable schreiben lassen. Bringt nochmal n ordentlichen Sicherheitsschub. und in der Nacht können dann rkhunter und chkrootkit nach Hacks auf dem Server suchen. Jeder User könnte seine eigene Quota haben und seine persönliche chroot Umgebung bekommen. (Hallo Admins...falls ihr mal nichts zu tun habt.... hier ist Arbeit )
ABER: Nicht jeder hat n leistungsfähigen dedi Server und der Spagat zwischen Administrierbarkeit, Updatebarkeit und Serversicherheit muss geschafft werden. Denn nicht zuletzt passieren die meisten Hacks noch immer über nicht gepflegte Homepages und / oder unsichere Passwörter.

[ollidroll]

Vielen Dank für Deine Ausführungen.
Das mit dem Benutzer anlegen hat funktioniert, das ging dann nicht.
Habe den entsprechende Eintrag im Log auch gefunden und konnte die Regel zuordnen.

Ich bekomme aber auch immer folgende Meldungen und kann daraus keine Regel ableiten ??

--62e60b47-H--
Apache-Error: [file "mod_access_compat.c"] [line 350] [level 3] AH01797: client denied by server configuration: %s%s
Stopwatch: 1464520905356745 1165 (- - -)
Stopwatch2: 1464520905356745 1165; combined=366, p1=280, p2=0, p3=17, p4=42, p5=27, sr=28, sw=0, l=0, gc=0
Response-Body-Transformed: Dechunked
Producer: ModSecurity for Apache/2.7.7 (http://www.modsecurity.org/); CWAF_Apache.
Server: Apache
Engine-Mode: "ENABLED"

Kannst Du mir da ggf. weiterhelfen?
Danke & Viele Grüße
Olli

[nikko]

Hm, kann es sein, dass eine .htaccess Datei hier einen Zugriff geblockt hat? (PS: Ist das ein orginal Keyhelp-System und entstand der Eintrag im Detection oder On Modus?) Weil.... eine Regel direkt ist ja nicht beschrieben.
Dazu müsste man aber auch den gesamten Eintrag von A-Z sehen - sind eigentlich sehr aufschlussreich. Auch mal nach der IP schauen, nicht das lokal etwas geblockt wurde. Step by Step (und prüfen, in welchem Zusammenhang der Eintrag geschrieben wurde) - dann müsste das zu finden sein.

[ollidroll]

Hey Nikko,
Der Eintrag entstand sowohl im "on"- als auch im "Detection Only"-Mode.
Im Moment läuft alles im "Off"-Mode, selbst da wird der Eintrag geschrieben.
Es ist eine Original Keyhelp-Installation auf Ubuntu 14.04.

Ich weiß woher der Eintrag kommt. Es wird hier immer die Server-UpTime von einem SEO-Tool geprüft.
Bei der Wordpress Installation ist ein SEO-Plugin aktiv, das auch Bad Bots vi htaccess ausschließt. Da ist die SEO-Firma bei.
Habe den Eintrag mal entfernt, jetzt ist alles gut.

Vielen Dank für Deine Hilfe und Infos. So langsam komme ich dahinter.

Noch eine Nachfrage:
Ich habe auf meinem Server (mehrere Domains) kein Drupal installiert, trotzdem springt ab und an eine Drupal-Regel an (bei Zugriff auf WordPress Seiten). Sollte ich die Regel dann deaktivieren oder besser behalten...?

Viele Grüße
Olli

[nikko]

Je weniger disabled wird, desto sicherer. Ich disable bei einem Eintrag nicht, erst wenn blockiert wird und es trotzdem benötige.