headers
David J Brumley | 1 Mar 2002 03:03
Picon

Re: hole in the argus archive on theorygroup.org


	
> 
> No problem..  I'm sorry that the mailing crap is changing 'all the
> time'.  I have no clue what's going on..  probably easier to just keep
> an eye on it, though I'll go do some bitching:-)..
> 
> I suppose there's some archive-posting delay?  On reload, I don't seen
> anything between 2/8-12 yet..

Hmm. I don't see anything received for that date to the address.  Can
you (and anyone else) forward any messages you have during that period
and I'll manually insert them?

-david

> 
> > -----Original Message-----
> > From: David J Brumley [mailto:dbrumley <at> rtfm.stanford.edu]
> > Sent: Thursday, February 28, 2002 2:37 AM
> > To: Mark Poepping
> > Subject: Re: hole in the argus archive on theorygroup.org
> > 
> > 
> > woohoo! it worked. Let me know if you still think there is a hole. I
> > found the old messages in the archiver's mbox and added them manually.
> > 
> > Thanks for keeping an eye on this. I really should be doing it, but
> > grad school is killing me :)
> >
(Continue reading)

Permalink | Reply | 0 comments |
headers
Mark Poepping | 1 Mar 2002 06:20
Picon
Favicon

RE: hole in the argus archive on theorygroup.org


Are you going to ship more than 8-900 Mbps so you'll need bonding?  Or
are you just planning ahead?  Do you know of a system that can ingest
that?  I guess that's what you want to find out..  We haven't tried
choking our fastest stuff yet..

We're doing everything on linux (2.4.16 right now), mostly because we're
lazy and it's been keeping up (using Carter's commercial code -
gargoyle, which kicks butt on the argus stuff by the way).

