[ARGUS] enterprise NAT consideration
Peter Van Epp
vanepp at sfu.ca
Wed Jun 23 22:36:14 EDT 2004
While I think the ra* answer will be no, I'll let Carter give the
definitive answer. Without the NAT state table this is going to be impossible
to do completely at all times I expect (the case of two private side hosts
going to the same external host and port number at close to the same time
for instance will likely be indistinguishable without NAT state), but with
perl or C you can probably come close.
You know from argusa output the start time, end time, number of packets
and bytes transferred from internal host x to external host y as things that
are going to be reasonably constant across the link (you know source port
numbers too but NAT is making them useless without state). So in the argusb
output you need to match external host y's IP and dst port with all data to
that external host/dst port pair from argusa (because the destination IP/port
is the only thing that NAT can't change on the way by) and byte counts and times
are going to be relatively constant (or at least probably not intentionally
changed unless your NAT maintainer is also reading this post :-)).
Once you have that probably much smaller set of data, now you compare
start/stop time and source / dest packet/byte counts on the two data sets. The
best match of argusa data with the argusb data is likely your end to end
connection. Often there will be only one data pair anywhere close and you can
be fairly confident you are correct, but as noted in the case with two close
to identical connections (such as to a popular web server) at close to the
same time (especially to the same page so that the counts match) you have much
less confidence. Things like retransmission and latency in the links will
probably also fuzz both the start/end time and the packet/byte counts just to
make things more interesting, but I expect this will come close.
Were I doing this I'd feed the ra output in to a perl script to make
the prototyping easy (or python if thats your poison of choice :-)) to at
least figure out how to do this. Once you've got it down how to do it, if you
need more speed then a new r* client can be written (I've never managed to get
out of the prototyping in perl myself :-)).
Peter Van Epp / Operations and Technical Support
Simon Fraser University, Burnaby, B.C. Canada
On Wed, Jun 23, 2004 at 09:39:33PM -0400, slif at bellsouth.net wrote:
> 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
>
More information about the argus
mailing list