it-swarm.com.de

Erlebe ich einen Brute-Force-Angriff?

Wenn Sie das Authentifizierungsprotokoll eines Servers mit dem folgenden Befehl überprüfen:

grep sshd.\*Failed /var/log/auth.log | less

Ich sehe Tausende solcher Zeilen:

    Jan 12 11:27:10 ubuntu-leno1 sshd[8423]: Failed password for invalid user admins from 172.25.1.1 port 44216 ssh2
    Jan 12 11:27:13 ubuntu-leno1 sshd[8425]: Failed password for invalid user phoenix from 172.25.1.1 port 20532 ssh2
    Jan 12 11:27:17 ubuntu-leno1 sshd[8428]: Failed password for invalid user piglet from 172.25.1.1 port 24492 ssh2
    Jan 12 11:27:22 ubuntu-leno1 sshd[8430]: Failed password for invalid user Rainbow from 172.25.1.1 port 46591 ssh2
    Jan 12 11:27:25 ubuntu-leno1 sshd[8432]: Failed password for invalid user runner from 172.25.1.1 port 57129 ssh2
    Jan 12 11:27:34 ubuntu-leno1 sshd[8434]: Failed password for invalid user sam from 172.25.1.1 port 11960 ssh2
    Jan 12 11:27:37 ubuntu-leno1 sshd[8437]: Failed password for invalid user abc123 from 172.25.1.1 port 5921 ssh2
    Jan 12 11:27:40 ubuntu-leno1 sshd[8439]: Failed password for invalid user passwd from 172.25.1.1 port 21208 ssh2
    Jan 12 11:27:43 ubuntu-leno1 sshd[8441]: Failed password for invalid user newpass from 172.25.1.1 port 65416 ssh2
    Jan 12 11:27:46 ubuntu-leno1 sshd[8445]: Failed password for invalid user newpass from 172.25.1.1 port 26332 ssh2
    Jan 12 11:27:49 ubuntu-leno1 sshd[8447]: Failed password for invalid user notused from 172.25.1.1 port 51126 ssh2
    Jan 12 11:27:52 ubuntu-leno1 sshd[8449]: Failed password for invalid user Hockey from 172.25.1.1 port 14949 ssh2
    Jan 12 11:27:56 ubuntu-leno1 sshd[8451]: Failed password for invalid user internet from 172.25.1.1 port 35105 ssh2
    Jan 12 11:27:59 ubuntu-leno1 sshd[8453]: Failed password for invalid user asshole from 172.25.1.1 port 7916 ssh2
    Jan 12 11:28:02 ubuntu-leno1 sshd[8456]: Failed password for invalid user Maddock from 172.25.1.1 port 26431 ssh2
    Jan 12 11:28:05 ubuntu-leno1 sshd[8458]: Failed password for invalid user Maddock from 172.25.1.1 port 53406 ssh2
    Jan 12 11:28:09 ubuntu-leno1 sshd[8460]: Failed password for invalid user computer from 172.25.1.1 port 23350 ssh2
    Jan 12 11:28:15 ubuntu-leno1 sshd[8462]: Failed password for invalid user Mickey from 172.25.1.1 port 37232 ssh2
    Jan 12 11:28:19 ubuntu-leno1 sshd[8465]: Failed password for invalid user qwerty from 172.25.1.1 port 16474 ssh2
    Jan 12 11:28:22 ubuntu-leno1 sshd[8467]: Failed password for invalid user fiction from 172.25.1.1 port 29600 ssh2
    Jan 12 11:28:26 ubuntu-leno1 sshd[8469]: Failed password for invalid user orange from 172.25.1.1 port 44845 ssh2
    Jan 12 11:28:30 ubuntu-leno1 sshd[8471]: Failed password for invalid user tigger from 172.25.1.1 port 12038 ssh2
    Jan 12 11:28:33 ubuntu-leno1 sshd[8474]: Failed password for invalid user wheeling from 172.25.1.1 port 49099 ssh2
    Jan 12 11:28:36 ubuntu-leno1 sshd[8476]: Failed password for invalid user mustang from 172.25.1.1 port 29364 ssh2
    Jan 12 11:28:39 ubuntu-leno1 sshd[8478]: Failed password for invalid user admin from 172.25.1.1 port 23734 ssh2
    Jan 12 11:28:42 ubuntu-leno1 sshd[8480]: Failed password for invalid user jennifer from 172.25.1.1 port 15409 ssh2
    Jan 12 11:28:46 ubuntu-leno1 sshd[8483]: Failed password for invalid user admin from 172.25.1.1 port 40680 ssh2
    Jan 12 11:28:48 ubuntu-leno1 sshd[8485]: Failed password for invalid user money from 172.25.1.1 port 27060 ssh2
    Jan 12 11:28:52 ubuntu-leno1 sshd[8487]: Failed password for invalid user Justin from 172.25.1.1 port 17696 ssh2
    Jan 12 11:28:55 ubuntu-leno1 sshd[8489]: Failed password for invalid user admin from 172.25.1.1 port 50546 ssh2
    Jan 12 11:28:58 ubuntu-leno1 sshd[8491]: Failed password for root from 172.25.1.1 port 43559 ssh2
    Jan 12 11:29:01 ubuntu-leno1 sshd[8494]: Failed password for invalid user admin from 172.25.1.1 port 11206 ssh2
    Jan 12 11:29:04 ubuntu-leno1 sshd[8496]: Failed password for invalid user chris from 172.25.1.1 port 63459 ssh2
    Jan 12 11:29:08 ubuntu-leno1 sshd[8498]: Failed password for invalid user david from 172.25.1.1 port 52512 ssh2
    Jan 12 11:29:11 ubuntu-leno1 sshd[8500]: Failed password for invalid user foobar from 172.25.1.1 port 35772 ssh2
    Jan 12 11:29:14 ubuntu-leno1 sshd[8502]: Failed password for invalid user buster from 172.25.1.1 port 18745 ssh2
    Jan 12 11:29:17 ubuntu-leno1 sshd[8505]: Failed password for invalid user harley from 172.25.1.1 port 38893 ssh2
    Jan 12 11:29:20 ubuntu-leno1 sshd[8507]: Failed password for invalid user jordan from 172.25.1.1 port 64367 ssh2
    Jan 12 11:29:24 ubuntu-leno1 sshd[8509]: Failed password for invalid user stupid from 172.25.1.1 port 27740 ssh2
    Jan 12 11:29:27 ubuntu-leno1 sshd[8511]: Failed password for invalid user Apple from 172.25.1.1 port 22873 ssh2
    Jan 12 11:29:30 ubuntu-leno1 sshd[8514]: Failed password for invalid user fred from 172.25.1.1 port 54420 ssh2
    Jan 12 11:29:33 ubuntu-leno1 sshd[8516]: Failed password for invalid user admin from 172.25.1.1 port 58507 ssh2
    Jan 12 11:29:42 ubuntu-leno1 sshd[8518]: Failed password for invalid user summer from 172.25.1.1 port 48271 ssh2
    Jan 12 11:29:45 ubuntu-leno1 sshd[8520]: Failed password for invalid user sunshine from 172.25.1.1 port 5645 ssh2
    Jan 12 11:29:53 ubuntu-leno1 sshd[8523]: Failed password for invalid user andrew from 172.25.1.1 port 44522 ssh2