We have several GigE cards, seem to have the best luck with the
SysKonnect fiber, but have both generation Intel (the second gen were
*much better*, but we've had some issues with them as eth2) and some
3Com's too.  Had the 2-port SysKonnect for a while, but it seemed to be
designed more for redundancy than performance, so I shipped it back.  I
admit we haven't been too systematic about the analysis mostly lacking
money to create time for that diligence. 

There seems to be a fair disparity in the interrupt load of the various
cards, which isn't surprising, but I haven't had the time to look into
real counts (from /proc/net since netstat can't count too high).

We'd talked about trying to do some more benchmarking on performance
numbers, but it wasn't much of a priority in our conversations with
Carter, especially since it's pretty easy to catch up by splitting
flows..

Mark.

> -----Original Message-----
(Continue reading)

Permalink | Reply | 1 comment |
headers
Chas DiFatta | 1 Mar 2002 06:45

RE: hole in the argus archive on theorygroup.org

Peter,

Here is the configuration of 3 of our probe hosts at CMU.
Not much tweaking to get 400 Mb/sec out of them with
the commercial code of Argus.  We really haven't tried to
push the limit on them. We have some ideas on how to make
them fly, but remember, we're just interested in not dropping
anything from the core auditing effort whish is about 400 Mb/sec max.

So far we're not dropping anything and we have about 10-15%
of cpu left without much tweaking done.  One thing to note,
Argus and really fly when it doesn't have to write to disk.
I.e. interrupts become a problem on any system with disk writes.
What we do is just have the probes run Argus without writing to
disk and collect data from them via the network (port 561/tcp).
Therefore, we don't have to load the system with disk writes.
We're pretty much collecting the kitchen sink when it comes to
data, so on a 400 Mb/sec network, Argus outputs about
1.5 Mb/sec of audit data.  Not much when you consider the
amount of data you're auditing.  We could reduce this to
1 Mb/sec easily, and then some.

	...cd

p.s. On the "Turbo" zero copy packet capture code in Linux,
     I understand that it only helps when you're doing
     packet filtering to reduce coping in the kernel.
P.s.s. We'd like to play with a NetBSD box, since I hear the
     network code is very fast.  But it's not a priority since
     our probes are keeping up.  Time to concentrate on
(Continue reading)

Permalink | Reply | 3 comments |
headers
Peter Van Epp | 1 Mar 2002 17:45
Picon
Picon
Favicon

Re: hole in the argus archive on theorygroup.org

> 
> Peter,
> 
> Here is the configuration of 3 of our probe hosts at CMU.
> Not much tweaking to get 400 Mb/sec out of them with
> the commercial code of Argus.  We really haven't tried to
> push the limit on them. We have some ideas on how to make
> them fly, but remember, we're just interested in not dropping
> anything from the core auditing effort whish is about 400 Mb/sec max.

	At the end of the day thats all I have time for as well :-) The bottom
line is likely to be if I can buy something that will just work without me
doing all the interesting poking, money is going to be spent because we can
get capital money much more easily than staff resources. Thats why I have been
doing an eval on a commercial IDS system, the boss was hoping for a capital 
intensive silver bullet (but I don't think we found one).

> 
> So far we're not dropping anything and we have about 10-15%
> of cpu left without much tweaking done.  One thing to note,
> Argus and really fly when it doesn't have to write to disk.

	Thats good to know. I'm currently going to disk on the sensor machine
(and then copying to an analysis machine) looks like I need to modify that
idea.

> I.e. interrupts become a problem on any system with disk writes.
> What we do is just have the probes run Argus without writing to
> disk and collect data from them via the network (port 561/tcp).
> Therefore, we don't have to load the system with disk writes.
(Continue reading)

Permalink | Reply | 2 comments |
headers
Peter Van Epp | 1 Mar 2002 19:09
Picon
Picon
Favicon

Re: hole in the argus archive on theorygroup.org

> 
> 
> Are you going to ship more than 8-900 Mbps so you'll need bonding?  Or
> are you just planning ahead? 

	Just planning ahead. I need to upgrade my argus hosts for Gig, and as
long as I'm spending money I want to get as much as I can. Our commodity link
will be bandwith limited (or more correctly cost limited by the mechanism
of bandwith limiting :-)) and likely not a big problem (we won't be able to
afford a huge bandwith there). The link to C4/I2 is currently projected to be
a separate gig link (the cost of long haul GBICs may crimp that plan) with
no traffic shaping and an underlying OC48/OC192 backbone beyond it. There is
currently no traffic charge there and I expect it to be the potential challange.We could see a full speed
attack/misconfiguration there although I don't expect
that to be the norm. The worlds largest MP3 site is a possiblility (we are also
getting a 25 Tbyte network file store that will be on C4 (probably on is 
own gig link / fibre). We already see MP3 transfers on the current C3 link
to other Canadian university res nets (thank god our resnet is being 
outsourced!)

>				 Do you know of a system that can ingest
> that?  I guess that's what you want to find out..  We haven't tried
> choking our fastest stuff yet..

	Just from looking at hardware specs I expect finding a host to keep up
at this rate (let alone 10 gigE which we have offered to beta test for one
of the vendors :-)) is going to be exciting. Getting close to a gig we start
hitting both memory bandwith and I/O bandwith issues (without even considering
interrupt load on the CPUs). Given our client base (bright students with time
on their hands and access to C4) I expect we may see some attempts at filling
(Continue reading)

Permalink | Reply | 0 comments |
headers
Chas DiFatta | 1 Mar 2002 20:45

RE: hole in the argus archive on theorygroup.org

Peter Van Epp writes on March 01, 2002 8:46 AM:

>	Any sense that one of these works better than the others (I'm guessing
> #1 is probably the star :-))?

Correct, but #2 isn't bad, and we haven't done any detailed testing.

If I can remember from about 3 or 4 months ago, we configured
a dual processor system then ran two Argus processes, each were bound
to an GigE card and a processor.  It was interesting in the fact
that both processors had obviously 50% more headroom.  Again we
didn't push it much, because the real limitation was the GigE cards,
which we had 3com at the time.

I recommend that you don't skimp and purchase the Syskonnect cards.

	...cd

>-----Original Message-----
>From: Peter Van Epp [mailto:vanepp <at> sfu.ca]
>Sent: Friday, March 01, 2002 8:46 AM
>To: chas <at> difatta.org
>Cc: argus
>Subject: Re: hole in the argus archive on theorygroup.org
>
>
>>
>> Peter,
>>
>> Here is the configuration of 3 of our probe hosts at CMU.
(Continue reading)

Permalink | Reply | 1 comment |
headers
Mark Poepping | 1 Mar 2002 22:54
Picon
Favicon

RE: hole in the argus archive on theorygroup.org


We started with Intel because they have the NIC evaluation program where
it's cheap and easy to get two cards:
	http://inteleval.ententeweb.com/category.asp?categoryid=DESA

In the end, I figured we'd have to run specific accuracy tests on
whatever we get anyway, since I really don't trust any of this stuff:-)
and want to know whether I'm really getting all the packets.

Mark.

> -----Original Message-----
> From: owner-argus-info <at> lists.andrew.cmu.edu [mailto:owner-argus-
> info <at> lists.andrew.cmu.edu] On Behalf Of Chas DiFatta
> Sent: Friday, March 01, 2002 2:46 PM
> To: Peter Van Epp
> Cc: argus
> Subject: RE: hole in the argus archive on theorygroup.org
> 
> Peter Van Epp writes on March 01, 2002 8:46 AM:
> 
> >	Any sense that one of these works better than the others (I'm
> guessing
> > #1 is probably the star :-))?
> 
> Correct, but #2 isn't bad, and we haven't done any detailed testing.
> 
> If I can remember from about 3 or 4 months ago, we configured
> a dual processor system then ran two Argus processes, each were bound
> to an GigE card and a processor.  It was interesting in the fact
(Continue reading)

Permalink | Reply | 0 comments |
headers
Peter Van Epp | 5 Mar 2002 18:50
Picon
Picon
Favicon

Re: argus-2.0.5.beta.4.tar.gz available

> 
> Gentle People,
>    ftp://qosient.com/dev/argus-2.0/argus-2.0.5.beta.4.tar.gz 
> is now available for downloading and testing.  This fixes two
> nagging problems, native Cisco netflow record support in ra*
> programs, and a client problem with outfile renaming.
> 
>    Please give these a test, as I'd like to release 2.0.5
> sometime in the next week or so.
> 
> Thanks!!!!!
> 
> Carter
> 

	Well, other than using beta.5 rather than beta.4 all of FreeBSD 
4.5-RELEASE, OpenBSD 2.7 and NetBSD 1.5 compile (with complaints) and 
run and collect and display data which looks right on a brief test:

FreeBSD (and the other 2) complains about this:

gcc -O2 -I. -I../include -DHAVE_TCP_WRAPPER=1 -DHAVE_SYS_SOCKIO_H=1 -DHAVE_STRING_H=1
-DHAVE_FCNTL_H=1 -DHAVE_SYS_FILE_H=1 -DHAVE_SYSLOG_H=1 -DHAVE_ETHER_HOSTTON=1
-DHAVE_STRERROR=1 -DSTDC_HEADERS=1  -DARGUS_SYSLOG=1 -c ./argus_filter.c
In file included from ./argus_filter.c:113:
../include/argus_filter.h:113: warning: static declaration for `bpf_image' follows non-static

OpenBSD complains about an IPV6 redefinition (an ifdef __openBSD__ in 
compat.h would fix it I expect):
(Continue reading)

Permalink | Reply | 0 comments |
headers
soyoung | 12 Mar 2002 08:11
Picon

[Q] Any GUI tool with ARGUS ?

Hi All, I have one simple question..

I want to make some visual results with ARGUS output.
Is there any appropriate GUI framework for ARGUS output?

Thanks in advance.

SoYoung
Permalink | Reply | 0 comments |
headers
Christian Martin | 12 Mar 2002 12:57
Picon
Picon

argus-2.0.4 does after a couple of days

Hello, kind people,

I'm running argus 2.0.3 on a machine with a 2.4 Linux kernel.  There's a
fair amount of traffic on the network (argus is pumping out about 800Mb a
day, uncompressed), but it does the job admirably.  So far, so good.  I
recently upgraded to 2.0.4, which worked fine for a couple of days and then
fell over with no explanation.  It restarted fine, but the same thing always
happened - it would survive for anything between one and three days before
bombing out.  I've switched back to 2.0.3 and the problems have gone.
Unfortunately, the environment isn't really suited to debugging (the machine
is in a locked room some distance from my office, and there's so much
activity that logging over SSH would be a bit crazy).

I was wondering if anyone else has experienced problems of this nature, and
if there may be any way to get to the bottom of them without '-D 8'.  Both
2.0.3 and 2.0.4 were installed from the RPM because it was easiest at the
time.

Incidentally, for anyone who is thinking of trying it, I've been
successfully running ra (2.0.1) as a persistent daemon on a Linux (debian,
2.2 kernel) box for over six months now - it has written hundreds of
gigabytes of logs with seemingly no memory problems.

Many thanks in advance,

Christian Martin

--
Christian Martin
IT Department
(Continue reading)

Permalink | Reply | 1 comment |

Gmane