This chapter is from the book

This chapter is from the book

In this chapter, we introduce you to proxy techniques and how they
have been used to create proxy firewalls. Proxy firewalls serve a role similar
to stateful firewalls. Both are designed to allow or deny access between networks
based on a policy. The method they use to accomplish this is very different,
though. As described in the last chapter, with a stateful firewall, network
connections flow through the firewall if they are accepted by the policy. This
type of firewall acts like a router, passing packets through that are deemed
acceptable. In contrast, a proxy firewall acts as a go-between for every network
conversation. Connections do not flow through a proxy. Instead, computers communicating
through a proxy establish a connection to the proxy instead of their ultimate
destination. The proxy then initiates a new network connection on behalf of
the request. This provides significant security benefits because it prevents
any direct connections between systems on either side of the firewall.

Proxy firewalls are often implemented as a set of small, trusted programs
that each support a particular application protocol. Each proxy agent has in-depth
knowledge of the protocol it is proxying, allowing it to perform very complete
security analysis for the supported protocol. This provides better security
control than is possible with a standard stateful firewall. However, you only
receive this benefit for the protocols included with the proxy firewall. If
you must allow the use of a protocol that your proxy firewall does not specifically
support, you are reduced to using a generic proxy. Generic proxies do not have
any in-depth knowledge of the protocols they proxy, so they can only provide
basic security checks based on the information contained within the headers
of the packets (IP address, port, and so on).

This chapter describes the basics of proxy firewalls and how they may fit
into your security architecture. Although proxies are not as popular as they
once were, they can still offer value when deployed appropriately. This chapter
will help you to understand how proxies work, what their strengths and weaknesses
are, and when you may want to use them.

Fundamentals of Proxying

A proxy acts on behalf of the client or user to provide access to a network
service, and it shields each side from a direct peer-to-peer connection. Clients
needing to communicate with a destination server first establish a connection to
the proxy server. The proxy then establishes a connection to the destination
server on the client's behalf. The proxy server sends data it receives from
the client to the destination server and forwards data it receives from the
destination server to the client. In the process of performing this role, the
proxy server can examine the requests to ensure they are valid and allowed by
the policy.

The proxy server is both a server and a client. It is a server to the client
and a client to the destination server. One way to keep this straight is to call
the listening end of the proxy the listener and the initiating side of
the proxy the initiator. This leaves the terms client and
server for the endpoints.

Another important issue is whether the proxy is transparent to the client.
Originally, all proxy servers required clients to be aware of them. This meant
that a client's software would need to include specific code to properly
use a proxy, and the client would need to be configured to send its requests to
the proxy. Client software that was not proxy aware could not communicate
through the proxy.

Two approaches were used to overcome this software burden. First, an industry
standard proxy protocol was developed. Called SOCKS, it allows client software
developers to easily add proxy support to their products. We'll be covering
SOCKS in more detail later in this chapter. The second approach was the
development of transparent proxies. These products intercept connection requests
by masquerading on the fly as the destination server being requested by the
client. The transparent proxy then goes on to make the request to the
destination server for the client. Using this method, the client is fooled into
thinking that it is communicating directly with the server, while the proxy is
actually handling the communications.

The following is an example of how a typical request from an internal client
to an external server would be handled by a transparent proxy firewall:

The client requests an Internet service, such as HTTP, FTP, or
Telnet.

The client computer starts by attempting to set up a session between the
client and the server. Assuming the Internet service being requested is TCP
based, this begins with the client sending out a SYN packet sourced from the
client's IP address and destined to the server's IP address.

The proxy firewall intercepts the connection request and, if allowed by
policy, replies with a SYN-ACK packet sourced from the destination server's
IP address. It is important to mention that this does require the proxy to be on
the network path between the client and the server.

Upon receipt of the proxy's SYN-ACK packet, the client finishes the
three-way handshake by sending out the final ACK packet, again destined to the
server's IP address. At this point, the client thinks it has a valid TCP
connection to the external server. In reality, it only has a connection to the
proxy.

The proxy is now responsible for establishing a connection to the
external server. It accomplishes this by sending out a SYN packet sourced from
its own IP address and destined to the external server. Upon receipt of the
server's SYN-ACK packet, it replies with an ACK packet to establish the
connection to the external server. At this point, the proxy has two valid TCP
connections for the session: one between itself and the client, and the other
between itself and the server.

Requests received over the client-proxy connection will be analyzed for
correctness and policy compliance. If they are acceptable, the proxy will make a
corresponding request using its proxy-server connection. Replies received over
the proxy-server connection will also be analyzed for correctness and policy
compliance and then, if acceptable, forwarded to the client over the
proxy-client connection. This will continue until either side of the
conversation terminates the connection.

A traditional, nontransparent proxy would similarly handle the request.
However, there would be no need for the IP address manipulations required by the
transparent proxy. Instead, the client would know about the proxy and would be
able to send the request directly to the proxy server's IP address. In
addition, because the client is proxy aware, if there are any special proxy
functions for the client to choose from, the client can include this information
in the request.

Proxy firewalls are often implemented as dual-homed bastion hosts running a
set of proxy agents. Each agent supports one or more Internet protocols. The
degree to which each agent understands the protocols it proxies determines how
effective the agent can be in managing the connection. A generic agent that
supports standard TCP protocols will likely only be able to restrict connections
based on the TCP and IP headers (for example, IP address, port, TCP state). This
functionality is similar to packet filter firewalls. However, if the protocol to
be proxied is not standard, or if additional security functionality is desired,
more sophisticated agents are required.

