Use SHELL scripts to defend against SSH and vsftpd brute force cracking (version ②)

When I routinely checked/var/log/secure logs on the FTP backup server, I found a lot of authentication information for sshd and vsftpd failures. It is obvious that someone wants to use brute force cracking tools to steal passwords, therefore, you need to write a security script to prevent it.

The script requirements are as follows: This SHELL script is placed in the crontab scheduled task and is defined every six hours according to the actual situation) to read the/var/log/secure script, obtain the malicious IP address. If the number of connections per week is higher than the threshold value, for example, 100, this threshold value can also be defined based on the actual situation ), add it to/etc/hosts. if the value in the deny blacklist is lower than this threshold, the IP address is ignored.

/Var/log/secure: Nov 28 10:18:08 centos2 sshd [7556]: Connection closed by 222.216.30.20.nov 28 10:18:08 centos2 sshd [7557]: pam_unix (sshd: auth ): authentication failure; logname = uid = 0 euid = 0 tty = ssh ruser = rhost = 222.216.30.109 user = rootNov 28 10:18:09 centos2 sshd [7559]: pam_unix (sshd: auth): authentication failure; logname = uid = 0 euid = 0 tty = ssh ruser = rhost = 222.216.30.109 user = rootNov 28 10:18:10 centos2 sshd [7551]: failed password for root from 222.216.30.109 port 2391 ssh2Nov 28 10:18:10 centos2 sshd [7552]: Connection closed by 222.216.30.20.nov 28 10:18:10 centos2 sshd [7553]: failed password for root from 222.216.30.109 port 2397 ssh2Nov 28 10:18:10 centos2 sshd [7554]: Connection closed by 222.216.30.20.nov 28 10:18:11 centos2 sshd [7557]: failed password for root from 222.216.30.109 port 2401 ssh2Nov 28 10:18:11 centos2 sshd [7558]: Connection closed by 222.216.30.20.nov 28 10:18:11 centos2 sshd [7559]: failed password for root from 222.216.30.109 port 2403 ssh2Nov 28 10:18:11 centos2 sshd [7560]: Connection closed by 222.216.30.20.nov 28 10:37:01 centos2 vsftpd: pam_unix (vsftpd: auth): check pass; user unknownNov 28 10:37:01 centos2 vsftpd: pam_unix (vsftpd: auth): authentication failure; logname = uid = 0 euid = 0 tty = ftp ruser = hello rhost = centos1.cn7788. comNov 28 10:37:01 centos2 vsftpd: pam_succeed_if (vsftpd: auth): error retrieving information about user helloNov 28 10:37:19 centos2 vsftpd: pam_unix (vsftpd: auth): check pass; userunknownnov 28 10:37:19 centos2 vsftpd: pam_unix (vsftpd: auth): authentication failure; logname = uid = 0 euid = 0 tty = ftp ruser = yhc rhost = centos1.cn7788. comNov 28 10:37:19 centos2 vsftpd: pam_succeed_if (vsftpd: auth): error retrieving information about user yhcNov 28 10:37:36 centos2 vsftpd: pam_unix (vsftpd: auth): check pass; user unknownNov 28 10:37:36 centos2 vsftpd: pam_unix (vsftpd: auth): authentication failure; logname = uid = 0 euid = 0 tty = ftp ruser = yuhongchun rhost = centos1.cn7788. comNov 28 10:37:36 centos2 vsftpd: pam_succeed_if (vsftpd: auth): error retrieving information about user yuhongchunNov 28 10:42:44 centos2 vsftpd: pam_unix (vsftpd: auth): check pass; user unknownNov 28 10:42:44 centos2 vsftpd: pam_unix (vsftpd: auth): authentication failure; logname = uid = 0 euid = 0 tty = ftp ruser = yuhongchun rhost = 10:42:44 centos2 vsftpd: authorization (vsftpd: auth): error retrieving information about user limit 28 10:42:56 centos2 vsftpd: pam_unix (vsftpd: auth): check pass; user unknownNov 28 10:42:56 centos2 vsftpd: pam_unix (vsftpd: auth): authentication failure; logname = uid = 0 euid = 0 tty = ftp ruser = andrewyu rhost = 114.1120.9.70nov 28 10:42:56 centos2 vsftpd: pam_succeed_if (vsftpd: auth ): error retrieving information about user andrewyu