Es scheint, dass ich einen SSH-Brute-Force-Angriff erlebe. Ist dies ein häufiges Ereignis oder werde ich gezielt angesprochen? Was sollte ich jetzt tun? Sollte ich den Angriff als erfolgreich betrachten und Maßnahmen ergreifen?

-----Bearbeiten-------

Die Tatsache, dass der Angriff von einer internen IP-Adresse ausgeht, wird dadurch erklärt, dass dieser Server eine SSH-Umleitung von außen hat. Nach dem Öffnen des Ports ging es sehr schnell. Wird jede öffentliche IP in freier Wildbahn auf der Suche nach einem vorhandenen Server gescannt?

67
syldor

Kurzer Hinweis zu fail2ban Hinzugefügt, wie viele Leute bereits erwähnt haben: Das Front-End ist eine Unternehmens-Firewall, das Back-End sieht nur die Umleitung/Proxy/interne Adresse, die von der Firewall stammt.

Also nein, 172.25.1.1 ist keine kompromittierte interne Maschine (und sowohl der Kommentar in der Antwort als auch die andere Antwort hier, die besagt, dass es sich um eine interne Maschine handelt sind falsch , wenn Sie das kommentieren). Dies ist eine der internen IP-Adressen der Firewall.

Fail2ban im Backend würde nur alle Möglichkeiten blockieren, SSH für Strecken gleichzeitig zu verwenden, da nur fehlgeschlagene Versuche ab 172.25.1.1 angezeigt werden. Bitte lesen Sie weiter für meine Antwort.

