The ARP Cache Is a Free Network Map — And Anyone Inside Your LAN Already Has It

I want you to try something. Open a terminal on whatever computer you're reading this on, type arp -an, and hit enter.

What you'll see is a list of every device your machine has talked to recently — by IP address and MAC address. On my laptop just now, that list had 59 hosts in it. My phone. My partner's phone. Three smart speakers. The printer. The TV. A handful of servers. The router. A Hue bridge. Two devices I don't immediately recognize. All of it.

That output took less than a tenth of a second to produce. It required no special privileges, no scanning, no probing. The information was already sitting there, cached, because that's what the ARP cache is — a list of "stuff I've seen on this network." Every operating system on every device on your LAN maintains one. Mine. Yours. The cheap IoT thermostat plugged in by the front door.

That's the uncomfortable part. One compromised device hands an attacker the map of every other device on the network, free, in milliseconds, with no noise. They don't need to scan. They don't need to provoke your router's IDS. They just read what's already there.

This article walks through exactly how that map gets used, and then — more importantly — how to make sure no compromised app on your machine can actually act on it.

The five-second LAN census

I'll show you what I did on my own network earlier today. None of this is exotic; it's all standard, well-documented tooling. The point isn't the technique. The point is how easy and quiet it is.

Step 1: read the ARP cache. Already there for the taking.

On macOS and Linux:

arp -an | grep "192.168.1"

On Windows in PowerShell:

arp -a | Select-String "192\.168\.1"

Either way you'll see something like:

1192.168.1.1   at 50:eb:71:xx:xx:xx on en0 ifscope [ethernet]
2192.168.1.14  at 00:00:aa:xx:xx:xx on en0 ifscope [ethernet]
3192.168.1.20  at b8:27:eb:xx:xx:xx on en0 ifscope [ethernet]
4... 56 more rows ...

That's instant. No packets sent. If the cache is stale, refresh it with a ping sweep.

On macOS and Linux:

for i in $(seq 1 254); do ping -c1 -t1 192.168.1.$i >/dev/null & done; wait

On Windows in PowerShell:

11..254 | ForEach-Object -Parallel {
2    Test-Connection -Count 1 -Quiet -TimeoutSeconds 1 "192.168.1.$_"
3} -ThrottleLimit 50 | Out-Null

That's noisy on the wire — but it's ICMP, which most home networks don't log, and you only have to do it once.

Step 2: scan ports. Now I know every IP that's alive. A short Python script with parallel TCP connects identifies what's listening on each — same code runs on macOS, Linux, and Windows:

1import socket
2from concurrent.futures import ThreadPoolExecutor
3
4PORTS = [22, 53, 80, 443, 3000, 8080, 8443, 9000, 9443, 11434, 32400]
5def open_port(host, port):
6    try:
7        with socket.socket() as s:
8            s.settimeout(0.5)
9            return s.connect_ex((host, port)) == 0
10    except: return False

If you'd rather stay in PowerShell, the built-in Test-NetConnection does the same job at one port at a time:

1$ports = @(22,53,80,443,3000,8080,8443,9000,9443,11434,32400)
2$hosts = 1..254 | ForEach-Object { "192.168.1.$_" }
3$hosts | ForEach-Object -Parallel {
4    $h = $_
5    $using:ports | ForEach-Object {
6        $p = $_
7        if (Test-NetConnection -ComputerName $h -Port $p -InformationLevel Quiet -WarningAction SilentlyContinue) {
8            "$h`:$p open"
9        }
10    }
11} -ThrottleLimit 40

Total runtime against 59 hosts × ~40 ports each: about 20 seconds. Nothing in the logs anywhere unless you're running an IDS specifically watching for connection bursts. Most home networks aren't.

Step 3: identify services. For every open HTTP/HTTPS port, fetch the title and Server: header.

On macOS and Linux:

curl -sIk https://192.168.1.20:9443 | grep -i 'title\|server'
curl -sk https://192.168.1.20:9443 | grep -oE '<title>[^<]+'

On Windows in PowerShell:

1$r = Invoke-WebRequest -SkipCertificateCheck -Uri "https://192.168.1.20:9443"
2$r.Headers["Server"]
3if ($r.Content -match '<title[^>]*>([^<]+)') { $Matches[1] }

Either way the response tells you the service name on that port — e.g. <title>Portainer</title>.

In about thirty seconds total, from a single laptop, with no admin rights and no special tools, I now know:

• where the Portainer instances are (and that one's running Business Edition)
• where the LLM inference endpoints are (Ollama leaks its existence at :11434)
• where the Plex server is, where the printer is, where the Hue bridge is
• where the honeypot is (and crucially, where it isn't — so I can avoid it)
• which boxes have SSH open (and probably weak keys somewhere)
• which boxes have stale services that haven't been updated in months (thttpd/2.25b 29dec2003 — that's a 2003 web server still running on my LAN)

That's the map. Now imagine I'm not me. Imagine I'm an attacker who got code execution through a malicious npm package, a poisoned VS Code extension, a fake Zoom installer, a compromised browser plugin. I am now sitting on a laptop with the same network access. The first thing I do is run those three commands and the second thing I do is start hitting the services that look interesting.

Why your edge firewall doesn't help

Most people, when they think about network security, think about the firewall on their router or modem. That firewall does exactly one job well: it stops connections originating from the internet from reaching your devices. Inbound. Outside-in.

It does nothing about traffic that originates inside your LAN. As far as the router is concerned, two devices on the same subnet talking to each other are just having a private conversation it doesn't need to inspect. That's by design — your laptop printing to your printer shouldn't have to traverse a firewall.

But it also means that once a single device inside the LAN is compromised, the attacker has a free pass to talk to every other device. The whole concept of "perimeter security" collapses the moment something hostile is already past the perimeter, and there are dozens of ways for something hostile to get past the perimeter: browser-based exploits, supply-chain attacks via package managers, malicious browser extensions, USB drives, phished credentials on a single device.

"Castles fall not because the walls are weak, but because someone inside opens the gate." — every successful network intrusion of the last twenty years, in one sentence.

The fix nobody talks about: outbound, per-app firewalls

The single most effective thing you can do is install an application-aware outbound firewall on each of your endpoints. These tools intercept every outgoing connection from every process and ask: should this process really be talking to that address? The first time Chrome wants to reach Google, you allow it. The first time some weird helper binary you've never heard of wants to reach a random IP on port 9443, you deny it — and now lateral scanning is dead.

Properly configured, these tools turn the discovery I demonstrated above from "thirty seconds and silent" into "instant alert and blocked at the first probe." It's the difference between an attacker who owns your laptop and an attacker who owns your laptop and your entire LAN.

Here are the tools worth knowing about, by platform. Free and open source first.

macOS

• Lulu — by Patrick Wardle / Objective-See. Free, open source, beautifully simple. Lets you allow or deny per-process outbound connections with one click. This is what I run.
• Little Snitch — paid, but the gold standard of macOS network monitors. Same idea as Lulu, with a much richer UI and traffic visualization.

Linux

• OpenSnitch — basically Little Snitch for Linux. Per-process outbound rules with a friendly GUI. Free and open source.
• Portmaster — by Safing. Cross-platform with Linux, Windows, and a beta on macOS. Open source. Adds a DNS-level blocklist on top of process-level outbound filtering, which is a fantastic combination.

Windows

• simplewall — free, open source, lightweight wrapper around the Windows Filtering Platform. No telemetry, no nag screens, just a clean app-level firewall.
• Portmaster — same project as above. Strong choice if you want consistent tooling across Linux and Windows.
• GlassWire — paid, more polished, with traffic graphs and bandwidth monitoring. Useful if you want eye-candy alongside the rules.

These tools all share the same pattern: prompt on first connection, remember your decision, build a rule database over time. The first week is mildly annoying as you teach the firewall which apps are legitimate. After that it's silent, and you're protected against the entire class of attacks where a compromised process tries to talk to something it has no business talking to.

Bonus mitigations (worth your weekend)

A few additional moves, in roughly decreasing order of impact:

• Put IoT devices on a separate VLAN. See callout above. The blast radius of a compromised smart speaker drops from "your whole LAN" to "the IoT VLAN and nothing else."
• Stop reusing SSH keys. Lateral movement from a compromised laptop is supercharged by SSH keys that can log into every server on the LAN. Use a different key per server, or at minimum a hardware-backed key (YubiKey, Secure Enclave) so the private material can't be exfiltrated from the laptop's disk.
• Patch the old web servers. That thttpd/2.25b from 2003 sitting on one of your devices? Find it. Update it or kill it. Even unauthenticated, those have a long history of memory-corruption bugs.
• Audit mDNS and Bonjour broadcast. Apple devices broadcast their hostname, model, services, and sometimes user names via mDNS — that's how AirDrop and AirPlay find each other. It's also how a passive observer on the LAN learns "this is Lee's MacBook Pro running such-and-such service." Most operating systems let you opt out per-interface.
• Disable Wi-Fi broadcasting in public. Your laptop probably broadcasts the SSIDs of every Wi-Fi network it remembers. Anyone in coffee-shop range knows where you live, work, and travel. macOS has been moving toward MAC randomization for this reason; check your settings.

Try the demo on yourself right now

If you take one thing away from this article, let it be this: the network map already exists, on every device you own, and you have not been the only one looking at it.

Open a terminal. Dump the ARP cache (arp -an on macOS or Linux, arp -a in Windows PowerShell). Count the rows.

Pick one row that doesn't look familiar. Probe whatever's on the other end — curl -m 3 http://<that-ip> on macOS or Linux, Invoke-WebRequest -SkipCertificateCheck "http://<that-ip>" in PowerShell. You might find a forgotten Raspberry Pi project. You might find a smart plug shipping data to a vendor in another hemisphere. You might find your own old hardware running firmware that hasn't been touched since the year your kid was born.

You're going to be uncomfortable for an hour. That hour pays for itself.

After that hour: install one of the per-app firewalls above. Spend a weekend teaching it which of your apps are legitimate. Sleep better afterward.

The ARP cache shows you the first part for free. The firewall above takes care of the second part — for free, on every platform that matters. Both halves are within reach of anyone who can open a terminal.

Schedule that audit before you close this tab. The reason most home networks stay quietly compromised for years isn't that the operator never installed a firewall — it's that nobody ever re-checked. Half an hour twice a year, on a calendar, is the difference between a network you actually trust and a network you only wish you did.