Scan and Secure Your Linux Network

Discover devices, capture live traffic, and lock down your Linux machine.

Introduction

30 Second Summary

Every device on your home network is a potential door. Some doors are wide open, some are locked, and some you didn't even know existed. Understanding what's connected and exposed is the first step to keeping your digital life secure.

In this project, you will perform a full security audit of your own Linux machine and local network. You'll discover connected devices, capture live traffic, and build a custom firewall to lock everything down.

What You'll Build

A complete network security audit using three professional-grade Linux tools: Nmap for discovery, tcpdump for traffic capture, and UFW for firewall defense.

By the end of this project, you'll have:

  • Nmap scan results showing all devices and open ports on your local network.
  • A .pcap capture file containing filtered network traffic you captured yourself.
  • A configured UFW firewall with custom allow and deny rules protecting your machine.
  • Secret Mission: Detect and analyze a live port scan using tcpdump.

Are there any prerequisites?

You need a Linux computer with terminal access. This guide covers the full installation of every tool you need, so no prior security experience is required.

Install Your Security Toolkit

Every network security audit starts with the right tools. In this project, you'll use three utilities that cover the fundamentals: one for discovering devices, one for monitoring traffic, and one for blocking unwanted connections.

In this step, you'll install Nmap and tcpdump, confirm that UFW is ready to go, and record your network details for use throughout the project.

In this step, get ready to:
  • Install Nmap and tcpdump and verify they work.
  • Confirm UFW is available and currently inactive.
  • Find your network interface name, local IP address, and subnet.
Install Nmap and tcpdump

These two tools form the offensive half of your toolkit. Nmap discovers devices and open ports on a network. tcpdump captures raw network traffic so you can see exactly what's flowing across the wire.

Using a different Linux distro?

This project uses apt commands, which work on Debian and Ubuntu-based systems. If you're on Fedora or RHEL, replace sudo apt install with sudo dnf install. If you're on Arch, use sudo pacman -S.

  • Install both tools by running this command:
sudo apt update && sudo apt install nmap tcpdump -y

What does this command do?

sudo apt update refreshes your package list so your system knows about the latest available versions.

sudo apt install nmap tcpdump -y installs both packages in one go. The -y flag automatically confirms the installation prompt.

  • You'll see a stream of output as packages download and install. Once it finishes, verify Nmap is installed by running:
nmap --version
  • You should see output starting with Nmap version followed by a version number.
  • Verify tcpdump is installed by running:
tcpdump --version
  • You should see output starting with tcpdump version followed by a version number.

Seeing 'command not found'?

If either version command fails, the installation may not have completed successfully. Run the install command again without -y to see any error messages. Common causes include a typo in the package name or needing to run sudo apt update first.

Help me troubleshoot why nmap or tcpdump didn't install on my Linux system.

Check that UFW is available

UFW (Uncomplicated Firewall) is the defensive side of your toolkit. It provides a simple interface for managing your machine's firewall rules.

On Ubuntu, UFW is pre-installed but disabled by default. On other Debian-based systems it may need to be installed separately.

  • Check if UFW is already on your system by running:
sudo ufw status

✔️ I see 'Status: inactive'

UFW is installed and currently disabled. That's exactly what you want for now. You'll enable it and configure rules in a later step.

ⓧ Command not found

  • Install UFW by running:
sudo apt install ufw -y
  • After it installs, confirm it's working by running:
sudo ufw status

You should now see Status: inactive. This means the firewall is installed but not yet enforcing any rules.

Why is UFW inactive?

UFW ships disabled so it doesn't accidentally block network connections on a fresh system. You'll deliberately enable it in Step 4 after you've set up the rules you need.

Find your network interface and IP address

Before you can scan your network, you need to know your machine's identity on it. Every device on a network has an IP address and connects through a network interface.

  • Display your network interfaces and their addresses by running:
ip addr show

You'll see output listing each network interface on your machine. Here's what to look for:

How do I read this output?

Each interface starts with a number and name like 2: eth0: or 2: enp3s0:. The lo interface is the loopback (your machine talking to itself). Skip it.

