Read exactly what the free firewall review looks at before you run it. Each check is deterministic: the same configuration always gives the same findings, with the reason and the fix written next to each one. Run it offline, so the configuration never leaves your machine, or online.
The checks cover overly broad allow rules, risky services exposed to the internet, cleartext and open management access, default and weak administrator settings, SNMP, missing logging and time sync, shadowed or disabled rules, known vulnerable firmware and weak transport encryption. Findings carry references to NIST, PCI DSS and CIS guidance where they apply.
| ID | Check | Severity | What it looks for | How to fix | References |
|---|---|---|---|---|---|
| SXL-001 | Permit rule allows any source to any destination on any service | critical | A rule matching every source, destination and service defeats the purpose of the firewall for all traffic reaching it. | Replace with explicit source, destination and service objects. If the rule is a temporary troubleshooting entry, remove it and re-test. | NIST SP 800-41r1, PCI DSS v4.0 Req. 1 (Network Security Controls), CIS Benchmark (vendor firewall) |
| SXL-002 | Permit rule allows any service | high | Permitting every port removes the firewall's ability to limit exposure. | Restrict the rule to the specific TCP/UDP services the application requires. | NIST SP 800-41r1, PCI DSS v4.0 Req. 1 (Network Security Controls) |
| SXL-003 | Permit rule accepts traffic from any source | high | An unrestricted source means the destination is reachable by any host that can route to the firewall. Severity depends on direction: inbound from an internet-facing interface is exposure, whereas an outbound rule permitting any internal host is usually the intended configuration. | Scope the source to known networks, or front the service with a VPN or proxy. | NIST SP 800-41r1, PCI DSS v4.0 Req. 1 (Network Security Controls) |
| SXL-004 | High-risk service permitted from any source | critical | Administrative, file-sharing and database services are routinely targeted by automated scanning and should never accept connections from arbitrary sources. | Restrict the source to named management networks, or move access behind a VPN or bastion host. Remove the rule if the exposure is not required. | NIST SP 800-41r1, PCI DSS v4.0 Req. 1 (Network Security Controls), CIS Benchmark (vendor firewall) |
| SXL-005 | Cleartext management protocol enabled | critical | Telnet, HTTP and FTP transmit administrative credentials and session data without encryption, allowing interception and replay by anyone on the path. | Disable the protocol on every interface and use SSH or HTTPS instead. | NIST SP 800-41r1, PCI DSS v4.0 Req. 2 (Secure Configurations), CIS Benchmark (vendor firewall) |
| SXL-006 | Management interface reachable from any source | high | Administrative access with no source restriction exposes the device's control plane to credential-stuffing and exploitation of management-plane bugs. | Restrict administrative access to a dedicated management network using trusted-host or per-service source restrictions. | NIST SP 800-41r1, PCI DSS v4.0 Req. 2 (Secure Configurations), CIS Benchmark (vendor firewall) |
| SXL-007 | SNMP v1/v2c in use | medium | SNMP v1 and v2c authenticate with a community string sent in cleartext and provide no message integrity. | Migrate to SNMPv3 with authentication and privacy enabled. | NIST SP 800-41r1, PCI DSS v4.0 Req. 2 (Secure Configurations), CIS Benchmark (vendor firewall) |
| SXL-008 | Default SNMP community string | critical | Default community strings are the first values any scanner tries and expose full device inventory, and configuration write access where the community is writable. | Remove the default community and configure SNMPv3 with unique credentials. | PCI DSS v4.0 Req. 2 (Secure Configurations), CIS Benchmark (vendor firewall) |
| SXL-009 | SNMP community permits write access | high | A writable community allows configuration change using a single shared secret. | Set the community to read-only, or move to SNMPv3 with scoped access. | PCI DSS v4.0 Req. 2 (Secure Configurations), CIS Benchmark (vendor firewall) |
| SXL-010 | Permit rule does not log traffic | medium | Traffic permitted without logging leaves no record for incident investigation, and unlogged allow rules are the usual reason a breach timeline cannot be reconstructed. | Enable session logging on permit rules and forward logs to a syslog collector. | PCI DSS v4.0 Req. 10 (Logging and Monitoring), NIST SP 800-41r1 |
| SXL-011 | No syslog server configured | high | Logs held only on the device are lost on failure, rotation or compromise. Off-box logging is required by most audit regimes and is the basis of any investigation. | Configure at least one remote syslog destination, ideally two. | PCI DSS v4.0 Req. 10 (Logging and Monitoring), NIST SP 800-41r1 |
| SXL-012 | Rule is unreachable (shadowed by an earlier rule) | medium | A rule fully covered by an earlier rule never matches. Where the actions differ the intended control silently does not apply. | Reorder or remove the shadowed rule so the intended policy takes effect. | NIST SP 800-41r1, CIS Benchmark (vendor firewall) |
| SXL-013 | Disabled rules left in the policy | low | Disabled rules accumulate, obscure the effective policy and are occasionally re-enabled without review. | Remove disabled rules that are no longer required, or document why they remain. | CIS Benchmark (vendor firewall) |
| SXL-014 | Default administrator account name in use | medium | Retaining a default account name gives an attacker a known-valid username, halving the work of a credential attack. | Rename the account, or create named per-administrator accounts and remove it. | PCI DSS v4.0 Req. 2 (Secure Configurations), CIS Benchmark (vendor firewall) |
| SXL-015 | No password policy enforced | medium | Without an enforced policy, administrative passwords may be short or reused. | Enable the device password policy with minimum length and complexity. | PCI DSS v4.0 Req. 2 (Secure Configurations), CIS Benchmark (vendor firewall) |
| SXL-016 | Administrative idle timeout missing or too long | low | Long-lived idle sessions can be reused from an unattended workstation. | Set the administrative idle timeout to 10 minutes or less. | PCI DSS v4.0 Req. 2 (Secure Configurations), CIS Benchmark (vendor firewall) |
| SXL-017 | No NTP server configured | low | Without synchronised time, log timestamps cannot be correlated across devices, which undermines investigation and the evidential value of logs. | Configure at least one reliable NTP source. | PCI DSS v4.0 Req. 10 (Logging and Monitoring), NIST SP 800-41r1 |
| SXL-018 | Administrative access enabled on an interface holding a public address | critical | Management services on an internet-facing interface expose the control plane directly to untrusted networks. | Disable administrative protocols on outward-facing interfaces and manage the device from an internal management network. | NIST SP 800-41r1, PCI DSS v4.0 Req. 2 (Secure Configurations), CIS Benchmark (vendor firewall) |
| SXL-019 | Firmware version matches a published advisory | critical | Configuration hardening does not help against a flaw in the firmware itself. Remote-access portals on unpatched firewalls are among the most reliably exploited paths into a network. | Apply the fixed release named in the advisory, or the vendor's current stable. | Vendor PSIRT advisory |
| SXL-020 | Remote access portal published to the internet | high | SSL-VPN and similar portals are reachable from the internet by design, which makes them the part of a firewall most worth keeping current and most worth restricting. A self-signed certificate additionally trains users to dismiss certificate warnings. | Keep the portal 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. | NIST SP 800-41r1, CIS Benchmark (vendor firewall) |
| SXL-021 | Obsolete transport security permitted | high | SSL 3.0 and TLS 1.0/1.1 have known, practical weaknesses and are refused by current clients. SSH version 1 is broken outright. Permitting them keeps an attacker's downgrade path open and fails most audits. | Require TLS 1.2 or later, and restrict SSH to version 2. | PCI DSS v4.0 Req. 2 (Secure Configurations), CIS Benchmark (vendor firewall) |