☰

Tipps zum Umgang mit einer überraschend hohen Rate an „Botnet“-SSHD-Anmeldefehlern?

tag-icon • tag-icon linux ssh ddos
Tipps zum Umgang mit einer überraschend hohen Rate an „Botnet“-SSHD-Anmeldefehlern?

Ich habe gerade 2 neue Debian 12 VPS gleichzeitig eingerichtet.

Einer von ihnen funktionierte einwandfrei, mit dem anderen schien ich zeitweise keine Verbindung zu haben. Ich habe sogar ein halbes Support-Ticket geschrieben, weil ich dachte, es müsse ein Verbindungsproblem in ihrem Rechenzentrum sein, aber dann habe ich tiefer gegraben und etwas über die „MaxStartups“-Funktion von sshd herausgefunden: Sobald mehr als eine bestimmte Anzahl von Verbindungen geöffnet, aber noch nicht authentifiziert wurden, beginnt sshd absichtlich, weitere Verbindungen zu trennen, was mit dem übereinstimmt, was ich gesehen habe.

Auf dem VPS, der einwandfrei funktioniert, zeigen die Protokolle etwa alle zwei Minuten einen böswilligen Versuch an, was ich inzwischen auch erwarte. Auf dem problematischen VPS scheint es etwa alle zwei Minuten zu sein.jede Sekundeim Durchschnitt, also ist es bei einer standardmäßigen LoginGraceTime von 2 Minuten vollkommen verständlich, warum ich Schwierigkeiten hatte, mich einzuloggen. Ich habe das bereits auf 5 Sekunden reduziert, was es gerade noch schafft, die Anzahl der offenen Verbindungen unter Kontrolle zu halten. (Beide VPS sind bereits so konfiguriert, dass sie nur Authentifizierung mit öffentlichem Schlüssel akzeptieren, also besteht sowieso keine Möglichkeit, dass ein böswilliger Versuch erfolgreich sein kann.)

Ich bin überrascht, wie schnell die Angriffsversuche bei dem problematischen Gerät erfolgen. Sie scheinen von allen möglichen Quell-IPs zu kommen, also eindeutig ein Botnetz und nichts, was ich einfach blockieren kann. Fail2ban zum Beispiel würde hier meines Wissens nichts bewirken, da es vollständig auf der Quell-IP funktioniert.

Ich plane, auf diesem VPS einen öffentlichen HTTP-Server einzurichten. Daher mache ich mir auch Sorgen, dass mein HTTP-Server, wenn er bereits das Ziel eines Botnet-Angriffs über SSH ist, durch DDOS-Angriffe ins Nichts geworfen werden könnte, bevor ich überhaupt angefangen habe, und/oder die Aufmerksamkeit von jemandem oder etwas auf sich ziehen könnte, das nach Schwachstellen sucht, die ausgenutzt werden können. (Auf dem anderen VPS, bei dem nur alle zwei Minuten ein Angriffsversuch stattfindet, plane ich, einen Mailserver einzurichten – ich bin mir nicht sicher, über welches Protokoll ich mir mehr Sorgen machen sollte!)

  • Wie hoch sollte die Rate böswilliger Versuche sein?erwartenan eine zufällig ausgewählte IPv4-Adresse umgeleitet werden?
  • Sollte ich darauf reagieren oder es einfach hinnehmen?
    • Fragen Sie meinen VPS-Anbieter, ob er die IP des Servers ändern kann, da ich vielleicht einfach nur Pech hatte und dieser das Ziel eines DDOS-Angriffs gegen eine beliebige andere Person war, die ihre IP inzwischen freigegeben hat und sie schließlich mir zugewiesen wurde?
    • SSH von überall blockieren, außer von einem anderen meiner VPS, über den ich darauf zugreifen kann – obwohl ich letztendlich sowieso einen öffentlichen HTTP-Server darauf betreibe? (scheint ein bisschen sinnlos, SSH per Firewall zu blockieren, wenn HTTP geöffnet sein muss – und für mich wäre dies mit ziemlichen Unannehmlichkeiten verbunden)
    • Protokollmeldungen für fehlgeschlagene Versuche einfach stumm schalten? (vorausgesetzt, es gibt Optionen dafür – ich habe es noch nicht geprüft)
    • Gibt es alternative SSH-Server-Softwarepakete, die ich verwenden kann und die besser für die Handhabung einer hohen Rate böswilliger Versuche optimiert sind? Beispielsweise erstellt sshd vor der Authentifizierung für jede neue Verbindung einen neuen Prozess, was nach viel unnötigem Aufwand aussieht: Im Idealfall sollte es so wenig Ressourcen wie möglich verbrauchen, bis die Authentifizierung erfolgreich war.
    • ...Irgendwelche anderen Vorschläge?

Antwort1

Mit welcher Häufigkeit böswilliger Angriffe muss ich bei einer zufällig ausgewählten IPv4-Adresse rechnen?