Look for the interface that has an inet line with an address like 192.168.1.100/24. The number before the slash is your IP address. The number after the slash (like /24) is the prefix length, which defines your subnet size.

Common interface names include eth0 (wired Ethernet), enp3s0 (predictable naming for wired), and wlan0 or wlp2s0 (wireless).

  • Write down three pieces of information from the output:
  • Your interface name (e.g. eth0, enp3s0, or wlan0).
  • Your local IP address (the number before the slash, e.g. 192.168.1.100).
  • Your subnet in CIDR notation. Replace the last number of your IP with 0 and keep the prefix length. For example, if your IP is 192.168.1.100/24, your subnet is 192.168.1.0/24.

Keep these values handy

You'll use your subnet in the very next step when you scan your entire local network with Nmap. Your interface name will be needed for tcpdump captures in Step 3.

Not seeing an IP address?

If your interface shows state DOWN or has no inet line, it means that interface is not connected. Look for a different interface that shows state UP and has an inet line with a 192.168.x.x or 10.x.x.x address.

Help me find my network interface and IP address from ip addr show output.

Your toolkit is ready and you know your place on the network. Next up, you'll use Nmap to discover every device connected to your local network and see what services they expose.

Discover Your Network with Nmap

Your toolkit is installed and your network details are recorded. Now it is time to put Nmap to work and answer the most fundamental security question: what is on your network, and what is it exposing?

In this step, you will scan your local network to discover every connected device, examine what services your own machine exposes, and probe a remote server to see how version detection reveals software running behind open ports.

In this step, get ready to:
  • Discover all live devices on your local network with a ping sweep.
  • Scan your own machine for open ports and interpret the results.
  • Run a version detection scan against a remote test server.
Run a ping sweep to discover live devices

A ping sweep sends lightweight probes to every address in a subnet and reports which ones respond. It answers the question: how many devices are connected to my network right now?

  • Discover all live devices on your local subnet by running this command:
sudo nmap -sn [[SUBNET="your subnet from Step 1, e.g. 192.168.1.0/24"]]

What does this command do?

  • sudo runs the command with root privileges, which allows Nmap to send raw packets and use ARP discovery on your local network.
  • -sn tells Nmap to perform host discovery only. It skips port scanning entirely, so the sweep finishes quickly.
  • The subnet (e.g. 192.168.1.0/24) defines the range of 256 IP addresses to probe.

On a local network, Nmap uses ARP requests for discovery. ARP is faster and more reliable than ICMP pings because devices on the same network segment must respond to ARP.

The scan takes a few seconds. You should see output listing each discovered host with a line like:

Nmap scan report for 192.168.1.1 followed by Host is up and a latency value.

  • Count how many hosts were reported as up. Note down at least 2-3 IP addresses from the results.
  • Look at the final summary line. It shows the total number of addresses scanned and how many responded.

What are these devices?

Common devices you will see include your router (often ending in .1), your own machine, and any phones, tablets, smart TVs, or IoT devices connected to the same network. Each one is a potential entry point that an attacker could target.

Only seeing one host?

Make sure you used sudo before the command. Without root privileges, Nmap falls back to a less reliable discovery method on local networks.

Double-check that the subnet matches what you recorded in Step 1. If your IP is 192.168.0.5, your subnet is 192.168.0.0/24, not 192.168.1.0/24.

help me troubleshoot my Nmap ping sweep

Scan your own machine for open ports

Now that you know what devices exist, the next question is: what services is each device exposing? A port scan checks the top 1000 TCP ports on a target and reports which ones are accepting connections.

  • Scan your own machine (localhost) by running:
nmap 127.0.0.1

What does this command do?

Running nmap with just a target address performs a default TCP port scan against the top 1000 most common ports. You do not need sudo for a localhost scan because the packets never leave your machine.

The address 127.0.0.1 is the loopback address that always points to your own machine.

Nmap prints a table with three columns: PORT, STATE, and SERVICE. Each row represents one of the top 1000 ports that was not in the default state.

  • Look at the STATE column for each port. You will see one of three values:
  • open means a service is actively listening on that port and accepting connections.
  • closed means no service is listening, but the port is accessible (it responded with a reset packet).
  • filtered means a firewall or filter is blocking access. Nmap cannot tell if the port is open or closed.

