Sicherheit administrativer Dienste und Logins im Internet – Schwerpunkt SSH

Im Zuge unserer Sicherheitsüberprüfungen und Pentests auf Internet-erreichbare Systeme stolpern wir immer wieder über das Thema Sicherheit administrativer Dienste und die damit zusammenhängenden Risiken.

Ist ein System aus dem Internet erreichbar, dann kann jede mit dem Internet verbundene Person grundsätzlich darauf zugreifen – das sind mal sehr, sehr viele. Das bedeutet auch, dass wir eine hohe Eintrittswahrscheinlichkeit haben, dass jemand diesen Dienst finden und angreifen kann. Mit ein paar wenigen Schritten verbessern Sie die Sicherheit administrativer Dienste und deren Widerstandsfähigkeit gegenüber den permanenten Angriffen aus dem www.

Der Angreifer

„Wieso sollte uns jemand angreifen?“ – Ich glaube jeder Berater im Bereich der IT- / Informationssicherheit kennt diese und ähnliche Sätze:

Wir sind doch viel zu { klein | uninteressant | … } und
haben doch sowieso keine { Geheimnisse | schützenswerten Daten | interessanten Informationen | … }.
Außerdem würde doch wenn dann jemand eher unsere Mitbewerber angreifen – die sind doch viel { größer | interessanter | … }.

Ertappt? Schluss damit! Ja, für staatlich unterstützte Hacker mag das gelten. Und auch ja: Industriespionage ist kein Thema für jede Firma. Vielen Angreifern ist Ihre Firma im ersten Schritt des Angriffs aber egal! Die Sicherheit administrativer Dienste ist ein must-have für jede Firma und zwingender Teil jedes Schwachstellenscans und Pentests.

Try and Error – Passwort-basierte Angriffe auf beliebige Ziele

Nehmen wir mal an, Sie haben einen administrativen SSH-Port im Internet. Was glauben Sie, wie lange es dauert, bis jemand versucht sich dort anzumelden?

Länger als 10 Minuten wird es nicht dauern. Im Zuge unserer Research-Tätigkeiten haben wir uns das Thema mal näher angesehen und verschiedene Honeypots aufgebaut. Ein Beispiel hierzu ist unser SSH-Honeypot in AWS:

Beliebige IPv4-Addresse aus dem AWS-IP-Adressbereich
Kein eingetragener DNS-Name (außer der AWS-Reverse-DNS-Eintrag)
Keine Zuordnung zu einer bestimmten Firma über den IP-Adressbereich möglich
Passwort-Authentifizierung erlaubt
SSH standardmäßig auf Port 22
Keine weitere Konfiguration von Schutzmaßnahmen

Nach Freischaltung der Firewall hat es im letzten Versuch rund 15 Minuten gedauert, bis die ersten Login-Versuche da waren: Natürlich auf den root-Benutzer.

Betrachten wir die Zahlen vom März 2021, dann sieht es so aus :

insgesamt gab es 743054 Anmeldeversuche,
bei denen 5526 verschiedene Anmeldenamen ausprobiert wurden,
wobei 60753 individuelle Passwörter zum Einsatz kamen.

Dabei sind die versuchten Benutzernamen und Passwörter durchaus nicht mehr nur „root:root“, wie die nachfolgende Abbildung exemplarisch zeigt. Wer also bisher die Sicherheit administrativer Dienste ausschließlich durch Änderung des Benutzernamens und die Wahl eines komplizierten Passworts erhöht hat, sollte unbedingt einen Blick in die typischen Namensliste der fortwährenden Brute-Force-Angriffe werfen – oder bis zum Ende lesen 🙂 !

In diesem Schritt ist es einem Angreifer übrigens vollkommen egal, wer das System betreibt oder was drauf ist: Ist SSH aus dem Internet erreichbar, dann wird es auch angegriffen. Täglich. In der Regel mehrfach!

Das gilt natürlich auch für über die Sicherheit administrativer Dienste und Protokolle wie SSH hinaus, z. B. auch für RDP, FTP, MySQL, … – Ende April haben wir nach nur wenigen Minuten sowohl für MySQL als auch RDP mehrere Zugriffsversuche festgestellt.

Ein Netzwerk- oder Schwachstellenscan kann beim Identifizieren solcher offener Dienste helfen. Hierzu reicht schon der geübte Umgang mit nmap – oder ein professioneller Security Partner.

Die andere Art von Angriffen – Ausnutzung bekannter Schwachstellen

Angriffe auf die Authentifizierung gibt es permanent. Aber nicht nur die – wie wirklich jeder spätestens seit der „ProxyLogon„-Lücke im Microsoft Exchange Server mitbekommen haben sollte. Werden Dienste mit bekannten Schwachstellen im Internet betrieben, dann werden sie auch angegriffen und erfolgreich kompromittiert. Oftmals sehr, sehr schnell.

Neue bekannte Schwachstellen gibt zehntausende pro Jahr. Jede davon kann potentiell ausgenutzt werden, um ein System anzugreifen, das nicht geupdated ist.

Sie patchen immer sofort und haben daher kein Problem? Na gut, treten wir noch etwas auf Microsoft und den Exchange Server ein:

08.02.2021
- Offizielle Vergabe der CVE-Nummern, also Bestätigung der Existenz der Schwachstelle (Microsoft kannte deren Existenz)
02.03.2021
- Notfallpatch durch Microsoft öffentlich bereitgestellt
03.03.2021 – 13:01 Uhr
- Erste Warnung des BSI vor aktiver Ausnutzung der Schwachstelle
07.03.2021: Veröffentlichung erster lauffähiger Exploits auf Github, die es jedem Script-Kiddie ermöglichen, die Systeme anzugreifen
- Hinweis: Microsoft (Besitzer von GitHub) hat mehrfach Exploit-Code von seiner Plattform entfernt und die Accounts der Forscher / Security Experten gesperrt. Es kann also durchaus schon früher lauffähige Exploits im Umlauf gegeben haben
12.03.2021 – 15:46
- Erste Nachrichten über Ausnutzung der Schwachstelle durch Ransomware-Gruppen

Selbst wenn Sie also Ihre Exchange-Server direkt am Tag der Veröffentlichung gepatcht haben, kannten Angreifer bereits seit über vier Wochen einen Weg, den Server zu übernehmen.

Und – mal ganz ohne auf Microsoft einzuprügeln: So ist eben der normale Verlauf vieler Patches: Ein Angreifer oder Forscher findet die Schwachstelle, meldet sie – oder nutzt sie aus – der Hersteller erstellt ein Update und veröffentlicht dieses — irgendwann.

Juhu, ich bin drin – und jetzt?

Wer die „guten alten“ Zeiten noch kennt, in denen solche Angriffe von Script-Kiddies durchgeführt wurden, die anschließend Stolz in einem Forum verkündet haben, dass sie es geschafft haben, dem sei gesagt: die Zeiten sind vorbei.

Angriffe sind professioneller und zielgerichteter geworden. Wenn heute ein Angreifer erfolgreich in ein System eindringt, dann kann es auch eine Ransomware-Gruppe sein – die haben sich in der „grausigen“ neuen Zeit aktuell u.a. auf RDP-Ports eingeschossen

Der Schaden, wenn ein Angreifer erfolgreich ist kann also enorm sein: Von der Veröffentlichung der gestohlenen Daten über die weitere Kompromittierung des Firmennetzwerks bis hin zu Erpressungsversuchen.

Absicherung – mit Hausmitteln

Erlangt ein Angreifer Zugriff auf eine Anwendung oder ein System mit administrativen Berechtigungen, dann sitzt das Kind ganz schön tief im Brunnen: Kundendaten weg. Passwörter kompromittiert. „Vertrauenswürdiges“ System übernommen.

Um das zu verhindern oder zumindest zu erschweren, helfen mehrere Ansätze.

Abschottung – Muss das wirklich Internet-erreichbar sein?

