Enhancing Wi-Fi Security with Switch ACLs

Why Do You Need Switch ACLs?

When one thinks of Wi-Fi Security, one is typically considering the 802.11 security protocols, such as the advantage of WPA2 over WPA and WEP, the use of pre-shared keys vs. 802.1x with RADIUS servers, implementing captive portals, etc.   All of these mechanisms are designed to control who has wireless access to your network and, generally, corresponding access to the Internet.

While these protocols are necessary to control access, they are insufficient in protecting user behavior once the devices are associated, especially with regard to inter-user communication.   The security of a Wi-Fi network relies upon the security of the underlying wired network infrastructure.   This is especially important on guest networks, whether in a private home, cafe, retail establishment, hotel, or large corporate facility.   Typically, guest networks are placed on their own VLANs (see previous post on VLANs) with their own subnet (see previous post on IPv4 Subnet Masking) to isolate them from other networks at the facility used for operations data, such as personally identifying information (PII), credit card transactions, health records, and other protected data.

There is generally a further requirement that client devices on a guest network should have access to the Internet but not be able to intercommunicate with each other.   If you are a guest at a hotel using their Wi-Fi, you don't want the hacker staying in another room to access your device over the hotel's Wi-Fi network.   Within an AP, most devices have a feature, per SSID, labeled something like "client isolation" or "station isolation" to prevent users connected to the same AP on the same SSID from communicating with each other. However, most networks consist of multiple access points, and client isolation features generally only work within an AP.   How do you prevent devices connected to one AP from seeing devices connected to a different AP within the same network?!

Take the following picture, which is a simple representation of a typical SMB network.   There are a couple of APs connecting both guests and staff, and a wired security camera which should only be accessed by the owner.  This network could have three VLANs: one for guests, one for staff, and one for security.

While some AP vendors offer a "layer 2 isolation" feature to attempt to block such inter-AP user communication, this feature is not universally available, and such features are not effective in many situations, especially if there are wired clients on the same guest network that also need to be isolated, as shown here.

A better approach is to use the ACL feature available on managed layer 2 switches to control the interaction of clients across all of your subnets.   ACLs act as a firewall for all traffic coming into a switch port, and thus are an extremely versatile and valuable tool, and should be deployed in any environment where such interactions need to be controlled.

Unfortunately, ACLs tend to also be very poorly documented and explained by switch vendors, and it is quite easy to get yourself into trouble and lose access to your switch and to other parts of your network.   This post provides a guide on how to successfully configure ACLs for this type of network environment.

How does an ACL work?

Access control lists (ACLs) are rules implemented on a router (and on firewalls) to identify what traffic is allowed and what traffic is denied. Rules within the ACLs provide rule-based management for the router and control inbound and outbound traffic. ACLs on routers provide basic packet filtering. They can filter packets based on IP addresses, ports, and some protocols, such as ICMP or IPsec, based on the protocol identifiers:

• IP Addresses and Networks:  You can add a rule in the ACL to block access from any single computer based on the IP address. If you want to block traffic from one subnet to another, you can use a rule to block traffic using the subnet IDs. For example, the Sales department may be in the 192.168.1.0/ 24 network and the Accounting department may be in the 192.168.5.0/ 24 network. You can ensure traffic from these two departments stays separate with an ACL on a router.
• Ports: You can filter traffic based on logical ports. For example, if you want to block HTTP traffic, you can create a rule to block traffic on port 80. Note that you can choose to block incoming traffic, outgoing traffic, or both. In other words, it’s possible to allow outgoing HTTP traffic while blocking incoming HTTP traffic. 
• Protocol identifiers: Many protocols are identified by their protocol IDs. For example, ICMP uses a protocol ID of 1 and many DoS attacks use ICMP. You can block all ICMP traffic (and the attacks that use it) by blocking traffic using this protocol ID. Many automated intrusion protection systems (IPSs) dynamically block ICMP traffic in response to attacks. Similarly, you can restrict traffic to only packets encrypted with IPsec ESP using a rule that allows traffic using protocol ID 50, but blocks all other traffic. PPTP uses protocol ID 47. 
• Implicit Deny: Implicit deny is an important concept to understand, especially in the context of ACLs. It indicates that all traffic that isn’t explicitly allowed is implicitly denied. For example, imagine you configure a router to allow Hypertext Transfer Protocol (HTTP) to a web server. The router now has an explicit rule defined to allow this traffic to the server. If you don’t define any other rules, then the implicit deny rule blocks all other traffic. The implicit deny rule is the last rule in an ACL. Some devices automatically apply the implicit deny rule as the last rule. However, some devices require an administrator to place the rule at the end of the ACL manually. Syntax of an implicit deny rule varies on different systems, but it might be something like Deny Any Any, or Deny All All, where Any indicates any type of traffic and All indicates all traffic.

