How to Increase Email Security With Axigen And Graylog

I’ve been using Axigen Mail Server for well over a year now, both for my own company, as well as for customers.

And I am just as enthusiastic about it as a complete, full-featured mail server, with enhanced email security features, dedicated to ensure secure and stable mail services, as I was in the beginning. 

Still, I do feel that there is one area which, in my opinion, the mail server industry has not yet managed to conquer: log filtering. Enter Graylog.

How I use Axigen’s Graylog integration for enhanced email security

As I see it, right now you’ve got 2 options: you can either set logging to an absolute minimum; which will keep your log files small but will also make it hard to get the information you might need, if push comes to shove.

Or you can set logging to a level you actually need, but then you will end up with a bunch of huge log files and sitting there and „grepping“ your way through them — in the end making it hard to get the information you might actually need.

That’s where Graylog comes in. With its data storage and retrieval architecture, Graylog can filter, split, and index your humongous logs: it can also add certain information, which actually saved my day and my customer a lot of stress.

Finding the Impostor with Axigen and Graylog

I recently used Graylog to find an impostor in a customer’s mailbox. Here’s a short recap of the events.

The Issue

The customer informed me by support ticket that their customers are complaining about receiving phishing emails, which looked like they were sent from my customer (let's call the client C).

Various employees had also received messages from their manager. Some of them had only clicked the link, but one had actually tried to login with her email server credentials.

The emails were actually sent by an attacker, using Sendgrid as their mailhost, with the managers as the sender address.

More emails follow, apparently sent by the CEO, claiming C has a new company bank account and all payments should be going to a bank account in Bulgaria.

I managed to get my hands on some emails to see the source code, but all information I could gather there was already stale — as the attacker had already "left the building". DNS records, mail servers: all gone.

What bothered us the most is that the attacker was actually hijacking already existent email conversations. This told me that the attacker must somehow be able to read the company emails. 

Conclusion: the point of entry could only be C, my initial customer, as none of the other customers involved (complaining) had knowledge of each other.

The Fix

So now I have an idea on how to try and get some insight: Graylog should have the answer, somewhere. Knowing that these customers would never be working outside of Germany, I had to try and filter for successful logins from non-German IP addresses. Since Graylog offers a "Geo-Location Processor", it was easy to filter by the following keywords:

• OP_OK for a successful logon
• IPV4_country_code IS NOT "DE" to filter out successful logins from outside of Germany.

Within seconds, I found addresses in Africa and Northern Europe, successfully logging on to the server with one of the affected customer’s accounts.

After that, it was quite easy: Set a new password for the customer and a ban for the IP addresses involved.

Out of curiosity, I take a look at the customers’ WebMail — the attackers didn't log on that often and not for very long either. How did they manage to hijack these email threads?

The answer was in the WebMail filter settings: the attacker had put in a rule to CC every incoming email to a Yahoo address. Of course, I got rid of that filter too.

How to Improve your Email Security Infrastructure

What I did in the situation above is rather simple: install either syslog-ng or rsyslog (whichever you like best) and have them pump everything into your Graylog appliance.

Then I filtered Axigen logs for "op_ok" and not "ipv4_countrycode":DE. What I found was a foreign IP that had somehow got access to the mailbox. 

Here’s how you can do this yourself. 

Step 1 — Axigen

You’ll need to install an Axigen Mail Server — you can find everything you need on the axigen.com website. Including how to get yourself a full feature 60-day trial.

Step 2 — Graylog

Next, you’ll need to set up a Graylog2 instance, by following their documentation. One small hint though: You can install the Enterprise Version for free, if you register and you are processing less than 5GB a day.

Step 3 — Set up “Syslog” inputs

Now that you have your basics set up, it‘s time to get your Axigen (and other logs) into Graylog.

Graylog offers a multitude of compatible plugins to get your data, but in this case, we're looking for simple, core syslog functionality.

For this to work from the Graylog side, you will need to setup „syslog“ inputs in Graylog:

In the Graylog interface, click on „System“ and then on „Inputs“:

Right at the bottom you will find both the syslog TCP and the syslog UDPinputs. Upon clicking the "Launch new input" button, you can enter the information for this input.

Step 4 — Tell Axigen to send “Syslog” messages

Graylog is now ready to accept incoming syslog messages. Now you need to tell Axigen and / or the underlying OS where to send those.

There are two ways to accomplish this:

1. Axigen will send the logs to Graylog directly
2. Axigen will save the logs locally, your local Syslog instance, be it syslog-ng or rsyslog, will read these files and push (filtered) messages to your Graylog system.

Method 1 will only send the Axigen logs you want to your Graylog instance.

Modify the axigen.cfg file, which you will find under /var/opt/axigen/run/

The variable you will want to change is called logHost and is probably set to 127.0.0.1:2000. For every Axigen service needed, you need to change that to the IP address and port number of your Graylog instance. At this point, make sure you check your firewalls on both sides.

After that, restart your Axigen server: systemctl restart axigen.service should suffice.

Method 2 will keep logging to local files, but for this tutorial syslog-ng will keep an eye on the logs, forwarding (filtered) events to Graylog.

Have a look at your syslog-ng config file, likely under /etc/syslog-ng/syslog-ng.conf. First, we need to tell syslog-ng where to find the interesting stuff.

Add something like this under #Sources:

Remember that you will have to add a source for every log you want to forward. Be careful with wildcards, like *.txt here, as Axigen saves older log files as everything.%date%.txt.

Now that syslog-ng knows about the file to observe, it will need to know where to send the messages to. Put a line like this underneath #Destinations:

All that is left now is to combine the information in the lines we added above:

After saving the changes to your file, do not forget to do a systemctl reload syslog-ng.service to activate the changes.

And that’s it, you’re done!

Now, all your logs will be filtered, split and indexed through Graylog, so you no longer have to worry about any future preventable email security issues like foreign IP intruders. 

Conclusion

Jeroen Keerl ‘s experience with their client is a good real-world story that can serve as a cautionary tale for anyone that doesn’t take mail server security seriously.

However, it’s Jeroen’s solution that impressed us the most — it’s a great demonstration of the versatility built into Axigen & how you can use the Graylog integration to detect impostors and upgrade your email security.
For more advanced email security topics, check out the Axigen resources.