How to Audit Your Exposed Services

Quick Answer

Write down what you intend to expose, then compare it with observations from an authorized external network. Include IPv4 and IPv6, router mappings, reverse proxies, tunnels, vendor relays, DNS, and secondary WAN paths. Reconfirm address ownership immediately before testing and start with approved targets and ports. Every finding needs an owner, purpose, access policy, logs, and removal procedure. A closed port from one vantage point does not prove there is no other public path.

Audit rule: Build the intended exposure list first, observe from outside second, and reconcile every difference. A closed IPv4 port does not rule out IPv6, a tunnel, a vendor relay, or a different public address.

The Reader Question

What can strangers see on my network right now?

This guide is for a home-lab or small-site operator who administers the gateway, DNS, reverse proxy, tunnels, and cloud remote-access accounts. It assumes explicit authorization to test the listed addresses and services, access to an external network or scanning host, and a protected configuration backup. The result is not a screenshot of open ports; it is an owned register of every public path, why it exists, how it is authenticated and logged, and how to remove it.

Before You Start: Safe Defaults

• Disable UPnP unless a specific device truly requires it and you review mappings.
• Do not expose hypervisor, NAS, firewall, router, or Docker admin UIs directly to the internet.
• Use VPN/tailnet for admin access and reverse proxy only for services meant for users.
• Review IPv6 exposure separately because NAT rules may not apply.

Reference Model

The model separates intent from observation. Inventory all publication mechanisms, observe from genuinely external vantage points, compare results, then remove drift. Repeat after changes because public exposure is a state, not a one-time project.

Interactive reference model

How to Audit Your Exposed Services reference model

Read the model left to right, then open each step below for the operational detail behind the diagram.

Plan Control Change Verify

01List intended services+

Domains, ports, protocols, owner, and reason.

Output: document the evidence from this step before moving to the next one.

02Inspect edge+

NAT, firewall, UPnP, IPv6, tunnels, and vendor cloud.

Output: document the evidence from this step before moving to the next one.

03Scan outside+

Use an external network or trusted scanner.

Output: document the evidence from this step before moving to the next one.

04Remove drift+

Close, restrict, patch, or document every exposure.

Output: document the evidence from this step before moving to the next one.

Decision Matrix

Choice	Best Fit	Watch Point
VPN/tailnet admin	Private administration	Still needs MFA and device hygiene.
Reverse proxy	One or few user-facing web apps	Authentication, headers, logs, and patching matter.
Cloud tunnel	No inbound port but public service	Provider account and tunnel policy become critical.
Direct port forward	Only when unavoidable	Higher exposure and usually less control.

Exposure Sources People Forget

Port forwards are only one source. Review static NAT, Universal Plug and Play (UPnP) and NAT-PMP mappings, reverse-proxy virtual hosts, overlay-network sharing, outbound cloud tunnels, NAS or camera relays, remote desktop brokers, management clouds, IPv6 firewall policy, public DNS, dynamic DNS, old cloud instances, and secondary WAN addresses. A carrier-grade NAT (CGNAT) address may prevent ordinary inbound IPv4, but it does not disable an outbound tunnel or vendor relay.

For each hostname, resolve A and AAAA records from a public resolver and test both families. Review certificate inventory and Certificate Transparency search as discovery aids, but do not treat either as complete: certificates can be private, shared, wildcarded, stale, or issued under names that no longer resolve.

Public Does Not Mean Bad, Unowned Does

A public website or mail gateway can be legitimate. Require a named owner, audience, data classification, application and edge authentication, supported software, least-privilege upstream path, logging, alert, certificate owner, backup, and removal date. A reverse proxy or tunnel changes the path; it does not make the origin application safe or private by itself.

Evidence-Based Cleanup

Classify each finding as keep public, restrict, move private, or remove. Restriction may mean identity-aware access, source allowlists, a private VPN, or disabling vendor-cloud sharing. Before removal, identify users and dependencies, export the current config, and keep a rollback window. Afterward, repeat the same external test and confirm expected users still have the approved path.

Create the Exposure Register

For each path, record public IP or hostname, protocol and port, IPv4/IPv6, publication mechanism, destination service, owner, intended audience, identity control, software version, patch source, log source, certificate expiry, data handled, last external test, and removal procedure. Keep sensitive addresses and scanner output in an access-controlled record rather than a public article or ticket.