Reference:  Gibson, Darril (2014-09-16). CompTIA Security+: Get Certified Get Ahead: SY0-401 Study Guide (Kindle Locations 5167-5189). YCDA, LLC. Kindle Edition. 
 

How to configure an ACL?

This is best done by example.   Say we have the network in the figure above, and I have defined the following VLANs below.   In addition, I have complex client isolation rules on my security network, which are highlighted.

• Network Equipment:  VLAN 4000 (Mgmt VLAN)
• Subnet:  192.168.4.0/22
• Router:  192.168.4.1
• Client connectivity: All devices wired
• Client isolation rules:  All network devices need to intercommunicate with each other
• Staff Network:  VLAN 8
• Subnet:  192.168.8.0/22
• Router:  192.168.8.1
• Client connectivity: Mixed wired and wireless.  Wireless connections via WPA2-AES (either Personal or Enterprise)
• Client isolation rules:  All network devices need to intercommunicate with each other
• Guest Network:  VLAN 16
• Subnet:  192.168.16.0/21
• Router:  192.168.16.1
• Client connectivity: Mixed wired and wireless.  Wireless connections via open network.
• Client isolation rules:  All network devices must be isolated from each other
•  Security Network:  VLAN 32
• Subnet:  192.168.32.0/23
• Router:  192.168.32.1
• Client connectivity:  Mixed wired and wireless.  Cameras, access controllers, and security servers (e.g. NVR) are wired and have static IP addresses in the 192.168.32.2 - 192.168.32.254 range.   Security personnel connect wirelessly with tablets / laptops with DHCP range of 192.168.33.2 - 192.168.33.254
• Client isolation rules:  All wired devices should communicate with each other.  All wireless clients should be able to access all wired appliances, but not intercommunicate with other wireless clients.

There are other "implicit requirements" for the network, which I will make explicit as follows:

• DHCP must work on all VLANs.   Clients will use a broadcast destination address of 255.255.255.255.  DHCP server(s) are on UDP port 67 and DHCP clients are on UDP port 68.
• Prevent rogue DHCP servers - there is a risk of guests and staff connecting their own consumer-level routers on their LAN ports into the network.
• All client devices on all VLANs must be able to access the Internet.

Here are the steps to be followed:

• Step 1:  Prevent non-authorized private IP address ranges to prevent rogue DHCP servers and misconfigured clients.  We are using addresses 192.168.4.0 - 192.168.11.255, 192.168.16.0 - 192.168.23.255, and 192.168.32.0 - 192.168.33.255.  This means we can block the entire 10.0.0.0/8 and 172.16.0.0/12 blocks immediately.  As for the 192.168.0.0/16 block, we will need to block this in sections.  Most especially, we want to block all typical consumer router subnets, which include 192.168.0.0/24, 192.168.1.0/24, and 192.168.2.0/24.

• Step 2:  Allow DHCP communication from clients to the DHCP server. 

 

• Step 3:  Allow traffic / to from the router on all VLANs / subnets.  This includes DHCP traffic from the router to the client devices.  Typical consumer routers have addresses like 192.168.0.1, 192.168.1.1, or 192.168.2.1, which are already blocked by rule 30 above.

 

•  Step 4:  Allow inter-communication between all devices on the management VLAN / subnet.

 

• Step 5: Allow inter-communication between all devices on the staff VLAN / subnet.

 

• Step 6: Allow inter-communication between wired and wireless devices with wired devices on the security VLAN / subnet, while blocking wireless-to-wireless client communication.  Remember that we purposely carved up the subnet to identify and separate infrastructure devices (192.168.32.0/24) vs. DHCP clients (192.168.33.0/24), even though they are on the same subnet of 192.168.32.0/23.

• Step 7:  This is the critical rule.  Now that we've defined exceptions, we want to block inter-communication between all users not defined above.  

• Step 8: Because ACLs have an implicit deny, we want to allow all Internet traffic.

Given that ACL rules do take processing power, you want to develop the rules as efficiently as possible.   We defined these four VLANs and all of their rules in 13 steps.  

Some other considerations

Granted that a malicious hacker can set up their own subnet and rogue DHCP server, but they would need detailed knowledge of the IP scheme on your network.   Meanwhile, accidental rogue DHCP servers are blocked, and fairly complex rules for isolation on the security network can be defined.  Furthermore, we allow all traffic from and to a device with a 192.168.x.1 address, so DHCP ranges should be defined on the partial class B subnets to not provide a 192.168.x.1 address in the subnet.

Once rules are defined, they must be applied explicitly to the switch ports.   Switches will allow you to provide different ACLs to different switch ports.  This is not recommended - best practice is to define an efficient set of rules covering all of your subnets, then apply the same rules to all ports.   This is to prevent mistakes and keep the network administrator sane.

This is what application of ACL rules look like in a managed switch web interface.  The figures here are from an EnGenius EWS switch.