headers
Alexander Bochmann | 15 Apr 1999 15:50
Picon

strange argus records

Hi,

in an output produced with ra -c I see entries that look like the 
second in the following example:

Wed 04/14 10:47:04      tcp xxxxxx.xxxxx.de.2255   ->  www2.xxxxxx.de.www   7      5       416       388      CLO
Mon 10/14 18:21:19T    unas     30.99.31.97       <-> xxxxxx.xxxxx.de       150339664 38      37        409      CON
Wed 04/14 10:48:06      tcp xxxxxx.xxxxx.de.2304   ->      xxxxxx.com.www   19     14      563       15031    CLO

What does this want to tell me? The date of the entry is quote wrong, 
and there were 150339664 packets transmitted with a total size of 37 bytes? 
And what protocol is "unas"?

Is there something broken? (This is argus-1.7.beta.1e on a Linux box.)

Alex.
Permalink | Reply | 4 comments |
headers
Russell Fulton | 15 Apr 1999 23:03
Picon
Picon
Favicon

Re: strange argus records


On Thu, 15 Apr 1999 15:50:40 +0200 Alexander Bochmann 
<bochmann <at> mupfel.infra.de> wrote:

> Hi,
> 
> in an output produced with ra -c I see entries that look like the 
> second in the following example:
> 
> Wed 04/14 10:47:04      tcp xxxxxx.xxxxx.de.2255   ->  www2.xxxxxx.de.www   7      5       416       388      CLO
> Mon 10/14 18:21:19T    unas     30.99.31.97       <-> xxxxxx.xxxxx.de       150339664 38      37        409      CON
> Wed 04/14 10:48:06      tcp xxxxxx.xxxxx.de.2304   ->      xxxxxx.com.www   19     14      563       15031    CLO
> 
> What does this want to tell me? The date of the entry is quote wrong, 
> and there were 150339664 packets transmitted with a total size of 37 bytes? 
> And what protocol is "unas"?
> 
> Is there something broken? (This is argus-1.7.beta.1e on a Linux box.)

This looks like another symptom of the incomplete read problem which 
linux system seem to be more prone to.  Carter has patches for it which 
will be incorporated into the upcoming 1.8 release.

The other possibility is that the ra input file was corrupt.  (unas is 
short for unassigned -- I think i.e. the field was garbage like the 
rest of the record). 

Cheers, Russell.
(Continue reading)

Permalink | Reply | 3 comments |
headers
Alexander Bochmann | 16 Apr 1999 10:46
Picon

Re: strange argus records

...on Fri, Apr 16, 1999 at 09:03:16AM +1200, Russell Fulton wrote:

 > On Thu, 15 Apr 1999 15:50:40 +0200 Alexander Bochmann 
 > <bochmann <at> mupfel.infra.de> wrote:
 > > Mon 10/14 18:21:19T    unas     30.99.31.97       <-> xxxxxx.xxxxx.de       150339664 38      37        409      CON
 > > Is there something broken? (This is argus-1.7.beta.1e on a Linux box.)
 > This looks like another symptom of the incomplete read problem which 
 > linux system seem to be more prone to.  Carter has patches for it which 

It's mildly strange, because at least the (obviously spoofed) IP 
address 30.99.31.97 also shows up in a cisco accounting logfile 
(would have to look up the traffic, though, but if I remember correctly 
it was only a handfull of bytes at east in the one record I saw)... 
The (x-ed out) receipient address is also ok.

 > The other possibility is that the ra input file was corrupt.  (unas is 
 > short for unassigned -- I think i.e. the field was garbage like the 
 > rest of the record). 

I assume that at least part of the record is actually correct - is there 
any kind of traffic that can break argus' recording and/or reporting?

Alex.
Permalink | Reply | 0 comments |
headers
Carter Bullard | 16 Apr 1999 18:24

RE: strange argus records

Hey Alexander,
   Hmmmmm, you may have tickled a bug in the 1.7e TCP
