RE: session logging IDS

From: Paine, Steve (Steve.Paine_at_ish.com)
Date: 08/31/04

  • Next message: Andy Cuff: "Re: serial-line protocols" 
    To: focus-ids@securityfocus.com
Date: Tue, 31 Aug 2004 09:41:54 +0200

    Hi.

    Dave has some good points - content checking is not really the realm of IPS
    devices.

    Intruvert, (i'm checking our intruvert 4000 configuration options right
    now), can not capture a whole flow. Only the flow from 256 bytes before the
    attack packet - and up to the end.

    On any attack signature, you can also set the intruvert to capture 256 bytes
    of 'application data'prior to an attack packet and then you can capture the
    rest of the flow - defined in different ways:

    Capture N packets
    Capture until time
    Capture rest of flow.

    In theory I guess you could create a signature that triggers onthe first
    packet of, say, a specific FTP connection and capture the whole lot.

    Steve

    -----Original Message-----
    From: David W. Goodrum [mailto:dgoodrum@nfr.com]
    Sent: Tuesday, August 31, 2004 12:05 AM
    To: Raj Malhotra
    Cc: focus-ids@securityfocus.com
    Subject: Re: session logging IDS

    Hmmmm, I would like verification that either Cisco or Intrushield (or
    any other IDS/IPS) can actually capture an entire session from beginning
    to end, when the alert was triggered somewhere in the middle, and that
    they can do it all the time. Most Network IDS & IPS systems can capture
    the offending packet. Many can capture the offending packet, PLUS the
    rest of the session (which is what we at NFR do). I haven't seen any
    that can guarantee capturing the entire session from beginning to end,
    unless they were capturing EVERY session (regardless of whether
    something bad happened in that session). Here's an example:

    I login via ftp. I stay logged in for 10 minutes, browsing around,
    downloading some large benign files, but doing nothing bad. Then, I try
    to get /etc/password. Boom I trigger an alert. 10 minutes of packets
    are long gone... potentially many, MANY MegaBytes of data have passed
    during a single session. On a gigabit network, 10 minutes is an
    EXTREMELY long time. Unless your IDS or IPS is recording EVERY SINGLE
    packet for great lengths of time, to a hard disk somewhere, it will be
    all but impossible to go back in time and recreate the full session from
    beginning to end. Starting recording from triggertime is easy, and I
    believe a lot of IDS and IPS systems do this.

    Having said that, it IS possible to use some third party utility to do
    something similar to what you want, but even then there's still no
    guarantee: TCP sessions can stay open for hours and hours if necessary.
    For example, I can setup a box to do nothing but run tcpdump on the same
    wire I am doing IDS/IPS on, with a huge hard drive. Let's say a 128GB
    drive. If I'm monitoring a fully saturated 100Mbps, I will fill up that
    hard drive in just under 3 hours. I can easily keep a session open for
    3 hours before doing something... "bad". Plus, as network speeds
    increase, you will not be able to write your raw network data to that
    hard drive fast enough (or read it fast enough if alert rates are high.

    -dave

    David W. Goodrum
    Senior Systems Engineer
    NFR Security, Intrusion Detection & Prevention
    http://www.nfr.com

    Raj Malhotra wrote:

    >Hello all,
    >
    >We are evaluating available NIDS products which would work at 100 mbps
    >and would also do "session logging". By "session logging", we would
    >want the IDS to log the "entire session" and not just the session
    >"after" an intrusion is detected.
    >
    >We saw a couple of IDS which would probably be able to do something like
    this,
    >Cisco IDS
    >Intrushield
    >
    >Cisco offers session logging as well as replay.
    >Intrushield says something like "Highly customized capture of
    >individual packet, individual session, specific source/destination, or
    >entire traffic stream upon attack detection" which might be translated
    >as "logging of the session only after an attack has been detected".
    >
    >Can anyone tell us more about these or any such IDS that are available
    >which can log the entire session.
    > Also, has anyone used any of these and with what degree of success?
    >You can mail us back off the list if you so wish so.
    >
    >thanks
    >Raj
    >
    >

  • Next message: Andy Cuff: "Re: serial-line protocols"

    Relevant Pages

    • RE: session logging IDS
      ... > other IDS/IPS) can actually capture an entire session from beginning to ... I can't see how this could occur since packets are not stored. ... Subject: session logging IDS ... It would then be possible to arrange for an IDS ...
      (Focus-IDS)
    • Re: session logging IDS
      ... we definitely agree with david's and your observation that session ... logging is not the goal of an IDS. ... Subject: session logging IDS ... Most Network IDS & IPS systems can capture ...
      (Focus-IDS)
    • Re: session logging IDS
      ... Most Network IDS & IPS systems can capture ... Many can capture the offending packet, ... rest of the session. ... Unless your IDS or IPS is recording EVERY SINGLE ...
      (Focus-IDS)
    • Re: Workstation Name in IP Packet
      ... expanded a portion of a packet or expand all if I want to view detailed info. ... course you can do that for the whole capture, a range, or single line. ... > session http protocol section in an option ntlm negotiate packet I have ...
      (microsoft.public.win2000.networking)
    • RE: Use of Taps for IDS
      ... the "session" info - so we direct the packets based on the session ... So the first packet in a session is sent to Port 1 ... sent to the same IDS - so the IDS sees a single stream of data (with both ... Another thing worth mentioning is that we are about to start offering taps ...
      (Focus-IDS)