Argus on multiple interfaces with NAT

Mark Poepping poepping at cmu.edu
Wed Mar 13 02:02:38 EST 2002



A few possible ideas..

> argus is currently configured to watch the external interface.  By the
> time
> they reach argus, outgoing packets have been translated (and have a
> 'shared'
> routeable source IP), and incoming packets have been 'untranslated'
(and
> have a unique non-routable destination IP).  NAT is configured such
that
> there is no easy way to identify the originating host from the
translated
> (routeable) IP.  Accordingly, I can identify the host associated with
a
> particular download (incoming packet, therefore unique non-routeable
IP),
> but uploads (outgoing packet, translated to a shared routeable IP)
cannot
> be
> identified with the originating host.

You say that argus sees the outbound packets *after* translation and the
inbound packets *after* translation too?  This seems very non-intuitive
(to me at least)..  

So if the actual transaction is:
	internal:192.168.10.10.33333  -> external:207.68.172.253.1214

You're saying it appears as:
	routable: 131.111.8.38.44444  -> external:207.68.172.253.1214
   *and*
	external: 207.68.172.253.1214 -> internal:192.168.10.10.33333

Hmm.  I'd have hoped that the packets you'd see on any particular
interface would be consistent for the attached network so both flows in
the transaction could be correlated.  Even if that's not the case, it
wouldn't be hard to relate the records from the different interfaces
since almost all of the transaction data (e.g. external host, timestamp,
packets, octets) should match except for the internal/routable address -
yielding the correlation.  You should be able to rasort (align
timestamps) both flowfiles and see the translated flows right next to
each other.  If the files aren't that big, this shouldn't be hard.

> As far as I can gather, there are a few options:
> 
> 1. Two argi, two data collectors, no easy way to correlate the
internal
>    IPs of outgoing packets with the translated IPs in the data from
the
>    external interface (my current setup).  Suggestions very welcome.

Option suggested above..

> 2. Two argi, one data collector which can differentiate between them
>    (by source identifier? interface?) and sift out duplicated records
>    and internal traffic. 

Start the argii with different probeID's (argus -e [probeID])

Did you realize that you can use tcpdump syntax on *any* of the argus
commands? Including the argus probe itself?  So if you don't want local
transactions, you need only craft the tcpdump syntax to strip them out
when you invoke argus_linux (e.g. not ( src net local and dst net
local))..  if you have two local nets in different netblocks, you'll
need to 'not' both combinations of src and dst..

> 3. One argus monitoring external and internal interfaces - but how do
>    I cut out the internal traffic (I'm only interested in stuff which
>    crosses the border on the external interface), and get rid of any

I believe that the public domain argus can only handle two interfaces at
a time..  talked above about ignoring internal traffic..

>    duplicated flow data?  Does the argus datastream include a
reference
>    to the interface from which the data was collected, allowing the
>    degree of analysis currently available by specifying the external
>    interface as part of a filter expression or similar?  The external

I think tcpdump syntax might be strong enough.

>    (routeable) IPs and internal IPs all fall within IP ranges which
>    could be specified in a filter expression.
> 
> 4. One argus monitoring the external interface, with some network
magic
>    to grab the pre-translation source IP for outgoing packets.  Ideal
>    solution, but that kind of magic isn't easy to come by...

idea already posted..

> 5. Any other ideas???
> 
> Should there be any problem running multiple instances of argus and
> multiple
> instances of ra on a machine?  Of course, I'd rather do it with just
one
> of each, but that might not be an option.

Just be careful of performance, *especially* if you're writing a bunch
of stuff to disk (and trying to NAT/route at the same time)..



More information about the argus mailing list