Der einfachste Weg Angriffe auf Dienste aus dem Internet zu vermeiden ist sicherlich: stellt die Dienste nicht ins Internet! Das Thema ist ein ständiges Ärgernis in den Abschlussdiskussionen zu unseren Pentests. Wenn ein Anwendungsserver eine Datenbank braucht, dann muss die nicht über das Internet erreichbar sein, sondern nur innerhalb der Anwendungslandschaft. Nur, weil der Postbote einen Brief in den Briefkasten werfen möchte, lassen Sie ja auch nicht die Wohnungstür offen stehen. Und wenn der Anbieter ein Shared-Hoster oder 0815-Consumer-Provider ist, der die Konfiguration nicht anpassen lässt, dann taugt er eben nicht für den Unternehmenseinsatz! Punkt.

Wer hier mit Firewalls und co. ausgerüstet ist, der kann solche Konfigurationsanpassungen gut zentral lösen. Aber auch bei einfachen Linux-Servern in der Cloud lassen sich:

die Listener der Datenbank auf Localhost begrenzen,
die IPtables des Betriebssystems so konfigurieren, dass nur Web-Dienste erreichbar sind oder
die Netzwerkfilter der Cloud-Anbieter so einstellen, dass Zugriffe auf das System nur über die Web-Dienste möglich ist:

Nachfolgend ein Beispiel aus unserer Azure-Umgebung, wie die Sicherheit administrativer Dienste erhöht wird:

Im obigen Beispiel wird der SSH-Zugriff über Azure Network Security Groups nur auf die tatsächlich benötigten Quell-Adressen eingeschränkt. Für Datenbanken geht das gut. Für andere Dienste, auf die jemand über das Netzwerk zugreifen muss vielleicht nicht. Aber dafür gibt es ja noch VPN-Lösungen und SSH-Tunnel.

Ob schwache Authentifizierung oder Schwachstelle im Dienst: So, kommt keiner ran um irgendetwas zu probieren.

Ein bisschen im Internet – IP-Restriction

Aber was, wenn die Dienste wirklich aus der Ferne benötigt werden? Beispielsweise der Login für das CMS oder der Root-Zugriff per SSH?

Klar, das ist ein valider Anwendungsfall. Aber muss wirklich jede IP-Adresse von überall auf der Welt den Zugriff haben?

Denken wir in Eintrittswahrscheinlichkeiten. Sagen wir, Sie haben einen verwundbaren Dienst. Die Schwachstelle ist 1% aller Internet-Nutzer bekannt.

Nehmen wir an, es könnten Internet-Nutzer von 4.294.967.296 (2³²) IP-Adressen grundsätzlich den verwundbaren Dienst ansprechen. Oder oder nur 10.000 IP-Adressen – oder nur 10.

IP-Beschränkungen reduzieren die Wahrscheinlichkeit, dass einer der bösen Nutzer dort draußen den Dienst überhaupt erreicht. Die meisten Firmen haben irgendwo eine statische IP-Adresse, die sich für solche Fälle hinterlegen lässt.

Und bitte: Schluss mit dem Märchen des IP-Spoofings über TCP – ja, Sie können Pakete mit beliebiger Absenderadresse über das Internet verschicken: Nein, die Antwort wird niemals bei Ihnen ankommen, weswegen niemals ein TCP-Handshake zu Stande kommt und niemals eine Interaktion mit dem Dienst oder der Anwendung über das Internet möglich ist.

Frei im Internet – aber sicher

Wenn alles nicht mehr hilft und der Dienst im Internet stehen muss, dann aber bitte wenigstens so gut es geht geschützt: Eintrittswahrscheinlichkeit für das Worst-Case-Ereignis reduzieren! Insbesondere in der Linux-Welt ist das in der Regel recht einfach und mit Bordmitteln möglich. Das einfache Dreigespann aus fail2ban, iptables und einer sicheren Dienstekonfiguration hilft hier das Schlimmste in der Regel zu verhindern.

Hier ein Beispiel, wie wir einen SSH-Dienst auf einem Debian Webserver absichern können:

Installation & Konfiguration von fail2ban:
- fail2ban untersucht die Logs der konfigurierten Dienste und fügt dynamisch Sperren auf IP-Adressebene zu
- Für SSH und viele Standarddienste gibt es vordefinierte Konfigurationen
- Auch für WordPress o.ä. lässt sich fail2ban nutzen
Konfiguration von iptables (o.ä.):
- Logging:
  iptables -N LOG21
  iptables -A INPUT -p tcp –dport 21 -j LOG21
  iptables -A LOG21 -m limit –limit 2/min -j LOG –log-prefix „fw-drop-ftp-21: “ –log-level 1
  (Erzeugt einen Logeintrag für Aufrufe auf ungewünschten Ports)
- Kein SSH, kein RDP? Dann Aufrufversuche direkt unterbinden:
  iptables -N FTP_BLACKLIST
  iptables -A INPUT -m state –state NEW -p tcp –dport 21 -j FTP_BLACKLIST
  iptables -A FTP_BLACKLIST -m recent –set –name FTP
  iptables -A FTP_BLACKLIST -m recent –update –seconds 600 –hitcount 1 –name FTP -j DROP
  (Sperrt jede IP, die FTP anfrage für 10 Minuten komplett aus: Weitere typische Port – alles was im Portscan vor kommt)
- SSH muss erreichbar sein? Dann maximale Anzahl Anfragen auf den Dienst begrenzen (Erhöht den Schutz bei Schwachstellen im Dienst)
  iptables -A INPUT -p TCP –dport 42322-j ACCEPT
  iptables -A INPUT -p tcp –dport 42322-m state –state NEW -m recent –set –name SSH42322-j ACCEPT
  iptables -A INPUT -p tcp –dport 42322-m recent –update –seconds 62 –hitcount 3 –rttl –name SSH42322 -j DROP
  (Lässt noch 3 neue Verbindungsversuche pro Minute auf SSH zu)
Konfiguration der wesentlichen SSH-Parameter:
- PermitRootLogin no
- Port 42322
- PubkeyAuthentication yes
- PasswordAuthentication no

Übrigens: Das direkte Aussperren bei Verbindungsversuchen zu bestimmten Ports lässt sich bequem auf die übliche Liste der Portscanner um alle Ports erweitern, die Sie nicht tatsächlich selber benötigen, z. B.: 20,21,22,2022,80,8080,445,3306,3389,…

Glauben Sie mir: Wenn Sie eine derartige Konfiguration strikt umsetzen, verderben Sie einem Angreifer enorm den Spaß – das gilt auch für einen Schwachstellenscan oder Pentest auf derart gehärtete Dienste! Unserem Ziel, der Reduktion der Eintrittswahrscheinlichkeit des Worst-Case kommen wir so auch deutlich näher: Ein Angreifer kann nur genau eine Verbindung aufbauen, bevor er für z. B. 10 Minuten das System überhaupt nicht mehr erreichen kann. Im „Standard-Portscan“ wird das System dann schnell als nicht erreichbar markiert.

Auf Anwendungsebene, z. B. im WordPress, helfen neben fail2ban und der Absicherung der URLs auch Security Plugins Cerber oder All in One WP Security & Firewall – wenn sie richtig konfiguriert sind. Die Sicherheit administrativer Dienste von CMS-Systemen ist aber noch mal ein eigenes Kapitel. Komplizierter wird es in der Windows-Welt, sofern ein Windows-PC direkt aus dem Internet zugreifbar sein muss – hier wird es bei der Sicherheit administrativer Dienste mit Bordmitteln eng. Also: kein RDP im Internet bleibt die beste Grundregel zum Schutz vor bösartigen Angreifern! Das gilt einerseits natürlich wegen möglicher Schwachstellen in RDP bzw. Windows selbst, andererseits wegen der in der Regel fehlenden Multifaktor-Authentifizierung: Und Benutzerpasswörter sollten nicht der Schlüssel zu Ihren Daten sein!

