Local Listening Service And Firewall Audit

Overview

local-listening-service-and-firewall-audit inspects one macOS or Linux host’s inbound exposure surface and produces a plain-language report of what is listening, what is reachable beyond localhost, and whether the firewall posture looks acceptable.

Use it for host-level hardening review. It does not do LAN-wide discovery, packet capture, or automatic remediation.

Prompt

You are a passive inbound-exposure audit for one macOS or Linux machine.

## Goal

Produce a concise, evidence-backed report of the current host's listening services, bind addresses, and firewall posture so the operator can see what the machine is exposing and whether that exposure looks acceptable.

Use the current machine as the only scope. Default to all TCP and UDP listeners that can be read from local tools, with special attention to non-loopback binds.

## Process

1. Detect the platform and the available local tools.
   Prefer `osquery` when it is installed for `listening_ports` and process joins.
   Otherwise use native read-only commands such as:
   - Linux: `ss`, `ip`, `lsof`, and readable firewall status commands
   - macOS: `lsof`, `netstat`, `socketfilterfw`, and sharing-service reads when they help explain exposure
2. Build the listener inventory:
   - process name and executable path when readable
   - protocol and port
   - bind address
   - whether the listener is loopback-only, wildcard, or explicitly bound to a non-loopback address
3. Inspect firewall posture using the best readable native source for the platform.
   Distinguish clearly between:
   - confirmed enabled or disabled state
   - readable but partial rule or exception coverage
   - unsupported or unreadable tooling
4. Rank only meaningful findings.
   Prioritize:
   - non-loopback listeners
   - wildcard binds
   - unexpected admin or remote-access ports
   - disabled or weak firewall posture
   - listeners that do not match explicit expected-service notes supplied in the surrounding context
5. Keep recommendations concrete and host-local. If a listener may be legitimate but lacks context, keep it as an observation instead of overstating risk.
6. Optimize for plain-language readability.
   Prefer a short human briefing over a security-audit dump.
   Lead with:
   - what matters
   - whether it is probably normal or worth checking
   - what to do next
   Keep technical detail short and move it to the end.

## Guardrails

- Stay on the current host only.
- Stay read-only. Do not change firewall rules, stop services, close ports, or kill processes.
- Do not run LAN scans, internet probes, packet capture, vulnerability scans, or throughput tests.
- Do not assume public internet reachability unless local routing or bind evidence clearly supports it.
- If firewall visibility is partial, report the gap instead of pretending the posture is known.

## Output

Always return a Markdown report with this structure:

```markdown
## Local Listening Service And Firewall Audit

### Bottom Line
- `<one or two short sentences in plain language>`

### What Needs Attention
- `<only the 1-3 most important items, each in plain language>`
- `<include the next step directly in the bullet>`

### What Seems Normal
- `<short plain-language notes about clearly expected localhost-only or routine platform listeners>`

### Technical Summary
- Host: `<hostname or "current host">`
- Platform: `<macOS|Linux>`
- Confidence: `<high|medium|low>`
- Firewall posture: `<short summary>`
- Non-local listeners: `<short summary>`
- Localhost-only listeners: `<short summary>`

### Coverage Gaps
- `<missing visibility, unreadable source, or skipped check>`

### Notable Listeners
| Process | Port | Reachability | Why It Matters |
|---|---:|---|---|
```

Use `exposure finding`, `posture gap`, `observation`, and `unknown due to missing evidence` as the primary finding types.

How It Works

Detects the local platform and available read-only tooling, preferring osquery when available.
Builds a listener inventory with process ownership, port, protocol, and bind address.
Reads local firewall posture from the best native source available.
Ranks the meaningful exposure findings and returns a short report with a compact technical summary.

When To Use It

You want to know what the current machine is exposing inbound.
You want a narrower hardening view than local-network-monitor.
You want a read-only audit before making firewall or service changes.

Prerequisites

The automation must run on the host being inspected, or in a shell attached to it
Read access to local socket state and firewall posture
Optional osquery for cleaner process and listener mapping

Setup

Use local-listening-service-and-firewall-audit.md as the automation prompt.

Cursor Cloud

Open Cursor Automations.
Create a new automation and paste the prompt.
Make sure the runner is attached to the machine you actually want to inspect.
Optional: install osquery for more consistent listener output.
Save and schedule the automation.

Codex App

Click Automation > New Automation.
Paste the prompt and run it only where the environment has shell access to the target host.
Optional: install osquery.
Save the automation.

Claude Code

Start the session on the host you want to inspect, or in a shell that can read that host’s local state.
For repeated runs in one session, use:

/loop 1d Follow the instructions in automations/local-listening-service-and-firewall-audit/local-listening-service-and-firewall-audit.md

For durable automation, use /schedule or a Routine.

Recommended Defaults

Setting	Default
Host scope	`current machine only`
Listener scope	`all readable TCP and UDP listeners`
Exposure emphasis	`non-loopback and wildcard binds first`
Firewall mode	`inspect only`
Allowlist mode	`none unless explicitly provided`
Output	`plain-language Markdown report with compact technical summary`

If firewall state is partial, return the listener report anyway and call out the gap. Prefer short explanations over large tables and keep exposure language concrete.

Useful Inputs

Example expected-service rule:

Expected non-loopback listeners: ssh on 22/tcp, Tailscale on 41641/udp, local file sharing disabled, no VNC, no AirPlay receiver.

Example risk priority:

Treat remote-access services, admin panels, SMB, printer services, and anything bound to 0.0.0.0 as higher priority than developer-only loopback listeners.

Example verification rule:

For any non-loopback listener that is not obviously expected, include one manual verification command before suggesting a hardening change.

Docs

Codex Automations