how to audit open ports on your network

How to Audit Open Ports on Your Network (October 2026)

by 12 min read

A port audit is three passes: find which hosts are alive, scan all 65535 TCP ports on them with service detection, then confirm from outside whether anything is genuinely reachable. Add a targeted UDP pass and a re-scan after you fix what you find. On a home or small office network the whole thing takes about half an hour, and the hard part is not the commands — it is recording which results were supposed to be there. If you have never run one, here is how to audit open ports on your network from start to finished evidence.

Scanning hardware you own is generally treated as legitimate security hygiene. Scanning anything you do not own or administer without written permission is a different matter and can be illegal in many jurisdictions, so at work get the authorization in writing before a single packet leaves your laptop.

Table of Contents

What You Need

Most failed audits fail at the setup stage, so gather these before you type anything:

  • Written authorization — a change ticket, email or signed rules-of-engagement note naming the ranges you may scan and the window you may scan them in.
  • A current subnet list — DHCP reservations, the router’s connected-device table, or your VLAN list. Assume nothing is on a single subnet until you confirm it.
  • Nmap 7.x or newer — install with sudo apt update && sudo apt install nmap on Debian or Ubuntu, sudo dnf install nmap on Fedora, brew install nmap on macOS, or the Windows installer, which also drops in Zenmap.
  • Privileges — root on Linux and macOS, an Administrator PowerShell on Windows. Without them Nmap falls back to a connect scan and gives you a weaker, slower, more visible result.
  • Local access to the hosts — netstat and ss only report the machine they run on, so you need console or remote-shell access to confirm what each listener actually is.
  • Firewall and asset records — current rule exports, a host register, and past scan output so you can diff against a baseline.

Command syntax differs across shells mainly in quoting and path separators; the Nmap flags themselves are identical everywhere. What differs is whether your prompt is elevated, and on Windows whether you run from PowerShell, cmd, or Zenmap.

Step-by-Step: How to Audit Open Ports on Your Network

1. Plan how to audit open ports on your network without scanning devices you do not own

Define the authorized IP ranges first, then decide who is in the blast radius. A work range like 192.168.10.0/24 covers 254 addresses and usually includes printers, VoIP phones, cameras and the router’s management interface, all of which can misbehave under a fast scan. Exclude them or scan them in a quiet window such as after hours, and record who approved the audit and when.

Prefer a DHCP reservation list or the router’s current address table over guessing that everything lives on one subnet. Guests, IoT gear and management networks frequently land on separate ranges you would otherwise never touch.

How you know it worked: you have a written list of ranges, an explicit exclusion list, and a named approver in the audit log before the first packet goes out.

2. Create a baseline of expected devices and services

Before scanning remotely, capture what each machine should legitimately be running. Pull DHCP leases, the switch or router neighbor table, and DNS records, then check listeners locally:

Windows (cmd)      netstat -ano | findstr LISTENING
Windows (PS)       Get-NetTCPConnection -State Listen | Select-Object LocalPort,OwningProcess
Linux              ss -tulnp
macOS              netstat -anv -p tcp
macOS (alt)        sudo lsof -nP -iTCP -sTCP:LISTEN

This local output only tells you what is listening on the one machine you are standing on — it scans nothing remote. Build a simple inventory with IP address, owner, device type, operating system and approved services, and keep it as a CSV or spreadsheet. That sheet is the difference between a list of ports and a list of problems.

Common intentional services on a home network include 443 for a reverse proxy, 32400 for Plex, and 22 for SSH if you actually use it. Write those down as expected before you see them in scan output.

How you know it worked: every device on the network appears in the inventory with a named owner, including the ones you are not sure about.

3. Run a scoped Nmap discovery scan

Run host discovery first so you scan hosts that actually exist instead of firing at all 254 addresses blindly:

Linux / macOS       sudo nmap -sn 192.168.10.0/24 -oA audit/discovery
Windows (Admin PS)  nmap -sn 192.168.10.0/24 -oA auditdiscovery

Then run the full TCP port scan against that range. The -sS flag is a half-open SYN scan, -T3 is the default timing template, -p- means all 65535 TCP ports, and -oA writes normal, XML and greppable output at once:

Linux / macOS       sudo nmap -sS -T3 -p- -oA audit/results 192.168.10.0/24
Windows (Admin PS)  nmap -sS -T3 -p- -oA auditresults 192.168.10.0/24

When -sS is unavailable — a locked-down workstation, a container without raw sockets — use the connect scan instead. It completes the full handshake, which is slower, noisier and leaves connection logs on the target:

                  nmap -sT -T3 -p- -oA audit/results 192.168.10.0/24

