headers
Russell Fulton | 1 Mar 01:39
Picon
Picon
Favicon

filters specified in config file ignored by rc39

Hi Folks,

Would someone else test this to make sure I'm not pissing into the wind
again :)

I recently transferred the filter specs from the command line, first to
the output file spec and then to the filter variable in the config
file.  Neither seemed to work.  Putting the filter back on the command
line worked as expected.

BTW  I assume it is more effective to specify the filter globally rather
than on the output file if there is just one output file.

Russell
Permalink | Reply | 2 comments |
headers
Russell Fulton | 1 Mar 02:20
Picon
Picon
Favicon

Re: filters specified in config file ignored by rc39


Russell Fulton wrote:
> Hi Folks,
>
> Would someone else test this to make sure I'm not pissing into the wind
> again :)
>
> I recently transferred the filter specs from the command line, first to
> the output file spec and then to the filter variable in the config
> file.  Neither seemed to work.  Putting the filter back on the command
> line worked as expected.
>
> BTW  I assume it is more effective to specify the filter globally rather
> than on the output file if there is just one output file.
>
>   

Hmmm... trap for the unwary :)  filter "tcp and dst port 80"  means
something rather different to ra and argus!  I took me about half an
hour to figure out why argus was seeing traffic in just one direction
after I applied this filter.    I've got so used to using filters with
ra where the filter applies to *flows* that I simply assumed that argus
filters would behave the same.  They don't they behave just like tcpdump
filters ( i.e. they are packet filters).

Carter, am I correct in assuming that the output filters associated with
an output file are flow filters not packet filters?

And this answers my original question about when to use the argus_filter
and when to use the filter option of the output file.
(Continue reading)

Permalink | Reply | 1 comment |
headers
carter | 1 Mar 13:20

Re: filters specified in config file ignored by rc39

Hey Russell,
You are absolutely correct!!!  The input filter for argus is a libpcap filter, and so its a packet filter.  All
other filters are flow filters.

Carter


Carter Bullard
QoSient LLC
150 E. 57th Street Suite 12D
New York, New York 10022
+1 212 588-9133 Phone
+1 212 588-9134 Fax  

-----Original Message-----
From: Russell Fulton <r.fulton <at> auckland.ac.nz>
Date: Thu, 01 Mar 2007 14:20:14 
To:Russell Fulton <r.fulton <at> auckland.ac.nz>
Cc:argus-info <at> lists.andrew.cmu.edu
Subject: Re: [ARGUS] filters specified in config file ignored by rc39



Russell Fulton wrote:
> Hi Folks,
>
> Would someone else test this to make sure I'm not pissing into the wind
> again :)
>
> I recently transferred the filter specs from the command line, first to
(Continue reading)

Permalink | Reply | 0 comments |
headers
Christoph Badura | 1 Mar 23:29
Picon
Favicon
Gravatar

more bugs

Hey Carter,

here are more notes about documentation bugs in ra(1) that I jotted down
last week. They applied to rc.39.

I also noticed with rc.40 that argus dumps core when told to read non-existing
file:
nervous-energy!bad 103 % argus -RJ -r non-existing -w /dev/null
argus[6034]: 01 Mar 07 23:11:49.537703 started

Segmentation fault (core dumped)
nervous-energy!bad 104 % 

from rc.39:
ra(1)

- man page talks about non-existing audit(8) in the NAME section.

- description of -n is wrong:

have no /etc/ra.conf nor ~/.rarc

no -n no hostname lookups done
-n suppresses port number conversion
-nn suppresses protocol number conversion
-nnn enables full translation except hostname lookup for first tcp record
-nnnn same as -n
I guess the compiled-in default changed.
but arp IP addresses are never looked up contrary to documentation
(Continue reading)

Permalink | Reply | 1 comment |
headers
Christoph Badura | 2 Mar 00:39
Picon
Favicon
Gravatar

how to aggregate multiple similar tcp flows?

So, I'm trying to use racluster to aggregate multiple similar TCP flows.

$ racluster -n -s +sloss +dloss -r trace.argus dst port 22
...
   14:27:04.225239    d        tcp      1.2.3.4.38501     ->        4.3.2.1.22         3776     7319       257536     11002749   FIN          0          1
   14:27:24.618657             tcp      1.2.3.4.38586     ->        4.3.2.1.22         3770     7324       257224     11001631   FIN          0          0
   14:27:43.040418             tcp      1.2.3.4.38588     ->        4.3.2.1.22         3767     7321       256834     11001433   FIN          0          0
   14:28:26.545754    d        tcp      1.2.3.4.38615     ->        4.3.2.1.22         7508     3841     11195264       262685   FIN          0          1
...

So clearly we have some packet loss.

$ racluster -n -s +sloss +dloss -r trace7s.argus -m saddr daddr dport - dst port 22
   14:25:35.871261              ip      1.2.3.4          <->        4.3.2.1           71124    85030     57813728    100321378   CON          0          0
$ racluster -n -s +sloss +dloss -r trace7s.argus -m saddr daddr dport - tcp and dst port 22
   14:25:35.871261              ip      1.2.3.4          <->        4.3.2.1           71124    85030     57813728    100321378   CON          0          0
$ racluster -n -s +sloss +dloss -r trace7s.argus -m saddr daddr dport - 
   14:25:35.871261              ip      1.2.3.4          <->        4.3.2.1           71124    85030     57813728    100321378   CON          0          0
$ 

So it doesn't want to treat the aggregated records as TCP flows, I think.
Why wouldn't it, though?  I told it that only sadd, daddr and dport matter
and they are the same for these aggregation objects in all records in the
trace.

Hmm...

