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:

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

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

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

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

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

6. 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:

1.	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.
2.	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).
3.	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.