Begin with one public hostname and trace it end to end: public DNS, WAN address, firewall or tunnel, proxy, identity layer, application, database, and logs. This catches a common failure where the public edge is patched but an origin port remains directly reachable around it.

Run an Authorized External Audit

Use a host outside the target network, such as an authorized VPS or a laptop on another connection. A scan from the LAN may see NAT reflection, split DNS, or internal policy instead of the public path. Confirm the current WAN IPv4 and delegated IPv6 addresses immediately before testing; dynamic addresses can change and accidentally point the scan at someone else.

1. Write the intended public exposure list and identify the authorized address range.
2. Export static NAT, port forwards, UPnP/NAT-PMP mappings, IPv4 and IPv6 policy, reverse-proxy hosts, tunnel routes, and vendor remote-access settings.
3. Resolve public DNS from more than one resolver and inventory certificates and cloud endpoints.
4. From outside, begin with the approved TCP ports and scan rate. Review findings before expanding to all TCP ports or adding application version probes; those are separate scope and impact decisions.
5. Test approved HTTP hostnames in a clean browser and verify TLS name, login path, headers, rate limits, and logs. Test VPN and non-HTTP protocols with their supported clients.
6. Investigate every mismatch; do not assume a service name inferred from a port number is correct.
7. Remove or restrict one path at a time, repeat the external test, and confirm the approved replacement path before ending rollback.

Unperformed diagnostic example: run only from the approved external host in a protected working directory, with Bash, mktemp, and Nmap available. Set the variables from the written scope: single current IP addresses, an approved numeric TCP port list, and a positive port-scan rate. Confirm the target can tolerate connection attempts and monitor it during the test. If one address family is not assigned or authorized, omit that family's command and required-variable check after reviewing the scope; do not substitute another target.

(
  set -eu
  : "${AUTHORIZED_TARGET_IPV4:?Set the verified single IPv4 address}"
  : "${AUTHORIZED_TARGET_IPV6:?Set the verified single IPv6 address}"
  : "${AUTHORIZED_TCP_PORTS:?Set the approved numeric TCP port list}"
  : "${AUTHORIZED_MAX_RATE:?Set the approved positive scan rate}"
  umask 077
  output_dir=$(mktemp -d ./exposure-review.XXXXXX)
  printf "Results directory: %s\n" "$output_dir"
  nmap -sT -Pn --max-rate "$AUTHORIZED_MAX_RATE" -p "$AUTHORIZED_TCP_PORTS" --reason -oA "$output_dir/ipv4" "$AUTHORIZED_TARGET_IPV4"
  nmap -6 -sT -Pn --max-rate "$AUTHORIZED_MAX_RATE" -p "$AUTHORIZED_TCP_PORTS" --reason -oA "$output_dir/ipv6" "$AUTHORIZED_TARGET_IPV6"
)

This baseline tests only the selected TCP ports. For an approved full-range audit, review Nmap's -p- behavior and scan duration before widening the port set. For approved service identification, use -sV only on reviewed ports and write to a fresh output basename. Consult the timing guide and output guide: the port-scan rate cap is not a universal limit for application probes. Stop on unexpected target impact and record incomplete coverage rather than treating it as closed ports.

A full TCP scan is not a complete internet audit. UDP is harder to classify, cloud relays may not expose your home IP, source allowlists can hide a service from the scanning host, and a service can appear only during a failover or scheduled window. Version detection sends application probes; use it narrowly on your own services and follow provider acceptable-use rules.

Evidence and Testing Methodology

• Operator evidence: dated config exports, DNS answers, tunnel and vendor-cloud inventories, scanner command and source address, raw results, HTTP/TLS checks, and matching firewall, proxy, identity, and application logs.
• Acceptance criteria: observed public paths equal the approved register; admin interfaces fail from untrusted sources; intended services require the expected identity control; IPv4 and IPv6 policy agree; every test reaches a log source.
• Independent context: Shadowserver distinguishes exposure from vulnerability and performs non-exploitative internet measurement; Nmap documentation warns that port-based service guesses and filtered UDP states have limits.
• Not performed here: TechGeeks did not scan the reader's addresses, verify a tunnel policy, identify software versions, or test failover. The commands are a documentation-backed method, not original lab results.

