|
|
| Zeile 69: |
Zeile 69: |
|
| |
|
| {{SORTIERUNG:Harten #Computer}} | | {{SORTIERUNG:Harten #Computer}} |
| = 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:
| |
| : <pre>$ sudo apt install apticron</pre>
| |
|
| |
| === 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.
| |
|
| |
| <pre>
| |
| [...]
| |
| 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).
| |
| [...]
| |
| </pre>
| |
|
| |
| * Aktuelle SSH Daemon Konfiguration anzeigen (eingeloggt am Debian Server):
| |
|
| |
| : <code>$ sudo sshd -T |grep permitrootlogin</code>
| |
| : <code>permitrootlogin without-password</code>
| |
|
| |
| * SSH Konfiguration von einem beliebigen Host abfragen:
| |
|
| |
| : <code>$ ssh -G <IP-des-Server-mit-SSH></code>
| |
|
| |
| Ä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 [[SSH Root Login unter Debian verbieten|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.
| |
|
| |
| # Öffnen Sie dazu die Konfigurationsdatei des SSH Daemons:
| |
| #: <pre>$ sudo vi /etc/ssh/sshd_config</pre>
| |
| # Ä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.
| |
| # Starten Sie danach den SSH Dienst neu, um die Änderung anzuwenden:
| |
| #: <pre>$ sudo systemctl restart sshd.service</pre>
| |
|
| |
| 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:
| |
|
| |
| : <code>$ cat /etc/services</code>
| |
|
| |
| 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:
| |
|
| |
| # Installation von s-nail per apt:
| |
| #:<code>$ sudo apt install s-nail</code>
| |
| # 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:
| |
| #::<code>#!/bin/bash</code>
| |
| #::<code>echo "Login auf $(hostname) am $(date +%Y-%m-%d) um $(date +%H:%M)"</code>
| |
| #::<code>echo "Benutzer: $USER"</code>
| |
| #::<code>echo</code>
| |
| #::<code>pinky</code>
| |
| # Anpassen von ''/etc/profile'':
| |
| #: Damit die Mails beim Login versendet werden, muss in der Datei ''/etc/profile'' folgende Zeile angefügt werden:
| |
| #:: <code>/opt/shell-login.sh | mailx -s "SSH Login auf IHR-HOSTNAME" ihre-emailadresse@example.com</code>
| |
| # Login-Skript Rechte anpassen:
| |
| #: Die Datei /opt/shell-login.sh muss die Rechte 755 besitzen:
| |
| #:: <code>$ sudo chmod 755 /opt/shell-login.sh</code>
| |
| #: 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.
| |
|
| |
| # Lassen Sie sich den Inhalt anzeigen:
| |
| #:<code>$ cat /var/mail/<username></code>
| |
| #:<code>[...]</code>
| |
| #:<code>Diagnostic-Code: smtp; 553 Requested action not taken: mailbox name not</code>
| |
| #:<code> allowed: tk@debian</code>
| |
| #:<code>[...]</code>
| |
| # Setzen Sie hostname neu:
| |
| #:<code>tk@debian:~$ sudo hostnamectl set-hostname debian.local</code>
| |
| # Passen Sie die ''/etc/hosts'' Datei entsprechend des neuen hostname-Eintrages an.
| |
| # 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.
| |
| #:<code>tk@debian:~$ mailx <Name>@<Domain>.<TLD></code>
| |
| #:<code>Cc: </code>
| |
| #:<code>Subject: Test</code>
| |
| #:<code>Das ist ein E-Mail Test.</code>
| |
| #:<code><STRG+D></code>
| |
|
| |
| <gallery>
| |
| File:debian-ssh-login-test-e-mail.png|Test E-Mail eingetroffen
| |
| File:debian-ssh-login-e-mail.png|E-Mail bei einem erfolgreichen SSH-Login
| |
| </gallery>
| |
|
| |
| == 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.
| |
|
| |
| : <code>$ sudo apt install tcpd</code>
| |
|
| |
| === 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:
| |
| *: <code>$ ldd /usr/sbin/sshd |grep libwrap</code>
| |
| *: <code> libwrap.so.0 => /lib/x86_64-linux-gnu/libwrap.so.0 (0x00007fd696a1a000)</code>
| |
|
| |
| * Der Apache2 Webserver ist nicht kompatibel:
| |
| *: <code>$ ldd /usr/sbin/apache2 |grep libwrap</code>
| |
|
| |
| 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:
| |
|
| |
| <pre>
| |
| # /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
| |
| </pre>
| |
|
| |
| ==== 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:
| |
|
| |
| <pre>
| |
| # /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
| |
| </pre>
| |
|
| |
| '''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.
| |
|
| |
| : <code>$ sudo apt install iptables-persistent</code>
| |
|
| |
| === 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:
| |
| : <code>$ sudo iptables-save > /etc/iptables/rules.v4</code>
| |
| : <code>$ sudo ip6tables-save > /etc/iptables/rules.v6</code>
| |
|
| |
| === Beispielkonfiguration ===
| |
| Um zum Beispiel eine einzelne IP per iptables Regel den Zugriff auf SSH zu blockieren, kann folgende Zeile adaptiert werden:
| |
|
| |
| : <code>$ sudo iptables -A INPUT -p tcp --dport ssh -s <IP-Adresse> -j DROP</code>
| |
|
| |
| 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:
| |
|
| |
| : <code>$ sudo apt install rkhunter</code>
| |
|
| |
| === Konfiguration von rkhunter ===
| |
| Die Konfiguration erfolgt in der Datei ''rkhunter.conf''.
| |
|
| |
| # Ergänzen Sie deshalb noch einige Informationen:
| |
| #: <code>$ sudo vi /etc/rkhunter.conf</source>
| |
| # Kommentieren Sie die Zeile MAIL-ON-WARNING ein und ersetzen Sie root durch Ihre E-Mail-Adresse:
| |
| #: <code>MAIL-ON-WARNING="user@domain.tld"</code>
| |
| # Danach kann die Funktion getestet werden:
| |
| #: <code>$ sudo rkhunter --check</code>
| |
| # 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:
| |
| #: <code>[...]</code>
| |
| #: <code> ALLOWHIDDENDIR=/dev/.mdadm</code>
| |
| #: <code> RTKT_FILE_WHITELIST=/etc/init.d/.depend.boot</code>
| |
| #: <code> SCRIPTWHITELIST=/etc/init.d/hdparm</code>
| |
| #: <code> [...]</code>
| |
| # Genaue Ergebnisse der Tests sind in den Logdateien von rkhunter zu finden:
| |
| #: <code>$ tailf /var/log/rkhunter.log</code>
| |
|
| |
| == 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.
| |
|
| |
| # Die Installation erfolgt wie gewohnt bequem per Paketverwaltung:
| |
| #: <code>$ sudo apt install monit</code>
| |
| # Ein automatischer Start von monit gelingt wie folgt:
| |
| ## Öffnen Sie die Monit Konfigurationsdatei:
| |
| ##: <code>$ sudo vi /etc/default/monit</code>
| |
| ## Suchen Sie nach diesem Eintrag:
| |
| ##: <code>startup=0</code>
| |
| ## Durch Änderung des Parameters in 1 ist Munin nun als Dienst lauffähig:
| |
| ##: <code>startup=1</code>
| |
| # Anschließend tragen Sie die Dienste, die überwacht werden sollen, in die Konfigurationsdatei ein:
| |
| #:<code>$ sudo vi /etc/monit/monitrc</code>
| |
| # Beispielkonfiguration:
| |
| #: Nachfolgend finden Sie eine beispielhafte Konfiguration (die // Kommentare sind nur zur Erklärung und dürfen in der Konfigurationsdatei nicht angegeben werden)
| |
|
| |
| <pre>
| |
| [...]
| |
| 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
| |
| [...]
| |
| </pre>
| |
|
| |
| == Festplatten mittels smartmontools überwachen ==
| |
| Wichtige Bauteile wie Festplatten sollten ebenfalls überwacht werden.
| |
| * Dieses Beispiel zeigt die Konfiguration der Smartmontools anhand eines bestehenden [[Linux Software RAID]]s 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 [[Software RAID mit MDADM verwalten|mdadm installiert und verwaltet]] werden.
| |
|
| |
| === Installation der smartmontools ===
| |
| Die Installation der smartmontools erfolgt wie gewohnt mithilfe der Debian Paketverwaltung:
| |
|
| |
| <code>$ sudo apt install smartmontools</code>
| |
|
| |
| === Automatischer Start der smartmontools ===
| |
| Um den smartmontools Dienst automatisch beim Systemstart zu starten, ist eine Anpassung in der Konfigurationsdatei erforderlich.
| |
|
| |
| # Öffnen Sie die dazu die Konfigurationsdatei:
| |
| #: <code>$ sudo vi /etc/default/smartmontools</code>
| |
| # Kommentieren Sie den folgenden Eintrag ein:
| |
| #: <code>#start_smartd=yes</code>
| |
| # Nachher:
| |
| #: <code>start_smartd=yes</code>
| |
|
| |
| === Festplatteneinträge erstellen ===
| |
| Um die Festplatten per smartmontools zu überwachen, werden sie nun in der Datei ''smartd.conf'' eingetragen.
| |
|
| |
| # Öffnen Sie die dazu die ''smartd.conf'' Konfigurationsdatei:
| |
| #: <code>$ sudo vi /etc/smartd.conf</code>
| |
| # Kommentieren Sie zunächst die folgende Zeile aus:
| |
| #:<code>DEVICESCAN -d removable -n standby -m root -M exec /usr/share/smartmontools/smartd-runner</code>
| |
| # 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.
| |
|
| |
| {| class="wikitable sortable options"
| |
| |-
| |
| ! 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.
| |
| * https://github.com/CISOfy/lynis
| |
| * https://cisofy.com/lynis/
| |
| * https://packages.cisofy.com/#debian-ubuntu
| |
| |-
| |
| | 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.
| |
|
| |
|
| [[Kategorie:IT-Sicherheit/Maßnahmen]] | | [[Kategorie:IT-Sicherheit/Maßnahmen]] |
|
| |
|
| </noinclude> | | </noinclude> |