raw socket packet and iptables

raw socket packet and iptables

[Xinwen - Fu]

Hi, All,

	I want  to know how a raw packet passes the chain of iptables.

	Here are the iptables chains

--->PRE------>[ROUTE]--->FWD---------->POST------>
        Conntrack    |       Filter   ^    NAT (Src)
        Mangle       |                |    Conntrack
        NAT (Dst)    |             [ROUTE]
        (QDisc)      v                |
                     IN Filter       OUT Conntrack
                     |  Conntrack     ^  Mangle
                     |                |  NAT (Dst)
                     v                |  Filter


	So how a raw packet go through these chains?

	Thanks!!

Xinwen Fu

Re: raw socket packet and iptables

[Rob Landley]

On Sunday 03 February 2002 01:45 pm, Xinwen - Fu wrote:
> Hi, All,
>
> 	I want  to know how a raw packet passes the chain of iptables.
>
> 	Here are the iptables chains
>
> --->PRE------>[ROUTE]--->FWD---------->POST------>
>         Conntrack    |       Filter   ^    NAT (Src)
>         Mangle       |                |    Conntrack
>         NAT (Dst)    |             [ROUTE]
>         (QDisc)      v                |
>                      IN Filter       OUT Conntrack
>
>                      |  Conntrack     ^  Mangle
>                      |
>                      |                |  NAT (Dst)
>
>                      v                |  Filter
>
>
> 	So how a raw packet go through these chains?


Well, from trial and error and a lot of documentation reading, I eventually 
worked out that a TCP/IP packet basically seems to do this:

--->pre--->forward--->post--->
     |                           ^
     |                           |
     v                          |
     input->local ports->output

I'd like to point out that the last arrow should point from "output" to 
"post", since kmail apparently is not using a fixed with font, and I can't 
figure out how to get it to do so.  (I did figure out how to get it to use a 
korean, chinese, or cyrillic encoding, but not monospaced.  Sigh...)

So in prerouting, the packet is either forwarded on to the forwarding chain 
(if it's not for this box) or to the input chain (if it's for a daemon on 
this box).  Forwarding never sees packets locally generated on this box, they 
go into the output chain and then get sent on to postrouting (which is where 
forwarding also feeds into).

It took a little trial and error to work this out, by the way.  It's entirely 
ossibly I'm wrong (since I don't think the above agrees with the 
documentation), but at the same time it works and survives specific behavior 
testing, so... :)  The tables are fairly arbitrarily broken into "NAT" tables 
and non-NAT tables.  Oh, and one of the chains (output, I think) exists in 
both nat and non-nat versions.  To this day, I have no idea why...

> 	Thanks!!
>
> Xinwen Fu

If the above doesn't help, this might:

http://netfilter.samba.org/unreliable-guides/

Rob

packet created by local raw socket

[Xinwen - Fu]

Rob, 
	Thanks for your reply! It's very good! 


	In fact my problem is simpler to you( the
last email is not clear):
	
	Now I create a raw socket(SOCK_RAW) on a local machine, construct
a ICMP packet and send it out. So what queues will this packet go through?

	I tested it and it seems that this packet first goes to OUTPUT
queue. is that right? If so, then ip stack's interface to RAW socket
should be below the function of appending IP header to a transport layer 
datagram but above the routing decision function and also above the
OUTPUT queue, am I right?

Thanks!

Fu	
	


	



Xinwen Fu


On Sun, 3 Feb 2002, Rob Landley wrote:

> On Sunday 03 February 2002 01:45 pm, Xinwen - Fu wrote:
> > Hi, All,
> >
> > 	I want  to know how a raw packet passes the chain of iptables.
> >
> > 	Here are the iptables chains
> >
> > --->PRE------>[ROUTE]--->FWD---------->POST------>
> >         Conntrack    |       Filter   ^    NAT (Src)
> >         Mangle       |                |    Conntrack
> >         NAT (Dst)    |             [ROUTE]
> >         (QDisc)      v                |
> >                      IN Filter       OUT Conntrack
> >
> >                      |  Conntrack     ^  Mangle
> >                      |
> >                      |                |  NAT (Dst)
> >
> >                      v                |  Filter
> >
> >
> > 	So how a raw packet go through these chains?
> 
> 
> Well, from trial and error and a lot of documentation reading, I eventually 
> worked out that a TCP/IP packet basically seems to do this:
> 
> --->pre--->forward--->post--->
>      |                           ^
>      |                           |
>      v                          |
>      input->local ports->output
> 
> I'd like to point out that the last arrow should point from "output" to 
> "post", since kmail apparently is not using a fixed with font, and I can't 
> figure out how to get it to do so.  (I did figure out how to get it to use a 
> korean, chinese, or cyrillic encoding, but not monospaced.  Sigh...)
> 
> So in prerouting, the packet is either forwarded on to the forwarding chain 
> (if it's not for this box) or to the input chain (if it's for a daemon on 
> this box).  Forwarding never sees packets locally generated on this box, they 
> go into the output chain and then get sent on to postrouting (which is where 
> forwarding also feeds into).
> 
> It took a little trial and error to work this out, by the way.  It's entirely 
> ossibly I'm wrong (since I don't think the above agrees with the 
> documentation), but at the same time it works and survives specific behavior 
> testing, so... :)  The tables are fairly arbitrarily broken into "NAT" tables 
> and non-NAT tables.  Oh, and one of the chains (output, I think) exists in 
> both nat and non-nat versions.  To this day, I have no idea why...
> 
> > 	Thanks!!
> >
> > Xinwen Fu
> 
> If the above doesn't help, this might:
> 
> http://netfilter.samba.org/unreliable-guides/
> 
> Rob
> 

SOCK_PACKET bypasses IPTABLES queue?

[Xinwen - Fu]

Rob,
	Another problem:
	Will a packet from SOCK_PACKET socket bypass all the queues of
IPTABLES?

	Thanks!
	

Xinwen Fu


On Sun, 3 Feb 2002, Rob Landley wrote:

> On Sunday 03 February 2002 01:45 pm, Xinwen - Fu wrote:
> > Hi, All,
> >
> > 	I want  to know how a raw packet passes the chain of iptables.
> >
> > 	Here are the iptables chains
> >
> > --->PRE------>[ROUTE]--->FWD---------->POST------>
> >         Conntrack    |       Filter   ^    NAT (Src)
> >         Mangle       |                |    Conntrack
> >         NAT (Dst)    |             [ROUTE]
> >         (QDisc)      v                |
> >                      IN Filter       OUT Conntrack
> >
> >                      |  Conntrack     ^  Mangle
> >                      |
> >                      |                |  NAT (Dst)
> >
> >                      v                |  Filter
> >
> >
> > 	So how a raw packet go through these chains?
> 
> 
> Well, from trial and error and a lot of documentation reading, I eventually 
> worked out that a TCP/IP packet basically seems to do this:
> 
> --->pre--->forward--->post--->
>      |                           ^
>      |                           |
>      v                          |
>      input->local ports->output
> 
> I'd like to point out that the last arrow should point from "output" to 
> "post", since kmail apparently is not using a fixed with font, and I can't 
> figure out how to get it to do so.  (I did figure out how to get it to use a 
> korean, chinese, or cyrillic encoding, but not monospaced.  Sigh...)
> 
> So in prerouting, the packet is either forwarded on to the forwarding chain 
> (if it's not for this box) or to the input chain (if it's for a daemon on 
> this box).  Forwarding never sees packets locally generated on this box, they 
> go into the output chain and then get sent on to postrouting (which is where 
> forwarding also feeds into).
> 
> It took a little trial and error to work this out, by the way.  It's entirely 
> ossibly I'm wrong (since I don't think the above agrees with the 
> documentation), but at the same time it works and survives specific behavior 
> testing, so... :)  The tables are fairly arbitrarily broken into "NAT" tables 
> and non-NAT tables.  Oh, and one of the chains (output, I think) exists in 
> both nat and non-nat versions.  To this day, I have no idea why...
> 
> > 	Thanks!!
> >
> > Xinwen Fu
> 
> If the above doesn't help, this might:
> 
> http://netfilter.samba.org/unreliable-guides/
> 
> Rob
> 

Re: packet created by local raw socket

[Rob Landley]

On Sunday 03 February 2002 07:24 pm, Xinwen - Fu wrote:
> Rob,
> 	Thanks for your reply! It's very good!
>
>
> 	In fact my problem is simpler to you( the
> last email is not clear):
>
> 	Now I create a raw socket(SOCK_RAW) on a local machine, construct
> a ICMP packet and send it out. So what queues will this packet go through?

