Shared Hosting und Sicherheit

[learnLinux]

Hallo,

was würdet ihr empfehlen um bei Shared Hosting (Webspace, Mysql, Mail, ftp usw.) trotzdem noch ein wenig Sicherheit hinzubekommen.

Bisher habe ich folgende PHP Einstellungen:
safe mode off (mit on gibt es leider zu viele Probleme)
aber weil ich safe mode off habe, sind folgende Funktionen gesperrt:

exec,system,passthru,shell_exec,shell,ini_restore,show_source,popen,escapeshellcmd,proc_open,proc_nice

Noch irgendwelche Tipps die man aufjedenfall beachten sollte?

 

[Lord Gurke]

Du solltest in den vHosts-Konfigurationen mit php_admin_value das "open_basedir" auf das Hauptverzeichnis des Benutzers/Hostings festlegen.
Sonst könnte der User mit PHP auf dem Dateisystem des Servers rumsuchen und zum Teil sogar Daten anderer Kunden verändern.

php_admin_value open_basedir /www/verzeichnis/des/users/

Das muss natürlich für jeden vHost angepasst werden, sonst kann der Benutzer ja garnicht in seinem eigenen Verzeichnis arbeiten

Daneben solltest du dem Apache natürlich noch beibringen, auf garkeinen Fall irgendwelche Daten über sich selbst preis zu geben, wie z.B. Version, geladene Module (und deren Versionen) etc...

In der apache2.conf geht das unter "ServerTokens" (sollte Prod sein) und "ServerSignature" (sollte Off sein).
Das sollte man aber generell jedem Serverdienst beibringen, dient einfach der Sicherheit.

Du solltest aber nichts desto trotz mit der Materie lapidar gesprochen "auf Du und Du" sein, sonst nützt das alles nicht viel.

 

[Roger Wilco]

Du solltest in den vHosts-Konfigurationen mit php_admin_value das "open_basedir" auf das Hauptverzeichnis des Benutzers/Hostings festlegen.

mod_php und Shared Hosting sind ein No Go. Informiere dich über SuExec, SuPHP usw.

Idealerweise werden die Skriptsprachen-Interpreter in einer chroot-Umgebung eingesperrt und/oder durch Erweiterungen wie AppArmor, SELinux, grsecurity oder RSBAC daran gehindert, zuviel Schabernack zu treiben.

In der apache2.conf geht das unter "ServerTokens" (sollte Prod sein) und "ServerSignature" (sollte Off sein).
Das sollte man aber generell jedem Serverdienst beibringen, dient einfach der Sicherheit.

Inwiefern dient das der Sicherheit? Das ist für die "Hacker", die auch ihre Haustüre ohne Namensschild nicht mehr finden würden...

 

[learnLinux]

mod_php und Shared Hosting sind ein No Go. Informiere dich über SuExec, SuPHP usw.

Problem bei suphp usw. ist, dass die Ladezeiten und Performance darunter leiten. Außerdem bringt es mir dann nichts wenn ich per Confixx nicht mal verschiedene Einstellungen vornehemen kann die per php admin value verwendet werden.

Ich habe hier eher an mod_php + mod_itk gedacht, was schneller und von der Sicherheit auch in Ordnung sein soll.

 

[Whistler]

Wenn man schon "security by obscurity" will, dann kann man auch gleich zur Irreführung eine ältere Versionsnummer nennen.
Man sollte aber ganz sicher sein, daß die dortigen Bugs in der aktuellen Version nicht mehr vorhanden sind.

 

[Roger Wilco]

Problem bei suphp usw. ist, dass die Ladezeiten und Performance darunter leiten.

Jein. Die Startzeit ist bei reinen CGI-Lösungen länger, als wenn der Interpreter gleich im Webserver-Prozess sitzt. Die Performance - also die reine Ausführungszeit der Skripte - ist allerdings identisch (Opcode Caches mal ausgenommen). Mit FastCGI lässt sich auch das Problem mit der Startzeit lösen.

Ich habe hier eher an mod_php + mod_itk gedacht, was schneller und von der Sicherheit auch in Ordnung sein soll.

MPM-itk ist eben "experimentell". Bleibt die Frage, wie sich das unter Last verhält.

 

[learnLinux]

MPM-itk ist eben "experimentell". Bleibt die Frage, wie sich das unter Last verhält.

Ich werde erstmal mpm-itk verwenden und dann werde ich ja sehe wie es läuft.
Ansonsten habe ich über mpm-itk bisher nur gutes gehört (von der Performance).

Ist sonst noch was zu beachten?