Normal Cloud Server, VPS etc does not face so much problem than a dedicated server or a colocation server. The possible reason is chance of success is more to get a server down in case of dedicated server or a colocation server. That pam_unix(sushi:auth): authentication failure SSH Flood is result of huge amount of continuous brute force attack on port. Here is How to Quickly Fix pam_unix(sushi:auth): authentication failure SSH Flood to Terminate Attack.We are mainly describing ready to run commands for is for Debian, Ubuntu. Find suitable of each command or location of file for other GNU/Linux distro from official documentation.
pam_unix(sushi:auth): authentication failure SSH Flood : Do You Have Basic Security of Server?
First open 2 SSH session window and stop SSH service :
1 | service sshd stop |
Locate where is your server operating system’s authentication log file is located. It is /var/log/auth.log for Ubuntu. To list the unique IP addresses with number of times they appeared, run this command on the file after making the path of log correct :
---
1 | grep "Failed password for" /var/log/auth.log | grep -Po "[0-9]+\.[0-9]+\.[0-9]+\.[0-9]+" | sort | uniq -c |
You will get some response like this :
1 2 3 | 1 167.114.0.192 3 200.63.166.32 6 218.50.4.180 |
Also, you can use this command :
1 | cat /var/log/auth.log* | grep 'Failed password' | grep sshd | awk '{print $1,$2}' | sort -k 1,1M -k 2n | uniq -c |
You will get some response like this :
1 2 3 4 5 6 7 8 | 857 Aug 14 175 Aug 15 4696 Aug 16 318 Aug 17 1971 Aug 18 1965 Aug 19 2866 Aug 20 ... |
Idiots slowly increased the attack on our servers. That is the log talking about. On Aug 15, Aug 17 we made rules tight. Then on Aug 16, we allowed all.
You definitely running iptables firewall even you do not know anything. Run this format of command after correcting the IP addresses :
1 2 3 | iptables -A INPUT -s 218.50.4.180 -j DROP iptables -A INPUT -s 167.114.0.192 -j DROP iptables -A INPUT -s 167.114.0.192 -j DROP |
Save the rule :
1 | iptables-save > /etc/iptables/rules.v4 |
You will be interested in the most recent login attempts. You can see by running the command “lastlog”. The log file is at /var/log/lastlog. Running this command will do the job of checking :
1 | lastlog |
There will be many IP addresses other than yours’ IP. Normally you will have log like this :
1 2 3 4 5 6 7 8 | Username Port From Latest myusername pts/0 my.ip.add.dress Sun Sep 11 18:03:49 -0500 2016 daemon **Never logged in** ... man **Never logged in** ... www-data **Never logged in** ... |
Those usernames are related to installed and running services, normally their login is not enabled. If www-data logged in to system, then your system is already penetrated. It is better to take it offline in such case and perform vigorous checking and repair (which can not be covered within this small quick guide), at minimum ask on StackExchange. In normal cases, except you, there will be no record of login.
In such case we say “brute force attempt”. Your condition is not yet bad. There are servers which none ever even do SSH to get that flood. It is not abnormal to fully loss control to take any backup from such server. Now run :
1 | last |
The above command will show up many IP addresses for sure. last reads from a log file, usually at /var/log/wtmp and prints the entries of successful login attempts made by the users in the past. You may get some similar IP addresses like :
1 2 3 | 223.191.41.59 223.191.38.149 223.191.44.219 |
In such case, you have to block the whole subnet with the same iptables -A INPUT -s .... DROP style command. These IP are usually from China, Korea, India. In addition to /var/log/lastlog, /var/log/wtmp; there are 3 files in /var/run and /var/log: utmp, wtmp and btmp, which hold info about current logins and additional info, historical and failed logins. You can check them slowly later. You should check cron :
1 | crontab -l | grep -v '^#' |
The above should have entries made by you. Odd entries should be web searched to exclude man in the middle attack (MITMA). Those IP like 223.191.44.219 are probably victims of MITMA — servers has became hackers property with huge effort. You also can be on that list. If you run this command :
1 | last | grep root | grep -v tty | awk '{print $3}' |
You will see that attacks are more with root username.
pam_unix(sushi:auth): authentication failure SSH Flood : Stop Using root User to SSH
Never change the default port of SSH. Many on internet will suggest you so. It just can complicate and end up security scanners flagging your login attempt as suspicious or simply you can never SSH inside. It is just not usable.
Basically IPTables alone can give enough power to fight with brute force ssh attacks. But first we need to get rid of root to login. Easy commands to create a user who can SSH, we are using an easy name thecustomizewindows, do not use such easy to guess username :
1 2 3 4 5 6 7 8 9 10 11 12 13 14 | adduser thecustomizewindows # complete the steps usermod -aG sudo thecustomizewindows # test su - thecustomizewindows # test cd /root nano /etc/ssh/sshd_config # do this change PermitRootLogin no # add this line AllowUsers thecustomizewindows # save the file, start SSH. We stopped it service sshd start |
Do not reboot now. Keep one shell SSH session active. From another screen, ssh as root user name which the command format of ssh roots@my.ip.add.ress. Your server will deny right password. That is what we wanted. Now use custom user name which the command format of ssh thecustomizewindows@my.ip.add.ress. Your server will accept right password for the user. Then run su root, use root’s password. So, even if someone know your password, can not easily login.
I do not know your IPTable rules, but we will say eth0.103. What is that 103? Open /etc/network/interfaces. You will see that :
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 | auto lo iface lo inet loopback .. auto eth0 ... auto eth0.101 ... ... auto eth0.102 face eth0.102 inet static .... auto eth0.103 iface eth0.103 inet static address 15.160.170.180 netmask 255.255.255.0 |
We are talking about that interface. The first rule tells that the TCP packets which will to come in and attempt to establish an SSH connection mark them as SSH, only give attention to the source of the packet. The second rule saying that if a packet attempting to establish an SSH connection comes, and it’s the fourth packet to come from the same source within thirty seconds, just reject it. The third and fourth rules mean if an SSH connection packet comes in, and it is the third attempt from the same IP within thirty seconds, log it, then reject it. The fifth rule says just accept the attempts which is not done by the above rule.
You can, indeed make it more tight to 3 and 2 instead of 4 and 3, around 25 seconds instead of 30 seconds. We need to log the attempts — a time and chance have to keep wider open.
1 2 3 4 5 | sudo iptables -A INPUT -i eth0.103 -p tcp -m tcp --dport 22 -m state --state NEW -m recent --set --name SSH --rsource sudo iptables -A INPUT -i eth0.103 -p tcp -m tcp --dport 22 -m recent --rcheck --seconds 30 --hitcount 4 --rttl --name SSH --rsource -j REJECT --reject-with tcp-reset sudo iptables -A INPUT -i eth0.103 -p tcp -m tcp --dport 22 -m recent --rcheck --seconds 30 --hitcount 3 --rttl --name SSH --rsource -j LOG --log-prefix "SSH brute force " sudo iptables -A INPUT -i eth0.103 -p tcp -m tcp --dport 22 -m recent --update --seconds 30 --hitcount 3 --rttl --name SSH --rsource -j REJECT --reject-with tcp-reset sudo iptables -A INPUT -i eth0.103 -p tcp -m tcp --dport 22 -j ACCEPT |
Save the rule :
1 | iptables-save > /etc/iptables/rules.v4 |
SSH from the other terminal screen. If everything is fine then reboot once, check the problems. You really need to :
Restrict that SSH login only from one IP.
Use Fail2Ban
or use Port Knocking.
Intrusion detection system like psad and/or Rootkit Hunter and/or OSSEC HIDS Security like effective Free Softwares to actively, automatically block. Next important is log monitoring.
You actually understood that we are worser hackers. None of us run the scripts oddly pointing to an innocent’s server. That doing is penetration testing and is a paid service. At the end from The Matrix, it is for you :
(after first meeting with The Merovingian)
Neo: Well, that didn’t go so well.
Morpheus: Are you Certain the Oracle didn’t say anything else?
Neo: Yes.
Trinity: Maybe we did something wrong.
Neo: Or didn’t do something.
Morpheus: No, what happened, happened and couldn’t have happened any other way.
Neo: How do you know?
Morpheus: We are still alive.
