Writing Good ACLs

From Digibase Knowledge Base
Revision as of 08:25, 3 January 2014 by Kradorex Xeron (talk | contribs)
(diff) ← Older revision | Latest revision (diff) | Newer revision → (diff)
Jump to: navigation, search

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

There are general rules that apply to all ACL types, no matter what kind.

  1. Backups Maintain backups of your ACLs no matter how small so that if needed, the ACL can be restored from that backup if needed.
  2. 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
  3. Set rules from most broad to least. This will speed up processing as the system will be able to match rules faster.
  4. Merge similar rules into one whenever possible. This will reduce the resources required to process and store the ACL.
  5. 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.
  6. Keep records Keep records of changes of your ACLs, document every manual change and implement mechanisms to log automated changes.
  7. 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.

Advertisment/Malicious Web Blocklists

Often times there is undesirable traffic that traverses through the web via HTTP, often these come in the form of in-your-face advertisements or platforms that track your movements that are embedded in various sites.

  1. 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.
  2. Use Wildcards With domain blocking, it is often preferential to wildcard an entire ad network domain name.
  3. 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.
  4. 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.

Ban Lists

Ban lists are oten in use on IRC networks, forums and many web software platforms

  1. 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.
  2. 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.

Firewalls

Firewalls are either devices or software that filter network-level traffic. ACLs on these solutions provide a platform to filter out specific Internet or other network traffic from doing what it shouldn't.

  1. 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.
  2. Default Drop Set up the firewall to drop all traffic by default first, then set exceptions to this default to accept.
  3. 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.
  4. 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.
  5. 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.
  6. 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.
  7. Whitelist Remote Controls If you operate SSH servers or other remote administration mechanisms, implement whitelists from expected networks or better individual IP adddresses. If you will be administering remotely from a dynamic IP, whitelist the ISP's subnets that you may be using. Do not leave a remote administration solution exposed.
  8. IPv6 firewalls are often seperately configured If you have an IPv6 network on top of v4, ensure your firewall is correctly set up.

Routing ACLs

More advanced routers, such as commercial quality units will have ACLs where basic filtration can be performed to ensure traffic egress or ingress or if routing updates are acceptable.

  1. Use routing ACLs before firewalls Often times routing ACLs are faster in processing and more efficient by huge magnitudes than fully featured firewalls as they are optimised by a routing engine and discard traffic faster.
  2. Ensure you filter your own users/your own traffic Be sure traffic leaving your network is coming from the prescribed IP space you are assigned or operate. Do not simply pass all of your traffic upstream to your provider.
  3. Implement NAT correctly If you must implement NAT, be sure neither your router nor any host behind it is able to transmit any RFC1918 traffic (e.g. 192.168.0.0/16, 172.16.0.0/12 or 10.0.0.0/8) out to the public Internet as nothing will be able to reply back to it (see previous point).
  4. (ISPs) Ensure you filter BGP updates from customers Ensure your customers are filtered so that they cannot accidently or maliciously hijack IP space that does not belong to them.

Blacklists

Blacklists are often the largest of any ACL and typically contain tens of thousands of entries and are often used by multiple parties in deciding wheather to accept a transmission or drop/reject it.

  1. 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
  2. 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.
  3. Use many sources of input A good and effective blacklist does not only retrive its listings from one source.
  4. 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.
  5. 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.
  6. 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.