All of lore.kernel.org
 help / color / mirror / Atom feed
* Query: iptables Conflict Policy Avoidance/Reduction
@ 2009-06-03 18:48 william fitzgerald
  2009-06-04 12:13 ` Gáspár Lajos
  0 siblings, 1 reply; 3+ messages in thread
From: william fitzgerald @ 2009-06-03 18:48 UTC (permalink / raw)
  To: Mail List - Netfilter

Dear all,

Configuring a larger firewall policy is error prone. Rules can be redundant to 
others, rules can be shadowed by proceeding rules whereby they are never activated 
and so forth.

How do conflicts arise when the iptable rules use the NIC interface option.

Simple Redundancy example:

Internet ---> (eth1)Firewall ---> Web Server
Intranet ---> (eth0)

Firewall with two interfaces eth1 (Internet facing) and eth0 (Intranet LAN 
facing), eth+ is the wildcard for both.

Rule 1: iptables -A FORWARD -i eth+ -s 0/0 -d 192.168.1.2 --dport 80 -j ACCEPT
Rule 2: iptables -A FORWARD -i eth+ -s 192.168.1.0/24 -d 192.168.1.2 --dport 80 -j 
ACCEPT

In the above scenario, Rule 2 is REDUNDANT to Rule 1 in that, the source IP of 
Rule 2 is covered by the source IP of Rule 1.

However, aren't these generic style rules not considered *best practice* given 
that the above rules when applied to all interfaces could allow IP Spoofing of 
reserved IP address range 192.168.1.0/24

So in order to avoid spoofing, one has to create the following two rules and apply 
them to specific interfaces.
iptables -A FORWARD -i eth1 -s 0/0 -d 192.168.1.2 --dport 80 -j ACCEPT
iptables -A FORWARD -i eth0 -s 192.168.1.0/24 -d 192.168.1.2 --dport 80 -j ACCEPT


Simple Shadowed example:

Internet ---> (eth1)Firewall ---> Web Server
Partner ---> (eth1) Firewall ---> VPN Server

Default Policy: iptables -P FORWARD DROP
Rule 1: iptables -A FORWARD -i eth1 -s 0/0 -d webIP --dport 80 -j ACCEPT
Rule 2: iptables -A FORWARD -i eth1 -s 0/0 -d vpnIP --dport 22 -j DROP
Rule 3: iptables -A FORWARD -i eth1 -s partnerIP -d vpnIP --dport 22 -j ACCEPT

Rule 2 blocks the intended partners access via Rule 3. A simple swap of rule 2 and 
rule 3 prevents this. But why bother with Rule 2 in the first place, given the 
default policy is DROP and so there is no way for anyone else other than the 
partners to get access (Rule 3). Looking at various example policies on the web, I 
find that there are explicitly defined DROP rules in conjunction with ACCEPT rules 
like rules 2 and 3 above. Its as if, one does not trust the default policy.

I am just wondering, if all rules are applied to specific Interfaces, specific 
destination IP address, specific destination ports  and some trust in the default 
policy would a lot of the possible policy conflicts be ruled out?

If anyone could provide me with some scenarios/examples to the contrary that would 
be great.

It would even be better if I could get a hold of some real firewall policies 
(anonymised internal IP ranges of course).

I have done some formal modelling on detecting conflicts with more complex 
scenarios then above on an already defined policy.

But lately its dawning on me that formal synthesis or creation of rules *may* 
completely rule out such conflicts. Of course the assumption is that you begin 
with an empty rule-less policy.

For example (trivial scenario):
Using formal logic to generate iptables syntax based on the fact that its best 
practice to allow both public and lan ip addresses access to the public web server.

Inface  SrcIP   SrcPort  DstIP  DstPort Target
eth1    anyIP   >1024    webIP    80    Accept
eth0    lanIP   >1024    webIP    80    Accept

Where the above is much better than:
SrcIP   SrcPort  DstIP  DstPort Target
anyIP   >1024    webIP    80    Accept

And where the above is much better than:
SrcIP   SrcPort  DstIP  DstPort Target
anyIP   >1024    dmz    80    Accept

It appears to me at least, that creating rules to be more specific than generic, 
while it increases the number rules, is probably a better solution more likely to 
be free of conflicts.

Again all feedback is welcome. Perhaps reality is not as black and white!

regards,
Will.

^ permalink raw reply	[flat|nested] 3+ messages in thread
end of thread, other threads:[~2009-06-04 16:11 UTC | newest]

Thread overview: 3+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
2009-06-03 18:48 Query: iptables Conflict Policy Avoidance/Reduction william fitzgerald
2009-06-04 12:13 ` Gáspár Lajos
2009-06-04 16:11   ` william fitzgerald

This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.