Locally generated packets seem to go through the tests in the output table 
first, then on to postrouting.  I didn't think the type of the locally 
generated packet mattered.  (I know UDP, TCP, or ICMP don't...)

> 	I tested it and it seems that this packet first goes to OUTPUT
> queue. is that right?

Sounds about right.

> If so, then ip stack's interface to RAW socket
> should be below the function of appending IP header to a transport layer
> datagram but above the routing decision function and also above the
> OUTPUT queue, am I right?

If you asked for a raw socket, the system won't append an IP header to it for 
you.  You asked it not to.

It has to come before the routing decision.  Otherwise how does it know where 
to send it?  (You might have more than one network interface in the machine.  
Two ethernet cards, or ethernet and ppp...)

> Thanks!
>
> Fu

Have you tried the "logging" target?  It's loads of fun for this sort of 
thing...

Rob

Re: packet created by local raw socket

[Andi Kleen]

landley@trommello.org (Rob Landley) writes:

> If you asked for a raw socket, the system won't append an IP header to it for 
> you.  You asked it not to.

I guess you mean prepend instead of append. 

In fact the raw sockets add an IP header, unless you specify 
IPPROTO_RAW or IP_HDRINCL. Both are discouraged. 

-Andi

packet_socket = socket(PF_PACKET, int socket_type, int protocol);

[Xinwen - Fu]

Rob, 
	PF_PACKET socket should bypass IPTABLES queue, I think.?
	http://docs.csoft.net/cgi-bin/man.cgi?section=7&topic=packet

	I will try logging target and will enjoy it.
	
	Thanks!

Xinwen Fu

P.S.
	This semester (I'm still a student, old. Ah, shameful) I took a
security class. Our (I'm in a black group) task is to hack a Redhat 7.2
linux
machine cnotrolled by a golden group. If you'd like, I can tell you what
we are doing step by step and
I think you can give a hand to crack these bad guys' machine...



On Sun, 3 Feb 2002, Xinwen - Fu wrote:

> Rob,
> 	Another problem:
> 	Will a packet from SOCK_PACKET socket bypass all the queues of
> IPTABLES?
> 
> 	Thanks!
> 	
> 
> Xinwen Fu
> 
> 
> On Sun, 3 Feb 2002, Rob Landley wrote:
> 
> > On Sunday 03 February 2002 01:45 pm, Xinwen - Fu wrote:
> > > Hi, All,
> > >
> > > 	I want  to know how a raw packet passes the chain of iptables.
> > >
> > > 	Here are the iptables chains
> > >
> > > --->PRE------>[ROUTE]--->FWD---------->POST------>
> > >         Conntrack    |       Filter   ^    NAT (Src)
> > >         Mangle       |                |    Conntrack
> > >         NAT (Dst)    |             [ROUTE]
> > >         (QDisc)      v                |
> > >                      IN Filter       OUT Conntrack
> > >
> > >                      |  Conntrack     ^  Mangle
> > >                      |
> > >                      |                |  NAT (Dst)
> > >
> > >                      v                |  Filter
> > >
> > >
> > > 	So how a raw packet go through these chains?
> > 
> > 
> > Well, from trial and error and a lot of documentation reading, I eventually 
> > worked out that a TCP/IP packet basically seems to do this:
> > 
> > --->pre--->forward--->post--->
> >      |                           ^
> >      |                           |
> >      v                          |
> >      input->local ports->output
> > 
> > I'd like to point out that the last arrow should point from "output" to 
> > "post", since kmail apparently is not using a fixed with font, and I can't 
> > figure out how to get it to do so.  (I did figure out how to get it to use a 
> > korean, chinese, or cyrillic encoding, but not monospaced.  Sigh...)
> > 
> > So in prerouting, the packet is either forwarded on to the forwarding chain 
> > (if it's not for this box) or to the input chain (if it's for a daemon on 
> > this box).  Forwarding never sees packets locally generated on this box, they 
> > go into the output chain and then get sent on to postrouting (which is where 
> > forwarding also feeds into).
> > 
> > It took a little trial and error to work this out, by the way.  It's entirely 
> > ossibly I'm wrong (since I don't think the above agrees with the 
> > documentation), but at the same time it works and survives specific behavior 
> > testing, so... :)  The tables are fairly arbitrarily broken into "NAT" tables 
> > and non-NAT tables.  Oh, and one of the chains (output, I think) exists in 
> > both nat and non-nat versions.  To this day, I have no idea why...
> > 
> > > 	Thanks!!
> > >
> > > Xinwen Fu
> > 
> > If the above doesn't help, this might:
> > 
> > http://netfilter.samba.org/unreliable-guides/
> > 
> > Rob
> > 
> 
> 

Re: packet_socket = socket(PF_PACKET, int socket_type, int protocol);

[Rob Landley]

On Sunday 03 February 2002 09:35 pm, Xinwen - Fu wrote:
> Rob,

> I think you can give a hand to crack these bad guys' machine...

Nope, sorry.

Rob