Lee, Most IDS's use PCAP to log packets to disk. This can cause a fundamental problem when the box has a high load pushed at it. You can either miss packet logging due the IO not being able to keep up with the streams, frames lost as the box cannot buffer enough to keep up, the disk becoming full, or just the meltdown of the box. A nice way to do this for forensics is to log based on multiple criteria such as srcip, destip, port, attack, etc. The problem of a PCAP core of most IDSes is that they either log everything to disk or nothing. The only IDS I've used that can log only flows that you care about to disk and give you an easy method of viewing/exporting them for forensic purposes is the Netscreen IDP, since they use a flow based system just like a firewall. I'm not sure about the other very high end 100M/1GB+ line rate IDSes out there, so I can't tell you if they do it. -dave On Fri, Jan 24, 2003 at 10:57:45AM -0500, Kelly, Lee wrote: > RealSecure has the capability to capture the packets, the issue is it > typically exponentially grows the size of the database. Thus you are > required to purge, or offload, more frequently. Not sure about netprowler. > > Thank You, > > Lee Kelly, CISSP > Manager, Assessment Services > Fortrex Technologies, Inc. > 1-877-367-8739 (Office) > 240-994-6786 (Cell) > > -----Original Message----- > From: H C [mailto:keydet89at_private] > Sent: Friday, January 24, 2003 10:34 > To: forensicsat_private > Subject: IDS and forensics > > I'm interested in other's views of network IDS systems > when looking at incident response and forensics > activities. > > This comes up from my hands-on dealings w/ IDSs like > RealSecure and NetProwler. These systems provide > alerts, but don't keep the actual packets that > initiate the alerts. I've done some research w/ > NetProwler specifically, and haven't been able to find > any explicit definition or descriptions of the alerts. > So I'll see an alert for "MS RPC portmapper small > packets", but I have no way of determining what > "small" is...and since we do a lot of DCOM on that > subnet, I'd really like to see what the actual > contents of the packet are...but can't through > NetProwler. I know I could load up snort or tcpdump, > and do captures that way, but Symantec recently > announced that it's no longer supporting NetProwler, > so... > > About a year ago I was working w/ RealSecure and had > the same issues...couldn't see what the packet > contents were, nor could I see what the actual details > of the filter were. On top of that, the ability to > create user-defined filters is extremely limited. > > What this leads to is the question of how useful such > systems are in the face of network forensics. If the > packet contents themselves aren't saved in some way, > but only used to trigger an alert, then how suitable > are such systems for forensics? To take a step back, > if the signatures themselves aren't viewable, and only > the alert, then how does the admin *really* determine > what happened? In most cases, they'd be at the mercy > of whatever info the IDS console provides. > > Thoughts? > > Carv > > __________________________________________________ > Do you Yahoo!? > Yahoo! Mail Plus - Powerful. Affordable. Sign up now. > http://mailplus.yahoo.com > > ----------------------------------------------------------------- > This list is provided by the SecurityFocus ARIS analyzer service. > For more information on this free incident handling, management > and tracking system please see: http://aris.securityfocus.com > > > > > .. > . > > ----------------------------------------------------------------- > This list is provided by the SecurityFocus ARIS analyzer service. > For more information on this free incident handling, management > and tracking system please see: http://aris.securityfocus.com > ----------------------------------------------------------------- This list is provided by the SecurityFocus ARIS analyzer service. For more information on this free incident handling, management and tracking system please see: http://aris.securityfocus.com
This archive was generated by hypermail 2b30 : Fri Jan 24 2003 - 14:41:41 PST