Detecting Hackers or Spammers sending email through your system.
Finding the source/cause of a spam
Use the command
to find any account sending a lot of email note down the top 1-2
accounts, next open the web admin to the msg.rec log file page and
search for the problem accounts to confirm if what they are sending
is spam or not, if it's spam change the passwords.
or in web admin use Status
or Mail queue to
examine some messages
to find if there is a bunch of email stuck in the outgoing queue,
spam messages tend to get stuck so this may help you identify some
spam, then search the msg.rec logs again to find the Received log
entry to find why the spam message was recieved.
In some instances, the outgoing message is a bounce or other
internally generated message, in this case you need to find the log
entries just 'before' the message in question to find what caused
it, so search on the time hh:mm: to find the log entries that are
Search RBL databases for your servers ip address
Use one of the many rbl services to find if your system has been
listed, you will need the ip address of your server. If you are
listed, then go to the specific RBL website to see if it will give
you more information, some of them require you register first, read
the relevant RBL listing reasons carefully to understand why you may
have been listed. Then continue your search to identify and
fix the CAUSE before you request delisting!
Reading msg*.rec log entries.
Log entries for an incoming message look like this:
9 21:35:30 Rcpt 184.108.40.206 <firstname.lastname@example.org> <email@example.com> 0 ""
9 21:35:31 Received 220.127.116.11 firstname.lastname@example.org <email@example.com> 120395 <XJkzvvWDQXeUsz7INbIxGQ@ismtpd0003p1lon1.sendgrid.net> "Relay=islocal, nrcpt=1, f="Booking.com" <firstname.lastname@example.org>, s=[Chris - Whakapapa Village and Adelaide! There's a deal with your name on it!]"
9 21:35:32 Aspam 18.104.22.168 email@example.com <firstname.lastname@example.org> 120395 <XJkzvvWDQXeUsz7INbIxGQ@ismtpd0003p1lon1.sendgrid.net> "notrust *****: 5.8 sd=5.8 l=0.00 nok=2/0 m=2 nf=0 Close 0.05(X-SpamContent:clean) 0.95(X-myrbl:Color=brown) 0.91(isclickimage2) 0.82(isclickimage1) 0.20(X-Phrase:clean) 0.37(dkimok) 0.37(genuine) 0.60(spfpass) 0.46(X-NotAscii:utf) 0.53(X-LangGuess:English) 0.49(X-Verify-Helo:+OK) SanScore 0.0 5.8 Sval 5.8"
9 21:35:32.00  Spam 22.214.171.124 <email@example.com> <firstname.lastname@example.org> 120395 <XJkzvvWDQXeUsz7INbIxGQ@ismtpd0003p1lon1.sendgrid.net> "[o4.sg.booking.com] SpamDetect"
9 21:35:32.00  Stored 126.96.36.199 <email@example.com> <firstname.lastname@example.org> 120395 <XJkzvvWDQXeUsz7INbIxGQ@ismtpd0003p1lon1.sendgrid.net> "[o4.sg.booking.com] Stored locally /home/surgemail/netwin.co.nz/hc/gf/chrisp/mdir/new/1470796532.2114_15646.netwin.netwinsite.co"
Cpu time used 0 cpu seconds
For an outgoing message it looks like this:
9 21:39:48 Rcpt 188.8.131.52 <email@example.com> <firstname.lastname@example.org> 0 ""
9 21:39:49 Received 184.108.40.206 email@example.com <firstname.lastname@example.org> 566 <email@example.com> "Relayfirstname.lastname@example.org, nrcpt=1, s=[test]"
9 21:39:49 NOSPAM 220.127.116.11 email@example.com <firstname.lastname@example.org> 566 <email@example.com> "trusted origin so skipping spam filtering g_smite_skip_relay"
9 21:39:53.00  Sent 18.104.22.168 <firstname.lastname@example.org> <email@example.com> 566 <firstname.lastname@example.org> "[115-18-8-177.jetstream.xtra.co.nz] Delivered to remote host 22.214.171.124 used SSL - 250 message sent ok "
In both cases the line you want when hunting a hacked account is the 'Received' entry, this shows you why the message was accepted by your server.
- email@example.com (The user gave valid smtp auth credentials, which are listed.)
- g_relay_allow_ip (The sender is from a trusted ip address you have listed)
- islocal (The message is to a local account/domain, or was being forwarded by one)
To find this look for the Relay=... text in the line, e.g. in this example the message is relayed because the sender authenticated correctly as firstname.lastname@example.org
9 21:39:49 Received 126.96.36.199 email@example.com <firstname.lastname@example.org> 566
<email@example.com> "Relayfirstname.lastname@example.org, nrcpt=1, s=[test]"
The number in square brackets lets you find all related log entries, e.g. search on 130766226 in the above example
In some cases you will need to find events just before a log entry, to find what caused the message to be sent, to do this search on the date and time, e.g. "9 21:39:4" in the above example...
Settings to help auto detect spammers.
One or more of your users will have their account hacked and abused
to send spam sooner or later, you can make it much harder, and you
can detect it and stop it early using these settings and policies.
# Login guesses per IP before it is automatically and permenently
locked out. Use tellmail unlock ip.address to fix...
# If hacker attempts to login to one of these then the ip is
instantly locked out. (Don't use accounts that exist)
# Only allow smtp logins if the user has previously logged in via
imap/pop from the same address
# Alert users when logins occur from unknown addresses that are not
from australia or usa...
# Max messages an authenticated user can send per 30 minutes, e.g.
# Max outgoing messages per ipaddress/return path pair, 30 minutes,
# Detect local users sending 'spam like' email and send a report to
# White list for people you know send mail that looks a bit dodgy.
# send manager an email if a local user sends more than 300
message in a day...
# Apply some more strict password checking, and alert users with
Lastly you should run this command to find any accounts with
trivially crackable passwords.
We've built a faster more extensive password checker into nwauth, if you have the latest version of it you can do this:
+OK nwauth 4.3e capa=cluster2
+DATA Info: testing for 999 common passwords, pass 1
+DATA Cracked: email@example.com
+DATA Info: testing for variations on common passwords, pass 2
Settings to stop spoofing of your domains.
The problem with spoofing is that traditional email allowed it and real legitimate systems still make use of that. Also your own users may send email from their own accounts via other systems (gmail etc)... so it's impossible to stop all forgeries unless your users are prepared to 'play the game' and only send email from your servers (or at least a list of known systems), so that's why there is such a lot of settings to do this, each one addresses a subset of forgery behaviour.
# Maybe this next one, but some real emailers will get blocked as they still don't obey spf properly.
Check your have spf entries for your domains. https://netwinsite.com/spf.htm#define
# Optional settings depending on your tolerance for bouncing real messages.
g_from_exact "true" # Bounce if the from doesn't match the authenticated sender, stops your users pretending to be each other.
g_from_noforgeme "true" # checks for the special case of 'from=to' and blocks it if it originates from outside your system.
g_from_check "true" # enables some checking of the from address.
g_from_nofriend "true" # prevent friend matches for apparently forged return addresses. So they don't bypass spam handling.
# And one of these
g_from_bounce "true" # Bounce messages that are probably forgeries.
g_from_stamp "true" # stamp forgeries in the spam headers but don't actually stop them.
An extreme setting you may use:
SECURITY_SUFFIX - Make logins fail unless the user knows
One other method to protect your server is to make the login
username different from the email address. You can do this on
a per domain level, lets say you have a domain MYDOMAIN.COM and you
want the users to login with username=JOHN@SECRET.MYDOMAIN.COM
note: I don't recommend using the security suffix on most
systems, it is the most complex of the settings and the most
likely to cause disruption, it does have benefits but I would only
use it for small sites where extreme security measures are