Thoughts on Distributed Firewalls

Author: Steven M. Bellovin

BibTex:

@ARTICLE{Bellovin99distributedfirewalls,
author = {Steven M. Bellovin},
title = {Distributed Firewalls},
journal = {IEEE Communications Magazine},
year = {1999},
volume = {32},
pages = {50--57}
}

also: S. M. Bellovin. Distributed Firewalls. ;login: magazine, special issue on security, November 1999.

Summary:

Centralize policy, distribute enforcement. The end-host knows exactly what is going on in the machine and can make more informed decisions. Distributed enforcement no longer depends on the topology of a network.

Use IPSEC certs to authenticate hosts. Use hybrid firewalls (both distributed and traditional) with app proxies for complex app rules.

Claim that:

• Can do application level filtering by distributing application rules (e.g. no Javascript in browsers)
• Can protect machines in internal network from each other
• Can understand app level semantics
• Can protect mobile nodes
• Can manage changes such as updates by distributing new certs and lowering privileges for old certs

Threat comparison between traditional and distributed:

• Service exposure and port scanning: Comparable
• App level proxies: conventional in most cases wins
• DoS: Distributed wins
• IDS: conventional easier, though distributed can gather more data.
• Insider attacks: comparable

The claim the author believes is the most important is freedom from topology restrictions.

The Good:
Yes it is definitely a great idea to centralize policy and make sure that it is consistent across multiple security mechanisms. It is also true that the end-host knows more about a connection and thus can enforce more things. Distributed firewalls also free the security policy from relying on topology.

The Bad:

• Enforcement on the end-host is a bad idea because it is easy to subvert the system (as was noted in the paper). This would make the admin's policies useless.
• The author mentions application level enforcement, but that means that the firewall must somehow know what each application is doing and for example realizae that some html has javascript or the like. That is a very difficult thing to do in a generic way. How would one keep track of all the new applications that come up? Indeed, the author mentions this is a problem just before the conclusion.
  
• The argument that conventional firewalls are more susceptible to DoS attacks is not quite correct. Firewall boxes are usually much more powerful than end-hosts, and so end-hosts are the ones that are more susceptible to DoS attacks. In addition, a DoS attack against an enterprise that does not have a conventional firewall at the point where it connects to the Internet can suffer from a DoS attack that extends deeper into the network such as NFS DoS.

The paper was well-written, though I do not feel it fixes much. Enforcement has to be impossible to circumvent so that an administrator always has the final word. ident++ deals with this issue exactly. In addition, ident++ moves the enforcement away from the end-host so it doesn't get DoS'ed. It also asks both end points of a connection whether the connection is allowed, making sure no bandwidth is wasted anywhere and no host misbehaves.