TLS secured SMTP inbound inspection?

[Dpeters1]

Hi,

I've recently had a client who's PAN appliance failed to pick up a Zero-Day piece of malware that found it's way into their network via email.

We have wildfire configured correctly and it transpires they are using opportunistic TLS on their mail relay, the spammer had send the infected attachement using TLS so the Palo Alto had no hope of actually seeing the content.

Oddly the application appears as SMTP rather than TLS, i'm guessing because the first couple of packeta would have a clear text EHLO amongst other items, identifying the App as SMTP, TLS happens a little later in the SMTP session.

So, I tried an inbound SSL inspection rule, which would work for TLSv1 (most commonly used for SMTP relays), but no luck, the PAN never notices the existence of the TLS in the session so doesnt try to decrypt.

Am I missing something or is this not possible right now?

It'll be a real shame if it's not as it's a gaping hole for APTs/Malware to creep through. Of course the first thing I did in this instance was to advise the client that they block all .EXE's via their SPAM filter, but would have been nice to catch it at the Palo...

Thanks for reading!

Dave

[Dpeters1]

Also, just spotted this

Re: TLS

Which would suggest that I'm on the right lines about PAN not seeing any difference between SMTP and TLS encrypted SMTP.

That's an old one from 2010 too, so if there's not an APP signature now and a way to inspect the traffic maybe it's not possible?

Thanks

[mikand · Accepted solution]

I guess your best option is to file this as a feature request.

I agree with you that it will be a gaping hole in case you already do a full ssl termination for browsertraffic but then is blind for whatever junk arrives through smtp.

As a sidenote, apart from .exe's you should also block .scr, .com, .bat and .vbs (and probably a few others I might have forgot).

As a workaround you can configure your mailserver in DMZ to accept inbound TLS but when forwarding to internal systems it should use cleartext. This way you can apply a filter in your PA to make it look at the traffic DMZ-MAIL -> Internal-MAIL

Edit: .pif and .lnk might be good to block aswell...

[Dpeters1]

Thanks for the feedback! Good idea with clear-text between the DMZ relay host/spam filter and the internal mail server. I'll make sure that happens.

Will have a chat with our SE from PAN and see if it can be added as a feature, I've a sneaking suspicion it may not be possible though, will have to see what magic the PAN developers can work!

Regarding the sidenote, we're forwarding PE (Pocket Executable) to wildfire, I was under the impression this encompassed all executable content, EXE/COM/ETC under 10MB in size. Am I right or have I misunderstood the classification?

Thanks

Dave

[ericgearhart]

+1 on the "clear text between a DMZ inbound and outbound mail relay and an internal SMTP server" idea - that's what we're doing and this enables visibility into mail coming in or out