Linux Server Sicherheitskonzept

Moin alle miteinander!

So, mein Server läuft jetzt seit ner weile so wie er soll, ich prüfe die Logs regelmäßig, mache Backups und alles.

Ich stelle mir allerdings immer wieder die Frage, ob das, was ich mache, an Sicherheit vorerst ausreicht. Also nicht zum System nie wieder anfassen! Das Sicherheit ein Prozess und kein Status ist ist mir klar.

Nun, auf meiner Maschine läuft Debian 6 Squeeze (Sollte ich auf Debian 7 updaten? Gerade läuft alles stabil..)

Das einzige, was eigentlich nach außen für andere angeboten wird, ist ein Minecraft Server. Sonst laufen noch lighttpd (Nur um PHP my Admin zu betreiben) und ssh.

Der MySQL Server ist nicht aus dem Netz zu erreichen.

Sowohl MySQL, lighttpd als auch Minecraft liegen in einem eigenen OpenVZ Container.

Meine nächste Idee wäre, ssh und lighttpd nur noch per VPN zugänglich zu machen.

Damit passt meiner Meinung nach die äußere Sicherheit. Wie sieht es allerdings im System selbst aus? Was sollte ich umbedingt tun? SELinux? Bestimmte Verzeichnisse ro mounten? Sonst irgendetwas?

Ja, ich gebe mir echt Mühe mit der Sache, denn auf einen gelungenen Angriff habe ich keine Lust.

Gruß,
Cayton.

PHPMyAdmin hat auf Produktiv-Systemen nichts verloren. Verwalte deine MySQL mittels MySQL-Client auf der Konsole, oder setze dir lokal ein PHPMyAdmin auf deinem Arbeitsrechner auf und verbinde dies mittels SSH-Tunnel zu deiner MySQL auf dem Server.

Was du unbedingt tun solltest:
1. Alle tmp-Verzeichnisse (z.B. auch jene, die PHP als Temp-Dirs nutzt) mit noexec-Flag mounten. Setzt natürlich voraus, dass sie auf einer extra Partition liegen.
2. Regelmässig Rootkit-Checks laufen lassen (z.B. rkhunter oder chkrootkit).
3. Überwachen ob Dateien im System verändert wurden (z.B. AIDE oder Tripwire).
4. Ein HIDS aufsetzen (ich empfehle OSSEC).
5. Ggf. ein NIDS aufsetzen und nur validen Traffic durchlassen (ich setze zumeist auf Snort).
6. Die Debian-Security-Guidelines befolgen: Securing Debian Manual
7. Log-Files mit Append-Flag ausstatten und dieses explizit nur vor den Logrotates entfernen und danach sofort wieder setzen.
8. Alle Dateien, die sich niemals ändern dürfen, mittels Immutable-Bit vor Änderungen schützen (z.B. Server- und PHP-Konfigurationen u.ä.).
9. Sicherstellen, das nur dein Shell-User und root eine valide Shell in der passwd-Datei stehen haben.
10. Den SSH-Server so konfigurieren, dass ein Login via Passwort und als root nicht mehr möglich ist. Keyfiles für den Login verwenden.

Ich denke das sollte das Gröbste gewesen sein.

Edit: Ganz vergessen. Tools wie wget, curl, lynx, w3m, ncftp, ftp usw. die für HTTP- oder FTP-Zugriffe via Terminal gedacht sind, umbenennen. Wenn sie in irgendwelchen Skripten verwendet werden, dann diese entsprechend anpassen.

Security through obscurity? Wirklich? Ich verstehe schon, warum du wget und so ein Zeug umbenennen willst. Nur bekommt man da nicht gröbere Probleme, weil ja auch die halben Skripte im System sich darauf verlassen, das wget halt eben wget ist? Und, als noch viel wichtigerer Grund: The enemy knows the system!?

mfg benediktibk

