💡

Before you start

You need a Linux machine (or WSL on Windows) and a terminal. The main tool, ss, is part of iproute2 and is already installed on every modern Linux — check with ss --version. One optional step uses tcpdump to look at raw packets; that one needs sudo, and the step says so plainly. Everything else is read-only and needs no special rights.

You will start a small listener of your own to watch, so nothing here depends on what happens to be running on your machine, and nothing you do changes a single setting.

Why Monitor Your Network?

Network monitoring helps you detect problems before they become serious: unauthorized devices, bandwidth hogs, suspicious connections, or services that have stopped responding. Even basic monitoring gives you visibility into what is happening on your network.

Essential Tools: ping and traceroute

ping

Tests whether a host is reachable and measures round-trip time:

# Ping a host (Ctrl+C to stop on Linux)
ping 1.1.1.1

# Send only 4 pings
ping -c 4 google.com

What to look for:

Response time: Under 50ms is good for most connections
Packet loss: Any loss above 0% indicates a problem
"Request timed out": The host is unreachable or blocking pings

traceroute (Linux) / tracert (Windows)

Shows the path packets take to reach a destination:

# Linux
traceroute google.com

# Windows
tracert google.com

Each line shows a "hop" (router) along the path. Useful for identifying where a connection problem occurs.

Checking Open Ports

Using ss (Linux)

# Show all listening ports
ss -tlnp

# Show all active connections
ss -tnp

-t TCP connections

-l Listening (waiting for connections)

-n Show port numbers (not service names)

-p Show the process using the port

Using netstat (Windows)

# Show all listening ports with process IDs
netstat -ano | findstr LISTENING

# Show all active connections
netstat -ano

💡

Unexpected open ports?

If you see ports you do not recognize, investigate the process using them. Unexpected listeners could indicate malware or misconfigured services.

Bandwidth Monitoring

iftop (Linux)

A real-time bandwidth monitor for Linux:

sudo apt install iftop
sudo iftop -i eth0

Shows which connections are using bandwidth in real time, sorted by usage.

Resource Monitor (Windows)

Press Ctrl + Shift + Esc to open Task Manager, then click "Open Resource Monitor." The Network tab shows per-process bandwidth usage.

Detecting Unusual Traffic

Signs that something may be wrong on your network:

Unexpected outbound connections to unknown IP addresses
High bandwidth usage when no one is actively using the network
New devices appearing in your router's connected device list
DNS queries to suspicious or unfamiliar domains
Connections on unusual ports (especially high-numbered ports)

If you detect suspicious activity:

Identify the source device and process
Run an antivirus scan on the suspected device
Change WiFi and router passwords if unauthorized devices are found
Review firewall rules for gaps

Now Do It Yourself: Watch Your Own Network in Five Steps

You cannot secure what you cannot see. In five steps you will list every open door on your machine, tie a mysterious port back to the exact program that opened it, take a one-line snapshot of all your connections, watch the actual packets of a single connection fly past, and learn the one field that tells you whether a service is exposed to the whole network or only to yourself. Every command below is real; the ss output was captured by running it.

List every open door: what is listening

Go: open a terminal.

Do: run ss -tlnp — t for TCP, l for listening, n for numeric ports, p for the owning process.

ss -tlnp

You should see: one row per service waiting for connections, like these:

State  Recv-Q Send-Q Local Address:Port  Peer Address:Port
LISTEN 0      80         127.0.0.1:3306       0.0.0.0:*
LISTEN 0      4096   127.0.0.53%lo:53         0.0.0.0:*

Each is a way in. 127.0.0.1:3306 is a database reachable only from this machine; :53 is DNS. If a row lists a port you cannot explain, that is exactly what you want to investigate — step 2.

If not: ss: command not found is rare, but on a minimal system install it with sudo apt install iproute2. Without -p you still get the ports but not the process names — on some systems the process column is only filled in when you add sudo, because reading another user’s process needs privilege.

Tie a mysterious port back to the program that opened it

Go: the same terminal. First give yourself a known listener to find.

Do: start a throwaway listener on port 9000 in one command, leave it running, and in the same terminal look for it. (Press Ctrl+C to stop it when done.)

python3 -c "import socket,time; s=socket.socket(); s.bind(('127.0.0.1',9000)); s.listen(); print('listening on 9000'); time.sleep(120)" &
ss -tlnp | grep 9000

