headers
Carter Bullard | 5 Oct 1999 00:41

RE: missed pings ??

Hey Russell,
   Its hard to figure it out from way over here ;o)  The interesting
thing is that the last 6 records from both are consistent, especially
the times, so there seems to be something that is correlatable.  Hmmm.

   Echo and Echo Response packets get collapsed into flows of their
own, and get reported based on an ICMP specific timeout timer, so the
reports maybe being generated much later than you anticipate.

   There are switches that change the ICMP behavior.  It maybe
that if there is a problem it is in this logic.  Run argus-1.8
with the -R option.  This will flush any Echo Request/Response
volleys as soon as they are completed.  This may bring your
Echo's back ?  More information would be appreciated.

Carter

Carter Bullard
Principal Consultant/Engineer
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: Russell Fulton [mailto:r.fulton <at> auckland.ac.nz]
> Sent: Monday, October 04, 1999 4:40 PM
(Continue reading)

Permalink | Reply | 0 comments |
headers
Carter Bullard | 6 Oct 1999 02:51

RE: another ra oddity...

Hey Russell,
   This is unavoidable.  What is happening is the flow idle timer
is reached and argus() times out the flow sometime after your #2
report.  Then when the flow kicks back in the, first packet seen
is going in the opposite direction.  But since we didn't see a SYN
or a SYN_ACK, we don't know who the source is.  In this case
we use the first packet encountered to define the scr and
dst for the flow.

   Not much you can do here.  raconnections() will match them up
correctly when it merges them together.

Carter

Carter Bullard
Principal Consultant/Engineer
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: Russell Fulton [mailto:r.fulton <at> auckland.ac.nz]
> Sent: Tuesday, October 05, 1999 8:27 PM
> To: Bullard, Carter [NYPAR:DS46-I:EXCH]
> Subject: another ra oddity...
>
(Continue reading)

Permalink | Reply | 0 comments |
headers
Carter Bullard | 6 Oct 1999 18:59

RE: RE: another ra oddity...


Hey Russell,
Yeah, it basically is aggregating all the Argus records,
and then, when reading is complete, it sorts the records based
on start time.

The sorting algorithm is an insertion sort, using a
bin hash with chains.  I create a bin for each second in the
range of time that spans the collected input, and then sort
by microsecond within that bin, using a straight insertion.

I would suspect that you just have too many output records
for your 32MB.  No real need to run raconnections() on the
entire daily log, since only a very small percentage of flows
will span hourly boundaries.  

You get the greatest amount of aggregation when you have a small
detail interval, say '-d 5', and a relatively large collection interval,
say with your hourly output files.  Since the mean duration of
argus IP flow output is usually under 10 seconds, you don't get much
straight reduction, except when the -d option is set.  In this
case, you'll reduce tcp reporting load to 25%, since there will
be 4 argus records, minimum, per TCP connection.  And to 50% for
UDP request/response traffic, say for DNS.

For those few services that do, X-Windows, SNMP associations,
Management pings, Telnet, etc.. you can pick these specific
records out of the file, by selectively aggregating just these
records by using filters on raconnections().
(Continue reading)

Permalink | Reply | 0 comments |
headers
Carter Bullard | 7 Oct 1999 16:07

RE: RE: another ra oddity...

Hey Russell,
   So I now rarely use the 'dst' or 'src' indications,
since this has caused me to miss some unexpected network
events.  Especially since many firewalls are misconfigured,
allowing incoming TCP connections with a source port of 23
to get in.  Filters like:

    ((src address local && dst port 23) ||
            (dst address local and src port 23))

or

  !((dst address local and dst port 23) ||
            (src address local $ src port 23))

appear to work for the most part, but, as we know, are
not good at all.  People tend to generate this type of
filter when they are trying to quickly fix a connectivity
problem and they've only got filter expressions in routers
to work with.

   And many an intrusion detector builder forget to go after
the most common and simple human filter errors, as they are
wrapped up in the complexity of solving the hard problems,
forgetting about the simple ones.  I would put reverse port use
way up front on any intrusion detection module.   

   This makes using raconnections() important.
If I'm looking for telnets in a whole days worth of logs, I would
run raconnections() with a filter of "tcp and port 23" on all the
(Continue reading)

Permalink | Reply | 0 comments |
headers
Carter Bullard | 8 Oct 1999 13:51

RE: RE: RE: another ra oddity...


Hey Russell,
   Thanks for all the mail, and its good to see that
you're getting something out of Argus, because you certainly
have put a lot in ;o)

   One note, the US has announced relaxation of their
encryption export and import policies, so the "made in the
USA" may be not be a barrier after Nov 1.

Hope all is well,

Carter

> -----Original Message-----
> From: Russell Fulton [mailto:r.fulton <at> auckland.ac.nz]
> Sent: Thursday, October 07, 1999 4:51 PM
> To: Bullard, Carter [NYPAR:DS46-I:EXCH]
> Subject: Re: RE: RE: another ra oddity...
> 
> 
> Hi,
> 	Again, thanks for your comments.  Figuring out the best ways of 
> using tools like argus are certainly non trivial, sigh...
> 
> I am pleased that I chose a file naming scheme that sort 
> lexically into 
> time order so I am doing a lot of 
> 
> "join(' -r ', sort grep(/\.gz$/, readdir(DIR))"
(Continue reading)

Permalink | Reply | 3 comments |
headers
Carter Bullard | 18 Oct 1999 20:52

RE: Problem with argus

Carmen,
   I'm sending you the lastest version of
argus-1.8.  This is a test version, and so please
don't post it for redistribution.  If you have any
problems, please send us mail.

Carter

> -----Original Message-----
> From: Maria del Carmen Contreras Espinosa [mailto:mcconesp <at> cic.upo.es]
> Sent: Wednesday, October 13, 1999 8:42 AM
> To: argus <at> sei.cmu.edu
> Subject: Problem with argus
> 
> 
> Hello
> I'm using Redhat 6.0 and when I do "make", appear the next error
> 
> making in server
> make[1]: Entering directory 
> `/home/cic/argus7/argus-1.7.beta.1e/server'
> gcc -O -I../include  -I../include/linux-include -DHAVE_MALLOC_H=1
> -DHAVE_ETHER_H
> OSTTON=1 -DHAVE_STRERROR=1 -DHAVE_NET_IF_ARP_H=1 -DTCPWRAPPER=1  -c
> ./argus.c
> ./argus.c: In function `init':
> ./argus.c:291: request for member `__fds_bits' in something not a
> structure or u
> nion
> ./argus.c:291: request for member `__fds_bits' in something not a
(Continue reading)

Permalink | Reply | 0 comments |

Gmane