RootForum Community

Hallo,

ich hab mich die letzten Tage mit security rund um eine shared hosting Umgebung beschäftigt und es soll ein kleines manual werden. Dinge mit denen ich mich bis jetzt beschäftigt habe.

1. mod_security

* Simple filtering
* Regular Expression based filtering
* URL Encoding Validation
* Unicode Encoding Validation
* Auditing
* Null byte attack prevention
* Upload memory limits
* Server identity masking
* Built in Chroot support
* And more

Rules: http://www.gotroot.com/tiki-index.php?p ... rity+rules


2. suphp
"suPHP is a tool for executing PHP scripts with the permissions of their owners. It consists of an Apache module (mod_suphp) and a setuid root binary (suphp) that is called by the Apache module to change the uid of the process executing the PHP interpreter."

3. Die wichtigsten Sicherheitsoptionen in der php.ini

register_globals = off verhindert, dass Variablenzuweisungen in HTTP-Anfragen und Cookies globale Programmvariablen überschreiben. Diese Option zwingt Skripte dazu, vom Anwenderseite übermittelte Variablen über gesonderte Arrays wie $_REQUEST bewusst abzuholen. Ein Angreifer kann es dadurch nicht mehr ohne Weiteres ausnutzen, falls ein Skript uninitialisierte Variablen verwendet oder leichtfertig von bestimmten globalen Vorbelegungen ausgeht.

allow_url_fopen = off sorgt dafür, dass PHP-Skripte nur lokale Dateien des Servers einbinden können. Dies ist eine besondere Hürde für viele Angriffstypen, da keine Skripte mehr direkt von externen Servern nachgeladen werden können.

safe-mode = on bewirkt unter anderem, dass der PHP-Prozess nur noch auf Dateien und Verzeichnisse zugreifen darf, die dem Nutzer gehören, mit dessen Rechten der PHP-Prozess läuft. Auf Linux-Servern ist dies meist www-data beziehungsweise beim Einsatz von Apache-Modulen wie mod_suexec [8] oder suPHP der Skriptbesitzer. Außerdem sperrt der Safe-Mode in seiner Default-Einstellung gefährliche Funktionen wie shell_exec(), doch sein Verhalten lässt sich durch weitere Optionen steuern [9].

open_basedir = /pfad/zum/www-ordner legt ein Verzeichnis fest, außerhalb dessen PHP-Skripte keine Dateien öffnen können - ähnlich einer chroot-Umgebung. Der Zugriff auf enthaltene Unterordner ist natürlich gestattet, doch das direkte Auslesen beispielsweise von /etc/passwd und anderen vertraulichen Daten außerhalb des WWW-Root durch Path Traversal ist damit nicht mehr möglich.

display_errors = off erschwert unter Umständen die Vorbereitung eines Angriffs. Für einige Attacken ist es beispielsweise nötig, dass der Dateisystempfad zur Webapplikation bekannt ist. Diese Information lässt sich unter anderem vielen PHP-Fehlermeldungen entnehmen. Die Option verhindert, dass Angreifer gezielt Fehlermeldungen provozieren können.
(bei shared hosting nicht wirklich sinnvoll)

quelle: http://www.heise.de/security/artikel/84149/4#kasten2


4. remote logfiles

so bleiben bei einem kompromitiertem system noch logfiles auf einem anderem Server.

5.1 rkhunter als cron

Dieses script als cron für rkhunter:
#!/bin/sh
echo "Subject: SERVERNAME rootkit detector" > rkreport
echo "" >>rkreport
/usr/local/bin/rkhunter --versioncheck >> rkreport
/usr/local/bin/rkhunter --update >> rkreport
/usr/local/bin/rkhunter --cronjob --report-warnings-only >> rkreport
sendmail your@email.com < rkreport

INSTALL rkhunter

5.2 chrootkit als cron

#!/bin/sh
cd /pfad/zu/chkrootkit/
./chkrootkit | /usr/bin/mail -s 'chkrootkit Täglicher Check SERVER' ich@mail.de

6. snort intrusion detection

7. monitors (hab ich noch keine Entscheidung getroffen)
* Angel Network Monitor
* Autostatus
* Big Brother
* Big Sister
* HiWAyS
* MARS
* Mon
* Netup (French)
* NocMonitor
* NodeWatch
* Penemo
* PIKT
* RITW
* Scotty
* Spong
* Sysmon

8. Zugang zum system

8.1 ssh pubkey-Authentifizierung
8.2 IP-tables

9. Backup

Dieses manual für rsync ist denke ich ganz ok. Rsync ist ein Netzwerkprotokoll welches beim synchronisieren nur die Dateien überträgt die seit dem letzten backup verändert wurden. Dies spart enorm Bandbreite.

10. update des systems

ich nehme in diesem thread Änderungen vor und es folgt ein Fragenkatalog...

