Firewall Configuration Best Practices: How to Secure Your Firewall

Hero Summary

A firewall is only as secure as its configuration. The core best practice, recommended by NIST in SP 800-41 Rev. 1, is "deny by default": block all inbound and outbound traffic that the firewall policy has not expressly permitted. Beyond that, a secure setup protects the firewall's own management interface, divides the network into zones, writes narrow allow rules followed by a final deny-all, controls changes formally, logs and monitors activity, and is tested regularly with vulnerability assessment and penetration testing.

Executive Summary

Firewalls filter traffic between networks based on rules covering addresses, ports, and protocols. A firewall with weak rules, default credentials, an exposed administration interface, or years of unreviewed exceptions can give a false sense of security. This guide explains how firewalls work, then sets out configuration practices in the order they matter: protecting the device itself, a deny-by-default rule base, network zones, access control list structure, change management, logging and monitoring, and testing. It also corrects a common ACL misconception — an access control list should end with a deny-all rule, not combine "deny all" and "allow all."

What a firewall does {#what}

A firewall sits between networks — for example, between the internet and an internal network, or between internal segments — and decides which traffic may pass. It evaluates traffic against an ordered set of rules based on attributes such as source and destination IP address, port, and protocol, and either allows or blocks it. Modern firewalls add application awareness, intrusion prevention, and inspection of encrypted traffic, but the fundamentals remain the same: the rules define the security, so the rules must be correct.

Protect the firewall itself {#protect}

The firewall is a high-value target, so secure it before configuring traffic rules:

• Keep firmware and software updated, and subscribe to vendor security advisories.
• Remove or change default accounts and passwords, and avoid shared administrator accounts. Use individual accounts with the minimum privileges needed.
• Require strong authentication, including multi-factor authentication, for administrators.
• Restrict management access to a dedicated management network or specific trusted addresses. Do not expose the administration interface to the internet.
• Disable unused services and features on the device.
• Back up configurations securely and store them offline, so a failed change or compromise can be reversed.

Deny by default {#deny-default}

NIST's Guidelines on Firewalls and Firewall Policy (SP 800-41 Rev. 1) recommend that firewalls block all inbound and outbound traffic that has not been expressly permitted by the firewall policy — traffic that the organization does not need. This practice, known as deny by default, reduces the risk of attack, and NIST considers it more secure than permitting everything not explicitly forbidden, because hosts, networks, protocols, and applications change constantly.

In practice:

• Start from a position where nothing is allowed.
• Add allow rules only for traffic with a documented business need.
• Be as specific as possible about source, destination, port, and protocol. Avoid "any to any" rules.
• Permit only the IP protocols the organization needs, and apply the same deny-by-default approach to IPv6 as to IPv4.

Segment the network into zones {#zones}

Group assets by function and sensitivity and place each group in its own zone — for example, a public-facing zone (often called a DMZ) for internet-facing servers, an internal user network, a server or data zone for sensitive systems, and a separate guest network. Then control traffic between zones with explicit rules. More zones, sensibly designed, limit how far an attacker can move after compromising a single system and make traffic easier to understand and monitor.

Structure access control lists correctly {#acls}

An access control list (ACL) is an ordered list of allow and deny rules, evaluated from top to bottom. A secure structure is:

1. Specific allow rules for each permitted flow.
2. A final deny-all rule that blocks everything else, ideally with logging.

An ACL should not end with an "allow all" rule — that would cancel out the protection of the deny-all. Rule order matters, because the first matching rule applies, so place specific rules before general ones.

Control outbound traffic {#egress}

Many organizations filter inbound traffic carefully but leave outbound traffic open. Restricting outbound connections limits what malware on an infected system can do — for example, contacting an attacker's server or sending data out. At a minimum, block traffic with invalid source addresses and allow outbound connections only to what is needed.

Use formal change management {#changes}

Changes to a firewall should go through a documented request, review, approval, and testing process, with a way to roll back. Avoid making changes on the basis of informal requests by email, text, or phone calls, which invite mistakes and can be used by attackers impersonating staff. Record who requested each rule, why, and when it should be reviewed or removed.

Review rules regularly {#review}

Rule sets accumulate exceptions over time. Review them on a schedule — at least annually, and after major changes — to find and remove unused, duplicate, expired, or overly permissive rules, and to confirm that each remaining rule still has a business owner and justification.

Log and monitor {#logging}

Enable logging for denied traffic and for administrative actions, and send logs to a central system so they can be correlated with other signal. Keep device clocks synchronized so events from different systems can be lined up in an investigation. For organizations in India, CERT-In's April 2022 directions require logs of ICT systems to be retained for 180 days. Logs only help if someone reviews them, so alerting and continuous monitoring turn raw logs into early warning.

Test the configuration {#test}

Do not assume a firewall works as intended. After changes — and on a regular schedule — test it:

• Vulnerability assessment to find weaknesses in the firewall and the services behind it.
• Penetration testing to check whether an attacker can actually bypass rules or reach protected zones.
• Configuration review or IT security audit against your policy and a recognized baseline.

Back up the configuration before testing so you can restore it if something breaks. For how the two testing methods differ, see VAPT vs Penetration Testing.

How Threat ResQ fits {#threat-resq-fit}

Threat ResQ's VAPT service covers vulnerability assessment and penetration testing, with retest included on all critical findings, and is delivered in collaboration with a CERT-In empanelled security firm. Its IT Security Audit service reviews configuration and controls against policy. SOC+, Threat ResQ's managed detection and response platform, provides 24x7 monitoring and alert triage by a live analyst team, with correlated detection across endpoint, network, and identity signal.

FAQ {#faq}

What is the most important firewall best practice? Deny by default: block all traffic that is not expressly permitted, then add narrow allow rules for documented business needs. NIST SP 800-41 Rev. 1 recommends this approach.

What should an ACL end with? A final deny-all rule that blocks anything not explicitly allowed by the rules above it. An ACL should not combine a deny-all with an allow-all rule, because the allow-all would override the protection.

How often should firewall rules be reviewed? Regularly — at least annually and after major changes — to remove unused, duplicate, and overly permissive rules and to confirm each rule still has an owner and a business justification.

How do I protect the firewall itself? Keep firmware updated, remove default accounts, use individual administrator accounts with multi-factor authentication, restrict management access to a dedicated network, disable unused services, and keep secure backups of the configuration.

How do I know my firewall is configured securely? Test it. Vulnerability assessment and penetration testing show whether rules can be bypassed and what an attacker could reach, and a configuration review checks the rule base against your policy.