Downloads |
Table Of Contents
ESMTP Support for Cisco IOS Firewall
Prerequisites for ESMTP Support for Cisco IOS Firewall
Information About ESMTP Support for Cisco IOS Firewall
SMTP Firewall and ESMTP Firewall Comparison
How to Configure a Firewall to Support ESMTP
Configuring a Firewall for ESMTP Inspection
Configuration Examples for Firewall ESMTP Support
ESMTP Inspection Configuration: Example
ESMTP Support for Cisco IOS Firewall
The ESMTP Support for Cisco IOS Firewall feature enhances the Cisco IOS Firewall to support Extended Simple Mail Transport Protocol (ESMTP), allowing customers who install mail servers behind Cisco IOS firewalls to install their servers on the basis of ESMTP (instead of Simple Mail Transport Protocol [SMTP]).
Feature History for ESMTP Support for Cisco IOS Firewall
Finding Support Information for Platforms and Cisco IOS Software Images
Use Cisco Feature Navigator to find information about platform support and Cisco IOS software image support. Access Cisco Feature Navigator at http://www.cisco.com/go/fn. You must have an account on Cisco.com. If you do not have an account or have forgotten your username or password, click Cancel at the login dialog box and follow the instructions that appear.
Contents
•
Prerequisites for ESMTP Support for Cisco IOS Firewall
•
•
•
Prerequisites for ESMTP Support for Cisco IOS Firewall
To enable this feature, your Cisco IOS image must contain the Cisco IOS firewall.
Information About ESMTP Support for Cisco IOS Firewall
To configure a Cisco IOS firewall to inspect an ESMTP session and command sequence, you should understand the following concepts:
•
SMTP Functionality Overview
SMTP inspection provides a basic method for exchanging e-mail messages. Figure 1 and the following steps outline a basic SMTP session.
Figure 1 Sample SMTP Exchange Topology
After a user sends an e-mail request to the client (the "SMTP sender"), the client established a TCP channel with the server (the "SMTP receiver"). Thereafter, the client and the server exchange SMTP commands and responses until the mail transaction is complete. The steps of typical SMTP transaction are as follows:
1.
2.
3.
4.
5.
6.
ESMTP Overview
Like SMTP, ESMTP inspection provides a basic method for exchanging e-mail messages. Although an ESMTP session is similar to SMTP, there is one difference—the EHLO command.
After the TCP connection has been established between the client (the ESMTP sender) and the server (the ESMTP receiver), the client sends the EHLO command (instead of the HELO command that is used for SMTP). If the server does not support ESMTP, it sends a failure reply to the client because it did not recognize the EHLO command. If it supports ESMTP, the server responds with the code 250 and a list of extensions that the server supports. (Refer to RFC 1869 for an explanation of the extensions that your server may support.)
The server may send any of the following error codes if it supports ESMTP but is unable to function as normal:
•
•
•
If the client receives any of these error codes, it should issue the HELO command to revert to SMTP mode or issue the QUIT command to end the session.
After the client receives a successful response to the EHLO command, it will work the same way as SMTP, except that the client may issue new extended commands, and it may add a few parameters to the MAIL FROM and REPT TO commands.
SMTP Firewall and ESMTP Firewall Comparison
Although a SMTP firewall and an ESMTP firewall support the same functionality—command inspection, session conversion, and Intrusion Detection System (IDS) detection—slight variations exist between the protocols. Table 1 explains the firewall functionality and protocol-specific differences.
How to Configure a Firewall to Support ESMTP
This section contains the following procedures:
•
Configuring a Firewall for ESMTP Inspection
Use this task to configure a Cisco IOS Firewall to inspect an ESMTP session and command sequence.
Restrictions
SMTP and ESMTP cannot exist simultaneously. If SMTP is already configured, an attempt to configure ESMTP will result in the error message, "%ESMTP cannot coexist with SMTP, please unconfigure SMTP and try again...." If ESMTP is already configured, an attempt to configure SMTP will result in the error message, "%SMTP cannot coexist with ESMTP, please unconfigure ESMTP and try again...."
The following example illustrates how the router will react if you attempt to configure both protocols:
Router(config)# ip inspect name mail-guard smtpRouter(config)# ip inspect name mail-guard esmtpESMTP cannot coexist with SMTP, please unconfigure SMTP and try again...Router(config)# endRouter# show running-config...ip inspect name mail-guard smtp...SUMMARY STEPS
1.
2.
3.
4.
5.
DETAILED STEPS
Troubleshooting Tips
To view and verify the inspection configuration, status, or session information, you can use any of the following EXEC commands:
•
•
•
Alert Messages
The existing SMTP-related alert message will not change. This message is logged every time the firewall detects an illegal or unsupported command. The message format is as follows:
FW-3-SMTP_INVALID_COMMAND: Invalid SMTP command (%s) (total %d chars) from initiator (%i:%d)A new alert message is added. This message is logged whenever the firewall detects an illegal parameter in an SMTP command. The message includes the address and port of the sender as well as the illegal parameter. The message format is as follows:
FW-3-SMTP_INVALID_PARAMETER: Invalid SMTP parameter (%s) from initiator (%i:%d)
What to Do Next
To provide a record of network access through the firewall, including illegitimate access attempts, and inbound and outbound services, you should turn on logging and audit trail. For information on completing this task, refer to the section "Configuring Logging and Audit Trail" in the chapter "Configuring Context-Based Access Control" in the Cisco IOS Security Configuration Guide.
Configuration Examples for Firewall ESMTP Support
This section contains the following configuration example:
•
ESMTP Inspection Configuration: Example
The following example shows how to configure inspection of ESMTP traffic:
Router# configure terminalRouter(config)# ip inspect name mail-guard esmtp timeout 30Additional References
The following sections provide references related to ESMTP Support for Cisco IOS Firewall.
Related Documents
Standards
MIBs
None
To locate and download MIBs for selected platforms, Cisco IOS releases, and feature sets, use Cisco MIB Locator found at the following URL:
RFCs
Technical Assistance
Command Reference
This section documents the following modified command:
ip inspect name
To define a set of inspection rules, use the ip inspect name command in global configuration mode. To remove the inspection rule for a protocol or to remove the entire set of inspection rules, use the no form of this command.
ip inspect name inspection-name protocol [alert {on | off}] [audit-trail {on | off}]
[timeout seconds]no ip inspect name [inspection-name protocol]
HTTP Inspection Syntax
ip inspect name inspection-name http [urlfilter] [java-list access-list] [alert {on | off}] [audit-trail {on | off}] [timeout seconds]
no ip inspect name inspection-name protocol
SMTP and ESMTP Inspection Syntax
ip inspect name inspection-name {smtp | esmtp} [alert {on | off}] [audit-trail {on | off}] [max-data number] [timeout seconds]
remote-procedure call (RPC) Inspection Syntax
ip inspect name inspection-name rpc program-number number [wait-time minutes] [alert {on | off}] [audit-trail {on | off}] [timeout seconds]
no ip inspect name inspection-name protocol
Fragment Inspection Syntax
ip inspect name inspection-name fragment [max number timeout seconds]
no ip inspect name inspection-name fragment
Syntax Description
Defaults
No inspection rules are defined until you define them using this command.
Command Modes
Global configuration
Command History
Usage Guidelines
To define a set of inspection rules, enter this command for each protocol that you want the Cisco IOS firewall to inspect, using the same inspection-name. Give each set of inspection rules a unique inspection-name, which should not exceed the 16-character limit. Define either one or two sets of rules per interface—you can define one set to examine both inbound and outbound traffic, or you can define two sets: one for outbound traffic and one for inbound traffic.
To define a single set of inspection rules, configure inspection for all the desired application-layer protocols, and for TCP, UDP, or ICMP as desired. This combination of TCP, UDP, and application-layer protocols join together to form a single set of inspection rules with a unique name. (There are no application-layer protocols associated with ICMP.)
To remove the inspection rule for a protocol, use the no form of this command with the specified inspection name and protocol; to remove the entire set of inspection rules, use the no form of this command only; that is, do not list any inspection names or protocols.
In general, when inspection is configured for a protocol, return traffic entering the internal network will be permitted only if the packets are part of a valid, existing session for which state information is being maintained.
TCP and UDP Inspection
You can configure TCP and UDP inspection to permit TCP and UDP packets to enter the internal network through the firewall, even if the application-layer protocol is not configured to be inspected. However, TCP and UDP inspection do not recognize application-specific commands, and therefore might not permit all return packets for an application, particularly if the return packets have a different port number from the previous exiting packet.
Any application-layer protocol that is inspected will take precedence over the TCP or UDP packet inspection. For example, if inspection is configured for FTP, all control channel information will be recorded in the state table, and all FTP traffic will be permitted back through the firewall if the control channel information is valid for the state of the FTP session. The fact that TCP inspection is configured is irrelevant.
With TCP and UDP inspection, packets entering the network must exactly match an existing session: the entering packets must have the same source or destination addresses and source or destination port numbers as the exiting packet (but reversed). Otherwise, the entering packets will be blocked at the interface.
ICMP Inspection
An ICMP inspection session is on the basis of the source address of the inside host that originates the ICMP packet. Dynamic access control lists (ACLs) are created for return ICMP packets of the allowed types (echo-reply, time-exceeded, destination unreachable, and timestamp reply) for each session. There are no port numbers associated with an ICMP session, and the permitted IP address of the return packet is wild-carded in the ACL. The wild-card address is because the IP address of the return packet cannot be known in advance for time-exceeded and destination-unreachable replies. These replies can come from intermediate devices rather than the intended destination.
Table 2 Protocol Keywords—Transport-Layer and Network-Layer Protocols
ICMP
icmp
TCP
tcp
UDP
udp
Application-Layer Protocol Inspection
In general, if you configure inspection for an application-layer protocol, packets for that protocol should be permitted to exit the firewall (by configuring the correct access control list), and packets for that protocol will only be allowed back in through the firewall if they belong to a valid existing session. Each protocol packet is inspected to maintain information about the session state.
Java, H.323, RPC, Session Initiation Protocol (SIP), and SMTP inspection have additional information, described in the next five sections. Table 3 lists the supported application-layer protocols.
Java Inspection
Java inspection enables Java applet filtering at the firewall. Java applet filtering distinguishes between trusted and untrusted applets by relying on a list of external sites that you designate as "friendly." If an applet is from a friendly site, the firewall allows the applet through. If the applet is not from a friendly site, the applet will be blocked. Alternately, you could permit applets from all sites except sites specifically designated as "hostile."
Note
Caution
H.323 Inspection
If you want CBAC inspection to work with NetMeeting 2.0 traffic (an H.323 application-layer protocol), you must also configure inspection for TCP, as described in the chapter "Configuring Context-Based Access Control" in the Cisco IOS Security Configuration Guide. This requirement exists because NetMeeting 2.0 uses an additional TCP channel not defined in the H.323 specification.
RPC Inspection
RPC inspection allows the specification of various program numbers. You can define multiple program numbers by creating multiple entries for RPC inspection, each with a different program number. If a program number is specified, all traffic for that program number will be permitted. If a program number is not specified, all traffic for that program number will be blocked. For example, if you created an RPC entry with the NFS program number, all NFS traffic will be allowed through the firewall.
SIP Inspection
You can configure SIP inspection to permit media sessions associated with SIP-signaled calls to traverse the firewall. Because SIP is frequently used to signal both incoming and outgoing calls, it is often necessary to configure SIP inspection in both directions on a firewall (both from the protected internal network and from the external network). Because inspection of traffic from the external network is not done with most protocols, it may be necessary to create an additional inspection rule to cause only SIP inspection to be performed on traffic coming from the external network.
SMTP Inspection
SMTP inspection causes SMTP commands to be inspected for illegal commands. Packets with illegal commands are modified to a "xxxx" pattern and forwarded to the server. This process causes the server to send a negative reply, forcing the client to issue a valid command. An illegal SMTP command is any command except the following:
•
•
•
•
•
•
•
•
•
•
•
•
ESMTP Inspection
Like SMTP, ESMTP inspection also causes the commands to be inspected for illegal commands. Packets with illegal commands are modified to a "xxxx" pattern and forwarded to the server. This process causes the server to send a negative reply, forcing the client to issue a valid command. An illegal ESMTP command is any command except the following:
•
•
•
•
•
•
•
•
•
•
•
•
•
•
•
In addition to inspecting commands, the ESMTP firewall also inspects the following extensions via deeper command inspection:
•
•
•
•
•
•
•
•
Note
Use of the urlfilter Keyword
If you specify the urlfilter keyword, the Cisco IOS firewall will interact with a URL filtering software to control web traffic for a given host or user on the basis of a specified security policy.
Note
Use of the timeout Keyword
If you specify a timeout for any of the transport-layer or application-layer protocols, the timeout will override the global idle timeout for the interface to which the set of inspection rules is applied.
If the protocol is TCP or a TCP application-layer protocol, the timeout will override the global TCP idle timeout. If the protocol is UDP or a UDP application-layer protocol, the timeout will override the global UDP idle timeout.
If you do not specify a timeout for a protocol, the timeout value applied to a new session of that protocol will be taken from the corresponding TCP or UDP global timeout value valid at the time of session creation.
The default ICMP timeout is deliberately short (10 seconds) due to the security hole that is opened by allowing ICMP packets with a wild-carded source address back into the inside network. The timeout will occur 10 seconds after the last outgoing packet from the originating host. For example, if you send a set of 10 ping packets spaced one second apart, the timeout will expire in 20 seconds or 10 seconds after the last outgoing packet. However, the timeout is not extended for return packets. If a return packet is not seen within the timeout window, the hole will be closed and the return packet will not be allowed in. Although the default timeout can be made longer if desired, it is recommended that this value be kept relatively short.
IP Fragmentation Inspection
CBAC inspection rules can help protect hosts against certain denial-of-service attacks involving fragmented IP packets. Even though the firewall keeps an attacker from making actual connections to a given host, the attacker may still be able to disrupt services provided by that host. This is done by sending many non-initial IP fragments or by sending complete fragmented packets through a router with an ACL that filters the first fragment of a fragmented packet. These fragments can tie up resources on the target host as it tries to reassemble the incomplete packets.
Using fragmentation inspection, the firewall maintains an interfragment state (structure) for IP traffic. Non-initial fragments are discarded unless the corresponding initial fragment was permitted to pass through the firewall. Non-initial fragments received before the corresponding initial fragments are discarded.
Note
Because routers running Cisco IOS software are used in a very large variety of networks, and because the CBAC feature is often used to isolate parts of internal networks from one another, the fragmentation inspection feature is not enabled by default. Fragmentation detection must be explicitly enabled for an inspection rule using the ip inspect name command. Unfragmented traffic is never discarded because it lacks a fragment state. Even when the system is under heavy attack with fragmented packets, legitimate fragmented traffic, if any, will still get some fraction of the firewall's fragment state resources, and legitimate, unfragmented traffic can flow through the firewall unimpeded.
Examples
The following example causes the software to inspect TCP sessions and UDP sessions, and to specifically allow CU-SeeMe, FTP, and RPC traffic back through the firewall for existing sessions only. For UDP traffic, audit-trail is on. For FTP traffic, the idle timeout is set to override the global TCP idle timeout. For RPC traffic, program numbers 100003, 100005, and 100021 are permitted.
ip inspect name myrules tcpip inspect name myrules udp audit-trail onip inspect name myrules cuseemeip inspect name myrules ftp timeout 120ip inspect name myrules rpc program-number 100003ip inspect name myrules rpc program-number 100005ip inspect name myrules rpc program-number 100021The following example adds fragment checking to software inspection of TCP and UDP sessions for the rule named "myrules." In this example, the firewall software will allocate 100 state structures, and the timeout value for dropping unassembled packets is set to 4 seconds. If 100 initial fragments for 100 different packets are sent through the router, all of the state structures will be used up. The initial fragment for packet 101 will be dropped. Additionally, if the number of free state structures (structures available for use by unassembled packets) drops below the threshold values, 32 or 16, the timeout value is automatically reduced to 2 or 1, respectively. Changing the timeout value frees up packet state structures more quickly.
ip inspect name myrules tcpip inspect name myrules udp audit-trail onip inspect name myrules cuseemeip inspect name myrules ftp timeout 120ip inspect name myrules rpc program-number 100003ip inspect name myrules rpc program-number 100005ip inspect name myrules rpc program-number 100021ip inspect name myrules fragment max 100 timeout 4The following firewall and SIP example shows how to allow outside-initiated calls and internal calls. For outside-initiated calls, an ACL needs to be punched to allow for the traffic from the initial signaling packet from outside. Subsequent signaling and media channels will be allowed by the inspection module.
ip inspect name voip sipinterface FastEthernet0/0ip inspect voip in!!interface FastEthernet0/1ip inspect voip inip access-group 100 in!!access-list 100 permit udp host <gw ip> any eq 5060access-list 100 permit udp host <proxy ip> any eq 5060access-list deny ip any anyThe following example shows two configured inspections named "fw_only" and "fw_urlf"; URL filtering will work only on the traffic that is inspected by fw_urlf. Note that the java-list access-list option has been enabled, which disables java scanning.
ip inspect name fw_only http java-list 51 timeout 30interface e0ip inspect fw_only in!ip inspect name fw_urlf http urlfilter java-list 51 timeout 30interface e1ip inspect fw_urlf inRelated Commands
Copyright © 2004 Cisco Systems, Inc. All rights reserved.
