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.
