Detection of Outbound Server Attacks and Handling Abuse Complaints
This article explains how to detect outbound server attacks in your web hosting environments and how to handle abuse complaints.
If you are a Linux system administrator, a web developer, or work with production environments, you are likely familiar with the three daily challenges we face: "Spam," "Phishing," and "Abuse Complaints." (There are more, but let’s focus on these three).
We have excellent tools to combat Spam, and today’s various malware scanners are even capable of detecting phishing websites. However, when it comes to proactively reading website code and comparing it against signature databases, we are still lacking adequate measures to handle the third challenge: "Abuse Complaints." We typically receive an "Abuse Complaint" after an outbound server attack has occurred. Our only response to the abuse team is to initiate a malware scan on the server to identify potentially infected or compromised accounts. The reality is that these types of attacks cannot be handled in real-time because the attack has already happened in the past.
This situation is particularly frustrating for system administrators because they are forced to hunt for the unknown without any clues about who performed the outbound server attack, when it happened, and which remote computer was targeted. The list of questions keeps growing...
Now that you understand what we are talking about, let’s delve deeper into "Abuse Complaints" and their most common types. Mostly, abuse complaints directed at production or web hosting servers arise when malicious users or scripts attack remote login portals such as CMS admin panels, other web forms, or banking web applications hosted on your server.
The next two rare types of abuse complaints are for outbound FTP and SSH-based attacks. In these complaints, remote FTP/SSH servers are often targeted by malicious scripts or user accounts hosted on your server.
In today’s write-up, we will address these three types of abuse complaints and reduction methods using server firewalls. If you think that firewalls are only used to block and allow traffic, then something really interesting is coming your way ????
Let’s outsmart the bad guys!
Server Requirements
- cPanel running on the server: Config Server Firewall (CSF) should be installed and operational.
- Iptables: Installed and running by default.
- Root access to the server: All commands in this article should be executed as the root user.
- Intermediate Linux system administration skills.
Once you ensure that all the above requirements are met, you can proceed with the following steps. I will provide detailed instructions for all the commands we will run on the server, so you won’t have to worry about anything going wrong. Just make sure to follow my instructions correctly. ???? However, if you do not possess the necessary skills, I recommend not attempting to run any of the commands listed below. If you still wish to proceed, do so at your own risk!
Step 1: Creating the “csfpost.sh” File
First, we will create the “csfpost.sh” file, which is a hidden feature provided by Config Server Firewall (CSF). This script executes all the commands specified in the “/etc/csf/csfpost.sh” file after loading the firewall rules.
If a “/etc/csf/csfpost.sh” file already exists on your server, add the following lines after the last line of the file. If not, create the file:
The following command will create the “/etc/csf/csfpost.sh” file:
Add the following code to the “/etc/csf/csfpost.sh” file:
Here, “<Server_Main_IP_Address>” is your server’s primary IP address. You can find it using the “hostname -i” command or obtain it from your data center if you are using a NAT network. Essentially, “<Server_Main_IP_Address>” is your server’s public IP address.
For example, if your server’s public IP address is “11.22.33.44”, your “/etc/csf/csfpost.sh” file should look like this:
The above file data includes a set of iptables commands that add rules to detect and log outbound traffic on ports 80 (HTTP), 443 (HTTPS), 21 (FTP), and 22 (SSH). These rules log the traffic along with the UID of the user initiating the connection, excluding connections to your own server.
These rules will not conflict with any existing firewall rules and will not cause any connectivity issues on your server because they only log traffic without performing any blocking or allowing actions.
After adding data to your csfpost.sh file, you need to make it executable using the following command:
The reason we chose "700" permission bits is that we do not want any standard user or group to be able to view the exact rules being loaded by the csfpost.sh file. This is simply a minor security measure.
Next, you need to restart your CSF firewall, and you should see the “csfpost.sh” file mentioned in the last 10 or 15 lines of the firewall restart output. Restart the CSF firewall using the following command:
Once this is done, if there are any outbound requests made from your server, you can find them in the server’s “/var/log/messages” file. Below are the strings you should search for to find specific types of outbound requests:
| String | Description |
|---|---|
| CSF-OUTBOUND:80:443:=: | Searching for this string in /var/log/messages will list all outbound requests to remote web servers on ports 80 and 443, including the exact time, UID, and remote server IP. |
| CSF-OUTBOUND:21:=: | Searching for this string in /var/log/messages will list all outbound requests to remote FTP servers on port 21, including the exact time, UID, and remote server IP. |
| CSF-OUTBOUND:22:=: | Searching for this string in /var/log/messages will list all outbound requests to remote SSH servers on port 22, including the exact time, UID, and remote server IP. |
These logs are incredibly helpful on their own and will be invaluable when you receive abuse complaints. All you need to do is look at the abuse complaint report, find the IP address of the remote server that was attacked, and search for this IP address in your server’s /var/log/messages file. That’s it! You have the full logs of the attack, including the user’s UID, which you can use to find the user’s name from the /etc/passwd file and take necessary actions.
You can even use these logs to provide evidence of the actions or accounts that led to an abuse complaint against your server.
Conclusion and Next Steps
With this method, you can detect outbound server attacks and identify the perpetrators. However, these attacks are detected retrospectively; for real-time handling, more advanced solutions like SIEM (Security Information and Event Management) software can be used. These tools can monitor attacks in real-time and provide you with updates on outbound attacks from your server.
To streamline the investigation process for our busy administrators, we have developed a simple bash script that performs all basic investigations, processes the data, and presents a neat summary of outbound attacks on your server in a small output window. Our Linux server security plan includes this script, and our team can install a customized version for you upon request.
