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

[gwesson]

Wildfire is for detection, the anti-virus signatures are for blocking. When a malware file is uploaded to Wildfire, you get a report that it was a bad file and can take action as mentioned above. Signatures detected as malware by Wildfire will be added to the Anti-Virus subscription that is pulled down at least once a day by your PA Firewall.

So your statement that Wildfire will NEVER block a file is correct in a sense. But files uploaded to Wildfire are quickly added as signatures to the Anti-Virus system and can be pulled in to the firewall. If using 5.0 there is a subscription feature available that pulls down the AV every hour and can include signatures recently uncovered (even within the most recent hour in some cases).

Hope this helps!

Greg

[Tician]

Hello All,

what about feature request to distinguish between tls and non tls SMTP traffic?

Is there something new in decryption of non https encrypted traffic in general?

It might be good reason to open new topic on this issue, but this is huge security gap if consider that almost three years passed since this topic.....