system is under attack (what can I do more?)

[Bruce Cran]

On Friday 18 June 2010 13:23:27 Dino Vliet wrote:
> Dear freebsd list,
> My server, which is a amd64 system running freebsd 8.0 is currently under
> attack from a botnet or something. Take a look at my /var/log/auth.log
> file:
> 
[...]
> 
> I looked at this and especially the way they seem to try different
> usernames (not fully random though) is quite clever. The postgres user
> they tried, worried me at first but fortunately I realized that postgres
> wasn't running on that server. I have configured the AllowUser directive
> in sshd_config and it only contains 2 usernames which can log in from sshd
> remotely.
> 
> Another "line of defence" is my pf firewall config which has the following
> in it:
> 
> pass in proto tcp from any to any port ssh keep state (max-src-conn 3,
> max-src-conn-rate 2/30, overload <bruteforce> flush global)
> 
> However, almost none of the ip-addresses above end up in that bruteforce
> table.
> 
> Now my questions are:
> 1) why doesn't ip-address 190.38.59.236 for instance isn't triggered by my
> pf rule? Is that because this connection stays within the limits? Should I
> change that, but then again, considering the attack rate....what values
> would be suitable? 2) are there other things I could do?

These types of ssh probes are common nowadays. Unless you have a misconfigured 
server you don't need to worry about users like postgres, uucp, games, bin, 
operator, daemon  etc. because they won't have a shell configured and so won't 
be allowed to login.  The attacks have recently started working around rate 
limits by only trying from a single address every few minutes.  Since you're 
already using the AllowUsers directive I suspect you're not really at much 
risk, but there are a few things you could do:

1. Don't allow password authentication. It might be a bit of a hassle to set 
up, but it's so much simpler once it's running to authenticate via ssh keys 
and it stops the bots in their tracks.

2. Block IP ranges that you won't login from, or, if you know of places you 
will login from, only allow connections from those IP addresses.

3. Move sshd to a different port. I don't like this workaround since although 
it stops the attacks it's nonstandard and means you have to remember to 
specify the port each time you connect.

-- 
Bruce Cran