Frage:
Wie kann man auf einen SSH-Brute-Force-Angriff auf einen einzelnen VPS reagieren?
Aage Torleif
2017-01-01 07:34:37 UTC
view on stackexchange narkive permalink

Ich habe mich heute Morgen bei meinem VPS angemeldet, um Millionen fehlgeschlagener Anmeldeversuche für den Benutzer root und andere Benutzer zu finden, die noch nicht einmal existieren. Ich habe die folgenden Maßnahmen ergriffen, um die (seit Monaten andauernden) Bemühungen der Angreifer zu verschleiern.

Frage (n)

  1. Ist dies eine angemessene Antwort?
  2. Was kann noch getan werden?
  3. Kann ich mit einer Liste dieser IPs etwas Wertvolles tun?
    4. ol>

    Systeminformationen für einen Centos7 vps 

      uname - ainux vm01 3.10.0-327.22.2.el7.x86_64 # 1 SMP Do 23. Juni 17:05:11 UTC 2016 x86_64 x86_64 x86_64 GNU / Linux

    Schritt 1

    Erstellt ein Skript zum Abrufen aller IP-Adressen, die sich nicht aus dem sicheren Protokoll anmelden konnten. ( / var / log / secure ) 

      # get_ips.shgrep "Passwort für" / var / log / secure \ | fehlgeschlagen grep -Po "[0-9] + \. [0-9] + \. [0-9] + \. [0-9] +" \ | sort \ | uniq -c

    Schritt 2

    Schreiben Sie ein Skript, um Firewall-Regeln zum Blockieren der IP-Adresse zu erstellen, die in Schritt 1 aus dem Skript gefunden wurden. Dieses Skript ist ip_list_to_rules.sh 

      #! / bin / bash # ip_list_to_rules.sh # Skript zum Analysieren der Ausgabe von get_ips.sh und Erstellen von Firewall-Regeln # zum Blockieren von ssh-Anforderungen, wenn [-z $ 1 ]; dann echo "arg1 muss Pfad zu einer Liste der Form sein <COUNT> <IP> \ n" exitfiLIST = $ (readlink -f $ 1) SSH_IP = $ (echo $ SSH_CLIENT | head -n1 | awk '{print $ 1;}') echo " Lesen von IPs aus $ {LIST} "echo" SSH-Client-IP wird ignoriert ($ {SSH_IP}) ", während COUNT IP gelesen wird; Echo "Regel für $ {IP} erstellen" firewall-cmd --direct --add-rule ipv4 filter INPUT 1 -m tcp --source $ IP -p tcp --dport 22 -j REJECT firewall-cmd --direct --add-rule ipv4 filter INPUT 1 -m tcp --source $ IP / 24 -p tcp --dport 22 -j REJECTdone<<< "$ (cat $ {LIST} | grep -v $ {SSH_IP})"

    Schritt 3

    Führen Sie alles aus und speichern Sie die Regeln. 

      ./get_ips.sh > attack_ips.list./ip_list_to_rules.sh attack_ips.listfirewall-cmd --reload

    Update

    Nachfolgend sind die Maßnahmen aufgeführt, die ich aus den Antworten ergriffen habe.

    1. Deaktivierte Root-Anmeldungen
    2. Geändert SSH-Port
    3. Installieren Sie & konfiguriert fail2ban
    4. Deaktivieren Sie die Kennwortauthentifizierung. & aktiviert die Authentifizierung mit öffentlichem Schlüssel Über Chrome Secure Shell Client und AFAIK gibt es keine Unterstützung für öffentliche Schlüssel.
