Re: Usefulness of Network Intrusion Detection Systems

[Gary Flynn <flynngn () jmu edu>]

Thomas wrote:

> Hello everybody,
> I write this eMail to receive more valuable response
> about this issue. It is not meant as offense or as an act
> of arrogance.

Hi Thomas,

Some comments inline:

> IP spoofing, ARP cache poisoning and similiar attacks
> can only be detected by NIDSs but parsing and keeping
> track of application data sent over the network as well
> as the current execution path state of an application
> is too complex and too error prone (often proofed in the
> past).
One could use the same argument in various degrees about firewalls,
content switches,  load balancers,  proxies, anonymizers, etc.

To a large extent, those complexities, and the resultant mistakes
and vulnerabilities they cause, are present even in the hosts
implementing the applications themselves.

Different applications and protocols present different
difficulties. Well defined protocols and applications
can be simple to implement and monitor - on a host or
network device. Others not. Lets not throw the baby
out with the bath water.

Rarely in this world is anything perfect. As we build onto architectures
functionality never intended by the authors some kludgy but useful
things pop out.

> This behaviour is similiar to a hostbased IDS that tries
> to monitor SQL transactions by analyzing arguments to
> syscalls like read() and write().
> Looking at a system like this should just force one reaction
> from an educated person: "What is this stupid thing doing?
> It operates on a different layer not on the the more abstract
> application layer."
> Yes, developing such a system proofs the misguided mind of
> a developer.
> What does the HIDS know about roles in an SQL environment,
> what about transaction ACLs, what about table contents?

True enough. But if we look at the world as it is instead of how it
should be, we'd find many of those SQL based applications
unsecurely implemented. The HIDS and other products are just
reactions to that reality. If all our OS platforms and applications
were securely designed, implemented, and operated, we probably
wouldn't need much of anything security-wise on the network except,
as you said, network layer stuff for denial of service and bandwidth
control issues. That, unfortunately, is not the case and will not be
for the foreseeable future. While the HIDS/NIDS cannot accurately
interpret everything, at this point in time I believe there is enough
that they can interpret to make them useful though certainly not
infallible nor impenetrable.

> One argument I got was: "Having *one* NIDS at the right place
> helps to stop intrusions over the network. The admin doesn't
> need to update all machines constantly. If an attack is
> detected the IP will be blocked."
>
> Beside the fact that IP addresses can be spoofed and that the
> admin has to update the signature database too, the shellcode
> of "rm -rf / &" (or whatever) is still running even if the
> suspicious connection was interrupted.

You're forgetting that the IDP may stop the exploit attempting to
start that shellcode in the first place.

> So why not develop an easy to use online update service that
> works on the various Linux distributions as well as on other
> Unices or even Windows system?
> This update service can monitor the updates sites of the vendors
> regulary and may be controlled centrally. So, there is not much
> more work then administrating an node-based or sniffer-based NIDS.
> And now the network is even more secure!

That is being worked on. But patches don't solve all vulnerabilities
and as we've seen lately, the time between patch and exploit can be
zero or negative.

In the short time we've had them, our IDPs have stopped hundreds
if not thousands of attempted exploits of Internet Explorer users' clients
before patches were available. They've allowed us to block an Instant
Messenger worm within a couple hours of its discovery. Yes, you could
say not to run IE or disable scripting or deny instant messaging or make
users not click malicious links but that is not the world we live in. 
Especially
in a university environment where we basically have 15,000 home
computers on our network that we attempt to protect.

You also have to remember today's environment. The most common
platform out there is almost sure to be infected or cracked within
minutes of its being installed fresh from a brand new CD before patches
can be obtained. While border filters, desktop firewalls, and carefully
followed installation procedures can prevent this, the sheer number
of vulnerable platforms and non-technical users makes failure
almost inevitable.

Even when patches become available, the reality of testing and
distributing them in a timely manner is still challenging and will
likely be so for the foreseeable future.

An IDP, while not perfect, requiring its own maintenance, and
presenting its own vulnerabilities, is just one more imperfect tool
in the arsenal to help seal up the holey environment that currently
exists on the increasingly hostile Internet. Its difficult to defend
an environment with any technology where the underlying
infrastructure and society allows the equivalent of dropping bricks
off thousands of overpasses, throwing rocks through thousands of
store windows, and going down the street grabbing mail from
thousands of mailboxes with the click of a mouse, anonymously,
in seconds, from across the world.

Most of my comments pertain to IDP, not IDS. We had IDS for
quite a while and, while useful in gaining an understanding of the
threat environment, most times made me feel like a helpless
bystander watching the rape of a network and not being able
to do a thing about it. An IDP at least provides some limited
capabilities to mount some defense, imperfect though they may
be.

Gary Flynn
Security Engineer
James Madison University


---------------------------------------------------------------------------

---------------------------------------------------------------------------