NOTE

Bastion hosts are systems that are expected to come under direct network
attack, especially from the Internet. They are used to offer public services
such as web, FTP, DNS, and email. Their exposed roles require them to be
carefully hardened against attack. Chapter 9, "Host Hardening,"
provides a detailed description on how you can properly protect these exposed
systems.

A good protocol to use as an example is the File Transfer Protocol (FTP).
Remember from Chapter 2, "Packet Filtering," that FTP does not act
like a standard TCP protocol. Instead, FTP uses two different TCP connections to
enable file transfer. One (the command channel) is used to send instructions to
the FTP server, the other (the data channel) is used to transfer files (see
Figure 4.1). This makes it impossible to support FTP with a generic proxy.
Unless the proxy agent was aware that this second TCP connection was needed, it
would not be able to accept the second connection, blocking the FTP protocol
from transferring files.

Figure 4.1 FTP requires two TCP connections to transfer files across a
network.

An agent specifically programmed to support FTP would be able to monitor the
individual FTP commands being issued over the command channel. It would be able
to watch for the command used to transfer a file and then begin listening for
the TCP connection used to transfer the file. In addition, by being protocol
aware, the agent has the ability to watch the FTP commands to detect suspicious
activity.

FTP was created during the early days of the Internet, when security was not
something the designers emphasized. The FTP protocol contains several,
well-known security flaws that have been repeatedly exploited. Even today, it is
not uncommon to locate FTP servers that are not properly protected. One classic
flaw is related to how the data channel is set up between a client and a
server.

When the client wants to request a file from the server, one option it has is
to send a PORT command. PORT is used to configure the server
to establish a TCP connection initiated from the server to the client. The
format for the PORT command is as follows:

PORT h1, h2, h3, h4, p1, p2

The values h1 through h4 form an IP address (h1.h2.h3.h4). p1 and p2 are used
to specify the destination port using the following formula:

256 * p1 + p2

For example, if the client is at IP address 192.168.5.12, it might issue the
command

PORT 192, 168, 5, 12, 4, 1

which would tell the server to transfer requested files to IP address
192.168.5.12 using TCP port 1025. To actually cause the connection to be
established, the client uses the RETR command to request a file. At
this point, the server will initiate the TCP session to the client on TCP port
1025 and transfer the file across the resulting connection.

The vulnerability is introduced because the client can provide any IP address
and port to the PORT command. In some circumstances, this can allow an
attacker to bypass firewall restrictions. We will use the network shown in
Figure 4.2 to illustrate this attack. This network is composed of a screened
subnet that contains a web server and an FTP server. To allow customers to
upload files to the company, the FTP server is set up to allow anonymous
connections. The web server is running a Telnet service to allow administrators
to access the system from the internal network. Unfortunately, the Telnet
service is susceptible to an invalid input attack that would allow anyone who
connects to the service access to the computer without authentication. The good
news is that the stateful inspection firewall is blocking all inbound network
connections from the Internet except packets destined to TCP port 80 on the web
server and TCP port 21 on the FTP server. This would prevent attackers from
establishing a connection to the Telnet service running at TCP port 23 on the
web server. On the surface it seems that even with the vulnerable Telnet
service, the firewall has effectively kept the network secure. This is just an
illusion, though, as the FTP server can be leveraged to reach the web
server.

Figure 4.2 Even though the firewall blocks non-HTTP access to the web server,
the FTP PORT command may allow attackers to access the web
server's Telnet service.

The following steps would allow the attacker to bypass the firewall and
attack the vulnerable web server:

Use a normal FTP connection to upload a file to the anonymous FTP server.
This file needs to contain the exploit commands necessary to attack the web
server.

Using the established FTP command channel, send the command PORT
192,168,5,7,0,23. This will tell the FTP server that the next file request
should be sent to the web server using port 23 (for example, Telnet).

Again using the FTP command channel, send the RETR command
specifying the name of the file transferred during step 1. This will cause the
FTP server to initiate a TCP connection to the web server on port 23, then
transfer the contents of the file over the connection.

Assuming the file contains the commands or data necessary to exploit the web
server's Telnet service, the attacker will have successfully bypassed the
firewall, gaining control of the web server.

A sufficiently sophisticated FTP proxy agent would have had little difficulty
blocking this attack at step 2. When the agent receives the PORT
command from the client, it could compare the parameters of the command to see
if the IP address matches the IP address of the client. If it does not, the
connection could be terminated and an alert generated. This is one example of
how protocol-aware proxy agents can prevent vulnerabilities that would be
difficult or impossible to eliminate using packet-filtering techniques.

Modern proxy firewalls provide proxy agents for a large set of Internet
protocols. You can expect the core Internet protocols, such as HTTP, FTP, SMTP,
DNS, and ICMP, to be supported by just about all the products. When selecting a
proxy firewall, though, you should look carefully at the set of protocols your
network will need to pass through the proxy. If a critical protocol is missing
from the product you are considering, you may be able fall back to a generic
proxy and live with the reduction in security enforcement. If the protocol you
are trying to support is nonstandard (such as FTP), you may need to choose
between the protocol and the firewall.