next up previous
Next: User Acceptance Up: Experiences in Designing Previous: Off-The-Shelf Software and

Vulnerabilities of the SURF Firewall


The SURF firewall design faces three potential sources of vulnerability: the open environment behind the firewall and absence of outgoing packet filtering, the coarseness of the incoming packet filter, and the potential for hijacking otherwise acceptable connections. We feel that each of these risks is either necessary to maintain an acceptable research environment or is already present with traditional firewalls.

Open Research Environment: The first risk arises because we do not restrict traffic between machines behind the firewall and because we do not filter any outbound packets. As a result, an intruder who penetrates the security perimeter has unrestricted access to all internal hosts. Moreover, once an intruder gains access to an internal host, SURF does not prevent any outbound operation, including data transfer. In effect, once it has been breached, the firewall no longer offers any protection. However, any attempt to ease these risks would significantly affect the openness of our research environment and thereby make the firewall unacceptable to our users.

At first, it might appear that having multiple physical enclaves connected by secure IP tunnels (swIPe) is an additional security risk. However, each enclave is surrounded by its own trusted firewall; these firewalls can be identical. Clearly, an attack that breaches one of these firewalls would also have breached a single physical enclave. Furthermore, the swIPe tunnels themselves are secure because we trust the DES encryption that they use. Therefore, our multiple physical enclaves do not introduce any additional risk.

Coarse-Grain Packet Filter: Our second risk comes from the design of our incoming packet filters. We employ a coarse-grain packet filter and rely on internal hosts to perform additional filtering. As a consequence, our packet filter admits packets that may not in fact be responses to outstanding requests. This policy potentially exposes us to a denial-of-service attack flooding our internal network with ``nuisance'' packets that internal hosts must subsequently process and drop. However, this risk is also not significant. An intruder can flood any protected network by discovering a packet which elicits a response from behind the firewall. Obviously, a packet filter cannot protect anything outside the LAN, such as the tail circuit or the filtering hardware itself.

In trusting internal hosts to discard inappropriate packets and unsolicited responses admitted by the filter, we must carefully choose the set of acceptable protocols that the packet filter accepts. We might otherwise accidentally admit Trojan Horse packets masquerading as responses to one application but in fact are requests to another; a poorly-written application may fail to implement end-to-end checks to validate that incoming packets are actually responses to outstanding requests. However, these risks are known in advance, and before allowing a particular application protocol through the firewall, the network managers must determine that the benefits of admitting apparent responses of the new protocol outweigh the additional masquerading risk. The vulnerability largely results from limitations in the application protocols themselves (and the semantics of UDP ports), and in the long-term, these protocols should be redesigned, as discussed in Section 7. In our current environment, the risks associated with over-permissive response filtering are worth the benefits of transparent access using off-the-shelf clients and servers.

Connection Attacks: Our final risk arises from potential attacks to authorized connections through the firewall. TCP sessions to external hosts are subject to hijacking, man-in-the-middle, and eavesdropping attacks. In addition, NFS requests to a compromised external fileserver may cause us to read or execute intruder-supplied data. To address these dangers, one must simply be careful in selecting which applications are available to users. For example, one would be foolhardy to permit an application through the firewall if its response packets could obtain control of a shell running inside the firewall.

SURF is also vulnerable to this class of attack because it supports authenticated access through potentially insecure hosts and networks outside the firewall. If a research group member is travelling and gains legitimate access to our internal machines from some machine, then that connection is vulnerable to attack at any point outside our network. By inserting himself between the user and the firewall, an intruder can gain full access to our network. These risks will only be eliminated in the future when portable ``bastion hosts'' (personal devices capable of encrypted telnet) are ubiquitous. However, the ability to log in while traveling is so important that, for the moment, we trust the discretion of our group members. When unable to plug their own personal computers into the network, users are expected to use one-time passwords, carefully choose the machines they use to log in, and be aware of the risks of connection eavesdropping and hijacking.

next up previous
Next: User Acceptance Up: Experiences in Designing Previous: Off-The-Shelf Software and

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