A full TCP scan of a /24 takes a while, sometimes 20 to 40 minutes at -T3. Do not speed it up to -T4 or -T5 on a production segment just because you are impatient.

How you know it worked: audit/results.xml exists, the live-host list matches the number of devices in your inventory, and any host you expected but did not see gets investigated before you move on.

4. Identify exposed services and scan UDP separately

Scan the interesting hosts again with service, script and OS detection, and read the columns rather than just counting open lines:

                  sudo nmap -sV -sC -O -p- 192.168.10.20
                  sudo nmap -A 192.168.10.20
PORT     STATE SERVICE VERSION
22/tcp   open  ssh     OpenSSH 8.9p1 Ubuntu 3ubuntu2
80/tcp   open  http    nginx 1.18.0
443/tcp  open  ssl/http nginx 1.18.0
445/tcp  open  smb     Samba 4.15.9
8080/tcp filtered http-proxy

State, port number, protocol, service name, version and any OS guess all carry information. A version string lets you check whether that software has known issues; an open|filtered UDP result usually means the host simply did not answer the probe, not that anything is wrong.

UDP is slower and less reliable by design because there is no handshake to reject a closed port. Never start with an exhaustive UDP sweep — pick the services you actually run:

                  sudo nmap -sU --top-ports 50 192.168.10.20
                  sudo nmap -sU -p 53,67,123,161,500,1900,5353 192.168.10.0/24

DNS, DHCP, mDNS, SSDP and SNMP are the ones worth checking on a home network, because misconfiguration there tends to leak more than it hides.

How you know it worked: every open port has a service and version attached, and your UDP pass covered a defined list rather than all 65535 sockets by brute force.

5. Validate unexpected listeners without assuming a vulnerability

An open port is a fact, not a finding. It only becomes a finding once you know what is listening and who was supposed to run it, so correlate each result with your inventory, the running process, the service config and the firewall rules in front of it:

Windows            tasklist /fi "PID eq 1234"
Linux / macOS      ps -p 1234 -f
Linux / macOS      sudo lsof -nP -i :8080
Firewall test      sudo nmap -sA -n 192.168.10.20
Single port        nmap -p 80,443,8080 192.168.10.20
Windows one port   Test-NetConnection -ComputerName 192.168.10.20 -Port 445

Keep the audit non-intrusive. No brute-force attempts, no exploit payloads, no vulnerability scripts that hammer a service — that is penetration testing, and it needs separate written permission and a different mindset.

The -sA ACK scan is useful in one narrow case: it tells you whether a firewall is dropping or rejecting traffic, which changes how you interpret a filtered result.

How you know it worked: every open port maps to either a named, expected service or a written finding with an owner attached.

6. Document risk, ownership, and the next action

Turn results into a worksheet with these columns: target IP, authorization reference, exact scan command, date, Nmap version, source IP, port, protocol, service, evidence, owner, severity, remediation status. Copy-paste the command verbatim — six months later, “we ran something with -sV” is not reproducible evidence.

Prioritise by reachability and privilege, not by port number. An unauthenticated management interface reachable from the whole user network outranks a deliberately exposed HTTPS endpoint every time, even though both read as “open” in the output.

These are the ports worth investigating first on a home or small office network, with the response I would normally reach for:

  • 21 / 23 — FTP / Telnet. Cleartext credentials. Close them and move to SFTP or SSH.
  • 22 — SSH. A remote shell and a constant brute-force target. Restrict it to admin source addresses and use keys.
  • 445 — SMB. The classic lateral-movement path on a Windows network. Restrict it to the hosts that genuinely need it.
  • 3389 — RDP. Remote desktop exposed beyond the desk it sits on. Put it behind a VPN or close it.
  • 3306 / 5432 — MySQL / PostgreSQL. Databases have no business facing a user network. Bind to loopback or an admin VLAN.
  • 8080 — HTTP proxy and admin UIs. Frequently a forgotten admin panel. Find the owner, then restrict or close it.
  • 32400 — Plex. A legitimate media server that is often mapped externally by design. Confirm the mapping is deliberate.
  • 5357 — WSDAPI. Windows network discovery that most networks never use. Block it at the host firewall.

How you know it worked: every port above has an owner and a disposition — close, restrict, or accept with a reason.

7. Remediate exposure and verify the fix

Each finding gets one of three responses. Close it when nothing uses the service. Restrict it when only certain hosts or source networks need it, using host firewall rules or interface binding rather than a wider router exception. Accept it when exposure is deliberate, and write down why so the next audit does not re-litigate it.

