"MÖGLICHER EINBRUCHVERSUCH!" In / var / log / secure - was bedeutet das?

96

Ich habe eine CentOS 5.x-Box, die auf einer VPS-Plattform läuft. Mein VPS-Host hat eine Supportanfrage zur Konnektivität falsch interpretiert und einige iptables-Regeln effektiv gelöscht. Dies führte dazu, dass ssh den Standardport abhörte und Port-Konnektivitätstests bestätigte. Nervig.

Die gute Nachricht ist, dass ich SSH-autorisierte Schlüssel benötige. Soweit ich das beurteilen kann, glaube ich nicht, dass es eine erfolgreiche Verletzung gegeben hat. Ich bin immer noch sehr besorgt über das, was ich in / var / log / secure sehe:

Apr 10 06:39:27 echo sshd[22297]: reverse mapping checking getaddrinfo for 222-237-78-139.tongkni.co.kr failed - POSSIBLE BREAK-IN ATTEMPT!
Apr 10 13:39:27 echo sshd[22298]: Received disconnect from 222.237.78.139: 11: Bye Bye
Apr 10 06:39:31 echo sshd[22324]: Invalid user edu1 from 222.237.78.139
Apr 10 06:39:31 echo sshd[22324]: reverse mapping checking getaddrinfo for 222-237-78-139.tongkni.co.kr failed - POSSIBLE BREAK-IN ATTEMPT!
Apr 10 13:39:31 echo sshd[22330]: input_userauth_request: invalid user edu1
Apr 10 13:39:31 echo sshd[22330]: Received disconnect from 222.237.78.139: 11: Bye Bye
Apr 10 06:39:35 echo sshd[22336]: Invalid user test1 from 222.237.78.139
Apr 10 06:39:35 echo sshd[22336]: reverse mapping checking getaddrinfo for 222-237-78-139.tongkni.co.kr failed - POSSIBLE BREAK-IN ATTEMPT!
Apr 10 13:39:35 echo sshd[22338]: input_userauth_request: invalid user test1
Apr 10 13:39:35 echo sshd[22338]: Received disconnect from 222.237.78.139: 11: Bye Bye
Apr 10 06:39:39 echo sshd[22377]: Invalid user test from 222.237.78.139
Apr 10 06:39:39 echo sshd[22377]: reverse mapping checking getaddrinfo for 222-237-78-139.tongkni.co.kr failed - POSSIBLE BREAK-IN ATTEMPT!
Apr 10 13:39:39 echo sshd[22378]: input_userauth_request: invalid user test
Apr 10 13:39:39 echo sshd[22378]: Received disconnect from 222.237.78.139: 11: Bye Bye

Was genau bedeutet "MÖGLICHER EINBRUCHVERSUCH"? Dass es erfolgreich war? Oder dass es nicht gefallen hat, von welcher IP die Anfrage kam?

linux security ssh centos Mike B
quelle

Antworten:

78

Leider kommt dies mittlerweile sehr häufig vor. Es handelt sich um einen automatisierten Angriff auf SSH, bei dem "gebräuchliche" Benutzernamen verwendet werden, um zu versuchen, in Ihr System einzudringen. Die Nachricht bedeutet genau das, was sie sagt. Sie bedeutet nicht, dass Sie gehackt wurden, sondern nur, dass es jemand versucht hat.

Iain
quelle
Danke Lain. Dadurch fühle ich mich besser. Ich bin wirklich froh, dass ich autorisierte Schlüssel für ssh benötige. =)
Mike B
28
"Reverse-Mapping-Überprüfung von getaddrinfo für" befasst sich eher mit der Erstellung von Quell-IP / Hostname. Derselbe gestaltete Datenverkehr versucht, falsche Benutzernamen zu ermitteln, aber falsche Benutzernamen generieren nicht die Meldung "MÖGLICHER EINBRUCHVERSUCH".
Giftbit
11
@MikeyB: Vielleicht möchten Sie versuchen, Ihrem System fail2ban hinzuzufügen . Dies kann so konfiguriert werden, dass die IP-Adressen dieser Angreifer automatisch blockiert werden.
user9517
9
Beachten Sie, dass "Reverse Mapping fehlgeschlagen" einfach bedeuten kann, dass der ISP des Benutzers das Reverse DNS nicht richtig konfiguriert hat, was sehr häufig vorkommt. Siehe die Antwort von @Gaia.
Wilfred Hughes
1
Dies ist ungenau. Es bedeutet lediglich, dass der Reverse-DNS nicht mit dem Hostnamen übereinstimmt, den der Client gesendet hat, um sich zu identifizieren. Es ist wahrscheinlich markiert, da dies eine Unterbrechung des Versuchs für die Benutzer .rhostsoder der .shostsAuthentifizierung gewesen sein könnte (ich habe noch nie gesehen, dass diese verwendet wurden). Scans passiert, aber das ist nicht das, was diese Nachricht über ist (obwohl jede Verbindung kann es auslösen) (Für Scans, die ausgefallenen Auth / unbekannt Benutzernachrichten besser suchen)
Gert van den Berg
52

Der Teil "MÖGLICHE EINBRUCHVERSUCHE" bezieht sich speziell auf den Teil "Überprüfung der umgekehrten Zuordnung getaddrinfo fehlgeschlagen". Dies bedeutet, dass für die Person, die die Verbindung hergestellt hat, Forward- und Reverse-DNS nicht richtig konfiguriert wurde. Dies ist besonders bei ISP-Verbindungen sehr verbreitet, woher der "Angriff" wahrscheinlich kam.

