detect original chain after jump?

detect original chain after jump?

[Richard Hector]

Hi,

Mostly, people seem to write their filter chains splitting first by
interface and/or address, then by protocol/port.

I'm experimenting with doing it the other way round: I want to process
all the ssh traffic in one chain, then all the smtp in another etc.

This means that early on, I have something like:

iptables -A INPUT -j protocol
iptables -A FORWARD -j protocol

iptables -A protocol -p tcp --dport 22 -j ssh

But then I get a bit stuck. I need to then do different things depending
on the source and destination - which includes whether this packet is
arriving locally or being forwarded. Therefore it would be useful to
know whether this packet started out in the INPUT or FORWARD chain - but
that info seems to have been lost with the jump.

Is there any way to regain that?

Many thanks,

Richard

Re: detect original chain after jump?

[Antony Stone]

On Saturday 27 March 2004 1:38 pm, Richard Hector wrote:

> This means that early on, I have something like:
>
> iptables -A INPUT -j protocol
> iptables -A FORWARD -j protocol
>
> iptables -A protocol -p tcp --dport 22 -j ssh
>
> But then I get a bit stuck. I need to then do different things depending
> on the source and destination - which includes whether this packet is
> arriving locally or being forwarded. Therefore it would be useful to
> know whether this packet started out in the INPUT or FORWARD chain - but
> that info seems to have been lost with the jump.
>
> Is there any way to regain that?

Surely the destination address is all you need for this?

If it's an address local to the machine, the packet is addressed to the 
machine, therefore it came through the INPUT chain.

If the destination address is not local, the packet isn't addressed to the 
machine, therefore it's going somewhere else, therefore it came through the 
FORWARD chain.

Are you sure that combining INPUT and FORWARD rules like this is really what 
you want to do?

I would have thought the two were sufficiently different (what traffic you 
allow in to your firewall, compared to what traffic you allow through it to 
elsewhere) that it would be worth writing separate rulesets for the two.

However, YMMV as they say....

Regards,

Antony.

-- 
Never write it in Perl if you can do it in Awk.
Never do it in Awk if sed can handle it.
Never use sed when tr can do the job.
Never invoke tr when cat is sufficient.
Avoid using cat whenever possible.

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

Re: detect original chain after jump?

[Richard Hector]

On Sat, Mar 27, 2004 at 01:51:32PM +0000, Antony Stone wrote:
> On Saturday 27 March 2004 1:38 pm, Richard Hector wrote:
> 
> > This means that early on, I have something like:
> >
> > iptables -A INPUT -j protocol
> > iptables -A FORWARD -j protocol
> >
> > iptables -A protocol -p tcp --dport 22 -j ssh
> >
> > But then I get a bit stuck. I need to then do different things depending
> > on the source and destination - which includes whether this packet is
> > arriving locally or being forwarded. Therefore it would be useful to
> > know whether this packet started out in the INPUT or FORWARD chain - but
> > that info seems to have been lost with the jump.
> >
> > Is there any way to regain that?
> 
> Surely the destination address is all you need for this?

I suppose so. It's just that the INPUT chain is a handy way to group all the
local interfaces and addresses. Without it, I multiply the number of rules by
the number of possible local addresses that could be used.

> Are you sure that combining INPUT and FORWARD rules like this is really what 
> you want to do?

No :-)

However, that's why I'm experimenting; I'll see what version looks simplest
and most intuitive of the likely possibilities I can think of.

> I would have thought the two were sufficiently different (what traffic you 
> allow in to your firewall, compared to what traffic you allow through it to 
> elsewhere) that it would be worth writing separate rulesets for the two.

That may well be true - especially if the firewall is sufficiently
dedicated to its firewalling. Mine is also a bounce point for SSH, a
DHCP server and an NTP server; not quite as clean as it could/should be.

Many thanks,

Richard

Re: detect original chain after jump?

[Antony Stone]

On Saturday 27 March 2004 2:20 pm, Richard Hector wrote:

> On Sat, Mar 27, 2004 at 01:51:32PM +0000, Antony Stone wrote:
> > On Saturday 27 March 2004 1:38 pm, Richard Hector wrote:
> > > This means that early on, I have something like:
> > >
> > > iptables -A INPUT -j protocol
> > > iptables -A FORWARD -j protocol
> > >
> > > iptables -A protocol -p tcp --dport 22 -j ssh
> > >
> > > But then I get a bit stuck. I need to then do different things
> > > depending on the source and destination - which includes whether this
> > > packet is arriving locally or being forwarded. Therefore it would be
> > > useful to know whether this packet started out in the INPUT or FORWARD
> > > chain - but that info seems to have been lost with the jump.
> > >
> > > Is there any way to regain that?
> >
> > Surely the destination address is all you need for this?
>
> I suppose so. It's just that the INPUT chain is a handy way to group all
> the local interfaces and addresses. Without it, I multiply the number of
> rules by the number of possible local addresses that could be used.

