Building a Global IDS

A good Intrusion Detection System (IDS) is designed to not only warn of known attacks, but to second guess and stop unknown attacks. This is done by utilizing known signatures of existing attacks, and speculating on unseen or new intrusion techniques that have some of the same characteristics of their predecessors. Attacks like buffer overflow exploits all utilize the same basic method for gaining additional priveledges. An effective IDS will look for the basic method rather than unique strings characteristic of an attack on a specific binary of a specific operating system.

The nature of IDS brings about potential weak spots that take away from their overall strength. Once deployed and deemed operating correctly, an IDS may log dozens of attempts at intrusion and simply block them because they meet a certain profile of attack. If the administrator doesn't read these logs, they move on in life unaware of the attempts to break into their network. If these logged events are signatures of new and unseen attacks, they will stay that way. Unless the administrator notices and reports these new attacks to a full disclosure list or an appropriate vendor, the IDS has only lived up to a fraction of its intended purpose.

The Next Evolution

In order to make IDS systems more useful to the Internet at large, there must be more communication. IDS administrators, security auditors, IDS vendors, Operating System vendors and related parties must establish a more static method of communication. In talking, the ability to notice and prepare for previously unseen threats grows quickly.

As with any form of communication, a break down at any point hinders the process and the effectiveness is limited.

Building the Network

It would take a surprisingly small amount of resources to achieve the desired results. Using the cooperation of IDS administrators on a wide variety of networks, an effective network could be setup to monitor these attacks. If ten machines on each Class-B network were setup to do this, and more importantly shared those results with a central source, it would achieve the desired goal. In a more ideal situation, some one hundred machines on each Class-B could even further pinpoint and track new attacks. Obviously, the more machines looking for these signatures, the better chance there is of noticing them.

The beauty of this proposed network is that it is not vendor specific. Any IDS product could be used to monitor new activity and report it. Regardless of your preferred operating system, utilities, or IDS, your machine or network would be just as effective as the next. The only catch to this entire idea is who the information is reported to. Each IDS would want to be the primary contact for publicity and name recognition. However, the plan is not best suited for that. A neutral third party coordination center would be ideal, but bodies like CERT are often frowned upon by knowledgable security professionals. Creating a new body to handle this workload would be the best option, but that leads to more questions of who will run it, and more importantly who will fund it.

Perhaps this is the reason an idea such as this hasn't taken off. It has obvious technical merit in the form of existing technology being put to a specific use. No new or additional hardware or software would be required for those participating.

Practical Example

An associate of mine recently asked me if there were any new exploits on a specific port. This question is asked of me once a month by various friends or acquaintences. Each and every time it is based on them monitoring and unusually high amount of requests to specific ports. The last query was prompted by hundreds of connection attempts on a port that is basically unused. Probing systems ranged from educational institutions to cable modems to standard dialup ISP users.

While this specific example may not indicate a new bug, it is reminiscent of another incident much like this one. In June of 1998, CERT released an advisory outlining a new threat to some Internet hosts. Based on an unusual amount of connection attempts on port 1, security professionals were able to figure out that these probes were designed to seek out Irix systems. Default installations of Irix left port 1 (TCPMUX service/protocol) open for connections. While there was no vulnerability in this specific service, intruders were using it as a litmus test in seeking out Irix boxes. From there, they would try several well known default login/password combinations and often gain access to the machine. This is a perfect example of the potential inherent in this type of system.

Even more recently, a well known computer journalist found himself in the role proposed by this type of IDS. John Dvorak recently wrote an article about his observations after installing a new firewall that logged all connection attempts. Within a day of putting up his new defense, he had logged dozens of rogue connection attempts to his system. Imagine if a network of individuals like him were out there, all sharing these attempts with a central source. The results could be extremely beneficial.

Conclusion? Everyone Wins

By establishing better communication between more administrators and IDS vendors, it is possible to establish a world wide IDS capable of detecting new vulnerabilities in products being widely used. When vendors and responsible parties are discovering these new threats, pro-active security measures can be put in place. Customers paying money for these products begin to receive more secure software. Security auditors are able to protect their clients from more attacks and recognize more signatures. Confidence in product vendors rises dramatically.

Brian Martin (
Copyright 1999