Kategorie Diskussion:Hardening

Aus Foxwiki

TMP

Beschreibung

Der Betrieb einer Linux Distribution als Server ist eine praktikable und anpassungsfähige Lösung.
  • Viele Editionen können als Minimalinstallation ohne grafische Oberfläche eingesetzt werden.
  • Dennoch gibt es bei der Installation und Konfiguration eines Linux-basierten Servers allerhand Optimierungsmöglichkeiten, um die Sicherheit zu erhöhen und die potentielle Angriffsfläche zu verringern.
  • Dieser Artikel beschreibt die Absicherung und Überwachung durch Monitoring eines Linux-basierten Servers am Beispiel einer Debian 9.1 Stretch Installation.
Root-Server offen im Internet zu betreiben birgt immer große Gefahren, egal ob als virtualisierte Instanz oder physisch im Rechenzentrum.
  • Da die Dienste der Server erreichbar sein müssen, wäre es absurd, alle Ports an der Firewall als Sicherheitsmaßnahme zu sperren.
  • Die Server wären so zwar vor Zugriffen von außen geschützt (sofern die Firewall keine Sicherheitslücken aufweist), könnten jedoch ihre Dienste nicht mehr zur Verfügung stellen.
  • Dieser „Tipp“ ist also nur sehr bedingt praxistauglich.
  • Deshalb im Folgenden ein paar echte Tipps, die Ihren Linux-basierten Root-Servern das Leben erleichtern.
  • Als kleines Special haben wir am Ende des Artikels außerdem eine Checkliste als PDF zum Download für Sie bereitgestellt.

Minimale Installation

Installieren Sie Ihren Server stets nur mit den wirklich erforderlichen Paketen
  • Wenn Sie keine grafische Oberfläche einsetzen möchten, sollte diese nicht installiert werden.
  • Denn jeder Overhead an Software bedeutet auch mehr potentielle Angriffsfläche.

Regelmäßige Systemupdates

Regelmäßige Updates versorgen das System mit Patches und neuen Funktionen
  • Dies sollte nicht vernachlässigt werden, da ein ungepatchtes System ein hohes Sicherheitsrisiko darstellt.
  • Um nicht jeden Tag Updates manuell prüfen zu müssen, gibt es das Paket apticron, denn es informiert Sie per Mail über neue Updates.

Apticron installieren

Das Tool apticron ist ein Shell-Skript, es informiert Sie automatisch per E-Mail, wenn Systemaktualisierungen vorliegen.

Apticron kann bequem per Paketverwaltung installiert werden: 

$ sudo apt install apticron

Apticron konfigurieren

Anschließend muss apticron noch konfiguriert werden, dies kann auf zwei Wegen erledigt werden. Sie können zum einen die Anpassungen in der Konfigurationsdatei /etc/apticron/apticron.conf mit einem Editor Ihrer Wahl vornehmen, weitere Informationen zur Konfiguration finden Sie im Artikel E-Mail Updatebenachrichtigung mit apticron.

Apticron kann aber auch bequem anhand eines Textmenüs konfiguriert werden.

  • Rufen Sie dazu sudo dpkg-reconfigure apticron auf und folgen Sie dem Dialog.

Jedoch wird hier nur die E-Mail-Adresse abgefragt, weitere Anpassungen können Sie dann in der bereits angesprochenen Konfigurationsdatei apticron.conf vornehmen.

Die Updates könnten natürlich auch per Cronjob jeden Tag automatisch installiert werden, was aber nicht empfehlenswert ist. Somit ist eine Kontrolle, welche Pakete installiert werden, schwierig und Fehler könnten nur schwer nachzuvollziehen sein.

SSH Konfiguration

Nachdem die Linux-Distribution nach Wahl installiert ist und apticron regelmäßig Sie über Updates informiert, gilt es nun den SSH Zugang abzusichern. Denn der OpenSSH Dienst stellt ein beliebtes Einfallstor für Angreifer bei jeder Linux-basierten Server-Distribution dar. Ein SSH-Zugang dient bei Servern zur bequemen Administration, eine Aktivierung dieses Dienstes ist bei einem Server ohne grafischer Oberfläche empfehlenswert.

SSH Login absichern

Standardmäßig ist der SSH Root Login bei vielen Distributionen deaktiviert und es wird empfohlen, dies auch nicht zu ändern.

Bei Debian Systemen ist der Wert aktuell auf prohibit-password (nicht auf no) gesetzt. Ein Blick in die Release Notes von OpenSSH zeigt, dass damit der passwortgestützte Login mit dem root-Konto gesperrt ist, jedoch z.B. eine Public-Key Authentifizierung möglich ist. 

