Re: Query: iptables Conflict Policy Avoidance/Reduction

[william fitzgerald <wfitzgerald@tssg.org>]

Thanks G치sp치r (aka Swifty),

I was having one of those moments where you think, you think, you did'nt grasp 
something! Like, did I book those flights on the correct days syndrome, so you 
start doubting yourself ;-)


G치sp치r Lajos wrote:
> Hi Will.!
> 
> On Wed, 03 Jun 2009 19:48:06 +0100, william fitzgerald
> <wfitzgerald@tssg.org> wrote:
>> Dear all,
>  
>> 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.
> 
> Without any NAT-ing the firewall would never see such packets... (Sending
> packets to the same subnet should not be routed.)
> 

Agreed. I always make the assumption that NAT-rules are independent of 
filter-rules and that that NAT up and running. Sorry, I should of made that 
clearer in my original post.

>> 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
> 
> IP Spoofing should be done by specifying ALLOWED LOCAL IP ranges (and drop
> everything else) and specifying DISALLOWED REMOTE (private) IP ranges (and
> accept everything else).
> 

In the below examples you gave, I was trying to think of a quick way to avoid 
these whereby you implicitly deny these kind of rules with the "default policy".

But I see how allowing all IP addresses (0/0) to a web server for example is also 
inclusive of RFC1918, RFC 3330 and NIST-800-41 best practice private-resevered IP 
address countermeasures. And so the need to be implemented on the external 
interface. It was one of those days where I was suffering from brain paralysis ;-)

> For example in RAW chain PREROUTING table:
> 
>     $table -P $chain DROP
> 
>     create_subchain PRE_PPP0
>     $table -A $chain -j $subchain -i $PPP0_IF -d $PPP0_IP
> 
>      $table -A $subchain -j DROP -s 10.0.0.0/8 -m comment --comment
> 'PRIVATE USE'                       #RFC1918
>      $table -A $subchain -j DROP -s 14.0.0.0/8 -m comment --comment 'PUBLIC
> DATA NETWORKS'              #RFC1700, page 181
>      $table -A $subchain -j DROP -s 24.0.0.0/8 -m comment --comment 'CABLE
> TELEVISION NETWORKS'         #NOT SURE!!!
>      $table -A $subchain -j DROP -s 39.0.0.0/8 -m comment --comment
> 'RESERVED'                          #RFC1797
>      $table -A $subchain -j DROP -s 127.0.0.0/8 -m comment --comment
> 'LOOPBACK'                         #RFC1700, page 5
>      $table -A $subchain -j DROP -s 128.0.0.0/16 -m comment --comment
> 'RESERVED'
>      $table -A $subchain -j DROP -s 169.254.0.0/16 -m comment --comment
> 'LINK LOCAL'
>      $table -A $subchain -j DROP -s 172.16.0.0/12 -m comment --comment
> 'PRIVATE USE'                    #RFC1918
>      $table -A $subchain -j DROP -s 191.255.0.0/16 -m comment --comment
> 'RESERVED'
>      $table -A $subchain -j DROP -s 192.0.0.0/24 -m comment --comment
> 'RESERVED'
>      $table -A $subchain -j DROP -s 192.0.2.0/24 -m comment --comment
> 'RESERVED'
>      $table -A $subchain -j DROP -s 192.88.99.0/24 -m comment --comment
> '6to4 RELAY ANYCAST'            #RFC3068
>      $table -A $subchain -j DROP -s 192.168.0.0/16 -m comment --comment
> 'PRIVATE USE'                   #RFC1918
>      $table -A $subchain -j DROP -s 198.18.0.0/15 -m comment --comment
> 'NETWORK INTERCONNECT'           #RFC2544
>      $table -A $subchain -j DROP -s 223.255.255.0/24 -m comment --comment
> 'RESERVED'
>      $table -A $subchain -j DROP -s 224.0.0.0/4 -m comment --comment
> 'MULTICAST'                        #RFC3171
>      $table -A $subchain -j DROP -s 240.0.0.0/4 -m comment --comment
> 'RESERVED'                         #RFC1700, page 4
> 
> ...
> 
>      $table -A $subchain -j ACCEPT
> 
> 
>     $table -A $chain -j ACCEPT -i $LAN_IF -s $LAN_NW
> 
> 
> 
>> 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.
> 
> Not just the "no trust" scenario. If you want to speed up the
> firewalling/lower the response ratio then maybe it is usefull to drop some
> packets as soon as possible. 
> 
> In my firewall policies I try to find asap the "usefull" rule for the
> packet/connection.
> For example:
> 
>> 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).
> 
> The same rules from above:
> 
Perfect.

