What netbobr does well

netbobr's strength is rule quality assessment. It does not need resolved IPs to do useful work. It evaluates how broad your source and destination networks are and flags when a rule covers more hosts than you might expect. It checks the requested service and port exposure. It looks at the underlying protocol and whether it transmits data in plaintext or relies on weak default authentication. That is how the risk score is calculated.

On the compliance side, over 90% of findings are driven by protocol and port, not by IP address. netbobr catches those violations regardless of how the endpoints are addressed.

Where it falls short

netbobr operates at Layer 3/4 of the OSI model with a limited attempt at Layer 7 through service-name lookups on well-known ports. It cannot resolve FQDNs to IP addresses. A hostname like "api.stripe.com" returns different IPs by region, time of day, and CDN edge. A browser-based tool with no backend cannot perform DNS lookups, so netbobr is a static, client-side firewall request analyzer without FQDN resolution.

The tool also lacks coverage for custom port mappings. If a service runs on a non-standard port, netbobr will not recognise it. Custom port support may ship in a future release using the same principles that drive the existing engine.

What the future may hold

netbobr is a client-side static analyzer. The built-in policies and the scoring engine behind them reflect years of hands-on network security work, tested and refined through daily use by the author.

FQDN support would require a server-side component and is significantly more complex than what netbobr does today. The same applies to cloud-native constructs like Azure service tags, AWS security group IDs, and Kubernetes labels. These are opaque references that mean nothing without querying the platform to resolve the underlying IPs, protocols, and ports. Both capabilities are on the radar if netbobr ever moves toward a commercial offering.

Scope of analysis

netbobr assesses firewall rule configurations, not organizational compliance. Findings identify structural risks in how rules are written - overly broad sources, permissive port ranges, unencrypted protocols - not active threats or confirmed policy violations. A finding means the rule permits a traffic pattern that conflicts with a framework's requirements. Whether that pattern represents actual risk depends on compensating controls, network context, and business justification that a static rule analyzer cannot observe.

About the risk score

The 0-100 risk score is a heuristic indicator of structural exposure. It measures configuration breadth across four factors: source CIDR width, destination CIDR width, port exposure, and zone policy. It does not account for business context, compensating controls, or threat intelligence. A high score means the rule permits a wide attack surface, not that a breach is imminent. A low score means the rule is tightly scoped, not that the underlying service is safe. Treat it as a prioritization signal for rule review, not a definitive risk measurement.

MITRE ATT&CK detection confidence

The 25 MITRE ATT&CK rules across 6 techniques detect structural enablement - the firewall permits a network path that an attacker could use for a given technique. They do not detect actual attacks or active exploitation. Detection confidence varies by technique.

High confidence: T1133 (External Remote Services) - port and direction are directly observable in the rule. Medium confidence: T1021 (Remote Services), T1048 (Exfiltration Over Alternative Protocol), T1071 (Application Layer Protocol) - structural capability is detected but actual exploitation requires additional context. Low confidence: T1018 (Remote System Discovery), T1046 (Network Service Discovery) - the rule permits a broad configuration that could enable reconnaissance, but the tool cannot distinguish intentional broad access from an actual scanning opportunity.

NIS2 and DORA article mapping

NIS2 and DORA findings map firewall rule characteristics to specific directive and regulation articles. Most rules combine flow data (protocol, port, direction) with policy inference from CIDR breadth - for example, a /8 source accessing a database port is flagged as an access control failure. A smaller number of rules are purely protocol-based (detecting cleartext or deprecated protocols), and one rule per framework checks documentation (business justification). NIS2 Art. 21(2) is principles-based; DORA Art. 9 is more prescriptive. In both cases, findings represent the author's interpretation of how firewall rule design relates to regulatory requirements, not a compliance determination. A flagged rule means the permitted traffic pattern may conflict with a requirement - it does not mean the organization is non-compliant.