Das hat mit Obscurity nichts zu tun. Gerade über PHP eingeschleuste Skripte laden ihren Schadcode zumeist über wget & Co nach. Selbiges tun die meisten Botnets, wenn sie aktuelle Exploits zum Kapern von Rechnern einsetzen. Da diese Angriffe durch Botnets vollkommen automatisiert erfolgen, kann man bei >80% der Bot-Eindringlinge damit schlimmeres verhindern. Und es gibt verdammt wenig System-Skripte, die auf wget setzen. Diese mal zu modifizieren ist weitaus geringerer Aufwand als einen Bot zu entfernen.

Nachtrag: Bitmuncher | Warum Security by Obscurity manchmal doch sinnvoll ist <- *klick* Ich hab meine Meinung diesbezüglich mal schnell zusammengefasst.

Also ich finde es ist vorallem wichtig sich über die Angriffsflächen die ein Server bietet Gedanken zu machen. Denn lieber sollte man einen Angriff direkt verhindern, als dass man ihn hinterher entdecken muss.

Bei Diensten immer zweimal überlegen ob man die wirklich braucht. Auf FTP kann und sollte man beispielsweise verzichten, einen NTP Server braucht man i.d.R. nicht und auch auf inetd/xinetd sollte man verzichten.

Wenn man für den privaten oder administrativen Zweck einen Webservice hosten möchte, würde ich den prinzipiell per HTTP Authentication absichern, so schützt man sich vor Bots die bekannte Sicherheitlücken in Webdiensten ausnutzen.

Einen echten Sicherheitsgeweinn bekommt man wohl indem man verschiedene Dienste getrennt voneinander virtualisiert.

Allgemein kann man glaub ich sagen, dass man immer wissen sollte was und warum man tut. Denn Dinge die man nicht Einschätzen/Überblicken kann sind immer potenziell unsicher, denn nur wenn ich Risiken erkenne kann ich abwägen und ggf. handeln.

Zusätzlich dazu sind natürlich die Ratschläge von Bitmuncher auch alle sinnvoll

xblax hat gesagt.:

Denn Dinge die man nicht Einschätzen/Überblicken kann sind immer potenziell unsicher, denn nur wenn ich Risiken erkenne kann ich abwägen und ggf. handeln.

Zum Vergrößern anklicken....

Die meisten Admins kennen die aktuelle Bedrohungslage im Netz unzureichend bis gar nicht. Daher lieber per Default etwas mehr absichern und damit auch einen grundlegenden Schutz gegen 0-Days haben, als sich nur auf die Absicherung der Dienste zu verlassen. Gerade Linux leistet sich auch gern mal Sicherheitslücken im Kernel und/oder in Treibern. Da reicht dann manchmal schon die falsche Netzwerkkarte im Server um Angriffsflächen zu bieten. Auch das machen sich viele Admins nicht bewusst und verzichten daher auf ein HIDS. Imo sollte ein Server daher auch immer so vorbereitet sein, dass ein erfolgreicher Angriff nachvollziehbar ist. Sonst kann man die Lücke, die ausgenutzt wurde, nicht effektiv schliessen.

Joa, erstmal danke für die Tipps!

@bitmuncher:

1. Alle tmp-Verzeichnisse (z.B. auch jene, die PHP als Temp-Dirs nutzt) mit noexec-Flag mounten. Setzt natürlich voraus, dass sie auf einer extra Partition liegen.

Zum Vergrößern anklicken....

Macht Sinn!
Nur: Meine OpenVZ Container haben ja auch das /tmp Verzeichnis. Wie setze ich da ein noexec Flag? Muss ich im Host das /tmp mit Flag mounten? gilt noexec dann auch im Container?

2. Regelmässig Rootkit-Checks laufen lassen (z.B. rkhunter oder chkrootkit).

Zum Vergrößern anklicken....

Jo, mach ich.

3. Überwachen ob Dateien im System verändert wurden (z.B. AIDE oder Tripwire).

Zum Vergrößern anklicken....

Keine verkehrte Idee. Welche Dateien sollten überwacht werden? Wie filtere ich interessante von uninteressanten Ausgaben?

4. Ein HIDS aufsetzen (ich empfehle OSSEC).

Zum Vergrößern anklicken....

Werde ich mich einlesen, klingt interessant!