[...]
PermitRootLogin=without-password/prohibit-password now bans all
 interactive authentication methods, allowing only public-key,
 hostbased and GSSAPI authentication (previously it permitted
 keyboard-interactive and password-less authentication if those
 were enabled).
[...]
  • Aktuelle SSH Daemon Konfiguration anzeigen (eingeloggt am Debian Server):
$ sudo sshd -T |grep permitrootlogin
permitrootlogin without-password
  • SSH Konfiguration von einem beliebigen Host abfragen:
$ ssh -G <IP-des-Server-mit-SSH>

Änderungen an der SSH Daemon Konfiguration werden in der Konfigurationsdatei /etc/ssh/sshd_config vorgenommen. Falls der Root-Login auf Ihrem System aktiviert ist, lässt sich dies ganz einfach unter Debian verbieten.

sudo als Alternative

Melden Sie sich deshalb mit einem regulären Benutzerkonto per SSH am Server an und wechseln Sie dann per sudo Befehl zum root-User.

  • Oder Sie verwenden nur für Befehle, die root-Rechte benötigen, per vorangestelltem sudo den Root-User.
  • Sie können festlegen, welche Benutzer und Gruppen eine Verbindung per SSH aufbauen dürfen.
  • Die sudoers Gruppe steuert die Benutzer, die per sudo Befehle mit Root-Rechten ausführen dürfen.

SSH Login mit Public Key Authentifizierung

Sicherer und komfortabler ist es außerdem, den passwortbasierten SSH Login gänzlich zu verbieten und dafür auf eine Public Key Authentifizierung zu setzen. Eine Anleitung, wie Sie eine OpenSSH Public Key Authentifizierung unter Ubuntu einrichten, ist in unserem Wiki verfügbar.

  • Sie ist ebenso auch für Debian Distributionen anwendbar.

SSH Port ändern

Die Mehrzahl der (automatisierten) Loginattacken auf SSH erfolgt auf den Standardport 22.

  • Eine einfache und effektive Methode gegen automatisierte Loginattacken wäre es, den SSH Port auf einen anderen, z.B. im Bereich der registrierten Ports zu ändern.

Ein Problem an der Sache ist jedoch, dass dies nicht zwangsläufig die Systemsicherheit erhöht.

  • Im Bereich der standardisierten Ports (0 - 1023) darf nur der root User Serverdienste bereitstellen, im Gegensatz zu den registrierten Ports.
  • Diese Ports können auch von normalen Benutzern verwendet werden.

Des weiteren müsste der Port aus dem registrierten Bereich natürlich über das Netzwerk erreichbar sein, in vielen Netzwerkkonfigurationen sind jedoch nicht-standardisierte Ports gesperrt.

  1. Öffnen Sie dazu die Konfigurationsdatei des SSH Daemons: 
    $ sudo vi /etc/ssh/sshd_config
  2. Ändern Sie nun den SSH Port vom standardmäßigen Port 22 auf einen anderen Port Ihrer Wahl ab, speichern und schließen Sie anschließend die Datei.
  3. Starten Sie danach den SSH Dienst neu, um die Änderung anzuwenden: 
    $ sudo systemctl restart sshd.service

Beachten Sie bitte, dass Sie keinen festen Port eines anderen Dienstes benutzen, suchen Sie deshalb nach einem freien High-Port. Eine Liste mit Ports und Diensten können Sie sich mit diesem Befehl anzeigen lassen:

$ cat /etc/services

Aktive SSH Verbindungen bleiben offen. Öffnen Sie nun ein neues Terminalfenster und testen Sie ob Sie SSH mit Ihrem angegebenen Port erreichen, bevor Sie das aktive Fenster schließen.

Benachrichtigung bei SSH Login

Eine E-Mail Benachrichtigung bei einem erfolgreichen SSH-Login an eine definierte E-Mail Adresse ist eine weitere Methode, einen Linux-basierten Server abzusichern.

Installation eines Tools zum Bereitstellen der mailx Funktionalität

