Check out the new USENIX Web site.



Developing a Tool to Aid Intranet Security


by Alec Muffett

Alec Muffett is a senior staff engineer for Sun Professional Services EMEA.

In recent years, the network-vulnerability scanner (NVS) has become a favored tool in the network-security manager's arsenal; programs like ISS, NMap, and Sun's (internal) AutoHack provide valuable feedback for securing Intranet hosts.

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:

  • NVS systems can have problems scaling to WAN-sized networks and typically only give a view of the security of a network of hosts as seen from one place in the network — the auditing host.

  • HVS systems give a much better analysis of host weaknesses but typically are installed only once on any given host, going rapidly out of date, so that newly discovered bugs cannot be tested for without upgrading the HVS on every host in the network; also, there are major problems related to securely collecting and indexing reports from many HVS systems.

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:

  • Waiting for cryptographic (Java2) functionality on many platforms. Lacking the immediate ability to run the code everywhere was irksome, but we viewed this as less a problem than a waiting game, and we seem to be being proven correct, now that Java2 is widespread.

  • Platform-independent languages are weak for diagnosing and fixing platform-
    specific bugs. It should have struck us as obvious at the outset that a language with no notion of, for example, setuid() would have problems manipulating permissions on UNIX.

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.

Pollet Name OS OS Rev Arch Hostname Type Package Name Options
NFSSrvChk sunos 5.*sparc *package sol-nfssrv-cfg
OSPatchRevChk sunos5.* sparc* package sol-sparc-pchk
OSPatchRevChk sunos 5.* sparc * package uk-sol-pchk tmp=/var/tmp
OSPatchRevChk sunos 5.5.1 sparc package uk.coyote-pchktmp=/var/tmp
OSPatchRevChk linux 2.* i?86 {foo,bar} package linux-x86-pchk

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:

  • To reduce denial-of-service and scalability problems, all communication is initiated from parent to child. This means that all output retrieval must be made via polling, which is slow but immensely simplifies the security design.

  • Due to US export restrictions, the Web server interface is currently implemented as an HTTP daemon bound to, rather than HTTPS. With recent export-control relaxations, the option of upgrading to HTTPS will be investigated. Similarly, the core PST modules currently use freely exportable digital-signature algorithms and do not provide cryptosecrecy.

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:

  • Bruce is a tool that is meant to aid the upkeep and maintenance of existing integrity in an intranet.

  • Like all security software, Bruce cannot provide trustworthy results for a host that has already been compromised; however, this does not render it useless.

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.


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.


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 <>.












Secure Java Coding Web pages




?Need help? Use our Contacts page.
Last changed: 9 Dec. 1999 mc
Issue index
;login: index