Validation Checklist

• External scans match the intended exposure list.
• Admin interfaces are not reachable publicly.
• UPnP mappings are disabled or documented.
• IPv6 firewall rules match IPv4 intent.
• Every public hostname has an owner, auth method, patch plan, and log source.

Maintenance Cadence

• After every gateway, DNS, tunnel, proxy, ISP, failover, or vendor-cloud change: repeat the affected external tests.
• Monthly: reconcile the exposure register with live DNS, certificates, NAT, UPnP, IPv6, tunnels, and cloud sharing.
• Quarterly: run the authorized outside scan from a known source and test removal of one noncritical path.
• Immediately after an unexpected finding: preserve logs, close or isolate the path, patch, rotate exposed credentials where warranted, and review for access.

Troubleshooting

Symptom	Likely Cause	First Check
External scan shows unknown port	UPnP, old NAT rule, IPv6, or vendor cloud	Check router mappings, firewall, tunnels, and device remote access settings.
Domain reaches wrong service	DNS or reverse proxy stale route	Check DNS records and proxy host mapping.
Service still reachable after closing port	Alternate tunnel or IPv6 path	Test from cellular and inspect tunnel/provider dashboards.

Common Mistakes

• Checking only IPv4 and forgetting IPv6.
• Assuming no port forward means no public access because a tunnel exists.
• Leaving old DNS records after removing a service.
• Publishing test services with default credentials.
• Putting a reverse proxy in front of an app and forgetting app-level auth.

Useful Gear And Buyer Notes

An exposure audit rarely requires new hardware. When a travel router, firewall appliance, console adapter, or test host fills a real gap, confirm IPv6 support, VLAN and VPN behavior, update policy, local logging, interface count, and the exact power and throughput requirements of the authorized test path.

Affiliate disclosure: As an Amazon Associate, TechGeeks may earn from qualifying purchases. The product links below are buying references, not a requirement to buy a specific brand or seller. Verify compatibility, seller quality, warranty, and current specs before ordering.

• Amazon search: firewall appliance
• Amazon search: YubiKey security key
• Amazon search: network scanner appliance
• Amazon search: UPS for router
• Amazon search: label maker network cables

Related TechGeeks Reading

• What Is the Safest Way to Expose One Self-Hosted App Publicly?
• Homelab Reverse Proxy Guide: HTTPS Without Unsafe Exposure
• WireGuard Home VPN: Secure Remote Access for Your Homelab

What This Evidence Does Not Prove

An open port proves that the scanning vantage point received a response; it does not by itself prove a vulnerability, identify the process with certainty, or show that every internet source has the same access. A closed or filtered result from one address does not rule out IPv6, UDP, source-specific policy, a tunnel, vendor relay, failover WAN, or a service that was offline during the test.

Only test systems and address ranges you own or have explicit written authorization to assess. ISP, cloud, hosting, and employer policies may impose additional limits. Discovery is not a penetration test and does not prove the application resists authentication bypass, request smuggling, vulnerable dependencies, credential abuse, or data leakage.

Practical FAQ

Should I use Shodan?

It can help, but do not rely on any single index. Scan and inspect your own edge too.

Is a Cloudflare Tunnel safer than port forwarding?

It reduces inbound firewall exposure, but the service is still public if policy allows it.

How often should I audit?

Monthly for small sites and after every router, firewall, reverse proxy, DNS, or tunnel change.

Before Each Audit

Before testing, verify current address ownership, Nmap behavior, gateway/IPv6 policy, and the provider's authorized-testing terms. Keep household names, public addresses, tunnel IDs, and raw results in the protected audit record. Third-party scanner coverage and privacy terms must be checked separately; an index is not a complete exposure register.

References

• Nmap Port Scanning Overview
• Nmap Service and Application Version Detection
• RFC 9099: Operational Security Considerations for IPv6 Networks
• RFC 6092: IPv6 Simple Security for Residential Gateways
• Shadowserver Internet Scanning Method and Limits
• Shadowserver Vulnerable IMAP Report
• Netgate Port Forward Documentation