Am Ende benötigt ein Angriff auf Passwörter mit Brute-Force-Verfahren zwar immer viele Anfragen – bei Password-Stuffing-Angriffen oder der Ausnutzung von erbeuteten Passwörtern aus Phishing-Attacken ist die Anzahl Anfragen und damit die Auffälligkeit solcher Angriffe deutlich geringer.

VPN und SSH-Tunnel

Blicken wir kurz ein par Jahre zurück, als Server noch im Keller des eigenen Rechenzentrums standen und der Perimeter der mächtigste Schutz vor Angriffen war.

Die Zeiten sind um – Entwicklungen wie SDWAN machen das immer deutlicher. Dennoch sollte die Sicherheit administrativer Dienste nicht durch deren Veröffentlichung im Internet erprobt werden. VPN- und SSH-Tunnel bieten einen enormen Vorteil: Verringerung der Angriffsfläche und damit Verringerung der Eintrittswahrscheinlichkeit des Worst-Case-Scenarios. Und hiermit sind auch unsere „Problemkinder“, die Windows-Clients und deren RDP-Verbindungen durchaus gut abzusichern. Ob OpenVPN als kostenfreie Lösung für einzelne Anwendungsfälle oder SSH-Tunnel für administrative Benutzer: mit etwas Aufwand sind auch ohne Enterprise-Equipment genug Möglichkeiten vorhanden, Angreifer aus dem weiten, weiten IPv4-Adressraum von den potentiell verwundbareren Diensten fernzuhalten. Ein kontrollierter Zugangsweg zu schützenswerten Diensten:

verringert die Angriffsfläche
erleichtert das Logging / Monitoring
erleichtert die Implementierung von Anti-Automatisierungslösungen (Rate-Limits, temporäre IP-Sperren, …)
ermöglicht Multi-Faktor-Authentifizierung
u.v.m.

Ob der Service in der Cloud steht oder im eigenen RZ – oder bei einem beliebigen (natürlich ISO 27001 zertifizierten ;-)) Hoster. Logs und Alarme lassen sich dabei übrigens auch von verschiedenen Quellen etwa über Azure sammeln und steuern – das notwendige Kleingeld vorausgesetzt:

Die Abbildung zeigt die SysLogs im Azure Log Analytics Workspace. Kostenfrei aber mit mehr Bastelei geht das Ganze z. B. mit HELK.

Egal wie: Sichtbarkeit – und damit die Aufzeichnung und Auswertung sicherheitsrelevanter Ereignisse sind unumgänglich für die Sicherheit administrativer Dienste auf dem Weg in die Cloud und die verteilten Unternehmensressourcen.

Sicherheit – eigentlich doch ganz einfach

Die Sicherheit administrativer Dienste ist keine Raketenwissenschaft. In Projekten kommen die größten Widerstände oft vom Anwender bzw. Administrator – also denen, die bisweilen „Sommer2021!“ für ein sicheres Passwort halten und Bildschirmsperren als überflüssig empfinden. Natürlich muss ein Administrator sich gegebenenfalls umgewöhnen. Ist SSH nicht auf Port 22 sondern auf Port 2022 bekommt er das aber wohl hin. Wenn nicht – naja, dann sollte er vielleicht auch keinen Root-Zugriff auf das System haben. Der Umzug auf einen anderen Port verhindert natürlich die Angriffe nicht. Auf unseren Testsystemen ist das Verhältnis aber gut 1 zu 20 von Zugriffen auf Port 22 zu Zugriffen auf „leicht erratbare Alternativports“ wie Port 2022.

Ist das Umdenken einmal angekommen, dann werden auch Vorteile von Passwort-Safes und der Public-Key-Authentifizierung schnell wahrgenommen. Ein bisschen ist die Einführung neuer Sicherheitsgrundlagen manchmal wie in der Hundeschule – wobei der administrative Dienst der Hund und der Administrator der Hundehalter ist: wenn der Hundehalter erst richtig erzogen ist, klappt’s oft auch mit dem Hund — oder der Sicherheit administrativer Dienste, wenn der Administrator erst angekommen ist.

blog