Do you have a question? Post it now! No Registration Necessary.  Now with pictures!

Threaded View
Hi kids

I get daily LogWatch messages from my servers and one of them came up with a
shedload of messages as follows:

reverse mapping checking getaddrinfo for db2.tallion.com failed - POSSIBLE

I had about a hundred of these now; I think my server is secure, as it only
accepts Version 2 connections and doesn't accept password authentication.

Any suggestions as to what else I can do to lock this down and [if possible]
not have to see/worry about these messages?

Conveniently, there's no documentation on this on the openssh site nor any
mention of it except for bug reports in the mailing lists.

Any ideas?



Quoted text here. Click to load it

Is db2.tallion.com a host from which you would normally expect

Quoted text here. Click to load it

If you put "VerifyReverseMapping no" in your sshd configuration file,
you won't see these messages.  Having VerifyReverseMapping turned on
is of dubious value anyway.

The default is supposed to be "no", but Apple turns it on for the
version of OpenSSH it supplies for Mac OS X (OpenSSH_3.6.1p1+CAN-2004-0175).
The reverse mapping check in that version is broken, though: we were
seeing these messages on my employer's hosts for *all* IP addresses
resolvable to host names, even when the check should clearly have
succeeded.  Since it was providing no useful information other than
that the address was resolvable, we turned it off.

John Wingate                        Mathematics is the art which teaches
johnww@worldpath.net                one how not to make calculations.
                                                         --Oscar Chisini


Quoted text here. Click to load it

Funny, I see db2.tallion.com in my logs (yesterday) as well. I
received hundreds of failed login attempts from this server on my ssh
port. I don't get that many attempts from other hosts. I have
explicitly added a firewall rule blocking any connections from this

Quoted text here. Click to load it

Disconnecting the computer is the only true way of being safe.
Otherwise deny password logins, root logins etc. Find out the hosts
you login from and only allow access to your ssh port from those
hosts. There's lots of documentation on security tradeoffs. Basically
the more you allow the more vulnerable you become.



On Mon, 25 Oct 2004 11:07:19 +0100, "Justin Finkelstein"

Quoted text here. Click to load it

Only a hundred?  Wait until one of the _serious_ (but stupid) SSH
cracker programs gets hold of your IP address.  I was getting over
1,500 _per_hour_ from one IP address.

Quoted text here. Click to load it

It depends a lot on who your SSH clients are.  If you have many,
spread out all over the world, that's one situation.  If you have few,
and localized, that's another.

You can set SSHD to answer on something besides the default port.
This works fine if all your clients can work with it, plus it gives
you the opportunity to put something on port 22 that jerks the
attacker's chain a bit.  The program I was using stripped the
whitespace from /unix, ROT13'd it, and spat it out the port.  Over and
over, as long as something was connected.  

Unfortunately, I had to discontinue that, because a couple of my users
are behind corporate firewalls that are very picky about what goes
out.  So I have to have SSHD on 22.

You can just firewall off parts of the internet from which you expect
no authorized traffic.  I actually found it easier to allow access
from subnets I know are sources of authorized traffic, and close the
port to the rest of the 'net.

If you want to get clever, have your logwatcher program generate
firewall entries after X unsuccessful login attempts.  This has the
potential for a self-DOS, so think it through.

Turn off logging of rejected port traffic, unless you dig the
amusement value.


Site Timeline