Forensics Business, Technology, Internet and network concept. Young businessman working on a virtual screen: Access control

Published on February 5th, 2019 📆 | 2361 Views ⚑

0

Access Control Lists: 6 Key Principles to Keep in Mind

In an industry of constant, rapid change, an old-school security tool remains an effective piece of an overall security. Access Control Lists (ACLs) that specify precise rules for destinations and protocols allowed or forbidden, are the foundation of firewalls. And while firewalls have advanced to use analysis of packet contents and behavior, ACLs have not gone away.

There are a number of reasons why ACLs endure. The first, and most important, is that they work. ACLs are straight-forward, conceptually simple ways to limit traffic to and from known (or suspected) malicious addresses and to clear traffic to and from addresses known to be acceptable. Next, they play well with others. As Twitter user Frank Barton (@fbarton) wrote in response to a question about ACLs, “…much less cpu intensive than stateful and deep-packet. But…like Ogres, and onions…use layers. If you can block traffic at ACL, then pass remaining to “NGFW” [next-generation firewall] the fw [firewall] has less traffic to inspect.”

As with all security measures, though, how an ACL is deployed will have a major impact on its effectiveness. Of course, precisely how the ACL is programmed will vary from manufacturer to manufacturer, and component to component, but there are key considerations that are true regardless of which device is hosting the ACL. Let’s take a look at the principles to keep in mind to make ACLs an effective (and efficient) part of the overall security infrastructure.

Think of the network interface that you’d like to use as the portal for inviting criminal hackers to steal your company IP and your customer PII. Good — that’s the interface that you don’t want to protect with an ACL

In virtually every piece of security or routing gear, ACLs are applied individually on each interface. That makes complete sense, because you don’t want to have the same rules for outward-facing interfaces and those that make up your campus network. But the differences between interfaces are not so great that you want some protected by ACLs and some left bare.

This practice of an ACL on every interface is critical for inbound ACLs — those rules that govern which addresses can send data into your network. Those are the rules that make the biggest, most immediate, difference. With that in mind, though, it’s important to remember that ACLs go both ways.

When most people think about “access” they consider the access that those on the outside have to resources on the inside. But access goes both ways — and in the vast majority of cases, so do ACLs.

Outbound ACLs can be used for two broad purposes. The first is to prevent employees from inadvertently visiting addresses known to harbor malicious payloads. This can help cut down on security events that have to be remediated by personnel post-infection.

The next purpose is to prevent bots and other malware from communicating with their C&C servers. Often, these C&C servers are known and can be blocked through specific ACL rules. In many cases, C&C servers for a particular bot or malware campaign are grouped geographically; if your business does not included customers or partners in the specific region, blocking access to that region can take care of both current and future servers for the campaign.

In just about every case, the engine applying the ACL will start at the top and work its way down the list. Once a rule triggers, that’s it; it’s applied, and the list traversal is at an end. That has some significant implication when it comes to figuring out precisely what an ACL is going to do with a particular data stream.

One of the reasons professionals like ACLs is that they have a lower computational overhead than stateful firewalls — they’re fast. That can be critical when you’re trying to provide security for a very high speed network interface. But the longer a packet stays in the system being checked agains the rules in the ACL, the slower the performance will be.

The key, here, is to put the rules that are most likely to be triggered at the top of the ACL. Work from general to specific while you keep the rules logically grouped as common sense or the rules of the particular security device demand. And always be aware that each packet will be acted on by the first rule that it triggers; if you’re not careful, you can end up passing a packet via one rule when you really want to block it via another. Think about how you want the chain of logic to flow, especially when adding new rules.

In just about every case, the engine applying the ACL will start at the top and work its way down the list. Once a rule triggers, that’s it; it’s applied, and the list traversal is at an end. That has some significant implication when it comes to figuring out precisely what an ACL is going to do with a particular data stream.

One of the reasons professionals like ACLs is that they have a lower computational overhead than stateful firewalls — they’re fast. That can be critical when you’re trying to provide security for a very high speed network interface. But the longer a packet stays in the system being checked agains the rules in the ACL, the slower the performance will be.

▼Advertisement

The key, here, is to put the rules that are most likely to be triggered at the top of the ACL. Work from general to specific while you keep the rules logically grouped as common sense or the rules of the particular security device demand. And always be aware that each packet will be acted on by the first rule that it triggers; if you’re not careful, you can end up passing a packet via one rule when you really want to block it via another. Think about how you want the chain of logic to flow, especially when adding new rules.

Here’s a question for you: Should you create an ACL rule for every known-bad address on every interface? Should you try to think of every possible situation and create a group of rules to deal with potential issues? If an ACL is the only security you’re going to have for your network, then the answer is an unequivocal “yes.” But in reality, the ACL is just one layer in your security onion. And it’s important to keep that in mind.

The argument against creating a rule to deal with every conceivable situation has two parts. Both of them are based on the evils of complexity. The first is simply logical; the more rules created, and the more that a packet must filter through before it is passed by the device, the greater the likelihood that something unintended will happen to the packet. The “law of unintended consequences” applies to ACLs as much as to anything else in the technology universe, and the more complex the environment, the more likely it is that the law will kick in.

The second part of the argument has to do with performance. Remember that one of the virtues of the ACL is that it requires far less in terms of compute and memory resources than stateful or deep packet inspection, and is therefore faster. The bigger your ACL becomes (and many have reached hundreds of thousands of lines in length), the more resources are required and the smaller that performance benefit becomes. Remember, an ACL is part of a security solution; let the rest of the infrastructure pick up some of the heavy lifting.

So here’s something that’s logical and a little odd-sounding to those who haven’t worked with firewalls and ACLs: When setting up inbound rules, be sure to block addresses inside the network. Let’s look at why this is important.

The inbound (or ingress) side of the device with the ACL should only see traffic from outside the network. So if it’s presented with a packet from an internal address, one of two things has happened. The first is that an attacker is spoofing your addresses in an attempt to get around firewall and filter rules. An ACL rule is a simple way to get rid of those attempts.

The second reason is that something has gone wrong in routing. While this is not necessarily a security issue, it can become a network performance issue and may even be a security issue. Either way, the ACL will help make sure that it doesn’t become a problem for users or application delivery.

So what goes into an ACL entry? Most are fairly simple and, while the syntax may vary slightly, most contain the same information.

• ACL name
• Name for the entry
• Statement of permission or denial for the entry
• Network protocol and associated function or ports
• Destination and source targets (anything from a single address to “all”
• Additional flags or identifiers that request additional functions when a match is found. This is often something like adding an entry to the log when the rule is matched.

ACLs can contain dozens of entries or tens of thousands. In some cases, individual ACLs have been alive, in one form or another, since the organization deployed its first network. Build them carefully and maintain them rigorously, and ACLs can remain a productive piece of the security infrastructure for generations of hardware to come.

Loading…

Download WordPress Themes
Free Download WordPress Themes
Free Download WordPress Themes
Download Best WordPress Themes Free Download
udemy course download free

Tagged with:



Leave a Reply


Back to Top ↑