Well, okay then - how about using the MARK target to mark packets with one 
value in INPUT and a different value in FORWARD, and then check the marked 
value in your user-defined chain to see how the packet got there?

Look up the MARK target and the -m mark match for more info.

Regards,

Antony.

-- 
Christmas was just an opportunity to upgrade to kernel 2.6 while no-one was 
around to notice the downtime.

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

Re: detect original chain after jump?

[rrecaba]

Hello all,

On Sat, 27 Mar 2004, Antony Stone wrote:

> Well, okay then - how about using the MARK target to mark packets with one
> value in INPUT and a different value in FORWARD, and then check the marked
> value in your user-defined chain to see how the packet got there?

I was meaning to ask about this. In such scenario he would have to place
two rules with identical matches, one for the mark, the other for the jump
to his chain. So what bothers me a little is that double match.

I was wondering, is it better to write just one rule with the appropiate
match (thus making only one match) and a jump to a "temporary" chain that
has the two abovementioned rules, but with no matches at all (i.e.
an unconditional match)?

I guess what I am asking is, what is more expensive in terms of
performance, a jump to a different chain, or a double match?...

Regards,
Ruben.

>
> Look up the MARK target and the -m mark match for more info.
>
> Regards,
>
> Antony.
>
> --
> Christmas was just an opportunity to upgrade to kernel 2.6 while no-one was
> around to notice the downtime.
>
>                                                      Please reply to the list;
>                                                            please don't CC me.
>
>
>

Re: detect original chain after jump?

[Antony Stone]

On Saturday 27 March 2004 3:07 pm, rrecaba@usb.ve wrote:

> Hello all,
>
> On Sat, 27 Mar 2004, Antony Stone wrote:
> > Well, okay then - how about using the MARK target to mark packets with
> > one value in INPUT and a different value in FORWARD, and then check the
> > marked value in your user-defined chain to see how the packet got there?
>
> I was meaning to ask about this. In such scenario he would have to place
> two rules with identical matches, one for the mark, the other for the jump
> to his chain. So what bothers me a little is that double match.

Yes, however unless he's dealing with a *high* bandwidth connection, it's 
unlikely that netfilter processing efficiency is going to be a bottleneck.

> I was wondering, is it better to write just one rule with the appropiate
> match (thus making only one match) and a jump to a "temporary" chain that
> has the two abovementioned rules, but with no matches at all (i.e.
> an unconditional match)?

Well, I'm of the opinion that it's doubtful whether trying to combine INPUT 
and FORWARD like this is useful anyway, however as Richard said, he's 
experimenting, so he'll find out which seems best for his needs....

> I guess what I am asking is, what is more expensive in terms of
> performance, a jump to a different chain, or a double match?...

Remember that all of this discussion applies only to the first packet of each 
connection (assuming the machine is doing stateful processing with an 
"ESTABLISHED,RELATED" rule at the top of the FORWARD and INPUT chains - if 
not, then he'll have serious problems making the system (a) work and (b) 
secure, at the same time), therefore any inefficiency is probably moot.

Regards,

Antony.

-- 
This email is intended for the use of the individual addressee(s) named above 
and may contain information that is confidential, privileged or unsuitable 
for overly sensitive persons with low self-esteem, no sense of humour, or 
irrational religious beliefs.

If you have received this email in error, you are required to shred it 
immediately, add some nutmeg, three egg whites and a dessertspoonful of 
caster sugar.   Whisk until soft peaks form, then place in a warm oven for 40 
minutes.   Remove promptly and let stand for 2 hours before adding some 
decorative kiwi fruit and cream.   Then notify me immediately by return email 
and eat the original message.

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

Double Match or jump (was Re: detect original chain after jump?)

[rrecaba]

Hello again,

So i decided to ask this again cause it is actually not related to the
original post...

Supose I want to log and drop a packet with certain criteria. Actually,
imagine that I want to send the logged info to a program in userspace. I
have seen recommendations in the lines of:

iptables <whatever> <MATCH> -j ULOG
iptables <whatever> <MATCH> -J DROP

That is doing a double match. So I wanted to ask: has anyone done any
experimentation to see when exactly is it better to do another chain,
call it "temp", to do the ULOG and DROP unconditionally, and call it from
a single one that does the match?

iptables <whatever> <MATCH> -j temp

iptables -A temp -j ULOG
iptables -A temp -j DROP

Of course, it cant be related to the final jumps, so I would expect the
drop and ulog not being important. I would conjecture that what is important
is the actually the MATCH. If the MATCH is very complex, is it
better to go the second way. Has anyone done experiments on this?

The reason this is important to me is because I am working on a user level
program that is supposed to analize and generate rules dynamically. I am
working on a very general multipurpose language and specification... so, I
want to be able to decide what kind of rules I am suppose to generate in
different scenarios ... kind of like bringing iptables alive... or
actually giving it a life of its own... :)

Regards,
Ruben.