From: Remad (listaggy@remad.net)
Date: Tue Aug 29 2006 - 16:24:12 EDT
As long as your network isn't send large amounts of traffic and your ruleset
is fairly well tuned it should be to bad. I'm used to dealing with larger
amounts of traffic so my logs would be pretty crazy if I tried to log packet
data. I would look at doing a test run and using that to determine how much
storage you would need and if it would cause a packet loss issue.
If you are looking at just specific rules/types of data, it might now be too
bad. I've just seen to many people turn on something like tcpdump and try
to capture everything. It quickly gets overwhelming and reduces your
effectiveness vice improving it. If you have a couple of areas that you are
concerned about then I would really look a doing some sort of capture.
,Remad
-----Original Message-----
From: xelerated [mailto:xelerated@gmail.com]
Sent: Tuesday, August 29, 2006 1:28 PM
To: Remad
Cc: pen-test@securityfocus.com
Subject: Re: Packet Payload
I should mention my only experience with this type of scenario was on a mid
size business network, using snort, the snort payload didnt take up nearly
as much space as i thought it would, i built the machines with 40gig drives
each, and would dump the database to an archive and store it on tape every
couple of months or so.
But i like you idea of just certain types of data. Now to just figure out
which types are best to hold on to. Honestly, I wouldnt care if the logs
were purged weekly or something, anything is better than what I have now.
On 8/29/06, Remad <listaggy@remad.net> wrote:
> I hope your company has lots of money for a SAN. I wouldn't recommend
> capturing payloads without a good reason. It will eat diskspace big time.
> I would turn it on when you see something that you need the data for.
>
> Another choice would be to build tcpdump filter to collect payload
> data for specific types of data. Might not get everything but 10TB of
> data isn't something you are going to find any useful info in anyways.
>
> ,Remad
>
> -----Original Message-----
> From: xelerated [mailto:xelerated@gmail.com]
> Sent: Tuesday, August 29, 2006 9:32 AM
> To: pen-test@securityfocus.com
> Subject: Packet Payload
>
> Im posrting this to the pen-test group, rather than firewall or IDS
> because it covers many areas.
>
> Id like to see what the pro's think about capturing and storing packet
> payloads from firewalls, ids, etc... everything rather than just
> loggin the incidents.
>
> Im trying to explain to my management how useful the payloads could be
> if we were ever to really need them, say from a forensics point of view.
> To give another example, one time I was seeing lots of firewall drops,
> I could tell what ports, src and dest. but no packet data. To everyone
> involved it looked like a worm trying to spread.
> Well in the end it wasnt, infact is was something that was nice to
> know about, but it was not hostile traffic. But if I had been able to
> see the payloads i could have seen the data request and known from the
> start what it was, or was not.
>
> What would be really great, is a whitepaper covering this, or enough
> info/facts that I could throw one together.
>
> thanks!
> Chris
>
> C|EH, CISSP
>
> ----------------------------------------------------------------------
> --
> This List Sponsored by: Cenzic
>
> Need to secure your web apps?
> Cenzic Hailstorm finds vulnerabilities fast.
> Click the link to buy it, try it or download Hailstorm for FREE.
> http://www.cenzic.com/products_services/download_hailstorm.php
> ----------------------------------------------------------------------
> --
>
>
>
>
------------------------------------------------------------------------
This List Sponsored by: Cenzic
Need to secure your web apps?
Cenzic Hailstorm finds vulnerabilities fast.
Click the link to buy it, try it or download Hailstorm for FREE.
http://www.cenzic.com/products_services/download_hailstorm.php
------------------------------------------------------------------------
This archive was generated by hypermail 2.1.7 : Sat Apr 12 2008 - 10:56:52 EDT