Modifying firewalls, IDS/IPS and the filtering layers

Objective 4.5 in this course covers enterprise security capabilities — CompTIA's scope note for it modifies firewalls, IDS/IPS, DNS filtering, DLP, NAC and EDR/XDR. This lesson takes firewalls, IDS/IPS and the filtering layers; DLP, NAC, EDR/XDR and email security are the next lesson.

Why this matters

Domain 3 asked where these devices go. This objective asks what you do to them — the verb in CompTIA's scope note is "modifying", and the questions are operational: a requirement arrives, what rule or setting changes?

Rule administration is also where organisations accumulate risk quietly. A firewall rule base that has grown for eight years contains rules for systems that no longer exist, opened for projects that finished, with no owner and no expiry. That is attack surface nobody is looking at.

The lesson

Rules, access lists, ports and protocols, and screened subnets

A firewall rule matches traffic and decides what happens to it. The parts: source, destination, service (port and protocol), action, and — on modern devices — application, user identity, and schedule.

Three principles the exam tests:

• Default deny. The rule base ends with "deny everything else", and traffic is permitted explicitly. A default-allow firewall with a list of blocked things is the wrong architecture, for the same reason a deny list loses to an allow list in Domain 2.
• Order matters. Rules are evaluated top to bottom and the first match wins, so a broad permit above a specific deny silently defeats the deny. "The rule is there but not working" is usually rule order.
• Specificity. Permit the narrowest thing that meets the requirement — this source, to this destination, on this port — rather than a whole subnet to a whole subnet on any port.

Outbound rules are the ones most often neglected and most often the answer. Organisations filter inbound carefully and permit outbound freely, which is exactly what C2 and exfiltration need. Restricting outbound traffic to what is required — and forcing web traffic through a proxy so direct connections become anomalies — is a high-value change.

Rule hygiene is part of the objective: every rule has an owner and a reason, rules are reviewed periodically, temporary rules carry an expiry, and unused rules are removed. A rule permitting access for a decommissioned system is the same finding as the decommissioned asset in 4.2.

Screened subnets were covered in Domain 3; what belongs here is the rule pattern that implements them. Internet may reach the screened subnet on specific services; the screened subnet may not freely initiate connections into the internal network — and where it must, the rule is narrow, specific, and preferably initiated the other way.

IDS versus IPS, trends, signatures, and where each belongs

Both look for malicious activity. The differences that matter operationally:

• IDS detects and alerts. It can sit on a tap, so it cannot break the network and cannot block.
• IPS detects and blocks. It must be inline, so it can break the network, and a false positive is an outage rather than a wasted alert.

That asymmetry drives how they are run. An IPS rule set is typically deployed in detection mode first, watched for false positives, and only then switched to blocking — for the rules that proved clean. Turning on every signature in blocking mode on day one is how an IPS ends up disabled by an angry operations team.

The detection methods:

• Signature-based — matches known patterns. Precise, low false positive rate, and blind to anything new. Requires constant signature updates.
• Anomaly-based / behavioural — compares against a baseline of normal. Can catch novel activity, produces more false positives, and needs a baselining period.
• Heuristic — rules about suspicious characteristics rather than exact matches.
• Trend-based — CompTIA's term for watching change over time rather than single events: a gradual rise in outbound volume, a slowly growing number of authentication failures.

The exam's discriminator: signature catches the known; anomaly catches the unknown and costs false positives. If the scenario says zero-day or previously unseen, the answer is behavioural or anomaly-based.

Placement, from Domain 3: an IPS inline at a boundary, a sensor inside the perimeter showing what got through, and — the gap people forget — neither sees east-west traffic within a segment.

Web filtering: agent-based, centralised proxy, URL scanning, content categorisation

Web filtering controls which sites users may reach, and CompTIA names the delivery models because they suit different estates.

