Härtungsmaßnahmen für Linuxserver – Teil 1

Server-Härtungen mögen nicht zu den beliebtesten Aufgaben gehören, da sie eine gewisse Planung und Durchführung voraussetzen und uns in der Bedinung unter Umständen ein wenig Komfort rauben. Dennoch sollte ein gewisses Mindestmaß an Sicherheit eingehalten werden um die Angriffsfläche möglichst gering zu halten.
Es folgen ein paar Basics, die eure Maschine zwar nicht gänzlich vor Angriffen immunisieren, jedoch eine gewisse Grundlage bieten soll. Die Schritte in vorliegendem Beitrag wurden auf einem Ubuntu-Server durchgeführt.

Minimale Installation auswählen

Ein recht simpler und doch wirkungsvoller Tipp, ist die Auswahl einer Installation mit möglichst minimaler Softwareausstattung. Bereits während der Installationsroutine wird man um die Erlaubnis der zu installierenden Pakete gebeten. Haltet diese Liste so klein wie möglich und so groß wie nötig und installiert ausschließlich Dienste, für die auch der Server vorgesehen ist. Installiert im Zweifel erstmal keine weitere Software und holt dies hinterher erst nach.
Ist das Kind nämlich einmal in den Brunnen gefallen und ein All-inklusive Wohlfühl-Server aufgesetzt, ist es Schwerstarbeit bis nahezu unmöglich die überschüssige Software wieder los zu werden. Ein ungewünschter Rest bleibt dabei immer irgendwie übrig.

Je weniger auf eurem Server installiert ist, desto weniger Angriffsfläche bietet die Maschine.

Regelmäßig Updates einspielen

Regelmäßige Updates sind nicht nur wichtig um die Systemstabilität zu verbessern, veraltete Features rauszukegeln oder neue hinzuzufügen, sondern primär auch um mögliche Sicherheitslücken zu schließen.
Einspielen lassen sich Updates folgendermaßen:

### Aktualisiert den Paket-Cache
sudo apt-get update
### Aktualisiert bereits installierte Pakete
sudo apt-get upgrade (Aktualisiert bereits installierte Pakete)
### Aktualisiert bereits installierte Pakete, löst dabei Abhängigkeiten auf und installiert u.U. neue oder entfernt alte
sudo apt-get dist-upgrade

Für automatische Updates wird uns ein Programm behilfich sein:

sudo apt-get install unattended-upgrades

Führt anschließend folgenden Befehl aus:

dpkg-reconfigure unattended-upgrade

und wählt in der folgenden Maske „Yes“ aus.
Das wars.

Zwei zusätzliche Dinge möchte ich an dieser Stelle ergänzen:
Verwendet möglichst wenig PPAs. PPAs (oder auch: Personal Package Archive) sind, wie der Name bereits vermuten lässt, selbst erstellte Paketarchive. Für ihre Sicherheit bei Verwendung kann euch in erster Linie niemand garantieren. Wie sehr ihnen vertraut werden kann liegt primär in den Fragen, wer diese erstellt hat und wie oft sie aktualisiert werden, bzw. wann sie das letzte Mal aktualisiert worden sind!? Ein PPA für die Firefox Beta vom Mozilla Team wäre in aller Regel beispielsweise vertrauenswürdiger als ein PPA von mir. ;- )

Außerdem solltet ihr nicht auf Pakete oder Paketquellen zurückgreifen, die für eine ältere OS-Version vorgesehen sind. Dies würde nicht nur eure Systemstabilität z.B. hinsichtlich fehlender Abhängigkeiten beeinträchtigen, sondern das daraus installierte Programm auch irgendwann an einer gewissen Version hängenbleiben, die nicht mehr aktualisiert werden kann.

root Login verbieten

Ein direkter Login als root mag zwar bequem sein, verspricht aber weniger Sicherheit als den Umweg über einen privilegierten Benutzer zu suchen, der sich über sudo als root anmelden darf. Auf einigen Distributionen ist diese Sicherheitsmaßnahme bereits von Haus auf aktiv. Es kann allerdings nicht schaden, dies nochmal zu überprüfen.
Damit wir uns nicht selbst den Ast (oder besser gesagt den “root”) absägen, auf dem wir uns derzeit befinden (und wir den root-Login ohne Vorsorge abschalten), sorgen wir für einen entsprechend berechtigten Benutzer für unser sudo-Vorhaben. Schaut zunächst nach ob bei euch ein Benutzer eingerichtet ist, der Mitglied der „sudo“ Gruppe ist. Ihr könnt dies mit dem Befehl …

### Fügt hier euren jeweiligen Benutzer ein
groups itadministrator

herausfinden. Habt ihr keinen gefunden oder wollt einen anderen der sudo Gruppe hinzufügen, könnt ihr dies folgendermaßen erledigen:

sudo usermod -aG sudo itadministrator

Ihr könnt ihn alternativ auch in die „sudoers“ eintragen:

sudo echo 'itadministrator ALL=(ALL) ALL' >> /etc/sudoers

Nach einem relog des neu hinzugefügten Benutzers, kann er dann auch schon sein neues sudo-Dasein ausleben.
Nun kümmern wir uns um den SSH-Dienst. Hierzu bearbeiten wir die Datei /etc/ssh/sshd_config und ergänzen die Zeile „PermitRootLogin“ mit folgendem Wert

