Fix : pam_unix(sushi:auth): authentication failure SSH Flood

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 :

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 :

You will get some response like this :

Also, you can use this command :

You will get some response like this :

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 :

Save the rule :

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 :

There will be many IP addresses other than yours’ IP. Normally you will have log like this :

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 :

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 :

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 :

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 :

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 :

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 :

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.

Save the rule :

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.