seeing private network traffic on public interface, WHY?

[Denis Ducamp]

On Sat, Jun 09, 2001 at 10:14:11AM -0600, Derrik Pates wrote:
> On Sat, 9 Jun 2001, s I n wrote:
> 
> > not quite. If you are in a network in wich you are conected bye a HUB, now
> > a SWITCH then you can see, with tcpdump, all the packets going thru that
> > HUB. So, tcpdump will see more packets than the filter table in iptables.
> > The filter table sees packets that come specifically to your machine, but
> > tcpdump will se packets that do not have anything to do with your machine.
> 
> Yes, but if the packet is part of a DNAT'd connection, packet dumpers (or
> at least ones built on top of libpcap) will see the packets _after_ the
> DNAT rewrite has taken place, but _before_ any SNAT rewriting has taken
> place, if any is to be done. I've seen the same thing.

This is what I can see since one year and reported this several times to the
netfilter lists as a bug but nobody replied me.

My configuration is simple : a firewall with a public eth0 and a private
eth1 and a masquerading rule to permit the private network to access to
Internet : iptables -t nat -A POSTROUTING -o eth0 -j MASQUERADE

Here is what I have with a recent version of tcpdump (the old one gives the
same thing but may listen only on one interface at the same time).

brett:~# ./tcpdump -ln -vvv -i any icmp
tcpdump: listening on any
(eth1) 19:51:53.112976 192.168.1.66 > 216.32.74.55: icmp: echo request (ttl 64, id 61909, len 84)
(eth0) 19:51:53.114499 195.132.147.17 > 216.32.74.55: icmp: echo request (ttl 63, id 61909, len 84)
(eth0) 19:51:53.230616 216.32.74.55 > 192.168.1.66: icmp: echo reply (ttl 235, id 41220, len 84)
(eth1) 19:51:53.231305 216.32.74.55 > 192.168.1.66: icmp: echo reply (ttl 234, id 41220, len 84)

Here we can see that the destination address of the third packet is
different of the source address of the second packet so it have been
modified before getting into libpcap. This significates that sniffers
doesn't see what is on the wire...

** This is bad because NIDS doesn't have the packet as it was on the wire **

I thing that this is a bug in netfilter because it modifies packets before
sniffers can have them, but if someone demonstrate me that this is a bug in
another part of the kernel then tell me please where to report the bug.

Regards,

Denis Ducamp.

-- 
 Denis.Ducamp@hsc.fr --- Hervé Schauer Consultants --- http://www.hsc.fr/
Owl/snort/hping/dsniff en français  http://www.groar.org/~ducamp/#sec-trad
            Owl en français    http://www.openwall.com/Owl/fr/
 Du bon usage de ... http://usenet-fr.news.eu.org/fr-chartes/rfc1855.html