headers
Carter Bullard | 1 Jun 1999 14:54

argus 1.8 suggestions list

Gentle People,
   I'm finishing up on the 1.8 changes, and there
have been a number of suggestions for changes in 
some of the programs and utilities.  I would like
to get a feel for what the wish list would look
like.  If you would like to alpha/beta test 1.8
please send me mail.

   Here is the list as I have it today.  Most are
related to ra().  I know that this is not complete
so if there is anything missing, please send mail.
Any suggestion is welcome.

   Argus()
     1. read compress and gzip'd files automatically.

   Ra() (all argus clients)
     1. extend filter expression.
          I've already added new tokens for:
             1. TCP states (syn synack data fin finack)
             2. ICMP types (echo unreach redirect)

          I'm looking into supporting 'greater' and 'less'
          for port numbers. 

     2. reverse '-n' flag logic.
          use the -n to turn on name resolution,
          default is no resolution.

     2. modify and internationalize default time output.
(Continue reading)

Permalink | Reply | 0 comments |
headers
Carter Bullard | 1 Jun 1999 13:45

Re: ARGUS

Hey Peter,
   Thanks for the Perl script.  Is it OK to put
it in the contrib section of the 1.8 tar file?

   I have fixed the known TCP byte reporting
problems in 1.8.  I do emphasis the "known" part,
and so we'll see how long this statement lasts.

Hope all is well,

Carter

-----Original Message-----
From: Peter Van Epp [mailto:vanepp <at> sfu.ca]
Sent: Friday, May 28, 1999 6:53 PM
To: argus <at> lists.andrew.cmu.edu
Subject: Re: ARGUS

> 
> 
> 
> There are no summary stats in any of the clients in 1.7,
> but there is some provision for this in the upcoming 1.8.
> Stay tuned.
> mark.

	Til then here is a quick and dirty perl script which takes output from
ra as in 

ra -r argus.log -c -n | argus.pl >logfile
(Continue reading)

Permalink | Reply | 0 comments |
headers
Carter Bullard | 1 Jun 1999 17:50

RE: argus 1.8 suggestions list

Hey Alex,
   Absolutely no problem, and I'll send 1.8 either today
or tomorrow.  We already support the 'net' keyword, so
you can say statements like:

   ra -nr filename src net 128.64

so that may satify your needs.
Thanks for the mail and remind me to send 1.8 if I
forget in the next day or so.

Carter

Carter Bullard
Principal Consultant
Nortel Networks
320 Park Avenue  16th Floor
New York, New York 10022
Email  cbullard <at> nortelnetworks.com
Phone +1 212 317 4230
Fax   +1 212 317 4324
Pager +1 800 217-7496

-----Original Message-----
From: Alexander Bochmann [mailto:bochmann <at> mupfel.infra.de]
Sent: Tuesday, June 01, 1999 10:31 AM
To: Carter Bullard
Subject: Re: argus 1.8 suggestions list

Hi,
(Continue reading)

Permalink | Reply | 1 comment |
headers
Alexander Bochmann | 1 Jun 1999 18:06
Picon

Re: argus 1.8 suggestions list

Hi,

...on Tue, Jun 01, 1999 at 11:50:30AM -0400, Carter Bullard wrote:

 > or tomorrow.  We already support the 'net' keyword, so
 > you can say statements like:
 >    ra -nr filename src net 128.64
 > so that may satify your needs.

Actually, I was thinking of smaller aggregations... At the place where I 
work, we have lots of small subnets (with for example /28 oder /30 prefixes) 
on our LAN, and I don't know whether there is an easy way to tell ra 
to report data just for a subnet a la 172.10.203.200/255.255.255.248...

It's no problem to specify 2 or 6 hosts directly with host xxx or host yyy 
etc., but then it gets annoying...

A. Bochmann

--

-- 
AB54-RIPE * http://users.infra.de/~bochmann/
Permalink | Reply | 0 comments |
headers
Carter Bullard | 1 Jun 1999 20:49

RE: argus 1.8 suggestions list

Ahhhhh,
   So you want CIDR address support.  You would want to
be able to specify:

    xxx.yyy.zzz.www/nn

where nn is the number of bits in the mask.  Hmmmm, that
is a bit of a challenge, but not an impossibility, given
the yacc and lex code that we currently have.  I'll see
what I can do.

Carter

-----Original Message-----
From: Alexander Bochmann [mailto:bochmann <at> mupfel.infra.de]
Sent: Tuesday, June 01, 1999 12:07 PM
To: Carter Bullard
Cc: 'argus <at> lists.andrew.cmu.edu'
Subject: Re: argus 1.8 suggestions list

Hi,

...on Tue, Jun 01, 1999 at 11:50:30AM -0400, Carter Bullard wrote:

 > or tomorrow.  We already support the 'net' keyword, so
 > you can say statements like:
 >    ra -nr filename src net 128.64
 > so that may satify your needs.

Actually, I was thinking of smaller aggregations... At the place where I
(Continue reading)

Permalink | Reply | 0 comments |
headers
Carter Bullard | 14 Jun 1999 17:45

RE: ra seg fault on 1.8 beta code

Hey Peter,
   Found the problem.  Bad index number for array of strings.
The complete fix is a little more than this, but if you make
this patch, then things will work much better until I get
the next set of fixes ready.

