I had a call this morning from a customer who found that he had been put on various blacklists. When he examined his mail log, he could easily see why: his server was sending out thousands of spam emails directly through the Kerio server. That's when he called me for help.
What he had noticed in the log was messages like this:
Those are simply the end result, however, and won't help us find out who or what is sending these. My first suspicion, of course, was a compromised machine, but he had already checked every machine - none were infected.
To find the source, I asked him to log into his Linux mail server. We could find what we need on a Windows server, but it's quicker with Linux (or if you have Cygwin on Windows). I asked him to cd to /opt/kerio/mailserver/store/logs and do this:
grep 501c1268-0001243c mail.log | head -1
On Windows the logs are in Program Files\Kerio\mailserver\store\logs by default unless you have put Store somewhere else - then it could be (for example) D:\keriostore\logs (or whatever you called it).
You can just open the log file with NotePad and search for things that way. Not as quick as Linux or Mac but you can do it.
The "501c1268-0001243c" is the Queue-ID: for one of the messages. The "grep" extracts all lines matching that id and the "head -1" strips out all but the very first, which gives us:
This line tells us that the user responsible for sending this message is "sales".
My customer immediately said: "But sales isn't a real user!"
Well, it has to be. I asked him to look into his configuration and sure enough, "sales" was defined, but only to forward everything to other users. Most likely it was defined a long time ago and because nobody actually ever logged in as "sales", the password was weak - nobody thought about it.
So, this hacker guessed the password and was able to relay spam email. A simple fix was to change the password to something long and obscure. For good measure, he also blocked that ip at the firewall, though I warned him that these spammers don't use their IP's for long, so it could end up owned by someone legitimate later - he should take the block off after a few weeks.
Wrong method for 'sales'
That sales user never should have existed, however. It should have been an alias for a real user or a group delivering to multiple users. It could also be an alias delivering to a public folder, but it should not be a real user.
Why? An alias or group can never be used to authenticate. It has no password - it can receive mail, and you can use it as a "reply-to" address, advertise it on your website and on business cards. but it can never be used to send email - therefore it is inherently more secure. You should consider that when creating accounts like "sales", "service" and the like - there is no reason for them to be real users.
For that matter, there's no need for your own email address to match what you want people to use when sending you mail. If your email is "firstname.lastname@example.org", you could have "bob" be an alias for an address like "b06by" and you'd use THAT for authentication, thereby making your advertised email address ("email@example.com") immune to password guessing. Of course that "b06by" will be visible in email headers, but it does improve security.
Renaming privileged accounts to something less obvious than "administrator" is often slammed as a wasteful, "security by obscurity" defense. However, this simple security strategy works. If the attacker hasn't already made it inside your network or host, there's little reason to believe they'll be able to readily discern the new names for your privileged accounts. If they don't know the names, they can't mount a successful password-guessing campaign against them.