Die Installation und Konfiguration von s-nail gelingt in wenigen Schritten:

  1. Installation von s-nail per apt:
    $ sudo apt install s-nail
  2. Erstellen eines Bash-Skriptes:
    Mit folgendem Skript erhalten Sie eine E-Mail, sobald sich ein Benutzer per SSH einloggt.
  • Das in diesem Skript verwendete pinky funktioniert ähnlich zu finger und ist über die GNU core utilities bei Linux-basierten Betriebssystemen standardmäßig installiert.
  • Erstellen Sie dazu ein ausführbares Bash-Skript /opt/shell-login.sh mit folgendem Inhalt:
  1. #!/bin/bash
    echo "Login auf $(hostname) am $(date +%Y-%m-%d) um $(date +%H:%M)"
    echo "Benutzer: $USER"
    echo
    pinky
  2. Anpassen von /etc/profile:
    Damit die Mails beim Login versendet werden, muss in der Datei /etc/profile folgende Zeile angefügt werden:
    /opt/shell-login.sh | mailx -s "SSH Login auf IHR-HOSTNAME" ihre-emailadresse@example.com
  3. Login-Skript Rechte anpassen:
    Die Datei /opt/shell-login.sh muss die Rechte 755 besitzen:
    $ sudo chmod 755 /opt/shell-login.sh
    Die Mail wird nun automatisch versandt, sobald sich ein Benutzer per SSH einloggt.
  • Der User hat vom Versand dieser E-Mail keine Kenntnis.

Achtung: Bei Programmen, die keinen vollständigen Login durchführen (z.B. winSCP) wird keine E-Mail versandt!

Troubleshooting hostname

Es kann zu Problemen bei der Zustellung der E-Mail kommen, wenn der Ziel Mail-Server den Absender nicht akzeptiert.

  • Die E-Mail landet dann in einer lokalen Datei, z.B. /var/mail/<username>.
  • Anhand der Berichte in diesen Dateien kann man das Problem einkreisen.
  1. Lassen Sie sich den Inhalt anzeigen:
    $ cat /var/mail/<username>
    [...]
    Diagnostic-Code: smtp; 553 Requested action not taken: mailbox name not
    allowed: tk@debian
    [...]
  2. Setzen Sie hostname neu:
    tk@debian:~$ sudo hostnamectl set-hostname debian.local
  3. Passen Sie die /etc/hosts Datei entsprechend des neuen hostname-Eintrages an.
  4. Testen des E-Mail Versandes:
    Falls eine E-Mail beim Login nicht im definierten Postfach einlangt, überprüfen Sie ob der Mailversand auf der Kommandozeile funktioniert.
  • Dies können Sie mit dem mailx Kommando durchführen.
  1. tk@debian:~$ mailx <Name>@<Domain>.<TLD>
    Cc:
    Subject: Test
    Das ist ein E-Mail Test.
    <STRG+D>

Mit tcpd und Whitelists arbeiten

Die Verwendung eines TCP-Wrappers wie tcpd bietet sich an, um die Sicherheit weiter zu erhöhen.

  • der tcpd wacht als Zwischenschicht vor dem inetd.
  • Noch bevor der inetd-Daemon bei einer Verbindungsanfrage den entsprechenden Dienst starten kann, wird vom tcpd geprüft ob der Anfrager diesen Dienst auch in Anspruch nehmen darf.
  • Diese Prüfung erfolgt anhand der beiden Konfigurationsdateien /etc/hosts.allow und /etc/hosts.deny.

Installation

Der tcpd ist oft schon standardmäßig installiert und kann auch bequem per Paketverwaltung installiert werden.

$ sudo apt install tcpd

Kompatibilitätsprüfung

Nicht jeder Dienst ist mit TCP-Wrappern kompatibel, denn es muss die libwrap Library verlinkt sein.

  • Die Kompatibilität kann mit dem Befehl ldd geprüft werden.
  • Der SSH Daemon ist kompatibel:
    $ ldd /usr/sbin/sshd |grep libwrap
    libwrap.so.0 => /lib/x86_64-linux-gnu/libwrap.so.0 (0x00007fd696a1a000)
  • Der Apache Webserver ist nicht kompatibel:
    $ ldd /usr/sbin/apache2 |grep libwrap

Das bedeutet, dass die Zugriffskontrolle per tcpd in Verbindung mit einem Apache2-Webserver nicht funktioniert.

  • In diesem Fall kann man auf die .htaccess Datei setzen oder per Firewallkonfiguration, z.B. mit iptables, die Zugriffe kontrollieren.

Konfiguration

Die Konfiguration des tcpd erfolgt anhand der beiden bereits angesprochenen Konfigurationsdateien hosts.allow und hosts.deny.

hosts.allow

In der hosts.allow können ganz gezielt einzelne IP-Adressen, aber auch IP-Bereiche per Wildcard, der Zugriff erlaubt werden.

Beispielkonfiguration anhand eines SSH Eintrages, hier wird dem Netzwerk 192.168.0.0/24 der Zugriff auf den SSH Daemon erlaubt: 

