Frühzeitiges Erkennen von Angriffen auf Active Directory mithilfe von „Deception“-Techniken

Die meisten Organisationen und Unternehmen verwenden das Active Directory in ihrer Infrastruktur als zentrale Lösung für die Verwaltung ihrer Ressourcen. Dabei stehen viele vor großen Herausforderungen bei der Absicherung und Stärkung dieser Active Directory-Umgebungen. Fehlendes Fachwissen, begrenzte Budgets, architektonische Herausforderungen aufgrund historisch-gewachsener Systemlandschaften sowie die daraus resultierende Notwendigkeit, Legacy-Systeme zu unterstützen, sind mögliche Ursachen für anfällige IT-Systeme.

Für Bedrohungsakteure stellt das Active Directory eine verlockende Zielscheibe dar, da eine erfolgreiche Kompromittierung in der Regel Zugang zu fast allen Unternehmensressourcen ermöglicht. Dies bietet Angreifern eine ideale Möglichkeit, z. B. Ransomware in das Netzwerk einzuschleusen, um finanzielle Forderungen stellen zu können.

Durch das Bekanntwerden von Schwachstellen im Active Directory besteht jederzeit die Gefahr, dass ganze Active Directory-Umgebungen ohne großen Aufwand kompromittiert werden können. Dabei ist es zunächst einmal unerheblich, über welchen Account oder über welche Schwachstelle der Einbruch gelungen ist. Denn ist den Angreifern der initiale Einbruch in das Firmennetzwerk gelungen, suchen sie nach sogenannten „Low-Hanging-Fruits“ innerhalb der Active Directory Umgebung, um Ihre Rechte auszuweiten.

Gerade für kleinere und mittelständische Unternehmen gestaltet sich das frühzeitige Erkennen von Angriffen auf das Active Directory als schwierig. Aufgrund der Firmengröße verfügen deren IT-Abteilungen in der Regel nicht über ein zureichendes Budget und die notwendigen Ressourcen für den Betrieb von Enterprise Security Lösungen wie SIEM oder EDRs. Doch gerade das rechtzeitige Erkennen von Angriffen ist entscheidend, um schnell zu reagieren und Schäden an der Reputation sowie finanzielle und datenschutzrechtliche Folgen zu vermeiden, bevor sie sich verschlimmern können.

Dennoch können mit Hilfe von „Deception“-Techniken auch Unternehmen, die lediglich über geringe IT-Security-Budgets verfügen, produktunabhängig bestimmte Angriffe wie Kerberoasting auf das Active Directory frühzeitig erkennen und deren Ausführung verzögern. Hierfür müssen gewisse Voraussetzungen erfüllt und präventive Maßnahmen bei der Nutzeranlage von sogenannten „Decoys“ getroffen werden. Diese „Decoys“ werden innerhalb einer Active Directory Umgebung platziert, um die Aufmerksamkeit von Angreifern auf diese zu ziehen, um so einen Alert auszulösen.


Praxisbeispiel: Anwendung von „Deception“-Techniken zur Erkennung von Kerberoasting Aktivitäten

Kerberoasting ist eine effiziente Technik für Angreifer, die lediglich über wenig Rechte innerhalb einer Domäne verfügen. Im Jahr 2014 präsentierte Tim Medin den Kerberoasting-Angriff bei seiner Präsentation „Attacking Microsoft Kerberos – Kicking the Guard Dog of Hades“ auf der Derbycon Konferenz. Beim Kerberoasting wird die Eigenheit bei der User-Anlage in Microsoft Kerberos ausgenutzt, dass jeder gültige Domain-User  einen Ticket Granting Server (TGS) für einen beliebigen Dienst beantragen und anschließend das Ticket für Offline-Passwort-Cracking-Versuche verwenden kann.

Je nach Stärke der Passwörter können Angreifer in kurzer Zeit und in den meisten Fällen relativ unbemerkt Benutzeraccounts kompromittieren und diese für weitere Angriffe verwenden.

Die einzige Voraussetzung für die Durchführung eines solchen Angriffs ist die Kenntnis über die existierenden Benutzerkonten, die einen sogenannten „Service Principal Name“ (SPN) gesetzt haben. Da alle existierenden SPNs mit einem simplen LDAP Query abgerufen werden können, stellt dies eine vergleichsweise geringe Einstiegsbarriere dar.

active directory deception
LDAP Query zum Extrahieren von allen Domain Accounts die einen SPN gesetzt haben