So und dann gleich mal ein paar Fragen:

mod_security bietet eine chroot Umgebung. Ist das dann nicht ein bisschen die selbe Idee wie suphp und safemode= off in der php-ini?

Wenn ich chroot richtig verstanden habe wird für jeden Benutzer ein "neues" root Verzeichnis erstellt was dem home directory des users entspricht. Ein jail/ Gefängnis was den Zugriff auf alles unterhalb des home directory verbietet.

Frage: Welche Probleme sind zu erwarten bei joomla, moodle und dem ganzen schnickschnack?

Ist dann safe-mode=on in der php-ini überflüssig?

suphp lässt php-scripte mit den rechten des Besitzers laufen. Welche Vorteile hat das?



Und der obige thread wird erweitert durch ein paar Dinge die ich vergessen habe.

Safemode sind relativ überflüssig weil er ein paar nützliche, wenn auch nicht wirklich sichere, Funktionen deaktiviert oder einschränkt. Beispielsweise: Ist man direkt auf ImageMagic angewiesen und die Applikation unterstützt kein GD, hat man schlechte Karten. Dann muss der arme Admin wieder für den vhost eine safemode_exec_dir anlegen und ImageMagic darin verlinken oder sogar reinkopieren (manchmal funktionieren Links nicht).

furl_open kann man machen, du solltest vorher allerdings Suhosin installieren und eine Whitelist erstellen.

register_globals auf off ist ok, sollte keine Applikation mehr brauchen. Fehler anzeigen ist allerdings nicht sinnlos wenn du Kunden hast, die installieren gerne mal Software die nicht läuft und fragen sich dann wegen fehlenden Ausgaben warum. OpenBasdir gehört schon zum guten Ton ;)

Logserver wenn möglich immer machen, dann müsste der Angreifer den Syslog mit zuviel Information überfluten um sich in deinen Logs etwas aus der Miesere zu ziehen. Ich verwende dazu gerne Syslog-NG.

Mod_Securitys Chroots sind eigentlich was eigenes, der Prozess des Users ist eingesperrt und darf nicht raus, sprich höher ins Dateisystem springen. suPHP/suExec ist anders, damit ändere ich nur den User und die Gruppe der dieses Script ausführt. Normalerweise laufen die Scripte mit dem Webserver User, bei Debian www-data, mit suPHP kann man sie dann als Rechteloser User aus der Datenbank ausführen. Diese zu Chrooten wäre mit Mod_Sec einfacher als mit anderen Methoden. Allerdings benötigt jeder Vhost ein eigenes Mod_Sec Setup bzw. die Einstellungen die für das Chroot zuständig ist, hält sich aber eigentlich in Grenzen.

Snort und Iptables spar ich mir mittlerweile weil es einfach zuviel des guten wäre. Auf einer Bridge wäre Snort Inline vielleicht nützlich, für ein Webserver ist es allerdings übertrieben. Mal davon abgesehen das gerade wegen solchen Programmen der Server mit einem DOS ausser gefecht gesetzt werden kann oder man gezielt die Programme abschiesst. Man verlässt sich zuviel darauf und meint nicht mehr nachsehen zu müssen. Das erhöhen der Codebase ist auch nie eine gute Idee, immer sowenig Sachen wie möglich laufen haben.

rkhunter und chkrootkit mit Cron durchlaufen lassen macht glaub ich jeder.
chkrootkit läuft bei mir immer mit einem cron.daily Script durch:
und rkhunter
Fürs Monitoring würd ich dir Monit oder MRTG empfehlen, Nagios wäre übertrieben.

Wichtig an allem ist aber nicht wie das du Programme zum Prüfen eingerichtet hast, du musst auch deine Dienste richtig einrichten und up-to-date halten. Die Programme sind nur zusätzliche Hindernisse. Im Forum gibt es noch mehr dazu, z.b. /tmp sicher mounten, Dienste einrichten oder einfach nur das System mit Fingerprints (Hashes) prüfen, dafür eignet sich Samhain oder Tripwire.

Kernel Härten ist auch ein Punkt den du durchführen solltest. GRSec ist dafür ein recht einfaches System im vergleich zu den anderen. Wichtig ist eigentlich auh das durch ein Stackschutz hast und damit nicht jeder Kochbuch Shellcode läuft. Kein root Zugang für den Angreifer, bessere Karten für dich.

Automatisch Updaten solltest du allerdings nicht, das führt öfter zu Problemen als du denkst, sei es ein Dienst der nicht mehr hochkommt etc.

Wenn du alleine auf dem Server bist, vergiss nie deine Webapplikationen auf dem neusten Stand zu halten, und wenn es nur phpmyadmin ist.

p.s. solltest du doch ein IDS/IPS haben wollen, nimm Prelude. Das kommt auch mit den VRT Regeln klar und du sparst dir Hostbasiernde IDS Tools wie Samhain oder Tripwire.

