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 privileges. 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
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.
- IDS Administrators: Monitor logs more closely. Unknown attacks or probes
should be reported and shared.
- Security Auditors: Take note of common attacks while auditing client
networks. Look for trends in their logs that indicate a new attack on
- IDS Vendors: Take in customer reports of suspicious activity. Report
these attempts to the appropriate software vendors. They will be much more
recipient to high profile IDS companies reporting the potential bugs.
- OS Vendors: Communicate with IDS vendors and respond quickly to
potential threats. Patch holes quickly and release vendor fixes to combat
the problems before they are widely exploited.
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 knowledgeable
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.
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 acquaintances. 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
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 (email@example.com)