Perimeter security alone is insufficient. A firewall at the network edge does nothing about a compromised laptop already inside, a user visiting a malicious site, or a rogue device plugging into a switch port. This guide covers the technologies that address those gaps: content and DNS filtering, port-based network access control, the authentication frameworks behind it, and behavioral monitoring that catches what policy cannot anticipate.
Content and URL Filtering
The first line of defense is preventing users from reaching harmful destinations in the first place. Several complementary approaches exist:
Agent-based Filtering
A lightweight agent installed on each endpoint enforces policy locally. Even when a device is off the corporate network — on a home connection or public Wi-Fi — the agent continues to apply filtering rules. This makes it effective for remote and hybrid workforces.
Proxy-based Filtering
A central proxy intercepts all outbound HTTP/HTTPS requests. Before fetching a page, the proxy checks the destination against a block list. If the domain or URL is on the list, the proxy returns an error page rather than retrieving the content. Users never contact the destination server directly.
URL Scanning and Keyword Matching
The domain itself may be legitimate, but the full URL can embed keywords that signal harmful content. URL scanning inspects the path, query string, and parameters for those keywords, blocking specific resources without blocking the entire domain.
Content Categorization
Third-party providers pre-classify websites by type: gaming, explicit content, social media, job boards, streaming, gambling, and hundreds of other categories. An organization subscribes to this categorization feed and configures which categories to block. New sites automatically inherit a category as the provider adds them, removing the need to maintain manual block lists.
Reputation Services
Tools like AbuseIPDB aggregate threat intelligence from many clients. When an IP address is reported as a source of malicious or suspicious activity, it is flagged in the shared database. Other subscribers then block traffic to or from that IP automatically. The list grows in real time as new reports arrive, creating a community-maintained threat feed.
DNS Filtering
DNS filtering intercepts name resolution requests. Before a user's browser can connect to a site, it must first resolve the domain to an IP address. If the domain is on a block list, the DNS resolver returns no result — the connection attempt fails before a single packet reaches the destination server.
User requests facebook.com
│
▼
┌──────────────────────┐
│ DNS Filter Server │
│ "facebook.com is │
│ blocked — no │
│ response" │
└──────────────────────┘
│
▼
Browser receives NXDOMAIN
Connection never initiated
Pi-hole is a free, open-source DNS filter commonly run on a Raspberry Pi or as a virtual machine. It ships with a curated list of ad-serving domains. When a webpage requests images or scripts from those domains, Pi-hole returns no response — the ads are never fetched and never displayed. The user sees only the page content they came for.
Operating System-Level Controls
Beyond network filtering, the operating system itself can enforce security policy.
Group Policy (Windows) defines what users and processes are and are not permitted to do. Administrators push these settings centrally across domain-joined machines — restricting software installation, controlling access to system settings, enforcing password policy, and more.
SELinux (Security-Enhanced Linux) embodies mandatory access control at the kernel level. Processes cannot access files, ports, or other resources unless explicitly permitted by policy. Users cannot log in unless specific criteria are met. SELinux is not typical for daily-use workstations, but it is well-suited to servers where tight process isolation is worth the configuration overhead.
802.1x — You Shall Not Pass
802.1x is an IEEE standard for port-based network access control. The core idea is simple: a device cannot send or receive traffic on a network port until it has authenticated. No credentials, no access.
┌──────────────┐ No auth? ┌──────────────┐
│ Device │────────────────▶│ Switch Port │
└──────────────┘ │ BLOCKED │
└──────────────┘
┌──────────────┐ Authenticated ┌──────────────┐
│ Device │◀───────────────▶│ Switch Port │
└──────────────┘ │ OPEN │
└──────────────┘
802.1x applies equally to wired and wireless networks. On Wi-Fi, associating with the access point does not grant network access until authentication succeeds. On a wired switch, plugging in a cable is not enough — the port stays in a blocked state until credentials are verified.
EAP — The Authentication Framework
802.1x defines the policy ("authenticate before you pass"), but not the mechanism. EAP (Extensible Authentication Protocol) provides that mechanism. EAP creates an authentication framework: a structured set of message exchanges that carry credentials from a supplicant (the device trying to connect) to an authentication server, without requiring the device to have full network access first.
The way EAP resolves this chicken-and-egg problem — "I need network access to authenticate, but I need to authenticate to get network access" — is by establishing a limited, direct channel between the supplicant and the authenticator (the switch or access point). Full network access is withheld until authentication completes.
EAP is extensible by design. Several implementations exist, each specifying the exact credential exchange mechanism:
┌───────────────────────────────────────┐
│ 802.1x │
│ "Authenticate before network access" │
│ │
│ ┌─────────────────────────────┐ │
│ │ EAP │ │
│ │ "Here is how to do that" │ │
│ │ │ │
│ │ ┌─────────┐ ┌──────────┐ │ │
│ │ │ EAP-TLS │ │EAP-TTLS │ │ │
│ │ └─────────┘ └──────────┘ │ │
│ │ ┌─────────┐ ┌──────────┐ │ │
│ │ │ PEAP │ │ EAP-FAST │ │ │
│ │ └─────────┘ └──────────┘ │ │
│ └─────────────────────────────┘ │
└───────────────────────────────────────┘
| Implementation | Full Name | Approach |
|---|---|---|
| EAP-TLS | EAP Transport Layer Security | Mutual certificate authentication via a TLS tunnel |
| EAP-TTLS | EAP Tunneled TLS | TLS tunnel with flexible inner authentication |
| PEAP | Protected EAP | TLS tunnel protecting a legacy inner method |
| EAP-FAST | EAP Flexible Authentication via Secure Tunneling | Lightweight tunneling using Protected Access Credentials |
For the Security+ exam, knowing that these four exist is sufficient. Understanding that EAP implements 802.1x, and that different EAP methods answer the same problem with different cryptographic approaches, is what matters.
RADIUS and the AAA Server
When a supplicant authenticates via EAP, its credentials must be checked against an authoritative source. That process flows through RADIUS (Remote Authentication Dial-In User Service).
Despite the dated name — dial-in service is a relic of modem-era remote access — RADIUS remains the standard protocol for this function. Today it connects to a centralized credential store rather than a dial-up bank.
The flow works as follows:
┌──────────────┐ EAP messages ┌──────────────┐
│ Supplicant │◀────────────────▶│ Authenticator│
│ (Device) │ │ (Switch / AP)│
└──────────────┘ └──────┬───────┘
│ RADIUS
▼
┌──────────────┐
│ RADIUS Server│
│ (AAA Server) │
└──────┬───────┘
│
▼
Credential store
(Active Directory,
LDAP, etc.)
The authenticator (switch or AP) acts as a RADIUS client — it forwards the supplicant's credentials to the RADIUS server rather than evaluating them itself. The RADIUS server queries the credential store, evaluates the result, and returns an accept or reject.
On the Security+ exam, RADIUS and AAA are used almost interchangeably. AAA stands for:
- Authentication — verifying identity
- Authorization — determining what an authenticated identity is permitted to do
- Accounting — recording what was done and when
The AAA server is the backend that RADIUS communicates with. When exam questions mention the server that receives and validates credentials for network access, both "RADIUS server" and "AAA server" refer to the same role.
Network Access Control (NAC)
NAC (Network Access Control) extends 802.1x beyond simple credential checking. Before granting network access, NAC can also verify the health of the connecting device — a process called a host health check.
A host health check inspects the device for:
- Operating system patch level
- Anti-malware presence and currency
- Endpoint detection and response (EDR) agent status
- Required security configuration compliance
Only devices that pass the health check receive network access. A device with an outdated OS or no anti-malware can be quarantined to a remediation network segment rather than the production environment.
Agent Types
Agent-based NAC runs a small executable on the connecting device. The agent performs the health check locally and reports results to the NAC system.
Agentless NAC scans devices from a network-based scanner. No software is installed on the endpoints; instead, the scanner probes each device externally and infers its health state.
Persistent vs. Dissolvable Agents
| Type | Behavior |
|---|---|
| Dissolvable | Downloaded on connect, runs the health check, vouches for the device, then deletes itself |
| Persistent | Remains installed, continuously vouching for the device at regular intervals throughout the session |
A dissolvable agent is practical for guest or contractor devices — no permanent software is left behind. A persistent agent is appropriate for managed endpoints where continuous compliance verification is required. If the persistent agent stops reporting (because the user disabled anti-malware, for example), the NAC system can revoke network access.
User Behavior Analytics (UBA)
Even a fully authenticated, fully patched, compliant device can be compromised. Credentials can be stolen. Legitimate accounts can be hijacked. Policy controls cannot catch every scenario.
User Behavior Analytics addresses this by establishing a baseline of normal behavior for each user, then flagging deviations from that baseline.
Humans are creatures of habit. A user who logs in every morning from the same city, accesses the same set of applications, and transfers files of roughly consistent sizes has a recognizable pattern. UBA systems learn this pattern over time.
When behavior falls outside the norm — a login from an unexpected country, a sudden bulk download of sensitive files, access to systems that user has never touched — the system flags it and can trigger an alert or an automated response.
Normal pattern:
Login: 08:00–09:00, Chicago
Apps: CRM, email, project tracker
Data transfer: ~50 MB/day
Anomaly detected:
Login: 02:30, unknown location
Apps: file server, HR database
Data transfer: 4.2 GB in 20 minutes
│
▼
Alert triggered → incident response
UBA catches what static policy cannot: the attacker who has valid credentials, moves slowly, and stays within individual policy rules while exhibiting a behavioral pattern no legitimate user would generate.
Summary
These technologies form complementary layers of a defense-in-depth architecture:
| Technology | What It Does |
|---|---|
| Content/URL filtering | Blocks access to harmful sites before connections are made |
| DNS filtering | Prevents name resolution for blocked domains |
| 802.1x | Denies network access until authentication succeeds |
| EAP | Implements the credential exchange mechanism for 802.1x |
| RADIUS / AAA | Validates credentials and enforces authentication, authorization, accounting |
| NAC | Adds host health checking on top of identity verification |
| UBA | Detects compromised accounts and insider threats through behavioral anomalies |
No single control is sufficient. A user who passes 802.1x with valid stolen credentials, on a healthy device, from an authorized location, will bypass every layer except UBA. Deploying them together closes the gaps that each individual control leaves open.