Absicherung und Grundkonfiguration von Debian 8 (Jessie)

Hier möchte ich euch kurz vorstellen, wie ich mein Debian etwas „abhärte“ und welche Tools ich gerne zur Wartung nutze. Dazu werde ich den Artikel hier auch mal von Zeit zu Zeit updaten, damit er immer halbwegs aktuell bleibt. Zunächst einmal beginne ich immer bei einer frischen Debian Minimalinstallation. Lediglich der SSH-Server ist vorinstalliert, damit ich mich später Remote mit dem System verbinden kann.

Nach dem ersten Login führe ich zunächst einmal ein Update durch. Ist die Installation frisch, sollte alles auf dem aktuellen Stand sein, aber Schaden tut es nicht. Danach installiere ich mir erst mal eine Hand voll Tools:

$ apt-get update && apt-get upgrade
$ apt-get install fail2ban mc htop needrestart ntp screen

Was machen die folgenden Tools? Ganz einfach:

  • fail2ban ist ein Dienst, der vor BruteForce Attacken schützt (aber nur IPv4-Traffic). Nach einer vorher definierten Anzahl an fehlerhaften Login-Versuchen wird die IP eine gewisse Zeit gesperrt
  • mc ist eine grafische Oberfläche für das Dateisystem und ein einfacher Texteditor, den ich recht gerne nutzen und auch hier fast immer verwende
  • htop zeigt die aktuelle System-Auslastung an (CPU/RAM) sowie alle laufende Prozesse
  • needrestart nach einer Aktualisierung zeigt das Tool an, welche Dienste neu gestartet werden müssen, damit die Aktualisierung wirksam wird
  • ntp sorgt dafür, dass eure Uhr immer richtig geht, indem die Zeit online abgeglichen wird. Mehr Informationen zur Einrichtung findet ihr hier
  • screen macht ein „neues“ Terminal auf, das auch erhalten bleibt nachdem man sich z.B. über SSH ab- und wieder anmeldet

mc benötigt keine weitere Konfiguration, bei htop kann man je nach Geschmack noch das Theme bearbeiten und sich alle Prozesse als Baum anzeigen lassen. fail2ban ist standardmäßig so konfiguriert, dass man nach 3 Fehlversuchen innerhalb 10 Minuten für 10 Minuten gesperrt wird. Diese Werte halte ich persönlich für etwas „lasch“ und habe sie daher bei mir etwas angehoben. Dafür müsst ihr einfach nur die /etc/fail2ban/jail.conf bearbeiten:

$ mcedit /etc/fail2ban/jail.conf

Dort findet ihr in der Sektion [DEFAULT] folgende Einträge, die ihr z.B. so anpassen könnt:

bantime = 86400
findtime = 300
maxretry = 5

Dies hat zur Folge, dass eine IP, die sich innerhalb 5 Minuten (findtime = 300) 5 mal mit ungültigen Daten anmeldet (maxretry = 5) für 24 Stunden gesperrt wird (bantime = 86400). Mit dieser Einstellung habe ich bisher recht gute Erfahrungen gemacht. Anschließend müssen wir den Dienst noch neu starten, damit die Änderungen wirksam werden:

$ service fail2ban restart

SSH absichern

Zu Beginn solltet ihr auf jeden Fall euren SSH-Server absichern. Einen grundlegenden Schutz gegen BruteForce-Angriffe habt ihr bereits durch fail2ban. Dies funktioniert aber aktuell lediglich für IPv4 Traffic, daher solltet ihr darauf achten das euer SSh-Server nur über IPv4 erreichbar ist (dazu den Eintrag ListenAddress :: auskommentieren). Nichtsdestotrotz sollte man weiter Maßnahmen ergreifen. Zudem ist es äußert ratsam, das Login als root über SSH zu verbieten. Ihr könnt euch dann nur noch mit eurem Nutzer-Konto anmelden. Root könnt ihr jedoch ganz einfach durch Ausführen von su werden. Eine weitere simple Maßnahme ist das ändern des SSH Ports. Standardmäßig lauscht der SSH Server immer auf Port 22, dieses Port können wir aber beliebig ändern, z.B. zu 16147 oder 1337.

