CCNA3 Module 5: ACLs for IPv4 Configuration - Enterprise Networking, Security, and Automation (ENSA)

The module concludes with a summary of learned concepts: creating, modifying, and applying numbered and named standard and extended ACLs, securing VTY ports, and using the 'established' keyword. Viewers are encouraged to practice with provided Packet Tracer files for hands-on experience. Sequence numbers in ACLs are automatically assigned (10, 20, 30, etc.) upon creation of an ACE.

This lecture introduces Module 5 of the Cisco Netacad CCNA3 series, focusing on IPv4 ACLs. The main objective is to implement IPv4 ACLs for traffic filtering and administrative access security. Highlights include configuring and modifying standard and extended IPv4 ACLs and securing VTY ports. Viewers are recommended to review Module 4 first for foundational ACL concepts.

To implement ACLs effectively, planning is crucial. It's recommended to use a text editor for complex ACLs, writing out policies and IOS commands, including remarks for documentation, and thoroughly testing. Numbered standard ACLs use the 'access-list' command with a number (1-99 or 1300-1999), followed by 'deny', 'permit', or 'remark', source IP, and wildcard mask. Named standard ACLs use 'ip access-list standard' followed by a unique, case-sensitive alphanumeric name.

Once configured, a standard IPv4 ACL must be bound to an interface using the 'ip access-group' command. Examples demonstrate creating a numbered ACL to permit specific host and network traffic, then applying it to a serial interface. Similarly, a named ACL is created and applied to the same interface. Verification can be done using 'show running-config' and 'show ip interface' commands.

Two methods for modifying ACLs are using a text editor or sequence numbers. The text editor method involves copying the ACL from the running configuration, editing it, removing the old ACL, and pasting the modified version. The sequence number method allows deleting or adding specific Access Control Entries (ACEs) using their sequence numbers directly in the configuration mode. ACLs process statements from top to bottom, so order matters.

The 'show access-list' command displays statistics on how many times each ACL entry has been matched. Implicit 'deny any' statements do not show statistics unless explicitly configured with 'deny any'. The 'clear access-list counters' command can reset these statistics for troubleshooting purposes.

Standard ACLs can secure remote administrative access to VTY lines. This involves creating an ACL to define allowed administrative hosts and applying it to incoming traffic on VTY lines using the 'access-class' command. An example shows configuring a local user, creating a named ACL 'admin-host' to permit a specific IP, denying all others, and then applying this ACL to VTY lines for inbound Telnet access. Verification involves checking 'show access-list' after attempting access from permitted and denied sources.

Extended ACLs provide more granular control by filtering on source, destination, protocol (IP, TCP, UDP, ICMP, FTP, etc.), and port numbers, operating at Layer 4. They can be numbered (100-199 or 2000-2699) using 'access-list' or named using 'ip access-list extended'. The '?' command in Cisco IOS is helpful for discovering available protocol and port options.

Extended ACLs can filter based on internet protocols and ports. The choice of protocol influences available port options. Examples demonstrate configuring ACLs to filter HTTP traffic using either port names (e.g., 'www') or port numbers (e.g., '80'). For protocols without specific names in the IOS, such as SSH (port 22) or HTTPS (port 443), port numbers must be used explicitly.

Similar to standard ACLs, extended ACLs are applied to interfaces usually closer to the source. An example shows an extended ACL (110) permitting HTTP and HTTPS traffic from a specific network, applied inbound on an interface. The 'ip access-group' command is used for binding. The 'established' keyword for TCP in ACLs enables basic stateful firewall services, permitting return traffic for internally initiated connections while denying outside-initiated connections.

Naming extended ACLs enhances readability. They are created using 'ip access-list extended <name>', which transitions to a sub-configuration mode. An example demonstrates creating a 'surfing' ACL to permit internal HTTP/HTTPS traffic out to the internet, and a 'browsing' ACL with the 'established' keyword to permit only returning web traffic back to internal hosts. These are then applied inbound and outbound, respectively, on the same interface.

Verification of extended ACLs can be done using 'show ip interface' to confirm application to interfaces and traffic direction (inbound/outbound), and 'show access-list' to check statistics and confirm expected behavior. Traffic generation is necessary for statistics to appear. 'Show running-config' can display the configured ACLs with remarks.