Debian Etch - ispCP (VHCS Omega)

[schnere]

Hallo!

Mein Server wurde wie hier im Forum zu lesen leider gehackt.
Nun muss ich ihn neu aufsetzen.

Auf dem alten Server hatte ich VHCS2 Spartacus und Ubuntu 6.06 laufen.
Aus persönlichen Gründen möchte ich weiterhin auf den "VHCS2-Nachfolger"
VHCS Omega setzen.
Das Betriebssystem soll in Zukunft Debian Etch sein.

Nun wollte ich fragen, ob ihr mir einige Tipps geben könntet:
1)Sicherheit am Server (iptables, munin (monitoring), ...)
2)PHP4/PHP5 gemeinsam - fastcgi mit VHCS OMEGA
3) Sicherheit PHP4/5 als fastcgi (safe-mode, etc)
4) Sicherheit Apache2
5) Tipps zu VHCS OMEGA
6) Mail-Server Sicherheit, Begrenzung Mailspace, Squirrelmail,...

zu Pkt 6: Hatte für Postfix einen Patch installiert, um den Mailspace zu begrenzen -> durfte keine updates über apt mehr machen.

7) apt oder make?
--habe bisher fast alles über apt installiert (auch apache), da ich dachte, dass ich alle security-patches einfacht mit apt-get update... installieren kann und das möglichst stabil ist.
Soll ich alles vl. doch besser selber kompilieren? Die Server-Performance hat ausgreicht mit apt. Bin ich auch sicherer, wenn ich selber kompilier?


Ich erwarte jetzt nicht, dass ihr mir alle Fragen gleich beantwortet.
Wollte hier nur mal fragen, was ihr mir an Tipps geben könnt. Die Fragen sollen nur eine Richtung vorgeben...

Bin für jede Hilfe dankbar!

MfG schnere

[daemotron]

Soll ich alles vl. doch besser selber kompilieren? Die Server-Performance hat ausgreicht mit apt. Bin ich auch sicherer, wenn ich selber kompilier?

2 Mal klares Nein. Es geht dabei nicht so sehr ums kompilieren ansich als vielmehr ums umgehen des Paketmanagements der Distribution. Solange Du Pakete verwendest, erhälst Du automatisch alle bereitgestellten Security Fixes (vorausgesetzt, Du bemühst die Update-Funktion regelmäßig) - bei selbstgebauter Software bist Du auf Dich allein gestellt. Mögen am Anfang die Vorsätze noch so gut sein, aber wenn man dann drei Tage hintereinander PHP neu kompiliert hat, weil 2 Mal am Tag ein Security Fix rauströpfelte, dann hat der Spaß ein Ende (und Deine Zeit vermutlich irgendwann auch).

Selber bauen ist nur dann eine Option, wenn die benötigte Software in keinem seriösen und gut gepflegten Repository als Paket bereitgestellt wird. Wenn Du in Größenordnungen selbst kompilieren müsstest, weil die Distribution Pakete entweder gar nicht oder nur mit unpassender Konfiguration bereitstellt (z. B. Postfix mit LDAP), lohnt IMHO ein Blick auf auch andere Distributionen, die die geünschten Pakete eben mitbringen oder zumindest Eingriffe in die Paketkonfiguration erlauben (z. B. Gentoo).

Sicherheit am Server (iptables, munin (monitoring), ...)

iptables ist meist reine Zeit- und Ressourcenvergeudung (siehe z. B. Sinn und Unsinn von Firewalls) - wichtiger ist ein gutes Sicherheitskonzept und vor allem eine gut gepflegte und aktuell gehaltene Software-Auswahl.

PHP als FastCGI einzubinden ist schon mal ein guter Ansatz (noch besser wäre es, auf PHP zu verzichten *SCNR* => siehe z. B. Pretty Hard to Protect im Blog unseres Captain) - wichtig ist, dass Du für jeden virtuellen Host dann auch einen eigenen Benutzer anlegst, unter dem PHP läuft. Sicherer wird's dann noch, wenn Du die PHP-Prozesse in eine chroot-Umgebung sperrst und einen Kernel-Patch wie GRSecurity einsetzt, um selbige entsprechend ausbruchsicher zu machen.

Am wichtigsten jedoch: herausfinden, wie der Eindringling überhaupt auf Deinen Server gelangt ist. Sonst ist am Ende vielleicht alles toll abgesichert, aber die eine Lücke (vielleicht in einer Webanwendung) besteht immer noch und lädt weitere ungebetene Gäste ein...

[schnere]

aus den logs konnte ich derzeit zumindest herauslesen, dass er sich über den user nobody irgendwie einloggen konnte und mit su an root-rechte kam.
Bin aber noch beim Durchsuchen der Logs...

[daemotron]

In den meisten Distributionen hat nobody eine Shell, weil es eine Art Allzweck-User ist für Dinge, die eben unprivilegiert laufen sollen. Dafür sollte aber zumindest Login für diesen User deaktiviert sein, und im Prinzip kannst Du ihm auch die Shell wegnehmen. Außerdem gehört es sich, für jeden laufenden Dienst einen eigenen User (ohne Shell und mit gesperrtem Login) anzulegen. Für User, die über SSH auf den Server zugreifen dürfen sollen, eine besondere Gruppe einrichten (z. B. sshusers o. ä.) und diese per AllowGroups <Gruppenname> in der /etc/ssh/sshd_config explizit für den Login via SSH freizuschalten. Anregungen zur sicheren Konfiguration von SSH gibt es z. B. hier...

Ein erfolgreicher Angriff über SSH, der zur Erlangung von root-Rechten führt, ist aber selbst bei nobody mit Shell eher die Ausnahme. Ich vermute daher, dass ein Dienst (vielleicht Apache mit mod_php?) als User nobody ausgeführt wurde und dieser über eine Schwachstelle als Eintrittskarte für den Angreifer gedient hat (z. B. per PHP Header Injection eine remote shell auf den Server geladen und ausgeführt...) Also mal das Apache-Log nach wget oder curl durchgreppen - vielleicht liefert das einen ersten Anhaltspunkt.