Concretely: stop and disable unused services, bind management interfaces to the address that needs them, patch outdated software, narrow firewall rules to required source networks, enable authenticated encryption, and replace default credentials where the product supports it. Moving a service to a nonstandard port is defence in depth, not a fix — it adds a small amount of noise reduction and no access control.

Then repeat the identical scoped scan and diff it against the first one. ndiff, shipped with Nmap, compares two XML scans and prints only what changed:

                  sudo nmap -sS -T3 -p- -oX audit/after 192.168.10.0/24
                  ndiff audit/results.xml audit/after.xml

Keep both files. A before-and-after pair is the only evidence that a control actually changed.

How you know it worked: the re-scan shows the intended state, the diff is empty or explained, and the worksheet rows are marked verified.

Common Mistakes

Scanning without authorization. Even a quick sweep of a subnet you do not own is a problem. Fix: get the written scope before you run anything, and keep the reference in the audit log.

Assuming every open port is a vulnerability. A port is a door, not a breach. Fix: validate against the inventory and the running process before assigning severity.

Running a SYN scan without elevated privileges. Nmap silently falls back and you get a connect scan that is slower and easier to spot. Fix: sudo, an Administrator PowerShell, or grant cap_net_raw for non-root use.

Ignoring UDP. A TCP-only audit misses DNS, mDNS, SNMP and SSDP, which is exactly where home networks leak. Fix: scan a defined list of common UDP ports, not all of them.

Scanning too aggressively. -T4 and -T5 can overwhelm a small switch or an old printer. Fix: stay on -T3, or slow down with --scan-delay.

Treating IPv4 discovery as full coverage. A /24 IPv6 sweep is a different and far larger address space. Fix: enumerate your IPv6 prefix from the router and scope it explicitly, or record IPv6 as out of scope and note it.

Confusing netstat output with a network inventory. Netstat and ss report one host. Fix: use them to confirm individual listeners, and use Nmap discovery for the network-wide view.

Not recording the exact scope. Without the range, date, command and Nmap version, the scan cannot be repeated or defended. Fix: capture those four fields per run.

Declaring success without a second scan. A closed firewall rule on paper is not a closed rule on the wire. Fix: re-scan the same scope and diff.

Two habits worth keeping from the people who do this regularly: build the port audit into a scheduled job so a new listener shows up as a diff rather than a surprise, and check your router’s port-forwarding rules and UPnP settings in the same session, since those are the reason an internal scan can look safe while the service is still reachable from the internet.

Frequently Asked Questions

Does an open port automatically mean my network is vulnerable?

No. An open port means a service accepted a connection, which tells you the software is reachable and nothing more. Most listening services on a home network are intentional and patched. Risk comes from what the service does, which version it runs, whether it needs authentication, and who can reach it. Always correlate a port with the running process and your asset inventory before treating it as a problem.

Why did Nmap miss a device that I know is online?

Discovery uses ICMP echo, TCP SYN and a few UDP probes, and a device can ignore all of them. Firewalls on mobile phones, IoT gear and hardened Linux hosts routinely drop unsolicited probes while working perfectly fine for outbound traffic. The fix is to check the switch neighbor table, the router’s client list or DHCP leases, and to scan that specific address with a full port scan instead of relying on discovery alone.

Is changing a service to a nonstandard port a real security fix?

Not on its own. Moving SSH from 22 to 2222 only removes the noise from automated internet-wide scanning; any attacker who knows the port can still reach the service, and the underlying access control problems remain. It is reasonable defence in depth once authentication, patching and firewall restrictions are in place, but never a substitute for restricting who can connect.

How often should I audit open ports on my network?

Monthly for home and lab networks is a reasonable baseline, and weekly for small offices where devices come and go. Schedule it so you get a diff rather than a fresh wall of output, and always run one immediately after a firewall change, a firmware upgrade or adding a new service. The value of the audit comes from comparing runs, not from any single scan.

What should I do when the scan finds a device I do not recognize?

Do not power it off yet, because you want evidence while it is live. Record the IP, MAC address from the router or switch table, hostname, open ports and any service version strings, then check DHCP leases and purchase records. If nobody claims it, isolate it on the guest or IoT VLAN, and treat it as unauthorized access until proven otherwise.

Conclusion: Start With a Scoped Inventory

Start by confirming authorization, writing down the exact ranges, and exporting your current device list. Run one low-impact TCP discovery pass, then a full port scan with service detection on the hosts you recognise, and check UDP on a short defined list. Finish by giving every unexpected listener an owner, a disposition and a verification scan — because an audit is not done until the re-scan shows the state you intended.

Leave a Comment

Keep reading