netbobr

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.