I've installed OSSEC on my server and I've been getting reports similar to the following:

Jan 11 19:27:03 Daddy sshd[14459]: pam_unix(sshd:auth): authentication failure; logname= uid=0 euid=0 tty=ssh ruser= rhost= user=root
Jan 11 19:26:54 Daddy sshd[14457]: pam_unix(sshd:auth): authentication failure; logname= uid=0 euid=0 tty=ssh ruser= rhost= user=root

Repeated about 10 times per email. So far not a day has gone by without 3 or 4 of these emails from OSSEC. Of course my initial emotion is a bit of rage and "how dare they try to hack into my box!" but I guess that's the state of the 'net these days anyway. The other day I also had someone try with user bin

I also recieved this message:

Jan 12 02:04:07 Daddy sshd[16109]: reverse mapping checking getaddrinfo for static-52-53.mk-net.ru [] failed - POSSIBLE BREAK-IN ATTEMPT!

(again, with multiple repeats)

I know at least one benign source of the reverse mapping comes from freenode when they try to make sure you're not a likely botnet, but I haven't gone checking about that source.

We're pretty sensitive about the issue of vulnerabilities, especially since a previous server was hacked (probably) via phpMyAdmin.

So obviously any advice/resources for securing our server would be appreciated, but my main question is this: should we be worried about these break-in attempts? The root user has no password (login disabled) so is it safe to ignore these failed logins? Is there anything else that I could or should do to limit the possible vulnerabilities along this avenue? This system is behind a router with only essential (e.g. services we're using) ports open (ssh, apache, and postfix).

2 Answers 2


Yeah, you can definitely ignore the root failed attempts if root login over SSH is disabled - and the reverse-DNS failures aren't worth worrying about; they may well be from an attacker, but it's just their ISP's inconsistent configuration.

If you want to sleep a bit better, take a look at fail2ban - it can be set up to temporarily block the IPs of the attackers after repeated failures.


Should I be worried? only if you're not sure about how it's secured.

With SSH, the highest form of security is to force both key & pass phrase login.

You can dramatically reduce (but not stop) login attempts to SSH but changing the port number from the default 22 to something else. It does nothing to beef up the security, but it does put off a lot of automated probes which probe common port numbers to see if there is a listening service.

If it's practical, only allow TCP connections to port 22 from known locations through the use of your firewall rules. Otherwise, there are methods to block/firewall off several failed connection attempts from those locations. fail2ban is one script that does this (as already mentioned already by Shane). I can recommend it as I've used it before.

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.