RE: session logging IDS

["Prabhat Singh" <prabhat.singh () nevisnetworks 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.
--------------------------------------------------------------------------