sshd warning, "POSSIBLE BREAK-IN ATTEMPT!" for failed reverse DNS

Question

Whenever I SSH somewhere I get something like this in the logs:

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

And it is right: if I do host 1.2.3.4 it returns 1.2.3.4.crummyisp.net, but if I do host 1.2.3.4.crummyisp.net it is not found.

I have two questions:

1. What security threat is there? How could anyone fake a one-way DNS in some threatening way?

2. Do I have any recourse for fixing this? I'll send my ISP a bug report, but who knows where that'll go.

Answer 1

What security threat is there?
How could anyone fake a one-way DNS in some threatening way?

Any party with control of a DNS reverse zone can set their PTR records to whatever they want. It's conceivable that someone could set their PTR record to legithost.example.com, and then try to brute force their way into your environment.

If you have fat-fingered users who tend to mistype their passwords, and are lacking in anti-brute-force measures, a bunch of log entries for failed passwords from legithost.example.com could be dismissed as "Oh that's just Bob - he can't type to save his life!" and give an attacker the opportunity to keep guessing passwords until they get in.

(The theoretical security benefit from this message is that the attacker can't create/change the A record for legithost.example.com in your DNS zone, so he can't silence the warning - absent a DNS poisoning attack of some kind...)

---

Do I have any recourse for fixing this?

Option 1: Fix your DNS so the forward (A) and reverse (PTR) records match.
Option 2: Add UseDNS no to your system's sshd_config file to shut the warning up.

Answer 2

If HostbasedAuthentication is set up, tou can specify hostnames that can login in /etc/hosts.equiv, ~/.shosts and ~/.rhosts. (There is a public key check on the client host as well (It might be a known_host to the server)).

This can be exploited if the key leaks (in which case you already have a problem) and HostbasedUsesNameFromPacketOnly is set to yes (Possibly UseDNS no might be needed as well) and an attacker, with the relevant keys, gives the hostname of an authorised host.

Another attack can be one known server pretending to be a different known server to gain higher privileges.

In order to avoid these attacks, the reverse and forward DNS is compared (and the log entry appears if they don't match).

The other thing that might be attacked: the authorized_keys host= paramter and Match block for a Host, which can be activated for the wrong host in the case that hostnames are used (instead of IP addresses) and DNS entries are modified. (UseDNS yes is needed to use non-IPs for this)