Saturday morning SOC

I run my own mail server, for various reasons outside the scope of this article.

Is it “secure”?

The standard (and hated) answer an Infosec professional will give to most questions is:

“It depends”

Most Infosec people

Here’s a trivial table to explain why:

OMG! Teh Russians will hack me! Well… probably not. Let’s look at motivation:

A script kiddie is probably scalp-hunting to impress his/her mates on 4Chan. If rattling the door handle doesn’t work they’ll get bored and try the next door. There are a lot of unlocked doors on the Interwebs, and opening any one of those will make them feel like Neo from The Matrix. My door just has to be unattractively secure compared to the rest of them and they’ll rapidly lose interest in mine.

Conversely, APT28 will have been tasked to mess with a government, an election, a power grid, etc. They are not going to be interested in my little mail server, except maybe as a proxy to help mask their origin. It’s extremely unlikely they’d want to risk burning a valuable zero-day exploit on it.

So why were you sweating this morning?

OK, OK. I had a 2-minute panic but it’s all good. This is what happens when you’re a one-man NOC/SOC (again, I have my reasons). My wife asked me about it and I thought it would be an interesting vignette to capture for the enlightenment and entertainment of all.

Note: this is a very simplistic example of an investigation! A proper SOC would use advanced monitoring and analysis tools and follow a well-designed methodology.

Go on…

I’ve recently installed a newer version of Suricata IPS on my mail server as part of my layered defence model. Once I’d tweaked it to get rid of the noise, I noticed lots of stuff like this in my logs:

[1:2260002:1] SURICATA Applayer Detect protocol only one direction [**] [Classification: Generic Protocol Command Decode] [Priority: 3] {TCP} XXX.XXX.XXX.XXX:25 -> 45.150.206.119:64369

So who is 45.150.206.119 and what are they doing to the SMTP port on my server?

$ whois 45.150.206.119 

route: 45.150.206.0/23
descr: IT LTD rented network
address: Russia, Moscow, Frunzenskay nab, 16k1

OMG! Teh Russians are…

Stop. Breathe. If APT28 was really after my server they wouldn’t be doing it from an IP address so easily associated with Russia (note: whois is not definitive on that point!), and they wouldn’t be so gauche in their methods. Let’s capture some packets and have a closer look…

$ tcpdump -w out.pcap -C 10M -i eth0 host 45.150.206.119

Fire up Wireshark…

That looks like SMTP, which is exactly what you’d expect to see on a mail server. Right-click, follow TCP stream…

Mystery solved. Some spam house is trying to log in to my mail server, probably to use it as a relay for their own nefarious activities. My mail server, brought up to have good manners, starts with a cheery “hello” and tells the Russian server what options it has. The Russian server chooses one for authentication: the ancient CRAM-MD5 which I’ve left in there as a sort of canary (I use TLS, obvs). My server presents the challenge, the Russian server supplies the response, and my mail server replies “WRONG! Off you trot, you nefarious spammer” (I paraphrase).

Upon further investigation there’s loads of that stuff in my Suricata logs from servers in Lithuania, Hong Kong and elsewhere. My conclusion? Just your normal work-a-day spam house door-handle rattling. If I was so inclined I could see which credentials they were trying to use to login using hashcat on the CRAM-MD5 (that’s why I use TLS!). It’s probably something like “admin:admin”.

So I can relax!

Email is now such a simple commodity service that most people (and companies) will use it “as a service” rather than running their own mail servers. Doing so saves them from the stress of regular patching and monitoring. With the benefits of scale, a large provider will also have the resources to see and understand the latest threats and to continually apply the best protective measures.

As for me? I just like a shot of adrenaline with my morning coffee.