AP Cybersecurity Firewall and ACL Configuration Guide

Firewalls show up across Unit 3 (Securing Networks) and Unit 4 (Securing Devices), and they are almost guaranteed to appear in the free-response Device Security Analysis. This guide helps you read an access control list (ACL), figure out exactly which packets get allowed or denied, and write or modify rules that meet a scenario's specifications.

The goal is not to memorize firewall definitions. The goal is to trace a packet through a rule set and explain the effect of a configuration on traffic and users, which is exactly what the exam asks you to do.

Where this shows up on the exam

In the multiple-choice section, you will see scenario-driven items built on technical artifacts, and firewall ACLs are specifically listed as one of those artifact types. Expect questions that hand you a short rule table and ask which traffic passes.

The free-response question, Device Security Analysis, can supply device firewall settings alongside logs and policies. That question assesses Skill Categories 2 (Mitigate Risk) and 3 (Detect Attacks), so you may need to evaluate a firewall control, describe how a rule change affects users, or write a corrected rule.

The relevant learning objectives are 3.4.B (explain how a firewall uses an ACL to allow or deny traffic), 3.4.D (configure a firewall to manage traffic flow), and 4.3.D (configure a host-based firewall). Keep your reasoning defensive: you are protecting assets, not attacking them.

How a firewall reads an ACL

An ACL is an ordered list of rules. The firewall checks a packet against each rule from top to bottom and stops at the first match. This is the single most important idea, because the same rules in a different order can produce opposite results.

Each rule typically specifies these fields:

Port numbers map to services, so know the common ones: 443 for HTTPS, 80 for HTTP, 22 for SSH, 53 for DNS, and 3306 for MySQL. A scenario that says "patients book appointments over a secure web connection" is pointing you at TCP 443.

Default deny

Most ACLs end with an implicit or explicit default deny rule. That means any packet not matched by an earlier allow rule is dropped. This is the safe baseline: you open only what you need and block everything else.

When you read a rule set, always ask what happens to traffic that matches no allow rule. If the answer is "it gets denied," the firewall is following default deny. If a broad allow sits at the bottom, the firewall is effectively permitting unexpected traffic, which is a finding worth flagging.

Worked mini-example

Consider Scenario 3A, where Firewall A protects a public web server at 10.0.1.10. You need external clients to reach the web app securely while blocking other traffic. Here is a clean rule set:

</>Code
1  allow  tcp   any            10.0.1.10   443   inbound
2  deny   tcp   any            10.0.1.10   80    inbound
3  deny   tcp   any            10.0.1.10   22    inbound
4  deny   ip    any            any               inbound   (default deny)

Trace a packet from an external user to 10.0.1.10 on port 443. It matches rule 1 and is allowed. Good, that is the patient booking traffic.

Now trace a packet to 10.0.1.10 on port 22 (an SSH attempt from the internet). It does not match rule 1, matches rule 3, and is denied. Remote administrative access from the outside is blocked, which is what you want for a public server.

For Firewall B, the requirement is that only internal employees reach patient records on the file server at 10.0.2.20. The matching key is the source IP, restricting access to the internal subnet:

</>Code
1  allow  tcp   10.0.2.0/24    10.0.2.20   445   inbound
2  deny   ip    any            10.0.2.20         inbound

A packet from an internal host in 10.0.2.0/24 to the file server matches rule 1 and passes. A packet from an external address fails rule 1, hits rule 2, and is denied. The control enforces the "internal only" specification through the source IP field.

A workflow for ACL questions

Use this order every time you face a rule set, whether on multiple choice or the FRQ.

1. Identify the packet in the question: its source IP, destination IP, protocol, and destination port.
2. Read rules top to bottom and stop at the first match.
3. Apply that rule's action. If no rule matches, apply the default deny.
4. Translate the result into plain language tied to the scenario, such as "the external user can reach the web app but cannot SSH into it."

When you are asked to write or modify a rule, name the exact fields. State the action, protocol, source, destination, port, and direction so there is no ambiguity. If the scenario wants secure web access only, write an allow for TCP 443 and rely on default deny for everything else rather than adding a broad allow.

Evaluating a control, not just reading it

The exam often wants you to evaluate impact, which goes beyond "allowed or denied." Describe the tradeoff for both security and users.

For example, blocking inbound 22 on a public server reduces the attack surface for brute-force SSH login attempts, which protects the asset. The cost is that administrators must connect through the internal network or a controlled path instead of straight from the internet. Naming both sides shows you understand the control's effect.

When a log file accompanies the firewall, connect them. If /var/log/auth.log shows repeated failed logins from an external IP and the ACL still allows that traffic, recommend a deny rule for that source or that port and explain that it would cut off the observed attempts.

Common mistakes to avoid

Ignoring rule order is the most frequent error. A specific deny placed below a broad allow never fires, so the broad allow wins. Always check whether an earlier rule already matched.

Confusing source and destination flips the entire meaning of a rule. The source is where the packet starts; the destination is the server or host it is trying to reach. Restricting by source controls who can connect; restricting by destination controls what can be reached.

Forgetting default deny leads students to assume traffic is allowed when it actually drops. If a packet matches no allow rule, it is denied. Conversely, do not assume everything is blocked if a wide-open allow sits at the bottom.

Writing vague rules costs FRQ points. "Block bad traffic" is not a configuration. Specify the action, protocol, addresses, and port. Use the right port for the service named in the scenario, and match the direction (inbound versus outbound) to the traffic described.

Finally, do not overcorrect by denying needed traffic. If you block 443 on a web server to "be safe," patients can no longer book appointments. Tie every rule back to the specification so you allow what the scenario requires and deny the rest.