# /etc/hosts.allow: list of hosts that are allowed to access the system.
# See the manual pages hosts_access(5) and hosts_options(5).
#
# Example: ALL: LOCAL @some_netgroup
# ALL: .foobar.edu EXCEPT terminalserver.foobar.edu
#
# If you're going to protect the portmapper use the name "rpcbind" for the
# daemon name. 
* See rpcbind(8) and rpc.mountd(8) for further information.
#
sshd: 192.168.0.0/255.255.255.0

hosts.deny

Wenn die Einträge in hosts.allow alle korrekt gesetzt wurden, kann in hosts.deny die Wildcard ALL:ALL eingetragen werden, somit wird standardmäßig sämtlicher Zugriff verweigert, außer die IP-Adressen bzw. Adressbereiche, die explizit in der hosts.allow erlaubt wurden.

Beispielkonfiguration: 

# /etc/hosts.deny: list of hosts that are _not_ allowed to access the system.
# See the manual pages hosts_access(5) and hosts_options(5).
#
# Example: ALL: some.host.name, .some.domain
# ALL EXCEPT in.fingerd: other.host.name, .other.domain
#
# If you're going to protect the portmapper use the name "rpcbind" for the
# daemon name. 
* See rpcbind(8) and rpc.mountd(8) for further information.
#
# The PARANOID wildcard matches any host whose name does not match its
# address.
#
# You may wish to enable this to ensure any programs that don't
# validate looked up hostnames still leave understandable logs. 
* In past
# versions of Debian this has been the default.
# ALL: PARANOID
ALL:ALL

Wichtiger Hinweis: Prüfen Sie deshalb unbedingt die Korrektheit der Einträge vor der Aktivierung damit Sie sich nicht vom System aussperren.

iptables

Da der TCP-Wrapper, wie der bereits angesprochene tcpd, nicht geeignet ist, um den Zugriff auf einen Apache Webserver zu steuern, bietet sich hier die Verwendung von iptables an.

  • Hiermit kann für sämtliche Dienste und Anwendungen der Zugriff definiert werden.
  • Sobald alle Dienste auf dem Server installiert und konfiguriert sind und man weiß, welche Ports benötigt werden, können anschließend alle anderen Ports mittels iptables Kommandos blockiert werden.

Installation von iptables-persistent

Hinweis: Die Regeln von iptables werden nicht dauerhaft gespeichert und sind beim nächsten Neustart deshalb nicht mehr vorhanden, deshalb bietet sich die Installation von iptables-persistent an.

  • Damit werden die Regeln automatisch geladen.
$ sudo apt install iptables-persistent

Konfiguration von iptables-persistent

Definieren Sie die gewünschten Regeln mit dem iptables Kommando, anschließend können die Einträge mit iptables-save und ip6tables-save in die rules.v4 bzw.

  • rules.v6 Datei übertragen werden:
$ sudo iptables-save > /etc/iptables/rules.v4
$ sudo ip6tables-save > /etc/iptables/rules.v6

Beispielkonfiguration

Um zum Beispiel eine einzelne IP per iptables Regel den Zugriff auf SSH zu blockieren, kann folgende Zeile adaptiert werden:

$ sudo iptables -A INPUT -p tcp --dport ssh -s <IP-Adresse> -j DROP

In diesem Fall wird durch den Schalter -A eine neue Regel angefügt (-A steht für Append), das Protokoll ist tcp (-p steht für Protocol), der Ziel-Port ist 22 (--dport bzw. -destination-port), danach wird die Quell-IP angegeben (-s bedeutet source). Am Ende der Zeile wird definiert was mit einer Anfrage von dieser IP auf den Port 22 passieren soll, dem Parameter -j (steht für jump) ist hier DROP hinten angestellt.

  • DROP bedeutet, das Paket wird nicht angenommen und der Sender erhält auch keine Nachricht.

Weitere Informationen dazu finden Sie auf folgenden Webseiten:

Diese Methode bedarf großer Vorsicht bei der Einrichtung, damit Sie sich nicht aussperren.

Brute-Force-Angriffe mit Fail2Ban verhindern

Das Python Tool fail2ban kann eingesetzt werden, um verschiedene Dienste gegen Brute-Force-Angriffe abzusichern. Brute-Force-Angriffe sind Versuche mittels "roher Gewalt" sich Zugang zu einem Computersystem zu ermöglichen.

  • Es wird mittels unzähliger Versuche ausprobiert, die richtige Lösung zu finden.

fail2ban setzt bei den unzähligen Versuchen an, indem es nach einer selbst definierten Anzahl von Logins die IP-Adresse des Angreifers für Minuten/Stunden/Tage sperren kann.