Unabhängig von der Meldung "POSSIBLE BREAK-IN ATTEMPT" (MÖGLICHE EINBRUCHVERSUCHE) versucht die Person tatsächlich, sich mit gebräuchlichen Benutzernamen und Kennwörtern einzumischen. Verwenden Sie keine einfachen Passwörter für SSH. Tatsächlich ist es die beste Idee, Kennwörter vollständig zu deaktivieren und nur SSH-Schlüssel zu verwenden.

Chris S
quelle
1
Wenn es durch eine (gültige) Verbindung über einen ISP generiert wurde, können Sie einen Eintrag zu Ihrer / etc / hosts-Datei hinzufügen, um diesen Reverse-Mapping-Fehler zu beseitigen. Natürlich würden Sie dies nur tun, wenn Sie wüssten, dass der Fehler harmlos ist und Ihre Protokolle bereinigen möchten.
Artfulrobot
32

"Was genau bedeutet" MÖGLICHER EINBRUCHVERSUCH "?"

Dies bedeutet, dass der Netblock-Besitzer den PTR-Datensatz für eine statische IP-Adresse in seinem Bereich nicht aktualisiert hat und dieser PTR-Datensatz veraltet ist, ODER dass ein ISP keine korrekten Reverse-Datensätze für seine dynamischen IP-Kunden erstellt. Dies ist selbst bei großen Internetdienstanbietern weit verbreitet.

Am Ende wird die Nachricht in Ihrem Protokoll angezeigt, weil jemand, der von einer IP-Adresse mit falschen PTR-Einträgen stammt (aus einem der oben genannten Gründe), versucht, gemeinsame Benutzernamen zu verwenden, um SSH auf Ihrem Server zu testen (möglicherweise ein Bruteforce-Angriff oder ein schwerwiegender Fehler) ).

Um diese Warnungen zu deaktivieren, haben Sie zwei Möglichkeiten:

1) Wenn Sie eine statische IP- Adresse haben , fügen Sie Ihre umgekehrte Zuordnung zu Ihrer Datei / etc / hosts hinzu (weitere Informationen finden Sie hier ):

10.10.10.10 server.remotehost.com

2) Wenn Sie eine dynamische IP- Adresse haben und diese Warnungen wirklich entfernen möchten, kommentieren Sie die Option "GSSAPIAuthentication yes" in Ihrer Datei / etc / ssh / sshd_config aus.

Gaia
quelle
2
das kommentieren GSSAPIAuthenticationhilft in meinem
SET
UseDNS noist wahrscheinlich die bessere Einstellung, um es loszuwerden (und langsame Anmeldungen, wenn der Server DNS-Probleme hat ...)
Gert van den Berg
15

Sie können das Lesen und Überprüfen Ihrer Protokolle vereinfachen, indem Sie Reverse-Lookups in sshd_config deaktivieren (UseDNS-Nr.). Dies verhindert, dass sshd die "Noise" -Zeilen mit "POSSIBLE BREAK-IN ATTEMPT" protokolliert, sodass Sie sich auf die etwas interessanteren Zeilen mit "Invalid user USER from IPADDRESS" konzentrieren können.

TimT
quelle
4
Was ist der Nachteil beim Deaktivieren von sshd-Reverse-Lookups auf einem mit dem öffentlichen Internet verbundenen Server? Hat es überhaupt einen Vorteil, diese Option aktiviert zu lassen?
Eddie
2
@ Eddie Ich glaube nicht, dass die von sshd durchgeführten DNS-Lookups irgendeinen nützlichen Zweck erfüllen. Es gibt zwei gute Gründe, die DNS-Suche zu deaktivieren. Die DNS-Suche kann die Anmeldung verlangsamen, wenn das Zeitlimit für die Suche überschritten wird. Und die Meldungen "MÖGLICHER EINBRUCH-VERSUCH" im Protokoll sind irreführend. Diese Meldung bedeutet nur, dass der Client DNS falsch konfiguriert hat.
Kasperd
1
Ich stimme @OlafM nicht zu - "UseDNS no" weist sshd an, die Reverse-Mapping-Prüfung nicht durchzuführen, und fügt daher keine Zeilen mit "POSSIBLE BREAK-IN ATTEMPT" zu den Systemprotokollen hinzu. Als Nebeneffekt kann dies auch Verbindungsversuche von Hosts beschleunigen, wenn Reverse-DNS nicht richtig konfiguriert ist.
TimT
1
Ja @OlafM habe ich gemacht, vor ca. 4-5 Jahren unter Linux. Es hat meine Protokolle erheblich verkürzt und logcheckmich nicht mehr mit wertlosen E-Mail-Berichten belästigt.
TimT
1
Die Hauptverwendung von UseDNSist für die (schlechte Idee zu verwenden) .rhostsund .shostsAuthentifizierung ( HostbasedAuthentication). (Und die FromÜbereinstimmungsoption in der SSHD-Konfiguration und authorized_keys) (Es gibt jedoch eine separate Einstellung, HostbasedUsesNameFromPacketOnlydie möglicherweise erforderlich ist, um Reverse-Lookups auch für Hosts-basierte Authentifizierung zu deaktivieren, was eine schlechtere Idee ist als die Verwendung der Host-basierten Authentifizierung ...)
Gert van den Berg
5

Es ist keine erfolgreiche Anmeldung erforderlich, sondern was es heißt "möglich" und "Versuch".

Ein böser Junge oder ein Script-Kiddie sendet Ihnen manipulierten Datenverkehr mit einer falschen Ursprungs-IP.

Sie können Ihren SSH-Schlüsseln Ursprungs-IP-Beschränkungen hinzufügen und so etwas wie fail2ban ausprobieren.

Giftbit
quelle
2
Vielen Dank. Ich habe iptables so eingestellt, dass nur SSH-Konnektivität von ausgewählten Quellen zugelassen wird. Ich habe auch Fail2Ban installiert und ausgeführt.
Mike B