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
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
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
>
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
>
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
[email protected] (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
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
> >
>
>
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