Huge increase in brute force attacks?

[Francisco]

Aldryic messaged me early yesterday morning telling me he had been seeing an unusual amount of SSH brute forces coming in.

Sure enough, I ran a quick counter and saw a RETARDED spike in the past 2 days:

[root@nj-edge01 ~]# grep -c 2014-08-28 /var/log/blackholed.log

15

[root@nj-edge01 ~]# grep -c 2014-08-29 /var/log/blackholed.log

13

[root@nj-edge01 ~]# grep -c 2014-08-30 /var/log/blackholed.log

16

[root@nj-edge01 ~]# grep -c 2014-08-31 /var/log/blackholed.log

14

[root@nj-edge01 ~]# grep -c 2014-09-01 /var/log/blackholed.log

150

[root@nj-edge01 ~]# grep -c 2014-09-02 /var/log/blackholed.log

61

Anyone else seeing something similar?

Francisco

 

[mikho]

Oh yes,


Had a server almost die on me when the logs almost filled the disk.


Mostly chinese IPs and dropping a couple of /24 has temporary(?) solved the problem.

 

[Munzy]

I guess I could add a option for blocking only port 22 in ASN-Blocklist?

 

[Francisco]

Oh yes,

Had a server almost die on me when the logs almost filled the disk.

Mostly chinese IPs and dropping a couple of /24 has temporary(?) solved the problem.

We've been improving our IDS a lot in the past couple months since we've seen some weird attacks

occur. There's a really nasty one I won't document until I can figure out a proper fix.

Francisco

 

[Patrick]

Seen a lot for the past few months, mostly from China or Argentina. 

 

[Jonathan]

Why don't you lock down shell to certain IPs only?

 

[Francisco]

Why don't you lock down shell to certain IPs only?

No no.

Our IDS monitors the whole network, in this case that sampling is from New Jersey.

Each ban is because it tripped an alarm and got itself banned.

Francisco

 

[splitice]

Our has been sitting at approximately 40-80/day for each server for quite a while. I cant see any peaks on the server level that would indicate a significant upwards trend.

I am guessing its localized. I am surprised you get so few.

 

[HalfEatenPie]

I remember a while back (like maybe a year or two?) IPXCore had a VM on their server trying to brute force into the host node. 

Dat sheet cray 

 

[KuJoe]

At first I thought this thread was going to be about this.

Just checked and I'm seeing our brute force detection script has been spitting out significantly more e-mails over the past 2 days.

 

[wlanboy]

Thank you for sharing this.

Now I now why I do get such a lot of Fail2ban mails.

 

[splitice]

Feeling strangely left out. But I suppose that's for the best.


root@us1:~# cat /var/log/bf/ssh-2014.09.03.log
38
root@us1:~# cat /var/log/bf/ssh-2014.09.02.log
87
root@us1:~# cat /var/log/bf/ssh-2014.09.01.log
60
root@us1:~# cat /var/log/bf/ssh-2014.08.30.log
72
root@us1:~# cat /var/log/bf/ssh-2014.08.29.log
73
I wonder if there is a new botnet making the rounds, or new exploitable vulnerability in use.

 

[DomainBop]

At first I thought this thread was going to be about this.

I think that is the reason I saw a huge increase in WordPress brute force attempts this weekend.  I had one blog with over 20,000 attempts in a 48-hour period.

I haven't seen any increase in SSH brute force attempts recently but all of my dedicated servers are in Europe which may be why.  I usually get a lot of brute force attempts from Iran, Turkey, and Russia but not many from China.

 

[wlanboy]

I think that is the reason I saw a huge increase in WordPress brute force attempts this weekend.  I had one blog with over 20,000 attempts in a 48-hour period.

Please don't talk about wordpress.

It is a hell of a week for everyone hosting known blogs.

 

[Flapadar]

In the last 16 hours we've blocked 36,000 bruteforce attempts to our client's SSH

 

[Mid]

May be, Is it better for the ssh daemon to support timing based acceptance? (like discarding all login requests that are not in the defined seconds range, say 25 to 29 and/or 55 to 59).

This way, it might be somewhat a waiting game (at most 30 or 60 seconds) for a genuine client to issue a login request, but it would make the brute forcer's job even harder, they might actually fail the login attempt even with the correct (brute forced) password.

I think those like me would be happy to have even more wait times (making it even harder), like logins allowed only on minutes divisible by 2 (or 3), may be in addition to the seconds limit.

 

[rds100]

@Mid what if the server's time is off? Or your time is off? Or you are trying to login from some slow lagged wifi... Imagine the frustration.

 

[Mid]

@rds100 What if the server's network is off? Or your network is off? You can only ssh if the server is up, while it is so what would be the problem to have it updated with a time server (and your local system too). This requirement in fact could be more helpful with security. Probably, sshd should restrict logins by "local time zone" as well (or user defined multiple time zones).

Slow lagged connection?, for that you have a time window (5 seconds or more) as defined by the user. Of course it could be frustration for some, but this option isn't for those, it is for those security concerned.

 

[rds100]

I am sorry to disappoint you, but this is not security. Only allowing ssh logins for 5 seconds every minute only reduces the risk from bruteforcing by a factor of 12.

It is much better to just allow ssh from only a handful of static, trusted IPs. Filter everything else.

 

[Flapadar]

@rds100 What if the server's network is off? Or your network is off? You can only ssh if the server is up, while it is so what would be the problem to have it updated with a time server (and your local system too). This requirement in fact could be more helpful with security. Probably, sshd should restrict logins by "local time zone" as well (or user defined multiple time zones).

Slow lagged connection?, for that you have a time window (5 seconds or more) as defined by the user. Of course it could be frustration for some, but this option isn't for those, it is for those security concerned.

That just trades in an inconvenience for something that wouldn't fool a human for long. As rds100 says, that isn't security.

SSH keys + (where suitable) trusted login IP address is enough to deter almost attacker from using brute force attacks.