source packet count logic.  I use to see this with argus-1.5
where occasionally we would get a report of a TCP connection with
an ungodly number of packets from the source.  In fact, 
the 1.5 ra(), actually had some logic to check for ungodly
numbers.  I thought we had fixed that in 1.[67], but you
know how bugs can be.

   To answer your question about certain kinds of input causing
problems.  I'm sure that the answer is yes, but I think we've
got all the ones we know about in the 1.8 code.

   You can suppress the 'unas' mapping with the -nn option (2 -n's)
which will show you the actual protocol number that was in the
packet stream.  This might help to rule out data corruption, which
has a probability, but I feel like that number is really low.

   We are reporting that the flow had IP Timestamp Options set, which
seems interesting in its own right.     Do you have any other crazy
looking records that may be clustered around this one in the file?
Especially with the T indicator set?

Carter

-----Original Message-----
From: Alexander Bochmann [mailto:bochmann <at> mupfel.infra.de]
Sent: Friday, April 16, 1999 4:47 AM
To: argus <at> lists.andrew.cmu.edu
Subject: Re: strange argus records
(Continue reading)

Permalink | Reply | 0 comments |
headers
David Brumley | 20 Apr 1999 18:25
Picon

strange records

Hey carter,
I've noticed some weird records lately while writing an IDS around argus.
I'm running argus on Solaris 2.6 on a FDDI.

In a nutshell, sometimes I get negative byte counts.  Another weird thing
is sometimes the startime is after lasttime.  Either there are
time-travelling packets, or i'm missing something.

We run AFS on the machine, so the clock is adjusted every so often.  I
don't know if this explains the whole skew, though.
      - startime: Wed 04/14 00:44:11
      - lasttime: Tue 04/13 19:41:20
results in
      -     src port num: 1350
      -     dst port num: 80
      -   src byte count: -12
      -   dst byte count: 0
      -    src pkt count: 3
      -    dst pkt count: 1

Sometimes there is the clock problem without the packet problem....but
maybe it's subtracting packets but just not enough to make the whole thing
negative....i don't know.

Is there a way to do this, perhaps with times() instead of time().

cheers,
david

#+--+#+--+#+--+#+--+#+--+#+--+#+--+#+--+#+--+#+--+#+--+#+--+#+--+#+--+#
(Continue reading)

Permalink | Reply | 2 comments |
headers
David Brumley | 20 Apr 1999 18:49
Picon

strange records

I forgot to mention, the clock is only adjusted at most a few seconds.

On Tue, 20 Apr 1999, David Brumley wrote:

> Hey carter,
> I've noticed some weird records lately while writing an IDS around argus.
> I'm running argus on Solaris 2.6 on a FDDI.
> 
> We run AFS on the machine, so the clock is adjusted every so often.  I
> don't know if this explains the whole skew, though.
>       - startime: Wed 04/14 00:44:11
>       - lasttime: Tue 04/13 19:41:20

#+--+#+--+#+--+#+--+#+--+#+--+#+--+#+--+#+--+#+--+#+--+#+--+#+--+#+--+#
David Brumley - Stanford Computer Security - dbrumley <at> Stanford.EDU
Phone: +1-650-723-2911    WWW: http://www.stanford.edu/~dbrumley
Fax:   +1-650-725-9121    PGP: finger dbrumley-pgp <at> sunset.Stanford.EDU
#+--+#+--+#+--+#+--+#+--+#+--+#+--+#+--+#+--+#+--+#+--+#+--+#+--+#+--+#
Permalink | Reply | 1 comment |
headers
Carter Bullard | 20 Apr 1999 19:02

RE: strange records

Hmmmmm,
   Very interesting, and we can't blame it on Daylight
Savings Time ;o)  The question would be "is this a TCP
record"?   Argus is doing some not-so-striaght foward
logic on TCP reporting (times, byte and packet counts) in
order to have the final record be a cumulative record
of the entire TCP.  If this is a really long lived record
we may have wrapped around a counter and thats how we
got a negative value in a byte counter, but the time should
wrap.   We may be tickling something in this code that
is not quite right.

   What I would be interested in is if there are any
