Handle outgoing broadcast packets when CentOS servers are attacked

This is the case: a linux server hosted in a certain place suddenly received a phone call from the data center saying that our machine had paralyzed the entire IDC network. External machines cannot access the IDC. After hanging up the phone: I began to think about how the computer room hosting the machine had a hard defense mechanism and how could one of my own machines have such a big impact. Therefore, I contacted the hardware defense manufacturers of the IDC room to inquire about the situation. The final answer was that the server I hosted sent a broadcast message to the outside, so that the hardware protection Sessions of the IDC were full and other devices were covered.

This is the case: a linux server hosted in a certain place suddenly received a phone call from the data center saying that our machine had paralyzed the entire IDC network. External machines cannot access the IDC.

After hanging up the phone: I began to think about how the computer room hosting the machine had a hard defense mechanism and how could one of my own machines have such a big impact. Therefore, I contacted the hardware defense manufacturers of the IDC room to inquire about the situation. The final answer I got was that the hosted server sent a broadcast message to the outside, so that the Hardware Defense Sessions of the IDC were full, no sessions are available for other devices. Processing: After understanding the situation, my first response is to go to remote ssh for a look. As a result, after connect, the password was changed and cannot be accessed. At that time, I felt like I was trying to hit the wall. After I calmed down, I remembered that the machine had a Super User reserved at that time, so I tried again from the Internet and found that the Internet interface was no longer accessible to this machine. What should I do? Suddenly, when the machine was configured with the Intranet, it would be too late to log in from the Intranet machine ssh, and finally the command prompt appeared. Solution: first, view the last command in "1". Recently, I logged on to the user and found that there were more than n unknown ip addresses logged on. Several ip addresses found in Russia and in the United States were captured. So far, I am sure it is a trojan of a foreign guy. 2. View ps-ln to view the current running process. It doesn't matter if you find that more than n wget programs can be downloaded remotely. That's cool. 3 without saying anything, discard the kill thread number first. 4. view the network port, netstat-atunlp 5. Check the Network Package and find several programs with jpg suffixes going out. Packet sending. The root cause is. kill "6" rm jpg to delete the executable. 7 again, monitoring found that the Internet can be accessed normally. After "8" was accessed normally, I was wondering how they attacked me. I did not find any trace after two days of analysis. Log does not record "9". In the end, it can only block the firewall more closely and Block inbound and outbound routes. Leave only the necessary 5060 (telephone Softswitch), 369 ssh Login, and so on "10" for a week without a large number of broadcast packets. According to this fault analysis, port 1.80 may be attacked in the following situations. 2. The password setting is too simple and may be cracked. 3. the ssh remote login port has been used to optimize and adjust these faults. ssh does not need to block ports 22, 80 by default, and the password is high. This fault is now terminated.