Um dies zumzusetzen, öffner ihr als erstes eure Konfiguration des SSH-Servers:

mcedit /etc/ssh/sshd_config

Dort findet ihr ganz oben den Eintrag Port. Hier ist standardmäßig Port 22 eingetragen. Diese Zahl könnt ihr durch einen beliebigen Port eurer Wahl verändern, am bestein ein Port zwischen 1023 und 65535 wählen. Wenn ihr etwas runter scrollt, findet ihr den Eintrag PermitRootLogin. Hier sollte no stehen. Danach sollte eure Config in etwa so aussehen wie diese hier:

Port 24517
#ListenAddress ::
ListenAddress 0.0.0.0
[...]
PermitRootLogin no

Habt ihr diese zwei simplen Schritt durchgeführt, ist euer SSH-Server bereits gut abgesichert. Natürlich kann man noch zusätzliche Maßnahmen ergreifen, z.B. das Einrichten einer 2-Faktor-Authentifizierung oder das Anmelden über Zertifikate. Wie erstes funktioniert, habe ich bereits hier beschrieben.

Update Reminder per E-Mail

Damit ihr nicht immer prüfen müsst ob Updates verfügbar sind, könnt ihr euch auch bei der Verfügbarkeit neuer Updates einfach eine E-Mail senden lassen. Dazu müsst ihr folgende Pakete installieren:

$ apt-get install ssmtp apticron
  • ssmtp ist ein Paket, dass es ermöglicht E-Mails über einen externen SMTP-Server zu versenden. Dies erspart es einem, einen MTA auf dem Server einzurichten den man meist nicht unbedingt braucht, da man sowieso schon irgendwo einen E-Mail Dienst betreibt bzw. eine E-Mail Adresse bei einem Anbieter besitzt.
  • apticron ist ein Dienst, der regelmäßig das System auf Updates prüft. Falls Updates verfügbar sind, sendet es eine E-Mail an die in der Konfiguration hinterlegte E-Mail Adresse

Zunächst konfigurieren wir ssmtp. Dazu bearbeiten wir die /etc/ssmtp/ssmtp.conf mit folgendem Befehl:

$ mcedit /etc/ssmtp/ssmtp.conf

In dieser Datei tragen wir nun die Zugangsdaten zu dem von uns genutzten SMTP-Server ein. Je nachdem ob ihr eine verschlüsselte Verbindung nutzt oder nicht, müsst ihr ein paar Parameter anpassen:

root=meine@email.de

mailhub=smtp.email.de:25
AuthUser=username
AuthPass=password

UseTLS=YES
UseSTARTTLS=YES

Anschließend könnt ihr eure Konfiguration testen. Gebt dazu den folgende Befehl ein. Anschließend könnt ihr eine E-Mail verfassen, die ihr durch drücken von Strg+D absenden könnt

$ ssmtp meine@email.de
Subject: test
test

Kam die E-Mail bei euch an, funktioniert alles. Jetzt muss nur noch apticron konfiguriert werden. Dazu muss die Datei /etc/apticron/apticron.conf bearbeitet werden

$ mcedit /etc/apticron/apticron.conf 

Dort müsst ihr nur die folgenden zwei Zeilen bearbeiten

EMAIL="meine@email.de"
SYSTEM="debian-system1"

Diese sprechen für sich selbst, EMAIL legt fest an wen im Falle eines Updates die E-Mail geht und SYSTEM gibt den Namen des Systems fest, der in der E-Mail erscheint, damit man mehrere Installationen später unterscheiden kann. Das war es auch schon, apticron läuft als cron, somit ist kein neustart eines Services notwendig. Ihr werdet nun, falls Paket-Updates anstehen, per E-Mail informiert.

Server Überwachung mit munin

Dazu wird es später einen extra Blog-Post geben 😉

Schreibe einen Kommentar

Deine E-Mail-Adresse wird nicht veröffentlicht. Erforderliche Felder sind mit * markiert.