topic - Kurzbeschreibung

Beschreibung

Unter Härten (englisch Hardening) versteht man in der Computertechnik, die Sicherheit eines Systems zu erhöhen, indem nur dedizierte Software eingesetzt wird, die für den Betrieb des Systems notwendig ist, und deren unter Sicherheitsaspekten korrekter Ablauf garantiert werden kann. Das System soll dadurch besser vor Angriffen geschützt sein.

Das National Institute of Standards and Technology definiert Härten in der IT-Sicherheit wie folgt

"Ein Prozess, der dazu dient, eine Angriffsmöglichkeit zu eliminieren, indem Schwachstellen gepatcht und nicht benötigte Dienste abgeschaltet werden.

Ziel ist es, ein System zu schaffen, das von vielen, auch weniger vertrauenswürdigen Personen benutzt werden kann.

Beispielsweise gibt es für Gentoo Linux das hardened-Projekt, das eine Kernel-Version sowie weitere Systemdienste zusammenstellt, mit denen ein sicheres Linux-System auch für fremde Nutzer bereitgestellt werden kann.

Ziele

In der Praxis haben sich als Ziele von Härtungsmaßnahmen herausgebildet

• die Reduktion der Möglichkeiten zur Ausnutzung von Verwundbarkeiten
• die Minimierung der möglichen Angriffsmethoden
• die Beschränkung der einem Angreifer nach einem erfolgreichen Angriff zur Verfügung stehenden Werkzeuge
• die Minimierung der einem Angreifer nach einem erfolgreichen Angriff zur Verfügung stehenden Privilegien
• die Erhöhung der Wahrscheinlichkeit der Entdeckung eines erfolgreichen Angriffs

Als Nebenziel der Härtung kann auch eine mögliche Verringerung der Komplexität und des Wartungsaufwands des Systems gesehen werden, die zu einer höheren Beherrschbarkeit und damit einer Minimierung von Administrationsfehlern führen kann.

Methoden

Übliche Methoden der Härtung

• Entfernung oder Deaktivierung von für den Betrieb nicht zwingend erforderlichen Softwarekomponenten
• Verwendung unprivilegierter Benutzerkonten zur Ausführung von Server-Prozessen
• Anpassung von Dateisystemrechten und ihrer Vererbung
• Verwendung von chroot oder anderen Jails für die Ausführung von Software
• Verwendung von Mandatory Access Control
• Nutzung von Verschlüsselung, z. B. für Datenübertragung
• Verwendung möglichst fehlerfreier Software ohne bekannte Verwundbarkeiten

Ein Betriebssystem ist als „gehärtetes System“ zu bezeichnen

• Wenn Adressbereiche für Programmbibliotheken (ASLR) und Programme (PIE) zufällig im virtuellen Speicher zugewiesen werden. ASLR kann nur vom Hersteller dieser Bibliotheken zum Erstellungszeitpunkt realisiert werden, nicht nachträglich im Betrieb.
• Bei dem nur die Komponenten und Dienste installiert sind, die zum eigentlichen Betrieb benötigt werden
• Alle nicht benötigten Benutzerkonten gelöscht sind
• Alle nicht benötigten Ports geschlossen sind
• Restriktive Rechte gesetzt sind
• Straffe Systemrichtlinien vergeben sind

Härtungsmaßnahmen sind getrennt von anderen Sicherungsmaßnahmen wie Patchzyklen, der Einführung von Antivirus-Lösungen, Firewalls oder IDS/IPS zu betrachten, die komplementäre Methoden der Prävention darstellen.

Anhang

Siehe auch

• Härten (Computer)

Dokumentation

Links

Projekt

Weblinks

1. https://de.wikipedia.org/wiki/H%C3%A4rten_(Computer)
2. heise.de
3. fraunhofer.de
4. Microsoft Security Baselines
5. VMware Hardening Guides
6. CIS Benchmarks
7. DISA (Defense Information Systems) STIG (Security Technical Implementation)
8. NIST Computer Security Ressource Center
9. Bundesamt für Sicherheit in der Informationstechnik

TMP

topic - Kurzbeschreibung

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.

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>

• 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.

• 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 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:

• http://wiki.debian.org/Firewalls
• http://wiki.debian.org/iptables

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.

• 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.

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

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

/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. 

-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

PermitRootLogin no

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
[…]

sudo apt-get install unattended-upgrades