Cisco switch configuration and application techniques of extension ACL for graphic settings

Whether it's on a Cisco router or a network device such as a Cisco switch, the standard ACL access control list is always unable to match both the traffic source address and the destination address, nor does it meet the requirements of the "granular" control of the current network world, such as: A service function that allows access to a server, However, pinging the server is not allowed. In this case, an extended ACL is needed to replace the standard ACL application, and in actual application control, the extended ACL seems to be more popular with administrators than standard ACLs.

Demo Goal: Configure extended ACLs to provide more granular control over network applications.

Demo environment: This is shown in the demo environment using the following image ACL for the configuration section demonstrating the standard ACL.

Demo background: Requires host a (192.168.1.2) to have access to server A's Web services, but does not allow hosts to aping the subnet on which server a resides, and allows hosts to aping the subnets of Server B and Server C. Use the extended ACL to complete the above control requirements and consider where to apply ACLs.

Demo steps:

Step one: Keep all of the underlying configurations of the previous experiment, but remove all of the original standard ACL configurations and complete the following extended ACL configuration based on the presentation background requirements, which is recommended for router R1, because the extended ACL can match both the source and destination addresses. It should be positioned closer to the source of the communication.

R1 (config) #access-list101permittcp192.168.1.00.0.0.255host192.168.5.2eqwww

* Define extended ACL list 101 (IP-based extended ACL numbering range is 100-199); Permittcp192.168.1.00.0.0.255host192.168.5.2eqwww indicates that the source subnet 192.168.1.0 is allowed to access TCP port 80 on the destination address 192.168.5.2, note that the first IP subnet and the counter code in the statement indicate the source subnet of the communication With the corresponding counter code; the second IP address, 192.168.5.2, is declared by the host to be a specific host.

R1 (config) #access-list101denyicmp192.168.1.00.0.0.255host192.168.5.2

* The second statement that defines the extended ACL list 101 denies the source subnet 192.168.1.0 access to the target host 192.168.5.2 through the ICMP protocol.

R1 (config) #access-list101permiticmp192.168.1.00.0.0.255host192.168.4.2

* The third statement that defines the extended ACL list 101 allows the source subnet 192.168.1.0 to access the target host 192.168.4.2 through the ICMP protocol.

R1 (config) #access-list101permiticmp192.168.1.00.0.0.255host192.168.3.2

* The fourth statement that defines the extended ACL listing 101 allows the source subnet 192.168.1.0 to access the target host 192.168.3.2 through the ICMP protocol.

R1 (config) #interfacee1/0

R1 (config-if) #ipaccess-group101in

R1 (config-if) #exit

Recommendation: Apply the ACL101 to the router's R1 e1/0 interface, which is the closest location to the source subnet, which makes the ACL more efficient and more reasonable, because the extended ACL can match both the source and destination addresses, so theoretically, as long as the control standards are met, It can be applied on any device that is passing through, but it is recommended that it be applied at a location closest to the source subnet, because it is not necessary to forward the final filtered traffic to the target or midway to discard it, which is unscientific for the valuable bandwidth utilization.

The second step: when the above configuration is completed, access to server A's Web services in Host a (192.168.1.2), and then ping servers A, B, C, if configured correctly, you should get the status shown in the following figure, which is consistent with the control requirements in the background note.

Step three: In order to view the filtering status on the router R1, you can view the matching status of the ACL by performing the showipaccess-lists instruction on R1, as shown in Figure 10.13, which shows that 5 www packets are allowed, and 8 packets of ICMP to server A are rejected; There are 4 ICMP packets to Server B and C, respectively, that are allowed.

Other forms of transmission and application considerations for ACLs

The application of standards and extended ACLs is described in the previous sections, and the specific configuration process is illustrated in this section, which summarizes the application of ACLs, including the way in which ACLs are written, where they are applied, and the additions and deletions of ACL entries, as follows:

About the input form of an ACL statement:

access-list1permithost192.168.100.1 equals access-list1permit192.168.100.10.0.0.0 function, the host in the statement is the stated address of the configuration is a host address, it is equal to the full match of the inverse code (0.0.0.0), an inverse code that appears as a full match, indicating that the matching IP address is a host IP address.

Access-list102permittcp0.0.0.0255.255.255.2550.0.0.0255.255.255.255eqwww equals access-list102permittcpanyanyeq80 function, the source IP address in the statement and The destination IP address is 0, indicates that the source and destination IP addresses can be any IP address, the source address and the destination address are all 255, indicating that no bit is cared for, and that it is equivalent to the case where both the source and destination IP addresses are in the extended ACL in any keyword; eqwww equals eq80, Because the TCP80 port is a well-known WWW service port, here is a note that if the Web server's port does not use the well-known port number 80th, for some security reason or special requirements, the server administrator has customized the web's service port number, then, when the write ACL, You can only declare the specific port number after the EQ keyword, not the WWW, or the ACL will not complete the match.

