XML support for Argus Data

[Kevin Houle]

Carter,

Perhaps you might consider working XML support into
Argus based on some of the work being done at the
CERT/CC with snort. See

  http://www.cert.org/kb/aircert/

In particular, the CERT/CC has defined an XML DTD
and incorporated it into a snort plugin to automate
intrusion detection reporting. It would be nice to
see Argus capable of being used with the AirCERT
project.

Regards,
Kevin

-----Original Message-----
From: owner-argus at lists.andrew.cmu.edu
[mailto:owner-argus at lists.andrew.cmu.edu]On Behalf Of Carter Bullard
Sent: Monday, October 09, 2000 3:17 PM
To: 'argus'
Subject: XML support for Argus Data


Gentle people,
   I am about to finish up an ArgusData -> XML argus client,
raxml(). This will eventually replace fullra.c as it generates
as detailed a data set as fullra() does, without the
english. (Sorry Rich V.  fullra() was a great idea!!!)
   If anyone has any XML experience and would like to
provide a style sheet or whatever, I will have an
ArgusData.dtd, ArgusData.xdr, ArgusData.xsd and sample
ArgusData.xml files tomorrow.
Thanks!!!!
Carter
Carter Bullard
QoSient, LLC
300 E. 56th Street, Suite 17A
New York, New York  10022
carter at qosient.com
Phone +1 212 813-9426
Fax   +1 212 813-9426
-----Original Message-----
From: owner-argus at lists.andrew.cmu.edu
[mailto:owner-argus at lists.andrew.cmu.edu]On Behalf Of Peter Van Epp
Sent: Monday, October 09, 2000 3:04 PM
To: argus
Subject: Re: Closing out Argus-2.0.0 feature set.


> Gentle people,
>    In preparation for a late October/early November
> release, I'd like to freeze the code for argus-2.0.0
> at the end of this week for new features.
>
>    Bug fixes will go on until the end of time, but
> new features can stop.  New client code as well as
> mods to existing client code can be considered until
> towards the end of the month, as it can be released
> as contrib code rather than core client code if it
> comes in in the last week of October.
>
>    I've decided to put user data capture into the
> next release, as we will not have sufficient time
> to get any clients for the feature.
>
>    This leaves RTP protocol support and multicast
> protocol support to be done this week.
>
>    I suspect that the true release date will be
> the end of November, but I'm going for early Nov
> if at all possible.
>
>    Comment/opinion/reaction/attitude is always
> welcome, so please do!
>
> Carter
>
> Carter Bullard
> QoSient, LLC
> 300 E. 56th Street, Suite 17A
> New York, New York  10022
>
> carter at qosient.com
> Phone +1 212 813-9426
> Fax   +1 212 813-9426
>
        One thing I've thought of but don't think we have discussed is
decode
of 803.1p an 1q tagged frames for vlans and QOS. We are using the 1p VLANs
internally and probably will be using them to replace the current MPOA over
ATM link on our link to the net. Is such support already there (I'd expect
it
needs to be for QOS support in future). We are talking about a wireless IP
phone pilot that will probably need 1Q as well.
        As well from a testing standpoint I managed to get tcpreplay
modified
to do full duplex (even if performance sucked probably because I used the
same file for both sides) on Friday. I figure on taking a page from the RISC
CPU guys book and tossing the timing issue back to a preprocessor which will
have to reorder the input tcpdump file to make sure that responses don't
get on the wire ahead of requests (by padding with none flow related packets
much like instruction reordering in a RISC CPU) when playing back at full
speed
rather than try and do that inside tcpreplay. I still need to get time sync
between the two files right (time 0 needs to start at the earliest time
stamp
in the two files) but that is a lot easier (since it is only once at
startup)
than trying to figure out interpacket timeing as the files unroll. The
upshot
of that is I have at least the tools for full duplex testing (but I think
time
is going to get sucked down performance testing on hardware for the next
little
while).
        From bonnie disk I/O benchmarks (confirmed mostly by iozone although
I didn't have time to complete that) I ran on Friday it currently appears
that
IDE disks are twice as fast (~20 megabyte per second) than SCSI (~11 megs).
But I have the loan of some 10,000 RPM 36 gig SCSI drives and I'll see what
that does.  I think Carter may be correct that the GX vs BX chipset on the
motherboard is the secret, but I won't know until I borrow an Adaptec 2940
SCSI controller to move between the machines hopefully next week.  Then
there
are raid controllers ...  I also understand from the Beowolf community that
there is a Supremicro mother board with a non Intel glue chipset that kicks
both the GX and BX's ass. I'll have to see about borrowing or buying one of
those too.
        Then there is a request from linux.sccurity.com about whether I'd
like
to write them an article on why argus is a wonderful idea after someone in
comp.unix.security asked about experiences with argus.
        So many questions so little time :-).
Peter Van Epp / Operations and Technical Support
Simon Fraser University, Burnaby, B.C. Canada