Re: Usefulness of Network Intrusion Detection Systems

[Thomas <TheTom () UnixIsNot4Dummies ORG>]

Am Mi, 2004-05-26 um 02.40 schrieb Gary Flynn:
> 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,

Hello Gary.


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

I can agree partly here. Some systems are complex but handle
their layer, that's ok in my opinion.
The complexity of code is another problem...


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

... it's a software design/quality assurance problem.
I try to focus on a domain problem.


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

Yes but we can try to make it better just by avoiding
uncontrolled activism and concentrate our limited power
and time on the right targets. I am speeking as developer
here, partly as an admin.


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

Unsecure implementation and complexity is another problem.


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

Just because of this fact NIDS should not be made more complex
by going to the domain of hostbased intrusion detection by
analyzing network payload. :)


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

I dislike the feeling of relying on a "may stop" assurance.
There are simpler and more straight foward ways of protecting
against known exploits then applying an Intrusion Prevention System.


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

This time difference would really be appreciated. ;)


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

[..]

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

Your comments really gave me a broader view of what is needed
in widespread daily life. Thanks.

My mail was an appeal to NIDS developers. :)


Bye,
        Thomas








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

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