What improvements do access control list?

Access-list (ACL) is a set of rules defined for controlling network traffic and reducing network attacks. ACLs are used to filter traffic based on the set of rules defined for the incoming or outgoing of the network. 

ACL features – 

1. The set of rules defined are matched serial wise i.e matching starts with the first line, then 2nd, then 3rd, and so on.
2. The packets are matched only until it matches the rule. Once a rule is matched then no further comparison takes place and that rule will be performed.
3. There is an implicit denial at the end of every ACL, i.e., if no condition or rule matches then the packet will be discarded. 
    

Once the access-list is built, then it should be applied to inbound or outbound of the interface: 
 

• Inbound access lists – When an access list is applied on inbound packets of the interface then first the packets will be processed according to the access list and then routed to the outbound interface. 
• Outbound access lists – When an access list is applied on outbound packets of the interface then first the packet will be routed and then processed at the outbound interface. 

Types of ACL – 
There are two main different types of Access-list namely: 

1. Standard Access-list – These are the Access-list that are made using the source IP address only. These ACLs permit or deny the entire protocol suite. They don’t distinguish between the IP traffic such as TCP, UDP, HTTPS, etc. By using numbers 1-99 or 1300-1999, the router will understand it as a standard ACL and the specified address as the source IP address. 
2. Extended Access-list – 
   These are the ACL that uses source IP, Destination IP, source port, and Destination port. These types of ACL, we can also mention which IP traffic should be allowed or denied. These use range 100-199 and 2000-2699.

Also, there are two categories of access-list:  

1. Numbered access-list – These are the access list that cannot be deleted specifically once created i.e if we want to remove any rule from an Access-list then this is not permitted in the case of the numbered access list. If we try to delete a rule from the access list then the whole access list will be deleted. The numbered access-list can be used with both standard and extended access lists. 
    
2. Named access list – In this type of access list, a name is assigned to identify an access list. It is allowed to delete a named access list, unlike numbered access list. Like numbered access lists, these can be used with both standards and extended access lists. 
    

Rules for ACL – 

1. The standard Access-list is generally applied close to the destination (but not always).
2. The extended Access-list is generally applied close to the source (but not always).
3. We can assign only one ACL per interface per protocol per direction, i.e., only one inbound and outbound ACL is permitted per interface.
4. We can’t remove a rule from an Access-list if we are using numbered Access-list. If we try to remove a rule then the whole ACL will be removed. If we are using named access lists then we can delete a specific rule.
5. Every new rule which is added to the access list will be placed at the bottom of the access list therefore before implementing the access lists, analyses the whole scenario carefully.
6. As there is an implicit deny at the end of every access list, we should have at least a permit statement in our Access-list otherwise all traffic will be denied.
7. Standard access lists and extended access lists cannot have the same name. 
    

Advantages of ACL – 

• Improve network performance.
• Provides security as the administrator can configure the access list according to the needs and deny the unwanted packets from entering the network.
• Provides control over the traffic as it can permit or deny according to the need of the network.

Article Tags :

A security configuration issue we witness regularly is misconfigured network Access Control Lists (ACL). ACLs help us to adhere to the “least privilege” element of the zero-trust security model by filtering (allowing or denying) network traffic.

ACLs achieve this by only allowing the permitted network traffic through the device and blocking all remaining traffic. This sounds simple in theory but takes careful planning to make this work effectively. For example, it is common to see a well implemented ACL on the inbound (untrust to trust) direction of a perimeter firewall. However, outbound (trust to untrust) is often left completely open.

The error in the above example is the implicit trust of the internal network. This is a common mistake that often leads to attacks that could easily have been prevented with a correctly configured ACL. Remember, in this scenario, zero-trust means explicitly verifying the traffic requirements, and implementing using the least privilege.

Many attacks rely on communication to a Command and Control (C&C/C2) endpoint or server to work correctly. This connection is usually established from a compromised device on the trusted/inside network to a threat actor on the untrust/outside network. Implementing a strong ACL will prevent this in most cases. In a similar manner, a threat actor performing a Cryptojacking attack will need solved data blocks added to the blockchain to get their reward. Without that outbound communication they will not be able to get this data block.

