Cisconinja’s Blog

Archive for the ‘ACL’ Category

Rate-limit ACLs

Posted by Andy on February 16, 2009

In this post we will examine how rate-limit ACLs work with CAR.  The topology and method of generating traffic will be the same as I used for testing WFQ.  The topology and inital configurations are shown below:

car-acl-topology

R1:
interface FastEthernet0/0
 ip address 10.1.1.1 255.255.255.0
 load-interval 30
 speed 100
 full-duplex
 no keepalive
 no mop enabled
!
interface Serial0/0
 ip address 10.1.12.1 255.255.255.0
 load-interval 30
 no keepalive
!
no cdp run

R2:
interface Serial0/0
 ip address 10.1.12.2 255.255.255.0
 load-interval 30
 no keepalive
!
no cdp run

The point of this example will be to examine how rate-limit ACLs work, and in particular the mask feature, so we will need traffic with various IP precedence values.  This particular traffic generator does not allow ToS byte values to be specified, so we will mark the traffic inbound on R1 F0/0.  We will generate 8 different traffic streams to ports 1000 – 1007, and each type of traffic will be marked with IPP X, where X is the last digit in the port number.  With an interpacket delay of 125 ms and packet size of 1500 bytes, this will give us 96 kbps of each IPP value (1500 * 8 * 8).  R2 will be configured to measure incoming traffic.  Let’s configure and verify this before setting up the rate-limit ACL:

R1:
access-list 100 permit udp any any eq 1000
access-list 101 permit udp any any eq 1001
access-list 102 permit udp any any eq 1002
access-list 103 permit udp any any eq 1003
access-list 104 permit udp any any eq 1004
access-list 105 permit udp any any eq 1005
access-list 106 permit udp any any eq 1006
access-list 107 permit udp any any eq 1007
!
class-map match-all Prec0
 match access-group 100
class-map match-all Prec1
 match access-group 101
class-map match-all Prec2
 match access-group 102
class-map match-all Prec3
 match access-group 103
class-map match-all Prec4
 match access-group 104
class-map match-all Prec5
 match access-group 105
class-map match-all Prec6
 match access-group 106
class-map match-all Prec7
 match access-group 107
!
policy-map Marker
 class Prec0
  set precedence 0
 class Prec1
  set precedence 1
 class Prec2
  set precedence 2
 class Prec3
  set precedence 3
 class Prec4
  set precedence 4
 class Prec5
  set precedence 5
 class Prec6
  set precedence 6
 class Prec7
  set precedence 7
!
interface FastEthernet0/0
 service-policy input Marker

R2:
class-map match-all Prec0
 match precedence 0
class-map match-all Prec1
 match precedence 1
class-map match-all Prec2
 match precedence 2
class-map match-all Prec3
 match precedence 3
class-map match-all Prec4
 match precedence 4
class-map match-all Prec5
 match precedence 5
class-map match-all Prec6
 match precedence 6
class-map match-all Prec7
 match precedence 7
!
policy-map Traffic-Meter
 class Prec0
 class Prec1
 class Prec2
 class Prec3
 class Prec4
 class Prec5
 class Prec6
 class Prec7
!
interface Serial0/0
 service-policy input Traffic-Meter

flood.pl --port=1000 --size=1496 --delay=125 10.1.12.2
flood.pl --port=1001 --size=1496 --delay=125 10.1.12.2
flood.pl --port=1002 --size=1496 --delay=125 10.1.12.2
flood.pl --port=1003 --size=1496 --delay=125 10.1.12.2
flood.pl --port=1004 --size=1496 --delay=125 10.1.12.2
flood.pl --port=1005 --size=1496 --delay=125 10.1.12.2
flood.pl --port=1006 --size=1496 --delay=125 10.1.12.2
flood.pl --port=1007 --size=1496 --delay=125 10.1.12.2

car-acl-1-r1f0

car-acl-1-r1s0

car-acl-1-r2s0

car-acl-1-r1pmap

car-acl-1-r2pmap