Das Hintergrundrauschen des Internets: routinemäßige, automatisierte Rasterfahndung (anstatt gezielt auf Ihre IPv4-Adresse abzuzielen) großer Teile des Internets auf der Suche nach gefährdeten Hosts und Diensten. Ein kontinuierlicher Strom von Tests, der leicht zu Hunderten von Anmelde-/Missbrauchsversuchen pro Tag allein auf einem gefährdeten SSHD führt (obwohl die Zahlen zwischen Dutzenden und (vielen) Tausenden liegen können, wobei bestimmte IP-Adressbereiche von Anbietern stärker als andere ins Visier genommen werden) mit unterschiedlichen Quellen wie:

  • gewissenhafte Anbieter (die möglicherweise Schwachstellenscanner einsetzen, weil sie Kunden warnen/von der Verbindung trennen möchten, wenn sie unsichere/anfällige/kompromittierte Systeme betreiben)
  • Forschungsprojekte (wie zum Beispielshodan.iound andere) und andere neugierige Leute
  • böswillige Akteure (die möglicherweise Botnetze zur Ausführung ihrer Untersuchungen verwenden)
  • usw. usw.

Sollte ich darauf reagieren oder es einfach hinnehmen?

Generell gilt: Wenn Sie einen Server oder Dienst dem Internet zugänglich machen, müssen Sie mit Verbindungen und vor allem Missbrauchsversuchen aus dem gesamten Internet rechnen.

Wenn eine Dienstleistung nicht als öffentliche Dienstleistung gedacht istDannes sollte nicht dem gesamten Internet zugänglich gemacht werden.
Wenn möglich: Die beste Vorgehensweise besteht darin, Zugriffskontrollen anzuwenden. Dies kann verschiedene Formen annehmen, ist aber in der Regel darauf beschränkt, den Zugriff auf bekannte IP-Adressen und/oder bekannte IP-Adressbereiche zu beschränken. Oder alternativ, wenn Sie gute IP-Adressbereiche nicht genau kennen, blockieren Sie Bereiche, für die wahrscheinlich nie ein gültiger Zugriffsanspruch besteht.
Obwohl die Verknüpfung von IP-Adressen (-bereichen) mit geografischen Standorten bei weitem nicht 100 % zuverlässig oder vollständig ist, können Zugriffslisten mit Geo-IP-Daten in dieser Hinsicht sehr nützlich sein.

Zugriffskontrollen können außerhalb des Hosts festgelegt werden, beispielsweise mit Sicherheitsgruppen oder einer Firewall-Appliance. Der Server selbst muss dann keine Ressourcen bereitstellen, um sie aufrechtzuerhalten.

Hostbasierte Zugriffskontrollen sind oft flexibler, erfordern aber auch Ressourcen vom Host selbst. Dazu zählen beispielsweise eine hostbasierte Firewall (unter Linux Netfilter/Iptables/Nftables) oder Zugriffskontrollen in der Anwendung selbst. Dies kann beispielsweise oft die einzige Möglichkeit sein, unterschiedliche IP-Adressbeschränkungen für verschiedene Benutzer festzulegen.

Wenn eine Dienstleistung beabsichtigt istfür einen öffentlichen Dienst, wie zum Beispiel ein Webserver mit Ihrer öffentlichen Website,Normalerweise wenden Sie keine Zugriffskontrollen an, weil echte Website-Besucher von überall willkommen sind.
Oft verfolgen solche öffentlichen Dienste den Ansatz: Zugriff von überall zulassen, aberböswilliges Verhalten erkennen und die von den böswilligen Akteuren verwendete IP-Adresse (vorübergehend) blockierenEin Werkzeug wieFail2banist ein solcher Ansatz,IDS- und IPS-Systemeein anderer.

Beispiel:Eine Zugriffskontrollliste auf der Seite für Bestellungen zum Mitnehmen und Online-Reservierungssysteme für ein lokales Restaurant in, sagen wir, Amsterdam, meiner Heimatstadt. Sie würden das nicht so einstellen, dass nur IP-Adressen aus Amsterdam Zugriff haben. Das wäre wahrscheinlich zu restriktiv und würde zum Beispiel berechtigte lokale Besucher abweisen, die ihre Mobiltelefone zum Zugriff auf die Site verwenden.
Andererseits sollte das Blockieren von IP-Adressbereichen, von denen bekannt ist, dass sie außerhalb Europas zugewiesen und verwendet werden und beispielsweise in den Regionen Afrika, Asien-Pazifik, Nord- und Südamerika verwendet werden, die Anzahl der Missbrauchsversuche erheblich reduzieren und wird sich wahrscheinlich nicht auf die Anzahl der Reservierungen/Bestellungen zum Mitnehmen auswirken.
Im Gegensatz dazu kann die Zugriffskontrollliste für den SSH-Zugriff auf denselben Webserver leicht auf die statischen IP-Adressen der Site-Administratoren, das Gateway ihres Büros und/oder, wenn sie keine statische IP-Adresse oder keinen VPN-Server haben, auf die von ihren ISPs verwendeten Bereiche beschränkt werden.

Gibt es alternative SSH-Server-Softwarepakete, die ich verwenden kann und die besser für die Handhabung einer hohen Rate böswilliger Versuche optimiert sind? Beispielsweise erstellt sshd vor der Authentifizierung für jede neue Verbindung einen neuen Prozess, was nach viel unnötigem Aufwand aussieht:

