Enhancing Network Security: A Guide to Access Control Lists (ACL)
Firewalls, such as OPNsense, pfSense, Omada, Ubiquiti, and Sophos, serve as vital components in the realm of network security. They act as the first line of defense, monitoring and controlling incoming and outgoing network traffic based on predetermined security rules.
OPNsense and pfSense are open-source solutions that are highly customizable, offering robust security features for diverse environments. Meanwhile, Omada and Ubiquiti stand out with their user-friendly interface and reliable performance. Sophos delivers a comprehensive security suite that is well-suited for complex networks.
Each of these firewalls brings unique strengths to the table, catering to a variety of needs and network sizes. While choosing the right one depends on specific requirements, all of these options offer a solid foundation for network security.
Access Control List (ACL)
Access Control Lists are crucial to managing network security. They define who gets to access what information and when; acting as gatekeepers of our digital assets.
Many businesses today have a robust security architecture that includes advanced threat detection systems, encryption protocols, and intrusion prevention systems. These sophisticated measures have become a standard in professional settings to protect valuable digital assets.
Understanding Access Control Lists
The concept of ACLs is straightforward: to control access to resources within a network. There are different types of ACLs, each with unique characteristics suited for different networking scenarios. The utilization of ACLs offers numerous advantages, such as improved network security and efficient data control, making them an essential tool in network management.
Situations requiring an ACL
ACLs come into play in several scenarios - from securing sensitive data to ensuring proper data routing. For instance, they can be implemented to confine access to confidential corporate data or protect a network from potential threats, block a network's internet access, or stop devices within a network from communicating with each other. So, understanding when to use ACLs is as important as understanding what they are.
Comparing ACL approaches
Deny all
When implementing Access Control Lists (ACLs), a "deny all" approach is commonly used, where all traffic is denied by default, and specific rules are created to allow desired traffic. However, there are alternative approaches to ACL implementation that can be employed based on specific requirements.
Whitelist
Instead of denying all traffic by default, a whitelist approach explicitly allows only pre-approved traffic while denying everything else. This approach can be useful when the network environment is well-defined and limited to specific applications or services. It provides a higher level of control and reduces the risk of unauthorized access.
Blacklist
In contrast to the whitelist approach, a blacklist approach allows all traffic by default and creates rules to block specific traffic that is known to be malicious or undesirable. Blacklists can include IP addresses, domains, specific protocols, or known attack patterns. While this approach can be effective in blocking known threats, it may not protect against emerging or unknown threats.
Role-Based Access Control
RBAC is a method that assigns permissions and access rights based on the roles and responsibilities of users or entities within a network. Instead of defining rules based on specific traffic attributes, ACLs are defined based on the roles of users or groups. RBAC provides a more dynamic and flexible approach to access control, allowing for easier management of user permissions.
Time-Based ACLs
Time-based ACLs allow or restrict network traffic based on predefined time ranges. For example, you may configure ACL rules to allow specific types of traffic during office hours and block them outside those hours. This approach can be useful for enforcing network usage policies based on time requirements or limiting access during specific periods.
Protocol-Based ACLs
Rather than filtering traffic based on source and destination IP addresses or ports, protocol-based ACLs focus on the type of protocol being used. This approach allows fine-grained control over different protocols, enabling or blocking specific protocols based on the network's security and operational needs.
While the aforementioned ACL types offer a range of choices for network traffic control, it's important to note that not all firewalls provide the same level of configuration. The type of firewall in use can limit the options available for implementing these ACLs. Basic firewalls often offer only simple blacklist or whitelist functionality, and might not support more advanced features like RBAC, time-based rules, or protocol-based filtering. Furthermore, the ability to define complex rules such as time-based or role-based controls often requires advanced firewalls or additional security appliances.
While these access control strategies offer potential enhancements to network security, the feasibility of their implementation depends heavily on the sophistication of the firewall or security system in place.
Implementing ACL on Omada
We are now going to illustrate the practical application of Access Control Lists (ACLs) by implementing them in an Omada environment. This is not intended as a technical guide or promotional material, but only a demonstration to provide a tangible understanding of how ACL operates and enhances network security in real-world scenarios.
Setting up diverse networks for distinct functions is central to optimizing operational efficiency and security. This approach allows for the segregation of network traffic based on functionality, purpose, or sensitivity, mitigating the spread of security threats and reducing the impact of a single point of failure. For instance, a business might establish separate networks for guest access, internal operations, and sensitive data handling. This network segregation facilitates robust control over access permissions, prioritizing network resources, and enhancing overall system resilience.
For this example, we will consider the following networks
- IoT Network: This network type is predominantly used for connecting and managing Internet of Things (IoT) devices. These could range from smart home appliances to industrial sensors, all contributing to a connected and automated ecosystem.
- IoT Unsecure Network: As the name suggests, this network type poses potential security risks, often due to less secure IoT devices. Such networks require stringent security measures to protect against cyber threats.
- IP Camera Network: This network type is dedicated to security and surveillance cameras. It allows for centralized control and monitoring, contributing to enhanced security.
- Home Network: Home networks are typically private networks set up in residential premises. They connect personal devices like computers, smartphones, printers, and entertainment systems.
- Admin Network: This network type is specifically designed for administrative tasks. It offers higher privileges and controls necessary for network management and configuration.
- Guest Network: Ideal for visitors or temporary users. Guest networks provide internet access while isolating the guests from the primary network, thereby safeguarding sensitive information and systems.
We will be using a deny-all approach, which basically means no network traffic can go anywhere. We will then take each network and define where each network is allowed to go.
Switch ACL
All of these rules will be made on switch ACL. You can repeat the same steps for Access-Point ACL for granular control over what's available on the wireless networks.
Safety-net rule
This rule allows traffic from the Admin interface LAN to LAN. Before we do anything else, this step makes sure that we still have access to our admin resources on the admin network. The next rule denies traffic to all networks, so start with this one first.
Deny-all rule
This is done in two parts. The first step is to create a profile that takes all valid IP ranges for your networks
We then use this profile to deny traffic from all IPs to all IPs. This is our deny-all rule.
It says to deny all traffic to all network IPs.
Allow interVLAN rule
Next, we want to allow IPs within a single VLAN to communicate with one another. We will repeat the same process for each of our VLANs.
This completes the basic setup for segregating network traffic by VLAN.
In simpler words, we have set up our network to allow devices on Home, IoT, Admin, and Guest to only be able to communicate to devices on the same network.
Going a step further, you can go a step further and apply the following rules
Disallow inter-VLAN communication but allow access to the internet
This rule stops devices on the same network from communicating with each other but still allows access to the internet
For this, you will first create an IP Profile that specifically points to the gateway.
Next, you will delete the rule that allows VLAN-VLAN and create a new rule that only allows traffic from Gateway-IP-Group to VLAN and make sure bidirectional is turned on.
Now, all devices on IoT Network can communicate to the IoT gateway and access the internet, but the devices can't communicate with each other.
Allow access to specific ports only
In this example, we want to allow the Admin network to access port 22 (ssh) for the Camera Network. This is important if you want to access resources securely over ssh while also keeping other types of traffic segregated.
We will first create an IP-Port Profile for devices on our IOT network.
Next, we will create a bidirectional rule to allow traffic from either specific IPs on the Admin network or the complete Admin network to the IOT SSH IP-Port Group
You can do the same thing to only allow traffic on port 80 (HTTP), port 443 (HTTPS), and port 22 (ssh)
Gateway ACL
Similarly, you can create rules to block devices from communicating to the internet on a VLAN level while still allowing local network access. A use-case for this scenario is an NVR system, where you do not want to allow your IP Cameras access to the internet while still allowing local network access.