We can see that the input rate on R1 F0/0, output rate on R1 S0/0, and input rate on R2 S0/0 roughly matches the combined bandwidth of the 8 traffic streams.  We can also see that the traffic is being marked with the IPP values we specified on R1 and that R2 is receiving approximately 96 kbps of each type.  Now we can move onto configuring the rate-limit ACL.

Rate-limit ACLs, when used with the mask option, allow a 1-byte mask value to be entered.  Each position in the mask corresponds to an IPP value (MPLS EXP values work the same way), with IPP 7 being the left most value and IPP 0 the right most value.  The values that should be matched are set to 1 in their respective positions and the resulting mask is entered as a hexadecimal value.  Let’s say that we want to limit all IPP 0-4 traffic to a combined rate of 128 kbps.  The mask to match these values will be 00011111, which is hexadecimal 0x1F.  The configuration for this is:

R1:
access-list rate-limit 0 mask 1F
!
interface Serial0/0
 rate-limit output access-group rate-limit 0 128000 8000 8000 conform-action transmit exceed-action drop

On R1, we can see that policing is taking place:

car-acl-2-r1car1

On R2, we can verify the amount of each IP Precedence value received:

car-acl-2-r2pmap

The combined 30 second offered rates for IPP values 0-4 equal roughly 128 kbps, while the other IPP values continued to send 96 kbps each.  This verifies that we have used the mask value correctly.

Posted in ACL, QoS | Leave a Comment »

Reflexive ACLs, Classic IOS Firewall (CBAC), and Zone-Based Policy Firewall

Posted by Andy on December 21, 2008

This example is designed to show a simple example of using reflexive ACLs, the Cisco IOS ‘classic’ firewall (CBAC), and the newer zone-based policy firewall to accomplish the same thing.  Although each of these technologies have significant differences, this example is only designed to show a basic configuration of each for comparison.  The topology and initial configurations are shown below:

 fw-topology4

hostname FW
!
interface FastEthernet1/0
 ip address 192.168.1.1 255.255.255.0
 duplex full
 speed 100
!
interface FastEthernet1/1
 ip address 10.1.1.1 255.255.255.0
 duplex full
 speed 100


hostname Inside
!
no ip domain lookup
ip host Outside 10.1.1.2
!
interface FastEthernet1/0
 ip address 192.168.1.2 255.255.255.0
 duplex full
 speed 100
!
ip route 0.0.0.0 0.0.0.0 192.168.1.1
!
line vty 0 4
 privilege level 15
 no login


hostname Outside
!
no ip domain lookup
ip host Inside 192.168.1.2
!
interface FastEthernet1/0
 ip address 10.1.1.2 255.255.255.0
 duplex full
 speed 100
!
ip route 0.0.0.0 0.0.0.0 10.1.1.1
!
line vty 0 4
 privilege level 15
 no login

For this example, we want to be able to initiate telnet connections from Inside to Outside, and allow Outside to respond only if the connection was initiated from Inside. All other traffic should be denied.  We will create a configuration to meet these requirements using each of the previously mentioned 3 technologies, with each one starting with the base configs shown above.

 

Reflexive ACL Configuration

FW:
ip access-list extended InsideACL
 permit tcp 192.168.1.0 0.0.0.255 gt 1024 10.1.1.0 0.0.0.255 eq telnet reflect TelnetResponse
 deny ip any any log
!

ip access-list extended OutsideACL
 evaluate TelnetResponse
 deny ip any any log
!
interface FastEthernet1/0
 ip access-group InsideACL in
!
interface FastEthernet1/1
 ip access-group OutsideACL in


The above configuration  creates an ACL named InsideACL which allows telnet traffic from Inside to Outside.  Any traffic permitted by the ACL causes a temporary entry in the reflexive ACL named TelnetResponse to be created, with the source and destination addresses and port numbers reversed.  All other traffic from Inside is denied and logged.  An ACL named OutsideACL was also created, which first evaluates the reflexive ACL we created.  Anything not permitted by the reflexive ACL is denied and logged.  Let’s test it out.  Outside attempting to telnet to Inside is denied and generates a log message on FW:

outsidetelnettest

outsidedeniedatfw2

Inside attempting to telnet to Outside is successful:

reflexiveacl-insidetelnet

We can also view the reflexive ACL entry that has been created on FW when we telnetted from Inside to Outside:

reflexiveacl1

 

Classic IOS Firewall / CBAC

FW:
ip access-list extended InsideACL
 permit tcp 192.168.1.0 0.0.0.255 gt 1024 10.1.1.0 0.0.0.255 eq telnet
 deny ip any any log
!
ip access-list extended OutsideACL
 deny ip any any log
!
ip inspect name AllowTelnet telnet
!
interface FastEthernet1/0
 ip access-group InsideACL in
 ip inspect AllowTelnet in
!
interface FastEthernet1/1
 ip access-group OutsideACL in

The above configuration creates an ACL named InsideACL which allows telnet traffic from Inside to Outside and denies everything else.  Next, it creates an ACL named OutsideACL which denies everything coming from Outside.  It also creates an inspection rule named AllowTelnet which inspects Telnet traffic from Inside to Outside and allows response traffic from Outside, which our OutsideACL would have otherwise denied.  Let’s test the CBAC configuration out.  Outside attempting to telnet to Inside is denied again and generates a log message on FW:

outsidetelnettest2

outsidedeniedatfw3

Inside attempting to telnet to Outside is successful:

reflexiveacl-insidetelnet1

We can view information about the telnet connection in the session table on FW:

cbac-sessiontable

 

Zone-Based Policy Firewall

FW:

zone security Inside
!
zone security Outside
!
interface FastEthernet1/0
 zone-member security Inside
!
interface FastEthernet1/1
 zone-member security Outside
!
class-map type inspect match-all TelnetClass
 match protocol telnet
!
policy-map type inspect AllowTelnet
 class type inspect TelnetClass
  inspect
!
zone-pair security Inside-Outside source Inside destination Outside
 service-policy type inspect AllowTelnet

 The above configuration creates the security zones Inside and Outside and places F1/0 into Inside and F1/1 into Outside.  Next, it creates the class-map TelnetClass which matches telnet traffic and the policy-map AllowTelnet which specifies that telnet traffic should be inspected in order to allow return traffic.  With the zone-based firewall, all traffic between different zones is denied by default, so no ACLs are necessary.  The last step is to create a zone pair named Inside-Outside with Inside as the source and Outside as the destination and apply our policy-map.  Let’s test the zone-based firewall configuration.  Outside attempting to telnet to Inside is denied, just like the last 2 examples:

outsidetelnettest3

Inside attempting to telnet to Outside is successful:

reflexiveacl-insidetelnet2

Just as with CBAC, we can view information about the telnet session:

zbfw-sessiontable1

Posted in ACL, Security | Leave a Comment »

Using ACLs with discontiguous wildcard bitmasks – an example

Posted by Andy on November 21, 2008

Suppose we’ve been given the requirement to permit the following 3 (randomly chosen) addresses:

 

#1 – 131.47.104.88

#2 – 203.42.155.67

#3 – 90.143.32.224

 

and to deny the following 3 (also randomly chosen) addresses:

 

#4 – 152.209.18.22

#5 – 8.25.99.150

#6 – 79.242.201.57

 

using only a single line access list.  Conventional access list knowledge would say that this is impossible, because even the very first bit differs between the 3 addresses that we must permit.  However, the truth is that each bit of an ACL is treated individually, and wildcard masks do not need to be contiguous.  In order to find the most specific address and wildcard mask that will match the first 3 addresses, we first convert each of them to binary:

 

#1 – 131.47.104.88  =  10000011 . 00101111 . 01101000 . 01011000

#2 – 203.42.155.67  =  11001011 . 00101010 . 10011011 . 01000011

#3 – 90.143.32.224  =  01011010 . 10001111 . 00100000 . 11100000

 

Next, we perform a logical AND on these 3 addresses to obtain the address portion of our ACL statement:

 

  10000011 . 00101111 . 01101000 . 01011000

  11001011 . 00101010 . 10011011 . 01000011

AND    01011010 . 10001111 . 00100000 . 11100000

————————————————————————————

   00000010 . 00001010 . 00000000 . 01000000  =  2.10.0.64

 