$ racluster -n -s +sloss +dloss -r trace7s.argus -m saddr daddr dport proto -
   14:25:35.871261    d        tcp      1.2.3.4.0         ->        4.3.2.1.22        71124    85030     57813728    100321378   FIN          0          2
$
(Continue reading)

Permalink | Reply | 5 comments |
headers
carter | 2 Mar 01:16

Re: more bugs

Hey Christoph,
Thanks, and I'll fix this one tonight with the other bugs/issues/problems/gotcha's.

Carter

Carter Bullard
QoSient LLC
150 E. 57th Street Suite 12D
New York, New York 10022
+1 212 588-9133 Phone
+1 212 588-9134 Fax  

-----Original Message-----
From: Christoph Badura <bad <at> bsd.de>
Date: Thu, 1 Mar 2007 23:29:00 
To:argus-info <argus-info <at> lists.andrew.cmu.edu>
Subject: [ARGUS] more bugs

Hey Carter,

here are more notes about documentation bugs in ra(1) that I jotted down
last week. They applied to rc.39.

I also noticed with rc.40 that argus dumps core when told to read non-existing
file:
nervous-energy!bad 103 % argus -RJ -r non-existing -w /dev/null
argus[6034]: 01 Mar 07 23:11:49.537703 started

Segmentation fault (core dumped)
nervous-energy!bad 104 %
(Continue reading)

Permalink | Reply | 0 comments |
headers
Scott A. McIntyre | 3 Mar 12:35

I must be going blind -- ramon?

Hi,

I've been so busy using just the basic ra3 utilities that when I went to
invoke my previously beloved "ramon" to do a -M Svc I was surprised to
see it was no longer in my $path (other than the ra2 version).

Sadly, a recent email server migration for me meant that a lot of my
argus-info mail was vorped into the Ether and I can't see what the
previous discussion has been on this utility.

What is the current best way to get a report like:

ramon -nn -L0  -M svc -r filename - | head -25

Sorry for the braindeadedness of the question!

Scott
Permalink | Reply | 2 comments |
headers
Russell Fulton | 3 Mar 19:57
Picon
Picon
Favicon

Re: I must be going blind -- ramon?

Scott,

You may be getting old(er?) but you are not going blind:)

ramon functionality is now built into racluster -- see the man page.
racluster -h is *not* helpful, it seems to be the same as ra.

Russell.

Scott A. McIntyre wrote:
> Hi,
>
> I've been so busy using just the basic ra3 utilities that when I went to
> invoke my previously beloved "ramon" to do a -M Svc I was surprised to
> see it was no longer in my $path (other than the ra2 version).
>
> Sadly, a recent email server migration for me meant that a lot of my
> argus-info mail was vorped into the Ether and I can't see what the
> previous discussion has been on this utility.
>
> What is the current best way to get a report like:
>
> ramon -nn -L0  -M svc -r filename - | head -25
>
> Sorry for the braindeadedness of the question!
>
> Scott
>
>
>
(Continue reading)

Permalink | Reply | 0 comments |
headers
carter | 4 Mar 19:47

Re: I must be going blind -- ramon?

Hey Scott,
The "-M svc" option may not be there, and if you don't get the output you expect, send mail!!!   You should be
able to accomplish what you want with:

    racluster -M rmon -m proto sport -r file -w - - tcp or udp | ra -N  25 -s proto sport spkts dpkts sbytes dbytes

Carter

(The only issue is whether racluster sorts the way you want, pkts bytes whatever)



Carter Bullard
QoSient LLC
150 E. 57th Street Suite 12D
New York, New York 10022
+1 212 588-9133 Phone
+1 212 588-9134 Fax  

-----Original Message-----
From: "Scott A. McIntyre" <scott <at> xs4all.net>
Date: Sat, 03 Mar 2007 12:35:55 
To:Argus <argus-info <at> lists.andrew.cmu.edu>
Subject: [ARGUS] I must be going blind -- ramon?

Hi,

I've been so busy using just the basic ra3 utilities that when I went to
invoke my previously beloved "ramon" to do a -M Svc I was surprised to
see it was no longer in my $path (other than the ra2 version).
(Continue reading)

Permalink | Reply | 0 comments |
headers
Schilling, Timo | 5 Mar 15:03
Picon

Argus & Cisco Netflow

Hi there,

I tried to read Cisco-NetFlow-Data from port 9995 with the ra-tool. On first server we have nProbe-
respective fprobe-daemon. 
With ra I get nothing. Either an error-message nor the data I search for. When I start tcpdump, the packets
arrive at port 9995, it seems that the daemon works correctly.

I tried to start listening with the following commands:

server> /usr/sbin/fprobe -ieth1 -fip -n5 10.10.10.2:9995
client> ra -CP 10.10.10.1:9995
I also tried radium with the same options, but this command only sets up a binary-file with the size of 4kb, always.

We use argus in version: 3.0.0.rc.34

After reading the mailinglist I tried to get some more information with "-D 12" but ra was as quiet as ever....

Hope someone could help me, 
bye

Timo Schilling

------------------------------------
Danet GmbH, Gutenbergstraße 10, 64331 Weiterstadt, Germany
Phone: +49 6151 868-610, Fax: +49 6151 868-980
eMail: timo.schilling <at> danet.de, URL: www.danet.com

Managing Board: Dr. Reiner Nickel (CEO), Dr. Burkhard Austermühl (CFO)
Chairman of the Supervisory Board: Jaques Bentz Address of Record: Weiterstadt
Commercial Register: Amtsgericht Darmstadt HRB 6450 - Tax Number: DE 172 993 071
(Continue reading)

Permalink | Reply | 2 comments |

Gmane