What is a port?

A port is a numbered endpoint on a machine that a specific service listens on. Port 22 is typically SSH. Port 80 is HTTP. Port 443 is HTTPS. When a port is "open," it means software is actively waiting for connections there.

On a personal machine, you may see very few open ports. That is normal. Servers typically expose more ports because they run more services.

Seeing 'All 1000 scanned ports are closed'?

This means no services are listening on the common ports. That is actually a good security posture for a personal workstation. Your scan still worked correctly. You will see a contrast when you scan the remote server in the next substep.

help me understand my Nmap localhost scan results

Scan a remote server with version detection

The Nmap project provides a test server specifically for practice scanning. You will scan it with version detection enabled, which probes each open port to identify the exact software and version number behind it.

Why scanme.nmap.org?

Scanning machines you do not own is illegal in many jurisdictions. The Nmap project explicitly grants permission to scan scanme.nmap.org for testing purposes. Limit yourself to a few scans per day as the site requests.

  • Run a version detection scan against the Nmap test server:
nmap -sV scanme.nmap.org

What does this command do?

  • -sV enables version detection. After finding open ports, Nmap sends additional probes to identify the specific software and version running on each one.
  • scanme.nmap.org is the target hostname. Nmap resolves it to an IP address automatically.

This scan takes longer than a basic scan because Nmap connects to each open port and analyzes the responses to fingerprint the service.

You should see a table with four columns: PORT, STATE, SERVICE, and VERSION. The VERSION column now shows exact software names and version numbers.

  • Compare this output to your localhost scan. Notice how the remote server has more open ports with identified services.
  • Note the service names and versions for each open port. This is exactly the information an attacker would use to search for known vulnerabilities.

Why does version detection matter?

Knowing a server runs a specific software version lets you check public vulnerability databases for known exploits. For example, an outdated version of OpenSSH or Apache might have published CVEs that give an attacker a clear path in.

This is why keeping software updated is one of the most basic defenses. Version detection shows you exactly where you stand.

Scan taking a very long time?

Version detection on filtered ports can be slow because Nmap waits for timeout responses. If the scan exceeds 2-3 minutes, press Ctrl+C and try again. Network conditions to the remote server may vary.

help me with a slow Nmap version detection scan

You now have a complete picture of your network. You know what devices are connected, what ports your machine exposes, and how to identify exact software versions on remote servers. Next up, you will learn to watch live traffic flowing across the wire using tcpdump.

Capture Live Traffic with tcpdump

You've mapped your network with Nmap and know exactly which devices are connected and what ports they expose. That covers the "discover" part of network security.

Knowing what's on your network is one thing. Knowing what those devices are actually saying to each other is something else entirely. In this step, you'll use tcpdump to intercept live network packets as they flow across your interface, filter for specific traffic, and save captures to disk for later analysis.

In this step, get ready to:
  • Run a live packet capture and understand the output format.
  • Filter traffic by protocol, port, and host.
  • Save a capture to a .pcap file for later analysis.
List your interfaces and start a basic capture

Packet capture means intercepting and recording the raw data flowing through your network interface. Every time your machine sends or receives data, it travels as discrete packets. tcpdump lets you see each one in real time.

  • Confirm which network interfaces tcpdump can see by running this command:
sudo tcpdump -D

What does this command do?

The -D flag lists all network interfaces available for capture. You should see your primary interface (the one you recorded in Step 1) in the list, along with a loopback interface and possibly others.

Now you'll start an actual packet capture. tcpdump requires sudo because intercepting network traffic requires root privileges to open a raw socket.

  • Start a live capture on your primary interface by running this command:
sudo tcpdump -i [[INTERFACE="your network interface (e.g. eth0)"]] -nn

What do these flags do?

  • -i specifies which network interface to listen on.
  • -nn tells tcpdump to show raw IP addresses and port numbers instead of resolving them to hostnames and service names. This makes the output faster and easier to read.

You should see packets scrolling across your terminal in real time. Each line represents one packet flowing through your interface.

  • Watch the output for about 10 seconds, then press Ctrl+C to stop the capture.