Es gibt keine Zweifel, wie andere Beiträge erwähnen, es ist schmerzlich offensichtlich, dass Sie einem Brute-Force-Angriff ausgesetzt sind.

Das bedeutet jedoch nicht, dass Sie in irgendeiner Weise von den Protokollen, die Sie uns gezeigt haben, kompromittiert werden. Leider sind heutzutage alle ssh-Brute-Force-Angriffe alles allzu häufig. Meistens sind sie wirklich automatisiert, und Sie werden nicht unbedingt gezielt.

Als anekdotische Warnung wurde vor einigen Jahren, als ich am ersten Tag neue Server bei einem ISP-Anbieter einrichtete, der für das Internet offene SSH-Server in einer einzigen Nacht über 200.000 SSH-Scansonden verfügen.

Bei der "internen IP-Adresse" verwenden Sie entweder SNAT oder eine 22/TCP-Proxy-Umleitung, und die Internet-Quell-IPs werden nicht angezeigt (was nicht die beste Vorgehensweise ist), oder im schlimmsten Fall ist dies Ihr Router/Kabelmodem kompromittiert.

Wenn Sie wirklich eine SNAT/Proxy-SSH-Konfiguration haben, empfehle ich Ihnen, darüber nachzudenken. Sie möchten Protokolle der tatsächlichen IP-Adressen und nicht Ihres Netzwerks.

In Bezug auf Maßnahmen empfehle ich einige:

  1. Lassen Sie keine Passwörter in SSH zu. nur Anmeldungen mit RSA-Zertifikaten;
  2. Öffnen Sie ssh nicht nach außen. Beschränken Sie es auf Ihr internes Netzwerk.
  3. Für den Zugriff von außen über ein VPN; Setzen Sie SSH nicht dem gesamten Internet aus.
  4. geschwindigkeitsbegrenzende SYNs von außen.

Wenn Sie unbedingt darauf bestehen, dass das SSH-Internet weiterhin nach außen geöffnet ist, beachten Sie, dass das Ändern des Standard-SSH-Ports nur ein falsches Sicherheitsgefühl vermittelt und das vorübergehende Blockieren von IP-Adressen den Angriff nur verlangsamt, da es sich häufig um koordinierte Farmen handelt Zombiemaschinen.

Sie können sich fail2ban Anschauen, wenn Sie Ihre Konfiguration ändern, um direkt öffentliche IP-Adressen zu erhalten, die eine Verbindung zu Ihnen herstellen. Berücksichtigen Sie jedoch, dass Sie, wenn tatsächlich eine externe IP mit der IP-Adresse Ihres Gateways eintrifft, den gesamten externen SSH-Zugriff damit effektiv sperren.

Es gibt auch andere Vorbehalte; Bitte beachten Sie, dass heutzutage Zombies/Malware fail2ban berücksichtigen und nach dem Standardzeitlimit zurückkehren oder sich mit anderen IP-Adressen abwechseln. (Ich habe es gesehen.) Selbst wenn Sie die obligatorische RSA-Zertifikatauthentifizierung verwenden, werden die Kennwortangriffe weiterhin protokolliert und brennen E/A, Speicherplatz und CPU-Zyklen.

