# Huge increase in brute force attacks?



## Francisco (Sep 2, 2014)

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


----------



## mikho (Sep 2, 2014)

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 (Sep 2, 2014)

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


----------



## Francisco (Sep 2, 2014)

mikho said:


> 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 (Sep 2, 2014)

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


----------



## Jonathan (Sep 2, 2014)

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


----------



## Francisco (Sep 2, 2014)

KnownHost-Jonathan said:


> 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 (Sep 2, 2014)

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 (Sep 2, 2014)

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 (Sep 3, 2014)

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 (Sep 3, 2014)

Thank you for sharing this.

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


----------



## splitice (Sep 3, 2014)

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 (Sep 3, 2014)

KuJoe said:


> 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 (Sep 3, 2014)

DomainBop said:


> 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 (Sep 3, 2014)

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


----------



## Mid (Sep 3, 2014)

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 (Sep 3, 2014)

@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 (Sep 3, 2014)

@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 (Sep 3, 2014)

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 (Sep 3, 2014)

Mid said:


> @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.


----------



## HDPIXEL (Sep 4, 2014)

Yep, 60% from China and 35% from the Netherlands, 146.0.0.0/16.

I have csf and mod_sec doing to heavy lifting. 

Also, I'm working with customers to remove the user admin from all WP dbs.


----------



## datarealm (Sep 5, 2014)

We haven't seen much change in ssh, but wordpress has been through the roof.  The biggest increase has been probes for wordpress's xmlrpc...


----------



## drmike (May 1, 2016)

China can die in a fire this week for me.


What are guys using at node level police and detect bruteforces on SSH?  Nice container running fail2ban saw 10k attempts in under 24 hours.  Oh the overhead.


----------



## DomainBop (May 1, 2016)

drmike said:


> China can die in a fire this week for me.
> 
> 
> What are guys using at node level police and detect bruteforces on SSH?  Nice container running fail2ban saw 10k attempts in under 24 hours.  Oh the overhead.



Depending on the server, any or all of these:


1. change SSH ports


2. private key authentication only, disable password authentication


3. fail2ban


4. allowed list of users that can access SSH


5. restrict IPs that can access SSH (setup a VPN and only allow access to the SSH port through the VPN IPs)


6. hashlimit rules


7. dirty networks full of brute forcers, comment spammers, and other attackers are blocked in firewalls


AS36352 ColoCrossing
AS55286 B2Net Solutions (ServerMania)
AS46573 Global Frag
AS8100, AS62639, AS29761 Quadranet
AS46844 Sharktech
AS29073 Ecatel/Quasi Networks/ Novogara LTD


8. other firewall blocks of IPs used by brute forcers, attackers, and spammers:


http://www.spamhaus.org/drop/drop.lasso
http://www.spamhaus.org/drop/edrop.lasso
http://www.dshield.org/block.txt
http://torstatus.blutmagie.de/ip_list_exit.php/Tor_ip_list_EXIT.csv
http://www.cymru.com/Documents/bogon-bn-agg.txt
http://www.projecthoneypot.org/list_of_ips.php?t=d&rss=1
http://danger.rulez.sk/projects/bruteforceblocker/blist.php
https://www.openbl.org/lists/base_30days.txt
http://www.autoshun.org/files/shunlist.csv
https://www.maxmind.com/en/anonymous_proxies
http://www.stopforumspam.com/downloads/listed_ip_1.zip


9. You could also setup port knocking but it makes logins a pain in the ass so not recommended unless you're a sadist


----------



## drmike (May 1, 2016)

Issue @DomainBop is all of the above is really suited to single end user, but on baremetal in provider environment probably all of those approaches = suicide.


With flows of these attacks / attempts the overhead on say iptables / ipset would really run up quickly.  I saw something like 900MB of SSH attempts in under a minute.


----------