Gelingt es also dem Angreifer einzelne oder alle SPNs zu kennen, kann er im System Service Tickets (TGS) für ebenjene anfragen. Die durch die Abfrage erlangten Service-Tickets residieren im Arbeitsspeicher des Angreifers, aus welchem er diese anschließend extrahieren und auf einer Festplatte speichern kann. Nachdem der Eindringling nun über die TGS-Tickets aller Service Accounts verfügt, kann er versuchen, die verschlüsselten Teile der Tickets mit Hilfe eines Brute-Force-Angriffs zu entschlüsseln.

active directory deception
Cracking-Prozess von TGS-Tickets

Praktische Durchführung des Kerberoasting-Angriffs mit  GetUserSPNs.exe

Zur praktischen Ausnutzung der gefundenen Schwachstelle in Microsoft Kerberos stehen mehrere öffentlich verfügbare Tools bereit. Die bekanntesten sind das Python-Skript GetUserSPNs.py und das PowerShell-Script Invoke-Kerberoast. In diesem Beispiel verwendet unser fiktiver Angreifer GetUserSPNs.exe (eine statisch kompilierte Version von GetUserSPNs.py für Windows) für die Durchführung.

Um den Angriff möglichst realistisch zu beschreiben, verfügt der Angreifer in unserem Szenario zunächst lediglich über ein unprivilegiertes Benutzerkonto, um die TGS Tickets anzufordern und deren Hashes für den Cracking-Prozess zu extrahieren. Dieser Account ist jedoch für das Tool GetUserSPNs.exe bereits ausreichend.

active directory deception
Durchführung des Angriffs mit GetUserSPNs.py

Die gewonnene Ausgabedatei kann im Anschluss in jedes beliebige Passwort-Cracking Tool importiert werden, mit deren Hilfe ein Offline-Brute-Force Angriff auf die extrahierten Hashes durchgeführt wird. Der Vorteil von Offline-Cracking Angriffen besteht darin, dass sie selbst keine Spuren im System des angegriffenen Unternehmens hinterlassen und somit nicht entdeckt werden können. Darüber hinaus ermöglichen sie eine deutlich höhere Anzahl von Brute-Force-Versuchen pro Sekunde im Vergleich zu jeglichen Online-Angriffen.

hashcat -a 0 -m 13100 -O kerberoasted_impacket.txt /opt/wordlists/Top2Billion-probable-v2/Top2Billion-probable-v2.txt -r rules/hob064.rule
active directory deception
Erfolgreiches Cracking eines der extrahierten Hashes

Wie in der oberigen Abbildung sichtbar, war es dem Passwort-Cracking-Tool möglich, einen der extrahierten Hashes in die Klartextform zurückzurechnen. Dem Angreifer erlaubt die gewonnene Information die Kontrolle über den betroffenen Account und ermöglicht es ihm so, seine Rechte im Netzwerk auszuweiten.

Anzeichen eines Kerberoasting-Angriffs im Domain-Controller

Auch wenn Kerberoasting-Angriffe vergleichsweise unbehelligt erfolgen, gibt es doch einige Hinweise, die ein aufmerksamer Administrator im Domain-Controller selbst erkennen kann. Denn analysiert man die Logging-Aktivitäten auf dem Domain-Controller während eines Angriffs, dann fallen folgende Events auf:

active directory deception
Relevanter Auszug des Event-Logs während des Angriffs

Die oben beschriebene Anfrage eines TGS-Tickets für einen SPN hinterlässt in Form der erzeugten Event-ID 4769 ihre Spuren im angegriffenen System. Sieht man sich das erzeugte Event genauer an, findet man dort weite Angaben zum angefragten „Service Name“, dem „Ticket Encryption Type“ sowie der IP-Adresse des anfragenden Systems. Diese Attribute helfen, einen Angriff frühzeitig zu erkennen.

Integration einer „Deception“-Technik mittels „Honeypot“-Accounts

Auch wenn Kerberoasting-Angriffe die oben beschriebenen Spuren im System hinterlassen, ist es doch relativ unwahrscheinlich, dass ein Administrator diese sofort bemerkt und dementsprechend zeitnah agieren kann. Daher ist es sinnvoll bereits bei der Implementierung der Active Directory die Deception-Techniken mit einzuplanen und umzusetzen.

