seeing private network traffic on public interface, WHY?
Sat, 9 Jun 2001 19:58:14 +0200
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 > 220.127.116.11: icmp: echo request (ttl 64, id 61909, len 84)
(eth0) 19:51:53.114499 18.104.22.168 > 22.214.171.124: icmp: echo request (ttl 63, id 61909, len 84)
(eth0) 19:51:53.230616 126.96.36.199 > 192.168.1.66: icmp: echo reply (ttl 235, id 41220, len 84)
(eth1) 19:51:53.231305 188.8.131.52 > 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.
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