Elisha Ziskind

Offline firewall analysis

Practically every corporation that is connected to the Internet has at least one firewall, and often many more. However, the protection that these firewalls provide is only as good as the policy they are configured to implement. Therefore, testing, auditing, or reverse-engineering existing firewall configurations are important components of every corporation’s network security practice. Unfortunately, this is easier said than done. Firewall configuration files are written in notoriously hard to read languages, using vendor-specific GUIs. A tool that is sorely missing in the arsenal of firewall administrators and auditors is one that allows them to analyze the policy on a firewall.To alleviate some of these difficulties, we designed and implemented two generations of novel firewall analysis tools, which allow the administrator to easily discover and test the global firewall policy. Our tools use a minimal description of the network topology, and directly parse the various vendor-specific low-level configuration files. A key feature of our tools is that they are passive: no packets are sent, and the analysis is performed offline, on a machine that is separate from the firewall itself. A typical question our tools can answer is “from which machines can our DMZ be reached, and with which services?.” Thus, our tools complement existing vulnerability analyzers and port scanners, as they can be used before a policy is actually deployed, and they operate on a more understandable level of abstraction. This paper describes the design and architecture of these tools, their evolution from a research prototype to a commercial product, and the lessons we have learned along the way.

Persistent objects in the Fleet system

Fleet is a middleware system implementing a distributed repository for persistent Java objects. Fleet is primarily targeted for supporting highly critical applications: in particular, the objects it stores maintain correct semantics despite the arbitrary failure (including hostile corruption) of a limited number of Fleet servers and, for some object types, of clients allowed to invoke methods on those objects. Fleet is designed to be highly available, dynamically extensible with new object types, and scalable to large numbers of servers and clients. In this paper, we describe the design of Fleet objects, including how new objects are introduced into the system, how they are named, and their default semantics.