Do you know how to read a pcap file continuously?

[David Edelman]

Carter,

I can't say that I have an immediate need for it, but I'd be happy to test
it.

--Dave

-----Original Message-----
From: argus-info-bounces+dedelman=iname.com at lists.andrew.cmu.edu
[mailto:argus-info-bounces+dedelman=iname.com at lists.andrew.cmu.edu] On
Behalf Of Carter Bullard
Sent: Friday, October 04, 2013 12:13 PM
To: el draco
Cc: Argus; jimr at highwire.stanford.edu
Subject: Re: [ARGUS] Do you know how to read a pcap file continuously?

I didn't hear anyone asking for this, is it still a request ????
I have it working and need some testing????

Carter


On Sep 19, 2013, at 3:05 PM, Carter Bullard <carter at qosient.com> wrote:

> Hey Sebas,
> OK, I need to handle the case where the file exists but is empty, and
> then I'll send it to whoever is interested.
> 
> I've got it such that argus can sit on the file, read packets in real time
> and provide socket access to the records that argus will generate.
> Basically the file is the packet source instead of the interface.
> 
> Send email if you're interested, and I'll send it out Friday????
> 
> Carter
> 
> On Sep 19, 2013, at 2:28 PM, el draco <eldraco at gmail.com> wrote:
> 
>> Hi list. Sorry for my late reply, I was traveling.
>> 
>> Carter: I would vote up for a simple approach, similar to what argus
>> does today. So people does not get confused with the new functionality
>> or
>> find out a different behavior.
>> - If the file is not there, exit with an error.
>> - If the file is there but empty, then just wait and continue.
>> - If the file is deleted during runtime, exit with an error.
>> 
>> This way we force the users to start argus again conscientiously when
>> they change the pcap file.
>> I'm not into the internals of argus, but I imagine that a problem that
>> could arise if argus does not exit when the file is deleted is that
>> the
>> internal state of the argus flows may be difficult to continue in the
>> new file. What if the new file has totally different packets?
> 
> So this is not an issue, as argus does the right thing.  Problems will
> occur, however, if the files are not presented to argus in the right time
order.
> 
>> 
>> I can test it as soon as you send it.
>> 
>> David and James: Thanks for your support. I didn't want to give too
>> much boring information before but I can tell you more. We are
>> managing a long-run malware capture facility. Long run means running
>> the malware (botnets in fact) for 1 or more months. However because of
>> university restrictions we are forced to use NATed networks devices on
>> the VirtualBox. That means that the only way to ONLY capture the
>> traffic of each vm is to have virtualbox capture the traffic for us.
>> That means using --nictrace
>> (https://www.virtualbox.org/wiki/Network_tips) to create a pcap file
>> with each guest traffic. Then, we can not run argus directly to
>> capture the guests flows.
>> Finally, the argus files are labeled with ralabel, but the pcap files
>> are needed to find out and verify those labels manually.
>> 
>> Hope it helps
>> sebas
>> 
>> On Thu, Sep 19, 2013 at 3:23 PM, James A. Robinson
>> <jimr at highwire.stanford.edu> wrote:
>>> I don't know the details, but the original poster stated that "We can
not
>>> change and use only argus, we need the pcaps".  I could easily imagine
>>> a social vs. technical problem with running argus, e.g., some person in
>>> charge has paperwork indicating that a pcap generating tool has been
>>> fully audited by their internal security group, and so they've decided
>>> that's the only packet capturing tool they will allow.
>>> 
>>> Jim
>>> 
>> 
> 

-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/pkcs7-signature
Size: 6283 bytes
Desc: not available
URL: <https://pairlist1.pair.net/pipermail/argus/attachments/20131004/55a0ee59/attachment.bin>