The threat from within

It is also a mistake to assume your employees and colleagues should be trusted; Insider Risk is a very real problem. What is to say your colleagues are not using peer-to-peer networking for illegal downloads on your corporate device? Or maybe they have inadvertently compromised their device, turning it into an open mail relay or mass-mailer? In these examples you may find your organisation on a blacklist quickly or your reputation impacted.

Once a solid ACL is created it should be implemented on as many devices in the traffic flow as possible. This means security controls such as the Windows Firewall, switches, Azure NSGs as well as the perimeter firewalls. This approach, whilst more difficult to administer and maintain, provides multiple layers of protection in case one control fails (the assume breach element of zero-trust).

Document everything

Before starting, think to yourself, “if I were to block all traffic to and from this device, what would I need to allow, and to what, in order for it to serve its role?”. This is why it’s important to accurately document the traffic flows.

This can be done by taking stock of your assets and determining what traffic is required in both directions. For example, only the DNS servers should be able to perform recursive queries, and only to your external name servers or using root hints.

A simple spreadsheet can be used to document the flows. I would recommend the following at a minimum for the column headings:

• Resource \ Source (example: Server01 \ 192.168.1.100)
• Application (example: DNS)
• Protocol (example: UDP)
• Port (example: 53)
• Traffic Direction (example: in \ out \ both)
• Target (example: ISP’s name servers \ 8.8.8.8)

Ideally the traffic flow documentation should be overlayed onto a network diagram to create a flow diagram. Being able to see this graphical representation often allows us to spot mistakes or issues with the proposed ACL.

Implementing a useful ACL

My advice for implementing your Access Control List would be as follows:

• Most devices apply Access Control Lists in a top-down manner starting with the most strict/specific settings. Therefore, it is advised to move the most complexed ACLs to the top of the list. For example, [Server02, SMTP, TCP 25, Outbound, to Mimecast] should sit above [All end user devices, Secure web, TCP 443, Outbound to Any].
• All ACLs should be completed with an explicit deny any rule at the end/bottom. Most firewalls for example will implement this anyway, but it should be defined to complete the ACL.
• Before applying the defined ACL backup your device and complete the change control to include a rollback plan.
• Once the ACL is created it should be implemented as close to the source of the traffic origin as possible to start with. Note: It is highly recommended that this is implemented in an AUDIT ONLY mode to start with. This way, any mistakes will not cause legitimate traffic to be denied. It allows you to review the traffic hits to determine if alterations to the ACL are required.
• Move the newly implemented ACLs to the top of the ACL list.
• If your device supports it, reset the traffic hit counters. Once the new ACL is applied you should see its hit counter increment, along with the explicit deny any rule. If the ACL has been implemented correctly, the only hits on the old/existing rules should be unwanted traffic.
• Once you are happy with the ACL you can move from audit mode to enforce. The old/existing rules can then be deleted, and another backup of the device taken.
• Leave this ACL in place for a period for monitoring. Providing all has worked correctly, you can then move on to apply this ACL to the next device in the traffic flow. Whilst it is recommended to implement the ACL as close to the traffic source as possible, the most impactful device in terms of your improved security posture is likely to be your perimeter firewall(s). Aiming to secure these device(s) should be a priority.

As a side note, I would also recommend that for firewalls and routers you move from 1-to-1 NAT (Network Address Translation) to PAT (Port Address Translation) where possible. These PAT translations should match your ACL. This is a belt and braces approach, meaning that if a mistake is made with the inbound ACL, the traffic should be dropped as it is not translated. The issue with 1-to-1 NAT is that if the ACL is misconfigured you can potentially expose more than you wanted to, which could be exploited.

The above zero-trust/least privilege approach to network ACLs can also be used for other ACLs such as Discretionary Access Control Lists (DACL) and System Access Control Lists (SACL) as well as Role-Based Access Control.

Next steps

Hopefully, this blog has shown how locking down your ACLs can mitigate many common attacks by limiting the exposure and therefore reducing the attack surface.

If you would like further advice relating to implementing your ACLs or would like to engage with an expert from Transparity’s security team, just click below to request a complimentary consultation.