IP Rules

   

IP Rules

One of the topics that you have not seen is the supposed original basis for using Policy Routing in the first place ”the ability to route based on source, TOS, packet data, and other packet features. This is where the final member of the Policy Routing triad , rules, enters the scene.

As you saw in Chapter 3, rules are what provide the decision structure in the RPDB. Rules function not just as logical packet selectors, but also possess the capability to act upon a selected packet. In this sense the true power becomes apparent. Rules have much the same set of actions as routes when acting directly on a packet. Unlike routes, they cannot specify any forwarding actions but only the blocking actions. To illustrate , consider Example 5.7.

Example 5.7: Basic Router Filters v2.0

Consider the setup you have running from Example 5.4 as illustrated by Figure 5.1. The security structure provided by the routes acts upon the traffic, leaving the subnets only. Since you have control of the core router and the subnet routers, you would like to reimplement the security structure so that the requesting client is returned the appropriate error message.

The logic revisited is that the accounting network is to be administratively denied to all except the range of addresses 10.2.3.32/27 and 10.3.2.0/27. The engineering test network may only be accessed by anyone in 10.10.0.0/14, with all others not even knowing the network exists. To summarize the logic tree:

 
 To accounting network - 172.17.0.0/16 10.2.3.32/27        -    allowed 10.3.2.0/27        -    allowed 0/0            -    prohibit To Engineering test network    - 192.168.2.0/24 10.10/14        -    allowed 0/0            -    blackhole 
 

Note that this logic is supposed to be from the point of view of the core router. Looking back at Listing 5.4 from Example 5.4 you can see that the implemented logic is on the subnet routers. To ensure that your new structure is not prone to the hackery that could be done under the implementation of Example 5.4, you also need to look at the logic from the point of view of the subnet routers. In that manner anyone trying to subvert the global security by directly pointing at the subnet routers would be forced to obey the same rules. So the subnet router's logic would then look like

 
 # Accounting Network Router 10.2.3.32/27        -    allow 10.3.2.0/27        -    allow 0/0            -    blackhole # Engineering test network Router 10.10/14        -    allow 0/0            -    blackhole 
 

Note that this is essentially the same as the core router logic with the exception that on the accounting router and the engineering router all traffic not allowed is silently discarded. In this manner you can essentially make the accounting and engineering routers invisible. Whether the end user workstation is coded for a default route to the core router or has entered a route directly to the accounting or engineering routers, the logical behavior of the network is consistent.

You then set about implementing this policy using the rules on the core, accounting, and engineering routers. Starting with the core router first, you allow for the default rules (see Chapter 4) and code in the following rule set:

 
 # For the Accounting Network  ip rule add from 10.2.3.32/27 to 172.17/16 prio 16000   ip rule add from 10.3.2.0/27 to 172.17/16 prio 16010   ip rule add from 0/0 to 172.17/16 prio 16020 prohibit  # For the Engineering Test Network  ip rule add from 10.10/14 to 192.168.2/24 prio 17000   ip rule add from 0/0 to 192.168.2/24 prio 17010 blackhole  
 

This allows all traffic from the allocated subnets to be passed into the routes while returning or dropping those packets not allowed. Of course you still have the routes themselves pointing to the accounting and engineering subnets. The ordering of the rules is important and you have allowed space to add rules later by spacing out the priority number. It would have sufficed to not put the to section in the first two rules or in the fourth. But you usually will want to err on the side of exact specification, especially when you end up placing rules into play that you come back to look at several months later. Also note that you are not specifying the interface on which the packets arrive or leave. This allows these rules to act globally. If you were certain that the traffic would be confined in transit to specific interfaces, then you would also specify the interface here. Conversely, by using an interface specification on a multi- interfaced router you can allow some traffic without having to specify any rules.

In this setup there is no restriction on any of the 10.10/14 addresses accessing the accounting network or on any of the 10.2.3.32/27, 10.3.2.0/27 addresses accessing the engineering test network. That is why you want to be able to specify Policy Routing structures on the accounting and engineering routers. By so spreading the logic, you allow for better traffic flow and also ensure that there is no one point of catastrophic failure.

You then continue on to configure the accounting router. As specified in the logic tree for Example 5.7, the accounting router will have the following rule set.

 
  ip rule add from 10.2.3.32/27 dev eth0 prio 16000   ip rule add from 10.3.2.0/27 dev eth0 prio 16010   ip rule add from 0/0 dev eth0 prio 16020 blackhole  
 

Note that in this case you do specify the interface on which the packets arrive. You make the assumption that if any packets originate from within the accounting network with an incorrect source address, there are other methods to deal with them.

Having coded the accounting router you turn to the engineering test network router. Again following the logic tree, you install the following rule set:

 
  ip rule add from 10.10/14 dev eth0 prio 17000   ip rule add from 192.168.2/24 dev tr0 prio 17010   ip rule add from 0/0 prio 17020 blackhole  
 

Now here you decide that because the engineers are wont to play with various attack programs, especially ones that use spoofing, you will limit the traffic both into and out of the network. So you allow the traffic on interface eth0 from the allowed addresses into the network. Then you allow out only the traffic with the appropriate IP address from the internal interface. Finally, you silently discard all other traffic. You essentially use the source address rules to only allow allocated addresses into and out of the network.


   
Top


Policy Routing Using Linux
Policy Routing Using Linux
ISBN: B000C4SRVI
EAN: N/A
Year: 2000
Pages: 105

flylib.com © 2008-2017.
If you may any questions please contact us: flylib@qtcs.net