[Fwd: ACCEPT/DROP]

[Fwd: ACCEPT/DROP]

[Venkatesh Prasad Ranganath]

Hi,

I was looking into the iptables implementation and was intrigued about 
how iptables would handle a situation in which we have identical rules 
except for their targets which are contradicting, say ACCEPT and DROP. 
 By looking at ipt_do_table() function it seems that the first 
non-IPT_RETURN  verdict from any standard target will end the traversal 
of a chain of a table, which seems to be a bit odd.  First, such 
conflicting rules must not be allowed.  Even beyond, this fails in the 
situation where you have a dropping rule added after an accepting rule.

For example, a packet from m.n.o.p to a.b.c.d would be accepted at 
a.b.c.d because of the first rule, although it had to be dropped 
according to the second rule.   And this would result because of the 
order in which the rules are added to the table.

iptables -A INPUT -d a.b.c.d -j ACCEPT
iptables -A INPUT -s m.n.o.p -j DROP

Is my understanding correct?  If so, I am curious to know how nf-hipac 
behaves in such situations?

waiting for reply,

-- 

Venkatesh Prasad Ranganath,
Dept. Computing and Information Science,
Kansas State University, US.
web: http://www.cis.ksu.edu/~rvprasad

Re: [Fwd: ACCEPT/DROP]

[Markus Schaber]

Hallo,

Venkatesh Prasad Ranganath <vranganath@cox.net> schrieb:

> I was looking into the iptables implementation and was intrigued about
> how iptables would handle a situation in which we have identical rules
> except for their targets which are contradicting, say ACCEPT and DROP.

This is a problem that _must_ be solved by the human being, because
equality of rules (as for other computer code) _cannot_ be computed.

(Equality of code is a broad area in computer science, e. G. a compiler
maker should be able to prove that the code after the optimization is
equal to the code before. It there is no general algorithm to prove the
equality of code, and it is proven that such an algorithm cannot exist,
except for very special cases. If you're interested in this subject, I
can give you some sources.)
 
>  By looking at ipt_do_table() function it seems that the first 
> non-IPT_RETURN  verdict from any standard target will end the
> traversal of a chain of a table, which seems to be a bit odd.  First,
> such conflicting rules must not be allowed.  Even beyond, this fails
> in the situation where you have a dropping rule added after an
> accepting rule.

Yes, and that's how iptables works. The creator of rules has to put the
rules into the correct order (that's why one can insert and remove rules
at arbitrary points).

> For example, a packet from m.n.o.p to a.b.c.d would be accepted at 
> a.b.c.d because of the first rule, although it had to be dropped 
> according to the second rule.   And this would result because of the 
> order in which the rules are added to the table.
> 
> iptables -A INPUT -d a.b.c.d -j ACCEPT
> iptables -A INPUT -s m.n.o.p -j DROP
> 
> Is my understanding correct?

Yes.

This is because your rules above say that traffic to a.b.c.d has to be
accepted from everywhere, and for all other possible destinations, drop
traffic from m.n.o.p.

This makes sense e. G. in case m.n.o.p is a portscanner, and you want to
block him except for your mail server a.b.c.d, so that he can answer on
your mailed complaint.

If you want to drop traffic for m.n.o.p even to a.b.c.d, you simply
change the order of the above rules.

>  If so, I am curious to know how nf-hipac behaves in such situations?

I didn't look into nf-hipac this far, but I don't think they can be much
different in this way.

Gruß,
Markus

-- 
Markus Schaber - http://www.schabi.de/

Schabi's Flohmarkt unter http://schabi.de/flohmarkt

Re: [Fwd: ACCEPT/DROP]

[Patrick McHardy]

Hi,

On Sat, 21 Dec 2002, Markus Schaber wrote:

> Hallo,
> 
> Venkatesh Prasad Ranganath <vranganath@cox.net> schrieb:
> 
> > I was looking into the iptables implementation and was intrigued about
> > how iptables would handle a situation in which we have identical rules
> > except for their targets which are contradicting, say ACCEPT and DROP.
> 
> This is a problem that _must_ be solved by the human being, because
> equality of rules (as for other computer code) _cannot_ be computed.

This may be true for code, but iptables rules describe sets of packets
and you can detect identical rules (or rules which describe 
subsets/supersets) if you have knowledge what a particular match matches.
 
> (Equality of code is a broad area in computer science, e. G. a compiler
> maker should be able to prove that the code after the optimization is
> equal to the code before. It there is no general algorithm to prove the
> equality of code, and it is proven that such an algorithm cannot exist,
> except for very special cases. If you're interested in this subject, I
> can give you some sources.)

I am interested, please point me where to read more about this ..

Bye,
Patrick

Re: [Fwd: ACCEPT/DROP]

[Miguel Amador L.]

Me too...
I am interested in the sources..

On Tue, 24 Dec 2002, Patrick McHardy wrote:

> Hi,
>
> On Sat, 21 Dec 2002, Markus Schaber wrote:
>
> > Hallo,
> >
> > Venkatesh Prasad Ranganath <vranganath@cox.net> schrieb:
> >
> > > I was looking into the iptables implementation and was intrigued about
> > > how iptables would handle a situation in which we have identical rules
> > > except for their targets which are contradicting, say ACCEPT and DROP.
> >
> > This is a problem that _must_ be solved by the human being, because
> > equality of rules (as for other computer code) _cannot_ be computed.
>
> This may be true for code, but iptables rules describe sets of packets
> and you can detect identical rules (or rules which describe
> subsets/supersets) if you have knowledge what a particular match matches.
>
> > (Equality of code is a broad area in computer science, e. G. a compiler
> > maker should be able to prove that the code after the optimization is
> > equal to the code before. It there is no general algorithm to prove the
> > equality of code, and it is proven that such an algorithm cannot exist,
> > except for very special cases. If you're interested in this subject, I
> > can give you some sources.)
>
> I am interested, please point me where to read more about this ..
>
> Bye,
> Patrick
>
>
>


 Miguel Angel Amador Lorca    |    mailto:amador@puc.cl
 "No sabiamos que era imposible,  por eso lo hicimos ... "

Re: [Fwd: ACCEPT/DROP]

[Thomas Heinz]

Hi Patrick

You wrote:
> This may be true for code, but iptables rules describe sets of packets

This is true for the basic cases only. In general the matches of a rule
must be considered to be arbitrary packet action (ACCEPT, DROP,
CONTINUE) returning functions that may even return different actions for
the same packet. The only constraint for matches is that they should
work read-only on the packet content, i.e. not modify it.

Of course your statement is correct in the context of the classical
packet classification problem.


Thomas

Re: [Fwd: ACCEPT/DROP]

[Markus Schaber]

Hi,

Thomas Heinz wrote:

> You wrote:
> > This may be true for code, but iptables rules describe sets of
> > packets
> 
> This is true for the basic cases only. In general the matches of a
> rule must be considered to be arbitrary packet action (ACCEPT, DROP,
> CONTINUE) returning functions that may even return different actions
> for the same packet. The only constraint for matches is that they
> should work read-only on the packet content, i.e. not modify it.

That's true, as examples one may see the state matches, or the random
match.


Markus

-- 
Schabi's Flohmarkt: http://www.uni-ulm.de/~s_mschab/flohmarkt/

Der Dienstweg ist die Verbindung der Sackgasse mit dem Holzweg!
[DoLi in unibwm.studium]