A host-based firewall is software on a server that filters that one machine's inbound and outbound traffic. Configure it as default deny: block everything, then allow only the ports, sources and applications the server needs. Add outbound limits and logging, and manage the rules centrally so they do not drift.
Why bother when a network firewall already exists?
A perimeter firewall only sees traffic that crosses it. Two servers on the same subnet talk to each other without passing through it at all. NIST SP 800-41 Rev. 1 makes this point directly: a host-based firewall that allows only necessary traffic protects against malicious activity from all hosts, including those on the same subnet or on other internal subnets not separated by a network firewall.
That matters after the first compromise. An attacker who lands on one web server will scan its neighbors. A host firewall that only accepts the database port from the application servers turns that scan into a wall of dropped packets.
What does a good rule set look like?
Here is a constructed example for a small database server. It needs to accept database connections from two application servers and SSH from a bastion host, and nothing else.
- Inbound from app servers A and B on port 5432: allow.
- Inbound from the bastion host on port 22: allow.
- Inbound from anything else: drop and log.
- Outbound to the package mirror and time server on ports 443 and 123: allow.
- Outbound to anything else: drop and log.
The last two rules are the ones most teams skip. NIST notes that limiting outgoing traffic from a server may help prevent certain malware that infects a host from spreading to other hosts. It also cuts off the easy path for a compromised process to call home.
Is the host firewall a security boundary on its own?
No, and NIST says why in a footnote: if an attacker gains administrator-level privileges on the host, they can disable or circumvent the host-based firewall. Treat it as a layer that raises the cost of lateral movement and shrinks the damage from a misconfigured service, not as a sandbox.
This is also why rule changes should leave a trail. If a firewall is turned off or a rule is widened, you want to know within minutes, from a system the attacker does not control.
What about laptops and personal firewalls?
NIST describes personal firewalls as the desktop and laptop version, with an interface meant for end users. They protect machines both inside and outside the perimeter, which is the situation for any laptop on a hotel network. Some allow separate profiles by location, so rules can be stricter on an untrusted network than in the office. NIST recommends centralized management where possible so policy follows the user.
How to check or apply this
- List every listening port on the server and name the service and owner for each one. Close the ones nobody can justify.
- Set the default inbound policy to deny, then add allow rules with a specific source address or range, not "any".
- Set the default outbound policy to deny for servers with a stable set of destinations. Allow package mirrors, time, DNS and the systems the service truly calls.
- Turn on logging for dropped traffic and send it to a central place. A flood of drops from an internal address is worth a look.
- Keep rules in version control or in your configuration management tool, and compare running state against it on a schedule.
- Test from a neighbor machine, not from the server itself. A rule that works from localhost proves nothing.
- Review the rules whenever a service is retired. Old allow rules are quiet exposure.
Quick check
Is a host-based firewall the same as antivirus?
No. A firewall controls network connections for one machine. Antivirus and endpoint tools look at files and processes. They solve different problems and work well together.
Should outbound traffic be restricted too?
On servers with a predictable set of destinations, yes. NIST notes it can limit the spread of malware that infects a host.
Sources
Last reviewed: 18 October 2026.
