Support - Technologie WAN (Lecture 1) (1).pdf

Module « Technologie des réseaux WAN » Elément de module : Commutation et Routage dynamique Filière RST – S7 Pr Chaïmaâ KISSI  IPv4 Switching & Routing  ACL Operation Purpose and operation of ACLs in small...

Module « Technologie des réseaux WAN » Elément de module : Commutation et Routage dynamique Filière RST – S7 Pr Chaïmaâ KISSI  IPv4 Switching & Routing  ACL Operation Purpose and operation of ACLs in small to medium-sized business networks : - How ACLs filter traffic ? - How ACLs use wildcard masks ? - How to create ACLs ? - How to place ACLs ?  Standard IPv4 ACLs Configure standard IPv4 ACLs to filter traffic in a small to medium-sized business network : - Configure standard IPv4 ACLs to filter traffic to meet networking requirements - Use sequence numbers to edit existing standard IPv4 ACLs - Configure a standard ACL to secure VTY access  Troubleshoot ACLs How a router processes packets when an ACL is applied ? Troubleshoot common standard IPv4 ACL errors using CLI commands  IPv4 Switching & Routing  What is an ACL? An ACL is a series of IOS commands that control whether a router forwards or drops packets based on information found in the packet header.  ACLs are not configured by default on a router.  ACL performing tasks Limit network traffic to increase network performance.  For example, video traffic could be blocked if it's not permitted. Provide traffic flow control.  ACLs can help verify routing updates are from a known source. ACLs provide security for network access and can block a host or a network. Filter traffic based on traffic type such as Telnet traffic. Screen hosts to permit or deny access to network services such as FTP or HTTP.  IPv4 Switching & Routing  Packet Filtering An ACL is a sequential list of permit or deny statements, known as access control entries (ACEs).  ACEs are commonly called ACL statements  Definition When network traffic passes through an interface configured with an ACL, the router compares the information within the packet against each ACE, in sequential order, to determine if the packet matches one of the ACEs. This is referred to as packet filtering.  Tasks Packet Filtering : - Can analyze incoming and/or outgoing packets. - Can occur at Layer 3 or Layer 4. Important remark !!! The last statement of an ACL is always an implicit deny. This is automatically inserted at the end of each ACL and blocks all traffic. Because of this, all ACLs should have at least one permit statement.  IPv4 Switching & Routing  Inbound vs Outbound ACL ACLs define the set of rules that give added control for packets that enter inbound interfaces, packets that relay through the router, and packets that exit outbound interfaces of the router. ACLs can be configured to apply to inbound traffic and outbound traffic : - Inbound ACLs : Incoming packets are processed before they are routed to the outbound interface. - Outbound ACLs : Incoming packets are routed to the outbound interface, and then they are processed through the outbound ACL.  Basic IPv4 ACLs  Introduction IPv4 access control lists (ACL) give network engineers the ability to program a filter into a router. Important Remarks : - Each router, on each interface, for both the inbound and outbound direction, can enable a different ACL with different rules. - Each ACL’s rules tell the router which packets to discard and which to allow through. IPv4 ACLs perform many functions in Cisco routers, with the most common use as a packet filter. Engineers can enable ACLs on a router so that the ACL sits in the forwarding path of packets as they pass through the router. After it is enabled, the router considers whether each IP packet will either be discarded or allowed to continue as if the ACL did not exist.  ACL impact on QoS ACLs can be used for many other IOS features as well. As an example, ACLs can be used to match packets for applying Quality of Service (QoS) features. QoS allows a router to give some packets better service, and other packets worse service. For example, packets that hold digitized voice need to have very low delay, so ACLs can match voice packets, with QoS logic in turn forwarding voice packets more quickly than data packets.  Important Guidelines This section introduces IP ACLs as used for packet filtering, focusing on these aspects of ACLs : - The locations and direction in which to enable ACLs ; - Matching packets by examining headers ; - Taking action after a packet has been matched.  ACL Location and Direction Cisco routers can apply ACL logic to packets at the point at which the IP packets enter an interface, or the point at which they exit an interface. In other words, the ACL becomes associated with an interface and for a direction of packet flow (either in or out). That is, the ACL can be applied inbound to the router, before the router makes its forwarding (routing) decision, or outbound, after the router makes its forwarding decision and has determined the exit interface to use. The arrows in the figure show the locations at which you could filter packets flowing left to right in the topology.  Example : Imagine that you wanted to allow packets sent by host A to server S1, but to discard packets sent by host B to server S1. -> Each arrowed line represents a location and direction at which a router could apply an ACL, filtering the packets sent by host B.  Explanation : The four arrowed lines in the figure point out the location and direction for the router interfaces used to forward the packet from host B to server S1. In this particular example, those interfaces and direction are : - inbound on R1’s F0/0 interface, - outbound on R1’s S0/0/0 interface, - inbound on R2’s S0/0/1 interface, - outbound on R2’s F0/0 interface. - If, for example, you enabled an ACL on R2’s F0/1 interface, in either direction, that ACL could not possibly filter the packet sent from host B to server S1, because R2’s F0/1 interface is not part of the route from B to S1.  Conclusion In short, to filter a packet, you must enable an ACL on an interface that processes the packet, in the same direction the packet flows through that interface. When enabled, the router then processes every inbound or outbound IP packet using that ACL. For example, if enabled on R1 for packets inbound on interface F0/0, R1 would compare every inbound IP packet on F0/0 to the ACL to decide that packet’s fate : to continue unchanged or to be discarded.  Important Guidelines  ACL Location and Direction Matching packets refers to how to configure the ACL commands to look at each packet, listing how to identify which packets should be discarded and which should be allowed through. Each IP ACL consists of one or more configuration commands, with each command listing details about values to look for inside a packet’s headers.  Generally, an ACL command uses logic like “look for these values in the packet header, and if found, discard the packet.”  The action could instead be to allow the packet, rather than discard.  Specifically, the ACL looks for header fields you should already know well, including the source and destination IP addresses, plus TCP and UDP port numbers.  ACL Location and Direction  Example Statement Consider an example with the figure, in which you want to allow packets from host A to server S1, but to discard packets from host B going to that same server. The hosts all now have IP addresses, and the figure shows pseudocode for an ACL on R2. Figure 2-2 also shows the chosen location to enable the ACL: inbound on R2’s S0/0/1 interface. Explanation : Figure 2-2 shows a two-line ACL in a rectangle at the bottom, with simple matching logic: both statements just look to match the source IP address in the packet. When enabled, R2 looks at every inbound IP packet on that interface and compares each packet to those two ACL commands.  Packets sent by host A (source IP address 10.1.1.1) are allowed through,  and those sourced by host B (source IP address 10.1.1.2) are discarded.  What would be done if a match occurs ??? When using IP ACLs to filter packets, only one of two actions can be chosen. The configuration commands use the keywords deny and permit, and they mean (respectively) to discard the packet or to allow it to keep going as if the ACL did not exist.  Types of IP ACLs Beginning with the original standard numbered IP ACLs in the early days of IOS, which could enable the logic shown earlier around Figure 2-2, Cisco has added many ACL features, including the following : - Standard numbered ACLs (1–99) - Extended numbered ACLs (100–199) - Additional ACL numbers (1300–1999 standard, 2000–2699 extended) - Named ACLs - Improved editing with sequence numbers Brief !!!! Briefly, IP ACLs will be either numbered or named in that the configuration identifies the ACL either using a number or a name. ACLs will also be either standard or extended, with extended ACLs having much more robust abilities in matching packets.  Figure 2-3 summarizes the big ideas related to categories of IP ACLs.  Standard Numbered IPv4 ACLs This section is about a type of Cisco filter (ACL) that matches only the source IP address of the packet (standard), is configured to identify the ACL using numbers rather than names (numbered), and looks at IPv4 packets.  Steps followed : This section examines the particulars of standard numbered IP ACLs. First, it examines the idea that one ACL is a list and what logic that list uses. Following that, the text closely looks at how to match the source IP address field in the packet header, including the syntax of the commands. This section ends with a complete look at the configuration and verification commands to implement standard ACLs.  List Logic with IP ACLs (ACE statement) A single ACL is both a single entity and, at the same time, a list of one or more configuration commands. As a single entity, the configuration enables the entire ACL on an interface, in a specific direction, as shown earlier in Figure 2-1. As a list of commands, each command has different matching logic that the router must apply to each packet when filtering using that ACL.  Standard Numbered IPv4 ACLs When doing ACL processing, the router processes the packet, compared to the ACL, as follows : - ACLs use first-match logic. - Once a packet matches one line in the ACL, the router takes the action listed in that line of the ACL and stops looking further in the ACL.  Example : To see exactly what that means, consider the example built around Figure 2-4. This example applies ACL 1 on R2’s S0/0/1 interface, inbound. This sequence of processing an ACL as a list happens for any type of IOS ACL: IP, other protocols, standard or extended , named or numbered. Finally, if a packet does not match any of the items in the ACL, the packet is discarded. The reason is that every IP ACL has a deny all statement implied at the end of the ACL. It does not exist in the configuration, but if a router keeps searching the list, and no match is made by the end of the list, IOS considers the packet to have matched an entry that has a deny action.  Matching Logic and Command Syntax Standard numbered IP ACLs use the following global command : Each standard numbered ACL has one or more access-list commands with the same number, any number from the ranges shown in the preceding line of syntax. IOS refers to each line in an ACL as an Access Control Entry (ACE), but many engineers just call them ACL statements. QUE PASA NEXT ???? Besides the ACL number, each access-list command also lists the action (permit or deny), plus the matching logic. The rest of this section examines how to configure the matching parameters, which, for standard ACLs, means that you can only match the source IP address or portions of the source IP address using something called an ACL wildcard mask.  Matching the Exact IP Address To match a specific source IP address, the entire IP address, all you have to do is type that IP address at the end of the command. Note that in later IOS versions, if you use the host keyword, IOS accepts the command but then removes the keyword.  Matching a Subset of the Address with Wildcards  Context and reasons : Often , the business goals you want to implement with an ACL do not match a single particular IP address, but rather a range of IP addresses. Maybe you want to match all IP addresses in a subnet. Maybe you want to match all IP addresses in a range of subnets. Regardless, you want to check for more than one IP address in a range of addresses.  Solution !!!! IOS allows standard ACLs to match a range of addresses using a tool called a wildcard mask. Note that this is not a subnet mask. The wildcard mask (which abbreviates as WC mask) gives the engineer a way to tell IOS to ignore parts of the address when making comparisons, essentially treating those parts as wildcards, as if they already matched. Logical processing idea : You can think about WC masks in decimal and in binary, and both have their uses. To begin, think about WC masks in decimal, using these rules : - Decimal 0: The router must compare this octet as normal. - Decimal 255: The router ignores this octet, considering it to already match.  Matching a Subset of the Address with Wildcards Keeping these two rules in mind, consider Figure 2-6, which demonstrates this logic using 3 different but popular WC masks : - one that tells the router to ignore the last octet, - one that tells the router to ignore the last 2 octets, - and one that tells the router to ignore the last 3 octets.  Figure interpretation : The example on the left shows WC mask 0.0.0.255, which tells the router to treat the last octet as a wildcard, essentially ignoring that octet for the comparison. Similarly, the middle example shows WC mask 0.0.255.255, which tells the router to ignore the 2 octets on the right. The rightmost case shows WC mask 0.255.255.255, telling the router to ignore the last three octets when comparing values.  Matching a Subset of the Address with Wildcards  Example interpretation : Figure 2-7 shows the updated version of Figure 2-4, but with the completed, correct syntax, including the WC masks. In particular, note the use of WC mask 0.0.0.255 in the second command, telling R2 to ignore the last octet of the number 10.1.1.0, and the WC mask 0.255.255.255 in the third command, telling R2 to ignore the last three octets in the value 10.0.0.0.  Finding the Right Wildcard Mask to Match a Subnet In many cases, an ACL needs to match all hosts in a particular subnet. To match a subnet with an ACL, you can use the following shortcut : - Use the subnet number as the source value in the access-list command. - Use a wildcard mask found by subtracting the subnet mask from 255.255.255.255. For example, for subnet 172.16.8.0 255.255.252.0, use the subnet number (172.16.8.0) as the address parameter, and then do the following math to find the wildcard mask :  Matching Any/All Addresses In some cases, you will want one ACL command to match any and all packets that reach that point in the ACL. For example, to permit all packets :  Implementing Standard IP ACLs The command is :  Process to follow :  Standard Numbered ACL Examples  Example 1 The first example shows the configuration for the same requirements demonstrated with Figure 2-4 and Figure 2- 5. Restated, the requirements for this ACL are as follows : Example 2-1 shows a completed correct configuration, starting with the configuration process, followed by output from the show running-config command.  Standard Numbered ACL Examples  Example 1 (suite) Example 2-2 lists some output from Router R2 that shows information about this ACL. The show ip access-lists command lists details about IPv4 ACLs only, while the show access lists command lists details about IPv4 ACLs plus any other types of ACLs that are currently configured; for example, IPv6 ACLs. Command interpretation : The first line of output in this case notes the type (standard) and the number. If more than one ACL existed, you would see multiple stanzas of output, one per ACL, each with a heading line like this one. Next, these commands list packet counts for the number of packets that the router has matched with each command. For example, 107 packets so far have matched the first line in the ACL.  Example 2 o Scenario : For the second example, use Figure 2-8, and imagine your boss gives you some requirements hurriedly in the hall. At first, he tells you he wants to filter packets going from the servers on the right toward the clients on the left. Then, he says he wants you to allow access for hosts A, B, and other hosts in their same subnet to server S1, but deny access to that server to the hosts in host C’s subnet. Then, he tells you that, additionally, hosts in host A’s subnet should be denied access to server S2, but hosts in host C’s subnet should be allowed access to server S2—all by filtering packets going right to left only. He then tells you to put the ACL inbound on R2’s F0/0 interface. o Answer : o Issue : As it turns out, you cannot do everything your boss asked with a standard ACL. For example, consider the obvious command for requirement number 2: access-list 2 permit 10.2.2.1. That permits all traffic whose source IP is 10.2.2.1 (server S1). The very next requirement asks you to filter (deny) packets sourced from that same IP address! Even if you added another command that checked for source IP address 10.2.2.1, the router would never get to it, because routers use first-match logic when searching the ACL. You cannot check both the destination and source IP address, because standard ACLs cannot check the destination IP address. o Solution : To solve this problem, you should get a new boss! No, seriously, you have to rethink the problem and change the rules. In real life, you would probably use an extended ACL instead, which lets you check both the source and destination IP address. Tips : For the sake of practicing another standard ACL, imagine your boss lets you change the requirements. First, you will use two outbound ACLs, both on Router R1. Each ACL will permit traffic from a single server to be forwarded onto that connected LAN, with the following modified requirements : o Interpretation details : As highlighted in the example, the solution with ACL number 2 permits all traffic from server S1, with that logic enabled for packets exiting R1’s F0/0 interface. All other traffic will be discarded because of the implied deny all at the end of the ACL. In addition, ACL3 permits traffic from server S2, which is then permitted to exit R1’s F0/1 interface. Also, note that the solution shows the use of the access-list remark parameter, which allows you to leave text documentation that stays with the ACL.  Troubleshooting and Verification Tips Troubleshooting IPv4 ACLs requires some attention to detail. In particular, you have to be ready to look at the address and wildcard mask and confidently predict the addresses matched by those two combined parameters. First, you can tell if the router is matching packets or not with a couple of tools.  Example : Example2-2 already showed that IOS keeps statistics about the packets matched by each line of an ACL. In addition, if you add the log keyword to the end of an access-list command, IOS then issues log messages with occasional statistics about matches of that particular line of the ACL. Both the statistics and the log messages can be helpful in deciding which line in the ACL is being matched by a packet.  Example 2-4 shows an updated version of ACL 2 from Example 2-3, this time with the log keyword added. The bottom of the example then shows a typical log message, this one showing the resulting match based on a packet with source IP address 10.2.2.1 (as matched with the ACL), to destination address 10.1.1.1. MUY IMPORTANTE !!!!!!! When you troubleshoot an ACL for the first time, before getting into the details of the matching logic, take the time to think about both the interface on which the ACL is Enabled and the direction of packet flow.  Sometimes, the matching logic is perfect— but the ACL has been enabled on the wrong interface, or for the wrong direction, to match the packets as configured for the ACL.  Example : Figure 2-9 repeats the same ACL shown earlier in Figure 2-7. The first line of that ACL matches the specific host address 10.1.1.1. If that ACL exists on Router R2, placing that ACL as an inbound ACL on R2’s S0/0/1 interface can work, because packets sent by host 10.1.1.1—on the left side of the figure—can enter R2’s S0/0/1 interface.  However, if R2 enables ACL 1 on its F0/0 interface, for inbound packets, the ACL will never match a packet with source IP address 10.1.1.1, because packets sent by host 10.1.1.1 will never enter that interface.  Packets sent by 10.1.1.1 will exit R2’s F0/0 interface, but never enter it, just because of the network topology.  Extended Numbered IPv4 ACLs  Standard vs Extended Extended IP access lists have many similarities compared to the standard numbered IP ACLs discussed in the previous chapter. Extended ACLs differ from standard ACLs mostly because of the larger variety of packet header fields that can be used to match a packet. One extended ACE (ACL statement) can examine multiple parts of the packet headers, requiring that all the parameters be matched correctly to match that one ACE.  Matching the Protocol, Source IP, and Destination IP Like standard numbered IP ACLs, extended numbered IP ACLs also use the access-list global command. The syntax is identical, at least up through the permit or deny keyword. In particular, the extended ACL access-list command requires three matching parameters: - the IP protocol type, - the source IP address, - and the destination IP address.  Extended Numbered IPv4 ACLs The IP header’s Protocol field identifies the header that follows the IP header. Figure 3-2 shows the location of the IP Protocol field, the concept of it pointing to the type of header that follows, along with some details of the IP header for reference. IOS requires that you configure parameters for the three highlighted parts of Figure 3-2. For the protocol type, you simply use a keyword, such as tcp, udp, or icmp, matching IP packets that happen to have a TCP, UDP, or ICMP header, respectively, following the IP header. Or you can use the keyword ip, which means “all IPv4 packets.” You also must configure some values for the source and destination IP address fields that follow.  Extended Numbered IPv4 ACLs Table 3-2 lists several sample access-list commands that use only the required matching parameters.  Matching TCP and UDP Port Numbers Extended ACLs can also examine parts of the TCP and UDP headers, particularly the source and destination port number fields. The port numbers identify the application that sends or receives the data. Figure 3-4 shows the location of the port numbers in the TCP header, following the IP header.  Extended Numbered IPv4 ACLs Figure 3-5 shows the positions of the source and destination port fields in the access-list command and these port number keywords.  Example : Consider the simple network shown in Figure 3-6. The FTP server sits on the right, with the client on the left. The figure shows the syntax of an ACL that matches the following : - Packets that include a TCP header - Packets sent from the client subnet - Packets sent to the server subnet - Packets with TCP destination port 21 (FTP server control port)  Inverse Process : Conversely, Figure 3-7 shows the reverse flow, with a packet sent by the server back toward PC1. In this case, the packet’s TCP header has a source port of 21, so the ACL must check the source port value of 21, and the ACL must be located on different interfaces. In this case, the eq 21 parameters follow the source address field but come before the destination address field.  ACL Examination : When examining ACLs that match port numbers, first consider the location and direction in which the ACL will be applied. That direction determines whether the packet is being sent to the server or from the server. At that point, you can decide whether you need to check the source or destination port in the packet. For reference, Table 3-3 lists many of the popular port numbers and their transport layer protocols and applications.  Note that the syntax of the access-list commands accepts both the port numbers and a shorthand version of the application name.  Extended IP ACL Configuration The configuration process for extended ACLs mostly matches the same process used for standard ACLs. You must choose the location and direction in which to enable the ACL, particularly the direction, so that you can characterize whether certain addresses and ports will be either the source or destination. Configure the ACL using access-list commands, and when complete, then enable the ACL using the same ip access-group command used with standard ACLs.  MUY IMPORTANTE REMARK !!!!! Place extended ACLs as close as possible to the source of the packets that will be filtered. Filtering close to the source of the packets saves some bandwidth. => Remember that all fields in one access-list command must match a packet for the packet to be considered to match that access-list statement.  Use numbers of 100–199 and 2000–2699 on the access-list commands; no one number is inherently better than another.  Extended IP Access Lists Example This example focuses on understanding basic syntax. In this case, the ACL denies Bob access to all FTP servers on R1’s Ethernet, and it denies Larry access to Server1’s web server. Figure 3-8 shows the network topology; Example 3-1 shows the configuration on R1.  Extended IP Access Lists Example This example uses the eq parameter, meaning “equals,” to check the destination port numbers for FTP control (keyword ftp) and HTTP traffic (keyword www). You can use the numeric values—or, for the more popular options, a more obvious text version is valid. If you were to type eq 80, the config would show eq www. This example enables the ACL in two places on R1: inbound on each serial interface. These locations achieve the goal of the ACL. However, that initial placement was made to make the point that Cisco suggests that you locate them as close as possible to the source of the packet.  Extended IP Access Lists Example Example 3-2 achieves the same goal as Example 3-1 of stopping Bob’s access to FTP servers at the main site, and it does so with an ACL on R3. The new configuration on R3 meets the goals to filter Bob’s traffic, while also meeting the overarching design goal of keeping the ACL close to the source of the packets. ACL 103 on R3 looks a lot like ACL 101 on R1 from Example 3-1, but this time, the ACL does not bother to check for the criteria to match Larry’s traffic, because Larry’s traffic will never enter R3’s Ethernet 0 interface. ACL 103 filters Bob’s FTP traffic to destinations in subnet 172.16.1.0/24, with all other traffic entering R3’s E0 interface making it into the network. Named ACLs and ACL Editing Figure 3-10 shows just such a conversion, using a simple three-line standard ACL number 1. Example 3-4 shows the configuration of a named extended ACL. Named ACLs and ACL Editing Named ACLs allow the user to delete and add new lines to the ACL from within ACL configuration mode. Example 3-5 shows how, with the no deny ip… command deleting a single entry from the ACL.  Editing ACLs Using Sequence Numbers Example 3-6 shows the configuration of a standard numbered IP ACL, using this alternative configuration style. In this example, the following occurs :