Re: Usefulness of Network Intrusion Detection Systems

From: James Fields (jvfields_at_tds.net)
Date: 05/28/04

  • Next message: Gary Halleen: "RE: IDS deployment on a Cat6500 series & which Snort box?" 
    To: <TheTom@UnixIsNot4Dummies.ORG>, <focus-ids@securityfocus.com>
Date: Thu, 27 May 2004 23:01:06 -0400

    I've read several of the replies and then your responses, and I guess I have
    to ask - What's the point?

    Who cares if you don't like to use NIDS for application inspection?

    That's what they're made for. If you don't like them, don't use them. Is
    there some reason you are trying to start a conversation about why they're
    all missing the boat?

    ----- Original Message -----
    From: "Thomas" <TheTom@UnixIsNot4Dummies.ORG>
    To: <focus-ids@securityfocus.com>
    Sent: Tuesday, May 25, 2004 8:20 AM
    Subject: Usefulness of Network Intrusion Detection Systems

    > 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.
    >
    > I recently had a discussion about the usefullness of
    > network-based IDSs.
    > In my opinion there is too much valueable effort wasted
    > in developing engines to keep track of network-traffic
    > collected via sniffing sensors for intrusion detection.
    >
    > Network-based IDSs should be limited to attacks on the
    > network layer not the application layer.
    > 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).
    > Maybe people are just doing it for fun or to suffice the
    > marketing hype... I do not know.
    >
    > 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?
    >
    > 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.
    >
    > 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!
    >
    > Sure everyone can do what s/he likes to do in his/her spare-time
    > but sometime it looks like uncontrolled activism. :)
    >
    > To avoid misunderstanding, I see the usefullness of NIDS in
    > protecting network components or to detect attacks on the
    > network layer, even for reasons of eForensic it is useful
    > (s. compromises of Debian(???) servers),
    > but everything else looks like a waste of time for me.
    >
    > Additionally companies do not care much about switches, routers
    > or web-servers. Sure they got bad PR if it is compromised or
    > turned off but there is no direct lost of money connected with it.
    > The direkt value lies in the data, plaintext emails on hard disks,
    > protocols about conference calls with co-companies, transactions
    > to suppliers, and so on.
    >
    >
    > Your comments are welcome!
    >
    > Bye,
    > Thomas
    >
    >
    >
    > --------------------------------------------------------------------------
    -
    >
    > --------------------------------------------------------------------------
    -
    >

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

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

  • Next message: Gary Halleen: "RE: IDS deployment on a Cat6500 series & which Snort box?"
    • Quantcast