Rootkits mit rkhunter aufspüren

Sollte es einem Angreifer gelingen das System zu kompromittieren, ist es meist schwer nachzuvollziehen wo der Einbruch erfolgte. Mit dem Tool rkhunter wird der Server auf häufige Rootkits, verdächtige Strings, etc. überprüft und der Benutzer beim Fund informiert.

Installation von rkhunter

rkhunter lässt sich ganz einfach über die Paketverwaltung installieren:

$ sudo apt install rkhunter

Konfiguration von rkhunter

Die Konfiguration erfolgt in der Datei rkhunter.conf.

  1. Ergänzen Sie deshalb noch einige Informationen:
    $ sudo vi /etc/rkhunter.conf</source>
  2. Kommentieren Sie die Zeile MAIL-ON-WARNING ein und ersetzen Sie root durch Ihre E-Mail-Adresse:
    MAIL-ON-WARNING="user@domain.tld"
  3. Danach kann die Funktion getestet werden:
    $ sudo rkhunter --check
  4. Sollten Sie hier Warnungen erhalten, aber es handelt sich um sogenannte false-positives, kann eine Whitelist in ebensolcher Konfigurationsdatei /etc/rkhunter.conf erstellt werden.
    Beispielhaft nun die folgenden Whitelist-Einträge:
    [...]
    ALLOWHIDDENDIR=/dev/.mdadm
    RTKT_FILE_WHITELIST=/etc/init.d/.depend.boot
    SCRIPTWHITELIST=/etc/init.d/hdparm
    [...]
  5. Genaue Ergebnisse der Tests sind in den Logdateien von rkhunter zu finden:
    $ tailf /var/log/rkhunter.log

Monitoring

Das Feld Monitoring darf zum Thema Server Sicherheit nicht fehlen.

  • Die Beobachtung der Server und Netzwerkinfrastruktur gehört zu den wichtigsten Aufgaben.
  • Probleme können anhand Trends in der Aufzeichnung der Werte, bevor es zu einem Ausfall kommt, erkannt und behoben werden.
  • Der Markt bietet eine Vielzahl an Monitoring-Lösungen.

Dienste mit Monit überwachen

