RE: session logging IDS

From: Prabhat Singh (prabhat.singh_at_nevisnetworks.com)
Date: 09/15/04

  • Next message: Scott Wimer: "Re: IPS, alternative solutions" 
    Date: Wed, 15 Sep 2004 13:25:53 +0530
To: "Alex Butcher, ISC/ISYS" <Alex.Butcher@bristol.ac.uk>, "Murtland, Jerry" <MurtlandJ@Grangeinsurance.com>

    Hi,
    The second approach proposed by Alex enables capturing history from a
    point *before* alerts are generated.

    However, if an attacker opened a session and left it open for a long
    time before sending the malicious content. In this case, the previous
    packets will not be present in the buffer (assuming rollover of buffers
    happened before alert generation).

    Another approach could be to do the flow based logging of the packets.
    Keep last n packets (or n bytes of data) of the flows sent before the
    alert generation and all packets subsequent to alert generation :-).
    And, if the flow did not generate any alert then purge the captured data
    for that flow on the flow termination. The rollover problem exists in
    this approach too, but, it guarantees that at least previous n packets
    (or n bytes) of previously transferred data is present in the history
    :-).

    Cheers,

    -PRabhat

    -----Original Message-----
    From: Alex Butcher, ISC/ISYS [mailto:Alex.Butcher@bristol.ac.uk]
    Sent: Tuesday, September 14, 2004 3:11 PM
    To: Murtland, Jerry
    Cc: focus-ids@securityfocus.com
    Subject: RE: session logging IDS

    --On 13 September 2004 12:52 -0400 "Murtland, Jerry"
    <MurtlandJ@Grangeinsurance.com> wrote:

    > I'm more interested in tethereal and how you say it can go back per
    the
    > 'tag' keyword. I'd have to try it out to see how this works, but are
    you
    > saying you can go back and review packets previous from when the
    sniffer
    > was enabled?

    I proposed /two/ separate solutions.

    The first was to use Snort's 'tag' keyword, which will log all packets
    *following* the alert-generating packet from the source host or in the
    session for a admin-definable period *after* the alert is generated.

    The second solution was to build something around tethereal; arrange for

    tethereal to capture to a pair of ring buffer files, rotating every n
    minutes (tethereal can do this part out-of-the-box, for anyone who's not

    familiar with it). Then use Snort flexresp or something (maybe even a
    new
    output plugin) to send a signal to tethereal's controlling process (i.e.

    the part that needs to be written) which makes it kill the present
    tethereal process, preserve the current pair of ring buffer files (thus
    giving at at least n minutes and at most 2n minutes capture history) and

    have a new tethereal process capture to a new file until it receives a
    second signal from snort, it runs out of disc, or some time period
    expires
    according to taste. Easy enough to DIY, but there's nothing out there
    right
    now that does it (to my knowledge). This approach has the advantage of
    not
    needing too much disc space, but being able to provide a capture history

    from a point *before* alerts are generated.

    > Jerry J. Murtland

    Best Regards,
    Alex. 

    -- 
Alex Butcher: Security & Integrity, Personal Computer Systems Group
Information Systems and Computing             GPG Key ID: F9B27DC9
GPG Fingerprint: D62A DD83 A0B8 D174 49C4 2849 832D 6C72 F9B2 7DC9
------------------------------------------------------------------------
--
Test Your IDS
Is your IDS deployed correctly?
Find out quickly and easily by testing it with real-world attacks from
CORE IMPACT.
Go to http://www.securityfocus.com/sponsor/CoreSecurity_focus-ids_040708
to learn more.
------------------------------------------------------------------------
--
--------------------------------------------------------------------------
Test Your IDS
Is your IDS deployed correctly?
Find out quickly and easily by testing it with real-world attacks from CORE IMPACT.
Go to http://www.securityfocus.com/sponsor/CoreSecurity_focus-ids_040708 to learn more.
--------------------------------------------------------------------------
  • Next message: Scott Wimer: "Re: IPS, alternative solutions"

    Relevant Pages

    • Re: Code red variants?
      ... I noticed it because the alert was occuring on IP addresses in our range that are not currently in use. ... Snort logged a bunch of somewhat anomolous packets. ... This list is provided by the SecurityFocus ARIS analyzer service. ... and tracking system please see: http://aris.securityfocus.com ...
      (Incidents)
    • Re: Intrushield
      ... To view the captured packets ensure you change the check box in the alert ... modifying the rule. ... "I have yet to get the logging capability to work. ...
      (Focus-IDS)