Habe ich alles bedacht?

[evilox]

Hallo,

ich wollte mal nachfragen ob ich alles bisher bedacht habe oder ob ich noch große Lücken auf meinem System habe.

OS: Ubuntu Server 8.04

Als Dienste laufen im Moment
- Apache2
- PHP5
- MySQL (allerdings nur via localhost)
- vsftpd
- postfix
- dovecot

Meine Maßnahmen bisher waren
- Root für ssh entfernt
- ssh nur noch via Public-Key Authentifizierung
- automatisch Updates um 0.00
- automatisch Backup von den Nutzerdaten um 0.00 auf einen externen FTP

Wo habe ich jetzt noch größere Lücken? Was kann mir da passieren? Und vor allem wie verhindere ich die ;)

[Roger Wilco]

- Sichere Passwörter für alle Benutzer und alle Dienste (es gibt nicht nur SSH...)
- Keine unsicheren Skripte, die genutzt werden könnten um Shellzugang zu erhalten oder den Versand von beliebigen E-Mails erlauben
- Sinnvolle Postfix Konfiguration
- SSL/TLS-Verbindungen wo möglich, so dass Daten nicht im Klartext übertragen werden
- MySQL-Rechte für einzelne Benutzer sinnvoll gesetzt
- Ungenutzte Apache Module entfernt und die, die benötigt werden sinnvoll konfiguriert (mod_proxy...)
- PHP mit Suhosin gehärtet
- Skripte werden im Kontext des Besitzers ausgeführt, nicht immer im gleichen Kontext (etwa wwwrun/www-data)
- Saubere Benutzertrennung auf Dateisystemberechtigungsebene
- Möglichkeit des Restore überprüft (Backup anlegen reicht nicht)
- Plan für den Fall einer Systemkompromittierung
- usw.
- usw.

Da gibts also noch einiges zu tun und die Liste ist bei weitem nicht vollständig.

[evilox]

Sichere Passwörter für alle Benutzer und alle Dienste (es gibt nicht nur SSH...)
-> soweit in meiner Hand, habe ich das, FTP Zugänge der einzelnen User sind ins chroot eingesperrt.

Keine unsicheren Skripte, die genutzt werden könnten um Shellzugang zu erhalten oder den Versand von beliebigen E-Mails erlauben
-> PMA in der aktuellen Version, User-Skripte könnten da eventuell noch laufen... Kann ich da was machen?

Sinnvolle Postfix Konfiguration
-> Sollte eigentlich der Fall sein

SSL/TLS-Verbindungen wo möglich, so dass Daten nicht im Klartext übertragen werden
-> Meinerseits immer, allerding wieder User z.T. nicht

MySQL-Rechte für einzelne Benutzer sinnvoll gesetzt
-> Jeder User bekommt einen User mit Zugriff auf nur seine DB

Ungenutzte Apache Module entfernt und die, die benötigt werden sinnvoll konfiguriert (mod_proxy...)
-> gleich nur das nötigste installiert

PHP mit Suhosin gehärtet
-> Was ist das und wo bekomme ich das?

Skripte werden im Kontext des Besitzers ausgeführt, nicht immer im gleichen Kontext (etwa wwwrun/www-data)
-> Für was für Skripte gilt das?

Saubere Benutzertrennung auf Dateisystemberechtigungsebene
-> Auch okay

Möglichkeit des Restore überprüft (Backup anlegen reicht nicht)
-> Restore? Für welchen Fall

Plan für den Fall einer Systemkompromittierung
-> System neu aufsetzten ;)

[EdRoxter]

PHP mit Suhosin gehärtet
-> Was ist das und wo bekomme ich das?

Google ist dein Freund. Ein Patch/Modul für PHP, der diverse Sicherheitseinstellungen möglich macht. Ich weiß nicht aus dem Kopf, ob es den im Ubuntu-Repository gibt (bei Debian heißt es php5-suhosin), im Zweifelsfall selbst kompilieren und in der php.ini einbinden.

Skripte werden im Kontext des Besitzers ausgeführt, nicht immer im gleichen Kontext (etwa wwwrun/www-data)
-> Für was für Skripte gilt das?

Insb. PHP und Perl, sprich, suphp und suexec sind die Schlagworte.

[evilox]

Dankeschön schonmal, da werde ich mich jetzt mal schleunigst auf die Suche machen ;)

[wgot]

Hallo,

automatisch Updates um 0.00

besser regelmäßig von Hand updaten. Bei einem Update kann es auch mal passieren, daß danach ein Dienst oder im Extremfall der ganze Server nicht mehr läuft. Beim manuellen Update sitzt man davor falls was schiefgeht.

-> Restore? Für welchen Fall

Für den Fall, daß Du das Backup brauchst. :roll:

Gut überlegen, was das für Situationen sein könnten (Hackereinbruch, zerschossen durch Update, Hardwaredefekt, auf der Konsole dumm vertippt usw) und wie Du dann effektiv die Daten bzw den ganzen Server restaurierst. Falls Kunden bzw Mitbenutzer auf dem Server sind könnten diese erwarten, daß Du eine Restoremöglichkeit hast falls der Nutzer seine Daten zerstört hat (über FTP gelöscht, mit selbstgeschiebenem Script gekillt). Dabei auch an die Datenbankinhalte denken.

Gruß, Wolfgang

[evilox]

... besser regelmäßig von Hand updaten...

Okay, dann werd ich das mal lieber per Hand machen, 24h ist ein guter Rhytmus?