Die Dienste eines Servers können mit dem Tool Monit überwacht werden. Je nach Konfiguration sendet Monit Ihnen Mails, z.B. wenn ein Dienst nicht erreichbar ist oder von Monit neu gestartet wurde. Sie können den Platz auf den Festplatten, Offene Ports, Dienste und vieles mehr überwachen.

  1. Die Installation erfolgt wie gewohnt bequem per Paketverwaltung:
    $ sudo apt install monit
  2. Ein automatischer Start von monit gelingt wie folgt:
    1. Öffnen Sie die Monit Konfigurationsdatei:
      $ sudo vi /etc/default/monit
    2. Suchen Sie nach diesem Eintrag:
      startup=0
    3. Durch Änderung des Parameters in 1 ist Munin nun als Dienst lauffähig:
      startup=1
  3. Anschließend tragen Sie die Dienste, die überwacht werden sollen, in die Konfigurationsdatei ein:
    $ sudo vi /etc/monit/monitrc
  4. Beispielkonfiguration:
    Nachfolgend finden Sie eine beispielhafte Konfiguration (die // Kommentare sind nur zur Erklärung und dürfen in der Konfigurationsdatei nicht angegeben werden)
[...]
 set daemon 120 // Monit überprüft all 2 Minuten
 set logfile syslog facility log_daemon // Wo wird die Logdatei hingeschrieben
 set mailserver localhost // Mailserver über den die Mails verschickt werden
 set mail-format { from: user@domain.tld } // Mailadresse Absender
 set alert user@domain.tld // Empfänger der Mails

 check system localhost // Lokalen Server überwachen
 if loadavg (5min) > 1 then alert // Wenn Loadaverage über 5 Minuten größer 1 ist, Alarm versenden
 if memory usage > 75% then alert // Wenn mehr als 75% des Speichers benötigt werden, Alarm versenden
 if cpu usage (user) > 70% then alert // Wenn mehr als 70% CPU Leistung benötigt wird, Alarm versenden (User)
 if cpu usage (system) > 30% then alert // Wenn mehr als 30% CPU Leistung benötigt wird, Alarm versenden (System)
 if cpu usage (wait) > 20% then alert // Wenn mehr als 20% CPU Leistung benötigt wird, Alarm versenden (Wait)

 check process sshd with pidfile /var/run/sshd.pid // Dienst SSH durch PID File überwachen
 start program "/etc/init.d/ssh start" // Wie kann SSH im Fehlerfall gestartet werden
 stop program "/etc/init.d/ssh stop" // Wie kann SSH im Fehlerfall beendet werden
 if failed port 22 protocol ssh then restart // Wenn der SSH Dienst nicht läuft, neu starten
 if 5 restarts within 5 cycles then timeout // Wenn nach 5 Versuchen der Dienst nicht gestartet werden kann, mit Timeout beenden

 check process mysql with pidfile /var/run/mysqld/mysqld.pid // Dienst Mysql durch PID File überwachen
 group database // Gruppe definieren
 start program = "/etc/init.d/mysql start" // Wie kann der MySQL Server im Fehlerfall gestartet werden
 stop program = "/etc/init.d/mysql stop" // Wie kann der MySQL Server im Fehlerfall gestopt werden
 if failed host 127.0.0.1 port 3306 then restart // Wenn Port 3306 (MySql) auf dem Lokalen Server nicht läuft, neu starten
 if 5 restarts within 5 cycles then timeout // Wenn nach 5 Versuchen der Dienst nicht gestartet werden kann, mit Timeout beenden
[...]

Festplatten mittels smartmontools überwachen

Wichtige Bauteile wie Festplatten sollten ebenfalls überwacht werden.

  • Dieses Beispiel zeigt die Konfiguration der Smartmontools anhand eines bestehenden Linux Software RAIDs mit zwei 2 SATA Festplatten.
  • Diese Festplatten wurden mittels mdadm zu einem RAID 1 Verbund kombiniert.

Ein Linux Software RAID kann einfach und schnell mit mdadm installiert und verwaltet werden.

Installation der smartmontools

Die Installation der smartmontools erfolgt wie gewohnt mithilfe der Debian Paketverwaltung:

$ sudo apt install smartmontools

Automatischer Start der smartmontools

Um den smartmontools Dienst automatisch beim Systemstart zu starten, ist eine Anpassung in der Konfigurationsdatei erforderlich.

  1. Öffnen Sie die dazu die Konfigurationsdatei:
    $ sudo vi /etc/default/smartmontools
  2. Kommentieren Sie den folgenden Eintrag ein:
    #start_smartd=yes
  3. Nachher:
    start_smartd=yes

Festplatteneinträge erstellen

Um die Festplatten per smartmontools zu überwachen, werden sie nun in der Datei smartd.conf eingetragen.

  1. Öffnen Sie die dazu die smartd.conf Konfigurationsdatei:
    $ sudo vi /etc/smartd.conf
  2. Kommentieren Sie zunächst die folgende Zeile aus:
    DEVICESCAN -d removable -n standby -m root -M exec /usr/share/smartmontools/smartd-runner
  3. Ergänzen Sie danach diese beiden Zeilen (angepasst an die Devicenamen, Parameter und E-Mail-Adresse):
    /dev/sda -n standby -a -I 194 -W 6,50,55 -R 5 -M daily -M test -m user@domain.tld
    /dev/sdb -n standby -a -I 194 -W 6,50,55 -R 5 -M daily -M test -m user@domain.tld

Erklärung: 

/dev/sda // Bezeichnung der zu überwachenden Festplatte
-n standby // Wenn die Festplatte im Standbymodus ist, diese nicht aufwecken
-a // Alle Werte überprüfen
-I 194 // Temperature Wert auslassen
-W 6,50,55 // Änderungen von 6 Grad oder mehr reporten.
  • Temperaturhöchstwert 50 Grad.
  • Bei 55 Grad warnen.
-R 5 // Reallocated Sectors beachten (ID 5)
-M daily // Tägliche Erinnerung versenden, auch wenn das Problem bereits gemeldet wurde
-M test // Testmail beim Neustart des Diensts schicken
-m user@domain.tld // Empfänger der Warnungen

TMP

Installation/Ersteinrichtung eines Linux Root-Servers

Eine wahllose Installation von Paketen erhöht das Risiko einer Sicherheitslücke – Sie sollten daher nur die für den Einsatzzweck erforderlichen Pakete installieren.
  • Wenn Sie von Ihrem Hoster Zugangsdaten für eine bereits installierte und vorkonfigurierte Maschine erhalten, meist geschieht dies per E-Mail, dann zögern Sie nicht, diese zu ändern.
  • Ein geändertes und möglichst sicheres Root-Passwort ist ein wichtiger Punkt auf der Checkliste.

SSH

Bei einem sicheren Passwort allein sollte man es aber nicht belassen
ein möglicher root-Login per SSH wird nicht empfohlen.
  • Verbieten Sie deshalb den root-Login über eine SSH-Session mit
PermitRootLogin no

in /etc/ssh/sshd_config und legen Sie für die Arbeiten am System einen weiteren User an, zum Beispiel admin.

  • Diesem User sollten dann natürlich sudo-Rechte gewährt werden.
Die Sicherheit lässt sich noch weiter erhöhen, wenn Sie generell auf Passwort-Logins verzichten und sich stattdessen über eine sogenannte Public-Key-Authentifizierungen anmelden.
  • Wie Sie dies am Beispiel eines Ubuntu-Systems vornehmen, erklären wir ausführlich in unserem Thomas-Krenn-Wiki.
Weitergehende Konfigurationstipps finden Sie zum Beispiel in der Ubuntu Dokumentation.

TCP-Wrapper

Als weitere Maßnahme auf dem Weg zu einem gut gesicherten System bietet sich die Verwendung des TCP-Wrappers an.
  • Dieser TCP-Wrapper, der tcpd, wacht als Zwischenschicht vor dem inetd.
  • Der inetd-Daemon startet bei einer Verbindungsanfrage den entsprechenden Dienst.
  • Ob der Anfrager an den Dienst diesen auch in Anspruch nehmen darf, wird vom tcpd anhand der Konfigurationsfiles /etc/hosts.allow und /etc/hosts.deny geprüft, ob beispielsweise diese IP-Adresse den SSH-Dienst starten darf.
Mit der hosts.allow kann somit ganz gezielt und explizit IP-Adressen oder auch per Wildcards einem Bereich der Zugriff erlaubt werden.
  • In der /etc/hosts.deny kann dann die Wildcard ALL:ALL eingetragen sein, damit standardmäßig sämtlicher Zugriff verweigert wird, es sei denn er wird explizit erlaubt.

fail2ban

Fail2Ban ist ein in Python geschriebenes Programm, das verschiedene Serverdienste, z. B. SSH oder auch Apache2, gegen unbefugten Zugriff absichern kann.
  • Dazu liest es die konfigurierten Logfile-Einträge aus, um nach Authentifizierungs-Fehlern zu suchen.
  • Wenn der Login-Vorgang zu oft fehlschlägt, wird die entsprechende IP per Firewall-Regel gesperrt.
  • Die maximale Anzahl fehlgeschlagener Logins kann eingestellt werden.
cat $ cat /var/log/auth.log |grep failure
[…]
Oct 4 14:52:52 tkmon sshd[1462]: pam_unix(sshd:auth): authentication failure; logname= uid=0 euid=0 tty=ssh ruser= rhost=10.1.102.106 user=tkmon
[…]

Automatische Updates

Ein ungepatchtes Server-Betriebssystem ist ein nicht unerhebliches Sicherheitsrisiko.
  • Damit dies im Tagesbetrieb nicht übersehen wird, können Updates auch automatisiert installiert werden:
sudo apt-get install unattended-upgrades

Möchte man an Updates erinnert werden, diese aber dann manuell installieren, ist die Installation des Shellskriptes apticron zu empfehlen.

  • Es dient zur automatischen E-Mail-Benachrichtigung, wenn System-Updates verfügbar sind.
  • Voraussetzung ist ein installierter MTA, z. B. Postfix, zur Zustellung der E-Mails.

Zwei-Faktor-Authentifizierung

Da immer bessere Passwort-Cracking-Tools verfügbar sind und die Hardware immer leistungsfähiger wird, sind Brute-Force Angriffe auf abgegriffene Passwort-Hashes mittlerweile ein probates Mittel, um sich Zugang zu einem Computersystem zu verschaffen.

Eine weitere Sicherheitsstufe, der zweite Faktor, gilt als immer verbreiterte Maßnahme, um Unbefugten den Angriff auf ein System zu erschweren.

  • Der zweite Faktor einer Authentifizierung kann auf vielerlei Arten durchgeführt werden, z. B. über Tokens wie den Yubikey oder den Google Authenticator.

Es wird dann, neben der Abfrage des Benutzerpasswortes, zusätzlich zum Beispiel ein Einmalpasswort abgefragt.

Tools

Die Paketquellen eines Linux-basierten Betriebssystems bieten ein großes Angebot an nützlichen Tools, um Angriffe und Veränderungen am System sichtbar zu machen.

Option Beschreibung
Backup Falls es, trotz aller Vorsichtsmaßnahmen und eingesetzter Tools, zu einem erfolgreichen Angriff kommt, ist eine zuverlässige Backup-Strategie von höchster Priorität.
  • Der Backup-Markt im Linux-Umfeld ist vielschichtig, in unserem Thomas-Krenn-Wiki finden Sie eine Auswahl an beliebten Backup-Lösungen wie rdiff-backup und rsnapshot.
nmap Mit nmap können offene Ports eines Servers gescannt werden.
  • Unbekannte oder nicht zur eigentlichen Konfiguration passende, offene Ports können ein Hinweis auf eine Veränderung durch einen erfolgreichen Angriff sein.
debsums Mit dem Tool debsums können Checksummen von Files, die über Debian Pakete auf dem System installiert wurden, überprüft werden.
  • Checksummen, die nicht mit den bei der Paketinstallation mitinstallierten Files übereinstimmen, können ein Hinweis auf eine Malware-Infizierung sein.
  • Die Binaries von ls und find werden gerne modifiziert um das Rootkit zu verstecken.
etckeeper Etckeeper stellt vom Grundgedanken her eigentlich eine Versionierungsmöglichkeit des Konfigurationsverzeichnisses /etc/ dar. Änderungen in den Unterverzeichnissen von /etc/ werden mitprotokolliert, wodurch bei einer fehlerhaften Konfiguration eine Vorgängerversion wiederhergestellt werden kann.
  • Da etckeeper eine Benachrichtigungsfunktion per E-Mail mitbringt, kann es auch als Tool zur Erkennung von unerwünschten Veränderungen am Server eingesetzt werden.
  • Weitere Informationen dazu finden Sie in unserem Thomas-Krenn-Wiki.
tripwire Das Tool „Open Source Tripwire“ ist ein freies Host-basiertes Intrusion Detection System für kleinere Umgebungen mit wenigen Linux Servern.
  • Es ist ein Tool für Sicherheit und Datenintegrität und wird direkt auf den Hosts zur Alarmierung bei Veränderungen an den Files verwendet.
rkhunter und chkrootkit Um Rootkits, Backdoors und lokalen Exploits auf die Schliche zu kommen, empfiehlt es sich mehrere Tools wie rkhunter oder chkrootkit parallel zu betreiben.
logcheck Auffälligkeiten in den Logfiles kann der Administrator manuell per Hand durchsuchen oder an kleine Programme wie logcheck delegieren.
  • Dieses Tool durchsucht automatisch die angegebenen Logfiles und benachrichtigt den Admin per E-Mail, wenn etwas Auffälliges in den Logs auftaucht.
Lynis Lynis stellt ein Open Source Auditing Tool für viele gängige Unix-basierte Betriebssysteme dar. Damit können auf dem Host automatisierte Sicherheitsevaluierungen durchgeführt werden. Unter anderem gibt es Pakete für Ubuntu, der Code ist aber ebenso auf Github zu finden.
Remote Management (IPMI) IPMI-Interfaces sind ein nützliches Feature, können aber gehörige Sicherheitsrisiken darstellen.
  • Da dieses Thema von großer Bedeutung ist und keinesfalls zu kurz kommen sollte, haben wir IPMI im Juli einen eigenen TKmag Artikel gewidmet.
  • Befolgen Sie die 7 Punkte für mehr Sicherheit im Umgang mit IPMI und Sie können ganz einfach eine weitere Sicherheitslücke auf der Checkliste abhaken.

Zusammenfassung

Zusammenfassend kann gesagt werden, dass eine grundsätzliche und vollumfängliche Sicherheit für Root-Server leider nur sehr schwer umzusetzen ist.

  • Zu viele unterschiedliche Parteien rütteln mit immer größerem Aufwand an den Toren der Server und es gelingt immer wieder, Systeme zu kompromittieren.

Selbst große Firmen wie aktuell Yahoo oder auch Dropbox sind davor nicht gefeit, um zwei bekannte Beispiele zu nennen.

  • Ein Computersystem ohne kontinuierliche Aktualisierungen und Sicherheitsüberprüfungen zu betreiben, wird in absehbarer Zeit zu Sicherheitsproblemen führen.
  • Es reicht schon ein ungepatchtes System mit einer Sicherheitslücke wie der bekannten SSL-Lücke Heartbleed, um es Angreifern (theoretisch) zu ermöglichen, Zugriff zum Server zu erhalten.
  • Die IPMI-Schnittstelle des Servers darf, wie im entsprechenden Abschnitt erklärt, ebenso nicht stiefmütterlich behandelt werden.

Die in diesem Artikel aufgeführten Tipps und die Auswahl an nützlichen Tools helfen dem Administrator aber, es Angreifern so schwer wie möglich zu machen, die Server-Infrastruktur anzugreifen.

Abgerufen von „https://wiki.foxtom.de/index.php?title=Kategorie_Diskussion:Hardening&oldid=113768“