tcpdump and iptables ..

tcpdump and iptables ..

[Mussie Gebregziabiher]

Dear All,

When I run tcpdump I seem to be getting data after it is being processed by
iptables.   Can someone tell me where 'tcpdump' resides in the order of
priority?  Have the packets I'm seeing been subjected to 'PREROUTING' rules
such as 'MANGLE' and 'NAT'?  

Thanks in advance. 
Mussie G.

Re: tcpdump and iptables ..

[John A. Sullivan III]

On Sat, 2004-03-06 at 10:59, Mussie Gebregziabiher wrote:
> Dear All,
> 
> When I run tcpdump I seem to be getting data after it is being processed by
> iptables.   Can someone tell me where 'tcpdump' resides in the order of
> priority?  Have the packets I'm seeing been subjected to 'PREROUTING' rules
> such as 'MANGLE' and 'NAT'?  
<snip>
I'll relate my experiences trying to trace the interchange between
iptables and openswan but it is only from observation.  If someone who
knows the code responds, please take their word for it over mine.

I believe you will see the packet on the inbound interface before it
hits the PREROUTING chain of the mangle table.  You will see it on the
outbound interface after it has passed through POSTROUTING (I don't
recall off the top of my head if nat or mangle is last.

If there is a hand-off to another interface during packet processing,
you will see it again in tcpdump on the new interfaces again,
pre-PREROUTING and then post-POSTROUTING.
-- 
John A. Sullivan III
Chief Technology Officer
Nexus Management
+1 207-985-7880
john.sullivan@nexusmgmt.com

Re: tcpdump and iptables ..

[Antony Stone]

On Saturday 06 March 2004 4:16 pm, John A. Sullivan III wrote:

> On Sat, 2004-03-06 at 10:59, Mussie Gebregziabiher wrote:
> > Dear All,
> >
> > When I run tcpdump I seem to be getting data after it is being processed
> > by iptables.   Can someone tell me where 'tcpdump' resides in the order
> > of priority?  Have the packets I'm seeing been subjected to 'PREROUTING'
> > rules such as 'MANGLE' and 'NAT'?
>
> I'll relate my experiences trying to trace the interchange between
> iptables and openswan but it is only from observation.  If someone who
> knows the code responds, please take their word for it over mine.
>
> I believe you will see the packet on the inbound interface before it
> hits the PREROUTING chain of the mangle table.  You will see it on the
> outbound interface after it has passed through POSTROUTING (I don't
> recall off the top of my head if nat or mangle is last).

I agree with John here (with the same disclaimer - if someone who knows the 
code thinks otherwise - believe them, not me).

If you think about the information you can see with tcpdump (or other packet 
sniffers which work at the same level such as ethereal), there's a lot more 
low-level stuff than netfilter knows about - tcpdump sees ethernet frames, 
IPX and similar traffic which are not even IP based, as well as completely 
different media types such as 802.11b headers.   All this gets stripped off 
before reaching netfilter (with the exception of MAC addresses, but even 
there, netfilter can't tell whether a packet arrived by ethernet or 802.11).

Therefore tcpdump works at a much lower level, before netfilter on the input 
side, and after it on the output side.

Regards,

Antony.

-- 
"Reports that say that something hasn't happened are always interesting to me, 
because as we know, there are known knowns; there are things we know we know. 
We also know there are known unknowns; that is to say we know there are some 
things we do not know. But there are also unknown unknowns - the ones we 
don't know we don't know."

 - Donald Rumsfeld, US Secretary of Defence

                                                     Please reply to the list;
                                                           please don't CC me.

Re: tcpdump and iptables ..

[Cedric Blancher]

Le sam 06/03/2004 à 19:12, Antony Stone a écrit :
> tcpdump sees ethernet frames, 
> IPX and similar traffic which are not even IP based, as well as completely 
> different media types such as 802.11b headers.   All this gets stripped off 
> before reaching netfilter (with the exception of MAC addresses, but even 
> there, netfilter can't tell whether a packet arrived by ethernet or 802.11).

Just a notice about 802.11 stuff.

The way tcpdump will see traffic coming from a wireless link depends on
the wifi interface state. If the interface is in normal operation mode
(managed, ad-hoc or master), it will see frames as usual ethernet ones,
just as it was sniffing a wired link. If the interface is in monitor
mode, then it will see the frames will full 802.11 header.

BTW, I can confirm tcpdump will see outgoing traffic as it is after
POSTROUTING chain, and incoming one as it is before PREROUTING. I've
just checked playing with TTL on pings.

-- 
http://www.netexit.com/~sid/
PGP KeyID: 157E98EE FingerPrint: FA62226DA9E72FA8AECAA240008B480E157E98EE
>> Hi! I'm your friendly neighbourhood signature virus.
>> Copy me to your signature file and help me spread!

Re: tcpdump and iptables ..

[Antony Stone]

On Saturday 06 March 2004 6:46 pm, Cedric Blancher wrote:

> Le sam 06/03/2004 à 19:12, Antony Stone a écrit :
>
> > tcpdump sees ethernet frames,
> > IPX and similar traffic which are not even IP based, as well as
> > completely different media types such as 802.11b headers. 
>
> Just a notice about 802.11 stuff.
>
> The way tcpdump will see traffic coming from a wireless link depends on
> the wifi interface state. If the interface is in normal operation mode
> (managed, ad-hoc or master), it will see frames as usual ethernet ones,
> just as it was sniffing a wired link. If the interface is in monitor
> mode, then it will see the frames will full 802.11 header.

True - I guess I'm just used to always doing my 802.11 sniffing in monitor 
mode, so I get the maximum information out of the exercise :)

> BTW, I can confirm tcpdump will see outgoing traffic as it is after
> POSTROUTING chain, and incoming one as it is before PREROUTING. I've
> just checked playing with TTL on pings.

Thanks.

Antony.

-- 
"Note: Windows 98, Windows 98SE and Windows 95 are not affected by [MS
Blaster].   However, these products are no longer supported.   Users of these
products are strongly encouraged to upgrade to later versions."

(which *are* affected by MS Blaster...)

http://www.microsoft.com/security/security_bulletins/ms03-026.asp

                                                     Please reply to the list;
                                                           please don't CC me.