Next, we perform a logical XOR on these 3 addresses to obtain the wildcard mask portion of our ACL statement:

 

  10000011 . 00101111 . 01101000 . 01011000

  11001011 . 00101010 . 10011011 . 01000011

XOR   01011010 . 10001111 . 00100000 . 11100000

————————————————————————————

  11011001 . 10100101 . 11111011 . 10111011  =  217.165.251.187

 

Why AND the addresses to find the address portion and XOR them to find the wildcard mask?  The logic works as follows:

1.  If all addresses have the same value in a given bit position, use that value in the address portion of the ACL entry.  This bit will be ‘checked’ (Step #3), so the value of that bit in the address portion must match the value of that bit in all the addresses we want to permit.

2. If not all addresses have the same value in a given bit position, use zero as the value for that bit.  This bit will not be ‘checked’ anyway (Step #4) because doing so would only allow a subset of the addresses that we want to match.  We could, in fact, use either a zero or one here without affecting the matching logic since it is not checked anyway, but standard practice is to use a zero.

3. If all addresses have the same value in a given bit position, place a zero in that position in the wildcard mask portion.  This means that we will ‘check’ this bit, meaning we will require it to match the value that we specified for this bit position in the address portion.  This should always result in a match, because in Step #1 we placed the value that all of these addresses have in common in that position.

4. If not all addresses have the same value in a given bit position, place a one in that position in the wildcard mask portion.  This is considered a ‘don’t care’ bit, and means that we do not require it to match.

 

Ok, so the address and wildcard mask that we came up with meet our requirement of permitting the first 3 addresses, but what about denying the next 3?  Start with the wildcard mask and look at all bit positions that contain a zero.  We’ve specified that these bits must match our address portion of the ACL, so allow the address bits to ‘pass through’ the wildcard bits where the wildcard bit is a zero and cross out all other bit positions that we are not checking:

 

ACL Address    00000010 . 00001010 . 00000000 . 01000000

ACL Wildcard   11011001 . 10100101 . 11111011 . 10111011

————————————————————————————————-

 Filter              xx0xx01x . x0x01x1x . xxxxx0xx . x1xxx0xx 

 

Next, compare each of the addresses that we want to deny against this filter.  If any bit that isn’t crossed out differs, the address will be denied.

 

#4 – 152.209.18.22   =  10011000 . 11010001 . 00010010 . 00010110

#5 – 8.25.99.150       =  00001000 . 00011001 . 01100011 . 10010110

#6 – 79.242.201.57  =   01001111 . 11110010 . 11001001 . 00111001

 

Addresses #4 and #5 will be denied by the 3rd bit that we are checking (7th bit, 1st octet).  Address #6 will be denied by the 2nd bit that we are checking (6th bit, 1st octet).  It appears that our address and wildcard will accomplish what we need.  Our ACL statement becomes:

 

access-list 1 permit 2.10.0.64 217.165.251.187

 

 However, note that the usefulness of an ACL like this is very limited, because it permits much more than we need to.  Because there are 22 ‘don’t care’ bits in the wildcard mask, this ACL will permit a total of 2^22 (4,194,304) different addresses.  A randomly chosen address will have a 1 in 2^10 (1/1024) chance of being permitted by our single line ACL.

Finally, let’s test it out and see if it works correctly.  We will use a simple 2 router topology as shown below:

acl-lab1

R1 will be using 6 loopbacks to simulate our addresses and sourcing pings from each of them to R2.  R2 will use the ACL we created inbound on F0/0.  The relevant portions of each router’s configuration are shown below: 

 

acl-lab-r1-config1

 

acl-lab-r2-config2

 

 

 

Now we can initiate pings on R1 to R2 sourced from each of our 6 addresses:

 

acl-lab-results

The first 3 addresses are permitted and second 3 are denied, just as we expected.

 

One final note on using discontiguous wildcard masks is that not all IOS features will allow them.  Attempting to use the same address and wildcard mask to enable OSPF on the first 3 loopback interfaces of R1 gives the following result:

acl-lab-ospf

Posted in ACL | 2 Comments »