How do I read the output?

Each line of tcpdump output follows this format:

timestamp protocol source > destination: flags

  • Timestamp shows hours, minutes, seconds, and fractions of a second.
  • Protocol tells you the type of traffic (IP for most TCP/UDP traffic).
  • Source is the IP address and port that sent the packet.
  • Destination is where the packet is heading.
  • Flags indicate what the packet is doing (e.g., S for SYN, . for ACK, P for PUSH).

Not seeing any output?

If nothing appears, your machine might have very little background traffic. Try opening a web browser or pinging a website from another terminal window to generate some packets.

If you see a permission error, make sure you included sudo at the start of the command.

help me troubleshoot why tcpdump is not showing any captured packets

Filter captures by protocol, port, and host

A raw capture shows everything flowing across the wire. In practice, you'll want to focus on specific types of traffic. tcpdump supports filters that let you zero in on exactly what you're looking for.

You'll need two terminal windows for this section. One runs tcpdump to watch for packets, and the other generates traffic for tcpdump to catch.

  • Open a second terminal window or tab.
  • In your first terminal, start a capture filtered to only ICMP packets (the protocol used by ping) by running:
sudo tcpdump -n icmp
  • Switch to your second terminal and generate ICMP traffic by running:
ping -c 4 8.8.8.8
  • Switch back to your first terminal. You should see the ICMP echo requests and replies captured in real time.
  • Press Ctrl+C to stop the capture.

What is ICMP?

ICMP (Internet Control Message Protocol) is the protocol behind ping and traceroute. It carries network diagnostic messages rather than application data. Filtering to icmp hides all the TCP and UDP noise and shows only these diagnostic packets.

Next, you'll filter by port number to watch web traffic specifically.

  • In your first terminal, start a capture filtered to port 443 (HTTPS traffic) by running:
sudo tcpdump -n port 443
  • In your second terminal, generate HTTPS traffic by running:
curl https://example.com
  • Switch back to your first terminal. You should see packets flowing between your IP and the example.com server.
  • Press Ctrl+C to stop the capture.

