Writing Good ACLs
Revision as of 06:58, 3 January 2014 by Kradorex Xeron (talk | contribs)
ACLs (Access Control Lists) which often come in the form of firewalls, route filters, ban lists, blacklists, and so forth are an important part of ensuring a system is secure and able to be legitimately used. This article is a list of things to do to ensure an ACL is well designed:
General
- Backups Maintain backups of your ACLs no matter how small so that if needed, the ACL can be restored from that backup if needed.
- Set rules with the expectation that the system will go down the list until one matches. Often times computers will process a list sequentially and branch off onto sublists recursively, designing your list with this in mind can ensure all desired rules are utilized
- Set rules from most broad to least. This will speed up processing as the system will be able to match rules faster.
- Merge similar rules into one whenever possible. This will reduce the resources required to process and store the ACL.
- Know your rules. Routinely check over your ACLs, try to observe trends in your ACLs if they are dynamically updated. Render summaries with tools if the ACL is too large.
- Keep records Keep records of changes of your ACLs, document every manual change and implement mechanisms to log automated changes.
- Set up independent ACLs On each element (be it a router, firewall appliance, server/workstation, service, application), ensure there are ACLs suited for each element as say, a routing ACL cannot adequately ensure that users may be authorised to access a service.
Firewalls
- Drop, don't deny or reject Often times people will believe that setting up a firewall to reject a connection is more effective than dropping, this isn't the case and still elicits a response. Firewalls should create silence in response to undesiragble traffic.
- Default Drop Set up the firewall to drop all traffic by default first, then set exceptions to this default to accept.
- Test Rule Types If you are implementing a different kind of rule, ensure it operates correctly and in the manner you expect, don't implement one without testing.
- Know your traffic Routinely check what kinds of traffic traverse through the firewall, understand how that traffic flows and its purpose, if something looks out of place, adjust your firewall ACLs to deal with it.
- Don't log dropped traffic This may seem counter-intuitive, but don't log dropped traffic as it is a vector for an attacker to use to cause your system to run out of storage resources.
- Don't use DMZ If your firewall offers a DMZ option, don't use it, instead learn how to correctly set up rules that correctly permit the traffic. If the firewall doesn't permit this, investigate another solution.
Advertisment/Malicious Web Blocklists
- Block names, not IPs Often times ad networks may be diversely dispersed through CDNs (Content Delivery Networks), so it is often beneficial to block the domain name involved in the advertisements.
- Use Wildcards With domain blocking, it is often preferential to wildcard an entire ad network domain name.
- Don't only rely on developer-maintained blocklists Often times blocklists maintained by plugin/filter developers over time can be softened up due to pressures from the blocked parties if the solution garners enough populairty.
- Ensure that your specific blocklist covers what you need it to Your blocklist will help you conserve resources on your network and computer, ensure that you can get the most out of it in this process by periodically checking what content is still being downloaded by the browser.
Blacklists
- Be Responsive If someone is incquiring about a status of their listing, be responsive to them and let them know what they can do to resolve, you don't nessasarily have to de-list them
- Don't expect monetary payment If someone wants to be de-listed, don't expect money for that de-listing, their cooperation in cleaning up their system or network should be payment enough and those who are grossly abusive (spammers in particular) tend to have enough money to pay for repeated de-listings.
- Use many sources of input A good and effective blacklist does not only retrive its listings from one source.
- Know your data This may seem like a duplication of a "General" section entry, it is a must to render reports, and have information that's easily retrivable about your blacklist either as a whole or subsets thereof, otherwise your blacklist will become unmaintainable.
- Automate If you are dealing with a large data set, don't try to manually maintain the database as that opens the blacklist (which others may be relying on) to damage. Instead, use tools (can be scripts) that check your inputs for errors.
- Index your database If your blacklist exceeds 1000 entries, have an indexable database that can be indexed by a unique column (say IP or network address or the like), that way you can ensure it is quick to respond to requests.
Ban Lists
- Minimize Entries for a single target If you can, discover one or more common elements among the target of the ban and attempt to ban them, don't repeatedly say, ban a dynamic IP that's demonstrated to be changed repeatedly.
- Remove outdated entries If your operation is sufficiently old, it may be prudent to over time remove older entries that are no longer relevant to keep your ban list processing quickly.