Für das VPN benötigen Sie keine dedizierte Hardware. Es ist trivial, ein VPN auf einem Linux- oder FreeBSD-Server zu konfigurieren.

Wenn Sie sich nicht wohl fühlen, wenn Sie eine von Grund auf neu einrichten, empfehle ich eine VM mit pfSense. für FreeBSD; strongSwan für die Einrichtung ein VPN in einem Linux-Server.

Wenn Ihr Front-End-Server Linux ist, ist eine andere Alternative das Klopfen von Ports. Aufgrund seiner inhärenten Funktionsweise empfehle ich es jedoch nur für Haushaltseinstellungen. Wie richtig von @GroundZero hervorgehoben "Port-Klopfen ist Sicherheit durch Dunkelheit und ein Angreifer kann Ihren Netzwerkverkehr aktiv überwachen, um die Klopfsequenz zu ermitteln."

So verwenden Sie Port Knocking, um Ihren SSH-Daemon vor Angreifern unter Ubuntu zu verstecken

Als zusätzliche Maßnahme können Sie das Ratenlimit auch mit den Firewall-/Iptables-Regeln SYNs in Port 22 begrenzen. Auf diese Weise können Sie Ihre legitimen Verbindungen nicht bewerten, und entweder Iptables unter Linux oder die meisten kommerziellen Firewalls erlauben diese Konfiguration. Ich habe böse Tricks gesehen, als Bots einige Dämonen so schnell wie möglich angriffen, bevor die Sicherheitsregeln in Kraft traten. Ich glaube jedoch, dass ssh tatsächlich eine eingebaute Verteidigung dagegen hat.

Um Ihnen über das grassierende Scannen zu antworten, ja. Sie haben viele schlechte Schauspieler, Zombie-Netzwerke und Malware, die ständig den IP-Adressraum durchsuchen, um Server mit kompromittierten Versionen von sshd, anfälligen/alten sshd-Versionen, Servern mit Standard-/schlechten Passwörtern/bekannten Hintertüren und einfach Servern mit openssh zu finden Ein Fuß in einem nicht privilegierten Benutzer, entweder durch Brute Force oder durch doppelte Angriffe durch Phishing.

Nach drei erfolgreichen Angriffen über Phishing (in separaten Ereignissen) in meinem Bastion Host in meiner aktuellen Arbeit habe ich mich für eine Dual-SSH-Konfiguration entschieden, bei der alle Benutzer nach einem RSA-Zertifikat in sshd_config Und nur nach dem internen Zertifikat gefragt werden Das Netzwerk ermöglicht die Kennwortauthentifizierung und fügt am Ende der Konfigurationsdatei Folgendes hinzu:

# sshd configuration allowing only RSA certificates
Match Address 10.0.0.0/8,172.16.0.0/12,192.168.0.0/24
PasswordAuthentication yes

Als eine weitere anekdotische Gruselgeschichte, bevor ich zu obligatorischen RSA-Zertifikaten wechselte, wurde einer der Phishing-Kompromisse genau in der Woche durchgeführt, in der es zwei Kernel-Updates für Schwachstellen gab, die eine Eskalation von Berechtigungen zum Rooten ermöglichten, und wenn ich nicht vor Ort aktualisiert hätte, würde ich dies tun wurden Wurzel kompromittiert. (und wenn mein Gedächtnis mich nicht enttäuscht, war es ungefähr am 4. Juli ... Hacker lieben es, diese fiesen Angriffe für Urlaubszeiten aufzubewahren)

Diagramme der tatsächlichen Live-Angriffe in Echtzeit finden Sie unter:

Zum Abschluss der Antwort:

Nein, Sie sind wahrscheinlich in keiner Weise gefährdet.

Ja, Sie müssen Maßnahmen ergreifen, um Ihr Sicherheitsniveau zu erhöhen. Ich würde einen VPN-Tunnel/Client von außen zu Ihrem Unternehmens-VPN-Server empfehlen. Es ist das, was ich eigentlich mache.