• Centralised proxy — all web traffic goes through a proxy that enforces policy. Full control and logging; only works for traffic that reaches it, which means office users or full-tunnel VPN users.
• Agent-based — software on the endpoint enforces policy wherever the device is. This is what covers remote and split-tunnelled laptops, which is the common case now.
• Cloud gateway — the SASE model from Domain 3: traffic goes to a cloud service that enforces policy, regardless of user location.

The techniques:

• URL scanning — checking the specific address, not just the domain.
• Content categorisation — classifying sites into categories (gambling, malware, adult, newly registered) so policy is written against categories rather than individual sites.
• Reputation — scoring a destination on observed behaviour and age. Newly registered domains are one of the highest-value categories to block or restrict, because phishing and C2 infrastructure is typically days old.
• Block rules — explicit deny for named destinations.

The recurring limitation: most traffic is HTTPS, so a filter sees the domain (via SNI or DNS) and not the path or content unless it terminates TLS. TLS inspection gives full visibility and costs performance, certificate management on every endpoint, and privacy considerations — plus some traffic (banking, health, certificate-pinned applications) is normally excluded, and those exclusions are a blind spot.

DNS filtering, and the block that happens before the connection

DNS filtering blocks by refusing to resolve a name, so the connection is never attempted.

Its advantages are structural and worth knowing:

• it works before any connection, so nothing is sent to the malicious host;
• it is protocol-independent — it covers every application on the device, not just the browser;
• it works regardless of encryption, because the lookup happens before the TLS session exists;
• it is cheap and low-latency, and easy to deploy via an agent or a cloud resolver for remote devices;
• and the logs are one of the most valuable detection sources there is. A device querying a known-bad domain is a high-confidence signal even if the connection was blocked.

Its limits: it is name-based, so it cannot block an address accessed directly by IP; it blocks a whole domain rather than one path; and it is bypassed by a client using its own resolver. That last point is the operational detail the exam likes — DNS over HTTPS (DoH) in browsers and applications routes lookups past your resolver entirely, so enterprise policy has to disable it, or force resolution to your own DoH endpoint, or the filtering simply stops applying.

The complementary control is to block outbound DNS to anything but your own resolvers, so a device cannot quietly use another one.

Reputation, block rules, and operating system security via group policy and SELinux

The last part of CompTIA's scope note for this objective is operating system security, and it names two mechanisms.

Group Policy (Windows) distributes configuration centrally from Active Directory: password and lockout policy, audit policy, service configuration, software restriction and application control, firewall rules, removable media restrictions, and the hundreds of settings a benchmark specifies. Its importance is that it is enforcement — the configuration reapplies on a schedule, so drift is corrected, which is the "maintain" stage of 4.1's baseline.

SELinux (and AppArmor) provide mandatory access control on Linux. The distinction from ordinary permissions is the point: standard Linux permissions are discretionary — the owner of a file decides who may access it, and a process running as root can do anything. SELinux adds a policy that the system enforces regardless of the owner's wishes, confining each process to what its type is permitted to do. A compromised web server confined by SELinux can be prevented from reading files outside its domain even when running as root, which is a genuinely different guarantee.

Its modes are worth knowing: enforcing applies the policy, permissive logs what it would have blocked, disabled turns it off. Setting it permissive to troubleshoot and never setting it back is the standard finding — and "we disabled SELinux to make the application work" is a wrong answer the exam will offer.

Reputation and block rules apply here too: application allow-listing at the OS level, driver blocklists, and execution prevention in user-writable directories — all delivered through the same policy mechanisms.

What to take into the exam

• Default deny, first match wins, be specific — and rule order is why a rule "exists but is not working".
• Outbound filtering is the neglected half and is what C2 and exfiltration rely on.
• IPS is inline and can cause outages, so deploy rules in detection mode first.
• Signature catches the known; anomaly catches the unknown at the price of false positives.
• DNS filtering blocks before any connection, covers every application and works despite encryption — and is defeated by DNS over HTTPS and by direct IP access.
• SELinux is mandatory access control: it confines a process even when it runs as root. Permissive mode logs without blocking.