Argus on multiple interfaces with NAT

[Carter Bullard]

Hey Christian,
   There seems to be some opportunity for solving your
problem, depending on what your trying to achieve.  From
your description, it appears that libpcap is getting its
data after iptables has had its way with the packets.  Is
this correct?  That doesn't seem like the right behavior.  

It seems to me that the best situation would be for you
to selectively read packets from just your internal
interfaces.  The public argus is configured to support 
reading packets from up to 3 interfaces at a time, and if
you need more, its just a compile define.

   If your interested only in generated argus data for
transactions with external hosts, then a single filter
works well:

   argus -i eth0 -i eth1 -i eth2 src net not x.y or dst net not x.y

where eth[0-2] are the internal interfaces, and x.y is
the local net.

Hope this is useful,


Carter

Carter Bullard
QoSient, LLC
300 E. 56th Street, Suite 18K
New York, New York  10022

carter at qosient.com
Phone +1 212 588-9133
Fax   +1 212 588-9134
http://qosient.com


   


> -----Original Message-----
> From: owner-argus-info at lists.andrew.cmu.edu 
> [mailto:owner-argus-info at lists.andrew.cmu.edu] On Behalf Of 
> Christian Martin
> Sent: Tuesday, March 12, 2002 8:20 AM
> To: argus-info at lists.andrew.cmu.edu
> Subject: Argus on multiple interfaces with NAT
> 
> 
> Once again, let's see if the Argus People can come to my rescue!
> 
> One of my argus hosts is a NATing firewall - it has a number 
> of internal
> interfaces (hosts being allocated non-routeable IPs from 
> private address
> ranges) and an external interface.  The source IP of outgoing 
> packets is
> translated to a routeable IP, and the packet goes out on the external
> interface.  The routeable IP is non-unique: many hosts share 
> only a few
> routeable IPs.  Incoming packets are 'untranslated' and 
> routed back to their
> originating host (on a non-routeable IP) on the appropriate internal
> interface.  So far so good.
> 
> 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.
> 
> To gather useful information about outgoing packets / uploads from the
> network, I have until recently run two argi, one monitoring 
> the external
> interface, and one monitoring the internal interfaces (well, 
> two of them).
> In effect, each packet is monitored twice - once on the 
> external interface
> (only useful for incoming packets and traffic totals), and once on the
> internal interface (loads of internal traffic I don't want to 
> monitor).
> Argus data is pumped down a completely separate interface to a logging
> server, data for the external interface over one port and data for the
> internal interfaces over another - two argi with an ra each 
> on the logging
> server to pick up the data.  My question - and sorry for the 
> wait - regards
> a better way of doing this, and preferably one which would allow full
> analysis of uploads as well as downloads.
> 
> 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.
> 
> 2. Two argi, one data collector which can differentiate between them
>    (by source identifier? interface?) and sift out duplicated records
>    and internal traffic.
> 
> 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
>    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
>    (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...
> 
> 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.
> 
> I'm using argus-2.0.3 (2.0.4 dies after a few days, per my previous
> posting), with ra 2.0.1 as a persistent daemon on a logging 
> server to store
> the data.  The firewall has a linux 2.4 kernel and all the 
> NAT magic is done
> by iptables.
> 
> Many thanks in advance for any suggestions or advice.
> 
> Christian
> 
> --
> Christian Martin
> IT Department
> Jesus College, Cambridge
> e-mail: c.martin at jesus.cam.ac.uk
> telephone: 01223-(7)64101
> 
> 
> 
>