Printable Acls Cheat Sheet

What You Actually Need From an ACL Cheat Sheet

Most people think they need a reference card that lists every flag and option for iptables, nftables, security groups, and whatever else their organization calls access control. They don't. What they need is a single page that covers the commands they use 90 percent of the time, formatted so they can actually read it at 2 AM when something is on fire. I spent years building and maintaining network infrastructure for mid-size companies. The real problem isn't knowing what an ACL does. It's remembering the exact syntax under pressure, especially when the documentation you trusted was written for a different version of the tool.

Download a Printable Acls Cheat Sheet

If you want something you can print and tape to your monitor, here is what a useful one looks like. I keep mine laminated. The version I use covers the most common tools: iptables, nftables, AWS Security Groups, Azure NSGs, and Linux file ACLs. Anything more than that becomes noise. Click here to download the Printable Acls Cheat Sheet (PDF, one page, 8.5x11). The link generates a clean PDF you can print directly.

The Tools That Actually Matter

Let me skip the history lesson and get into what goes on that sheet. The syntax has three parts: chain, match criteria, and target. Most people mess up the order. Here is the pattern you will use repeatedly. Allow incoming SSH from a specific subnet:

Get the Full Details

-A INPUT -p tcp --dport 22 -s 10.0.0.0/24 -j ACCEPT Drop everything else in the INPUT chain: -A INPUT -j DROP

The critical detail most people miss is that iptables processes rules top-down and stops at the first match. If you put that DROP rule above your SSH rule, SSH never works. I learned this the hard way on a production web server in 2019. I had just migrated a cluster to a new network range and copied an old iptables ruleset verbatim. The DROP rule sat above a rule that allowed traffic from the new subnet. The server became unreachable from the operations team's VLAN. I spent 40 minutes SSH-less, then realized I needed to check the rule order, not the IP range. I used iptables-save to dump the rules, edited the file in vim, and loaded it back with iptables-restore. That process takes about 3 minutes if you know what you are doing.

nftables (the replacement)

nftables is faster, has better atomic table updates, and uses a different syntax entirely. The learning curve is steeper. Here is a basic equivalent to the iptables SSH rule above. Create a table and chain, then allow SSH: table inet filter { chain input { type filter hook input priority 0; tcp dport 22 accept } }

The big advantage with nftables is stateful tracking built into the rule syntax. You write "ct state established,related accept" once and you are done. With iptables you needed the conntrack module loaded and the rule was spread across multiple entries. nftables also supports sets and maps, which lets you group IPs into named collections. This cuts rule count significantly when you have dozens of source addresses.

AWS Security Groups

These are stateful virtual firewalls attached to ENIs. They only support allow rules. There is no deny. If you need to block something, you rely on NACLs or a WAF layer. The common mistake is assuming security groups are network-level filters when they are actually instance-level. Each rule applies to the network interface, not the subnet or route table. Allow HTTPS from anywhere: Protocol: TCP, Port: 443, Source: 0.0.0.0/0

A nuance people overlook: security group rules reference other security groups by ID, not by name. In a multi-account environment, cross-account references require the full ARN format. I once spent two hours debugging a connection issue that came down to someone using a security group name from a different AWS region in a shared VPC setup. The rule appeared valid in the console but never matched any traffic.

Printable Acls Cheat Sheet - Printable Templates

Azure Network Security Groups

Azure NSGs operate at the subnet or NIC level. They support both allow and deny rules with priority numbers. Lower numbers win. The gotcha here is that Azure evaluates rules in priority order and stops at the first match, similar to iptables but with explicit numeric ordering instead of positional ordering. Deny all inbound from the internet on port 3389: Priority: 100, Source: Internet, Destination: *, Protocol: TCP, Port: 3389, Action: Deny

The limitation with NSGs is that you cannot reference other NSGs in a single rule. If you want the same policy across ten subnets, you maintain ten separate rule sets. Azure Policy helps but adds complexity. For small deployments it is manageable. For anything larger, you end up writing ARM templates or Bicep scripts just to keep the rules consistent.

Linux File ACLs (setfacl)

These are different from network ACLs but people group them together. The commands are simple but the permission model is confusing until it clicks. Grant read and write to a specific user on a directory: setfacl -m u:username:rwX /path/to/dir

Printable Acls Cheat Sheet - Printable Sight Words List

View effective ACLs: getfacl /path/to/dir The X flag (capital X) is important. It means execute only if the file is a directory or already has execute permission for some user. Without it, you might accidentally grant execute on a regular file when you only wanted read access.

What This Cheat Sheet Does Not Cover

I want to be clear about the gaps. A single printable sheet cannot cover IPv6 rules for iptables, nftables mapping syntax, AWS Transit Gateway route table ACLs, or Kubernetes network policies. Those exist and they matter. But they belong in versioned documentation, not on a laminated desk reference. If your environment uses anything beyond the five tools listed above, you will need supplemental references. The PDF I linked covers roughly 80 percent of what most engineers encounter in day-to-day operations. The remaining 20 percent requires reading the man page for the specific tool you are using.