Fixup Protocol Examples
 
The next three topics—FTP, SMTP, and VoIP—are included as
examples of the application-inspection features and fixup
commands. The Cisco site has more details and examples for any of the other
supported protocols or applications.
FTP
The default application inspection for FTP sessions performs
the following four tasks:
-
NATs any IP addresses embedded within the application
payload
-
Prepares dynamic secondary data connections for FTP data
transfer
-
Tracks FTP command-response sequence
-
Generates a detailed audit trail
The following output shows the command syntax, plus an example of
the Strict option and adding port 3021 for the PIX to listen to for FTP traffic.
Our only concern is with the FTP listening ports because the PIX stateful
inspection will dynamically prepare the data connection as needed.
Pix(config)# fixup protocol ftp [strict] [port] Pix(config)#fixup protocol ftp strict 21 Pix(config)#fixup protocol ftp 3021
The Strict option causes each FTP command
and response sequence to be monitored for various RFC violations, including web
browsers embedding commands in FTP requests. Any connections discovered to
contain embedded commands or that have been manipulated are dropped. Each FTP
command must be acknowledged before a new command is allowed.
SMTP—Disabling Fixup Protocol Example
The Mail Guard feature provides safe access for Simple Mail
Transfer Protocol (SMTP) connections from the outside to an inside e-mail
server. Mail Guard allows a mail server to be safely
deployed on the inside network, without the need for an external mail relay (or
bastion host) system.
SMTP servers respond to client requests with numeric reply codes
and optional human readable strings. The SMTP servers are vulnerable to mischief
because of the simplicity of these messages and because some mail systems, such
as Microsoft Exchange, don’t fully comply with RFC 821. Mail Guard enforces a
safe minimal set of SMTP commands to avoid an SMTP server system from being
compromised. Mail Guard performs the following three primary tasks:
-
Restricts SMTP requests to seven commands included in RFC
821: HELO, MAIL, RCPT, DATA, RSET, NOOP, and QUIT.
-
Monitors the SMTP command and response sequence looking for
a series of common anomalous signatures. Unacceptable characters or commands are
replaced by Xs, which are then rejected by the internal
server.
-
Generates a detailed audit trail by logging all SMTP
connections.
The SMTP application inspection command syntax
and an example of disabling the Mail Guard feature are as follows:
Pix(config)# fixup protocol smtp [port[-port]] Pix(config)# no fixup protocol smtp 25
The pervasiveness of Exchange servers in the workplace is reason
enough to be aware that Mail Guard could cause Exchange servers and Microsoft
Outlook clients to have problems in communicating through a PIX Firewall. It
might be necessary to disable the SMTP application inspection and use an access
list instead.
The following example demonstrates disabling Mail Guard, while
allowing outside access to the DMZ e-mail server. The static
command assigns a global address to the server. The ACL let_in allows outside
users access to the e-mail server global address via SMTP port (25). The DNS
server needs to point to the 1.1.1.6 address, so mail can be sent to this
address.
Pix(config)# static (dmz,outside) 1.1.1.6 192.168.2.6 netmask 255.255.255.255 Pix(config)# access-list let_in permit tcp any host 1.1.1.6 eq smtp Pix(config)# access-group let_in in interface outside Pix(config)# no fixup protocol smtp 25
Voice over IP (VoIP)
VoIP involves using H.323 gateways to convert traditional
voice analog traffic into IP data packets. The challenges of highly
time-sensitive packets in a LAN environment are compounded exponentially when
VoIP has to deal with firewalls and NAT. Fortunately, the PIX Firewall
application-layer inspection (fixup) features smooth out most of these wrinkles
across all the protocols.
-
H.323
-
Media Gateway Control Protocol (MGCP)
-
Session Initiation Protocol (SIP)
-
Skinny Client Control Protocol (SCCP)
-
Real-Time Transport Protocol (RTP)
-
RTP Control Protocol (RTCP)
This section looks at three protocol suites that provide or
facilitate call signaling, call control, and media communications. Depending on
the VoIP protocols used, the communications between the devices might use either
one channel or many different channels. The channels are Transmission Control
Protocol (TCP)/User Datagram Protocol (UDP) ports used for the connections
between two network devices.
Session Initiation (or Initiated) Protocol (SIP)
Session Initiation (or Ini-tiated) Protocol (SIP) is a
signaling protocol for Internet conferencing, telephony, events notification,
presence, and instant messaging. The protocol initiates call setup, routing,
authentication, and other feature messages to end-stations in an IP network. The
PIX Firewall application-inspection capabilities support SIP VoIP gateways, VoIP
proxy servers, and dynamically allocated UDP ports.
Use the fixup protocol command to change the
default port assignment for SIP or to add additional ports the PIX will “listen”
to. The command syntax is as follows:
Pix(config)# fixup protocol sip [port[- port]] Pix(config)# no fixup protocol sip [port[- port]]
H.323
H.323 is a suite of protocols defined
by the International Telecommunication Union (ITU) enabling multimedia
conferences over LANs, even though hosts are using different applications. PIX
Firewall software versions 6.2 and higher support PAT for H.323. The PIX
Firewall supports the secure use of H.323 Version 2 to provide the following
features:
-
Fast Connect or Fast Start Procedure for faster call
setup.
-
H.245 tunneling for resource conservation, call
synchronization, and reduced setup time.
-
Conferencing—the conference is established only after the
endpoints agree to participate.
-
Call redirection.
Use the fixup protocol command to change the
default port assignment for H.323 or add additional ports the PIX will “listen”
to. The command syntax and default settings are as follows:
Pix(config)# fixup protocol h323 {h225 | ras} [port[- port]] Pix(config)# no fixup protocol h323 {h225 | ras} [port[- port]] Pix(config)# show fixup fixup protocol h323 h225 1720 fixup protocol h323 ras 1718-1719
Skinny (Simple) Client Control
Protocol (SCCP)
Secure handling of SCCP in VoIP networks is necessary to use
Cisco IP Phones, Cisco CallManager, and other Cisco IP Telephony products. When
coupled with an H.323 Proxy, an SCCP client can coexist with H.323-compliant
terminals. The PIX application-inspection capabilities ensure proper NAT
translation of all SCCP signaling and media packets passing through the
firewall.
PIX Firewall version 6.2 introduced support for DHCP options 150
and 166 (discussed in Chapter 18), which allow the PIX Firewall to send the
location of a TFTP server to Cisco IP Phones and other DHCP clients.
Use the fixup protocol command to change the
default port assignment for SCCP or add additional ports the PIX will “listen”
to. The command syntax is as follows:
Pix(config)# fixup protocol skinny [port[- port]] Pix(config)# no fixup protocol skinny [port[- port]]
Two problems still exist for SCCP:
-
If the Cisco CallManager server address is configured for
NAT and outside phones register to it using TFTP, the connection will fail
because PIX Firewall currently doesn’t support NAT TFTP messages.
-
The PIX Firewall currently can’t handle fragmented SCCP
packets, such as those that occur with a voice-conferencing bridge. The SCCP
inspection checks each packet and drops what appear to be bad packets because
the internal checksums aren’t accurate.
197 times read
|
|
|
Did you enjoy this article?
(total 0 votes)
|