5. Ggf. ein NIDS aufsetzen und nur validen Traffic durchlassen (ich setze zumeist auf Snort).

Zum Vergrößern anklicken....

Werde ich mich einlesen.

6. Die Debian-Security-Guidelines befolgen: Securing Debian Manual

Zum Vergrößern anklicken....

Sind die nicht veraltet? Ich sehe mir sie auf jeden Fall an.

7. Log-Files mit Append-Flag ausstatten und dieses explizit nur vor den Logrotates entfernen und danach sofort wieder setzen.

Zum Vergrößern anklicken....

Warum auch nicht. Zusätzlich könnte ich einen zweiten Server die Logs empfangen lassen, als Schutz vor Manipulation (Mit nem Raspberry PI und Dynamic DNS)

8. Alle Dateien, die sich niemals ändern dürfen, mittels Immutable-Bit vor Änderungen schützen (z.B. Server- und PHP-Konfigurationen u.ä.).

Zum Vergrößern anklicken....

Macht auch Sinn, wird gemacht.

9. Sicherstellen, das nur dein Shell-User und root eine valide Shell in der passwd-Datei stehen haben.

Zum Vergrößern anklicken....

Wird umgehend überprüft.

10. Den SSH-Server so konfigurieren, dass ein Login via Passwort und als root nicht mehr möglich ist. Keyfiles für den Login verwenden.

Zum Vergrößern anklicken....

Ist schon.

Tools wie wget, curl, lynx, w3m, ncftp, ftp usw. die für HTTP- oder FTP-Zugriffe via Terminal gedacht sind, umbenennen. Wenn sie in irgendwelchen Skripten verwendet werden, dann diese entsprechend anpassen.

Zum Vergrößern anklicken....

Puuh, wird davon irgendwas im System verwendet, wo es durch das Umbenennen zu Komplikationen kommen kann? Darf ich einen alias mit dem alten Namen in meine .bash_aliases setzen, oder nicht?

PHPMyAdmin hat auf Produktiv-Systemen nichts verloren.

Zum Vergrößern anklicken....

Warum? Ich meine, wenn du das sagst, will ich das mal glauben. Werde also voraussichtlich den Webserver komplett abschalten. Warum interessiert mich trotzdem

@xblax:
Auch danke für deine Hilfe Die Anzahl der Dienste ist absolut minimal, und es sind alle Dienste getrennt virtualisiert

Cayton hat gesagt.:

Warum? Ich meine, wenn du das sagst, will ich das mal glauben. Werde also voraussichtlich den Webserver komplett abschalten. Warum interessiert mich trotzdem

Zum Vergrößern anklicken....

phpmyadmin ist in der Vergangenheit leider immer wieder wegen kritischer Sicherheitslücken aufgefallen.
Im Gegensatz dazu braucht man phpmyadmin selbst aber nicht zum Betrieb des Servers (weil es ja nur ein Webinterface ist).

Das Risiko, sich dadurch (unnötigerweise) Sicherheitslücken ins System zu schaffen, steht also in keinem Verhältnis zum dazugewonnen Komfort.

kaputtnik hat gesagt.:

Das Risiko, sich dadurch (unnötigerweise) Sicherheitslücken ins System zu schaffen, steht also in keinem Verhältnis zum dazugewonnen Komfort.

Zum Vergrößern anklicken....

*signed*

Wenn auf einem Server eh ein SSH-Server läuft, dann kann man PHPMyAdmin auch problemlos auf einem anderen Webserver installieren, den man sich z.B. auf seine lokale Workstation packt. Oder man nutzt gleich einen grafischen Client wie Sequel Pro o.ä.. Die Verbindung baut man dann einfach via SSH-Tunnel auf.

Welche Dateien sollten überwacht werden? Wie filtere ich interessante von uninteressanten Ausgaben?

Zum Vergrößern anklicken....

In erster Linie alle Systemdateien. Diese dürfen sich nur bei Updates ändern. Ausgeschlossen sind natürlich die Daten in /var, da diese sich häufig ändern ('var' steht nicht umsonst für 'variable') können. Da darf man natürlich nicht vergessen nach einem Update die Checksummen zu aktualisieren, damit man keine False-Positives bekommt.

