Firewall Misconfiguration Examples

Rules that allow too much

Four checks look at what a permit rule matches. They describe traffic that is allowed right now, so they are the findings that most often decide a review.

• Any source, any destination, any service (SXL-001, critical). The rule matches everything that reaches it, so the firewall does nothing for that traffic. It is often a troubleshooting rule that was never removed. Replace it with explicit sources, destinations and services, or delete it and retest.
• Any service (SXL-002, high; medium when the traffic stays internal). The rule names who and where but permits every port. Restrict it to the TCP and UDP services the application needs.
• Any source (SXL-003). Severity follows direction: high on an interface that holds a public address, low when the rule is internal and probably intended outbound access, medium when the direction cannot be established. Scope the source to known networks, or put the service behind a VPN or proxy.
• High-risk services open to any source (SXL-004, critical when reachable from a public interface, high when internal). The check looks for Telnet, FTP, SMB, MS RPC, NetBIOS, RDP, VNC and SNMP, and for databases and caches: SQL Server, Oracle, MySQL, PostgreSQL, Redis, Elasticsearch and MongoDB. Restrict the source to named management networks, use a VPN or bastion host, or remove the rule.

The management plane

A tidy rule base on a firewall whose administration is exposed is not secure. Four checks cover how the device itself can be reached.

• Cleartext management enabled (SXL-005, critical). Telnet, plain HTTP or FTP used for administration sends credentials across the network unencrypted. Disable them on every interface and use SSH or HTTPS.
• Management reachable from any source (SXL-006, high; critical when the protocol is cleartext). Administrative access with no source restriction exposes the control plane to credential stuffing and to flaws in the management software. Limit it to a dedicated management network with trusted-host or per-service source restrictions.
• Administration on an interface with a public address (SXL-018, critical). Management services on an internet-facing interface expose the device directly. Turn administrative protocols off on outward-facing interfaces and manage the firewall from an internal network.
• Obsolete transport security (SXL-021, high; critical for SSH version 1). SSL 3.0, TLS 1.0 and TLS 1.1 still accepted for administration, or SSH version 1 enabled. Require TLS 1.2 or later, and SSH version 2 only.

SNMP, accounts and sessions

Small settings that make a credential attack cheaper or a stolen session more useful.

• SNMP v1 or v2c in use (SXL-007, medium). The community string travels in cleartext and there is no message integrity. Move to SNMPv3 with authentication and privacy.
• Default SNMP community (SXL-008, critical). Well-known default strings are the first values a scanner tries, and expose the device inventory, or let an attacker write configuration if the community is writable. Remove it and use SNMPv3 with unique credentials.
• Writable SNMP community (SXL-009, high). One shared secret is enough to change configuration. Make it read-only, or use SNMPv3 with scoped access.
• Default administrator account name (SXL-014, medium). A known valid username halves the work of a password attack. Rename it, or create named per-administrator accounts and remove it.
• No password policy (SXL-015, medium). Without an enforced policy, administrative passwords can be short or reused. Enable minimum length and complexity.
• Administrative idle timeout missing or too long (SXL-016, low). The check flags no timeout at all, or more than ten minutes. An unattended workstation with a live session is an open door.

Logging and time

These do not stop an attack. They decide whether you can find out what happened afterwards.

• Permit rule does not log (SXL-010, medium). Unlogged allow rules are the usual reason a breach timeline cannot be reconstructed. Enable session logging on permit rules and send the logs to a collector.
• No syslog server configured (SXL-011, high). Logs held only on the device are lost to failure, rotation or compromise. Configure at least one remote destination, ideally two.
• No NTP server configured (SXL-017, low). Without synchronised time you cannot line up timestamps across devices, which weakens an investigation and the value of the logs as evidence. Configure at least one reliable time source.

Rule hygiene

Dead rules open no hole of their own, but they hide the live ones.

• Shadowed rule (SXL-012, medium when the actions differ, low when they match). A rule that an earlier rule fully covers never matches. If the earlier rule allows and the later one was meant to deny, the intended control silently does not apply. Reorder or remove it.
• Disabled rules left in the policy (SXL-013, low). They accumulate, obscure the effective policy and are sometimes re-enabled without review. Remove them, or record why they stay.

Firmware and remote access

The parts of a firewall that are reachable from the internet by design deserve the most attention.

• Firmware matches a published advisory (SXL-019, critical by default; the advisory sets the severity). Hardening the configuration does not help against a flaw in the firmware. Apply the fixed release the advisory names, or the vendor's current stable release.
• Remote access portal published to the internet (SXL-020, high; critical when it negotiates weak TLS or presents a self-signed certificate on a public interface; lower when it is internal). Keep it on a supported release, restrict it to the countries or networks it is used from, require multi-factor authentication and install a certificate from a trusted authority.

All 21 at a glance

What a configuration review cannot tell you

A clean result means these checks passed. It does not mean the firewall is secure, and it is worth knowing where the checks stop.

A configuration shows what is allowed, not what is used. It cannot say whether a rule still carries traffic, so pair it with hit counters over a full business cycle before you remove anything.

Direction depends on addressing. Whether a rule faces the internet is judged from which interfaces hold a public address. Where that is missing from the file, the finding says the direction was not established and is rated medium instead of guessing.

Some formats do not record everything. Where a platform has no per-rule logging setting, logging is not assessed, and the report says so. The shadowed-rule comparison is skipped above 4,000 enabled rules because the pairwise check is not worth the run time at that size.

Firmware is checked only against the advisory data that is loaded, and only when the version is recorded in the configuration. A clean result there is not a statement that the device is fully patched.

Where this maps

References

• NIST SP 800-41 Rev. 1, Guidelines on Firewalls and Firewall Policy
• PCI DSS v4.0, PCI Security Standards Council
• CIS Benchmarks