If you have ssh enabled on a system that is accessible to the Internet, it is probable that malicious individuals will try to gain access to the system by brute force login attempts. I.e., since a Linux, Unix, or OS X system is likely to have a root account, an attacker may use "root" as the userid and then attempt to login with commonly used passwords. There are sites on the Internet that provide lists of passwords commonly used and an attacker can easily use a dictionary attack where he tries every word in a dictionary as a possible password. Attackers can use dictionaries for multiple languages, lists of sports teams, name dictionaries, e.g., dictionaries of names parents might check to aid in selecting a name for a baby, etc. So a root or another administrator account should have a strong password. If it doesn't, the system will likely be cracked by an attacker eventually.
Attackers also routinely use name dictionaries to break into systems with any accounts that have weak passwords. E.g., an attacker may use a name dictionary to pick names to use as the userid. Let's say the first name in the name dictionary is Aaron. The attacker might then use a word dictionary to try every word in the English language, or some other language, as a possible password for an account with the userid of aaron. If an aaron account doesn't exist on the system or has a strong password, once the attacker has gone through every word in the word dictionary or whatever other password list he is using, he will then go onto the next name in his name dictionary, e.g., perhaps Abe. The attacker will proceed in this manner until he finds an account with a weak password he can compromise or exhausts all possible combinations of names for accounts and words to use for possible passwords. Of course it would take a human an inordinate amount of time to type all such possible userid and password combinations, but an attacker will let a program make such guesses for him. He merely needs to start the program and let it run. His program may be able to check many thousands of userid and password combinations in minutes.
If the system isn't monitored for such brute-force password attempts, an attacker can run unchecked for days. Even if he can't get in, he will be using bandwidth to/from the system under attack as well as CPU cycles, etc., so may slow down access to the system for legitimate users. I've seen periods where a system has been under attack from 5 such attackers in different countries at once.
On CentOS Linux,
you can check the /var/log/secure log to find instances of
such attacks.
# grep 'Failed password' /var/log/secure | tail -5 Oct 28 09:47:43 frostdragon sshd[32246]: Failed password for root from 123.125.219.130 port 11859 ssh2 Oct 28 09:47:47 frostdragon sshd[32249]: Failed password for root from 123.125.219.130 port 13894 ssh2 Oct 28 09:47:52 frostdragon sshd[32253]: Failed password for root from 123.125.219.130 port 15886 ssh2 Oct 28 09:47:56 frostdragon sshd[32256]: Failed password for root from 123.125.219.130 port 17740 ssh2 Oct 28 09:48:01 frostdragon sshd[32259]: Failed password for root from 123.125.219.130 port 19477 ssh2
You can see the number of failed ssh login attempts from various login
addresses with the command grep 'Failed password' /var/log/secure | grep
sshd | awk '{print $11}' | sort | uniq -c - the IP address from which
the failed login attempt was made is the 11th item on the line.
If you pipe the output of the awk command into sort, you can sort the
output by IP address; uniq -c will then provide you the count
of failed SSH login attempts from particular IP addresses.
# grep 'Failed password' /var/log/secure | grep sshd | awk '{print $11}' | sort | uniq -c
1 101.227.71.40
409 117.27.158.71
2 117.27.158.91
84 122.225.109.104
315 122.225.109.108
232 122.225.109.118
321 122.225.109.197
247 122.225.109.212
115 122.225.109.217
458 122.225.97.103
309 122.225.97.108
96 122.225.97.110
377 122.225.97.117
478 122.225.97.120
121 122.225.97.83
63 122.225.97.84
81 122.225.97.88
36 122.225.97.98
382 123.125.219.130I can see from the above output from that command that there were
382 failed ssh login attempts from the 123.125.219.130 address
at the time I ran the command.
From a search on that IP address at the American Registry for Internet Numbers (ARIN), I found the address was part of a block of addresses managed by the Asia Pacific Network Information Centre (APNIC) . A whois search on the APNIC site showed the IP address is part of a large block of addresses, 123.112.0.0 - 123.127.255.255, allocated to an organization in Beijing, China. I often see attacks from IP addresses allocated to entities in China.
You can manually block further attempts to compromise a system in this
manner using a route
reject command or through the firewall software
on the system. The default firewall software for CentOS 7 is
FirewallD.
You can configure it through a
Graphical User
Interface (GUI), which can be opened using the command
firewall-config or through a command line interface at a shell
prompt by using the command firewall-cmd. I blocked the IP
address from any access to the system using the command below, though by
the time I blocked it, the login attempts had ceased:
# firewall-cmd --add-rich-rule="rule family='ipv4' source address='123.125.219.130' reject" success
The block can be viewed through the graphical interface for FirewallD
by running firewall-config. E.g., in this case under "Rich
Rules" for the public zone, I can see the blocked IP when starting the
application after issuing the firewall-cmd command.
The command above will put in place a firewall rule that will apply to the default firewall zone, but will only remain until the firewall service is restarted, e.g., with a system reboot. To put in place a permanent block, I could have used the commands below. Instituting a permanent change requires a restart of the firewall service, though.
firewall-cmd --permanent --add-rich-rule="rule family='ipv4' source address='123.125.219.130' reject"
systemctl restart firewalld.serviceTo have a block apply to a specific firewall zone, e.g., the public zone, I could use the commands below.
firewall-cmd --permanent --zone='public' --add-rich-rule="rule family='ipv4' source address='123.125.219.130' reject"
systemctl restart firewalld.serviceThe output of the grep command run against /var/log/secure
displayed above was sorted by IP address; if you, instead, would like
to sort the output by count of failed login attempts you can pipe the
output of the commands above into sort again adding the
-n argument to sort by the number that appears first on
each line.
# grep 'Failed password' /var/log/secure | grep sshd | awk '{print $11}' | sort | uniq -c | sort -n
1 176.222.201.154
1 85.132.71.83
1 91.220.131.33
1 a
1 pi
1 ubnt
2 client
4 ubuntu
4 usuario
27 git
48 122.225.97.117
64 221.228.205.196
71 61.174.51.223
78 admin
129 122.225.97.79
191 122.225.109.198
237 122.225.97.116
268 117.27.158.88
306 113.200.188.55
336 117.27.158.89I can see from the above output that the greatest number of failed
SSH login attempts made on the day I ran the command, which was November 9,
2014, were made from 117.27.158.89. Checking the APNIC site again,
I see that IP address is also assigned to an entity in China.
If you want to reverse the sorting order, so that the largest number
appears first, simply add the -r argument to the last sort command.
# grep 'Failed password' /var/log/secure | grep sshd | awk '{print $11}' | sort | uniq -c | sort -nr
336 117.27.158.89
306 113.200.188.55
268 117.27.158.88
237 122.225.97.116
191 122.225.109.198
129 122.225.97.79
78 admin
71 61.174.51.223
64 221.228.205.196
48 122.225.97.117
27 git
4 usuario
4 ubuntu
2 client
1 ubnt
1 pi
1 a
1 91.220.131.33
1 85.132.71.83
1 176.222.201.154In the above output, some of the failed entries are associated with
userids the attacker attempted to use to login. E.g., for the case of
the usuario one, I can see that the illegitimate login attempts
where that name was used for the userid orginated from the 221.228.205.196
IP address. There is no account on the system with that userid. The IP address
is also assigned to an entity in China.
# grep usuario /var/log/secure Nov 9 10:53:01 localhost sshd[23516]: Invalid user usuario from 221.228.205.196 Nov 9 10:53:01 localhost sshd[23516]: input_userauth_request: invalid user usuario [preauth] Nov 9 10:53:03 localhost sshd[23516]: Failed password for invalid user usuario from 221.228.205.196 port 52710 ssh2 Nov 9 10:53:04 localhost sshd[23568]: Invalid user usuario from 221.228.205.196 Nov 9 10:53:04 localhost sshd[23568]: input_userauth_request: invalid user usuario [preauth] Nov 9 10:53:06 localhost sshd[23568]: Failed password for invalid user usuario from 221.228.205.196 port 53534 ssh2 Nov 9 10:53:07 localhost sshd[23654]: Invalid user usuario from 221.228.205.196 Nov 9 10:53:07 localhost sshd[23654]: input_userauth_request: invalid user usuario [preauth] Nov 9 10:53:10 localhost sshd[23654]: Failed password for invalid user usuario from 221.228.205.196 port 55193 ssh2 Nov 9 10:53:12 localhost sshd[23657]: Invalid user usuario from 221.228.205.196 Nov 9 10:53:12 localhost sshd[23657]: input_userauth_request: invalid user usuario [preauth] Nov 9 10:53:14 localhost sshd[23657]: Failed password for invalid user usuario from 221.228.205.196 port 56072 ssh2
To count just by IP address so that the login failurers for particular
usernames don't appear in the output, I can put another grep
command, one that will filter the output of the prior grep command so any lines of output from it are eliminated if they contain "invalid user", before the
awk command.
# grep 'Failed password' /var/log/secure | grep sshd | grep -v "invalid user" | awk '{print $11}' | sort | uniq -c | sort -n
1 176.222.201.154
1 85.132.71.83
1 91.220.131.33
48 122.225.97.117
64 221.228.205.196
71 61.174.51.223
129 122.225.97.79
191 122.225.109.198
237 122.225.97.116
268 117.27.158.88
306 113.200.188.55
336 117.27.158.89If you wish to see what userids are being used most frequently for the
failed login attempts, the string of commands entered above need to be
modified to search for the userids used in failed login attempts. The above
commands don't show the most commonly used userid, which is
root, since almost all Unix/Linux systems will have a root
account.
For failed login attempts the lines that appear in the output are slightly
different depending upon whether the userid used exists on the system. E.g.,
if the account doesn't exist on the system, as in the case for client
and git below, the lines appear as follows:
Nov 9 10:34:14 localhost sshd[21745]: Failed password for invalid user client f rom 91.220.131.33 port 60223 ssh2 Nov 9 10:52:00 localhost sshd[23204]: Failed password for invalid user git from 221.228.205.196 port 60513 ssh2
If the account does exist, e.g., the root account, then
the lines have the following format:
Nov 9 04:58:50 localhost sshd[21319]: Failed password for root from 122.225.97. 79 port 7951 ssh2
The sed command can be used to strip out the "invalid user"
from lines to make the format of those lines containing "invalid user" the
same as for those for valid userids on the system. You can then use
the awk command to display the contents of the 9th entry on
the line, which is the userid used.
# grep "sshd.*: Failed password for" /var/log/secure | sed 's/invalid user //' | awk '{print $9}' | sort | uniq -c | sort -n
1 a
1 operator
1 pi
1 ubnt
2 client
4 ubuntu
4 usuario
27 git
78 admin
1844 rootThe output from a check of the /var/log/secure file shows
that the most common user name used in attempts to log into the system
by attackers is root.
References:
-
Firewalld - Block an IP Address
By: up2long
Date: February 26, 2014
Fedoraforum.org
