✎ I'm Sending Spam. How do I Stop it? [ClearOS Documentation]

Edit the page and hit Save. See Formatting Syntax for Wiki syntax. Please edit the page only if you can improve it. If you want to test some things, learn to make your first steps on the playground.

===== 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.

<note tip>The following command will give a very good indication of the compromised user by giving a count of user logins:
  grep sasl_username /var/log/maillog|awk {'print $NF'} |sort |uniq -c |sort -n

A high count is your possible compromised user.</note>
===== 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.

<note warning>The following instructions destroy messages in your mail queue. Use with discretion</note>

To following deletes all deferred messages in the queue

postsuper -d ALL deferred

To following deletes ALL 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 [[http://www.cyberciti.biz/tips/howto-postfix-flush-mail-queue.html|NIX Craft]] or this one from [[https://www.howtoforge.com/delete-mails-to-or-from-a-specific-email-address-from-postfix-mail-queue|HowtoForge]].

===== The future =====
There is a KB document, [[:content:en_us:7_ug_more_antispam_measures|More anti-spam and e-mail defence measures]] which is worth reading. The [[:content:en_us:7_ug_more_antispam_measures#reorganise_how_you_send_mail_from_your_clients|Reorganise how you send mail from your clients]] is especially worthwhile as it allows you to stop any user/pass access on port 25 from the outside which is where the majority of these password breaches happen.
{{keywords>clearos, clearos content, AppName, app_name, kb, howto, xcategory, maintainer_dloper, maintainerreview_x, keywordfix}}

Edit summary

Note: By editing this page you agree to license your content under the following license: CC Attribution-Noncommercial-Share Alike 4.0 International

CLEAROS DOCUMENTATION

Sitemap

Foundation

Company

Partners

Purchase

Contact Us