Ich habe auch einen letzten und wichtigen Ratschlag: Um sicherzustellen, dass ein reguläres Konto nicht gefährdet wird, überprüfen Sie Ihre /var/log/auth.log - Authentifizierungsprotokolle auf eine erfolgreiche Authentifizierung. Es gibt Möglichkeiten, sich mit einem beliebigen Konto bei openssh anzumelden, ohne dass es in /var/log/wtmp Registriert ist und folglich nicht im last erscheint Befehl.

Es versteht sich von selbst, dass alle Wetten ungültig sind, wenn ein reguläres Konto auf einem alten Computer ohne Updates kompromittiert wird. Und im unglücklichen Fall einer Eskalation von Berechtigungen zu root können sogar die Protokolle kompromittiert werden.

29
Rui F Ribeiro

Ja, es sieht so aus, als ob Sie einen Brute-Force-Angriff erleben. Der Angreifer befindet sich an einer privaten Adresse der Klasse B, daher ist es wahrscheinlich, dass jemand mit Zugriff auf das Netzwerk Ihres Unternehmens den Angriff ausführt. Aus den Benutzernamen geht hervor, dass sie durch ein Wörterbuch gängiger Benutzernamen laufen.

Schauen Sie sich 'So stoppen/verhindern Sie SSH-Bruteforce' (Serverfehler) und 'Verhindern von Brute-Force-SSH-Angriffen' (Rimu Hosting) an, wie Sie Maßnahmen ergreifen können, um einige zu verringern des Risikos im Zusammenhang mit SSH-Bruteforce-Angriffen.

63
TheJulyPlot

Ja, das sieht genauso aus wie ein Brute-Force-Angriff und nach dem Googeln admins phoenix piglet Rainbow es sieht so aus, als ob dies die Wortliste ist, die der Angreifer verwendet: https://github.com/hydrogen18/kojoney/blob/master/fake_users
Überprüfen Sie ab Zeile 116. Die Wortliste wird in genau derselben Reihenfolge verwendet.
Dies scheint eine generische Wortliste zu sein, da sie auch auf anderen Websites vorhanden ist. z.B. http://src.gnu-darwin.org/ports/net/kojoney/work/kojoney/fake_users

@TheJulyPlot hat einige gute Informationen dazu bereitgestellt, wie dieser Angriff abgewehrt werden kann.

Ja, du wirst brutal gezwungen. Aber ich denke nicht, dass Sie sich Sorgen machen sollten, wenn Bruteforce aus dem Internet kommt. Sie sollten sich jedoch Sorgen über Brute-Force-Angriffe machen, die von Ihrem eigenen Netzwerk ausgehen.

Bruteforced ist sehr häufig und solange Sie keine Passwörter für SSH verwenden (oder gute Passwörter verwenden), ist der Angriff überhaupt nicht erfolgreich (insbesondere mit einer Vermutung alle 3-4 Sekunden ).

Die IP (172.25.1.1) befindet sich jedoch im selben Netzwerk wie Sie. Dies ist das eigentliche Problem, und Sie sollten überprüfen, ob diese Maschine kompromittiert ist so bald wie möglich.

28
Benoit Esnard

Sie überleben den Angriff anscheinend. SSH macht das, was es machen soll. Im Folgenden finden Sie jedoch einige Schritte, die Sie so schnell wie möglich ausführen sollten, um ein kontinuierliches Überleben zu gewährleisten.

Auch und leider wurde ein System innerhalb des Netzwerks kompromittiert. Heutzutage zu häufig. Sie sollten die Art dieses scheinbar inneren Angriffs feststellen, aber nicht davon ausgehen, dass dieses System einfach auf der Grundlage von dieser Protokolldatei kompromittiert wird. Jeder, der eine mit dem Internet verbundene SSHD betreibt, hat dies schon seit Jahren immer wieder gesehen. Korrigieren Sie die SSHD-Installation auf diesem Host und untersuchen Sie das System unter 172.25.1.1.

Befolgen Sie solche SSHD-Best Practices ...