Hierfür werden sogenannte „Decoys“ – also ungenutzte „Honeypot“-Accounts – erstellt, die als leere Attrappen für potenzielle Angreifer dienen. Hierbei wird die Tatsache ausgenutzt, dass während eines Kerberoasting-Angriffs mehrere Anomalien in den Windows-Logs zu sehen sind. Insbesondere die Tatsache, dass die bekannten Tools standardmäßig SPN-Tickets für alle Accounts, die ein „SPN-Attribut“ gesetzt haben, anfordern (siehe Abbildung 1: LDAP Query zum Extrahieren von allen Domain Accounts die einen SPN gesetzt haben), kann als Frühwarnsystem verwendet werden.

Diese „Honeypot“-Accounts haben nämlich keine eigentliche Funktion im Active Directory und sollten im Regelfall nicht verwendet werden. Im „normalen“ Betrieb werden für diese also keine „TGS“-Tickets für den Service angefragt. Ist dies doch der Fall, handelt es sich mit hoher Wahrscheinlichkeit um den Versuch eines Kerberoasting-Angriffs.

Bei der Anlage des Honeypot-Accounts im Active Directory gelten einige Besonderheiten im Vergleich zu normalen Usern, wie der folgende PowerShell-Befehl zeigt:

New-ADUser -Name "DBAdmin" -DisplayName "DBAdmin" -SamAccountName "dbadm" -description "DatabaseAdministrationAccount" -UserPrincipalName "dbadm" -GivenName "Database" -Surname "Administrator" -AccountPassword ((ConvertTo-SecureString "kd329-/Sl2(2)02(§23kcJk3A$" -AsPlainText -Force)) -Enabled $true -Path "OU=ServiceAccounts, OU=AdministrativeAccounts, DC=WINDOMAIN, DC=LOCAL" -ChangePasswordAtLogon $false -PasswordNeverExpires $true

Im Anschluss kann mithilfe des „setspn“-Befehls eine SPN für den betroffenen Account gesetzt werden.

setspn -s http/wef.windomain.local:1433 windomain.local\dbadm

Nach Setzen des SPNs sollte folgende Meldung erscheinen:

active directory deception
Erstellung des Honeypot-Accounts und Setzen eines SPN

SPN-Anfragen für den Honeypot-Account mit Windows-Board-Mitteln frühzeitig erkennen

Wir verwenden in diesem Beispiel den Windows Event Viewer zur Erkennung eines potenziellen Angriffs, um zu demonstrieren, dass dies bereits mittels Standard-Funktionen innerhalb des Active Directorys bzw. Windows realisierbar ist. Selbstverständlich ist es auch möglich dies mittels Monitoring-Lösungen von Drittanbietern umzusetzen.

Der Windows Event Viewer bietet sich für das Tracking von Anomalien bei „Honeypot“-Accounts an, da dort sogenannte „Custom Views“ erstellt werden können, die nach spezifischen Events filterbar sind. Um Ticket-Anfragen des erstellten Honeypot Accounts herauszufiltern, kann folgende XML-Syntax verwendet werden:

<QueryList>
  <Query Id="0" Path="Security">
    <Select Path="Security">
         *[EventData[Data[@Name='ServiceName']  and (Data='dbadm')]]
         and
         *[System[(EventID='4769')]]
    </Select>
  </Query>
</QueryList>

Eine mögliche „Custom“-View würde bei einer SPN Ticket-Anfrage des Honeypot-Accounts wie folgt aussehen:

active directory deception
Custom-View zum Filtern von SPN-Anfragen für den angelegten Honeypot-Account

Die „Custom View“-Ansicht erlaubt neben der einfachen Anlage von Events auch die Einstellung von „geplanten Aufgaben“, die im Falle eines neuen Events für den im „Custom View“ eingestellten Filter ausgeführt werden.

Windows Event Viewer bietet dafür folgende bereits eingebaute Funktion an:

active directory deception
Erstellen eines Tasks in Bezug des erstellten “Custom Views”

In diesem Beispiel wird eingestellt, dass bei Auslösen des Events eine E-Mail an den „Administrator“ der AD-Umgebung gesendet wird.

active directory deception
Event Viewer Task führt ein PowerShell-Skript aus im Falle eines SPN-Requests für den betroffenen Account

Bei der Ausführung des Kerberoasting-Angriffs auf den Honeypot-Account erhält dieser eine E-Mail zur Alarmierung bei potenziell bösartigen Aktivitäten.

active directory deception
Automatisch versendete E-Mail nach der Anfrage eines SPN-Ticket für den “Honeypot”-Account

Fazit