Observe the polling features of the/var/log/secure file as follows:

ls -lsart secure.*512 -rw------- 1 root root 516379 11-04 01:31 secure.4660 -rw------- 1 root root 668192 11-11 00:05 secure.3304 -rw------- 1 root root 306589 11-17 10:33 secure.2484 -rw------- 1 root root 488620 11-25 02:33 secure.1

Basically, the/var/log/secure file takes the week as the polling cycle, if you have strict security requirements, you can also stick to the principle of "Never let go" to capture the malicious IP of the old secure, and then throw it into/etc/hosts. in the deny file. Next, we will try to capture these malicious IP addresses efficiently. If you refer to the original SHELL script writing method, we will capture the detection vsftpd and sshd in the secure log.

For the IP address of the service, run the following command:

cat /var/log/secure | awk '/Failed/{print $(NF-3)}'| sort| uniq -c| awk '{print $2"="$1;}'

Obviously, the IP address value of vsftpd failure cannot be obtained. The failure information of sshd log is different from that of vsftpd log. I have written several awk mixed sed methods to test the efficiency, I feel that awk script is the fastest. You can write several types of scripts and test them with the time Command. At last, the code is simplified, and the script and script are completed.

The content is as follows:

#!/bin/bashawk '{for(i=1;i<=NF;i++){if($i ~ /rhost/)print substr($i,7)}}' /var/log/secure | sort | uniq    -c>/root/black.txtDEFINE="100"cat     /root/black.txt |    while read LINEdo               NUM=`echo $LINE |awk '{print $1}'`               host=`echo $LINE    |awk '{print $2}'`               if [ $NUM -gt $DEFINE ];               then                grep $host    /etc/hosts.deny > /dev/null                   if [ $? -gt 0 ];                   then                   echo "sshd:$host"     >> /etc/hosts.deny                   echo "vsftpd:$host" >> /etc/hosts.deny                   fi               fidone

After the script runs for a period of time, we can observe some files involved in the script, such as/root/black.txt. The results are as follows:

cat /root/black.txt               2 113.17.144.156               4 114.112.51.208               4 114.112.69.170           169 118-163-227-50.hinet-ip.hinet.net               8 119.188.7.200               8 122.70.130.11            61 124.248.32.246            12 183.203.14.121               3 189.26.255.11            56 199.204.237.60               3 199.30.53.220               5 201.236.80.4               6 220.172.191.31            30 222.216.30.109            60 222.253.159.111            58 223.4.180.23           166 58.221.42.178               1 61.132.4.85           152 61.142.106.34            22 61.167.33.222               7 85.126.166.83           166 www.b-nets.com

The content of the/etc/hosts. deny script is as follows:

sshd:124.248.32.246vsftpd:124.248.32.246sshd:199.204.237.60vsftpd:199.204.237.60sshd:222.253.159.111vsftpd:222.253.159.111sshd:223.4.180.23vsftpd:223.4.180.23sshd:58.221.42.178vsftpd:58.221.42.178sshd:61.142.106.34vsftpd:61.142.106.34sshd:118-163-227-50.hinet-ip.hinet.netvsftpd:118-163-227-50.hinet-ip.hinet.netsshd:www.b-nets.comvsftpd:www.b-nets.com

Finally, we put the shell script into crontab and run it every six hours. The command is as follows:

* */6 * * * root /bin/bash /root/hostsdeny.sh >> /dev/null 2>&1

Because/var/log/secure logs are round-robin every week, you can set the script execution frequency. If you feel that the server is frequently detected, you can set a shorter execution interval. Otherwise, it can be set to be longer. Note: If you only want to prevent SSH Brute force cracking, there is no need to update this script. You can use the original SHELL script, that is, the original version ), this update script is suitable for deployment in the FTP of the public network machine above, the current test is relatively stable, but the feeling is still not perfect place, welcome to communicate with you, fuqin boiled wine (yuhognchun027@163.com ).

This article from the "fuqin liquor" blog, please be sure to keep this source http://andrewyu.blog.51cto.com/1604432/1074650