Ich denke und hoffe, dass Sie den tatsächlichen Ressourcenbedarf und die Auswirkungen dieser Anmeldeversuche stark überschätzen. Insgesamt gesehen ist die Belastung, die ein „normales“ Maß an SSH-Missbrauchsversuchen auf den exponierten VPS-Systemen, die ich gesehen habe, erzeugt, im Vergleich zur tatsächlichen Anwendungslast vernachlässigbar.

scheint ein bisschen sinnlos, SSH durch die Firewall zu deaktivieren, wenn HTTP geöffnet werden muss

Ein allgemeiner Ansatz zur Sicherheit ist diePrinzip der geringsten Privilegien; was in Firewall-Regeln bedeutet:

  • standardmäßig alles blockieren
  • Erlauben Sie nur denjenigen Zugriff auf das, was Sie brauchen.

Daher ist es nicht sinnlos, den SSH-Zugriff nur von einigen IP-Adressen statt von der ganzen Welt aus zuzulassen und der ganzen Welt Zugriff auf die Ports 80 (für die einfache Umleitung auf https) und 443, den Standard-https-Port, zu gewähren.

Antwort2

Ich habe bisher noch keine Angriffe vom Typ Slowloris auf SSH gesehen. Wenn man sich die Dokumentation ansieht, scheint es MaxStartups egal zu sein, ob diese vom selben Client stammen (d. h. Sie könnten damit den DOS-Angriff erleichtern). Meine erste Reaktion (je nach Angriffsmuster) wäre, iptables connlimit zu verwenden (Verbindungen pro Client-IP begrenzen).

Fail2ban ist die naheliegende Lösung für die meisten SSH-Angriffe (ich habe es auch für HTTP[S]-Verkehr verwendet), aber stellen Sie sicher, dass es für die Verwendung von IPset konfiguriert ist.

Eine Änderung der IP-Adresse dürfte auf lange Sicht kaum hilfreich sein.

Blockiere SSH von überall außer von einem meiner anderen VPS, über den ich darauf zugreifen kann

Ja – die Verwendung einer Jumpbox ist durchaus üblich. Auch dies können Sie selbst tun. Legen Sie einfach eine Standard-Firewall-Regel für Port 22 fest und setzen Sie dann Ihre Jumpbox(en) auf die Whitelist. SSH verfügt sogar über eine integrierte Funktion, die die Verwendung transparent macht, z. B.

ssh -J [email protected] [email protected]

oder Sie können dies in Ihrer ssh_config festlegen und einfach ssh targethost.example.com:

Host jumpbox.example.com
   User: jumpuser
   IdentityFile: ~/.ssh/jumpuser.id_rsa

Host targethost.example.com
   User: user
   ProxyCommand: ssh -q -W %h:%p [email protected]:22 
   IdentityFile: ~/.ssh/user.id_rsa

Protokollmeldungen für fehlgeschlagene Versuche einfach stummschalten?

Ich würde das nicht empfehlen. Sie können sie ruhig ignorieren, wenn Sie angemessene Maßnahmen ergriffen haben, um unbefugten Zugriff zu verhindern.

Wie pepoluan vorschlägt, können Sie auch einen nicht standardmäßigen Port und Port-Knoocking verwenden (letzteres kann übrigensrein in iptables implementiertohne knockd verwenden zu müssen)

Antwort3

Meine Vorschläge:

  1. Ändern Sie den SSH-Port von 22 in einen anderen.
  2. Wenn die Bots Ihren Port immer noch finden können, installieren knockdund konfigurieren Sie Ihren Server so, dass Port-Knocking implementiert wird.

Antwort4

Wenn Sie SSH über eine öffentliche IP-Adresse verfügbar machen, wird es früher oder später gescannt und Bedrohungsakteure werden Authentifizierungsversuche unternehmen, unabhängig vom VPS-Anbieter oder Netzwerk.

Ich würde Ihre SSH-Konfiguration mithilfe eines Ansible-Playbooks wie diesem absichern: https://github.com/dev-sec/ansible-collection-hardening/tree/master/roles/ssh_hardening

Oder dieses Playbook, das den ganzen Server härtet: https://github.com/konstruktoid/ansible-role-hardening

Und ich würde auch fail2ban empfehlen. Fail2Ban: Hosts sperren, die mehrere Authentifizierungsfehler verursachen Fail2Ban durchsucht Protokolldateien wie /var/log/auth.log und sperrt IP-Adressen, die zu viele fehlgeschlagene Anmeldeversuche durchführen. Dies geschieht, indem die System-Firewall-Regeln aktualisiert werden, um neue Verbindungen von diesen IP-Adressen für eine konfigurierbare Zeitspanne abzulehnen

Oder Sie können möglicherweise eine VPN-Verbindung zum Netzwerk Ihres VPS herstellen bzw. einen VPN-Server in Ihrem VPS erstellen, indem Sie beispielsweise OpenVPN verwenden und SSH hinter das VPN stellen und es nicht dem Internet aussetzen.

verwandte Informationen