Having issues with firewall dropping mail as spam

[Eric_Lindsey1]

We have R80.10 and we do not have anti-spam turned on.  We are having issues with our firewall preventing mail for some reason.  The Anti-Bot blade is picking up the mail traffic.  The description is Malicious MAil activity and email control says Anti Maleware.   The email itself does not have antyhing in it but a few words.  I can have the email sent to my outside email account. Then I forward the same email inbound and it passes our firewall.  The only thing I noticed it that there is a proxied source IP in the log.  I am not sure how or why the firewall is preventing this email.  Has anyone seen this before?  Its happening to numerous different domain names.  a few of them are office 365 users.

[Chris_Atkinson]

Hi

Have you reviewed solutions such as sk111560?

I would also suggest validating the  configuration further with TAC.

Thanks

Chris

[TP_Master]

Hi Eric,
The "Malicious Mail Activity" is an Anti-Bot protection that looks for outgoing spam from your network. You can add an exception or disable it completely if you feel that in your specific network it does not help identify infected endpoints.

[Dale_Lobb]

Hi Eric,

  We have had a case open with TAC on this issue for a few months now.  The Proxied IP is just the first originating MTA that CheckPoint harvests from the headers of the e-mail.  If the IP has a valid reverse DNS entry, then SmartLog will show that instead of the raw IP.

  In our case, the Anti-Bot protections is being applied in inbound e-mail from our external border MTA.  And the e-ails are not just short e-mails but have all sorts of content, but mostly look like commercial email, but not so low as to stoop to the level of spam.

  Our border MTA is an anti-spam security engine that sanitizes e-mail by sender reputation and content before it hits the CheckPoint MTA for further analysis.  TAC only recently identified the Anti-Bot blade and anti-spam activity as the culprit module and is now trying to determine why the e-mails are being dropped. 

[Eric_Lindsey1]

That the same issue we are having.  We have upstream spam filtering before the email hits our checkpoint MTA.  We are not sure why checkpoint is flagging the email as spam. We also have a case open with Checkpoint.  Did you come up with a work around?  Someone mentioned a protection that can be disabled but I was not sure which protection they were referring to.  

[Dale_Lobb]

BTW: We are running R80.20 and the problem showed up right after our upgrade from R77.30 to R80.20.

[Dale_Lobb]

I also read the post from TP_Master with interest: How does one write an exception for the Anti-bot blade?  We are not interested in disabling Anti-Bot completely, as we think has a decent value add for situations other than inbound e-mail. 

We have come up with two procedures:

1) If the upstream MTA performs TCP pipelining (delivers multiple e-mails on one TCP connection,) turn it off, if possible.  This was a huge problem in our environment, because any e-mail queued up behind a disputed e-mail was prevented from delivery when CheckPoint dropped the connection.  By turning off pipelining, at the least the undisputed e-mail will get delivered.

2) A couple of times a day, we uncheck the Anti-Bot blade on our gateway cluster (disable Anti-Bot), push the policy and then goose the border MTA to get it to deliver everything.  As soon as the delivery queues have drained, we re-enable the Anti-Bot blade and re-push the policy. 

Procedure 2 is pretty much a pain, but it keeps the mail flowing and mostly, users do not notice if delivery is delayed a few hours, especially since disabling pipelining enabled 99% of e-mail to make it through unimpeded.

[Chris_Atkinson]

Hi,

Are you certain the gateways topology is configured correctly i.e. External & DMZ interfaces etc? 

Further to looking at exceptions (refer TP admin guide) how is the Threat Prevention profile currently configured in terms of "protected scope"...

Regards,

Chris

[Eric_Lindsey1]

The topology looks fine.  We were running on 77.30 but we recently upgraded to 80.10 and that is when the problems started.  WE have our gateway cluster object as the protected scope in the  Threat Prevention policy.

[Dale_Lobb]

  Last night, CheckPoint TAC handed me a temporary work-around.  The temporary fix is a global exemption rule written in the Threat Prevention policy limiting the Anti-Bot blade to detect only mode when dealing with e-mail sent from the border MTA to the CheckPoint MTA. 

  My TAC engineer said that the issue stems from the CheckPoint MTA seeing enough e-mail from the border MTA that it would classify as possibly malicious that the Anti-Bot blade then classifies the border MTA as BOT infected and interrupts the communication pathway.,  The new exemption rule prevents this behavior.  If you want to reference my case when talking to your TAC engineer, my case number is: 6-0001665562.

  The attached picture (click to enlarge) shows the rule.  ProofPointAgnt and ProofPointAgnt2 are my border MTAs (which actually happen to live in a firewall DMZ,) and Musketeers is my CheckPoint firewall cluster.  The exemption affects only e-mail bound from ProofPoint to the CheckPoint MTA.  All other Anti-Bot functionality is still turned on and functioning.

  I implemented the exemption rule last night, and it appears to work as intended: email is flowing between the two system without delays.

  BTW: CheckPoint TAC considers this to be a temporary work around.  They still want to get to the bottom of why the CheckPoint Threat Prevention system disagrees so drastically with our ProofPoint border MTA on what constitutes possibly malicious e-mail.

[Eric_Lindsey1]

Thank you for the reply and reference to the TAC case.  We came up with another solution as well.  The servers that were have issues sending us mail were all cloud hosted email servers.  It turns out they server IP addresses were in a malicious IP list feed out on the internet.  Our firewall was picking up the IP addresses as malicious and then dropping the email.  Since our firewall is just an mta and we are not doing spam filtering we were able to turn off this protection.  Under Threat Tools > Protections we set the Mail Activity protection to Inactive.  This left all other Anti-Bot threats running.  This worked for us pretty quickly.