Finally, you'll filter by a specific host IP address. This catches all traffic to or from that host, regardless of protocol or port.

  • In your first terminal, start a capture filtered to traffic involving 8.8.8.8 (Google's public DNS server) by running:
sudo tcpdump -n 'host 8.8.8.8'
  • In your second terminal, generate traffic to that host by running:
ping -c 4 8.8.8.8
  • Switch back to your first terminal to see the captured packets, then press Ctrl+C to stop.

What's the difference between these filters?

  • Protocol filters (icmp) match packets by their network protocol.
  • Port filters (port 443) match packets going to or from a specific service port number.
  • Host filters (host 8.8.8.8) match all packets involving a specific IP address, regardless of port or protocol.

You can combine these filters for even more precise captures. For now, each individual filter gives you powerful control over what you see.

Not seeing filtered packets?

Make sure you're generating the right type of traffic in your second terminal. An ICMP filter only shows ping traffic. A port 443 filter only shows HTTPS traffic.

If you see 0 packets captured after stopping, confirm both terminals are on the same machine and that your traffic-generating command completed successfully.

help me figure out why my tcpdump filter isn't catching any packets

Save a capture to a .pcap file

Watching live traffic is useful for quick checks, but for real analysis you need to save captures to disk. The .pcap file format stores raw packet data that you can analyze later or open in tools like Wireshark.

  • In your first terminal, start a filtered capture that saves directly to a file by running:
sudo tcpdump -n -c 10 -w ~/capture.pcap port 443

What do these flags do?

  • -c 10 stops the capture automatically after 10 packets. This prevents the file from growing indefinitely.
  • -w ~/capture.pcap writes raw packet data to a file instead of printing it to the terminal.
  • port 443 filters to only HTTPS traffic so your file contains focused, relevant data.
  • In your second terminal, generate HTTPS traffic so tcpdump has something to capture:
curl https://example.com

Once 10 packets are captured, tcpdump stops automatically and you'll see a summary line showing how many packets were captured and saved.

  • Verify your saved file by reading it back with this command:
tcpdump -r ~/capture.pcap

You should see the same packet data printed to your terminal, read from the saved file instead of a live interface. Notice that this command doesn't need sudo because reading a file doesn't require raw socket access.

  • Confirm the file exists on disk by running:
ls ~/capture.pcap

You should see capture.pcap listed in the output.

Seeing 'Permission denied' or an empty file?

If the file wasn't created, make sure you included sudo in the capture command. Without root access, tcpdump can't open the network interface.

If the file exists but tcpdump -r shows 0 packets, the capture stopped before any matching traffic arrived. Run the capture command again and generate traffic more quickly in your second terminal.

help me troubleshoot why my tcpdump pcap file is empty or wasn't created

You can now intercept, filter, and record network traffic on demand. Next up, you'll use UFW to build a firewall that controls which traffic is allowed to reach your machine in the first place.

Lock Down Your Machine with UFW

You now know what's on your network and what traffic looks like on the wire. The final piece of the security triad is defense.

A firewall controls which traffic is allowed into and out of your machine. Without one, every open port you discovered in your Nmap scan is an invitation for anyone on the network. In this step, you will activate UFW and build a ruleset that lets only the traffic you approve through the door.

In this step, get ready to:
  • Set a default deny policy and enable UFW.
  • Add allow rules for SSH, HTTP, and HTTPS traffic.
  • Verify the firewall's effect by scanning your machine with Nmap again.
Set the default deny policy and enable UFW

A default deny policy means all incoming connections are blocked unless you explicitly allow them. This is the safest starting point for any firewall configuration.

  • Set UFW's default policy to deny all incoming traffic by running this command:
sudo ufw default deny incoming

What does this command do?

This tells UFW to block every incoming connection by default. Any traffic not matched by a specific allow rule will be silently dropped.

Outgoing traffic (requests your machine makes to the internet) is still allowed. Only unsolicited incoming connections are blocked.

  • Enable the firewall by running:
sudo ufw enable
  • UFW will ask you to confirm. Type y and press Enter to proceed.

Why confirm?

UFW warns you because enabling a firewall can interrupt existing SSH connections on remote servers. Since you are working on your own local machine, this is safe to confirm.

  • Check the status to confirm the firewall is active by running:
sudo ufw status verbose
  • You should see Status: active and Default: deny (incoming), allow (outgoing) in the output.

Still seeing Status: inactive?

Make sure you typed y when prompted to confirm. If you accidentally declined, run sudo ufw enable again and confirm with y.

If you see a permission error, make sure you are using sudo before the command.

Help me troubleshoot UFW not activating on my machine.

Add allow rules for SSH, HTTP, and HTTPS

Your firewall is now blocking everything incoming. You need to punch holes for the traffic you actually want to receive.

  • Allow SSH connections (port 22) so you can still access your machine remotely by running:
sudo ufw allow 22

Why allow SSH?

Port 22 is used by SSH (Secure Shell) for remote terminal access. If you ever need to manage this machine from another computer, SSH is how you connect. Blocking it could lock you out of remote access entirely.

  • Allow HTTP traffic (port 80) by running:
sudo ufw allow 80
  • Allow HTTPS traffic (port 443) by running:
sudo ufw allow 443

Why allow ports 80 and 443?

Port 80 handles HTTP traffic and port 443 handles HTTPS traffic. These are the standard web ports. Allowing them means if you run a web server on this machine, outside clients can reach it.

  • View your complete numbered rules list by running:
sudo ufw status numbered
  • You should see numbered rules for ports 22, 80, and 443, each showing ALLOW IN and Anywhere as the source.

Not seeing all three rules?

Run each allow command again. UFW will tell you if a rule already exists, so there is no harm in re-running the commands.

Check for typos in the port numbers. Each command should use a plain number (22, 80, 443) with no slash or protocol suffix.

Help me figure out why my UFW rules are not appearing correctly.

Verify the firewall with a second Nmap scan

Now you can prove that the firewall is actually doing something. You will scan your own machine with Nmap again and compare the results to what you saw before UFW was active.

  • Run an Nmap port scan against localhost by running:
nmap 127.0.0.1

What should I see?

Compare this output to your earlier localhost scan from Step 2. Ports that were previously open may now show as filtered (blocked by the firewall). Ports you explicitly allowed (22, 80, 443) will still appear open if a service is listening on them.

The key difference is that ports without a running service behind them are now invisible to outside scanners, rather than responding with a "closed" message.

  • Add a deny rule for a specific port to test blocking. Deny traffic on port 8080 by running:
sudo ufw deny 8080
  • Confirm the deny rule was added by running:
sudo ufw status numbered
  • You should see your new deny rule for port 8080 listed alongside your allow rules, showing DENY IN for that port.

What is the difference between default deny and an explicit deny rule?

The default deny policy silently drops any traffic not matched by a rule. An explicit deny rule lets you specifically block a port and see it listed in your ruleset. This is useful for documentation purposes and for overriding allow rules that might be broader.

Nmap results look the same as before?

Scanning from localhost (127.0.0.1) may bypass some firewall rules because the traffic never leaves the machine. UFW primarily filters traffic on network interfaces. The key thing to verify is that sudo ufw status numbered shows your rules correctly.

If your status output looks correct, your firewall is working. External machines scanning your IP will see the filtered ports.

Help me understand why my Nmap scan looks the same after enabling UFW.

Your machine is now protected by a working firewall. You have discovered your network, monitored its traffic, and locked it down. Next up in the Secret Mission, you will combine your offensive and defensive skills to detect a live port scan in real time.

Secret mission

Detect a Port Scan with tcpdump

Ready to play both attacker and defender at the same time? In this bonus challenge, you will launch a port scan against your own machine while simultaneously watching it happen in real time from the defender's perspective. This is exactly how a security analyst detects malicious reconnaissance on a network.

Clean Up Your Resources

Clean Up Your Resources

This project runs entirely on your local Linux machine, so there are no ongoing cloud costs. Decide whether to keep your tools and firewall active, pause protection temporarily, or remove everything.

Resources you used:

  • Nmap (network scanner, installed via apt).
  • tcpdump (packet capture tool, installed via apt).
  • UFW firewall (active with custom allow/deny rules).
  • capture.pcap file (filtered packet capture).
  • port-scan-detected.pcap file (SYN scan capture from the Secret Mission).

Keep everything running

No action needed. Choose this if you want your firewall to keep protecting your machine and your tools ready for future network exploration.

  • UFW stays active with your custom rules, blocking unauthorized incoming traffic.
  • Nmap and tcpdump remain installed for future security audits.
  • Your capture.pcap and port-scan-detected.pcap files stay on disk for review or analysis in other tools.

Pause - I'll come back to this later

Disable your firewall to return to the default open state. Your rules are preserved and can be re-enabled later.

  • Disable UFW by running:
sudo ufw disable

Your firewall rules are saved. Run sudo ufw enable any time to reactivate them.

  • Nmap and tcpdump remain installed but use no resources when idle.
  • Your .pcap files stay on disk for future reference.

Delete - I don't want to use this again

Remove all project tools and files to start fresh.

  • Disable UFW and reset all rules to defaults by running:
sudo ufw disable
sudo ufw --force reset
  • Remove Nmap and tcpdump by running:
sudo apt remove nmap tcpdump -y
  • Delete your .pcap capture files by running:
rm capture.pcap port-scan-detected.pcap

After these commands, your machine is back to its pre-project state with no firewall rules, no scanning tools, and no capture files.

Nice Work!

Nice Work!

You just completed a full network security audit of your own machine and local network. You now have the skills to discover, monitor, and defend any network you manage.

You've learned how to:

  • Discovered all devices on your local network and identified open ports and running services using Nmap ping sweeps and version detection scans.
  • Captured and filtered live network traffic with tcpdump, saving packets to .pcap files for later analysis.
  • Built a custom UFW firewall with a default deny policy and targeted allow rules to harden your machine against unwanted connections.
  • Secret Mission: Detected a simulated port scan in real time by watching SYN packets flood your tcpdump capture, then verified your firewall blocked the probes.

Ready to quiz yourself?