... Gut überlegen, was das für Situationen sein könnten (Hackereinbruch, zerschossen durch Update, Hardwaredefekt, auf der Konsole dumm vertippt usw) und wie Du dann effektiv die Daten bzw den ganzen Server restaurierst. Falls Kunden bzw Mitbenutzer auf dem Server sind könnten diese erwarten, daß Du eine Restoremöglichkeit hast falls der Nutzer seine Daten zerstört hat (über FTP gelöscht, mit selbstgeschiebenem Script gekillt). Dabei auch an die Datenbankinhalte denken...

Gut da werde ich mir auch nochmal was überlegen, MySQL Dump und Kopie des DocumentRoot wird schon alle 12h auf einen externen FTP gemacht.

Danke für die Hilfe

[wgot]

Hallo,

24h ist ein guter Rhytmus?

sooo viele Sicherheitslücken haben Linuxsysteme nicht. :-D
Einmal die Woche sollte genügen wenn Du Dich zusätzlich über aktuelle Sicherheitsprobleme informierst. Bei wirklich kritischen Lücken kann 23h warten schon zu viel sein (solche Probleme sind aber selten).

MySQL Dump und Kopie des DocumentRoot wird schon alle 12h auf einen externen FTP gemacht.

Das ist schonmal viel wert, aber wenn ein Hacker den Server knackt (Rootzugang) hat er auch die Zugangsdaten zum Backupspace und könnte dort Manipulationen vornehmen.

Gruß, Wolfgang

[evilox]

Okay, dann bin ich ja beruhigt :)

Als Quelle für Sicherheitsprobleme bin ich auf der Mailingliste des BSI und lese milw0rm sowie packetstormsecurity, das sollte reichen, oder?

Gut, dann werde ich mir noch eine schöne Offline Alternative für das Backup überlegen.

[Roger Wilco]

-> PMA in der aktuellen Version, User-Skripte könnten da eventuell noch laufen... Kann ich da was machen?

Das bereits erwähnte Suhosin nutzen, eventuell (nicht immer sinnvoll) mod_security2 und ggf. einen Sendmail-Wrapper installieren, so dass havarierende Skripte schnell entdeckt werden.

SSL/TLS-Verbindungen wo möglich, so dass Daten nicht im Klartext übertragen werden
-> Meinerseits immer, allerding wieder User z.T. nicht

Das kann man bei vielen Diensten forcieren, z. B. Verbindungen zu IMAP-/POP3-Server und SMTP-Server nur via TLS, Verwaltungsoberflächen nur via HTTPS usw.

Okay, dann werd ich das mal lieber per Hand machen, 24h ist ein guter Rhytmus?

Es ist nicht so, dass in einem festen 24 Stunden-Zyklus neue kritische Updates vorhanden sind. Da kann auch mal 3 Wochen lang nichts kritisches kommen. Wenn die da sind, solltest du allerdings möglichst schnell die Folgen evaluieren und dann aktualisieren. Damit du das nicht verschläfst, solltest du dich bei den üblichen Mailinglisten (Security-Liste deiner Distribution, div. CERTs, evtl. Bugtraq) anmelden oder diese z. B. über GMANE im Auge behalten.

[evilox]

Das bereits erwähnte Suhosin nutzen, eventuell (nicht immer sinnvoll) mod_security2 und ggf. einen Sendmail-Wrapper installieren, so dass havarierende Skripte schnell entdeckt werden.

Suhosin ist bereits aktiv, genauso wie der safe_mode von PHP. Nach mod_security2 und einem sendmail-wrapper schaue ich gleich mal

Das kann man bei vielen Diensten forcieren, z. B. Verbindungen zu IMAP-/POP3-Server und SMTP-Server nur via TLS, Verwaltungsoberflächen nur via HTTPS usw.

Gut, da werde ich auch mal nach schauen.

Es ist nicht so, dass in einem festen 24 Stunden-Zyklus neue kritische Updates vorhanden sind. Da kann auch mal 3 Wochen lang nichts kritisches kommen. Wenn die da sind, solltest du allerdings möglichst schnell die Folgen evaluieren und dann aktualisieren. Damit du das nicht verschläfst, solltest du dich bei den üblichen Mailinglisten (Security-Liste deiner Distribution, div. CERTs, evtl. Bugtraq) anmelden oder diese z. B. über GMANE im Auge behalten.

Ja wie eben oben schon geschrieben.. ;)

[unerkannt]

…, MySQL Dump und Kopie des DocumentRoot wird schon alle 12h auf einen externen FTP gemacht.

Backup vielleicht nicht per FTP von A nach B schieben - sondern von B per rsync von A abholen.
Beim Einbruch in A ist so kein direkter zugriff auf das Backup möglich, da in den FTP-Backup-Scripten ja prinzipbedingt auch die FTP-Zugangsdaten enthalten sind - diese Gefahrenquelle wird dadurch ausgeschlossen, dass B die daten bei A abholt, ohne dass auf A daten über B hinterlegt sein müssen …

[daemotron]

Dafür braucht man aber "Infrastruktur", die die meisten Server-Vermieter nicht bieten. Im eigenen Netzwerk oder bei Einsatz mehrerer Server ist eine Agent-basierte Lösung wie Amanda natürlich schick (und IMHO etwas professioneller als rsync), aber dazu brauchst Du erst mal einen zweiten Server mit entsprechender Netzanbindung (ADSL ist keine Lösung, da dauert ein Full Restore ja mehrere Tage) und genügend Frei-Traffic.

Für einen hobbymäßig betriebenen Server muss die Lösung mit FTP beim Provider herhalten, ggf. ab und zu (z. B. einmal wöchentlich) die Backups auf eine lokale Maschine übertragen. Wer Server professionell einsetzt, sollte sowieso entweder auf Housing umsteigen oder zumindest mehrere Server anmieten (Stichwort: Hot Standby) und auch das Geld für eine eigene Backup-Kiste lockermachen.