So, viel Spaß beim Suchen im Forum, eigentlich war alles schonmal da.

Dank dir... Ich passe morgen alles nochmal an... Ich hab auch beschlossen, dass es besser ist um alles an output von rkhunter und chkrootkit in eine file wegzuschreiben dann kann man mehrere server in eine file wegschreiben. Irgendwann bekommt man so viele mails, dass man die doch nicht mehr liest...

Volkan

Noch eine Anmerkung zu Chroot-Jails: chroot() ist ein syscall des Linux-Kernels, der für einen Prozess den Mountpoint für / auf eine beliebige Stelle im Dateisystem legen kann. Problem: die Original-Implementierung aus dem Vanilla-Kernel war nie als Sicherheitsfeature konzipiert, sondern eher für Entwickler, die mehrere Userland-Bereiche auf einer Maschine haben wollten. Ergo ist es auch nicht gerade schwer, aus einem solchen chroot auszubrechen (auf manchen Systemen genügt schon ein chroot ../ auf der Root-Ebene im Jail).

Wesentlich ausbruchssicherer als chroot-Umgebungen sind para-virtualisierte Linux-Instanzen mit eigenem Kernel (wie z. B. Xen-DomU's). Wer den Aufwand nicht treiben will oder kann, hat immer noch die Möglichkeit, den gemeinen chroot-Syscall durch Kernel-Patches etwas zu frisieren. Das bereits angesprochene GRSecurity verhindert z. B. das Absetzen eines chroot-Calls aus einer chroot-Umgebung heraus. Zusammen mit einigen weiteren Restriktionen macht es ein chroot-Jail ziemlich ausbruchssicher.

Was GRSecurity aber nicht verhindern kann, ist dass ein innerhalb eines chroots Amok laufender Prozess alle Systemressourcen auffrisst und den gesamten Server lähmt. RSBAC, ebenfalls ein Härtungspatch (mit entsprechenden Userland-Tools) leistet aber genau das. Neben granularer Rechtevergabe für Prozesse über Mandatory Access Control beherrscht RSBAC auch die Ressourcenbeschränkung für Jails (RSBAC ersetzt damit das klassische chroot). Neben Speicher und CPU-Zeit lässt sich auch der Zugriff auf einzelne Geräte und sogar virtuelle Netzwerk-Interfaces steuern.

Während diese Themen aber die absolute Kür nach der Pflicht sind, vermisse ich in Deinem Ansatz so Basis-Themen wie Berechtigungskonzept, Backup- und Update-Strategie, Umgang mit Releasewechseln und Remote-Zugriff für Webhosting-Kunden (es gibt sicherere Protokolle als FTP - z. B. sftp in Kombination mit der rssh). IMHO ist auch PHP via FastCGI anstelle von suPHP eine erwähnenswerte Alternative (schon allein wegen der besseren Performance).

jfreund wrote: Während diese Themen aber die absolute Kür nach der Pflicht sind, vermisse ich in Deinem Ansatz so Basis-Themen wie Berechtigungskonzept, Backup- und Update-Strategie, Umgang mit Releasewechseln und Remote-Zugriff für Webhosting-Kunden (es gibt sicherere Protokolle als FTP - z. B. sftp in Kombination mit der rssh). IMHO ist auch PHP via FastCGI anstelle von suPHP eine erwähnenswerte Alternative (schon allein wegen der besseren Performance).

Stimmt, muss ich dir recht geben. Ein ordentlicher Backup Plan ist Pflicht. Bei einem Zwischenfall ist es unabdingbar so schnell wie möglich ein Sauberes System zu bekommen oder einfach ein funktionierendes einzuspielen. Allerdings ist das wieder Providerabhängig. Einige Provider haben in der Rescue Console rsync, dann wird das relativ einfach, andere nicht, wie bekomme ich dann in der Rescue meine Daten wieder? Ramdisk laden, System in die Ramdisk installieren mit rsync? Ich nutz für meine paar Dedi Server nur rsync, alles andere wäre der Überkill. Allerdings weiß ich von einem Provider das er rsync in der Rescure nicht hat.

PHP mit FCGI ist vielleicht noch ein guter Ansatz, das er allerdings schneller als suPHP ist kann ich nicht sagen, nutze nur Lighttpd ;) Was vielleicht auch ein besserer Ansatz wäre LH per default in /srv/www/ zu chrooten und jeden Vhost mittels FCGI und eingesperrt auszuführen, damit sollte auch erfolgreicher Hack auch ziemlich schwierig sein da keine Programme wie wget und co. zur Verfügung stehen. Da im April sowisso eine Debian Neuinstallation ansteht (nach 3 Distributions Upgrades will ich mal wieder ein sauberes System haben von Grundauf), werd ich das vielleicht mal zum Spaß machen, spart man sich eigentlich gleich schon wieder etwas Ressourcen.

