CPUG: The Check Point User Group

Resources for the Check Point Community, by the Check Point Community.


First, I hope you're all well and staying safe.
Second, I want to give a "heads up" that you should see more activity here shortly, and maybe a few cosmetic changes.
I'll post more details to the "Announcements" forum soon, so be on the lookout. -E

 

Results 1 to 6 of 6

Thread: SMTP Relay Security Risks

  1. #1
    Join Date
    2020-01-15
    Posts
    3
    Rep Power
    0

    Default SMTP Relay Security Risks

    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

  2. #2
    Join Date
    2012-07-19
    Posts
    108
    Rep Power
    9

    Default Re: SMTP Relay Security Risks

    Quote Originally Posted by saltfinger View Post
    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.

  3. #3
    Join Date
    2020-01-15
    Posts
    3
    Rep Power
    0

    Default Re: SMTP Relay Security Risks

    Quote Originally Posted by Jejerod View Post
    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?

  4. #4
    Join Date
    2012-07-19
    Posts
    108
    Rep Power
    9

    Default Re: SMTP Relay Security Risks

    Quote Originally Posted by saltfinger View Post
    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.

  5. #5
    Join Date
    2020-01-15
    Posts
    3
    Rep Power
    0

    Default Re: SMTP Relay Security Risks

    Quote Originally Posted by Jejerod View Post
    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?

  6. #6
    Join Date
    2007-06-04
    Posts
    3,314
    Rep Power
    18

    Default Re: SMTP Relay Security Risks

    Quote Originally Posted by saltfinger View Post
    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.

Similar Threads

  1. Gmail email alias implementation using CheckPoint SMTP Security Server SMTP Resource
    By BAM279 in forum Content Security/Security Servers/CVP/UFP
    Replies: 1
    Last Post: 2014-03-05, 07:09
  2. DHCP Relay Configuration, Dropped - No bootp relay on in interface
    By Neilharrison_253 in forum R75.40 (GAiA)
    Replies: 1
    Last Post: 2013-09-23, 01:45
  3. Replies: 5
    Last Post: 2009-04-02, 18:21
  4. SMTP Security
    By echoking in forum Content Security/Security Servers/CVP/UFP
    Replies: 2
    Last Post: 2007-05-08, 08:50
  5. SMTP Security Server
    By roadrunner in forum Content Security/Security Servers/CVP/UFP
    Replies: 0
    Last Post: 2005-08-13, 16:11

Bookmarks

Posting Permissions

  • You may not post new threads
  • You may not post replies
  • You may not post attachments
  • You may not edit your posts
  •