Host-Based Firewall and Application Allowlisting

A network firewall sits at the perimeter and filters traffic between network segments. A host-based firewall runs on the individual endpoint and filters traffic to and from that specific machine. Host-based firewalls provide defense-in-depth: even if an attacker bypasses the network firewall (via a VPN, a compromised insider, or lateral movement from another infected host), the host firewall enforces local traffic rules. They are especially important for laptops that travel outside the corporate perimeter and connect to untrusted networks.

Windows Defender Firewall (WDF) is the built-in host firewall in all modern Windows versions. It supports three profiles: Domain (connected to corporate domain — typically more permissive), Private (trusted home network), and Public (untrusted networks — most restrictive). WDF rules can filter by port, protocol, application path, remote IP, and user identity. The Windows Defender Firewall with Advanced Security (WFAS) MMC snap-in and Group Policy enable centralized enterprise management of firewall rules across all domain-joined machines.

Linux host firewalls use the Netfilter kernel framework, configurable through iptables (legacy, still widely used) or the modern nftables. Rules are organized into chains (INPUT, OUTPUT, FORWARD) within tables (filter, nat, mangle). The default policy should be DROP with explicit ACCEPT rules for needed traffic — the deny-by-default posture. Higher-level tools like ufw (Ubuntu) and firewalld (RHEL/CentOS) provide friendlier interfaces while still using Netfilter under the hood.

Host-based firewalls can enforce rules at the application layer — filtering traffic by the application that generated it, not just the port. Windows Defender Firewall supports application-based rules: allow C:\Program Files\MyApp\app.exe to make outbound connections while blocking everything else on the same port. This prevents malware from hijacking allowed ports by pretending to be a trusted application. Application-layer rules are significantly more effective than port-only rules, which can be bypassed by binding malware to common ports like 443.

Application allowlisting (previously called whitelisting) is a security control that permits only explicitly approved applications to execute on an endpoint. Any executable not on the allowlist is blocked, regardless of whether it is malware or simply unapproved software. This is a powerful defense against malware because even novel, zero-day malware is blocked if it is not on the approved list. The challenge is operational: managing the allowlist in large, dynamic environments requires a mature change management process and generates significant support tickets if poorly tuned.

AppLocker is Windows' built-in application control feature available on Enterprise and Education editions. It filters execution by: path (block executables from %TEMP% or user-writable directories), file hash (allow only known-good hashes), or publisher (allow software signed by Microsoft or Adobe). AppLocker policies are deployed via Group Policy and logged to the Windows Event Log (Event ID 8003 = blocked). Running AppLocker in Audit Mode first — logging blocks without enforcing — lets teams tune the allowlist before enforcement begins.

WDAC is the more powerful successor to AppLocker, enforced at the kernel level rather than user space. Unlike AppLocker, WDAC cannot be bypassed by attackers with local administrator rights, making it the preferred control for high-security environments. WDAC policies are written in XML and converted to binary policy files deployed via MDM (Intune) or Group Policy. WDAC also enables Intelligent Security Graph (ISG) integration, which uses Microsoft's cloud reputation service to automatically allow software with a trusted reputation — reducing the operational burden of manually curating the allowlist.

Allowlisting is powerful but operationally demanding. Common challenges: LOLBins (Living-Off-the-Land Binaries) — attackers use Windows system tools like PowerShell, wscript.exe, and mshta.exe that are typically on every allowlist; allowlisting must restrict how these are invoked, not just whether they run. Scripting languages (PowerShell, Python) are often allowlisted but can execute malicious code. False positives — legitimate software blocked by the allowlist — generate helpdesk tickets and pressure to weaken controls. Mature allowlisting programs address LOLBins through additional constrained language mode policies.

Allowlisting permits only explicitly approved items and blocks everything else — a stronger security posture. Denylisting (blacklisting) blocks explicitly known-bad items and allows everything else — the traditional antivirus model. Denylisting fails against unknown threats; allowlisting fails against LOLBins and overly broad allow entries. Most mature security programs use allowlisting as the primary control for critical systems while using behavioral detection (EDR) to catch misuse of allowed applications. For less critical systems, a well-tuned denylist with behavioral monitoring may be acceptable.

Host-based firewalls and application allowlisting are complementary, layered controls. The allowlist prevents unauthorized code from executing; the firewall prevents unauthorized network connections from authorized-but-compromised code. Together, they implement least-privilege principles at both the application and network layer on the endpoint. Adding EDR as a third layer creates a defense-in-depth stack where each control catches what the others might miss, dramatically raising the cost and complexity of successful attacks on endpoints.

Host-based firewalls are only as valuable as the logs they generate. Enable logging for blocked connections to capture attack attempts and policy violations. Enable logging for allowed connections on sensitive rules (such as those permitting administrative tools) to maintain an audit trail. Forward firewall logs to the SIEM for correlation — a pattern of blocked outbound connections from a single host may indicate malware attempting C2 callbacks. On Windows, firewall logs are written to %systemroot%\System32\LogFiles\Firewall\pfirewall.log by default and should be forwarded via Windows Event Forwarding (WEF) or a log agent.

Test your understanding of CompTIA Security+ (SY0-701) concepts from this lesson.

In this lesson you learned: host-based firewalls (Windows Defender Firewall, iptables) filter traffic per-endpoint with deny-by-default posture and application-scoped rules, application allowlisting (AppLocker, WDAC) blocks unauthorized executables including malware from running, and layering firewall, allowlisting, and EDR creates defense-in-depth that raises the attack cost dramatically. Next up we explore email authentication: SPF, DKIM, and DMARC.