access-list102permitiphost192.168.1.2host192.168.2.2 equals access-list102permitip192.168.1.20.0.0.0192.168.2.20.0.0.0 ; The source IP and destination IP in the ACL statement are the specific host IP addresses, so the host keyword can be declared in the ACL statement, which is the same as the meaning of the full matching form of the inverse code.

About the design of the ACL application location:

The n standard ACL is only concerned with the source address, so it must be applied to the nearest interface location of the distance control target.

The n extension ACL is concerned with both the source address and the destination address, it is recommended to apply it to the nearest interface location of the control source, which can optimize the flow and reduce the overhead of the backbone network.

N Only one access control list can be applied to the same interface, the same protocol, and the same direction.

n Access control list that only filters traffic through the router and does not take effect on local traffic generated by routers that apply access control lists.

About the increase and deletion of ACL entries in the traditional iOS version

In the traditional version of iOS, adding or deleting ACL entries is a very painful thing to do, because when multiple statements of an ACL are configured after a router, if you want to add a filter statement to the ACL, the added statement will appear after all existing ACL statements. This creates a security vulnerability that poses a risk behavior for the network, and for a better understanding of this, one example is now:

For the first time, the user has finished writing a ACL101:

ACL101 's first statement: access-list101denyiphost192.168.1.2host192.168.2.1

ACL101 's second statement: Access-list101permitipanyany

Now that the user wants to change the original ACL101, you want to add an ACL statement between the two statements as follows:

access-list101denyiphost192.168.3.1host192.168.4.1

But when you're done, the added statement will be placed at the end of the ACL101, as the following illustration shows, it matches the order as shown, and the last added statement is placed at the end of the ACL list, and the second statement is the one that allows any traffic, so there is no chance of matching the third statement. Then the third statement will never take effect, even if you may want it to take effect before permitanyany, but in fact it does not, this is similar to the principle of the microcomputer inside the stack principle, first enter. Called first.

So in traditional iOS, administrators have a headache for modifying ACLs, and often administrators copy the ACL into a text file to add or DELETE statements, then remove the ACLs that were originally configured on the router through noaccess-list101, Then the modified ACL in the text file is copied to the router, and the effect of the ACL statement can not be modified.

Add and remove ACL entries using the enhanced editing capabilities of ACLs

The new iOS will break traditional iOS restrictions on ACL entry modifications, as the following illustration shows, it adds a serial number to each ACL statement, such as the serial number of the first ACL statement is 10, the second ACL statement has a sequence number of 20, and 10 as the cardinal number of the first ACL, and then, A new ACL statement is incremented by 10, so if you need to add an ACL statement between the serial Number 10 and 20, just add a sequence number that falls between 10-20, and the new ACL statement will exist between 10 and 20.

For example, now, between 10 and 20, an ACL statement with a serial number of 15 is added, as shown in the following, where the 15 in the configuration statement indicates the serial number of the ACL statement that is about to be inserted, and when the configuration is complete, You can use showipaccess-lists on routers to view the statements for each ACL as shown in Figure 10.16, it can be seen that an ACL statement with a sequence of 15 is found between serial Number 10 and 20, which breaks the traditional iOS's difficulty in ACL editing, which enhances the ability to edit ACLs.

A configuration with a serial number of 15 is inserted between two ACL statements:

R1 (config) #ipaccess-listextended101

R1 (Config-ext-nacl) #15denyiphost192.168.3.1host192.168.4.1

#FormatImgID_5 #

There are so many versions of iOS, how do you know which iOS versions support ACL enhancements when used, and which versions of iOS do not support ACL-enhanced editing? It's simple, users don't have to remember the version number of iOS, because it's a really hard thing to remember, You can view the ACL list directly through showipaccess-lists, and if you have a sequence number in front of each ACL statement in the display result, the device supports enhanced editing of the ACL, not the other way around.

Question: Why does the iOS system automatically insert a serial number for an ACL statement with 10 as the cardinality (the sequence number of the first ACL statement) and 10 as an increment to insert the subsequent ACL sequence number?

In fact, this is also for the convenience of editing ACLs, when the first ACL statement is generated, the serial number cardinality is set to 10, in order to reserve space for inserting the ACL before the original first ACL statement, at least 1-9 ACL statements can be inserted, and subsequent ACLs are incremented by 10. Of course, users can change the cardinality of the first ACL when it is automatically inserted and the incremental number of subsequent ACLs, depending on their requirements, but I recommend that you keep the default configuration.