You should see: the port tied to the exact process and its PID — this is how you turn “what is on port 9000?” into “kill that process”:

LISTEN 0  5  127.0.0.1:9000  0.0.0.0:*  users:(("python3",pid=391092,fd=3))

The PID will differ on your machine. The lesson is the users:(("python3",pid=…)) field: every listening port belongs to a process you can name, inspect (ps -p PID), and stop.

If not: if grep prints nothing, the listener did not start — look for listening on 9000 in the scrollback. If port 9000 was already taken you get Address already in use; pick another number like 9001 in both places.

Take a one-line snapshot of all your connections

Go: same terminal.

Do: run ss -s for a summary of every socket, grouped by state and protocol.

ss -s

You should see: totals like these — the number that matters day to day is estab, the count of connections that are actually established right now:

Total: 1267
TCP:   67 (estab 51, closed 2, orphaned 0, timewait 2)

Watch this number over time and you learn what “normal” looks like for your machine. A sudden jump in estab with no reason is worth a second look.

If not: the totals will be far smaller on a quiet desktop than on a server — there is no “right” number, only your baseline and changes from it.

Watch the actual packets of one connection (optional; needs sudo)

Go: same terminal, with the port-9000 listener from step 2 still running. This step reads raw packets, which needs administrator rights — that is why it uses sudo.

Do: start a capture limited to eight packets on the loopback interface, then in another terminal connect to the listener with curl -s localhost:9000 (or nc localhost 9000).

sudo tcpdump -i lo -n -c 8 tcp port 9000

You should see: the TCP three-way handshake that opens every connection — a [S] (SYN), a [S.] (SYN-ACK) back, then a [.] (ACK). The sequence numbers and timestamps will be different every time; the flag sequence is the constant to recognise:

IP 127.0.0.1.53930 > 127.0.0.1.9000: Flags [S],  ...
IP 127.0.0.1.9000 > 127.0.0.1.53930: Flags [S.], ...
IP 127.0.0.1.53930 > 127.0.0.1.9000: Flags [.],  ...

Those three lines are a connection being born. A [P.] later carries data; an [F.] closes it. This is what tools like Wireshark show with a graphical face on top.

If not: tcpdump: ... Operation not permitted means you left off sudo. If it just sits there printing nothing, no traffic is hitting port 9000 yet — make the curl/nc connection in the other terminal to produce the packets.

Learn the field that says “exposed” or “local only”

Go: back to the ss -tlnp output from step 1.

Do: read the Local Address of each listening row and sort them in your head into two buckets by what comes before the colon.

ss -tlnp | awk 'NR==1 || /LISTEN/ {print $4}'

You should see: addresses that begin either with 127.0.0.1 (or [::1]) or with 0.0.0.0 (or *). That prefix is the whole security story of a listening port:

127.0.0.1:3306   -> local only: nothing off this machine can reach it
0.0.0.0:8080     -> every network interface: the internet may reach it

A database or admin panel bound to 0.0.0.0 when it only needed to be local is one of the most common real-world exposures. If you find one, that is a finding worth fixing — bind it to 127.0.0.1 or put a firewall in front of it.

If not: if every address is 127.0.0.1, good — nothing is exposed beyond this machine. A LAN address like 192.168.x.x means reachable from your local network but not the wider internet.

🎉

Check yourself before moving on

Without scrolling up: ss -tlnp shows LISTEN 0 128 0.0.0.0:6379 and you did not knowingly expose anything on port 6379. Two questions: is it reachable from outside this machine, and how do you find out what opened it? Answer: yes — 0.0.0.0 means all interfaces, so it is reachable from the network. Add -p (with sudo if needed) and read the users:(("…",pid=…)) field to name the process; port 6379 is Redis, which should almost always be bound to 127.0.0.1, not 0.0.0.0.

Now do it without the page: run ss -tlnp on a machine you own and write down, for every listening port, which process owns it and whether its address is local-only or exposed. Any port you cannot explain is your next investigation.

Summary

In this tutorial, you learned:

Essential tools: ping, traceroute, ss/netstat
How to check for open ports and identify processes
Monitoring bandwidth with iftop and Resource Monitor
Signs of unusual network activity and how to respond

🎉

You can now see what is happening on your network!

Regular monitoring helps you catch problems early. Consider checking your network at least once a month for unexpected changes.

Network Monitoring Basics