Chapter 10 — Network and communications security: control configuration
Lesson map
Lesson 10 published. Map, example, EX037.
flowchart TD
N0["Learning outcomes"]
N1["10.1 Inbound and internal rules"]
N2["10.2 Why restrict outbound traffic"]
N3["Lab — Egress rules"]
N4["10.3 Reading the result"]
N5["10.4 Applying changes carefully"]
N6["Synthesis"]
N0 --> N1 --> N2 --> N3 --> N4 --> N5 --> N6
N6 --> EX["Worked example"]
EX --> Q["Exercise EX037"]
Logical drawing
flowchart LR
N0["Learning outcomes"]
N1["10.1 Inbound and internal rules"]
N2["10.2 Why restrict outbound traffic"]
N3["Lab — Egress rules"]
N4["10.3 Reading the result"]
N5["10.4 Applying changes carefully"]
N6["Synthesis"]
N0 --> N1 --> N2 --> N3 --> N4 --> N5 --> N6 --> Q["EX037"]
[Learning outcomes]
|
v
[10.1 Inbound and internal rules]
|
v
[10.2 Why restrict outbound traffic]
|
v
[Lab — Egress rules]
|
v
[10.3 Reading the result]
|
v
[10.4 Applying changes carefully]
|
v
[Synthesis]
|
v
[Worked example] --> [Exercise EX037]
Learning outcomes
You will (1) configure firewall rules from needed flows; (2) restrict outbound traffic; (3) review rule order.
10.1 Inbound and internal rules
Amina drafts firewall rules from the needed-flows list, one allow rule per flow, followed by a rule denying everything else, as NIST SP 800-41r1 recommends. Each rule has a comment naming the flow and its owner. Rules are ordered from specific to general, because the firewall applies the first match. She reviews the draft with Rosa, who spots that the branch office printers also need to receive scans from the copier, a flow missing from the list. The list and rules are updated together.
10.2 Why restrict outbound traffic
Many organisations allow all outbound traffic, but restricting it limits what infected devices can do. If staff browsing must go through the web proxy and DNS must use Castleford's resolvers, malware cannot easily contact its own servers directly or use outside resolvers to hide. Servers need even less: only updates and the mail relay. Amina drafts egress rules for the office and server zones and checks synthetic flows against them before anything is applied. Outbound denies also make infections easier to notice, because blocked attempts appear in the logs.
Lab — Egress rules
"""Evaluate synthetic outbound flows against a first-match egress list with default deny (stdlib only)."""
rules = [("office", "proxy", 8080, "allow"), ("office", "dns", 53, "allow"), ("servers", "updates", 443, "allow"),
("servers", "mail-relay", 25, "allow"), ("*", "*", None, "deny")]
flows = [("office", "proxy", 8080), ("office", "internet", 443), ("office", "dns", 53), ("office", "internet", 53),
("servers", "updates", 443), ("servers", "internet", 25), ("servers", "mail-relay", 25), ("guest", "internet", 443)]
def decide(src, dst, port):
for i, (s, d, p, a) in enumerate(rules, 1):
if s in ("*", src) and d in ("*", dst) and p in (None, port): return a, i
for f in flows:
a, i = decide(*f); print(f"{f[0]:8}->{f[1]:11}:{f[2]:<5} {a:5} rule {i}")
print("allowed", sum(decide(*f)[0] == "allow" for f in flows), "of", len(flows))
Run with python3 lab_egress.py. Verified output:
office ->proxy :8080 allow rule 1
office ->internet :443 deny rule 5
office ->dns :53 allow rule 2
office ->internet :53 deny rule 5
servers ->updates :443 allow rule 3
servers ->internet :25 deny rule 5
servers ->mail-relay :25 allow rule 4
guest ->internet :443 deny rule 5
allowed 4 of 8
10.3 Reading the result
Four of eight synthetic flows are allowed: office browsing through the proxy, office DNS to the school's resolvers, server updates and server mail through the relay. Office traffic directly to the internet on port 443 and to outside DNS is denied, as intended. A server sending mail directly to the internet is denied, which is good, because direct mail from servers is a common sign of compromise. The guest flow is denied by this list because guest traffic leaves through a separate internet path that does not reach internal zones.
10.4 Applying changes carefully
Egress restrictions can break things nobody remembered, such as a software update service on staff laptops that ignores the proxy. Amina recommends applying the new rules first in logging-only mode for two weeks, reviewing what would have been blocked, adding genuine needs and then enforcing. During enforcement, the help desk has a quick route to report problems. This approach catches hidden dependencies before they disrupt work, which is why it is common practice for outbound filtering. Each genuine need found is added to the flow list with its owner.
Worked example
Four of eight flows are allowed; direct server mail and direct office DNS are denied; enforcement follows two weeks of logging-only mode.
Synthetic case. Rules and flows are synthetic.
Errors and limits
Enforcing outbound rules without a logging period often breaks unlisted dependencies.
Exercises
- EX037 — Allowed flows. How many synthetic flows are allowed? Rubric: 3 = four of eight, naming them;; 2 = four;; 1 = some;; 0 = none.
- EX038 — Direct server mail. Why deny direct mail from servers to the internet? Rubric: 3 = common sign of compromise; use relay;; 2 = compromise;; 1 = speed;; 0 = none.
- EX039 — Missing copier flow. What flow did Rosa notice was missing? Rubric: 3 = copier scans to branch printers;; 2 = scans;; 1 = vague;; 0 = none.
- EX040 — Logging-only purpose. Why start egress rules in logging-only mode? Rubric: 3 = find hidden dependencies before blocking;; 2 = dependencies;; 1 = testing;; 0 = none.
Synthesis
Default-deny rules for internal and outbound traffic, applied carefully, limit what compromised devices can do.
Continue studying — chapter 10 of 18
← Chapter 09 (draft) · Course chapter index · Chapter 11 (draft) →