Record solves the problem of outgoing packet sending on the Redhat Server

Recently, it was found that the office network is not smooth, webpage access is slow, and Intranet websites are also slow. After troubleshooting, a server in the RedHat system has an exception. It sends out data packets and closes the server. The network returns to normal. Once enabled, the server logs on to the service due to network problems, run last to view the following suspicious ip58.51.95.75MonMay1420: 59-

Recently, it was found that the office network is not smooth, webpage access is slow, and Intranet websites are also slow. After troubleshooting, a server in the RedHat system has an exception. It sends out data packets and closes the server. The network returns to normal. Once enabled, the network becomes faulty.

Log on to the service and run the last

View User Logon history

There are several suspicious ip addresses

58.51.95.75 Mon May 14-() from Xiangfan Telecom, Hubei Province

124.127.98.230 Sun May 13-() from Beijing Telecom

178.207.18.184 Sun May 13-() from Russia 178.207.18.184 Sun May 13-() from Russia

178.207.18.184 Sat May 12-() from Russia

178.207.18.184 Sat May 12-() from Russia

178.207.18.184 Sat May 12-() from Russia

178.207.18.184 Sat May 12 07:26-07:26 (00:00) from Russia

202.47.160.12 Fri May 11-() from Malaysia

149.20.35.23 Fri May 11-() from Poland

Top check that one of the processes "f" occupies more than 90% of the CPU

View network traffic through iftop and find that port 33334 of the local machine is frantically connected to the ssh of the external ip address. You can judge that this machine has been implanted with an executable file, as a zombie, The Internet address is constantly scanned to see if the ssh service is enabled.

From the last record, we can judge that the passwords scanned and cracked were successfully cracked on the 13th or 14th, and the system encountered problems, one to two days later, the system became a zombie and began to send packets to the Internet on May 17, May 16.

############## Process

# Top

Check that one of the processes "f" occupies more than 90% of the CPU.

View/bin

/Bin/f

This file is not a system-related command. You cannot delete it by checking its hidden attributes.

Lsattr/bin/f

---------- I -------

Run chattr-I/bin/f to modify the File Permission attributes.

The system prompts that chattr cannot run chattr: command not found.

View/usr/bin

Chattr has been deleted. Copy one/usr/bin/chattr from another machine.

Run # chattr-I/bin/f

# Rm/bin/f

Deleted successfully. The network is restored and the traffic is normal.

Every other minute, the system prompts,

Subject: Cron F Opyum Team

The prompt "/bin/f" cannot be executed. The command file has been deleted. You need to check where the command will be called.

Vi/etc/crontab

An attempt is made to delete the *** root f Opyum Team row and save the row. The row cannot be saved, and the File Permission is also changed.

Lsattr/etc/crontab

--------- I ------

Chattr-I/etc/crontab

Delete the *** root f Opyum Team line

Restart the machine

Monitoring for 10 minutes, normal network traffic

Now the problem is solved;

From this accident, we can conclude the following:

The system password must be a complex and strong password with more than 10 characters including letters, numbers, and special characters;
Reject ssh scanning and block IP addresses that attempt to scan and brute-force cracking through technical means;
Modify the default ssh service port without using the default port 22.
Remote Data Backup