sshd Warnung: "MÖGLICHER EINBRUCHVERSUCH!" für fehlgeschlagenes Reverse-DNS

Immer wenn ich irgendwo SSH mache, bekomme ich so etwas in den Protokollen:

sshd[16734]: reverse mapping checking getaddrinfo for
    1.2.3.4.crummyisp.net [1.2.3.4] failed - POSSIBLE BREAK-IN ATTEMPT!

Und es ist richtig: Wenn ich es tue host 1.2.3.4, kehrt es zurück 1.2.3.4.crummyisp.net, aber wenn ich es tue host 1.2.3.4.crummyisp.net, wird es nicht gefunden.

Ich habe zwei Fragen:

1. Welche Sicherheitsbedrohung gibt es? Wie könnte jemand einen Einweg-DNS auf bedrohliche Weise vortäuschen?

2. Habe ich einen Rückgriff, um dies zu beheben? Ich werde meinem ISP einen Fehlerbericht senden, aber wer weiß, wohin das führen wird.

Welche Sicherheitsbedrohung gibt es?
Wie könnte jemand einen Einweg-DNS auf bedrohliche Weise vortäuschen?

Jede Partei, die die Kontrolle über eine DNS-Reverse-Zone hat, kann ihre PTR-Einträge nach Belieben einstellen. Es ist denkbar, dass jemand seinen PTR-Rekord auf legithost.example.comsetzt und dann versucht, seinen Weg in Ihre Umgebung brutal zu erzwingen.

Wenn Sie Benutzer mit fetten Fingern haben, die dazu neigen, ihre Passwörter falsch einzugeben, und denen es an Anti-Brute-Force-Maßnahmen mangelt, kann eine Reihe von Protokolleinträgen für fehlgeschlagene Passwörter von legithost.example.comals "Oh, das ist nur Bob - er kann nicht tippen" abgetan werden rette sein Leben!" und geben Sie einem Angreifer die Möglichkeit, Passwörter zu erraten, bis sie eintreten.

(Der theoretische Sicherheitsvorteil dieser Nachricht besteht darin, dass der Angreifer den Eintrag in Ihrer DNS-Zone nicht erstellen / ändern kann, sodass er die Warnung nicht stummschalten kann - ohne einen DNS-Vergiftungsangriff ...)Alegithost.example.com

Habe ich einen Rückgriff, um dies zu beheben?

Option 1: Korrigieren Sie Ihren DNS so, dass die Einträge vorwärts ( A) und rückwärts ( PTR) übereinstimmen.
Option 2: Fügen UseDNS noSie der sshd_configDatei Ihres Systems hinzu, um die Warnung zu schließen.

Wenn HostbasedAuthenticationeingerichtet, kann tou Hostnamen angeben, die sich anmelden können /etc/hosts.equiv, ~/.shostsund ~/.rhosts. (Es gibt auch eine Überprüfung des öffentlichen Schlüssels auf dem Client-Host (möglicherweise known_hostauf dem Server).

Dies kann ausgenutzt werden, wenn der Schlüssel undicht ist (in diesem Fall haben Sie bereits ein Problem) und HostbasedUsesNameFromPacketOnlyauf yes( UseDNS nomöglicherweise auch erforderlich) eingestellt ist und ein Angreifer mit den entsprechenden Schlüsseln den Hostnamen eines autorisierten Hosts angibt.

Ein weiterer Angriff kann ein bekannter Server sein, der vorgibt, ein anderer bekannter Server zu sein, um höhere Berechtigungen zu erhalten.

Um diese Angriffe zu vermeiden, wird das umgekehrte und das vorwärts gerichtete DNS verglichen (und der Protokolleintrag wird angezeigt, wenn sie nicht übereinstimmen).

Die andere Sache, die angegriffen werden könnte: der authorized_keys host=Parameter und MatchBlock für a Host, die für den falschen Host aktiviert werden können, falls Hostnamen (anstelle von IP-Adressen) verwendet und DNS-Einträge geändert werden. ( UseDNS yeswird benötigt, um hierfür Nicht-IPs zu verwenden)