Blocking a slow-burning SSH bruteforce
J.D. Bronson
jd_bronson at sbcglobal.net
Fri Jan 1 15:07:43 UTC 2010
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
More information about the freebsd-questions
mailing list