Better Security through Access-List Management

Chia sẻ: Huy Hoang | Ngày: | Loại File: PDF | Số trang:8

Thêm vào BST

Báo xấu

113
lượt xem 9
download

Download Vui lòng tải xuống để xem tài liệu đầy đủ

Security is becoming more and more common in every environment, regardless how big or small the network happens to be. Anytime we think of security, the first thing that comes to our minds is the implementation of firewalls. What if firewalls are not available in your network? What if your firewalls are only meant for connectivity from the outside world? Or, better yet, what if firewalls are controlled by different groups in your organization, and you want to do something to protect your network internally between departments and/or maybe your budget doesn’t allow you to get firewalls. Can you get somewhat similar...

Chủ đề:

Bình luận(0) Đăng nhập để gửi bình luận!

Lưu

Nội dung Text: Better Security through Access-List Management

Expert Reference Series of White Papers Better Security through Access-List Management 1-800-COURSES www.globalknowledge.com
Better Security through Access-List Management Raj Tolani, Global Knowledge Networking Instructor Introduction Security is becoming more and more common in every environment, regardless how big or small the network happens to be. Anytime we think of security, the first thing that comes to our minds is the implementation of firewalls. What if firewalls are not available in your network? What if your firewalls are only meant for connec- tivity from the outside world? Or, better yet, what if firewalls are controlled by different groups in your organization, and you want to do something to protect your network internally between departments and/or maybe your budget doesn’t allow you to get firewalls. Can you get somewhat similar functionality with your existing routers? The answer is yes. You can get limited security with the access-list on your routers. However, access-lists on routers are in no way replacements for firewalls. The abilities of access-list have evolved a lot since they were introduced in the early versions of Cisco IOS. What you can and cannot do with access-list will vary between IOS releases. With the IOS Firewall Feature set you can do more than what will be discussed in this whitepaper. This paper gives you the basics of access-list with implementations examples as covered in the CCNA certifications. These CCNA focused access-lists are for TCP/IP protocol only even though access-lists can control other protocols like IPX/SPX, and Appletalk. Typically, when you think of access-list you think about permitting or denying certain type of traffic. You think of protecting your network from being hacked. Well, that’s not the only use for access-list. access-lists have many other purposes. For example, with an access-list, you can trigger your ISDN calls – to mark what interest- ing traffic will trigger the call. With access-lists, you can mark traffic from specific source and/or destination addresses and prioritize that traffic over other traffic. With access-lists, you can allow or disallow certain routes to be added in your routing table and various other things that are beyond the scope of this whitepaper. Categories of Access-Lists There are two main categories of access-lists, Standard and Extended. Some folks might argue that the two types of access-lists are named and numbered. But remember that both named and numbered lists could be either standard or extended. (We will give you numbered examples in this whitepaper.) What do we mean by standard or extended type of access-list? Standard and Extended access-lists allow different type of control. Standard Access-Lists vs. Extended Access-Lists Standard Access-List: With standard access-lists you can check the source IP address of the packet, mean- ing, you can check to see if the source address happens to be a specific IP address (or IP subnet), then you can permit or deny that packet. Copyright ©2007 Global Knowledge Training LLC. All rights reserved. Page 2
Extended Access-List: With extended access-list, there are many things that can be checked. Besides source L3 addresses, you can check for destination L3 addresses, source/destination port number, or source/destina- tion protocol number. You can also check to see if the Acknowledge (ACK) bit on TCP connections is set or not. Wow, that’s a lot of control, giving us more items than we can cover in this whitepaper. Named Access-Lists Standard Access Lists are in the range from 1- 99. Extended access-lists are in the range from 100-199. That would mean that you can only have 99 standard access-lists or 100 extended access-lists on any given router. If you really wanted more than 99 standard access-lists or more than 100 extended access-list, you can use Named access-list. With named access-list, you can classify it to be standard or extended, and then you will follow the same rules (meaning standard named access-list can check for source address only and extended named access-list can check for all those other things mentioned earlier). Later on, with the newer IOS versions, you get expanded ranges for both standard and extended access-lists, giving you the ability to have many more access-lists. The expanded range for standard access-list is 1300-1999 and for extended it is 2000-2699. Wildcard Mask With both standard and extended access-lists you could use something called wildcard mask. Let us under- stand the wildcard mask first, before we go into the details of the implementations of standard or extended access-list. The wild card mask functions in reverse manner to a subnet mask. A wildcard mask is used to mark-specific bit patterns in an address. Since we are now talking about bits (i.e., binary), then we need to know that there are two possibilities – 0 and 1. The binary 0 is used to represent a match and a binary 1 is used to represent a “don’t care” condition. So, 0 means must match 1 means don’t care The syntax for the standard access-list is: Router(config)# access-list access-list-number {permit | deny} {test conditions} Let’s take a standard list example. Let’s start with a statement saying that the HR manager should be permit- ted to access the network. Pretend that the address is 131.107.2.14 for the HR manager. The command to accomplish this access-list condition would look like Router(config)#access-list 1 permit 131.107.2.14 Note: This line is configured at the global configuration mode in your router. To get to the global configuration mode, you need to take the following steps: Router>enable Router#config t Router(config)# Copyright ©2007 Global Knowledge Training LLC. All rights reserved. Page 3
We are using the number 1 in this example (remember that the range for standard access-list is 1-99); we could have picked any number in that standard access-list range. There is no higher or lower priority for higher or lower numbers. In our example, we used the number 1, which means all conditions we are going to do should be grouped under the number 1. Some students would look at that first line of code and argue that in their organization, the syntax would be something like Router(config)#access-list 1 permit 131.107.2.14 0.0.0.0 This is just an alternative way of accomplishing the same thing. The last four zeros are our wildcard mask bits, which are just stating that we need to exactly match that particular IP for HR manager (really there are 32 zeros in the wildcard mask because, in each octet, there are 8 bits, so we really have 32 zeros, if you think in binary). Another way of saying the same thing would be Router(config)#access-list 1 permit host 131.107.2.14 This line is using the keyword host, which also means to exactly match the IP following the host keyword. The keyword host is used before the IP address and the wildcard mask numbers are used after the IP address (just what the syntax requires in the IOS). So far we have seen three ways of saying the same things. Option 1: Router(config)#access-list 1 permit 131.107.2.14 Option 2: Router(config)#access-list 1 permit 131.107.2.14 0.0.0.0 Option 3: Router(config)#access-list 1 permit host 131.107.2.14 In plain English, we have stated that we want to allow the packet FROM 131.107.2.14. What we are allowing here and from what interfaces will be clear soon. But, how do you know at this point that this is the source address of 131.107.2.14 and not the destination address of 131.107.2.14? Remember, we said that the stan- dard access-list can only check for the source address and, since the number 1 falls in the range of standard access-list, we can only check for the source address of the packet. It doesn’t matter which line you pick; they are all correct. Some might argue that option 1 is less typing so it’s better. Others will argue that option 3 is better since it clearly states that this is for a host, which might make it easier for some of us to remember later on when you look at your access-lists. Continuing this example in this whitepaper I’ll use the syntax from option 1 since it’s less typing Copyright ©2007 Global Knowledge Training LLC. All rights reserved. Page 4
Let’s say the next requirement we have is that the rest of the HR department should not be allowed to access the network. To accomplish this, we will have to deny the rest of the folks on the 131.107.2.0 subnet. Here it goes: Router(config)#access-list 1 deny 131.107.2.0 0.0.0.255 Remember that 1 in binary means any. And 255 is nothing but 8 contiguous 1s. So, this statement is saying deny 131.107.2.. Now you might wonder if that isn’t going to deny the HR manager? The HR manager is also on the 131.107.2.0 subnets. Well, you can be at ease because the HR manager will NOT be denied, since we already allowed the HR manager in the beginning of the access-list. In the world of access-lists, we have the rule of top-down processing and, since our first line allowed the HR manager, we don’t have to worry about acciden- tally denying him/her. So far our conditions look like Router(config)#access-list 1 permit 131.107.2.14 Router(config)#access-list 1 deny 131.107.2.0 0.0.0.255 You might wonder if second line shouldn’t be access-list 2? No, because the number 1 is nothing but a GROUPING of conditions, and remember, we mentioned that these statements in the GROUP are going to be read top-down so the order is important. Some books even recommend that you should think of what you want to accomplish in the access-list in English on a regular piece of paper before you start keying in the com- mands. Let’s say that the rest of the company network should be allowed and the non-company networks should not be allowed. To make this happen the next command would be Router(config)#access-list 1 permit 131.107.0.0 0.0.255.255 Again, using the same rules for Wildcard Mask, we are matching the first two octets (131.107) and ignoring the last two octets (0.0 in the third and forth octet). This is like saying access-list 1 permit 131.107... So, are we done? Well, yes, but what about that last condition that said that the non-company networks should not be allowed? Well, we are saved here because at the end of every access-list there is always an “IMPLICIT DENY ANY”. You can’t see this when you type the commands to see the access-lists, but it exists. The complete access-list looks like this Router(config)#access-list 1 permit 131.107.2.14 Router(config)#access-list 1 deny 131.107.2.0 0.0.0.255 Router(config)#access-list 1 permit 131.107.0.0 0.0.255.255 Copyright ©2007 Global Knowledge Training LLC. All rights reserved. Page 5
So, at this point, if the HR manager tried to access the network, he/she will be able to do it, but so would everybody else. Huh! Yes, because we have NOT applied our access-list to any interface yet. So far, all we have done is make our wish list as to what we want to accomplish, but we haven’t put these rules on any of the router interfaces. It’s like hiring a security guard for your party but not specifying what door you want to be monitored. Do you want this security guard to be watching all guests coming in the door or going out of the door? With routers, you have multiple interfaces. (That’s what makes a router a router – the ability to route traffic from one router interface to another towards the destination.) You have to know what traffic you wish to con- trol and which door it will be coming in. Applying an access-list on an incorrect interface might have the wrong impact or might not accomplish anything. The syntax for applying the access-list is: Router(config-if)# {protocol} access-group access-list-number {in | out} So, let’s say we have a router with two fast ethernet interfaces -> fast ethernet 0/0 and fast ethernet 0/1. We want to control the flow from the fast ethernet 0/0. So, to apply this access-list the command would be Router(config)#interface fast ethernet 0/0 Router(config-if)#ip access-group 1 in First we went into the interface configuration mode for fast ethernet 0/0 by using the interface fast ethernet 0/0 command and then we applied the access-list we had previously created by using the ip access-group 1 in command. The number 1 in the ip access-group 1 in command specifies the access-list number we want to accomplish. This number must match the number that we used while creating the access-list. The “in” at the end specifies that we want to look at all the IP packets that are coming into fast ethernet 0/0 and have them go through the permit/deny conditions we have created. Final Product in this standard list example: Router(config)#access-list 1 permit 131.107.2.14 Router(config)#access-list 1 deny 131.107.2.0 0.0.0.255 Router(config)#access-list 1 permit 131.107.0.0 0.0.255.255 Router(config)#interface fast ethernet 0/0 Router(config-if)#ip access-group 1 in Now, let’s look at the extended access-list. With extended access-list, you can specify many more things than just source address of the IP packet. Remember that previously we listed many things that can be checked with extended access-list. Extended access-lists are in the range from 100-199, 2000-2699 (or named extended access-lists). Copyright ©2007 Global Knowledge Training LLC. All rights reserved. Page 6
The syntax for extended access-list is Router(config)# access-list access-list-number {permit | deny} protocol source source-wildcard [operator port] destination destination-wildcard [operator port] [established] [log] Let’s take an example where we want to control users on 10.1.3.0 subnet from accessing the tftp server sitting on the 10.1.4.0 segment with an ip address of 10.1.4.14 Router(config)#access-list 101 deny udp 10.1.3.0 0.0.0.255 10.1.4.14 0.0.0.0 eq 69 In this access-list we are using access-list 101 which falls in the extended access-list range. TFTP communica- tion happens using the UDP protocol so we specified UDP as the protocol; next we used 10.1.3.0 which happens to be our source subnet. We are only keying in on the first three octets by using the 0.0.0 (remember from before that 0 means must match that exact pattern), the last octet in 10.1.3.0 is being ignored. The desti- nation address is a unique IP address 10.1.4.14 where we are matching the exact address and finally specifying the destination protocol to be 69 (eq means equals). TFTP uses protocol number 69. Let’s continue the example with allowing all other type of communication between 10.1.3.0 subnet to 10.1.4.0 subnet. The command for that would be Router(config)#access-list 101 permit ip any any So, the completed access-list looks like Router(config)#access-list 101 deny udp 10.1.3.0 0.0.0.255 10.1.4.14 0.0.0.0 eq 69 Router(config)#access-list 101 permit ip any any Remember, it means nothing unless we apply it. So, let’s apply this on our fast ethernet 0/1 interface. Router(config)#interface fast ethernet 0/1 Router(config-if)#ip access-group 101 in Same as before, we are applying this access-list we created on one of our interfaces. Now ask yourself. Will we be able to initiate TFTP traffic from 10.1.3.0 subnet destined for 10.1.4. ? The answer is yes. We have only denied for TFTP traffic from the 10.1.3.0 subnet to 10.1.4.14. And the second line of our access-list is allowing ALL IP traffic from ANY source to ANY destination. What about telnet traffic from 10.1.3.0 to the same TFTP server 10.1.4.14? The answer again is yes. We have not denied telnet traffic. Telnet uses port 23 for communication and it will be allowed by the second line of statement. Copyright ©2007 Global Knowledge Training LLC. All rights reserved. Page 7
So, as you could see that extended access-lists give us a finer granular control when you are trying to control the traffic. Conclusion The goal of this white paper is to get you thinking about the access-lists. You will realize that there are many other possibilities and many other rules you have to follow to plan your access-lists for your production envi- ronment. Cisco’s ICND 2 class (Interconnecting Cisco Network Devices 2) gives you a more in-depth understanding of the access-lists and how to use them correctly. Learn More Learn more about how you can improve productivity, enhance efficiency, and sharpen your competitive edge. Check out the following Global Knowledge courses: ICND1 (Interconnecting Cisco Network Devices 1) ICND2 (Interconnecting Cisco Network Devices 2) CCNA Boot Camp v2.0 For more information or to register, visit www.globalknowledge.com or call 1-800-COURSES to speak with a sales representative. Our courses and enhanced, hands-on labs offer practical skills and tips that you can immediately put to use. Our expert instructors draw upon their experiences to help you understand key concepts and how to apply them to your specific work situation. Choose from our more than 700 courses, delivered through Classrooms, e-Learning, and On-site sessions, to meet your IT and management training needs. About the Author Dheeraj (Raj) Tolani has been working with Global Knowledge as a contract instructor teaching various net- working courses including CCNA, CCNP, CCIP, CCVP tracks. He has been in the industry for over 15 years working with various technologies, including Cisco, Banyan Vines, Microsoft, and Novell. Dheeraj has worked as a consultant for various medical, financial, legal, government, and publishing companies. He runs a consult- ing company based out of New York City, which provides IP integration solutions. You can visit his Web site at www.rajtolani.com. Copyright ©2007 Global Knowledge Training LLC. All rights reserved. Page 8