other records that apply to this same flow
that are well formed.

Carter

PS. Hows the FDDI performance?  I have not had the best
    results with Sun FDDI.  I've had better results with
    DEC.

-----Original Message-----
From: David Brumley [mailto:dbrumley <at> goju.Stanford.EDU]
Sent: Tuesday, April 20, 1999 12:50 PM
To: Carter Bullard
Cc: argus <at> lists.andrew.cmu.edu
Subject: strange records

I forgot to mention, the clock is only adjusted at most a few seconds.
(Continue reading)

Permalink | Reply | 501 comments |
headers
Chas DiFatta | 20 Apr 1999 20:34

RE: strange records

David,

I don't know if this will help but it may be two things.  I was pushing
about 30-40 Mb/sec
on Solarus full-dup 100base-T and had to do a few things to make it sing.

	- Installed a new version of libpcap, 0.4
	- changed all varables in my clients to accomidate 64 bit length (long
long).
        This was needed when I crossed over the 20 Mb/sec mark.  I.e.
pumping
	  lots of data for hours on end.

Sometimes when I had different versions of the argus server and it's clients
compiled
with different versions of libpcap the clock would get far off and
occasionaly the
data would get wacky.  I just made sure that all code was compiled from the
same
base libs.

I hope this helps.

	...Chas

> -----Original Message-----
> From: owner-argus <at> lists.andrew.cmu.edu
> [mailto:owner-argus <at> lists.andrew.cmu.edu]On Behalf Of David Brumley
> Sent: Tuesday, April 20, 1999 9:50 AM
> To: Carter Bullard
(Continue reading)

Permalink | Reply | 0 comments |
headers
Alexander Bochmann | 21 Apr 1999 10:06
Picon

Re: strange argus records

...on Fri, Apr 16, 1999 at 09:03:16AM +1200, Russell Fulton wrote:

 > > in an output produced with ra -c I see entries that look like the 
 > > second in the following example:
 > > Mon 10/14 18:21:19T    unas     30.99.31.97       <-> xxxxxx.xxxxx.de       150339664 38      37        409      CON
 > This looks like another symptom of the incomplete read problem which 
 > linux system seem to be more prone to.  Carter has patches for it which 
 > will be incorporated into the upcoming 1.8 release.

Darn. Either my seeing the address from the above record in a cisco 
accounting file was wishfull thinking or I made some other error.

Currently I can't reproduce this output, so best blame the original 
mail on my stupidiy or something :(

Sorry,

Alex.
Permalink | Reply | 1 comment |
headers
David Brumley | 21 Apr 1999 18:14
Picon

RE: strange records

On Tue, 20 Apr 1999, Carter Bullard wrote:

> Hmmmmm,
>    Very interesting, and we can't blame it on Daylight
> Savings Time ;o)  The question would be "is this a TCP
> record"?   Argus is doing some not-so-striaght foward
> logic on TCP reporting (times, byte and packet counts) in
> order to have the final record be a cumulative record
> of the entire TCP.  If this is a really long lived record
> we may have wrapped around a counter and thats how we
> got a negative value in a byte counter, but the time should
> wrap.   We may be tickling something in this code that
> is not quite right.
> 
>    What I would be interested in is if there are any
> other records that apply to this same flow
> that are well formed.

The one right before it seems okay:
      - startime: Wed 04/14 00:43:45
      - lasttime: Tue 04/13 19:41:20
      - src addr: 171.215.74.136
      - dst addr: 171.64.14.237
    TCP Structure:
      -     src port num: 1348
      -     dst port num: 80
      -   src byte count: 622
      -   dst byte count: 1448
      -    src pkt count: 3
      -    dst pkt count: 3
(Continue reading)

Permalink | Reply | 501 comments |

Gmane