Sind die nicht veraltet?

Zum Vergrößern anklicken....

Grundlegende Tipps veralten nicht so schnell.

Puuh, wird davon irgendwas im System verwendet, wo es durch das Umbenennen zu Komplikationen kommen kann? Darf ich einen alias mit dem alten Namen in meine .bash_aliases setzen, oder nicht?

Zum Vergrößern anklicken....

Meiner Erfahrung nach nutzen Systemskripte diese Tools nicht, da nur wenige System-Skripte Verbindungen nach aussen aufbauen. Bei Backup-Tools wie reobackup u.ä. muss man halt darauf achten, dass man in denen die umbenannte Binary verdrahtet.

Edit: Zur .bash_profile... Wenn dein Account infiziert wird, wird auch deine Shell-Konfiguration geladen. Überleg's dir also lieber, ob du dir da Aliases setzen willst.

Wenn es unbedingt ein Webinterface zur Datenbank geben soll würde ich mal Adminer als als phpMyAdmin-Alternative in den Raum werfen. Deutlich schlanker, single-file, mit gefühlt mehr Features und vor allem nicht jeder Woche einem Remote-Exploit. Ich würde das trotzdem genau überlegen ob man einen Webserver und php mit dreiundzwölfig libs nur wegen sowas wirklich braucht oder ob man sich mal eine Stunde in die mysql-shell einarbeiten möchte.

Sich in die MySQL Shell einarbeiten? Muss ich nicht, ist schon geschehen
Trotzdem verwende ich solche Sachen gerne als Werkzeug, ist doch relativ komfortabel

Ich denke, ich werde ab jetzt ein offline Administrationstool über VPN verwenden.

Gruß,
Cayton

@bitmuncher: zu deinen Punkten:

3. Überwachen ob Dateien im System verändert wurden (z.B. AIDE oder Tripwire).
4. Ein HIDS aufsetzen (ich empfehle OSSEC).

Zum Vergrößern anklicken....

OSSEC überwacht von Haus aus auch die Systemdateien. Benötigt man dann überhaupt nocht AIDE oder Tripwire oder benutzt du verschiedene Programme für die jeweiligen Aufgaben, da du evt. bessere Erfahrungen mit AIDE/ Tripwire gemacht hast?

Wie würdest du OSSEC dann noch zusätzlich konfigurieren?

Wenn man mit OSSEC mehr als nur die Systemdateien überwachen will und lieber mit einer Exclude- als einer Include-Liste arbeitet, wird es irgendwann inperformant. Ausserdem bietet gerade Tripwire bessere Möglichkeiten um auch die Konfiguration für Angreifer unmanipulierbar zu machen. OSSEC umgeht das lediglich indem es seine eigene Config überwacht und bei Bedarf an einen zentralen Server meldet, wenn da was geändert wird. Tripwire hingegen verschlüsselt die Config, so dass sie gar nicht erst sinnvoll manipulierbar ist.

Sonst hängt die OSSEC-Konfiguration natürlich davon ab, was für Dienste auf dem Rechner laufen und welchen Gefährdungsarten der Server ausgesetzt ist. Sind z.B. viele User via Shell o.ä. drauf, sollte man Regeln einpflegen die melden, wenn ein User aus einer ungewöhnlichen IP-Range connected oder ausführbare Dateien anlegt oder oder oder... Läuft eine Webapp, könnte man z.B. überwachen, dass zwischen Webapp und DB-Server nur valide Anfragen ausgetauscht werden, die die Webapp auch beinhaltet. usw. usf.

Es gibt kein allgemeingültiges Sicherheitskonzept. Es gibt nur grundlegende Features, die jedes Sicherheitskonzept beinhalten sollte. Die einzelne Umsetzung ist aber immer vom Server und seinem Netzwerk abhängig und von diversen anderen Punkten wie Wirtschaftlichkeit oder auch simplen Dingen wie "Sind Zertifikate auf dem Rechner abgelegt, die besonders geschützt werden müssen?" o.ä.