Interpretation of ra output...

[Carter Bullard]

Hey Russell,
   My interpretation is that someone is doing something
using TCP SYN packets, but using some of your addresses
as the source.  You, of course, receive the SYN_ACK's,
and of course your machine doesn't have a TCP in the
right state for the ACK, so it RST's it.

   Reported TTL is the last TTL value seen for the
flow.  Argus just overwrites the TTL value in the flow
control block with the value from each packet.  We
should have a bit that indicates that the TTL has
changed, similar to the MAC address indicator, but
that is for Argus 2.0.  Same for the ToS (DS-Byte).

   Now trying to figure out the distance values from the
TTL is interesting, since the inital TTL is unknown.
If the values seem random, then I would agree that
someone may be trying to forge packets and isn't
initializing the TTL field.  TTL is rather straight
forward, but what will take you off the track is that
both the source and destination addresses may be bogus,
forged source address on the SYN, and some NAT function,
or TCP "firewall" like device driving the destination
address to look the same.  It may be that someone is
scanning in a private 10 network, and this is what pops
out.  Maybe bugs in a NAT device?   All of these sound
possible.

Carter

   

> -----Original Message-----
> From: Russell Fulton [mailto:r.fulton at auckland.ac.nz]
> Sent: Sunday, March 12, 2000 3:50 PM
> To: Argus (E-mail)
> Subject: Interpretation of ra output...
> 
> 
> Hi All,
> 	here are some logs from my patched ra which displays all the
> tcp state info, not just the final state.  In this case
> S = SEEN_SYN+ACK and R = RST.
> 
> 12 Mar 00 11:09:38      tcp  130.216.35.201.1610   |>   
> 202.44.216.10.55302 2      2       0         0        SR
> 12 Mar 00 11:10:11      tcp  130.216.35.201.1610   |>   
> 202.44.216.10.55350 1      1       0         0        SR
> 12 Mar 00 11:25:47      tcp  130.216.35.201.2259   |>   
> 202.44.216.10.56948 2      2       0         0        SR
> 12 Mar 00 11:26:18      tcp  130.216.35.201.2259   |>   
> 202.44.216.10.57005 1      1       0         0        SR
> 12 Mar 00 11:41:36      tcp  130.216.35.201.2885   |>   
> 202.44.216.10.58437 2      2       0         0        SR
> 12 Mar 00 11:42:06      tcp  130.216.35.201.2885   |>   
> 202.44.216.10.58483 1      1       0         0        SR
> 12 Mar 00 11:56:07      tcp  130.216.35.201.3505   |>   
> 202.44.216.10.59825 2      2       0         0        SR
> 12 Mar 00 11:56:37      tcp  130.216.35.201.3505   |>   
> 202.44.216.10.59865 2      2       0         0        SR
> 
> My interpretation of this trace is that the argus server saw a SYN+ACK
> packet come in *from* 202.44.216.10 (but never saw the 
> corresponding SYN
> packet) and that 130.216.35.201 responded with a RST packet.  Argus/ra
> has simply assumed that it missed the SYN packet and has adjusted the
> source and destination addresses accordingly.
> 
> I don't have any problems with this behaviour ;-) I just want to be
> sure I really do understand what is happening here.  Well at the
> packet level at any rate - why we have been seeing this stuff over the
> weekend is a mystery.
> 
> Unfortunately it now appears to have stopped otherwise I would have
> cranked up tcpdump to get some more details.
> 
> Running this through fullra reveals that the dst TTLs vary wildly
> (in this sample from 10 to 170) while the src TTLs are all between
> 190 and 210.
> 
> Carter: how should we interpret these TTL values (given that TTL is
> the property of a single packet) are they averages?  I assume that
> source TTL refers to the TTL for packets sent by the source and dest
> TTL to those sent by the destination.  I find it strange strange that
> the TTL associated with 130.216.35.201 varies at all since it is our
> student Mail system and is two hops from the argus monitor.  And what
> should I make of the wild variation in the other TTL?
> 
> Any ideas?
> 
> My guess is that this traffic was not generated by a tcp stack and
> source addresses forged, why I have no idea.
> 
> Cheer, Russell.
> 
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://pairlist1.pair.net/pipermail/argus/attachments/20000313/86cb3817/attachment.html>