Huge increase in brute force attacks?

Francisco

Company Lube
Verified Provider
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:

[[email protected] ~]# grep -c 2014-08-28 /var/log/blackholed.log

15

[[email protected] ~]# grep -c 2014-08-29 /var/log/blackholed.log

13

[[email protected] ~]# grep -c 2014-08-30 /var/log/blackholed.log

16

[[email protected] ~]# grep -c 2014-08-31 /var/log/blackholed.log

14

[[email protected] ~]# grep -c 2014-09-01 /var/log/blackholed.log

150

[[email protected] ~]# grep -c 2014-09-02 /var/log/blackholed.log

61

Anyone else seeing something similar?

Francisco
 
Last edited by a moderator:

mikho

Not to be taken seriously, ever!
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.
 

Francisco

Company Lube
Verified Provider
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
 

splitice

Just a little bit crazy...
Verified Provider
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

The Irrational One
Retired Staff
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

Well-Known Member
Verified Provider
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.
 

splitice

Just a little bit crazy...
Verified Provider
Feeling strangely left out. But I suppose that's for the best.


[email protected]:~# cat /var/log/bf/ssh-2014.09.03.log
38
[email protected]:~# cat /var/log/bf/ssh-2014.09.02.log
87
[email protected]:~# cat /var/log/bf/ssh-2014.09.01.log
60
[email protected]:~# cat /var/log/bf/ssh-2014.08.30.log
72
[email protected]:~# 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

Dormant VPSB Pathogen
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

Content Contributer
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.
 

Mid

New Member
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

New Member
Verified Provider
@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

New Member
@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

New Member
Verified Provider
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

Member
Verified Provider
@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.
 
Top