SMTP Relay Security Risks

[saltfinger]

Hi Guys,

We recently had an external penetration test and one of the issues raised was the fact that anyone can telnet into our SMTP gateway and send forged emails from ANY email address to any user in our domain. I have my doubts as to whether this is a legitimate issue so would like to ask the community:

• Is this a security risk?
• Is this correct and/or the default behaviour?
• How can i prevent this?

Thanks and Regards,

Samuel

[Jejerod]

Hi Guys,
one of the issues raised was the fact that anyone can telnet into our SMTP gateway and send forged emails from ANY email address to any user in our domain.

I hope this means anyone can telnet into your SMTP gateway on port 25 to deliver mail to your domain (not any domain). Which is exactly what your MTA/MX should do, if your company wants to be able to get mail from the rest of the world. Which is no security risk and correct behavior.

If we are talking Mail Transfer Agent on Check Point Gateway, however, things are different.

By default enabling MTA on Check Point will make the Gateway accessible from any IP to gateway with service smtp if implied rules are enabled. Starting with R80.20 you can opt out of this in the MTA settings.

Furthermore, the postfix on a Check Point Gateway will accept mail from anyone and to anyone, acting as an open relay.

I recommend disabling the implied rule for this and using explicit rules in the access policy for SMTP. Note that disabling the implied rule is global, so each firewall where SMTP traffic passes to the gateway needs an explicit rule.

[saltfinger]

I hope this means anyone can telnet into your SMTP gateway on port 25 to deliver mail to your domain (not any domain). Which is exactly what your MTA/MX should do, if your company wants to be able to get mail from the rest of the world. Which is no security risk and correct behavior.

Surely there IS a security risk here becasue a malicious user could send a phishing email to an employee in my company pretending to be another employee?

[Jejerod]

Surely there IS a security risk here becasue a malicious user could send a phishing email to an employee in my company pretending to be another employee?

This is true. You should have some security on your MTAs like SPF checking and sending from your own domain only when authenticated. However, that's not a Check Point topic.

You should never use Check Point MTA as your external MTA. Use a fully configured and secured mail server for that and have Check Point MTA in your mail routing if you need it.

[saltfinger]

This is true. You should have some security on your MTAs like SPF checking and sending from your own domain only when authenticated. However, that's not a Check Point topic.

You should never use Check Point MTA as your external MTA. Use a fully configured and secured mail server for that and have Check Point MTA in your mail routing if you need it.

Agreed, do Check Point have any recomended security best practices with regards to SMTP services on their devices?

[mcnallym]

Agreed, do Check Point have any recomended security best practices with regards to SMTP services on their devices?

Never seen any such, it is quite basic although uses Postfix as the MTA that is in the background. The purpose of the MTA on the Check Point is to allow the other Blades to do inspection, ie anti-virus/abot, TE/TX etc. It isn't a fully fledged Mail System and shouldn't be thought of as such.
Being Postfix then you can edit it's config files in the same way, however that is Postfix as opposed to Check Point.

From the ATRG: Mail Transfer Agent (sk109699)

Postfix is an open source mail server that is used by Check Point software to route and deliver e-mails in the MTA implementation.

Postfix is configured using two main configuration files:

Note: Both files are generated on Security Gateway during policy installation by the process in.emaild.mta.

/opt/postfix/etc/postfix/master.cf

This file configures the communication between Postfix processes and Check Point processes, ports, protocols, and so on.
This file should not be changed.

/opt/postfix/etc/postfix/main.cf

Almost everything is configurable in Postfix.
Administrator must be fully aware of implications resulting from manual configuration of Postfix (refer to http://www.postfix.org/postconf.5.html).
Related solution: sk101870 - How to change Postfix configuration for Threat Emulation MTA

So based on that you are free to manipulate the main.cf as you like, however is not down to Check Point, and they are not providing any interface to Postfix. So think of it as Postfix in the same way that Gaia IS Red Hat Enterprise Linux and then modded. You can start making RHEL changes etc but don't expect Check Point to look at those.

Nearest that ever found was this which basically says to list your domains as opposed to leaving the * there so not an open relay.

In the Mail Forwarding section, add one or more rules:

Click on the relevant button on the toolbar

Right-click in the Domain cell - select Edit...

Enter the domain for the SMTP traffic for this rule.
The default setting is to use the wildcard (*) to send all traffic, but it is recommended to add the managed domain name instead of keeping the default *, to prevent the spam traffic.

Click OK.

Click in the Next Hop cell - select the node object that is represents the mail server for this rule.

Most implementations that came across the organisation uses someone LIKE MessageLabs, MimeCast etc as the External MX record and then lock SMTP to just that provider as a Source.

Others have a Full Mail solution in the DMZ that mail delivered too and then is forwarded to the MTA on the Check Point afterwards.

So basically locked down in terms of what can get to it.