|
SENSS BruceDeveloping a Tool to Aid Intranet Security
by Alec Muffett
Alec Muffett is a senior staff engineer for Sun Professional
Services EMEA.
These tools typically suffer from one problem — the inability to provide a comprehensive security report for a host as seen from the inside. An NVS can tell you whether a particular revision of a buggy network daemon is installed on a given host, but it is less likely to be able to tell you that the host's /etc directory has rwxrwxrwx permissions. This contrasts with the effectiveness of older host-vulnerability scanner (HVS) tools such as COPS, which — because they run inside a host — can provide a thorough report of almost all the security weaknesses a machine exhibits. For several years, people have tried to marry these two kinds of functionality, with varying degrees of success. The obstacles have been:
In 1997, a small SunLabs team decided to attempt to address these problems. The result has become the primary component of the Sun Enterprise™ Network Security Service, called Bruce — a networked host-vulnerability scanner. How Bruce Works After long debate, we decided to implement a network of service daemons to be installed on every host on an intranet, interlinked in a web of trust, formalizing the trusted host model of computer security that is familiar to most system administrators. We chose to implement the daemons and driver code in Java, since this provided the opportunity for a platform-independent code base, as well as strong typing, RMI-based remote execution, rapid coding with reduced opportunity for buffer overflows, and access to activation mechanisms and cryptography hooks. The only problems that we encountered in using Java to implement Bruce were:
With the latter issue, after experimenting with JNI native-method extensions, we chose to maintain a platform-independent code base and adopt the following philosophy: Use Java for secure, platform-independent glue; use platform-specific tools for platform-specific tasks. From these, we developed a design for a six-stage system that would do what we wanted: 1. Run a daemon on each host. 2. Command that daemon to launch some named task that has some security-checking function, for example OSPatchRevisionCheck; we call these tasks pollets — originally policy applets — in order to emphasize the platform-independent nature of the task names. 3. Have the daemon consult a table — embedded as part of the pollet launch request — that maps the OSPatchRevisionCheck pollet into the name of a package that implements that pollet for the host, selecting the package on the basis of the host's OS name, OS revision, CPU type, and fully qualified domain name. 4. The daemon then unpacks the package and executes its content, generating report output that is stored locally.
5. The person who launched the command can reconnect later to retrieve the output. This is a simplified view of how Bruce operates; so far, it makes Bruce sound like little more than an advanced HVS and doesn't give much of a clue how to make this into a networked tool. We then add a further stage: 6. One of the pollets, Dispatch, consults a (possibly empty) list of child hosts, held on each machine, and uses it to further punt the launch request onward to each of those children, polling them later to retrieve the output they generate. The Dispatch pollet is also responsible for propagating new revisions of pollet packages to the children, providing a shrink-wrapped software-distribution mechanism. Thus, by simple recursion, a pollet launch request is propagated among a tree of hosts, rooted at some suitably trusted parent. Output from child hosts is stored in the same manner as output generated locally, so that all output from all hosts eventually percolates up to the tree root. Because parent/child relationships are maintained locally (i.e., grandparents don't know in advance who their grandchildren will be), it is simple to add hosts into a Bruce Network without centralized intervention and associated administrative loading. A pollet's output consists of a serialized Java object containing chunks of HTML and other WWW content, held in a miniature filesystem; it is expected that this will gradually migrate to XML to allow mechanized processing of pollet output. A simple HTTP server embedded in the Bruce daemon provides the hook for report-browsing by any Web browser, including lynx. Obviously, a simple Web of trust is not enough to ensure security of a Bruce Network; thus a X.509 master certificate is installed on each host, the private key of which is used to authenticate a chain of other certificates and keys that eventually digitally sign and authenticate launch requests, preventing forgery. Other digital signatures protect the pollet-mapping tables and packages against tampering, and each launch request contains a 64-bit random serial number that is used to prevent replay attacks and loops in the Bruce Network. Further, Bruce provides hooks to extend Java's remote method invocation (RMI) mechanism, using pluggable secure transport (PST) modules to provide strong authentication, encryption, or compression between pairs of hosts; the selfsame configuration files for these PSTs also automatically generate TCP access-control lists, limiting undesired network access to the sockets used by Bruce. What We Didn't Try to Solve and Why Not A great deal of pragmatism was brought to bear on the design of Bruce. Certain problems were deemed insoluble or political. Others were addressed simply:
Other problems were more subtle. Suggestions of encrypting or signing pollet outputs were considered, but eventually rejected; without use of export-controlled public-key encryption, it would be impossible to sign or encrypt the pollet output without use of a private key that would have to be stored on each host, or embedded en clair in the launch request. Simple obfuscation of this key would add nothing to security, being merely security through obscurity. Following this premise, we also rejected attempts to solve man-in-the-middle attacks, where a Trojan-horse version of Bruce is installed on some intermediate host, forging pollet output for itself and child hosts. If a system has been compromised to this extent, then no trustworthy mechanism is available to check, for example, Bruce-executable code signatures. Instead, we cast a different light upon the software:
The benefits of Bruce come from its ability to scale; in a network of many hosts, by using Bruce in a sensibly configured manner — a shallow tree, with hardened intermediate hosts — an administrator is equipped to check and fix every machine with a single operation, whereas a hacker must still compromise them one at a time. Summary SENSS Bruce is a tool that provides an intranet administrator with the ability to maintain the security of each host on a network, also permitting security checking in a platform-independent manner. Its aim is to provide this functionality without making the security of a machine any worse than it already is. Its benefit is that it allows system administrators to bulk-administer entire networks in a secure, batch-like manner, fixing them before the hackers can get to them. Availability SENSS Bruce will be made available (including source code) to the Internet community at large under the terms of the Sun Community Source License. More information pertaining to Bruce may be requested by sending email to <bruce-feedback@sun.com>. Resources AutoHack
<ftp://coast.cs.purdue.edu/pub/doc/network/muffett-wanhack.ps.Z>
COPS <https://www.cs.purdue.edu/homes/spaf/tech-reps/993.ps> ISS Java NMAP <https://www.insecure.org/nmap/> Secure Java Coding Web pages
<https://www.javaworld.com/javaworld/jw-12-1998/jw-12-securityrules.html>
| |||||||||||||||||||||||||||||||||||||||||||||||||
 Need help? Use our Contacts page.
Last changed: 9 Dec. 1999 mc |
|
Issue index