Iptables :: priority of rules

John DeDourek dedourek at unb.ca
Fri Feb 23 23:20:10 UTC 2007


Gordon Messmer wrote:
> Luc MAIGNAN wrote:
>>
>> So i Wrote :
>>
>> (1) : iptables -I INPUT -p tcp -s 192.168.0.0/24 --dport ssh -j ACCEPT
>> (2) : iptables -I INPUT -p tcp -s ! x.x.x.x --dport ssh -j DROP
>
> Double negatives are bad in english, and they're bad in software, too.
>
> You probably wanted to build your rules like this:
>
> iptables -A INPUT -p tcp -s 192.168.0.0/24 --dport ssh -j ACCEPT
> iptables -A INPUT -p tcp -s ! x.x.x.x --dport ssh -j DROP
>
> But, even if that was your intention, a packet from x.x.x.x won't 
> necessarily be accepted by those rules.  The first rule doesn't match, 
> so the packet continues through the chain.  The second rule doesn't 
> match, either, so the packet continues through the chain.  The packet 
> may, then, match a later rule that drops it, or it may hit the policy, 
> which you've stated is DENY.
>
> When your policy is DENY, you probably want to accept related packets 
> first, then accept any new packets for sources or destinations that 
> you want to allow, and allow the policy to catch everything else.
>
I'll also note, as in my previous message, that when using -A,
which puts the rules at the end of the list (chain) of INPUT
rules, you need to know all the rules that are ahead of the
rules you're adding.  If it's the standard RedHat firewall,
I believe that a previous rule directs all the packets to
a subsidiary chain which handles all packets without returning.
It ends with a rule to REJECT all packets.
(That's from an older release; they may have changed it in newer
releases.)
That being the case, note that neither the POLICY of the INPUT
chain, nor rules appended to the chain after the rule that
"branches" to the subsidiary chain have no effect.


Unfortunately, the original poster only indicated the rules that
were added at the beginning of the chain ("-I"); several subsequent
posters recommended the ("-A") to append rules to the end of the
chain.  Other existing rules in the chain were not described.




More information about the fedora-list mailing list