Network security is as important now than ever with data getting bigger and more precious. As network security helps businesses reduce the risk of data theft and disturbance in production network operations, it is key to understand your security environment. An access control list (ACL) provides the network security in your routing and switching environments through a rule or series of rules that can permit or deny data traffic from the network layer. Today, we will look at ACL concepts as well as troubleshooting common cases that you may see.
A quick note before we dive in. Where there are no specific prerequisites for applying ACL in the network, it should be done with professional network/security engineers. This feature is in Cisco IOS software releases 8.3 or later, and uses packet filtering. Packet filtering is a firewall technique used to control network access by monitoring outgoing and incoming packets while allowing them to pass or halt based on the source and destination Internet Protocol (IP) addresses, protocols, and ports. We can set the configuration (as you'll see below) to IP filter traffic in Cisco layer 3 switches, such as the Nexus switches, between two different SIV's/VLANs. Let's dive in!
Why ACL in Networks
The ACLs work by blocking specified traffic to enhance the performance of the network. A strong security is provided though blocking packets that are destined to sensitive areas in the network. Determination of the type of traffic to forward based on the protocols takes places to then deny certain users access to the internet while allowing others. Please note that we are not focusing on access list types today, but if you would like to access more information, click here to get in touch!
The example we will use today uses a PivIT environment with Nexus switches. We will show you a couple of rules to you can use, but you can add or remove rules from the default network ACL. When rules are added or removed they are automatically applied to the subnets that the ACL is associated with. Parts of a network ACL rule include:
- Rule Number
- Type
- Protocol
- Port Range
- Source
- Destination
- Allow/Deny
Access control lists are a principal element in securing your network, and understanding their function is essential to achieving their best effectiveness. Below are a few rules and configurations to help gain the knowledge and understanding around ACLs and basic rules to apply.
Step-by-Step Configurations
We have created one VLAN (154) in both Nexus switches. In the diagram below, you can also check the recommended way to configure SVI in the Cisco 9500 series switches to get the maximum output. Note: The configurations below can only be done on Cisco Nexus Layer 3 switches.
Step 1. Create VLAN in both Nexus Core Switches
Core 1 Configurations:
Core 2 Configurations:
Step 2. Create SVI on both Nexus Core Switches
A Switched Virtual Interface (SVI) is a routed interface in IOS representing the IP addressing space for a particular VLAN connected to this interface. There is no physical interface for the VLAN, and the SVI provides the Layer 3 processing for packets from all switch ports associated with the VLAN.
With SVIs the switch will use a virtual Layer 3 interface to route traffic to another Layer 3 interface thus eliminating the need for a physical router. VLANs reduce the load on a network by dividing a LAN into smaller segments and keeping local traffic within a VLAN. However, because each VLAN has its own domain, a mechanism is needed for VLANs to pass data to other VLANs without passing the data through a router. We'll now show those configurations to create the SVI.
Core 1 Configurations:
Core 2 Configurations:
Step 3. Create Access List to Block All Traffic from VLAN 154
Before configuring the ACL rule, verify the inter VLAN communication between the two VLANs. Below is what the verification should look like.
Now we'll block the inter VLAN traffic between two VLANs through an ACL rule, but first we will create the access list.
Next, we need to apply this access list in VLAN 154 SVI. This makes it to where both VLANs cannot communicate with each other. If we do not apply the access list in SVI, the case will not work.
Step 4. ACL Cases
Scenario 1: No one can access VLAN 154 through 8080 port
Scenario 2: Block ICMP from VLAN 154
Scenario 3: Support 888 port for 10.0.121.15 IP address
Scenario 4: Show access list commands
About PivIT Global
PivIT Global provides the support you need through infrastructure, maintenance, and professional services. Contact us today to chat more about configuring an ACL in SVI environments or how we can support you through our third-party maintenance and professional services offerings.
VLAN access-lists (VACL) are very useful if you want to filter traffic within the VLAN. Let me give you an example:
Let’s say I want to make sure that the two computers are unable to communicate with the server. You could use port-security to filter MAC addresses but this isn’t a very safe method.
I will show you how to configure a VACL so that the two computers won’t be able to reach the server. First we have to create an access-list:
SW1(config)#access-list 100 permit ip any host 192.168.1.100First step is to create an extended access-list. Traffic from any source to destination IP address 192.168.1.100 should match my access-list. This might look confusing to you because your gut will tell you to use “deny” in this statement…don’t do it though, use the permit statement!
SW1(config)#vlan access-map NOT-TO-SERVER 10 SW1(config-access-map)#match ip address 100 SW1(config-access-map)#action drop SW1(config-access-map)#vlan access-map NOT-TO-SERVER 20 SW1(config-access-map)#action forwardNext step is to create the VACL. Mine is called “NOT-TO-SERVER”.
• Sequence number 10 will look for traffic that matches access-list 100. All traffic that is permitted in access-list 100 will match here. The action is to drop this traffic.
• Sequence number 20 doesn’t have a match statement so everything will match, the action is to forward traffic.
As a result all traffic from any host to destination IP address 192.168.1.100 will be dropped, everything else will be forwarded.
SW1(config)#vlan filter NOT-TO-SERVER vlan-list 10Last step is to apply the VACL to the VLANs you want. I apply mine to VLAN 10. Let’s see if this works or not…
The switch supports the following four types of ACLs for traffic filtering:
- Router ACL
- Port ACL
- VLAN ACL
- MAC ACL
Router ACL
As the name implies, Router ACLs are similar to the IOS ACL discussed in Chapter 2, "Access Control," and can be used to filter network traffic on the switched virtual interfaces (SVI). (SVI interfaces are Layer 3 interfaces on VLANs, on Layer 3 physical interfaces, and on Layer 3 EtherChannel interfaces.) Both standard and extended ACLs are supported. For more details to configure Router ACL, refer to Chapter 2.
Port ACL
Port ACLs are similar to Router ACLs but are supported on physical interfaces and configured on Layer 2 interfaces on a switch. Port ACL supports only inbound traffic filtering. Port ACL can be configured as three type access lists: standard, extended, and MAC-extended.
Processing of the Port ACL is similar to that of the Router ACLs; the switch examines ACLs associated with features configured on a given interface and permits or denies packet forwarding based on packet-matching criteria in the ACL.
When applied to a trunk port, the ACL filters traffic on all VLANs present on the trunk port. When applied to a port with voice VLAN, the ACL filters traffic on both data and voice VLANs.
The main benefit with Port ACL is that it can filter IP traffic (using IP access lists) and non-IP traffic (using MAC access list). Both types of filtering can be achieved—that is, a Layer 2 interface can have both an IP access list and a MAC access list applied to it at the same time.
VLAN ACL (VACL)
VLAN ACL (also called VLAN map) provides packet filtering for all types of traffic that are bridged within a VLAN or routed into or out of the VLAN. Unlike Router ACL, VACL is not defined by a direction (input or output). All packets entering the VLAN (bridged or routed) are checked against the VACL. It is possible to filter traffic based on the direction of the traffic by combining VACLs and Private VLAN features.
VACLs are processed in hardware, so there is no performance penalty in processing them. Therefore, they are also referred to as wire-speed ACLs. The forwarding rate remains unchanged regardless of the size of the access list because the lookup of VACLs is performed in hardware.
VACL on a Bridged Port
Figure 4-2 illustrates where the VACL is processed when VACL is applied on a bridged port for traffic from Host A in VLAN 5 that is communicating to Host B in VLAN 10 through the switch.
Figure 4-2 VACL on a Bridged Port
VACL on a Routed Port
Figure 4-3 illustrates how IOS ACL and VACL are applied on routed packets and Layer 3 switched packets. Following is the order of processing:
- VACL for input VLAN
- Input IOS ACL
- Output IOS ACL
- VACL for output VLAN
Figure 4-3 VACL on a Routed Port
Configuring VACL
Perform the following steps to configure and apply a VACL (VLAN access map) on the switch:
- Define the standard or extended access list to be used in VACL.
- Define a VLAN access map.
- Configure a match clause in a VLAN access map sequence.
- Configure an action clause in a VLAN access map sequence.
- Apply the VLAN access map to the specified VLANs.
- Display VLAN access map information.
Example 4-6 shows how to define and apply a VACL to drop packets matching access list 1 from network 192.168.1.0/24; all other packets matching access list 2 are forwarded. The VACL is applied to VLANs 5 through 10.
Example 4-6. VACL Configuration Example
Switch(config)#access-list 1 permit 192.168.1.0 0.0.0.255 Switch(config)#access-list 2 permit any Switch(config)#vlan access-map mymap 10 Switch(config-access-map)#match ip address 1 Switch(config-access-map)#action drop Switch(config-access-map)#exit Switch(config)#vlan access-map mymap 20 Switch(config-access-map)#match ip address 2 Switch(config-access-map)#action forward Switch(config-access-map)#exit Switch(config)# vlan filter mymap vlan-list 5-10 Switch(config-access-map)#end Switch# show vlan access-map Vlan access-map "mymap" 10 Match clauses: ip address: 1 Action: drop Vlan access-map "mymap" 20 Match clauses: ip address: 2 Action: Forward Switch# show vlan filter VLAN Map mymap is filtering VLANs: 5-10MAC ACL
MAC ACL, also known as Ethernet ACL, can filter non-IP traffic on a VLAN and on a physical Layer 2 interface by using MAC addresses in a named MAC extended ACL. The steps to configure a MAC ACL are similar to those of extended named ACLs. MAC ACL supports only inbound traffic filtering.
To define the MAC Extended ACL, use the mac access-list extended command. Several non-IP protocols are supported.
After the MAC ACL is created, it can be applied to a Layer 2 interface using the mac access-group [acl-name] in command to filter non-IP traffic received on the interface.
Example 4-7 shows how to define and apply a MAC ACL to drop all (non-IP) AppleTalk Address Resolution Protocol (AARP) packets, allowing all other types of traffic.
Example 4-7. MAC ACL Configuration Example
Switch(config)# mac access-list extended my-mac-acl Switch(config-ext-macl)# deny any any aarp Switch(config-ext-macl)# permit any any Switch(config-ext-macl)# exit Switch(config)# interface Fastethernet0/10 Switch(config-if)# mac access-group my-mac-acl in Switch(config-if)# end Switch#Page 2
Spanning Tree Protocol (STP) resolves redundant topologies into loop-free, treelike topologies. When switches are interconnected via multiple paths, STP prevents loops from being formed. An STP loop (or forwarding loops) can occur when the entire network fails because of a hardware failure, a configuration issue, or a network attack. STP loops can be costly, causing major network outages. The following STP features can be used to improve the stability of the Layer 2 networks.
Bridge Protocol Data Unit (BPDU) Guard
Bridge protocol data units (BPDU) are data messages exchanged between bridges using spanning tree protocol to detect loops in a network topology. BPDU contains management and control data information that is used to determine the root bridge and establish the port roles—for example: root, designated, or blocked port.
The BPDU Guard feature is designed to keep the active topology predictable and to enhance switch network reliability by enforcing the STP domain borders.
The guard can be enabled globally on the switch or enabled on a per-interface basis. In a valid configuration, ports with port fast enabled do not receive BPDUs. Receiving a BPDU on a port with port fast enabled signals an invalid configuration, such as the connection of an unauthorized device, and the BPDU Guard feature puts the interface in the error-disabled state.
At the global level, BPDU Guard can be enabled on a port with port fast enabled using the spanning-tree portfast bpduguard default global configuration command. Spanning tree shuts down interfaces that are in a port fast operational state.
At the interface level, BPDU Guard can be enabled on an interface by using the spanning-tree bpduguard enable interface configuration command without also enabling the port fast feature. When the interface receives a BPDU, the switch assumes that a problem exists and puts the interface in the error-disabled state.
The BPDU Guard feature provides a secure response to invalid configurations because you must manually put the interface back in service. In a service-provider network environment, the BPUD Guard feature can be used to prevent an access port from participating in the spanning tree.
Root Guard
In a switched network environment with shared administrative control or in a service provider (SP) environment where there are many connections to other switches (into customer networks), it is important to identify the correct placement of the root bridge. If possible, it is also important to identify a specific predetermined location to achieve an optimal forwarding loop-free topology. There is no mechanism in the standard STP to enforce the position of the root bridge, as any bridge in a network with a lower bridge ID can assume the role of the root bridge. Sometimes because of a misconfiguration, a spanning tree may converge incorrectly by selecting an imprecise switch to be the root switch. This situation can be prevented by enabling the Root Guard feature. For example, you could enable Root Guard on SP-side switch interfaces that connect to a customer-side switch. With the Root Guard feature implemented, if a switch outside the SP network becomes the root switch, the interface is put in a blocked state, and spanning tree will select a new root switch. The customer's switch does not become the root switch and is not in the path to the root.
With the Root Guard feature, a Layer 2 interface is set as the designated port, and if any device through this port becomes the root bridge, the interface is placed into the blocked (root-inconsistent) state. The Root Guard feature can be enabled by using the spanning-tree guard root command in interface configuration mode.
EtherChannel Guard
The EtherChannel Guard feature is used to detect EtherChannel misconfigurations between the switch and a connected device. An example of a misconfiguration is when the channel parameters are not identical and do not match on both sides of the EtherChannel. Another example could be when only one side is configured with channel parameters. EtherChannel parameters must be the same on both sides for the guard to work.
When the switch detects an EtherChannel misconfiguration, the EtherChannel Guard places the switch interface in the error-disabled state and displays an error message.
The EtherChannel Guard feature can be enabled by using the spanning-tree etherchannel guard misconfig global configuration command.
Loop Guard
The Loop Guard feature provides an additional layer of protection against the Layer 2 forwarding loops (STP loops) by preventing alternative or root ports from becoming designated ports because of a failure resulting in a unidirectional link. This feature works best when enabled on all switches across a network. By default, the spanning tree does not send BPDUs on root or alternative ports.
The Loop Guard feature can be enabled by using the spanning-tree loopguard default global configuration command.
Page 3
The DHCP Snooping feature provides network protection from rogue DHCP servers. It creates a logical firewall between untrusted hosts and DHCP servers. The switch builds and maintains a DHCP snooping table (also called DHCP binding database), shown in Figure 4-4a. In addition, the switch uses this table to identify and filter untrusted messages from the network. The switch maintains a DHCP binding database that keeps track of DHCP addresses that are assigned to ports, as well as filtering DHCP messages from untrusted ports. For incoming packets received on untrusted ports, packets are dropped if the source MAC address does not match MAC in the binding table entry.
Figure 4-4a DHCP Snooping Table
Figure 4-4b illustrates the DHCP Snooping feature in action, showing how the intruder is blocked on the untrusted port when it tries to intervene by injecting a bogus DHCP response packet to a legitimate conversation between the DHCP client and server.
Figure 4-4b DHCP Snooping in Action
The DHCP Snooping feature can be configured for switches and VLANs. When enabled on a switch, the interface acts as a Layer 2 bridge, intercepting and safeguarding DHCP messages going to a Layer 2 VLAN. When enabled on a VLAN, the switch acts as a Layer 2 bridge within a VLAN domain.
For DHCP Snooping to function correctly, all DHCP servers connected to the switch must be configured as trusted interfaces. A trusted interface can be configured by using the ip dhcp snooping trust interface configuration command. All other DHCP clients connected to the switch and other ports receiving traffic from outside the network or firewall should be configured as untrusted by using the no ip dhcp snooping trust interface configuration command.
To configure the DHCP Snooping feature, first enable DHCP Snooping on a particular VLAN by using the ip dhcp snooping vlan [vlan-id] command in global configuration mode. (Repeat this command for multiple VLANs.) Next, enable DHCP Snooping globally by using the ip dhcp snooping command from the global configuration mode. Both options must be set to enable DHCP snooping.
In Example 4-8, the DHCP server is connected to the FastEthernet0/1 interface and is configured as a trusted port with a rate limit of 100 packets per second. The rate limit command ensures that a DHCP flood will not overwhelm the DHCP server. DHCP Snooping is enabled on VLAN 5 and globally activated.
Example 4-8. DHCP Snooping Configuration Example
Switch(config)# interface Fastethernet0/1 Switch(config-if)# ip dhcp snooping trust Switch(config-if)# ip dhcp snooping limit rate 100 Switch(config-if)# exit Switch(config)# ip dhcp snooping vlan 5 Switch(config)# ip dhcp snooping Switch(config)# ip dhcp snooping information optionUse the show ip dhcp snooping command to display DHCP snooping settings. Use the show ip dhcp snooping binding command to display binding entries corresponding to untrusted ports.
Page 4
IP Source Guard is a security feature that restricts IP traffic on untrusted Layer 2 ports by filtering traffic based on the DHCP snooping binding database or manually configured IP source bindings. This feature helps prevent IP spoofing attacks when a host tries to spoof and use the IP address of another host. Any IP traffic coming into the interface with a source IP address other than that assigned (via DHCP or static configuration) will be filtered out on the untrusted Layer 2 ports.
The IP Source Guard feature is enabled in combination with the DHCP snooping feature on untrusted Layer 2 interfaces. It builds and maintains an IP source binding table that is learned by DHCP snooping or manually configured (static IP source bindings). An entry in the IP source binding table contains the IP address and the associated MAC and VLAN numbers. The IP Source Guard is supported on Layer 2 ports only, including access and trunk ports.
Example 4-9 shows how to enable the IP Source Guard with dynamic source IP and MAC address filtering.
Example 4-9. IP Source Guard Configuration Example 1
Switch(config)#interface GigabitEthernet1/0/1 Switch(config-if)#ip verify source port-securityExample 4-10 shows how to enable the IP Source Guard with a static source IP address and MAC address filtering mapped on VLAN 5.
Example 4-10. IP Source Guard Configuration Example 2
Switch(config)# ip source binding 0011.0011.0011 vlan 5 10.1.1.11 interface GigabitEthernet1/0/2Use the show ip verify source command to display the IP Source Guard configuration and the show ip source binding command to display the IP source bindings on the switch.
8. Dynamic ARP Inspection (DAI) | Next Section Previous Section