Blocking a slow-burning SSH bruteforce

[J.D. Bronson]

On 1/1/10 8:56 AM, David Rawling wrote:
> I tend to think there's not much I can do about this, but I'll ask anyway.
>
> I've implemented sshguard to block the normal bruteforce attacks - which
> seems to be working reasonably well.
>
> However now I have the following:
>
> Jan  1 17:42:52 timeserver sshd[1755]: error: PAM: authentication error
> for illegal user but from 190.146.246.36
> Jan  1 17:55:09 timeserver sshd[1788]: error: PAM: authentication error
> for illegal user byung from 212.243.41.9
> Jan  1 18:07:38 timeserver sshd[1809]: error: PAM: authentication error
> for illegal user cac from 148.233.140.193
> Jan  1 18:20:06 timeserver sshd[1832]: error: PAM: authentication error
> for illegal user cachou from 121.52.215.180
> Jan  1 18:32:21 timeserver sshd[1851]: error: PAM: authentication error
> for illegal user calla from 212.243.41.9
> Jan  1 18:44:35 timeserver sshd[1884]: error: PAM: authentication error
> for illegal user calube from 83.211.160.211
> Jan  1 19:09:12 timeserver sshd[1923]: error: PAM: authentication error
> for illegal user cancy from 194.51.12.238
> Jan  1 19:21:35 timeserver sshd[1946]: error: PAM: authentication error
> for illegal user candice from 82.106.226.77
> Jan  1 19:46:12 timeserver sshd[1997]: error: PAM: authentication error
> for illegal user candyw from 116.55.226.131
>
> Now this seems to me to be a dictionary attack on timeserver, and I'd
> guess that it's a botnet behind it. It's rather sophisticated since it's
> only attempting 1 user and password combination per source - so it's far
> too little to trigger the sshguard rules. Even if it did trigger, it
> wouldn't prevent the attacks.
>
> Apart from switching away from user authentication to private/public
> keys ... is there anything I can do to mitigate these attacks? Any
> advice welcome.
>
> Dave.
>
> --

Few options I can think of in random order...I use #1:

1. Run SSH on an obscure port. Seriously, thats one of the easiest 
things to do. Since I have done that, I have had ZERO attempts and it 
works perfectly as long as users know the odd port. In fact, I dont know 
anyone in our IT circle of friends that runs SSH on port 22.

2. Consider controlling/limiting access via 'pf' if your running 'pf'.

Of course with your examples coming from all different IPs, thats not 
likely gonna help much.

3. Just ignore it - they aren't getting in...similar to spammers being 
rejected by RBLs....its traffic, but cant be a whole lot.

4. Limit login time window too...I run a very narrow window of time to 
login and a LOW number of attempted logins per session.

-JD