Bereits mit einem geringen IT-Security-Budget ist es möglich, Angriffe wie Kerberoasting frühzeitig zu erkennen. Gelingt es, den Angriff zu verzögern oder im besten Fall sogar zu stoppen, können schlimmere Folgen für das Unternehmen abgewendet werden. Natürlich bilden derartige Alert-Systeme nur einen Baustein bei der Einführung und Umsetzung von Sicherheitssystemen, um die eigene IT-Infrastruktur zu schützen. Dennoch zeigt das Beispiel Kerberoasting, wie einfach und wirksam Deception-Techniken implementiert werden können.

Automatisierte Cyberangriffe: Kein System bleibt unberührt

Automatisierte Angriffe

Unabhängig von der Unternehmensgröße oder der Branche müssen alle Unternehmen damit rechnen das Ziel von Cyberangriffen zu werden. Diese Cyberattacken sind nicht nur zielgerichtet, sondern passieren zufällig sowie automatisiert. Bei der Inbetriebnahme eines neuen Servers zur Bereitstellung einer Schwachstellendatenbank, ist uns aufgefallen, dass bereits in den ersten 20 Stunden des Online-Betriebs des Servers fast 800 Anfragen auf dem Webserver geloggt werden konnten. In diesem Fachartikel werden wir genauer betrachten, welchen Ursprung diese Anfragen haben und aufzeigen, dass Angreifer längst nicht mehr nur bekannte Systeme und Unternehmen ins Visier nehmen. Natürlich geben wir auch konkrete Empfehlungen, um Systeme gegen diese Angriffe abzusichern.

Legitime Anfragen an die Schwachstellendatenbank (37%)

In einem ersten Schritt wollen wir alle Anfragen aus der Logdatei filtern, die reguläre Anfragen an die Schwachstellendatenbank darstellen und von uns zu Testzwecken ausgeführt wurden. Hierzu filtern wir alle bekannten Quell-IP-Adressen sowie gewöhnliche Anfragen auf bestehende Endpunkte. Die Schwachstellendatenbank stellt dabei die folgenden API Endpunkte für die Abfrage von Schwachstellendaten zur Verfügung:

  • /api/status
  • /api/import
  • /api/query_cve
  • /api/query_cpe
  • /api/index_management

Nach unserer ersten Analyse konnten wir feststellen, dass von insgesamt 724 Anfragen 269 Anfragen legitime Anfragen an die Schwachstellendatenbank darstellen:

Cyberangriffe Abbildung 1: Auszug legitimer Anfragen an den Webserver

 

Doch welchen Ursprung haben die verbleibenden 455 Anfragen?

Verzeichnisenummerierung von administrativen Backends für Datenbanken (14%)

Eine einzelne IP-Adresse fiel besonders auf: Mit 101 Anfragen versuchte ein Angreifer diverse Backends für die Datenbankadministrierung zu finden:logs 2 cut

Abbildung 2: Scannen von Verzeichnissen um Datenbank-Backends zu finden

Schwachstellenscans unbekannter Quellen (14%)

Weiterhin konnten wir 102 Anfragen identifizieren, bei denen unsere Versuche die Quell-IP-Adressen zu identifzieren (mittels nslookup, user-agent) erfolglos waren. Die 102 Anfragen stammen von 5 verschiedenen IP-Adressen oder Subnetzbereichen. Somit wurden pro Schwachstellenscan ca. 20 Anfragen ausgeführt.

logs 3 cut

Abbildung 3: Verschiedene Schwachstellenscans mit unbekannter Herkunft

Geprüfte Komponenten waren dabei:

  • boaform Admin Interface (8 Anfragen)
  • /api/jsonws/invoke: Liferay CMS Remote Code Execution und andere Exploits

 

Anfragen auf / (11,5%)

Insgesamt konnten wir 83 Anfragen feststellen, die die Index-Datei des Webservers angefragt haben. Diese dienen zur Ermittlung, ob ein Webserver online ist und zur Identifikation, welcher Dienst initial zurückgegeben wird.

logs 4

Abbildung 4: Index-Anfragen verschiedener Quellen

Hierbei konnten wir verschiedene Anbieter und Tools identifizieren, die unseren Webserver auf Erreichbarkeit geprüft haben:

Schwachstellenscans von leakix.net (9%)

Während unserer Auswertung der Logdatei konnten wir weitere 65 Anfragen identifzieren, die von zwei IP Adressen stammen, die in Ihrem User-Agent die Adresse “leakix.net” nennen:

logs 5