Deaktivieren Sie die Kennwortauthentifizierung zugunsten der schlüsselbasierten Authentifizierung:

# grep PasswordAuth sshd_config | grep no
PasswordAuthentication no

Deaktivieren Sie wie erwähnt die Root-Anmeldungen:

PermitRootLogin no

Zulässige Benutzer zu sshd_config hinzufügen:

AllowUsers myusername the_other_sysop_guy

Wenn Sie den letzten Vorgang ausführen, ändert sich die Protokollmeldung von "Ungültiger Benutzer" in "Unzulässiger Benutzer".

Abhängig von Ihrer Geschäftssituation können Sie auch darüber nachdenken, den SSHD-Port durch eine Firewall zu schützen (SSH nur von autorisierten IP-Adressen aus zulassen) oder ihn in einen anderen Port zu ändern (was wirklich Sicherheit durch Unbekanntheit ist, aber die meisten Angriffe dieser Art werden tatsächlich per Skript ausgeführt). . Leider kann die Tatsache, dass sich der Angreifer in Ihrem LAN befindet, dazu führen, dass diese nicht so viel Hilfe bieten wie sonst.

Die Tatsache, dass das Gerät auf 1.1 steht, lässt mich übrigens fragen, ob sie in Ihren Router gelangt sind. ;-);

7
Kevin_Kinsey

Das Standard-Aussehen der Protokolle scheint ein häufiger Brute-Force-Angriff zu sein, da die in den Protokollen eingetragenen Namen aus einem verwendeten Standardwörterbuch stammen. Sogar die gängigen Wortlisten betrachten diese als primäre Zielbenutzernamen. Die Injektion stammt ebenfalls von einer IP der privaten Klasse B. Machen Sie sich jedoch keine Sorgen, solange die von Ihnen erzwungenen Kennwörter stark genug sind und Sie über einen Lastausgleich verfügen, um dies zu verwalten. Dies ist für Sie kein Problem. Suchen Sie nach Maßnahmen, um dies in SSH zu schützen. Brute-Force-Schutzmaßnahmen in SSH.

4
D3X

Da alle SSH-Anmeldungen auf Ihrem Server über dieselbe lokale IP-Adresse umgeleitet werden, würde ich empfehlen, fail2ban Vorsichtig zu verwenden, wenn Sie sich für die Verwendung entscheiden. Wenn Sie fail2ban Auf demselben Server wie sshd installieren, wird die IP 172.25.1.1 sofort blockiert. Danach kann sich niemand mehr über SSH bei Ihrem Server anmelden.

Wenn Sie fail2ban Auf dem Server installieren können, der den SSH-Verkehr umleitet, tun Sie dies. Ich verwende fail2ban Auf meinem öffentlichen SSH-Server und es macht einen großartigen Job, den Angreifer auf 3 Versuche in 10 Minuten zu beschränken. Die meisten "Cracking" -Skripte, die die Skriptkinder verwenden, werden nach diesen drei Versuchen einfach eine Zeitüberschreitung verursachen und mich tagelang nicht mehr stören.

3

Sie können den Angreifer, der das Passwort errät, auch ziemlich einfach verlangsamen.

In der Datei /etc/pam.d/sshd können Sie eine Zeile wie folgt hinzufügen:

auth     optional   pam_faildelay.so   delay=7000000

Bei jedem fehlgeschlagenen Anmeldeversuch sshd wartet das PAM-Modul 7 Sekunden. Möglicherweise möchten Sie die Verzögerung erhöhen oder verringern, da Sie 7 Sekunden warten, bis Sie eine weitere Eingabeaufforderung erhalten, wenn Sie Ihr eigenes Kennwort eingeben. Ich würde eine Vermutung wagen, dass die meisten SSH-Passwort-Schätzprogramme so unkompliziert sind, dass sie keine Zeitüberschreitung haben, wenn sie auf eine neue Eingabeaufforderung warten, aber es ist möglich, dass eine wirklich lange Verzögerung dazu führt, dass irgendwann bessere Schätzprogramme eine Zeitüberschreitung verursachen.

3
Bruce Ediger