Change the default ssh port. Most of the attacks are from automated crawlers that try to brute force port 22. Your logs will become much more manageable.
You should also run logwatch - it will show you all the attempts that keep happening on any public servers running ssh.
I once had to look at a box compromised, which was then used to brute force other servers, and it contained a file with 100-200 passwords for other hosts it brute-forced.
Do you actually run any public server with ssh on 22 and monitoring logs about it? From my experience noise on port 22 is so high that you wouldn't even notice actual targeted attempt.
I always install fail2ban or something like it on servers I want to have SSH on. Really cuts down on the log volume, even if I have locked myself out occasionally. The thing about port scanning is that it's cheap as hell. There's less than 4 billion IP4 addresses and zmap can hit them all within an hour on a decent network connection.
IPs on the log files most likely are exit proxies if those attackers were not rookies. Simply change the SSH port only would deter 90% of those attempts per my personal experience.
Nice analysis! You should protect your infra to avoid this kind of scanning:
- Disable password login for SSH, use keys instead.
- Limit access to known IPs (with a managed vpn)
- Use Cloudflare: Their WAF is really good
- Forward logs to an other service that can analysis logs (datadog is nice)
shameless plug: started a small honeypot service[1] if anyone would need it as a last resort[1] to catch hackers in your servers . Feedbacks appreciated!
It is so common I'd be surprised if you weren't seeing these login attempts. Every ssh server I've run in the last 10 years has had this happen, even those without domain names. They must just scan random IPv4 addresses for anyone responding on port 22. It's the modern equivalent of wardialing.
Changing the SSH port proved to be most successful. Yes, of course you can find the port with a port scan. But it keeps the logs clean. And I don't want to waste CPU cycles on some brute-forcing idiots.
It's interesting to log failed SSH attempts, I normally get someone trying to brute force access within an hour or two of brining a server up. Changing to a non standard port doesn't deter them for long.
Are we just speculating? SSH scanners are not sources of DDoS. Large companies have ssh bastions on the internet and do not worry about ssh DDoS. Its not really a thing that happens.
You don't need to freak out if you see a bunch of failed ssh auth attempts in your logs. Just turn off password based authentication and rest easy.
1. SSH - security related - modify sshd config - no password auth, only key based, no root login, other than that the default sshd config for Ubuntu 12.04 is pretty ok.
PermitRootLogin no
If you do not use IPv6, you can disable sshd to use it.
#ListenAddress ::
ListenAddress 0.0.0.0
2. SSH - ease of maintenance related - change default port from 22 to smth else. This will not help against targeted attacks, but this will reduce the noise in the logs and will allow better visibility of attack attempts.
#Port 22
Port 63777 (or whatever)
Don't forget to reload ssh for changes to take effect and check with netstat what's running where.
If you are concerned with getting locked out you can do this:
2.1. enable sshd to listen on multiple ports simultaneously
Port 22
Port 63777 (or whatever)
2.2. Login through Port 63777, and only then disable Port 22.
3. The PRC thing - fail2ban and hosts is simple but not the best tools for the job.
3.1. You can disable access to your site for all China (or any other country for this matter) using ipset. Much better speed and ease of maintenance, it's even better then using iptables itself [ipset is iptables module], one set can contain/block up to 65000+ IPs.
3.2. If you want smth more targeted, then consider either sshguard or psad. They can be configured to block inline and dynamically add rules [perm/temp] to iptables.
Edit: forgot to mention another cute recipe. see below
If you are on AWS and are using security groups (you should), after you are done on the server, you can go to the security group in AWS Mgt Console and remove ingress for ssh ports. Now your server is accessible only on 80/443 and ssh is NOT accessible to anyone. Later, when you need to access the server - enable ingress for the ssh ports, do your job and disable again.
A few useful resources:
If you don't want your SSH server being found by trivial port-scanning, apply port-knocking:
https://github.com/moxie0/knockknock
I've nearly eliminated the problem with brute force attacks, but it's quite multilayered. I use public key authentication with strong passphrases, but leave password authentication enabled for the standard port, so I'll focus on that as the weak link. Assuming high quality passwords and nonobvious user names on systems where password authentication is allowed, set "PermitRootLogin no", "MaxAuthTries 3", and explicitly list users: "AllowUsers fooz1 barx2 cary3" in sshd_config. This is usually enough to foil most random brute force attacks seeking low hanging fruit. After that, the main problem is log noise and the fact that the attack has been slowed, but not stopped. My next line of defense is a short-lived block using the recent module in my iptables startup script (on Linux):
IPTABLES=/usr/sbin/iptables
# only allow up to 2 connections in a 15 second period
$IPTABLES -A INPUT -p tcp --dport 22 \
-m state --state NEW \
-m recent --update --seconds 15 --hitcount 2 \
-j DROP
$IPTABLES -A INPUT -p tcp --dport 22 \
-m state --state NEW \
-m recent --set \
-j ACCEPT
That's enough to really slow down brute force attacks without locking out fat-fingered users for too long.
Finally, I use fail2ban to block persistent attacks for 6 hours after 8 failures/hr in jail.conf:
This allows me to identify attacks and penalize them hard without affecting real users. This basically leaves a DoS as the only threat, and only if you're using the same IP address as the attacker.
It may look complicated, but it only takes a few minutes to set up and doesn't require using a nonstandard port (which you can do to further harden the system, along with other things). In my experience, this has been enough to thwart brute force attacks against ssh.
An ssh server isn’t really like a front door though. I don’t necessarily think attempting a random ssh server should be a crime.
I used to spend time on custom iptables scripts but came to the conclusion it’s much better to just architect things in a way where the bots and scanners can’t plausibly create a problem and then ignoring them.
Hang any SSHD on the internet, and within minutes you get these attempts. You can choose to log the passwords if you like and this is what you would see.
It even happens if you just open port 22 on your home router. You can use things like fail2ban to put a short-term ban on offending addresses, and put your ssh server on a random (i.e. not 2222) high numbered port to reduce automated scans.
The article makes it sound like the SSH brute-forcing requests were part of the attack, but it's unlikely - they are very common. My servers get several of these attacks a day.
I don't like changing my default SSH port, but I don't like people trying to brute-force my SSH passwords either. Instead I use iptables to drop SSH connections from any IP address that attempts to connect overly frequently. This is highly efficient (compared to scripts like fail2ban) and very simple to implement:
# SSH daemon - tcp Port 22 - drop any more than 3 new connections from one address every 5 mins
$IPTABLES -I INPUT -p tcp -i eth+ --dport 22 -m state --state NEW -m recent --set
$IPTABLES -I INPUT -p tcp -i eth+ --dport 22 -m state --state NEW -m recent --update --seconds 300 --hitcount 3 -j DROP
$IPTABLES -A INPUT -p tcp -i eth+ --dport 22 -j ACCEPT
reply