Posts Tagged ‘access-list’
I. Security Fundamentals
a. Why Needed?
i. A closed network allows no connection to a public network; although security is still an issue due to a majority of attacks coming from inside networks today
Hello to all our faithful blog readers, I hope this post find you very well, and enjoying your studies!
Access list tasks are a common CCIE Lab Exam feature, and I wanted to take a moment to show how easy it can be for a candidate to miss one thing or many things in such a task.
Here is the task topology and the task itself. Following that we have the proposed solution by a Mock Student
Can you find the errors in his or her ways?
8.1 Configure a security filter on R3 that will accomplish the following for traffic entering the router from the direction of R2:
- Allow Telnet from R2 (S0/1) to R1 (Lo1)
- Allow BGP traffic through the router
- Allow ICMP ping traffic between R1 (Lo1) and R2 (Lo1)
- Block any traffic sourced from RFC 1918 addresses – log these violations and include Layer 2 address information
The Proposed Solution
access-list 100 permit tcp host 220.127.116.11 eq telnet host 192.168.100.1 eq telnet
access-list 100 permit tcp any any eq bgp
access-list 100 permit icmp host 18.104.22.168 host 192.168.100.1
access-list 100 permit icmp host 192.168.100.1 host 22.214.171.124
access-list 100 deny ip 10.0.0.0 0.255.255.255 any log
access-list 100 deny ip 172.16.0.0 0.0.255.255 any log
access-list 100 deny ip 192.168.0.0 0.0.255.255 any log
ip access-group 100 in
NOTE: I have posted a solution to this blog in the comments. The solution post date is November 20th, 2008.
Answers for Part II
So the answers to the exciting tasks at hand….
There was a good amount of activity surrounding answers submitted for the contest! It was good to see that many people interested in them! Now, it’s time to go through the answers and stretch the imagination a bit! Be prepared for some stretching as well!
One quick thing to point out before we get started, there was a question asked about why /24 routes won’t have a “.255″ as the fourth octet. This really depends on how we are using the ACL. If we are doing traffic filtering, where packets will obviously come from hosts INSIDE the /24, then yes, I’d use a “.255″ mask.
However, when the entry is being used for a routing filter, and it’s a /24 route… The fourth octet will, by definition, always be “.0″ and shouldn’t be changed. So the mask of “.0″ prevents anything from changing!
Now… On to the answers!
I know, I know… I promised this a while back, after I did the first part. Sorry ’bout that!
So we’ve played around a bit with the access-list idea and some binary matching. So let’s expand our brains even further!
I will start out by telling everyone that I am NOT picking on or otherwise attempting to insult any CCNA’s out there by comparing methodology to what is learned in CCNA. The idea being that there are basic and advanced ways to learn things.
When we all first learned fractions, if anyone attempted to explain more advanced methods of long division, or finite state mathematics, or anything we now consider to be “basic algebra”, plain and simple…. our brains would have imploded! It wouldn’t have been pretty at all.
There is a time and a place for everything. When first beginning as a CCNA, the concept of “network” and “network mask” and wonderful subnets on standard bit-boundaries is good. It’s a starting point. Just realize that it isn’t the end point, and as CCIE Candidates, we need to see beyond those initial learning steps in order to succeed! If you have stumbled across these blogs, and are still a CCNA, my sincere apologies as I did not mean to offend! (And my apologies for any induced-brain-implosions!)
Now, all those legal disclaimers aside, it’s time to move up a notch in Binary Math. We’re still counting to one, we’re just doing it with more finesse now! So let’s start with our first problem for Part II.
Prior to the support of prefix-lists in the IOS advanced filtering for BGP needed to be done using extended ACLs. The syntax for using extended ACLs is shown below:
access-list <ACL #> permit ip <network> <wildcard mask of network> <subnet mask> <wildcard mask of subnet mask>
The source portion of the extended ACL is used to match the network portion of the BGP route and the destination portion of the ACL is used to match the subnet mask of the BGP route. Here are some examples:
access-list 100 permit ip 10.0.0.0 0.0.0.0 255.255.0.0 0.0.0.0
Matches 10.0.0.0/16 – Only
access-list 100 permit ip 10.0.0.0 0.0.0.0 255.255.255.0 0.0.0.0
Matches 10.0.0.0/24 – Only
access-list 100 permit ip 10.1.1.0 0.0.0.0 255.255.255.0 0.0.0.0
Matches 10.1.1.0/24 – Only
access-list 100 permit ip 10.0.0.0 0.0.255.0 255.255.255.0 0.0.0.0
Matches 10.0.X.0/24 – Any number in the 3rd octet of the network with a /24 subnet mask.
access-list 100 permit ip 10.0.0.0 0.255.255.0 255.255.255.0 0.0.0.0
Matches 10.X.X.0/24 – Any number in the 2nd & 3rd octet of the network with a /24 subnet mask.
access-list 100 permit ip 10.0.0.0 0.255.255.255 255.255.255.240 0.0.0.0
Matches 10.X.X.X/28 – Any number in the 2nd, 3rd & 4th octet of the network with a /28 subnet mask.
access-list 100 permit ip 10.0.0.0 0.255.255.255 255.255.255.0 0.0.0.255
Matches 10.X.X.X/24 to 10.X.X.X/32 – Any number in the 2nd, 3rd & 4th octet of the network with a /24 to /32 subnet mask.
access-list 100 permit ip 10.0.0.0 0.255.255.255 255.255.255.128 0.0.0.127
Matches 10.X.X.X/25 to 10.X.X.X/32 – Any number in the 2nd, 3rd & 4th octet of the network with a /25 to /32 subnet mask
I’m trying to create a distribute-list in RIP to allow only even routes to be received. I can do it successfully with a standard ACL, however if I use an extended ACL I can’t get any routes at all. I’ve heard that extended ACLs are better because they also check the netmask. What am I doing wrong?
Using an extended access-list with a distribute-list is supported, however the syntax can be a little confusing because it means different things for different applications. When using an extended ACL for a distribute-list in BGP it acts like a prefix-list. This means that you can match on both the address of the prefix and the subnet mask. In other words if you have prefixes 10.0.0.0/8 and 10.0.0.0/16 you can distinguish between them by saying not only must the address be 10.0.0.0 but the subnet mask must be /8. In prefix-list syntax this is very straightforward, as to match this prefix we would use the following:
ip prefix-list PREFIX1 permit 10.0.0.0/8
When using an extended access-list in BGP the syntax of the list changes in that we are not matching source and destination pairs, but instead are matching the address and netmask. In extended ACL syntax the above prefix-list would read:
access-list 100 permit ip host 10.0.0.0 host 255.0.0.0
This means that the address must be exactly 10.0.0.0 and the subnet mask must be exactly 255.0.0.0. By changing the “host” keyword to a wildcard mask we can do fuzzy binary matches. For example the following syntax means check any address that starts with “192.168” and has a subnet mask of /24:
access-list 101 permit ip 192.168.0.0 0.0.255.255 host 255.255.255.0
In other words this list matches 192.168.0.0/24, 192.168.100.0/24, 192.168.200.0/24, etc.
This extended access-list syntax can also be used in a route-map for redistribution filtering in both IGP and BGP. For example if we took the previous access-list 101 and matched it in a route-map as follows:
route-map OSPF_TO_RIP permit 10 match ip address 100 ! router rip redistribute ospf 1 metric 1 route-map OSPF_TO_RIP
This syntax would say that we want to redistribute OSPF routes into RIP, but only those which are 192.168.X.X/24.
The confusion for this extended access-list implementation is that when it is called as a distribute-list in IGP the syntax changes. In the previous examples the normal “source” field in the ACL represents the network address, where the “destination” field represents the subnet mask. In IGP distribute-list application the “source” field in the ACL matches the update source of the route, and the “destination” field represents the network address. This implementation allows us to control which networks we are receiving, but more importantly who we are receiving them from. Take the following topology:
R1, R2, and R3 share an Ethernet network 126.96.36.199/8 that is running RIP. Both R1 and R2 are advertising the identical prefixes 10.0.0.0/8 and 188.8.131.52/8 to R3. Their configurations are as follows:
R1#show ip int brief | exclude unassigned Interface IP-Address OK? Method Status Protocol FastEthernet0/0 184.108.40.206 YES manual up up Loopback0 10.0.0.1 YES manual up up Loopback1 220.127.116.11 YES manual up up R1#show run | begin router rip router rip version 2 network 10.0.0.0 network 18.104.22.168 network 22.214.171.124 R2# show ip int brief | exclude unassigned Interface IP-Address OK? Method Status Protocol FastEthernet0/0 126.96.36.199 YES manual up up Loopback0 10.0.0.1 YES manual up up Loopback1 188.8.131.52 YES manual up up R2#sh run | begin router rip router rip version 2 network 10.0.0.0 network 184.108.40.206 network 220.127.116.11 R3#show ip route rip R 18.104.22.168/8 [120/1] via 22.214.171.124, 00:00:00, Ethernet0/0 [120/1] via 126.96.36.199, 00:00:00, Ethernet0/0 R 10.0.0.0/8 [120/1] via 188.8.131.52, 00:00:00, Ethernet0/0 [120/1] via 184.108.40.206, 00:00:00, Ethernet0/0
From this output we can see that R3 has the two prefixes installed twice, once from R1 and once from R2. Now let’s suppose that prefix 10.0.0.0/8 we only want to receive from R1, while prefix 220.127.116.11/8 we only want to receive from R2. We can accomplish this with an extended access-list as follows:
R3#conf t Enter configuration commands, one per line. End with CNTL/Z. R3(config)#access-list 100 permit ip host 18.104.22.168 host 10.0.0.0 R3(config)#access-list 100 permit ip host 22.214.171.124 host 126.96.36.199 R3(config)#router rip R3(config-router)#distribute-list 100 in Ethernet0/0 R3(config-router)#end R3#clear ip route * R3#show ip route rip R 188.8.131.52/8 [120/1] via 184.108.40.206, 00:00:00, Ethernet0/0 R 10.0.0.0/8 [120/1] via 220.127.116.11, 00:00:00, Ethernet0/0
We can see now R3 only has one entry for each prefix, with the 10.0.0.0/8 coming only from R1 and the 18.104.22.168/8 coming only from R2. The disadvantage of this application however is that we cannot distinguish prefixes based on their netmask. For example we could not say that we want to receive prefix 172.16.0.0/16 from only R1 and prefix 172.16.0.0/24 only from R2. For this implementation in IGP we would use a prefix-list that is called from a distribute-list with the “distribute-list prefix” syntax under the routing process.