Reversed udp addresses

[Carter Bullard]

Hey Russell,
First, is this 1.8 code?  That does make a difference.

The data appears to be correct, based on your
description.  All traffic is being sourced by
aaa.bbb.37.70.  But because of the nature of the
dst port numbers, we get some rather interesting output.

How a particular IP address gets into the left most
position on the ra() output is somewhat convoluted.  The
primary logic is that the lower port number should
be on the right (most destination ports are in the
< 1024 range, and so this is not a terrible idea).
The idea being we would like most of the arrows pointing
in the -> direction.

This is the essence of Russell's problem.

We are flip flopping the addresses because there are
two flows going on, udp ports 1755 <-> 5632 and 1755 <-> 22.
We get a flip flop condition on the ra() output, because
the source port is < in the first, and > in the other.

The arrow is trying to correct for the problem where
the source and destination have been mismapped to
the wrong columns.  So in these two records:

udp 130.216.168.1.5632 <-  aaa.bbb.37.70.1755  0   1   0   10  TIM
udp aaa.bbb.37.70.1755  -> 130.216.168.1.22    1   0   10  0   TIM

aaa.bbb.37.70 is the source for both.

Now if this is all there is to it then there isn't
really a problem, its just seems cosmetic.  The real
issue is, do we get both of the these records if we
do this:

   ra -ncr filename src host aaa.bbb.37.70

If we don't get them both from this select,
and see the flip flopping, then we've got a problem.


What do you think Russell?

Best Regards,

Carter



   

-----Original Message-----
From: Russell Fulton [mailto:r.fulton at auckland.ac.nz]
Sent: Tuesday, May 11, 1999 1:04 AM
To: Argus (E-mail)
Subject: Reversed udp addresses


Greetings All,
	     Today I spotted some rather odd logs from argus.  My
simple ID system picked up a udp scan of one of our subnets and when I
used ra to extract all traffic for the source address this is the sort
of records I got:

Tue 05/11 15:31:55      udp   130.216.168.1.5632  <-    aaa.bbb.37.70.1755  0      1       0         10       TIM
Tue 05/11 15:31:55      udp   aaa.bbb.37.70.1755   ->   130.216.168.1.22    1      0       10        0        TIM
Tue 05/11 15:31:55      udp   130.216.168.2.5632  <-    aaa.bbb.37.70.1755  0      1       0         10       TIM
Tue 05/11 15:31:55      udp   aaa.bbb.37.70.1755   ->   130.216.168.2.22    1      0       10        0        TIM
Tue 05/11 15:31:55      udp   130.216.168.3.5632  <-    aaa.bbb.37.70.1755  0      1       0         10       TIM
Tue 05/11 15:31:55      udp   aaa.bbb.37.70.1755   ->   130.216.168.3.22    1      0       10        0        TIM
Tue 05/11 15:31:55      udp   130.216.168.4.5632  <-    aaa.bbb.37.70.1755  0      1       0         10       TIM

So far as I can see all traffic was initiated by aaa.bbb.37.70 (number
disguised to protect the guilty ;-) yet on half the records the
130.216 address (ours) was shown as 'source'.  I have had a look at
the ra source and can't find any code that swaps udp src and dest
addresses (as there is for tcp) therefore it must be the server that
is assigning the addresses this way.

My guess is that it is doing this because aaa.bbb.37.70.1755 is
appearing as both a source and destination.  Sigh...

It is rather confusing when presenting logs as evidence of scans or
attacks. 

BTW 5632 is used by PCAnywhere :-( and, no, I'm not telling if any
machines responded ;-)

Cheers, Russell.