Cisco PIX: Advanced Features and Attack Guards

This chapter is from the book

Cisco Secure PIX Firewalls

Learn More Buy

This chapter is from the book

This chapter is from the book 

Cisco Secure PIX Firewalls

Learn More Buy

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.

• Use Network Address Translation (NAT)-relevant instances of IP addresses inside a packet.

• Use Port Address Translation (PAT)-relevant instances of ports inside a packet.

• Inspect packets for signs of malicious application misuse.

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).

Example 9-1 Sniffer Trace Illustrating Classic Mode FTP

Figure 9-1 Standard Mode FTP Client/Server Transactions

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.

Figure 9-2 Passive Mode FTP Client/Server Transactions

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 ftp port-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.

Example 9-2 Configuring and Removing 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.

Figure 9-3 shows transactions between the client and server for rsh.

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.

Figure 9-3 rsh Client/Server Transactions

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.

Example 9-3 Configuring and Removing Standard and Non-Standard Ports for RSH

The fixup protocol rsh command enables the PIX Firewall to dynamically create conduits for rsh standard error connections for rsh traffic on the indicated port.

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.

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

Figure 9-4 SQL*Net Client/Server Transactions

For SQL*Net traffic, the PIX Firewall behaves in the following manner:

• Outbound connections—If all outbound TCP traffic is implicitly allowed, no special handling is required because the client initiates all TCP connections from the inside.

  If all outbound TCP traffic is not implicitly allowed, the PIX Firewall opens a conduit for the redirected channel between the server and the client.

• Inbound connections—If a conduit exists allowing inbound SQL*Net connections to an SQL*Net server, the PIX Firewall opens an inbound conduit for the redirected channel.

fixup protocol sqlnet Command

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

fixup protocol sqlnet port [-port ]
no fixup protocol sqlnet port [-port ]
clear fixup protocol sqlnet

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.

Example 9-4 Adding and Removing Standard and Non-standard Ports for SQL*NET

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.