nano /etc/ssh/sshd_config

### und folgende Option setzen
PermitRootLogin prohibit-password

Diese Option verbietet direkte root-Anmeldungen mit Passwort. Möchte man auch sämtliche andere Anmeldungen als root (beispielsweise über SSH-Key) deaktivieren, setzt man die Option auf:

PermitRootLogin no

Anschließend wird der SSH-Dienst einmal neugestartet und der direkte root-Login unterbunden.

systemctl restart ssh

SSH Login verbieten

Passwörter können geknackt werden. Wer nun einen Schritt weiter gehen möchte, verbietet gleich komplett den SSH-Login und verwendet anstelle dessen SSH-Keys. Diese müssen natürlich zuvor erstellt werden. Auf dem System, welches sich auf den Server verbinden soll, erstellen wir uns also ein Public-Private Key Pärchen:

ssh-keygen -f ~/.ssh/id_rsa

Im darauffolgenden Passwort-Eingabeprompt legt ihr (bei Bedarf) ein Passwort fest.
Es wurden nun im Home-Verzeichnis des angemeldeten Benutzers ein SSH-Key Schlüsselpaar (~/.ssh/id_rsa = private und ~/.ssh/id_rsa.pub = public) erzeugt. Den Public-Key können wir mit der Welt (oder auch mit unseren Clients) teilen, den Private-Key sollten wir tunlichst nicht vom Fleck bewegen oder laut vorlesen.

Und so kommt der Public-Key auf die Zielmaschine:

ssh-copy-id -i ~/.ssh/id_rsa.pub root@<Ziel-Server>

Dummerweise erlauben einige Linux-Distributionen standardmäßig keine direkten root-Logins, denn genau diesem User müssen wir den Public-Key geben. Wenn nichts hilft, kopiert euch einfach dessen Inhalt auf die Zielmaschine in die Datei:

/root/.ssh/authorized_keys

Legt sie an, falls die Datei nicht vorhanden ist und sorgt dafür, dass nur der Benutzer root Besitzer von ihr ist und darauf zugreifen darf:

sudo mkdir -p /root/.ssh/ sudo chown root:root /root/.ssh/authorized_keys sudo chmod 400 /root/.ssh/authorized_keys

Testen können wir die Verbindung nun von unserer Maschine (die das Schlüsselpaar erstellt hat) mit dem Benutzer (mit dem dies getan wurde) auf den Server (auf dem wir den Public-Key abgelegt haben).

ssh root@<Ziel-Server>

Nun sollte nurnoch der fingerprint bestätigt werden. Falls ein Passwort für das Schlüsselpaar festgelegt worden ist, muss dieses nun auch eingegeben werden.
Ihr solltet als root angemeldet sein!

Da wir uns eine Möglichkeit gebastelt haben, auch ohne Passwort-Eingabe auf den Server zu gelangen, können wir nun eben diesen Passwort-Login abschalten. Hierzu gehen wir auf dem Ziel-Server in die SSH Hauptkonfig-Datei und setzen 2 Einträge:

sudo nano /etc/ssh/sshd_config

Sucht folgende 4 Einträge, kommentiert sie ein und setzt ihre Option auf no

ChallengeResponseAuthentication no
UsePAM no
PermitRootLogin no
PasswordAuthentication no

Abschließend muss der SSH-Dienst neu gestartet werden:

sudo service ssh restart

Bevor ihr euch nun von der Maschine ausloggt, testet den Zugang bitte noch einmal aus. Falls euch irgendein Fehler unterlaufen sein sollte, seid ihr von der Maschine u.U. komplett ausgesperrt!

Firewall einschalten

DIE Härtungsmaßnahme schlechthin stellt die Firewall dar. Also sollten wir auch Gebrauch von ihr machen. Uns zur Verfügung steht u.a. die ufw (oder auch uncomplicated firewall), die ein sehr einfach zu bedienendes Frontend hat. Wir installieren es mit

sudo apt install ufw

Der Befehl …

ufw status

… gibt uns Aufschluss darüber, ob die Firewall aktiv oder inaktiv ist.
Bevor wir diese nun aktiv schalten, schauen wir uns zunächst die aktiven Dienste auf unserem Server an, um sie versehentlich nicht abzuschalten (z.B. unser SSH-Zugriff):

sudo netstat –tulpn

Falls ihr an dieser Stelle auf, für euch unbekannte, Ports stoßt, sucht im Internet nach ihrer Funktion und erwägt, ob ihr den Dienst dahinter überhaupt benötigt. Interessant für uns ist der Port der Reihe „Local Address“. Unsere Dienste geben wir nun in der Firewall frei und starten sie anschließend:

### Für z.B. den SSH-Dienst
sudo ufw allow 22
sudo ufw enable

Wir werden darauf aufmerksam gemacht, dass unsere SSH-Verbindung wegknallen könnte. Da wir jedoch vorgesorgt haben, können wir ohne weiteres mit „y“ bestätigen. Die Firewall ist nun aktiv!
Der Status der Firewall kann wieder mit …

sudo ufw status

… abgefragt werden.

Damit hätten wir die Grundvoraussetzungen geschaffen, und unseren Linux-Server einigermaßen sicher gemacht. Dieser Leitfaden galt lediglich als Einführung in die Linux-Härtung und soll absolut keinen Anspruch auf Vollständigkeit erheben.