This chapter is from the book

This chapter is from the book

With only a few exceptions, advanced protocol handling is accomplished via a
mechanism called a fixup protocol. The fixup protocol command
operates not as a true proxy but as an application aware agent. In most
cases, the fixup protocol acts by monitoring the control channel of an
application to prevent protocol violations and enable the PIX to respond
dynamically to a protocol's legitimate need to open an inbound connection
securely by making a temporary exception in the ASA. When the exception is no
longer needed, the fixup protocol closes it. Each new version of the PIX OS
brings new and improved protocol handling. It is important to note that the PIX
can only perform these operations on the fixups that are part of the PIX OS
running on your PIX. Fixups are not user-definable or user-programmable. Fixups
allow you to enable or disable processing for the supported protocols and
determine what ports (standard or non-standard) to operate on.

The Need for Advanced Protocol Handling

Nearly every enterprise uses the Internet for business transactions. For
these enterprises to keep their internal networks secure from potential threats
from the Internet, they must implement firewalls to separate their trusted
internal networks from the untrusted Internet. Even though firewalls help
protect an enterprise's internal networks from external threats,
implementation challenges have arisen as well.

Some of the protocols and applications that enterprises used to
communicate with outside resources prior to the installation of a firewall are
now blocked by the firewall.

Many popular protocols and applications negotiate connections to
dynamically assign source or destination ports or IP addresses. To further
complicate matters, some applications embed source or destination IP addressing
information above the network layer (Layer 3).

A good firewall must inspect packets above the network layer and perform the
following operations as required by the protocol or application:

Securely open and close negotiated ports or IP addresses for legitimate
client/server connections through the firewall.

Through the use of the Cisco Secure PIX Firewall's fixup protocol
protocol commands, you can provide secure passage for these
applications.

The sections that follow explain how the specific fixup protocol
protocol commands for Standard and Passive File Transfer Protocol
(FTP), rsh (Remote Shell), and SQL*Net operate and how to configure them.

Standard Mode FTP

Standard mode FTP (also called classic mode FTP) uses two channels for
communication. When a client behind a firewall initiates an FTP connection from
their host, it opens a standard TCP channel from one of its high-order ports
(TCP source port >1023) to destination TCP port 21 on the outside server.
This connection is referred to as the control channel. When the client
requests data from the server, it tells the server to send the data to a given
high-order port. The server acknowledges the request and initiates an
inbound connection from its own port 20 to the high-order port that the
client requested. This connection is referred to as the data channel
(port 20 FTP-DATA).

In the past, it was difficult to allow this inbound connection through the
firewall to the requested port on the client without permanently opening port 20
connections from outside servers to inside clients for outbound FTP connections.
This creates a huge potential vulnerability by allowing any inbound traffic from
any host on the Internet with a TCP source port of 20, regardless of the intent!

Example 9-1 and Figure
9-1 demonstrate the TCP three-way handshake and the establishment of the
FTP control channel (TCP port 21). Notice that in the second section of the
trace, the FTP-DATA channel is initiated by the server 198.10.2.51 (ftp.cisco.com)
with a source port of 20 and a random high port of 1066 (selected by the client).

The Cisco Secure PIX Firewall uses the fixup protocol ftp command to
securely enable the exception required by the FTP-DATA connection. The Cisco
Secure PIX Firewall handles FTP in the following manner for outbound and inbound
connections:

Outbound ConnectionsWhen the client requests data, the PIX
Firewall opens a temporary inbound conduit to allow the data channel from the
server. This conduit is torn down immediately after the data is sent.

Inbound ConnectionsIf a conduit exists allowing inbound
connections to an FTP server, and if all outbound TCP traffic is implicitly
allowed, no special handling is required because the server initiates the data
channel from the inside.

If a conduit exists allowing inbound FTP control connections to an FTP
server, and if all outbound TCP traffic is not implicitly allowed, the PIX
Firewall opens a temporary conduit for the data channel from the server. This
conduit is torn down after the data is sent.

Passive Mode FTP

Passive mode FTP also uses two channels for communications. The control
channel works the same as in a standard FTP connection, but the data channel
setup works differently. When requesting data from the server, the client asks
the server if it accepts PASV connections. If the server accepts PASV
connections, it sends the client a high-order port number to use for the data
channel. The client then initiates the data connection from its own high-order
port to the port that the server sent.

Because the client initiates both the command and data connections, early
firewalls could easily support this without exposing inside clients to attack.
Figure 9-2 shows
transactions between the client and server with passive mode FTP. Most web browsers
use passive mode FTP by default.

For passive mode FTP traffic, the PIX Firewall behaves in the following
manner for outbound and inbound PASV connections:

Outbound PASV ConnectionsIf all outbound TCP traffic is
implicitly allowed, no special handling is required because the client initiates
both the command and data channels from the inside.

If all outbound TCP traffic is not implicitly allowed, the PIX Firewall opens
a temporary conduit for the data channel from the client. This conduit is torn
down after the data is sent.

Inbound PASV ConnectionsIf a conduit exists allowing inbound
FTP control connections to a PFTP server, the PIX Firewall opens a temporary
inbound conduit for the data channel initiated by the client. This conduit is
torn down after the data is sent.

fixup protocol FTP Command

The syntax of the fixup protocol ftp command is as follows:

where port[-port] is the single port or port range that the
PIX Firewall will inspect for FTP connections.

