Grundlagen der Serversicherheit

Eine der täglichen Aufgaben eines Administrators ist die Absicherung der von ihm betreuten Server.In meinem Fall handelt es sich hauptsächlich um Server auf Linux-Basis, meist Debian, die abgesichert werden müssen.Ich möchte heute einen kleinen Einblick in die Grundlagen der Serversicherheit geben – das hier soll kein Tutorial sein und erhebt keinen Anspruch auf Vollständigkeit!Root-Zugriff auf ein System bringt große Verantwortung mit sich – hat der root-User doch immer alle Zugriffsrechte auf ein System, es wäre also schlecht, wenn ein Unbefugter sich als root-User anmelden könnte.

Ich nutze zwar auch privat fast nur Linux-Distributionen, man kann einen Linux-Server aber auch problemlos mit einem Windows-Client administrieren – z.B. mit mRemoteNG.

Unbedingt sollte man seinem eigenen PC nicht blind vertrauen und ihn bestmöglich absichern – darunter fallen neben den regelmäßigen Updates von Betriebssystem und eingesetzter Software auch der Einsatz von Firewalls und Antivirus-Produkten.

Man bekommt dem Zugangsdaten des neuen Root-Servers vom Hoster bereitgestellt und ist voller Tatendrang, dem Server seine Aufgaben zu verpassen – immer langsam!

Zuerst ändert man immer das Passwort, denn immerhin wurde es unverschlüsselt und für jeden lesbar per E-Mail versendet. Nach der Änderung des Passworts in ein ausreichend komplexes Kennwort updaten wir den Server noch und installieren somit die aktuellsten Pakete.

Aaah, ein frisches und aktuelles Debian-System, dass nur darauf wartet, in Betrieb genommen zu werden – ein schönes Gefühl.

Doch… möchten wir dauerhaft mir root-Rechten arbeiten? Nein! Wir legen also einen neuen User für die tägliche Arbeit an und vergeben ihm ein Passwort – wie man diesen User nennt ist letztlich egal, ich kann aber empfehlen, sich an ein Schema zu halten, beispielsweise immer im Schema „dpratt“ oder „prattd“. Das macht die Sache später wesentlich übersichtlicher.

Ob man die Deaktivierung des Logins mit einem Passwort als sinnvoll erachtet, muss jeder für sich entscheiden. Ich bin der Meinung, sofern das Passwort ausreichend komplex ist und man eine Software wie denyhosts oder fail2ban einsetzt, kann man den Passwortlogin ruhig aktiviert lassen – bequemer ist dennoch der Login per Key.

Hat man sich gegen den Login mit einem Passwort entschieden, kann man noch ein paar Optionen in der Konfiguration des SSH-Server setzen bzw. ändern:

Den Root-Login sollte man natürlich erst deaktivieren, sobald man sichergestellt hat, dass der Login mit dem eigenen User funktioniert!

Um Brute-Force-Angriffe, also das Ausprobieren vieler verschiedener Passwörter nacheinander, zu erkennen und zu blockieren, sollte man die oben schon erwähnte Software fail2ban nutzen.

In der Debian-Standardkonfiguration ist fail2ban schon so konfiguriert, dass Angriffe auf den SSH-Dienst erkannt und gebannt werden – und mehr als einen SSH-Server haben wir auf dem Server ja noch nicht installiert…

Man kann außerdem den Port des SSH-Server verlegen, was das allgemeine Grundrauschen in den Logs erheblich reduziert!

Was viele leider im Rahmen der Serverabsicherung vergessen ist eigentlich ziemlich wichtig: der Client-PC!

Meldet man sich an seinem Root-Server von einem PC aus an, der nicht als vertrauenswürdig eingestuft werden kann, gilt für mich der Root-Server als kompromittiert.

Das gilt leider auch für den Login per SSH-Key, sofern ihr diesen auf nicht vertrauenswürdigen Rechnern verwendet.

Als nicht vertrauenswürdig zähle ich übrigens jeden PC, der nicht komplett unter meiner Kontrolle steht – von Internetcafés über Büro-PCs bis hin zu Laptops von Freunden und Bekannten; man weiß einfach nicht, wie der PC konfiguriert ist und ob er ordentlich abgesichert ist.

Dafür habe ich mir ein Zweithandy zugelegt, dass nur für SSH-Logins genutzt wird. Auf diesem Handy ist wirklich nur ein SSH-Client installiert und eine Datenkarte mit günstigem Tarif eingelegt – letztere findet man z.B. bei DeinHandy, mit und ohne Handy.

Dadurch bin ich auch mobil in der Lage, plötzlich auftretende, kleinere Probleme zu lösen.

Hat man die oben genannten Punkte beachtet und geht bewusst mit seinen Zugangsdaten um, hat man die ersten Schritte in Richtung eigenen Server schon hinter sich.

Ein Administrator haftet für den Server, den er betreut – es sollte also selbstverständlich sein, sich in das Thema einzuarbeiten und die gelernten Dinge ein- und umzusetzen.

Die Sicherheit eines Root-Servers ist außerdem kein einmaliger, sondern ein fortlaufender Prozess; Updates, Updates, Updates!

Natürlich kann man einen Server auch komplett abschotten – man sollte aber ganz dringend an ein gutes Verhältnis von Sicherheit, Administrierbarkeit und Kosten im Auge behalten – es hilft einem Kunden nicht, wenn ich ihm für einen Homeserver eine Firewall für mehrere 10.000 Euro ans Herz lege…