SMTP encrypted session bypassed, yet attachments are emulated

[SantiagoPlatero]

Hi community long time no see (dunno why these days can't login to CheckMates), I'm seeing some strange things in the Firewall and Threat Emulation logs, but first some context:

- R80.20 GA Management

- R80.10 Security Gateway, with Threat Emulation blade enabled (emulation occurs in the Check Point Cloud), MTA enabled and imported the SSL certificate of our local antispam to inspect TLS SMTP connections

The incoming email flow for our organization is like this:

- The MX entries for our mail domain has as its highest priority some servers provided by TrendMicro (the service it's called TrendMicro Cloud Pre-Filter), which basically work as a cloud antispam and receive the mails on a TLS session

- Then the cloud MTA forwards the email to our local antispam (also a TrendMicro VM appliance deployed on our DMZ) on a TLS session, which also analyze the incoming mail and then forward it to the Security Gateway (also on a TLS session, and if I'm not wrong it uses the SSL certificate I imported to the Security Gateway)

- The Security Gateway do its thing and forward the mail to the MS Exchange, and the mail arrives then to the client

The strange thing is I have a lot (A LOT) of SMTP traffic bypassed logs (encrypted session) in the Security Gateway, but also I have logs of the attachment of these TLS connection are been emulated, so it appears the Security Gateway can't decrypt the TLS connection, but in the same time it's capable to strip the attachment to upload for emulation?!

The header of some test mail I sent shows the connection between our antispam and the Security Gateway is in fact TLS and then I have a bypass log for the same email session:

X-MTA-CheckPoint: {5BBF4235-0-A00A8C0-129C07B6}
Received: from myantispam (unknown [10.10.0.4]) by Security Gateway
(Postfix) with ESMTPS id ACFF41B0FA6 for <splatero@domain.com.ar>; Thu, 11 Oct 2018 09:29:41 -0300 (ART)

The SMTP bypass log:

Time: 2018-10-11T12:29:42Z
Interface Direction: outbound
Interface Name: eth2
Email Control: SMTP Policy Restrictions
Email Session ID: 5BBF4235-7-A00A8C0-C0000001
Information: Encrypted session
Source: 10.10.0.4#
Source Port: 43182
Destination: 10.10.0.10
Destination Port: 25
IP Protocol: 6
Action: Bypass
Type: Log
Blade: Firewall
Service: TCP/25
Product Family: Access
Interface: eth2
Description: smtp Traffic Bypassed from (10.10.0.4) to 10.10.0.10

The TE log:

Time: 2018-10-11T12:29:46Z
Source: 10.10.0.4
Destination: 192.168.0.10
IP Protocol: 6
Destination Port: 25
Threat Prevention Rule Id:DA846A34-636B-4B7A-A75C-0F72DC130D1E
Scope: 192.168.0.10
File Name: test.pdf
File Type: pdf
File Size: 215615
File MD5: 265c632b5d24d09f1e20d763ab8f3ee4
File SHA1: a6e5d9577005cbb3e2ad013ee71d4baf85a2d299
File Sha256: 361d4f8bc67527b1e9d2231cc340a53a09d7935f4c9af99923f62227bd29ddda
Verdict: Benign
Analyzed On: Check Point Threat Cloud
Determined By: Win7,Office 2013,Adobe 11: static analysis. WinXP,Office 2003/7,Adobe 9: static analysis.
Protection Type: SMTP Emulation

Note: some log fields where deleted o modified to keep confidentiality of the organization.

So, the main question is: I should ignore the SMTP bypassed logs or I'm missing something?

My fear is I could be missing some potentially malicious attachment on incoming SMTP TLS traffic flows.

Thanks mates.

[G_W_Albrecht]

Looks like a topic for TAC !

[KennyManrique]

Can you post an image for this log?

I think this behavior is for outgoing traffic to final Relay Server, since incoming traffic to local MTA is decrypted once the certificate is loaded. However, apparently acording to the log, the source is the first Relay and destination the local MTA (see the difference on interface direction for all logs of this kind).

So it looks like a cosmetic issue because the mail is probably encrypted again to be delivered to the final destination.

Regards.

[SantiagoPlatero]

Hi Kenny, here you have the images

Thanks!

[KennyManrique]

Thanks Santiago,

The first log you posted shows the traffic leaving (outgoing) the interface eth3; I'm not sure about your topology but I think this is the log for traffic destined to the final relay encrypted again as TLS (as I mentioned on the above comment).

Can you filter all logs from rule 77 and verify if there is any on which the traffic direction is incoming? This way we can see when the original mail arrives to local MTA.

Regards.

[SantiagoPlatero]

Thanks to you Kenny. 

The eth3 is one of the externals interfaces (I've enabled the ISP redundancy, but the internet mail flow only goes through the eth3).

And as for rule 77 I've only anti-spam blade related logs (?) which have incoming traffic on the eth3, going from the Trend's Cloud to the public address of my local anti-spam. I only have firewall logs for outgoing traffic for rule 77.

The flow and topology roughly looks like this:

Internet -> Trend Micro Cloud Service -> Local anti-spam (sitting on DMZ -eth2- and statically natted to a public address -eth3-) -> Firewall -> MS Exchange server (only NAT hide behind GW for internet browsing, sitting on same LAN as FW's eth0).

Topology:

eth0: LAN (management and SIC interface), defined as InternalZone

eth1: external interface (doesn't have scope on the internet MTA flow, only used as redundancy for internet browsing), defined as ExternalZone

eth2: DMZ, defined as DMZZone

eth3: external interface (one of the public IP pool is assigned here and one of them is used to sNAT to the local anti-spam), defined as ExternalZone

eth3.2: external interface (other public IP pool, related to the same internet connection but defined as VLAN in Gaia and used by other services), defined as ExternalZone

Hope this helps to clarify, thanks!

[KennyManrique]

Im searching for the logs of one MTA deployment I did.

Once I got it, i will update so you can view the behavior on my scenario.

Regards.

[SantiagoPlatero]

Thanks Kenny, hope you can find it.

[Baasanjargal_Ts]

Hi Kenny,

I am preparing a MTA deployment with TE1000x appliance, So question is: Should we have to do some configuration on local MTA server, ssl domain certificate e.g

Regards,

[Jean-Francois_G]

Did you find a solution to this problem ?  We have the same problem here.  Our MX is redirected to our FW R80.10 Take 163.  When people send us email we see a lot of log like yours 

.

Thanks for your help !

[Baasanjargal_Ts]

HI,

Can you show me your MTA MX record which is redirecting email to Checkpoint Sandblast

Regards,

[Thomas_Werner]

Hi,

Destinations on your two logs are different:

Time: 2018-10-11T12:29:42Z
Interface Direction: outbound
Interface Name: eth2
Email Control: SMTP Policy Restrictions
Email Session ID: 5BBF4235-7-A00A8C0-C0000001
Information: Encrypted session
Source: 10.10.0.4#
Source Port: 43182
Destination: 10.10.0.10
Destination Port: 25
IP Protocol: 6
Action: Bypass
Type: Log
Blade: Firewall
Service: TCP/25
Product Family: Access
Interface: eth2
Description: smtp Traffic Bypassed from (10.10.0.4) to 10.10.0.10

The TE log:

Time: 2018-10-11T12:29:46Z
Source: 10.10.0.4
Destination: 192.168.0.10
IP Protocol: 6
Destination Port: 25
Threat Prevention Rule Id:DA846A34-636B-4B7A-A75C-0F72DC130D1E
Scope: 192.168.0.10
File Name: test.pdf
File Type: pdf
File Size: 215615
File MD5: 265c632b5d24d09f1e20d763ab8f3ee4
File SHA1: a6e5d9577005cbb3e2ad013ee71d4baf85a2d299
File Sha256: 361d4f8bc67527b1e9d2231cc340a53a09d7935f4c9af99923f62227bd29ddda
Verdict: Benign
Analyzed On: Check Point Threat Cloud
Determined By: Win7,Office 2013,Adobe 11: static analysis. WinXP,Office 2003/7,Adobe 9: static analysis. 
Protection Type: SMTP Emulation

Can you explain the two IPs ?

I assume that one log is caused by streaming inspection of the firewall blade which is unable to encrypt TLS mail traffic. 

Regards Thomas

[SantiagoPlatero]

Hi Thomas, thanks for the response. The destinations are the same as it's the firewall interfaces: 10.10.0.10 is the IP of the DMZ interface and 192.168.0.10 is the internal interface one.

Regards!

[Thomas_Werner]

It looks like you are just seeing FW streaming inspection picking up the TLS encrypted streams.

So these logs are normal.  

Regards Thomas

[Baasanjargal_Ts]

Hi Thomas,

I have a quick question,
Do we have to change on production NON-checkpoint customer, (e.g DNS, local MTA except checkpoint TE appliance)