By default, the fixup protocol ftp 21 command is enabled and the PIX
Firewall inspects port 21 connections for FTP control traffic. If you have FTP
servers using ports other than port 21, you need to use the fixup protocol
ftpport-number command to have the PIX Firewall inspect these
non-standard ports for FTP traffic. The strict option causes fixup
protocol ftp to require that every FTP request be acknowledged before a new
command is allowed and prevents web browsers from embedding commands in FTP
requests. Any FTP packets containing embedded commands are dropped. Example 9-2
demonstrates the use of the fixup protocol ftp command and its no
form to both configure and remove standard and non-standard ports for FTP.

The fixup protocol ftp command enables the PIX Firewall
to perform the following operations for FTP traffic on the indicated port:

Perform NAT or PAT in packet payload.

Dynamically create conduits for FTP data connections.

Log FTP commands (when syslog is enabled and the logging level is
debug).

Use the no form of the command as indicated in Example 9-2 to disable
the inspection of traffic on the indicated port for FTP connections. If the
fixup protocol ftp command is not enabled for a given port, then

Outbound standard FTP will not work properly on that port.

Outbound passive FTP will work properly on that port as long as outbound
traffic is not explicitly disallowed.

Inbound standard FTP will work properly on that port if a conduit to the
inside server exists.

Inbound passive FTP will not work properly on that port.

Using the clear fixup protocol ftp command without any arguments
causes the PIX Firewall to clear all previous fixup protocol ftp
assignments and set port 21 back as the default.

Remote Shell (rsh)

The rsh daemon running on a UNIX or Windows host provides remote execution
facilities with authentication based on privileged port numbers from trusted
hosts. Typically, the daemon checks the requesting client's source IP
address and source port. The source port should be in the range of
5121023; otherwise the service should abort the connection.

A second connection is then created from the rsh daemon to the specified port
on the client's machine for standard error output.

The rsh daemon then validates the host/client name by checking the
/etc/hosts.equiv and ~/.rhosts files. If the check fails, the connection is
aborted and a diagnostic message is returned.

CAUTION

Many reconnaissance tools look for misconfigured rsh services as a first step
to gain unauthorized access to your hosts. Because there are Windows ports of
rsh available, this should no longer be considered a UNIX-only
vulnerability. The safest approach to rsh is to prohibit inbound rsh connections
from outside your network.

The fixup protocol rsh command enables the PIX Firewall
to secure rsh requests in the following manner:

Outbound connectionsWhen standard error messages are sent
from the server, the PIX Firewall opens a temporary inbound conduit for this
channel. This conduit is torn down once it is no longer needed.

Inbound connectionsIf a conduit exists allowing inbound
connections to an rsh server, and if all outbound TCP traffic is implicitly
allowed, no special handling is required because the server initiates the
standard error channel from the inside.

If a conduit exists allowing inbound connections to an rsh server, and if
all outbound TCP traffic is not implicitly allowed, the PIX Firewall opens a
temporary conduit for the standard error channel from the server. This conduit
is torn down after the messages are sent.

fixup protocol rsh Command

The syntax of the fixup protocol rsh command is as follows:

where port[-port] is the single port or port range that
the PIX Firewall will inspect for rsh connections.

By default, the PIX Firewall inspects port 514 connections for rsh traffic.
If you have rsh servers using ports other than port 514, use the fixup
protocol rsh command as shown in Example 9-3 to instruct the PIX Firewall to
inspect these other ports for rsh traffic.

Use the no form of the command to disable the inspection of traffic on
the indicated port for rsh connections.

If the fixup protocol rsh command is not enabled for a given port,
then

Outbound rsh will not work properly on that port.

Inbound rsh will work properly on that port if a conduit to the inside
server exists.

Using the clear fixup protocol rsh command without any arguments
causes the PIX Firewall to clear all previous fixup protocol rsh
assignments and set port 514 back as the default.

SQL*Net

SQL*Net is used to query remote SQL databases. Although the protocol was
written by Oracle for Oracle databases, it works equally well to query the SQL
databases of other vendors. The main issue to consider when securing SQL*Net is
that while it only uses one TCP port for communications, that port can be
redirected to a different port and, even more commonly, to a different secondary
server altogether. When a client starts an SQL*Net connection, it opens a
standard TCP channel from one of its high-order ports to port 1521 on the
server. The server then proceeds to redirect the client to a different port or
IP address. The client tears down the initial TCP connection and establishes the
second connection using the redirected port.

NOTE

While the default port inspected by the fixup protocol sqlnet command
is 1521, Oracle registered TCP and UDP port 66 with IANA (Internet Assigned
Numbers Authority). You may be required to add fixup protocol 66 to your
configuration to support your particular implementation. Please see the
following web page for details:
http://www.iana.org/cgi-bin/usr-port-number.pl

Figure 9-4 illustrates
transactions between the client and the server for SQL*Net connections.

fixup protocol sqlnet Command

where port[-port] is a single port or port range that
the PIX Firewall will inspect for SQL*Net connections.

By default, the PIX Firewall inspects port 1521 connections for SQL*Net
traffic. If you have SQL*Net servers using ports other than port 1521, use the
fixup protocol sqlnet command as illustrated in Example 9-4 to instruct
the PIX Firewall to inspect these other ports for SQL*Net traffic.

The fixup protocol sqlnet command causes the PIX
Firewall to do the following for SQL*Net traffic on the indicated port:

Perform NAT in packet payload.

Dynamically create conduits for SQL*Net redirected connections.

Use the no form of the command to disable the inspection of traffic on
the indicated port for SQL*Net connections. If the fixup protocol sqlnet
command is not enabled for a given port, then the following will occur:

Outbound SQL*Net will work properly on that port as long as outbound
traffic is not explicitly disallowed.

Inbound passive SQL*Net will not work properly on that port.

Using the clear fixup protocol sqlnet command without any arguments
causes the PIX Firewall to clear all previous fixup protocol sqlnet
assignments and set port 1521 back as the default.