Wegen deinem Angesprochenen Thema mit SFTP: Erklär mal ein Kunden, der gerade mal weiß wie er Smartftp starten kann und Datei rüberschieben, wie er ein etwas komplexeres Programm wie WinSCP und Co. bedienen soll, ich hab aufgegeben. Jetzt ist vielleicht der FTP Ersatz in Form von WebDAV im Auge, das läuft eigentlich nativ unter jedem aktuellen OS und von Grundauf besser als FTP. Selbst mit Tools wie SysCP sollte das ja klappen wenn man die "FTP Nutzer" verwendet.

Hat jemand eigentlich mal ein direkten vergleich gemacht mit GRSec und RSBAC? Ich meine, die Prozess Limits kann ich auch mit den Linuxeigenen Limits festlegen, wenn es nur das ist, dürfte sich der Umstieg ja nicht lohnen oder?

Lord_Pinhead wrote:PHP mit FCGI ist vielleicht noch ein guter Ansatz, das er allerdings schneller als suPHP ist kann ich nicht sagen, nutze nur Lighttpd ;)

SuPHP ist prinzipbedingt langsamer (CGI <-> FastCGI).

Lord_Pinhead wrote:Was vielleicht auch ein besserer Ansatz wäre LH per default in /srv/www/ zu chrooten und jeden Vhost mittels FCGI und eingesperrt auszuführen

Es reicht aus, die FastCGI-Prozesse einzusperren. Der lighttpd kann ruhig ohne chroot weiterlaufen.

Lord_Pinhead wrote:Wegen deinem Angesprochenen Thema mit SFTP: Erklär mal ein Kunden, der gerade mal weiß wie er Smartftp starten kann und Datei rüberschieben, wie er ein etwas komplexeres Programm wie WinSCP und Co. bedienen soll, ich hab aufgegeben.

Viele FTP-Clients unterstützen inzwischen nativ SFTP, etwa Filezilla, Wise-FTP, PSFTP und CuteFTP Pro.

Lord_Pinhead wrote:Hat jemand eigentlich mal ein direkten vergleich gemacht mit GRSec und RSBAC?

Was willst du großartig vergleichen? GrSecurity und RSBAC sind 2 verschiedene Paar Schuhe. GrSecurity mit RBAC ist ähnlich wie RSBAC, letzteres ist aber detaillierter.

Roger Wilco wrote:Was willst du großartig vergleichen? GrSecurity und RSBAC sind 2 verschiedene Paar Schuhe. GrSecurity mit RBAC ist ähnlich wie RSBAC, letzteres ist aber detaillierter.

Für mich ist die Entscheidung relativ einfach: Auf einem System ohne Remote Console mach ich lieber keine Experimente mit RSBAC (man kann sich wirklich gründlich damit aussperren - zum Glück war das nur ein Testsystem @home :D)

Ihr seit zu schnell für mich und ich muss heute noch ein paar andere Sachen machen aber kurz:

Punkt 9. Backup: ich poste später eine kurzes manual für rsync auf zwei servern.

- Ist jeder damit einverstanden, dass php-safemode aus darf?
- Ich hab den Titel geändert um es ein bisschen einzuschränken auf das einrichten einer shared hosting Umgebung mit apache, sonst wirds mir doch ein bisschen zu viel... Ich finds selbst schade, da ich in einer testumgebung mit lighttpd angefangen habe zu spielen...
- Zu chroot: In wie weit ist es noch nötig um neben dem chroot von mod_sec noch GRSec zu installieren?
- sftp finde ich bei shared hosting ebenfalls zuviel des guten.
- suphp <-> fast-cgi muss ich erst mehr lesen
- RSBAC wird auch lesen aber klingt echt interessant.
- /tmp sicher mounten konnte dann wieder grsecurity aber muss ich auch erst mehr drüber lesen...
- der rest kommt auch später einmal dran...

Punkt 10. updates: was kann man da groß drüber schreiben ausser das man regelmässig nicht automatisch updates einspielen muss?




Danke, dass ich die nächsten Tage Lektüre habe!

und gleich einen hinterher:

Another common error in these books is that they spread the urban legend that the most dangerous problem within PHP "remote code inclusion vulnerabilities" can be fixed by disabling allow_url_fopen in the configuration (or allow_url_include in PHP 5.2.x). This information is simply wrong, because these configuration directives do NOT protect against attacks through php://input or data:// URLs. Our Suhosin and the former Hardening-Patch are the only available protections that close all URL include attacks.

quelle: http://www.hardened-php.net/suhosin/why.html

suhosin mit dazu? Da ansonsten "allow_url_fopen = off" irgendwie unsinn wäre...

Volkan