Es gibt einen viel einfacheren Schritt, mit dem Sie die überwiegende Mehrheit der automatisierten SSH-Kennwortschätzungsangriffe beruhigen können: Ändern Sie Ihre SSH-Portnummer.Nun, * natürlich *, wird dies nicht ausreichen, um einen entschlossenen Angreifer aufzuhalten.Sie müssen auch über substanzielle Sicherheitsmaßnahmen verfügen.(Und es hört sich so an, als würdest du das verstehen).Wenn Sie dies tun, werden Ihre Protokolle vom Datenverkehr der unzähligen automatisierten Bots befreit, die das Netz nach offenen gemeinsamen Ports durchsuchen, um Vermutungen von Benutzernamen und Kennwörtern anzustellen.So erhalten Sie eine bessere Sichtbarkeit im Vergleich zu potenziell mehr Bedrohungen.
Ich würde dringend empfehlen, ein geeignetes SSH-Tool wie Bitvise, PuTTy usw. zu verwenden und die Authentifizierung mit öffentlichem Schlüssel zu aktivieren, anstatt eine Erweiterung in einem Browser zu verwenden, um Aktionen auszuführen, für die ein Browser nicht vorgesehen ist und für die keine ausreichende Sicherheit bereitgestellt werden kann.
Sie möchten [Secure Secure Shell] lesen (https://stribika.github.io/2015/01/04/secure-secure-shell.html).
Probieren Sie für die sichere Chrome-Shell die Termius-App aus.Es unterstützt private Schlüssel.
Diese Frage passt besser zu [SF].
Acht antworten:
Xiong Chiamiov
2017-01-01 08:05:09 UTC
view on stackexchange narkive permalink

Ja, dies ist ein absolut vernünftiger und allgemeiner Ansatz. Sie haben jedoch fail2ban neu erfunden. Sie möchten wahrscheinlich stattdessen darauf umsteigen, damit Sie keine Probleme mit Ihrem Skript debuggen müssen und die vorhandenen Filter für SSH, Apache und andere allgemeine Dienste verwenden können.

Leider gibt es solche Mit diesen IPs kann man nicht viel anfangen. Sie können versuchen, die Aktivität dem Missbrauchskontakt zu melden, der für seinen IP-Block aufgeführt ist, aber es lohnt sich nicht wirklich, es sei denn, er tut etwas Ernsthafteres.

Sie sollten auch die Standard-SSH-Härtung durchführen, z. B. das Deaktivieren des Kennworts -basierte und Root-Anmeldungen, sofern Sie diese nicht unbedingt benötigen.

Temporäres Blockieren wie das, was fail2ban tut, ist für eine kurzfristige Lösung in Ordnung, aber im Allgemeinen ist ein permanentes Blockieren unerwünscht, da diese IP normalerweise Teil eines Botnetzes sind und eine große Anzahl wahrscheinlich von ISPs mit dynamischer IP-Zuweisung oder großen Netzwerken mit NAT ausgegeben wird, in denen viele Benutzer vorhanden sindTeilen Sie eine einzelne öffentliche IP-Adresse.Wenn zu viele dieser IP-Adressen blockiert werden, blockieren Sie möglicherweise auch versehentlich legitime Kunden.
fail2ban oder ähnliches sollte eines der ersten Dinge sein, die einem VPS hinzugefügt werden müssen.Gleich nach dem Ändern des Standard-SSH-Ports!Wie Lie sagt, verwenden Sie vorübergehende Verbote, da sich die Angriffe sehr schnell verschieben.Normalerweise reichen 10 Minuten, ich glaube ich benutze eine Stunde.
fail2ban kann auch automatisierte Missbrauchsberichte senden, glaube ich ... ich habe es nie eingeschaltet.
Lie Ryan
2017-01-01 14:04:32 UTC
view on stackexchange narkive permalink

Der effektivste Weg, ein SSH-System zu sichern, besteht darin, sich nur mit dem privaten Schlüssel ssh anzumelden. Sie sollten die Kennwortauthentifizierung deaktivieren und die direkte Root-Anmeldung nicht zulassen. Danach werden Sie immer noch viele fehlgeschlagene Authentifizierungsversuche erhalten, aber es gibt keine Chance, dass Brute-Force-Angreifer in der Hölle erfolgreich sind.

Wenn Sie Ihre Protokolle danach sauber halten möchten, sollten Sie Ihren SSH-Port auf eine andere Portnummer verschieben.

Oder deaktivieren Sie einfach die Protokollierung fehlgeschlagener Anmeldeversuche, da diese bedeutungslos sind, wenn Sie die Kennwortauthentifizierung nicht aktiviert haben.
Wie auch immer +1, weil dies der richtige Ansatz ist.Andere sind unterschiedliche Grade von Übungen in Sinnlosigkeit / Zeitverschwendung.
CaffeineAddiction
2017-01-01 14:33:56 UTC
view on stackexchange narkive permalink

Es mag einschüchternd sein, eine Million fehlgeschlagener Anmeldeversuche zu sehen, aber ehrlich gesagt ist die Bandbreite und Verarbeitungsleistung, die diese Versuche verbrauchen, trivial.

Die eigentliche Frage lautet also: Ist Ihr System sicher:

  • Haben Sie die Root-Anmeldung deaktiviert?
  • Haben Sie die Kennwortauthentifizierung zugunsten des Pub-Schlüssels deaktiviert?
  • Haben Sie den Standardport des sshd geändert? Service auf Ihrem VPS?

Alle diese Änderungen können in der Datei / etc / ssh / sshd_config vorgenommen werden (stellen Sie sicher, dass Sie sshd neu starten, nachdem Sie Ihre Änderungen vorgenommen haben)

Sie könnten fail2ban oder ein benutzerdefiniertes Skript verwenden, um diese IPs in der Firewall zu blockieren, aber die sshd-Authentifizierung selbst ist für sich genommen sicher genug. Das Hinzufügen von mehr Komplexität ist nicht unbedingt sicherer und führt höchstwahrscheinlich dazu, dass Sie sich versehentlich sperren aus dem vps.

Bei diesen Angriffen geht es nicht wirklich um die Bandbreite oder Verarbeitungsleistung.Es ist die Tatsache, dass es die Protokolle überflutet und so andere Probleme oder Angriffe verbirgt.
Zeta Two
2017-01-01 11:07:10 UTC
view on stackexchange narkive permalink

Wie andere bereits erwähnt haben. Fail2ban mit ziemlich strengen Regeln (zum Beispiel: 3 falsches Passwort oder der Versuch, sich mit einem nicht vorhandenen Benutzer anzumelden) kann sehr effektiv sein.

Ich würde auch empfehlen, SSH auf einen nicht standardmäßigen Port zu verschieben. Natürlich hilft dies überhaupt nicht gegen jede Art von intelligentem Angriff, aber es beseitigt die grundlegendsten automatisierten Scanner, von denen es einige gibt.

Wenn Sie dies mit etwas kombinieren, das das Scannen von Ports und erkennt Verbinden Sie das mit fail2ban. Sie können sogar einen großen Teil der Scanner, Botnets und anderen Mist abwehren.

Tomáš Pánik
2017-01-02 02:28:52 UTC
view on stackexchange narkive permalink

Sie können IP-Tabellen festlegen, die nicht Ihren gesamten Server sperren, aber Brute-Force-Angriffe bis zu einem Punkt verlangsamen, an dem sie unwirksam werden .

Das Einschränken des SSH-Zugriffs durch IP-Adressen ist die sicherste Methode. Das Ändern des SSH-Ports kann Bot-Scans verhindern, wirkt sich jedoch nur wenig auf gezielte Angriffe aus.

Geben Sie im Terminal

ein 
  / usr / sbin / iptables -I INPUT -p tcp --dport 22 -i eth0 -m state --state NEW -m aktuell --set / usr / sbin / iptables -I INPUT -p tcp --dport 22 -i eth0 -m state --state NEW -m kürzlich --update --seconds 60 --hitcount 4 -j DROP

Dies blockiert die neue IP-Adresse wenn es mehr als 3 Mal pro Minute verbindet . Hergestellte Verbindungen führen zu einer erfolgreichen Authentifizierung. Sie können auch protokollieren, was hier getan wird, indem Sie eine Protokollregel festlegen. 

  / sbin / iptables -N LOGDROP / sbin / iptables -A LOGDROP -j LOG / sbin / iptables -A LOGDROP -j DROPiptables -I INPUT -p tcp --dport 22 -i eth0 -m state --state NEW -m aktuell --setiptables -I INPUT -p tcp --dport 22 -i eth0 -m state --state NEW -m aktuell - -update --seconds 60 --hitcount 4 -j LOGDROP
Slim-Jay1
2017-01-01 10:34:07 UTC
view on stackexchange narkive permalink

Sie können versuchen, fail2ban zu installieren, oder Sie können beispielsweise die direkte Root-Anmeldung deaktivieren oder den Standard-SSH-Port ändern

danofsatx
2017-01-02 09:22:46 UTC
view on stackexchange narkive permalink
  1. Deaktivieren Sie die Kennwortauthentifizierung. & aktiviert die Authentifizierung mit öffentlichem Schlüssel AFAIK gibt es keine Unterstützung für öffentliche Schlüssel.

Ich verwende den Chrome Secure Shell-Client auf meinem Chromebook und er unterstützt die Authentifizierung mit öffentlichen Schlüsseln. Ich habe die Kennwortauthentifizierung auf allen meinen Systemen deaktiviert und kann problemlos über das Chromebook oder mein Telefon mit Juice darauf zugreifen.

@grochmal, stellte er keine Frage, er beantwortete einen kleinen Teil der ursprünglichen Frage.danofsatx, Ihre Antwort könnte verbessert werden, indem Sie einen Screenshot hinzufügen, in dem Sie Chrome Secure Shell Client für die Verwendung von Schlüsseln konfiguriert haben.
@gowenfawr - guter Punkt, mit dem Zitat sehe ich es.Vielen Dank.
@danosatx, guter Fang.Ich konnte "import ..." nie zum Laufen bringen, ich nahm an, dass der Support gerade in der Entwicklung war.
Danny Duval
2017-01-01 20:32:09 UTC
view on stackexchange narkive permalink

Richten Sie ssh so ein, dass Sie sich über einen anderen Port anmelden.

Dies ist ein doppelter Vorschlag aus mehreren anderen Antworten und enthält * weniger * Informationen als alle.


ⓘ
Diese Fragen und Antworten wurden automatisch aus der englischen Sprache übersetzt.Der ursprüngliche Inhalt ist auf stackexchange verfügbar. Wir danken ihm für die cc by-sa 3.0-Lizenz, unter der er vertrieben wird.
Loading...