Abbildung 5: Schwachstellenscan von leakix.net

Auf der Seite selbst wird erklärt, dass der Dienst das gesamte Internet zufällig auf bekannte Schwachstellen durchsucht:

logs 6

Abbildung 6: leakix.net – About

HAFNIUM Exchange Exploits (2,8%)

Des Weiteren konnten wir 20 Anfragen identifizieren, die versuchen verschiedene Teile der HAFNIUM Exchange Schwachstellen auszunutzen oder aufzuspüren. (Gängige IOCs lassen sich z.B. finden unter https://i.blackhat.com/USA21/Wednesday-Handouts/us-21-ProxyLogon-Is-Just-The-Tip-Of-The-Iceberg-A-New-Attack-Surface-On-Microsoft-Exchange-Server.pdf):

  • autodiscover.xml: Versuch, das Administratorkonto des Exchange Servers zu ermitteln
  • \owa\auth\: Ordner in den Shells nach einer Kompromittierung für weiteren Fernzugriff geladen werden

logs 7

Abbildung 7: Versuchte Ausnutzung der HAFNIUM/Proxlogon Exchange Schwachstellen

NGINX .env Preisgabe von sensitiven Informationen der Serverumgebung (1,5%)

11 Anfragen haben versucht die .env Datei im Webserver Wurzelverzeichnis auszulesen. Diese Datei kann oft sensitive Umgebungsvariablen (und Passwörter) enthalten.

logs 8

Abbildung 8: Versuch die .env Datei des Servers auszulesen

 

Verbleibende Anfragen (10,2%)

Weitere 58 Anfragen waren nicht Teil eines größeren Scans und haben gezielt einzelne Schwachstellen abgefragt:

  • Server-Side Request Forgery Versuche: 12 Anfragen
  • CVE-2020-25078: D-Link IP Kamera Admin Passwort Exploit: 9 Anfragen
  • Hexkodierte Exploits/Payloads: 5 Anfragen
  • Spring Boot: Actuator Endpunkt zur Darstellung von Serverinformationen: 3 Anfragen
  • Netgear Router DGN1000/DGN2200: Remote Code Execution Exploit: 2 Anfragen
  • Open Proxy CONNECT: 1 Anfrage

  • Verschiedene einzelne Exploits oder Schwachstellentests: 27 Anfragen

Weiterhin wurden die folgenden harmlosen Dateien angefragt:

  • favicon.ico – Lesezeichen-Grafik: 7 Anfragen
  • robots.txt – Datei für Suchmaschinenindizierung: 9 Anfragen

Fazit

Mit Tools wie zmap scannen Angreifer das gesamte Internet in unter 5 Minuten (siehe https://www.usenix.org/system/files/conference/woot14/woot14-adrian.pdf). Die aufgeführten Statistiken haben gezeigt, dass IT-Systeme ein unmittelbares Ziel automatisierter Angriffe und Schwachstellenscans sind, sobald diese von außen aus dem Internet erreichbar sind. Die Größe eines Unternehmens oder der Bekanntheitsgrad spielen hierbei keine Rolle, da Angreifer das komplette Internet nach anfälligen Hosts durchforsten und oftmals den vollständigen IPv4-Adressraum abdecken. Selbst unter Einsatz herkömmlicher IT-Infrastrukturkomponenten wie z.B. Reverse Proxies oder Load Balancers, die lediglich unter Angabe eines validen Hostnamens eine Anwendung zurückgeben, können sich automatisierte Angriffe ereignen. Der Hostname ist nämlich, wie oftmals fälschlicherweise angenommen, kein Geheimnis bzw. ein ausreichender Schutz vor unautorisierten Zugriffen. Bereits bei der Anforderung von SSL-Zertifikaten für Ihre Dienste und Applikationen werden Hostnamen in sogenannten SSL-Transparency-Logs protokolliert und stehen öffentlich zur Einsicht verfügbar. Hierdurch können sich erneut automatisierte Angriffe ereignen, da die Hostnamen durch Online-Dienste wie crt.sh öffentlich in Erfahrung gebracht werden können. Weitere Informationen finden Sie in unserem Fachartikel Subdomains unter der Lupe: SSL Transparency Logs.

Die Implementierung von Zugriffskontrollen oder Härtungsmaßnahmen zum Schutz vor unautorisierten Handlungen in Ihren Diensten und Anwendungen muss demnach noch vor der eigentlichen Veröffentlichung im Internet erfolgen. Denn sobald ein IT-System im öffentlichen Internet erreichbar ist, müssen Sie mit aktiven Angriffsversuchen rechnen, die im schlimmsten Fall Erfolg haben könnten.

Empfehlung

Lediglich notwendige Netzwerkdienste bereitstellen

Bei der Veröffentlichung von IT-Systemen in das öffentlich erreichbare Internet sollten lediglich diejenigen Netzwerkdienste preisgegeben werden, die für den Geschäftszweck notwendig sind und nach außen hin offenbart werden müssen. Bei dem Betrieb einer Webanwendung oder Dienst auf Basis des HTTP-Protokolls ist dies in der Regel der eingesetzte Webserver, dessen Netzwerkdienst üblicherweise über den TCP-Port 443 angeboten wird.

Halten Sie davon Abstand, den kompletten Host, also alle verfügbaren Netzwerkdienste eines IT-Systems, im Internet preiszugeben.

Netzwerktrennung

Implementieren Sie eine demilitarisierte Zone (DMZ) mittels Firewalls, um eine zusätzliche Netztrennung zwischen dem öffentlichen Internet und Ihrer internen IT-Infrastruktur zu erhalten. Platzieren Sie alle Infrastrukturkomponenten, welche Sie nach außen ins Internet preisgeben möchten, in der dafür entworfenen DMZ. Weitere Informationen finden Sie im IT-Grundschutz-Katalog des Bundesamts für Sicherheit in der Informationstechnik (BSI).

Patch-Management und Inventarisierung

Halten Sie alle Softwarekomponenten auf einem aktuellen Stand und richten Sie einen Patch-Management-Prozess ein. Führen Sie eine Inventarisierung über alle IT-Infrastrukturkomponenten ein, unter Auflistung der eingesetzten Softwareversionen, virtuellen Hostnamen, SSL-Zertifikatsablauf, Konfigurationseinstellungen und Co.

Weitere Informationen finden Sie unter: http://www.windowsecurity.com/uplarticle/Patch_Management/ASG_Patch_Mgmt-Ch2-Best_Practices.pdf

Härtungsmaßnahmen

Härten Sie Ihre offenbarten Netzwerkdienste und IT-Komponenten nach Angaben des Herstellers bzw. den spezifischen Härtungsempfehlungen des Center for Internet Security (CIS). Ändern Sie zudem alle Standardpasswörter oder einfache Logins aus der Entwicklungszeit ab und konfigurieren Sie Ihre Dienste für den produktiven Betrieb. Dazu gehört ebenfalls die Deaktivierung von Debug-Features oder Test-API-Endpunkte. Implementieren Sie weiterhin alle empfohlenen HTTP-Response-Header und härten Sie Ihre Webserver-Konfiguration. Stellen Sie sicher, dass sensitive Cookies über das Secure, HttpOnly und SameSite Cookie-Flag verfügen, falls möglich.

Transportverschlüsselung

Achten Sie darauf, Ihre Netzwerkdienste über einen verschlüsselten Kommunikationskanal anzubieten. Dies stellt die Vertraulichkeit und Integrität von Daten sicher und sorgt dafür, dass die Authentizität Ihres Servers validiert werden kann. Halten Sie Abstand von der Verwendung von veralteten Algorithmen wie RC4, DES, 3DES, MD2, MD4, MD5 oder SHA1. Verwenden Sie SSL-Zertifikate, welche von einer vertrauenswürdigen Zertifizierungsstelle ausgestellt worden sind, wie z.B. von Let’s Encrypt. Halten Sie Ihre Zertifikate fortlaufend aktuell und erneuern Sie diese frühzeitig. Verwenden Sie für jeden Ihrer Dienste ein einzigartiges SSL-Zertifikat unter Nennung des korrekten (Sub)Domainnamen im Common Name des Zertifikats. Die Verwendung von SSL-Wildcard-Zertifikaten ist lediglich in seltenen Fällen notwendig und zu empfehlen.

Zugriffsschutz und zusätzliche Sicherheitslösungen

Beschränken Sie den Zugriff auf Ihre Netzwerkdienste, sollten diese nicht für alle Teilnehmer im öffentlichen Internet zur Verfügung stehen. Hierbei kann es sich anbieten, ein IP-Whitelisting einzurichten, wodurch lediglich Anfragen von vertrauenswürdigen, statischen IPv4-Adressen entgegengenommen werden. Konfigurieren Sie dieses Verhalten entweder in Ihrer eingesetzten Firewall-Lösung oder unmittelbar in dem bereitgestellten Netzwerkdienst, falls möglich. Alternativ können auch SSL-Client-Zertifikate oder Basic-Authentication eingerichtet werden.

Implementieren Sie für Ihre Netzwerkdienste zusätzliche Sicherheitslösungen wie Intrusion Prevention Systeme (IPS) oder eine Web Application Firewall (WAF), um einen zusätzlichen Schutz gegenüber Angriffen zu erhalten. Als IPS können wir die quelloffene Software Fail2ban empfehlen. Als WAF kann ModSecurity mit dem bekannten OWASP Core Rule Set eingerichtet werden.

Fail2ban ist ein in Python geschriebenes Intrusion Prevention System, welches auf Basis von Protokolleinträgen (Logs) und Regex-Filtern auffällige Aktivitäten identifizieren und automatische Maßnahmen ergreifen kann. So ist es z.B. möglich, automatisierte Schwachstellenscans, Brute-Force-Angriffe oder Bot-basierte Anfragen erfolgreich zu erkennen, blockieren und Angreifer mittels IP-Tables zu bannen. Fail2ban ist eine quelloffene Software und kann kostenfrei eingesetzt werden.

  • Installation von Fail2ban
    • Fail2ban kann in der Regel über die reguläre Paket-Verwaltung Ihrer Linux-Distribution installiert werden. Dazu genügt der folgende Befehl:
sudo apt update && sudo apt install fail2ban
    • Danach sollte der Fail2ban-Dienst automatisch gestartet worden sein. Überprüfen Sie dies mittels des folgenden Befehls:
sudo systemctl status fail2ban
  • Konfiguration von Fail2ban
    • Nach der Installation von Fail2ban steht ein neues Verzeichnis namens /etc/fail2ban/ zur Verfügung, worunter alle relevanten Konfigurationsdateien vorgefunden werden können. Standardmäßig werden zwei Konfigurationsdateien /etc/fail2ban/jail.conf und/etc/fail2ban/jail.d/defaults-debian.conf mitgeliefert. Diese sollten jedoch nicht bearbeitet werden, da sie bei einer Paketaktualisierung überschrieben werden können.
    • Stattdessen sollten spezifische Konfigurationsdateien mittels der .local Erweiterung angelegt werden. Konfigurationsdateien mit dieser Dateierweiterung überschreiben Direktiven in der übergeordneten .conf Konfigurationsdatei. Für die meisten Benutzer ist der einfachste Konfigurationsweg die mitgelieferte Datei jail.conf nach jail.local zu kopieren und anschließend die .local-Datei abzuändern. Die .local-Datei muss hierbei nicht alle Einstellungen aus der .conf-Datei enthalten, sondern nur diejenigen, die Sie überschreiben möchten.
  • Fail2ban für SSH
    • Nach der Installation von Fail2ban ist standardmäßig bereits der Schutz für den Netzwerkdienst SSH auf dem default TCP-Port 22 aktiv. Sollten Sie einen anderweitigen TCP-Port für Ihren SSH-Netzwerkdienst einsetzen, so müssen Sie die Konfigurationseinstellung port in Ihrer jail.local Datei für die SSH-Jail anpassen. Hier können Sie ebenfalls wichtige Direktiven wie findtime, bantime und maxretry anpassen, sollten Sie eine spezifischere Konfiguration benötigen. Sollten Sie diesen Schutz nicht benötigen, so können Sie ihn über die Direktive enabled auf den Wert false setzenWeitere Informationen finden Sie unter: https://wiki.ubuntuusers.de/fail2ban/
  • Fail2ban für Webdienste
    • Weiterhin kann mittels Fail2ban ein Schutz vor automatisierten Webangriffen eingerichtet werden. Hierbei können beispielsweise Angriffe zur Enumeration von Webverzeichnissen (Forceful Browsing) oder bekannte Anfragen von Bots zur Durchführung von Schwachstellenscans erkannt und blockiert werden.
    • Die Community stellt hierfür bereits vorgefertigte Konfigurationsdateien zur Verfügung, welche verwendet werden können:
    • Legen Sie diese beispielhaften Filter-Konfigurationen in dem Verzeichnis /etc/fail2ban/filter.d/ ab und konfigurieren Sie eine neue Jail in Ihrer jail.local Datei. Ein Beispiel folgt.
  • Blockieren von Suchanfragen durch Bots
    • Automatisierte Bots und Schwachstellenscanner durchforsten fortlaufend das gesamte Internet, um anfällige IT-Hosts zu identifizieren und Exploits auszunutzen. Hierbei kommen oftmals bekannte Tools zum Aufdecken solcher Schwachstellen zum Einsatz, dessen Namen bei HTTP-Anfragen im User-Agent HTTP-Header mitgeschickt werden. Anhand diesem Header können viele einfache Bot-Angriffe erkannt und aktiv blockiert werden. Angreifer können diesen Header jedoch auch abändern, wodurch ausgeklügelte Angriffe unentdeckt bleiben. Die Fail2ban-Filter *badbots.conf sind in der Regel solche Filter, die auf dem HTTP-Header “User-Agent” basieren. 
    • Alternativ bietet es sich an, alle Anfragen zu verwerfen, welche ein typisches Angriffs-Muster an den Tag legen. Dazu gehören unter anderem automatisierte Anfragen, welche fortlaufend versuchen, Dateien oder Verzeichnisse auf einem Webserver zu identifizieren. Da diese automatisierten Angriffe eine Vielzahl von Dateien und Verzeichnisnamen zufällig anfragen, ist die Wahrscheinlichkeit gegeben, dass viele dieser Versuche ins Leere führen und eine 404 Not Found Fehlermeldung verursachen. Anhand dieser Fehlermeldungen und dazugehörigen Logs kann Fail2ban einen Angriffsversuch erkennen und das Angreifer-System frühzeitig bannen.
    • Hier am Beispiel eines nginx Webservers:

1. Speichern Sie die folgende Datei unter /etc/fail2ban/filter.d/nginx-botsearch.conf

https://github.com/fail2ban/fail2ban/blob/master/config/filter.d/nginx-botsearch.conf

2. Fügen Sie die folgenden Konfigurationsanweisungen in Ihrer /etc/fail2ban/jail.local ein:

[nginx-botsearch]
ignoreip = 127.0.0.0/8 10.0.0.0/8 172.16.0.0/12 192.168.0.0/16
enabled = true
port = http,https
filter = nginx-botsearch
logpath = /var/log/nginx/access.log
bantime = 604800 # Bann für 1 Woche
maxretry = 10 # Bann bei 10 Fehlermeldungen
findtime = 60 # zurücksetzen von maxretry nach 1 Minute

3. Inkludieren Sie falls nötig weitere vertrauenswürdige IP-Adressen unter ignoreip Ihres Unternehmens, welche von Fail2ban erlaubt und nicht blockiert werden sollen. Passen Sie ggf. die anderweitigen Direktiven auf Ihre Wünsche hin an und verifizieren Sie den angegebenen Port Ihres Webservers sowie dass der Logpfad  /var/log/nginx/access.log vorhanden und ausgelesen werden kann.

4. Starten Sie anschließend den Fail2ban-Dienst neu

sudo systemctl restart fail2ban

Bei automatisierten Suchanfragen zum Auffinden von Verzeichnissen und Dateien können nun Bots gebannt werden, welche mehr als zehn 404-Fehlermeldungen innerhalb einer Minute erzeugen. Die IP-Adresse des angreifenden Systems wird anschließend von Fail2ban mittels IP-Tables automatisch für eine Woche gebannt und anschließend automatisch wieder freigegeben. Auf Wunsch können Sie sich durch weitere Konfigurationseinstellungen per E-Mail über IP-Banns informieren lassen. Eine Push-Benachrichtigung ans Smartphone über einen Telegram-Messenger-Bot in Fail2ban ist ebenfalls denkbar. Allgemein ist Fail2ban sehr anpassbar und erlaubt beliebig viele banactions, wie z.B. selbst entwickelte Shell-Skripte, sollte ein Filter greifen

Um bereits gebannte IP-Adressen anzeigen zu lassen, verwenden Sie den folgenden Befehl:

  • Verfügbare Jails anzeigen lassen
sudo fail2ban-client status
  • Gebannte IP-Adresse der Jail anzeigen
sudo fail2ban-client status 

Fail2ban bietet viele weitere Möglichkeiten, um Ihre Dienste zusätzlich abzusichern. Informieren Sie sich gerne über zusätzliche Filter und implementieren Sie diese, falls gewünscht. Alternativ können Sie auch eigene Filter unter Verwendung von Regex kreieren und diese auf Logeinträge testen.

Hier können Sie weitere vorgefertigte Fail2ban-Filterlisten entdecken: https://github.com/fail2ban/fail2ban/tree/master/config/filter.d