|
COMMAND Symantec Enterprise Firewall SMTP proxy inconsistencies SYSTEMS AFFECTED Symantec Enterprise Firewall (SEF) 6.5.x PROBLEM Martin O\'Neal found following, as published in Corsaire Limited Security Advisory [http://www.corsaire.com]: The aim of this document is to clearly define some issues related to a some SMTP proxy inconsistencies within the Symantec Enterprise Firewall (SEF) environment as provided by Symantec [http://enterprisesecurity.symantec.com/products/products.cfm?ProductID=47&PID=9674250&EID=0] The SEF firewall product uses an application proxy strategy to provide enhanced security features for a variety of common protocols. For the SMTP proxy, part of this additional functionality allows the firewall to restrict the sender / recipient domains and to hide internal infrastructure information from external recipients. However, when the firewall is configured to provide network address translation (NAT) to an SMTP connection (effectively hiding the internal server behind a publicly routable address), this might not always be conducted as desired. -- Analysis -- The SMTP proxy works by analysing the SMTP format and optionally rewriting some of the headers to achieve the desired aim. When an inbound or outbound SMTP connection is NATed to an address other than the one assigned to the physical firewall interface, then the SMTP proxy still uses the physical interface name and address within the SMTP protocol exchange. This has two potential issues: The first issue is that there is now a potential information leak; additional information is contained within the SMTP protocol exchange that could aid an attacker in analysing the firewall configuration. The second issue is that any receiving / sending host that is configured to enforce strict checks on the SMTP protocol exchange, might not accept the connection due to the inconsistencies in the fields. -- Proof of concept -- To reproduce this issue, place an SMTP host on an internal interface of the SEF firewall. Create a rule that allows inbound and outbound traffic to this host, then create an address translation and redirection entry that maps SMTP connections to and from an external address other than the physical interface address. smtp address (internal) 1.1.1.1 (twist.dance.org) firewall address (external physical) 2.2.2.2 (waltz.dance.org) firewall address (external SMTP NAT) 2.2.2.254 (foxtrot.dance.org) firewall name tango firewall domain dance.org redirect 2.2.2.254 -> 1.1.1.1 (for SMTP only) NAT 1.1.1.1 -> any (use 2.2.2.254) NAT any -> 1.1.1.1 (use client address) rule 1.1.1.1 -> any (for SMTP only) rule any -> 1.1.1.1 (for SMTP only) For inbound connections to 2.2.2.254: -> 220 tango.dance.org Generic SMTP handler For outbound connections from 2.2.2.254: <- 220 ... -> HELO waltz.dance.org <- 250 ... talking to foxtrot.dance.org ([2.2.2.254]) SOLUTION Accordingly with Symantec\'s answer, available at http://securityresponse.symantec.com/avcenter/security/Content/2002.02.20.html : Solution ======== Bug will be corrected in near-future release version 8 Workarounds =========== - Configure Symantec Enterprise Firewall to use the same name for the firewall name and the firewall external interface name. - If NAT is not needed, use the SMTP wizard included with Symantec Enterprise Firewall to set up rules and redirects for all inbound and outbound SMTP traffic.