Security
How SlaySlop checks Open Ports
SlaySlop's Open ports check reviews unexpected public service exposure on a permissioned target, then keeps that evidence beside other security surface findings.
· by Henry Smith

I still reach for a mental allowlist first: what did we intend to publish? SlaySlop's Open ports check "Reviews unexpected public service exposure." Without intent, every open listener looks like a crisis or nothing looks like one. I prefer the boring middle: compare public exposure to the written baseline.
I have argued with enough launch decks that said "network locked down" while a forgotten listener answered on a marketing IP. The check exists for that gap.
Outcome the check is for
You want a clear signal when public services fall outside what you meant to expose, so firewall and cloud-network owners get a ticket they can finish. Security and secrets framing keeps this on the public attack surface. Domain insights may sit nearby for infrastructure context. The check is not a full internal network census, and I say that out loud when clients ask for "complete port coverage of the VPC."
Boundaries
Read-only. Permission required. Not a pentest. SlaySlop will not edit security groups. Scanning targets you do not own, manage, or have permission to test violates Acceptable Use. Defensive observation only. No exploit payloads. No "prove it with a banner grab attack chain" requests in the handoff doc.
Open ports is also not nginx/web-server misconfiguration, not Exposed files and admin panels, and not uptime. Those siblings answer different questions even when the emotional label is "infrastructure."
Loading diagram.
Happy path: how I read the signal
- Write the allowlist for the launch (usually HTTPS, maybe HTTP redirect).
- Run or open the permissioned scan.
- Compare Open ports evidence to the allowlist.
- Close or justify each unexpected exposure.
- Rescan the same hostname.
Website scanner framing still applies in the background: public pages and related public infrastructure signals get collected under permission. Open ports is the unexpected-exposure slice of that story.
Local orientation on owned infrastructure stays simple and non-offensive:
# Permissioned / owned — document intent, do not attack
cat <<'EOF'
allowlist:
tcp/443
tcp/80
EOFcheck: open-ports
definition: Reviews unexpected public service exposure.
evidence: unexpected public services vs allowlist
next: security group / firewall rule / justifyWhat the finding can claim
It can claim unexpected public service exposure showed up relative to what you should have intended to publish. It should not invent a private scoring formula. It should not claim private subnets were enumerated. Take the evidence to the owner who can change public reachability.
Pitfalls in interpretation
Treating uptime as a port review. Ignoring forgotten staging IPs. Collapsing nginx/web-server misconfig into the same ticket. Asking for offensive confirmation. Assuming private VPC ports were scanned when they were never public.
I also see teams "fix" exposure by hiding a service behind a secret URL path while the port still answers. That is not the same as removing unexpected public service exposure. Be precise in the note. Another habit to drop: editing a staging security group and calling production done.
Related next step
Keep Open ports beside related security findings in the portal. Soft links: Open ports and Security and secrets. Soft close: a permissioned SlaySlop rescan beats a spreadsheet of assumed firewall rules.