Here's the diff.

./common/argus_util.c
384c384
<       processStr = process_state_strings[8];
---
>       processStr = process_state_strings[4];

Hope this helps and thanks!!!!

Carter

-----Original Message-----
From: Peter Van Epp [mailto:vanepp <at> sfu.ca]
Sent: Friday, June 11, 1999 5:25 PM
To: argus <at> sei.cmu.edu
Subject: ra seg fault on 1.8 beta code

	Ra is seg faulting (probably because of bad fragmentation from where
it is) on an argus capture file. However gdb isn't thinking it wants to let
me look at any of the variables after the seg fault and the capture file is
a little large (138 megs uncompressed) to send to you. Can you suggest a way
to either extract a piece of the capture file or display something from the 
ra seg fault under gdb that would be useful to you?
(Continue reading)

Permalink | Reply | 0 comments |
headers
Carter Bullard | 21 Jun 1999 14:42

RE: argus 1.8 suggestions list

Hey Alex,
   No release yet for Argus-1.8.  Would you like
to try what we have to date?  All code fixes, no
documentation yet.

Carter

-----Original Message-----
From: Alexander Bochmann [mailto:bochmann <at> infra.de]
Sent: Saturday, June 19, 1999 6:15 PM
To: Carter Bullard
Subject: Re: argus 1.8 suggestions list

Hi,

...on Tue, Jun 01, 1999 at 08:54:29AM -0400, Carter Bullard wrote:

 >    I'm finishing up on the 1.8 changes, and there

Was the 1.8 beta already released? I didn't get any mail on the list this 
week, so if there was an announcement I probably missed it...

cu,

Alex.
Permalink | Reply | 3 comments |
headers
Russell Fulton | 24 Jun 1999 01:10
Picon
Picon
Favicon

ra output intrepretation

Greetings All,
	     I run two argus servers, one in detail mode and one not.
(To be complete the one in detail mode is 1.7be and the other one
is 1.8 code).

The data here comes from the port scan of a machine (130.216.85.131)
that should be invisible (except for pings) from the outside.  I will
present data for one connection from both logs and would like an
explaination of what it actually means.  I am confused (if that isn't
already appearent ;-)

First data from server in detail mode:

argus <at> k-meter argus]$ grep '\.80 ' june/139.80.75.71 
Wed 06/23 16:03:09     icmp    xxx.yy.75.71        ->  130.216.85.131       1      0                          ECO
Wed 06/23 16:03:09     icmp    xxx.yy.75.71       <->  130.216.85.131       1      1                          ECO
Wed 06/23 16:03:24      tcp    xxx.yy.75.71.41325 <?>  130.216.85.131.80    1      0       0         0        EST
Wed 06/23 16:03:24      tcp    xxx.yy.75.71.41325 <|   130.216.85.131.80    0      1       0         0        RST

the same session reported by the other server was:

Wed 06/23 16:03:09     icmp    xxx.yy.75.71       <->  130.216.85.131       1      1                          ECO
Wed 06/23 16:03:24      tcp    xxx.yy.75.71.41325 <|   130.216.85.131.80    1      1       0         0        RST

This caught my eye because traffic to that address should be blocked
at our packet filter (the argus machines are outside the packet
filter).

These are the first packets of the scan i.e. a ping followed by a tcp
packet to port 80.  These were followed by a normal port scan with
(Continue reading)

Permalink | Reply | 0 comments |
headers
Carter Bullard | 24 Jun 1999 14:48

RE: ra output intrepretation

Hey Russell,
   The detail and the non-detail argi are consistent
in their reporting, a ping volley and then a TCP
packet with a reset.  It should be impossible for the
probe to react packets that it promiscuously reads,
as these packets don't go to the communication stacks,
so lets eliminate that up front.

   I believe that you are seeing connectivity between
these two machines, on both ICMP and TCP protocols.
Since the "hidden" machine's responses are what would
be predicted by protocol, there isn't any evidence
to suggest that you shouldn't trust the argi() data.
And since you see evidence on two independent protocols,
the best conclusion is that the filter scheme is
inappropriate for the policy.

   If this really beings to bug you and you want to
dig further, I would recommend two additional things
that I would look at to additionally validate this
conclusion.  Use the -g option on the ra() to see
what the delay is for the Pings and the TCP packets.
They should be order of magnitude the same.  This may
suggest that the same target machine is being hit.
Also look at the TTL's for the packets.  Both the
source and destination TTL's should be the same for
both flows.  If they aren't the same then you might
be able to say that more than one host is involved.
Use fullra() to get the TTL values.
(Continue reading)

Permalink | Reply | 1 comment |
headers
Russell Fulton | 24 Jun 1999 23:05
Picon
Picon
Favicon

RE: ra output intrepretation

HI Carter,
	  Thanks for your comprehensive answer to my query. 

I think that the first packet to port 80 may have had fin flag set thus 
is label EST by ra in detail mode (that is really what I wanted to 
know) and I had forgotten that it would go right through the filter 
which does only block syn packets. This is, of course, the main purpose 
of using fin scans.

I have a slightly modified version of ra that I use for detecting 
scans,  I will add some logic to it to report connections consisting of 
lone fin or fin and rst.

Cheers, Russell.
Permalink | Reply | 0 comments |

Gmane