I'm Sending Spam. How do I Stop it?
This document is designed to help system administrators discover the source of spam being relayed through their ClearOS server and more importantly, how to secure your environment so that it doesn't happen again.
Sources
The source of the spam can be a daunting task, but there are some common causes.
Relay from inside
By default, the ClearOS SMTP service will and can relay email from internal sources if configured that way. This setting is located in the SMTP Server module in the 'Trusted Networks' section. The ClearOS server itself is always 'trusted'. Other hosts that are trusted can be 'compromised' in such a way so that a virus on that device can discover your server and send mail through your server. There are two ways in which this is typically discovered by a virus on the infected computer:
- The virus/spammer scanned your internal network and found it.
- The virus/smapper merely looked into your SMTP server settings on your mail client and started to use it.
The best way to stop these spam messages is to locate the workstation involved and clean off the virus. As a temporary injunctive relief, you can close, or limit the trusted networks by removing or tightening the network(s) that are trusted.
Relay from outside
This problem occurs more frequently than the other and represents a more sophisticated but, increasingly, more common attack. This attack exploits the SMTP Authentication method and can come from inside or outside the network. Basically, the spammer knows the username and password for one of your users and is using the SMTP gateway to relay messages. There are three primary ways that an attacker typically gets this access:
- The spammer has a keylogger on one of your workstations and gathered the username/password.
- The spammer is exploiting a weakness in the mail client of your user
- The spammer brute forced the password of one of your users. (Easy to do if your users have weak passwords.)
If the attack is from one of your user's workstations, be sure to clean viruses and trojans the computer. You will also need to change the user's password. If the attack is from a computer outside your network, you will need to isolate the user that is being used and change their password. It would be good to also scan their computer for keyloggers in case that is how the password was acquired.
Finding the bad user
One of the most common ways that a mail system is compromised is when one of your user accounts is compromised. This is rather easy to find and you can look in the Log Viewer app in the Reports section under the maillog or you can look at the situation from command line.
In the search field in the Log viewer type the following:
sasl_username
This will show you the login requests and successes. You can do the following from command line as well:
grep sasl_username /var/log/maillog
From here you can see which usernames are being used to log into your mail server to authenticate and send email. You can use a 'whois' program to find out where the user authentication came from for example, change the IP address of the following and then paste it in your browser (change 123.45.67.89 to the IP in the report):
http://www.iptrace.in/IPv4-IP-Address/123.45.67.89.html
Oftentimes, what happens is that a user's computer is compromised or uses a network with an unsecure connection to external POP3 or IMAP port and hackers are able to see the plain text password. To remedy this situation, do the following:
- Immediately change the user's password.
- Inspect the user's computer for viruses or trojans.
- Inform the blocking blacklist servers that you are no longer relaying.
- Turn off non-encrypted POP and IMAP ports on the outside of your network and use the SSL/TLS enabled versions instead.
- Adjust settings on your user's computers to use the encrypted versions.
grep sasl_username /var/log/maillog|awk {'print $NF'} |sort |uniq -c |sort -n
A high count is your possible compromised user.
Finding the bad computer
A bad computer can either send e-mails via your server or send them directly to the internet.
Sending e-mails via your server
To find out if your server is really under attack as a spam relay, you'll see a lot of emails on your server when you run the following command:
mailq
If this queue is full with lots of recipients, chances are, you are under attack. You can analyze the following log either in the Log Viewer app or at command line:
/var/log/maillog
This log should show you where the mails are coming from. If the source IP address is off network, it is either a remote user in the field or a completely foreign computer. You should see the username that is authenticating if you are using “SMTP Authentication.”
Sending e-mails directly
If you find nothing from the above, it is likely a PC is sending e-mails directly. To find the PC, add the following custom firewall rule:
$IPTABLES -I FORWARD -m state --state NEW -p tcp --dport 25 -j LOG
You can then watch your messages log for messages with DPT=25 in them. A lot of traffic from one device indicates a problem.
You can check your logs with the following:
grep kernel.*DPT=25 /var/log/messages | awk '{print $9}' | grep SRC | sort | uniq -c | sort -nr
This will log every attempt to send an e-mail directly. There may be normal traffic if you allow BYOD to connect to your LAN but the counts should be small.
Stopping the madness
Cleaning all of this out can be difficult to do, or you can take the shotgun approach. Any emails in your queue that are still trying to send can be purged from the queue.
Sent spam that is deflected will still end up in your queue. You can get rid of all the deferred messages or get rid of all of them altogether. But realize, this is indiscriminate and will remove legitimate deferred or pending messages.
To following deletes all deferred messages in the queue
postsuper -d ALL deferred
To following deletes ALL deferred messages in the queue
postsuper -d ALL
If you want a script to delete messages based on a match of a string (e.g e-mail address), try this solution from NIX Craft or this one from HowtoForge.