> 
> Chain PREROUTING (policy DROP 1 packets, 76 bytes)
>  pkts bytes target     prot opt in     out     source              
> destination         
> 1240K  495M ACCEPT     all  --  lo     *       0.0.0.0/0           
> 0.0.0.0/0           
>   692 19424 PRE_ETH0   all  --  eth0   *       192.168.255.0/24    
> 0.0.0.0/0           
> 6996K 6377M PRE_PPP0   all  --  ppp0   *       0.0.0.0/0           
> EXTERNAL_IP       
> 1669K  514M PRE_MFL1   all  --  mfl1   *       172.31.255.248/29   
> 0.0.0.0/0           
> 6697K 2227M PRE_BR1    all  --  br1    *       0.0.0.0/0           
> 0.0.0.0/0           
>  412K  121M PRE_BR2    all  --  br2    *       0.0.0.0/0           
> 0.0.0.0/0           
> 1667K  385M ACCEPT     all  --  vpn1   *       192.168.10.0/24     
> 0.0.0.0/0           
>    25 15605 ACCEPT     all  --  vpn2   *       192.168.253.0/24    
> 0.0.0.0/0           
> 1219K   82M ACCEPT     all  --  vpn-ftp *       172.31.255.1        
> 0.0.0.0/0           
>    35  1960 PRE_BRS    all  --  brs    *       0.0.0.0/0           
> 0.0.0.0/0           
>     1    76 LOG        all  --  *      *       0.0.0.0/0           
> 0.0.0.0/0           LOG flags 0 level 7 prefix `IPT: RAW PRE ' 
> 
> Chain PRE_PPP0 (1 references)
>  pkts bytes target     prot opt in     out     source              
> destination         
>    56  3136 DROP       all  --  *      *       10.0.0.0/8          
> 0.0.0.0/0           /* PRIVATE USE */ 
>     0     0 DROP       all  --  *      *       14.0.0.0/8          
> 0.0.0.0/0           /* PUBLIC DATA NETWORKS */ 
>     0     0 DROP       all  --  *      *       24.0.0.0/8          
> 0.0.0.0/0           /* CABLE TELEVISION NETWORKS */ 
>     0     0 DROP       all  --  *      *       39.0.0.0/8          
> 0.0.0.0/0           /* RESERVED */ 
>     0     0 DROP       all  --  *      *       127.0.0.0/8         
> 0.0.0.0/0           /* LOOPBACK */ 
>     0     0 DROP       all  --  *      *       128.0.0.0/16        
> 0.0.0.0/0           /* RESERVED */ 
>     0     0 DROP       all  --  *      *       169.254.0.0/16      
> 0.0.0.0/0           /* LINK LOCAL */ 
>     0     0 DROP       all  --  *      *       172.16.0.0/12       
> 0.0.0.0/0           /* PRIVATE USE */ 
>     0     0 DROP       all  --  *      *       191.255.0.0/16      
> 0.0.0.0/0           /* RESERVED */ 
>     0     0 DROP       all  --  *      *       192.0.0.0/24        
> 0.0.0.0/0           /* RESERVED */ 
>     0     0 DROP       all  --  *      *       192.0.2.0/24        
> 0.0.0.0/0           /* RESERVED */ 
>     0     0 DROP       all  --  *      *       192.88.99.0/24      
> 0.0.0.0/0           /* 6to4 RELAY ANYCAST */ 
>     1   154 DROP       all  --  *      *       192.168.0.0/16      
> 0.0.0.0/0           /* PRIVATE USE */ 
>     0     0 DROP       all  --  *      *       198.18.0.0/15       
> 0.0.0.0/0           /* NETWORK INTERCONNECT */ 
>     0     0 DROP       all  --  *      *       223.255.255.0/24    
> 0.0.0.0/0           /* RESERVED */ 
>     0     0 DROP       all  --  *      *       224.0.0.0/4         
> 0.0.0.0/0           /* MULTICAST */ 
>     0     0 DROP       all  --  *      *       240.0.0.0/4         
> 0.0.0.0/0           /* RESERVED */ 
> 
> ...
> 
> 6996K 6377M ACCEPT     all  --  *      *       0.0.0.0/0           
> 0.0.0.0/0           
> 
> 
>> 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.
> 
> YES! For example if you have to connect a new subnet/network. With generic
> rules you may have some unwanted side-effects... :D

Agreed ;-)

Two other previous posts I sent yesterday also suffer from the same short-term 
memory delusion ;-)

Thanks for everything,
Will.

> 
>> Again all feedback is welcome. Perhaps reality is not as black and white!
>>
>> regards,
>> Will.
> 
> Swifty
> --
> To unsubscribe from this list: send the line "unsubscribe netfilter" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html
> 

-- 
________________________________________
William M. Fitzgerald (MSc, BSc)
PhD Student,
Cork Constraint Computation Centre,
Computer Science Dept.,
University College Cork,
Cork,
Ireland.
----------------------------------------
www.williamfitzgerald.net
www.williamfitzgerald.info
www.linkedin.com/in/williamfitzgerald
http://4c.ucc.ie/web/people.jsp?id=143
www.tssg.org/people/wfitzgerald/
________________________________________