|
|
| (2 dazwischenliegende Versionen desselben Benutzers werden nicht angezeigt) |
| Zeile 1: |
Zeile 1: |
| '''topic''' - Kurzbeschreibung
| |
| == Beschreibung ==
| |
| Unter '''Härten''' (englisch Hardening) versteht man in der Computertechnik, die [[Computersicherheit|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 [[Linux (Kernel)|Kernel]]-Version sowie weitere Systemdienste zusammenstellt, mit denen ein sicheres [[Linux|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 [[Hacker|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 [[Jail]]s 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 [[Programmbibliothek]]en ([[Address Space Layout Randomization|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 [[Benutzerkonto|Benutzerkonten]] gelöscht sind
| |
| * Alle nicht benötigten [[Port (Protokoll)|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|Antivirus-Lösungen]], [[Firewall]]s oder [[Intrusion Detection System|IDS]]/[[Intrusion Prevention System|IPS]] zu betrachten, die komplementäre Methoden der Prävention darstellen.
| |
|
| |
| <noinclude>
| |
|
| |
| == Anhang ==
| |
| === Siehe auch ===
| |
| {{Special:PrefixIndex/Härten}}
| |
|
| |
| ==== Dokumentation ====
| |
| ==== Links ====
| |
| ===== Projekt =====
| |
| ===== Weblinks =====
| |
| # https://de.wikipedia.org/wiki/H%C3%A4rten_(Computer)
| |
| # https://www.thomas-krenn.com/de/wiki/Absicherung_eines_Debian_Servers
| |
| # [https://www.heise.de/security/meldung/Bundesregierung-verteidigt-neue-Ansaetze-zur-Staerkung-der-IT-Sicherheit-200501.html heise.de]
| |
| # [http://testlab.sit.fraunhofer.de/content/output/article/0605Produktionssicherheit.php fraunhofer.de]
| |
| # [https://blogs.technet.microsoft.com/secguide/ Microsoft Security Baselines]
| |
| # [https://www.vmware.com/security/hardening-guides.html VMware Hardening Guides]
| |
| # [https://www.cisecurity.org/cis-benchmarks/ CIS Benchmarks]
| |
| # [https://public.cyber.mil/stigs/ DISA (Defense Information Systems) STIG (Security Technical Implementation)]
| |
| # [https://csrc.nist.gov/ NIST Computer Security Ressource Center]
| |
| # [https://www.bsi.bund.de/ Bundesamt für Sicherheit in der Informationstechnik]
| |
|
| |
| Blogs mit Konfigurationstipps
| |
| # https://www.hosteurope.de/blog/4-tipps-wie-sie-ihren-virtualserver-gegen-hacking-attacken-schuetzen/
| |
| # https://www.rechenkraft.net/wiki/Root_Server_absichern_(Ubuntu_14.04)
| |
|
| |
| Checklisten
| |
| # https://www.thomas-krenn.com/de/tkmag/expertentipps/linux-basierte-root-server-absichern/
| |
| # [[Medium:Linux-server-absichern-cheat-sheet-v1.0.pdf|Cheat Sheet]]
| |
|
| |
| {{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>
| |