ssh connections with no authentication attempts

T

ta0kira

I have a server running 9.1-RELEASE-p10. Periodically I get what appear to be brute-force attacks, based on /var/log/auth.log entries. There seems to be no attempt to authenticate, however, because I don't have any PAM authentication errors in my system logs. In fact, I don't think I've ever seen PAM authentication errors from unknown IP addresses, but I do see "Invalid user" quite frequently. I've considered that they might be collecting statistics regarding prompt latencies so that they have a better idea of whether or not they're using valid usernames. It could also be that they're only attempting to use private keys. Am I missing something here?
Thanks!

Kevin Barry
 
SirDice said:
They're brute-force attempts using a list of users and common passwords. Install something like security/sshguard-pf.
Click to expand...
I assumed that for quite a while; however, it doesn't look like they're using passwords. When I give a bad password, or any password when attempting to use an invalid user, I get "error: PAM: authentication error for" in /var/log/auth.log, but when I disconnect before I attempt to authenticate with an invalid user, I get "Invalid user". Messages resulting from the attacks are like the latter, and not like the former.

I wrote a daemon and program for use with pam_exec.so that tracks bad users and failed authentications as they happen, and adds IPs to a pf table. I noticed it wasn't blocking the attacking IPs, and I thought it was a problem with my program, but I tested it quite a bit more (and even faked attacks) and concluded that the attackers must not be using passwords. I now have it set up to block IPs that use invalid users, whether or not authentication is attempted.

Thanks!

Kevin Barry
 
Yeah, I'm not exactly sure what they're trying to do. I'm guessing it's some pre-authentication bug they're trying to abuse. Most of these things are automated, if they find the port open they'll try the exploit. Even if the exploit was written for a completely different operating system they'll still fire it at you.

It's an unfortunate part of having an internet facing service.
 
I've also been getting ssh connections that don't trigger any logging, other than ipfw logging the connection. That's strange, because for that to happen, the client must at least pretend to be ssh; otherwise, I'd get "Did not receive identification string" in /var/log/auth.log. I've managed to replicate the effect with ssh -o NumberOfPasswordPrompts=0 user@server. They also occur at a rate of once per 2-3s, keeping my pf overload rule from triggering. This is obviously an attempt to periodically check if the port is open without being detected. The attack is also spread out among several hosts on 2-3 different subnets, so I'm just blocking them all.

Kevin Barry
 
You must log in or register to reply here.
Back
Top