next up previous
Next: Exposing a Secure Up: Request-Response Policy Previous: Packet Filtering and

Application-Level Proxies for Ill-Behaved Application Protocols

We have found that many application protocols are not immediately amenable to our request-response paradigm. These applications typically fall into two categories: connectionless UDP-based applications and ``reverse-channel'' TCP-based applications. For a few critical applications, we introduce application-level proxies to create a request-response illusion over an otherwise ill-behaved protocol. The proxies run on a bastion host, an internal host configured specifically for the purpose. Unlike many traditional designs, our firewall permits multiple bastion hosts, thereby both eliminating the performance bottlenecks often seen in other firewall designs and allowing each bastion host to be stripped-down to support a limited set of applications. The packet filter accepts incoming packets for these restricted protocols if they are destined for an appropriate bastion host.

Connectionless UDP-Based Applications: Most applications do not use UDP sockets in connected mode, so an application receives all packets addressed to its UDP socket, regardless of the foreign address or port. Because there is no connection setup, a packet filter and endpoint host cannot distinguish between a UDP ``response'' from an external host and a subsequent ``request'' from that external host that coincidentally or maliciously uses the same remote and local port numbers as an earlier response. To evaluate whether an inbound packet is indeed a valid UDP ``response,'' the packet filter or host operating system would need to retain some application-specific state. Clearly, our TCP approach of a packet filter and host filtering is impractical for connectionless UDP protocols.

Two connectionless UDP services that we regard as essential are NTP [20] for time synchronization, and DNS [21] for mapping between hostnames and addresses.

NTP servers are configured in a tree; higher-level servers periodically broadcast their current time statistics to lower-level servers, so the lower-level servers can measure and adjust for clock drift. This server-initiated traffic does not match our request-response paradigm.

We allow NTP through our perimeter by designating a set of internal hosts as NTP ``bastions.'' Our packet filters allow traffic from the NTP port of any external host to the NTP port of any NTP bastion. All other internal machines synchronize to the bastion machines. This approach fits naturally within the architecture of NTP, and has not caused any problems to date.

Although DNS fits a request-response paradigm and can be configured to use either TCP or UDP, DNS clients typically use UDP from an arbitrary UDP port. We manage DNS like we manage NTP. We have configured a set of internal ``slave'' nameservers that forward all requests they receive to a set of external nameservers. Our packet filters admit UDP traffic with source and destination ports set to the DNS reserved port from external hosts to our internal nameservers. This design has worked satisfactorily, and has actually produced an unexpected positive side effect: because the local nameservers maintain a cache, we have seen improved performance during intermittent failures of the campus nameservers.

The approach we have taken for other UDP services is unconventional: we simply require users to invoke these services from our expendable machine outside the firewall. Services like talk, archie, and rusers use UDP and are currently blocked by our packet filters. While far from ideal, maintaining a login session to an expendable host for these services has proved to be a workable interim solution.

Proxies for Reverse-Channel Services: Our request-response implementation also cannot currently handle TCP-based services that require a ``back-channel'' connection. For example, FTP clients implement requests like dir and get by creating a local ``throwaway'' TCP socket, sending a message to the remote server asking that the resulting output be sent to the throwaway port, and then waiting for the remote server to connect to the throwaway port and send the data. Our request-response implementation blocks the server's connection to the throwaway port. The FTP protocol is almost rich enough so that minor changes to the client can eliminate most of FTP's uses of back-channels.gif Unfortunately, few protocols are as flexible as FTP. For example, the back-channel problem also arises with the Berkeley rsh command, which establishes back-channels for the remote stderr.

The back-channel problem arises in a different form when a user inside the firewall tries to start an X windows [24] client on an external host to appear on the user's local display. To connect to the display, the external client must establish a TCP connection to the X server inside the firewall. Our access policy does not allow this connection, however. We could choose to let the connection through the firewall and rely on the X server to reject unauthorized connections. Unfortunately, authentication systems such as Kerberos [23,19] are not deployed on all potential external client machines. Without a convenient, unobtrusive, and ubiquitous authentication mechanism, we believe the temptation to disable server authentication is too great. At this point, we have not fully assessed the implications of allowing arbitrary client connections to reach internal X servers.

We currently use off-the-shelf application-level proxies for remote X clients, FTP, and login. This solution is similar to that taken by existing corporate firewalls. For example, the X proxy simply allocates a new logical display on the bastion host corresponding to the display on a trusted, internal host H. If a client wants to open a window on host H, it instead opens the corresponding logical display on the bastion host. The proxy queries the user on host H for permission to open the window. If the user on host H grants permission, then the bastion translates all operations on the logical display to the corresponding window on host H. At one level, the bastion is actually seeking explicit human-level acknowledgement that the incoming client connection was actually requested. This is, therefore, consistent with the request-response policy, though the filtering is not automatic.

Ultimately, we regard the use of application-level proxies as a temporary workaround for ill-designed application protocols. We would prefer that our packet filter could fully implement the request-response policy. As the need for security becomes more prevalent, we hope and expect that many of the connectionless UDP and back-channel TCP protocols will be redesigned to support the automated request-response paradigm.

next up previous
Next: Exposing a Secure Up: Request-Response Policy Previous: Packet Filtering and

Sandeep Singhal
Thu Nov 30 01:58:58 PST 1995