Absicherung eines Debian Servers

Aus Thomas-Krenn-Wiki
Zur Navigation springen Zur Suche springen
Hinweis: Bitte beachten Sie, dass dieser Artikel / diese Kategorie sich entweder auf ältere Software/Hardware Komponenten bezieht oder aus sonstigen Gründen nicht mehr gewartet wird.
Diese Seite wird nicht mehr aktualisiert und ist rein zu Referenzzwecken noch hier im Archiv abrufbar.

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.

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.[1] 

[...]
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.[2] 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.[3] 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.[4][5] Erstellen Sie dazu ein ausführbares Bash-Skript /opt/shell-login.sh mit folgendem Inhalt:
    #!/bin/bash
    echo "Login auf $(hostname) am $(date +%Y-%m-%d) um $(date +%H:%M)"
    echo "Benutzer: $USER"
    echo
    pinky
  3. 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
  4. 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.
    tk@debian:~$ mailx <Name>@<Domain>.<TLD>
    Cc:
    Subject: Test
    Das ist ein E-Mail Test.
    <STRG+D>
  • Test E-Mail eingetroffen

    Test E-Mail eingetroffen

  • E-Mail bei einem erfolgreichen SSH-Login

    E-Mail bei einem erfolgreichen SSH-Login

Mit tcpd und Whitelists arbeiten

Die Verwendung eines TCP-Wrappers wie tcpd bietet sich an, um die Sicherheit weiter zu erhöhen.[6] 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.[7]

  • Der SSH Daemon ist kompatibel:
    $ ldd /usr/sbin/sshd |grep libwrap
    libwrap.so.0 => /lib/x86_64-linux-gnu/libwrap.so.0 (0x00007fd696a1a000)
  • Der Apache2 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 Apache2 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.[8] 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. Damit können Sie unter anderem den SSH Login unter Debian mit fail2ban absichern.

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.[9]

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.[10] 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

Cheat Sheet

In diesem Cheat Sheet sind wichtige Punkte zum Thema Linux Server absichern übersichtlich notiert. Es enthält darüberhinaus noch Links zu Wikiartikel mit Konfigurationsanleitungen zum Beispiel zur Public-Key Authentifizierung.

Einzelnachweise

  1. ↑ OpenSSH Release Notes (openssh.com)
  2. ↑ sshd_config(5) - Linux man page (linux.die.net)
  3. ↑ Privileged Ports (w3.org)
  4. ↑ pinky(1) - Linux man page (linux.die.net)
  5. ↑ coreutils - Debian Wiki (wiki.debian.org)
  6. ↑ tcpd(8) - Linux man page (linux.die.net)
  7. ↑ ldd(1): print shared library dependencies (linux.die.net)
  8. ↑ Fail2ban (fail2ban.org)
  9. ↑ rkhunter (rkhunter.sourceforge.net)
  10. ↑ Monit (mmonit.com)

Das könnte Sie auch interessieren

E-Mail Updatebenachrichtigung mit apticron
Zum Artikel
TK Debian Sourcen lassen sich nicht kompilieren
Zum Artikel
Upgrade von Debian Etch auf Lenny
Zum Artikel