A Security+ style PBQ, solved step by step: firewall rules from a scenario

Performance-based questions (PBQs) are the part of Security+ that people worry about most, and firewall rule tables are a classic shape for them. You get a short network description, a list of requirements and an empty rule table. None of it is hard on its own; the marks are lost on direction, scope and order.

Below is an original practice scenario written in that style (it is not taken from the exam), followed by the way I would work through it.

The scenario

A small company has one stateful firewall between these networks:

Network	Range	Hosts that matter
Internet	any
DMZ	172.16.20.0/24	web server 172.16.20.10, mail relay 172.16.20.25
Office LAN	10.0.10.0/24	internal DNS resolver 10.0.10.53
Management	10.0.99.0/28	admin workstations

The firewall reads its rules from the top down and applies the first one that matches. Return traffic for an allowed connection is permitted automatically.

Requirements:

1. Anyone on the internet can reach the company website, over HTTPS only.
2. The mail relay receives mail from the internet and is the only host allowed to send SMTP out.
3. Office users can browse the web. They resolve names through the internal resolver, and only the resolver may send DNS queries to the internet.
4. Admin workstations manage both DMZ servers over SSH.
5. A contractor laptop, 10.0.99.14, has been given an address in the management subnet. It must not reach the DMZ at all.
6. Everything else is blocked.

Task: fill in the rule table. Try it yourself before you read on.

Step 1: turn each requirement into flows

Before writing a single rule, write down who starts each connection, where it goes and on which port:

Req	Source	Destination	Protocol and port
1	any	172.16.20.10	TCP 443
2	any	172.16.20.25	TCP 25
2	172.16.20.25	any	TCP 25
3	10.0.10.0/24	any	TCP 80, 443
3	10.0.10.53	any	UDP 53, TCP 53
4	10.0.99.0/28	172.16.20.10, 172.16.20.25	TCP 22
5	10.0.99.14	172.16.20.0/24	any

Two details are easy to miss here.

Some traffic never touches the firewall. Office PCs asking the resolver for a name stay inside 10.0.10.0/24, so that leg needs no rule. If you find yourself writing one, you are working from the requirement text instead of the network diagram.

DNS is not only UDP. When an answer is too large for UDP, the server marks it as truncated and the resolver retries over TCP. A resolver that is only allowed UDP 53 will fail on some lookups, which is why RFC 7766 makes TCP support a requirement for DNS implementations.

Step 2: make each rule exactly as wide as the requirement

Requirement 1 says HTTPS only, so the web server gets TCP 443 and nothing else. Opening port 80 for a redirect is a sensible choice on a real site, but it is not what was asked, and in a rule-table question an extra port is a wrong answer.

The same goes for SSH: requirement 4 names the management subnet and the two DMZ servers. Allowing SSH from the whole office LAN, or to the whole DMZ range, is broader than the requirement.

Step 3: put exceptions above the rule they carve out of

The contractor laptop sits inside 10.0.99.0/28, which covers 10.0.99.0 to 10.0.99.15. If the SSH allow for the management subnet comes first, the laptop matches it and a deny placed underneath is never reached. With first-match processing, the specific deny has to sit above the general allow.

The catch-all deny goes at the very bottom for the same reason: any rule placed below it can never match.

Step 4: let the stateful firewall handle the replies

You do not need rules for return traffic, such as the web server answering a browser or DNS answers coming back to the resolver. Writing "allow any from 172.16.20.10" to cover replies would also let the web server open new connections to anywhere, which is exactly what requirement 6 rules out.

The answer

#	Action	Source	Destination	Protocol	Port
1	Allow	any	172.16.20.10	TCP	443
2	Allow	any	172.16.20.25	TCP	25
3	Allow	172.16.20.25	any	TCP	25
4	Allow	10.0.10.53	any	UDP	53
5	Allow	10.0.10.53	any	TCP	53
6	Allow	10.0.10.0/24	any	TCP	80, 443
7	Deny	10.0.99.14	172.16.20.0/24	any	any
8	Allow	10.0.99.0/28	172.16.20.10, 172.16.20.25	TCP	22
9	Deny	any	any	any	any

Rules 1 to 6 never contradict each other, so their order among themselves does not change the result. Only rules 7, 8 and 9 depend on where they sit.

The traps this question is built around

• Wrong direction: allowing SMTP into the relay but forgetting that it also needs to send mail out, or the reverse.
• Too broad: "any port" to the web server, or SSH from every internal network.
• Wrong order: the contractor deny below the management allow, or any rule below the final deny.
• Rules for replies on a stateful firewall.
• Rules for traffic that never crosses the firewall.

On the exam the interface and the wording will be different, but these five mistakes carry over to any rule-table question.

If you want more practice of this kind, the Security+ performance-based questions guide on CertSprint covers how PBQs are scored, how to budget your time for them and a four-step method for any simulation, with PBQ-style matching and ordering exercises to try.

Disclosure: I build CertSprint.