How do I keep track of failed SSH log-in attempts?
772
I'd like to see if somebody has been trying to log-in by brute-force into my Ubuntu 12.04 server over SSH. How can I see if such activities have been taking place?
All login attempts are logged to /var/log/auth.log.
1. Filter for brute-force interactive SSH logins
Open a terminal, and type the below; if it's longer than 1 page you will be able to scroll up and down; type q to exit:
grep sshd.\*Failed /var/log/auth.log | less
Here's a real example from one of my VPSs:
Aug 18 11:00:57 izxvps sshd[5657]: Failed password for root from 95.58.255.62 port 38980 ssh2
Aug 18 23:08:26 izxvps sshd[5768]: Failed password for root from 91.205.189.15 port 38156 ssh2
Aug 18 23:08:30 izxvps sshd[5770]: Failed password for nobody from 91.205.189.15 port 38556 ssh2
Aug 18 23:08:34 izxvps sshd[5772]: Failed password for invalid user asterisk from 91.205.189.15 port 38864 ssh2
Aug 18 23:08:38 izxvps sshd[5774]: Failed password for invalid user sjobeck from 91.205.189.15 port 39157 ssh2
Aug 18 23:08:42 izxvps sshd[5776]: Failed password for root from 91.205.189.15 port 39467 ssh2
2. Look for failed connections (i.e. no login attempted, could be a port scanner, etc.):
Use this command:
grep sshd.*Did /var/log/auth.log | less
Example:
Aug 5 22:19:10 izxvps sshd[7748]: Did not receive identification string from 70.91.222.121
Aug 10 19:39:49 izxvps sshd[1919]: Did not receive identification string from 50.57.168.154
Aug 13 23:08:04 izxvps sshd[3562]: Did not receive identification string from 87.216.241.19
Aug 17 15:49:07 izxvps sshd[5350]: Did not receive identification string from 211.22.67.238
Aug 19 06:28:43 izxvps sshd[5838]: Did not receive identification string from 59.151.37.10
How to reduce failed/brute-force login attempts
Try switching your SSH to a non-standard port from the default 22
I would argue that monitoring logs is a weak solution especially if you have a weak password on an account. Brute attempts often try at least hundreds of keys per minute. Even if you have a cron job set to email you of brute attempts, it could be hours before you get to your server.
If you have a public-facing SSH server, you need a solution that kicks in long before you can be hacked.
I would strongly recommend fail2ban. Their wiki says what it does better than I can.
Fail2ban scans log files (e.g. /var/log/apache/error_log) and bans IPs that show the malicious signs -- too many password failures, seeking for exploits, etc. Generally Fail2Ban then used to update firewall rules to reject the IP addresses for a specified amount of time, although any arbitrary other action (e.g. sending an email, or ejecting CD-ROM tray) could also be configured. Out of the box Fail2Ban comes with filters for various services (apache, curier, ssh, etc).
Getting protection from it is as simple as sudo apt-get install fail2ban.
By default as soon as somebody has three failed attempts, their IP gets a five minute ban. That sort of delay essentially halts a SSH brute force attempt but it's not going to ruin your day if you forget your password (but you should be using keys anyway!)
Short Answer:
To keep track of the failed attempts, you should just view the log file /var/log/auth.log without using any pattern matching commands because those patterns are not exhaustive. Then, to mitigate it, you could use tools like fail2ban.
Long Answer:
There are many ways for invalid logins to happen. For example, an attacker might try some default usernames and passwords like the default "kali" username and "kali" password on Kali Linux. (It is a technique German hackers used extensively during the Cold War era. Read The Cuckoo's Egg if you are interested.)
Say if you remove the "kali" user, the grep commands above won't catch this:
Nov 25 07:11:32 Everything20170707 sshd[27216]: input_userauth_request: invalid user kali [preauth]
All login attempts are logged to
/var/log/auth.log.1. Filter for brute-force interactive SSH logins
Open a terminal, and type the below; if it's longer than 1 page you will be able to scroll up and down; type
qto exit:Here's a real example from one of my VPSs:
2. Look for failed connections (i.e. no login attempted, could be a port scanner, etc.):
Use this command:
Example:
How to reduce failed/brute-force login attempts
I would argue that monitoring logs is a weak solution especially if you have a weak password on an account. Brute attempts often try at least hundreds of keys per minute. Even if you have a cron job set to email you of brute attempts, it could be hours before you get to your server.
If you have a public-facing SSH server, you need a solution that kicks in long before you can be hacked.
I would strongly recommend
fail2ban. Their wiki says what it does better than I can.Getting protection from it is as simple as
sudo apt-get install fail2ban.By default as soon as somebody has three failed attempts, their IP gets a five minute ban. That sort of delay essentially halts a SSH brute force attempt but it's not going to ruin your day if you forget your password (but you should be using keys anyway!)
Short Answer: To keep track of the failed attempts, you should just view the log file
/var/log/auth.logwithout using any pattern matching commands because those patterns are not exhaustive. Then, to mitigate it, you could use tools like fail2ban.Long Answer: There are many ways for invalid logins to happen. For example, an attacker might try some default usernames and passwords like the default "kali" username and "kali" password on Kali Linux. (It is a technique German hackers used extensively during the Cold War era. Read The Cuckoo's Egg if you are interested.)
Say if you remove the "kali" user, the grep commands above won't catch this: