[ARGUS] enterprise NAT consideration

[Carter Bullard]

Hey Mike,
   Peter is right, the process of discovering the NAT mappings
is not straight-forward, but I believe that its not as 'impossible'
as Peter suggests ;)  While there is not specific support for
this in the freebie code, the ra* programs should give you
enough information so that you can find the two records, I
believe even in the presence of double NAT.

   So given two probes, looking at the same flows correlated in
time, you can match flow records using, what are referred to as,
non-key attributes.  There are three candidates in order of
best to worst.  The UserData buffer strings are great for finding
NAT'd flows.  While NAT can do a lot to the IP headers, it
can't really modify the user data, so comparing parts of the user
data buffer is not too hard to do (should be doable using
perl/python/java and ra()).  The next non-key attribute that
is somewhat reliable is the base TCP sequence numbers, assuming TCP
of course, and third are the IpId fields.  These values generally
survive NAT operations.  Ra can printout each of these fields,
(hmmm, raxml() can print them all, maybe ra() doesn't print out
the TCP base sequence numbers yet, although they are in the
argus record).

  Once you decide on a strategy, we can discuss the best way
to find the matches, if its something you want to share on
the list.

Carter




-----Original Message-----
From: owner-argus-info at lists.andrew.cmu.edu
[mailto:owner-argus-info at lists.andrew.cmu.edu] On Behalf Of
slif at bellsouth.net
Sent: Wednesday, June 23, 2004 9:40 PM
To: argus-info at lists.andrew.cmu.edu
Subject: [ARGUS] enterprise NAT consideration

Hello,
I'm beginning to use argus, and I have a question
that I've not had the hardware to verify. I'm also
fairly new to WAN correlation, and I'm not familiar
with many of the tools that might be second nature
to you.

I've scanned the mail list archive and found six messages
in 2002 that discussed NAT. Starting with Message-ID:
 <BEEOKCJBNELJMDMAIKHFKEDECBAA.c.martin at jesus.cam.ac.uk>
 It seemed the discussion drew
near an assumption that firewall logs were available.  This
is not the case for the scenario I"m describing below.


Given the following network diagram:

    DMZ -- subnet is 192.168.1
     |
     +------ machine A (in California) argus writes argusA.out
     |
   firewall applying NAT [DMZ/24 --> MM.NN.OO.PP/32]
     |
     +------ machine B (in Colorado) argus writes argusB.out
     |
   outside

Given an external destination XX.YY.ZZ.WW routed to outside,
Given an internal source 192.168.1.10
Given a connection from source to destination
Given machine A and machine B are NTP time-synched to
    within 20 milliseconds
Given the logs on the firewall may not be available
   (e.g., a Linksys or a NetGear firewalling router,
    or firewall is owned by a different administrative authority)

Machine A sees:
  Connection from DMZ 192.168.1.10 to  XX.YY.ZZ.WW (outside)
Machine B sees:
  Connection from firewall MM.NN.OO.PP/32 to  XX.YY.ZZ.WW (outside)

Given that the argusA.out and argusB.out are safely copied to another
machine,
Can one or more ra* tool [believed to be ragator] understand NAT to
correlate
each connection that was collected in argusA.out and argusB.out ?

Can it still correlate the connection if the firewall also
NATs the source and destination ports ?

Can parts of the connection be missing for this to succeed
(e.g., SYN not seen, or FIN not seen, or  single UDP packet seen ) ?

Is there a need for special filtering ?

What other tools might help complete the correlation ?

Thanks in advance,
-Mike Slifcak