Kali Linux, Firewalls, and Security Testing

Add Kali Linux to your home lab and lock down servers with host-based firewalls.

Introduction

30 Second Summary

You lock your front door every night without thinking twice. But right now, your lab servers are sitting on the network with every service exposed to anything that connects.

In this project, you will add a Kali Linux security workstation to your home lab and use it to discover every exposed service. Then you will lock both servers down with host-based firewalls and prove the lockdown works with before-and-after scans.

What You'll Build

Picture booting your Kali Linux workstation, scanning your entire lab network to reveal every open port, then re-running the same scan after locking down the firewalls and watching every exposed port vanish.

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

  • A Kali Linux security workstation where you can run Nmap scans that map every device, open port, and running service across your entire lab network.
  • Host-based firewalls on both your Ubuntu Server and Windows 11 VMs, enforcing a default-deny posture that only lets through the traffic your lab actually needs.
  • Before-and-after scan evidence proving your firewalls work. Ports that were wide open now show as filtered.
  • Secret Mission: Enable UFW logging, launch an aggressive scan, and read the raw firewall logs to see exactly which probes were blocked.

Are there any prerequisites?

This project builds on Projects 1 and 2 of the Build Your Own Home Lab series. You need a working VirtualBox environment with an Ubuntu Server VM (lab-server) and a Windows 11 VM (Luthadel) on Host-Only Adapter #3.

Before We Start

Your lab has two servers humming along on a private network, trusting each other completely. In this project, you are going to add an attacker to the mix and find out just how exposed those servers really are.

Install 7-Zip and Import the Kali Linux VM

Your lab network has two VMs that trust everything on the wire. To find out how exposed they really are, you need a dedicated security workstation built for the job: Kali Linux.

Kali ships as a pre-built VirtualBox image compressed in .7z format, which Windows cannot extract natively. In this step, you will install 7-Zip to handle the extraction, then import the Kali VM into VirtualBox and wire it to your lab network.

In this step, get ready to:
  • Download and install 7-Zip on your Windows host.
  • Download and extract the Kali Linux 2026.2 VirtualBox image.
  • Import and configure the Kali VM for your lab network.
Download 7-Zip and the Kali Linux image

The Kali VirtualBox image is a .7z compressed archive. You need 7-Zip installed before you can extract it.

  • Open your browser and go to https://www.7-zip.org/download.html.
  • Download the 64-bit Windows x64 .exe installer (version 26.02).
  • Run the downloaded installer and accept the default settings.

Already have 7-Zip installed?

If 7-Zip is already on your machine, skip straight to downloading the Kali image below.

  • Confirm 7-Zip installed correctly by right-clicking any file on your Desktop.
  • On Windows 11, click Show more options in the context menu if you do not see 7-Zip listed directly.

You should see 7-Zip as an option in the context menu. That confirms the install worked.

Don't see 7-Zip in the right-click menu?

Make sure you ran the installer as an administrator. Try right-clicking the .exe file and selecting Run as administrator, then reinstall.

If you still do not see it, try restarting File Explorer or logging out and back in.

Why isn't 7-Zip showing up in my right-click menu after installing?

Now download the Kali Linux image.

  • Open https://www.kali.org/get-kali/ in your browser.
  • Find the Pre-built Virtual Machines section.
  • Download the VirtualBox image: kali-linux-2026.2-virtualbox-amd64.7z (3.7 GiB).

This download takes a while

The Kali image is 3.7 GiB. Depending on your connection speed, this can take 10-15 minutes. A good time to stretch or review what you built in the previous projects.

  • Confirm the file kali-linux-2026.2-virtualbox-amd64.7z exists in your Downloads folder before moving on.
Extract the image and import it into VirtualBox

The .7z archive contains a .vbox file, which is VirtualBox's native VM configuration format. You will use VirtualBox's Add function to register this VM directly.

  • Press the Windows key to open your search bar, type File Explorer, and press Enter.
  • Navigate to your Downloads folder.
  • Right-click kali-linux-2026.2-virtualbox-amd64.7z.
  • Click Show more options if you see the simplified Windows 11 context menu.
  • Click 7-Zip, then click Extract Here.

Extraction takes a minute or two. When it finishes, you should see a new folder containing a .vbox file and a .vdi disk image.

What are these files?

The .vbox file is the VM configuration. It tells VirtualBox the hardware settings, adapter layout, and which disk to use.

The .vdi file is the virtual hard disk. It contains the entire Kali Linux operating system.

Now add the VM to VirtualBox.

  • Open VirtualBox.
  • Click Machine in the top menu bar.
  • Click Add.
  • Navigate to the extracted folder inside your Downloads folder.
  • Select the .vbox file and click Open.

The Kali Linux VM now appears in the VirtualBox sidebar alongside lab-server and Luthadel.

Don't see the Kali VM in the sidebar?

Make sure you selected the .vbox file, not the .vdi file. The .vbox file is the VM configuration that VirtualBox knows how to register.

Also check that the extraction finished completely. If the extracted folder is empty or missing files, re-extract with 7-Zip.

Help me troubleshoot importing the Kali VM into VirtualBox.

Configure the network adapter and take a snapshot

The pre-built Kali image ships with its network adapter set to NAT by default. You need to switch it to Host-Only Adapter #3 so Kali joins your lab's 192.168.67.0/24 subnet alongside lab-server and Luthadel.

  • Select the Kali VM in the VirtualBox sidebar.
  • Click Settings in the toolbar.
  • Click Network in the left panel.
  • Under the Adapter 1 tab, change the Attached to dropdown to Host-Only Adapter.
  • In the Name dropdown, select VirtualBox Host-Only Ethernet Adapter #3.

Why Host-Only Adapter #3?

This is the same adapter your lab-server and Luthadel use from the previous projects. Connecting Kali to this adapter places it on the 192.168.67.0/24 subnet where it can reach both VMs.

Kali will also be able to receive a DHCP lease from lab-server's dnsmasq service, just like Luthadel does.

Now check the RAM allocation.

  • Click System in the left panel.
  • On the Motherboard tab, check that Base Memory is set to at least 2048 MB.
  • If it is lower, drag the slider or type 2048 in the field.
  • Click OK to save the settings.

Finally, take a snapshot so you have a clean rollback point before you boot Kali for the first time.

  • With the Kali VM still selected in the sidebar, click Machine in the top menu bar.
  • Click Take Snapshot.
  • Name the snapshot Clean Import and click OK.

Why take a snapshot before booting?

A snapshot captures the exact state of the VM at that moment. If anything goes wrong during setup, you can restore to this snapshot instead of re-downloading and re-importing the 3.7 GiB image.

Before moving on, what do you expect to see in the Kali VM's details pane for its network adapter and memory?

  • Select the Kali VM in the VirtualBox sidebar and look at the details pane on the right.

You should see Adapter 1 set to Host-Only Adapter #3, 2048 MB of RAM, and a Clean Import snapshot listed. The VM is imported and configured but not yet booted.

Can't find Host-Only Ethernet Adapter #3?

This adapter was created in Project 1. If you do not see it in the Name dropdown, go to File > Host Network Manager in VirtualBox and check that the adapter exists with the 192.168.67.1 address.

If it is missing, revisit the networking setup from Project 1 to recreate it.

Help me fix my Host-Only Adapter #3 in VirtualBox.

Your Kali VM is imported, configured, and snapshotted. Next up, you will boot it for the first time and watch it join your lab network.

Boot Kali and Map the Network

Your Kali Linux VM is imported and sitting in VirtualBox, ready for its first boot.

Before you can run any security tools, Kali needs to actually be a working member of your lab network. That means getting an IP address, resolving hostnames, and reaching every device on the subnet. In this step, you will boot Kali, confirm it gets a DHCP lease from lab-server, and then map every device on the subnet.

In this step, get ready to:
  • Boot the Kali VM and confirm it has a DHCP lease from lab-server.
  • Verify DNS resolution and ping connectivity to all lab hosts.
  • Run a network discovery scan to map every device on the subnet.
Boot Kali and verify network connectivity
  • In VirtualBox, select the Kali Linux VM in the sidebar.
  • Click Start in the toolbar to boot the VM.
  • At the login screen, enter username kali and password kali.

What are the default Kali credentials?

The pre-built Kali Linux VirtualBox image ships with the default username kali and password kali. These are standard for the pre-built images and should be changed in a production environment.

Once you see the Kali desktop, you need to open a terminal to check your network connection.

  • Right-click anywhere on the desktop and select Open Terminal Here. You can also click the terminal icon in the top taskbar.
  • Check your IP address by running this command:
ip a

Look for an interface with an IP address in the 192.168.67.100-200 range. The interface name will be eth0 on most Kali images, but yours might show as enp0s3 instead. Either name is fine.

Note your interface name

Whatever interface name appears next to your 192.168.67.x address is your lab network interface. The rest of this project will refer to it as eth0. If yours is different, substitute your actual name whenever you see eth0.

  • Confirm the default gateway and DHCP lease came from lab-server by running:
ip route

You should see a default via line pointing to an address on the 192.168.67.0/24 subnet. This confirms that lab-server's dnsmasq service handed Kali a working network lease.

No IP address in the 192.168.67.x range?

If you see no IP address on your network interface, lab-server may not be running or the adapter is misconfigured.

  • Confirm lab-server is powered on in VirtualBox. It must be running to hand out DHCP leases.
  • Double-check that the Kali VM's Adapter 1 is set to Host-Only Adapter and that it is using VirtualBox Host-Only Ethernet Adapter #3.
  • Try requesting a fresh lease manually by running sudo dhclient in the Kali terminal, then run ip a again.

Need more help? Help me troubleshoot why my Kali VM is not getting a DHCP lease from lab-server on Host-Only Adapter #3.

Test DNS resolution and connectivity to all lab hosts

Having an IP address is only half the story. Your Kali workstation also needs to resolve hostnames through lab-server's DNS service and reach every host on the subnet.

  • Test DNS resolution for lab-server by running:
nslookup lab-server.lab 192.168.67.10
  • Test DNS resolution for the Windows VM by running:
nslookup luthadel.lab 192.168.67.10

Both commands should return the correct IP addresses: 192.168.67.10 for lab-server and 192.168.67.50 for Luthadel.

  • Ping each host to confirm full connectivity. Run these commands one at a time:
ping -c 3 192.168.67.10
ping -c 3 192.168.67.50
ping -c 3 192.168.67.1

All three pings should return replies with 0% packet loss. The first targets lab-server, the second targets Luthadel, and the third targets your host machine (Shreya).

DNS not resolving or pings failing?

  • If nslookup times out, confirm lab-server is running and that dnsmasq is active on it. SSH into lab-server from another terminal and run sudo systemctl status dnsmasq.
  • If pings to Luthadel fail but lab-server works, check that the Luthadel VM is powered on in VirtualBox and connected to Host-Only Adapter #3.
  • If pings to the host (192.168.67.1) fail, your host firewall may be blocking ICMP on the Host-Only adapter.

Need more help? Help me troubleshoot DNS resolution and ping connectivity from my Kali VM to the other hosts on my lab network.

Run network discovery to map the entire subnet

Pinging individual IPs works, but a real security audit starts with discovering everything on the network automatically. The netdiscover tool uses ARP requests to find every device on a subnet and report their IP addresses, MAC addresses, and hardware vendor names.

Before you run this, how many devices do you think netdiscover will find on the subnet?

  • Map all hosts on the subnet by running this command:
sudo netdiscover -r 192.168.67.0/24 -c 3

What does this command do?

This command sends ARP requests to every possible address in the 192.168.67.0/24 subnet. ARP operates at Layer 2 of the network, which means it can find devices even when higher-level firewalls are in place.

The -r flag specifies the IP range to scan. The -c 3 flag sends each ARP request three times, which helps catch devices that might miss a single request.

The scan results appear in an interactive display that updates as devices are found. You will see a table with IP addresses, MAC addresses, and vendor names.

  • Wait a few seconds for the scan to complete, then press q to exit the interactive display.

You should see at least three hosts: lab-server at 192.168.67.10, Luthadel at 192.168.67.50, and your host machine (Shreya) at 192.168.67.1. Each entry includes the device's MAC address and a vendor identifier like PCS Systemtechnik GmbH (VirtualBox's default MAC vendor).

Why ARP discovery instead of just pinging?

Ping uses ICMP, which operates at Layer 3 (the network layer). A firewall can block ICMP and make a device invisible to ping. ARP operates at Layer 2 (the data link layer) and is required for basic network communication. Devices cannot hide from ARP on a local subnet.

This is why security professionals use multiple discovery techniques. Different tools work at different network layers, and combining them gives a more complete picture.

Not seeing any hosts in the scan?

  • Make sure you ran the command with sudo. ARP scanning requires root privileges to send raw packets.
  • If you see a "command not found" error, install it first by running sudo apt update && sudo apt install -y netdiscover, then try the scan again.
  • Confirm that lab-server and Luthadel are both powered on in VirtualBox. The scan can only find devices that are running.

Still stuck? Help me troubleshoot why netdiscover is not finding hosts on my 192.168.67.0/24 subnet.

Your Kali workstation is connected and you have mapped every device on the network. Next, you will use Kali's security tools to audit exactly what those devices are exposing.

Run a Baseline Security Audit

Your Kali workstation is on the network with a working IP, DNS resolution, and connectivity to every host. Now it is time to find out what those hosts are actually running.

Neither lab-server nor Luthadel has a firewall enabled right now. Every listening service is wide open to any device on the subnet. You will run a full security audit from Kali to document this wide-open state as a "before" snapshot you compare against after locking things down.

In this step, get ready to:
  • Run Nmap port scans with service version detection against lab-server and Luthadel.
  • Audit listening services and grab service banners with netcat.
  • Test unrestricted SSH access from Kali to lab-server.
Run Nmap port scans with service version detection

Nmap is a network scanner that probes hosts for open ports and identifies what services are running on them. You will scan both lab-server and Luthadel, saving the results to files so you can compare them against post-lockdown scans later.

  • Scan lab-server and save the results to a file by running this command in your Kali terminal:
sudo nmap -sS -sV 192.168.67.10 -oN baseline-labserver.txt

What do these flags mean?

  • -sS performs a TCP SYN scan (also called a stealth scan). It sends a SYN packet to each port and reads the response without completing the full handshake.
  • -sV probes each open port to detect the service name and version number running on it.
  • -oN baseline-labserver.txt saves the scan output in normal (human-readable) format to the file. Nmap still displays the results in your terminal at the same time.

The scan takes about 15-30 seconds. You should see a table listing open ports, protocols, service names, and version numbers for lab-server.

Seeing "host seems down" or no results?

  • Make sure the lab-server VM is running in VirtualBox.
  • Confirm you can still ping lab-server: ping -c 3 192.168.67.10. If pings fail, check that both VMs are on Host-Only Adapter #3.
  • Don't forget sudo. SYN scans require root privileges.

Help me troubleshoot my Nmap scan against lab-server.

  • Now scan Luthadel and save those results by running:
sudo nmap -sS -sV 192.168.67.50 -oN baseline-luthadel.txt

You should see a similar table for Luthadel, showing Windows services like SMB on port 445 and RPC on port 135.

  • Confirm both baseline files were saved by running:
ls ~/baseline-*.txt

You should see baseline-labserver.txt and baseline-luthadel.txt listed.

  • Take note of every open port and service version reported in both scans. You will compare these against your post-lockdown scans later.
Audit listening services on lab-server and grab banners from Kali

Nmap shows you what is visible from across the network. Now you will look from the server's own perspective with ss, then use netcat to grab the banners those services broadcast to anyone who connects.

  • SSH into lab-server from Kali by running:
ssh [[USERNAME="your lab-server username"]]@192.168.67.10
  • Enter your password when prompted.
  • Once connected, list every TCP service listening on lab-server by running:
sudo ss -tlnp

What do the ss flags mean?

  • -t shows only TCP sockets.
  • -l filters to listening (waiting for connections) sockets only.
  • -n shows numeric port numbers instead of resolving to service names.
  • -p shows the process name that owns each socket. Using sudo ensures you see process names for system services like sshd and dnsmasq.

You should see lines for each listening service, including the port number and process name. Compare this with your Nmap output to confirm they match.

  • Exit the SSH session to return to Kali by running:
exit

Now you will use netcat to connect directly to services on lab-server and see what information they broadcast. This is called banner grabbing.

  • Grab the SSH service banner from lab-server by running:
nc -v 192.168.67.10 22

What is banner grabbing?

When you connect to a service, it often announces itself with a text string called a banner. The SSH banner reveals the exact software version running on that port, such as SSH-2.0-OpenSSH_8.9p1.

An attacker can use this information to search for known vulnerabilities in that specific version. Seeing how much your servers reveal is part of understanding what you need to protect.

You should see a line starting with SSH-2.0-OpenSSH followed by the version number and operating system details.

  • Press Ctrl+C to close the netcat connection.
  • Try grabbing a DNS banner over UDP by running:
nc -v -u 192.168.67.10 53
  • Type a few random characters and press Enter.
  • Press Ctrl+C to close the connection.

Why does DNS not show a readable banner?

DNS expects properly formatted query packets, not raw text. You may see garbled output or nothing at all. That is normal. Not every service broadcasts a human-readable banner, but the connection attempt itself confirms the port is open and accepting traffic.

Test SSH access from Kali to confirm there are no restrictions

You already connected to lab-server via SSH earlier in this step. Now try it again and think about what this means from a security perspective.

  • Attempt SSH from Kali to lab-server by running:
ssh [[USERNAME="your lab-server username"]]@192.168.67.10
  • Enter your password when prompted.

The connection succeeds immediately. No firewall challenged it. No rule restricted which IP addresses can connect.

Why is this a problem?

Kali is acting as an attacker workstation on this network. Without a firewall, any device on the subnet can SSH into lab-server, query its DNS, or reach any other listening service. There is nothing stopping an unauthorized machine from connecting.

This is exactly the gap you will close in the next steps with host-based firewalls.

  • Exit the SSH session by running:
exit

Before you move on, take a moment to predict: how many of the ports Nmap found on lab-server do you think actually need to be open for the lab to function?

  • Confirm your baseline files are ready for comparison by running:
ls -la ~/baseline-*.txt

You should see both baseline-labserver.txt and baseline-luthadel.txt with non-zero file sizes, confirming the scan data was saved.

Files missing or empty?

  • If a file is missing, re-run the Nmap scan with the -oN flag to save the output. Double check the filename matches exactly.
  • If a file shows a size of 0, the scan may have failed. Re-run it and check that the target VM is powered on and reachable.

Help me troubleshoot my missing Nmap baseline files.

Your baseline audit is complete. You have documented proof of every exposed service on both servers. Next up, you will start locking things down with UFW on lab-server.

Lock Down Ubuntu Server with UFW

Your baseline scans told a clear story. Every service on lab-server is exposed to every device on the network. Any host that joins the subnet can reach SSH, DNS, and every other port without restriction.

In this step, you will lock down lab-server using UFW, Ubuntu's built-in firewall manager. You will set a default-deny policy that blocks all incoming traffic, then punch precise holes for only the services lab-server needs: DNS, DHCP, and SSH.

In this step, get ready to:
  • Add UFW allow rules for SSH, DNS, and DHCP before enabling the firewall.
  • Enable UFW with a default-deny incoming policy and verify the active ruleset.
  • Test the lockdown from Kali with a quick Nmap scan and a ping.
Add allow rules before enabling UFW

The order you add firewall rules matters. If you enable a default-deny firewall before adding an SSH allow rule, you will instantly lock yourself out of the server with no way back in except the VirtualBox console.

  • SSH into lab-server from your Kali terminal by running this command:
ssh [[USERNAME="your lab-server username"]]@192.168.67.10
  • Enter your password when prompted.

Connection refused?

Make sure the lab-server VM is running in VirtualBox. Confirm you are using the correct username you set up for lab-server in a previous project, not kali.

Help me troubleshoot my SSH connection to lab-server

Now that you are on lab-server, you will add three allow rules. The SSH rule goes first so your current session stays alive when the firewall activates.

  • Add the three allow rules by running these commands one at a time:
sudo ufw allow from 192.168.67.0/24 to any port 22 proto tcp
sudo ufw allow 53
sudo ufw allow 67/udp

What do these rules do?

  • The first rule allows SSH connections (port 22, TCP) only from devices on your lab subnet (192.168.67.0/24). No device outside this range can SSH in.
  • The second rule allows DNS traffic (port 53, both TCP and UDP) from any source, because lab-server runs dnsmasq for the entire lab.
  • The third rule allows DHCP server traffic (port 67, UDP only) so lab-server can continue handing out IP addresses to new VMs.
  • Set the default policies by running these two commands:
sudo ufw default deny incoming
sudo ufw default allow outgoing

What is a default-deny policy?

A default-deny policy blocks all incoming traffic that does not match an explicit allow rule. This is the opposite of what lab-server has right now, where every port is reachable by default.

The outgoing policy stays at allow so lab-server can still reach the internet for updates and DNS lookups of its own.

Enable UFW and verify the rules

Your rules are staged but not active yet. Enabling UFW flips the switch and starts enforcing them immediately.

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

Why does UFW warn about disrupting SSH?

UFW warns that enabling the firewall may disrupt existing SSH connections. Because you already added the SSH allow rule from 192.168.67.0/24 in the previous substep, your Kali SSH session will survive.

Your terminal prompt should still be active. That is the first sign your allow rule is working.

  • Review the full active ruleset by running:
sudo ufw status verbose

You should see output showing Status: active with a Default: deny (incoming) policy. Below that, three allow rules should be listed: port 22 TCP from 192.168.67.0/24, port 53, and port 67/udp.

Lost your SSH connection?

If your terminal froze or disconnected, the SSH allow rule was not added correctly before enabling UFW. Open the Kali VirtualBox console window for lab-server directly (not through SSH).

Log in at the VirtualBox console and run sudo ufw disable to turn off the firewall. Then re-add the SSH rule with the exact subnet range and enable UFW again.

Help me fix my UFW lockout on lab-server

Quick-test from Kali to confirm UFW is blocking

Seeing the rules listed is one thing. Proving they actually block traffic from an external host is the real test. You will now switch to Kali and scan lab-server the same way an attacker would.

  • Open a second terminal window in Kali (keep your SSH session to lab-server open in the first terminal).

Before you run the scan, think about what you expect to see. Your baseline showed multiple open ports on lab-server. Now that UFW is enforcing a default-deny policy, which ports do you think will still appear as open?

  • Run a quick Nmap scan against lab-server from Kali by running this command:
sudo nmap -sS 192.168.67.10 -p 1-100

Compare the results with your baseline. Ports that were previously open (other than 22 and 53) should now show as filtered. That means UFW is silently dropping those packets instead of letting them through.

What does filtered mean in Nmap?

When Nmap reports a port as filtered, it means a firewall is preventing the probe from reaching the port. Nmap cannot determine whether the port is open or closed because no response came back at all.

This is different from closed, which means the port is reachable but no service is listening. A filtered result is exactly what a well-configured firewall produces.

  • Confirm that ICMP still works by pinging lab-server:
ping -c 3 192.168.67.10

You should see three successful replies. UFW allows ICMP (ping) by default through its before.rules file, so no explicit rule was needed.

Still seeing all ports as open?

Switch back to your lab-server SSH session and run sudo ufw status verbose to confirm the status is active. If the status shows inactive, the enable command did not run successfully. Run sudo ufw enable again and type y to confirm.

Also make sure you are scanning from the Kali terminal, not from inside the SSH session on lab-server. Scanning from lab-server itself would bypass the firewall since traffic would stay local.

Help me troubleshoot my UFW firewall not blocking Nmap scans

Lab-server is now running a proper default-deny firewall. Only DNS, DHCP, and SSH from your lab subnet can get through. Next up, you will lock down Luthadel's Windows firewall and re-run the full audit to prove both servers are hardened.

Lock Down Luthadel and Verify the Full Lockdown

Lab-server is now behind a default-deny firewall, only accepting the traffic you explicitly allowed. Luthadel is still wide open.

In this step, you will create block rules on Luthadel using Windows Defender Firewall with Advanced Security to shut down the exposed ports your baseline scan revealed. Then you will re-run the full audit from Kali and prove both servers are properly locked down.

In this step, get ready to:
  • Create inbound block rules on Luthadel for exposed ports like SMB and RPC.
  • Re-run the full Nmap audit from Kali against both lab-server and Luthadel.
  • Run individual service tests to confirm DNS, SSH, and ICMP still work while blocked ports are closed.
Create inbound block rules on Luthadel

Your baseline scan of Luthadel showed ports like 445 (SMB) and 135 (RPC) wide open to anyone on the network. These are common targets for lateral movement and enumeration attacks.

You will use netsh in PowerShell to create inbound block rules on Luthadel. This gives you scriptable, reproducible firewall rules you can verify from the command line.

  • Switch to your Luthadel VM in VirtualBox.
  • Press the Windows key to open your search bar.
  • Type PowerShell.
  • Right-click Windows PowerShell and select Run as administrator.
  • Block inbound SMB traffic on port 445 by running this command:
netsh advfirewall firewall add rule name="Block SMB Inbound" dir=in action=block protocol=TCP localport=445
  • Block inbound RPC traffic on port 135 by running this command:
netsh advfirewall firewall add rule name="Block RPC Inbound" dir=in action=block protocol=TCP localport=135

What do these rules do?

SMB (port 445) is the Windows file-sharing protocol. RPC (port 135) is used for remote service communication. Both are prime targets for attackers trying to move laterally across a network.

Each netsh advfirewall command creates an inbound rule that drops any TCP traffic arriving on that port. The dir=in flag targets incoming connections, and action=block silently drops the traffic.

Found more open ports in your baseline?

Check your baseline-luthadel.txt file for any additional open ports beyond 445 and 135. You can create a block rule for each one using the same command pattern, replacing the name and localport values.

  • Verify the SMB block rule was created by running:
netsh advfirewall firewall show rule name="Block SMB Inbound"
  • You should see a rule listing with Action: Block, Direction: In, and LocalPort: 445.
  • Verify the RPC block rule the same way by running:
netsh advfirewall firewall show rule name="Block RPC Inbound"

Not seeing your rule?

Make sure you opened PowerShell as Administrator. Standard PowerShell does not have permission to create or view firewall rules.

Double-check the rule name matches exactly, including capitalization and spaces. The show rule command is case-sensitive on the name parameter.

Still stuck? Help me troubleshoot my Windows Firewall block rule.

  • Now confirm that your existing ICMP allow rules from the previous project are still working. Switch back to your Kali VM terminal.
  • Ping Luthadel from Kali by running:
ping -c 3 192.168.67.50
  • You should see three successful replies. The new block rules only affect TCP ports 445 and 135. Your ICMP rules are untouched.
Re-run the full Nmap audit from Kali

Both servers now have host-based firewalls enforcing restrictions. Time to re-run the exact same Nmap audit you ran during the baseline and save the results to new files for a side-by-side comparison.

  • From your Kali terminal, scan lab-server and save the results by running:
sudo nmap -sS -sV 192.168.67.10 -oN lockdown-labserver.txt

Why save to a new file?

The -oN flag saves the output in normal format to a text file. By using lockdown-labserver.txt instead of overwriting your baseline file, you keep both snapshots for comparison.

  • Scan Luthadel and save the results by running:
sudo nmap -sS -sV 192.168.67.50 -oN lockdown-luthadel.txt

Before you read the results, think about what you expect to see. Which ports should now show as filtered compared to your baseline?

  • Compare the lockdown results against your baselines. Look at the lab-server lockdown scan by running:
cat lockdown-labserver.txt
  • Compare it with your baseline by running:
cat baseline-labserver.txt
  • Do the same comparison for Luthadel by running:
cat lockdown-luthadel.txt
  • And compare it with the baseline by running:
cat baseline-luthadel.txt

You should see significantly fewer open ports in the lockdown files. Ports that were previously open now show as filtered or closed on both hosts.

What does filtered mean in Nmap output?

A filtered port means Nmap sent a probe but received no response. This typically means a firewall silently dropped the packet. That is exactly the behavior you want from your block rules.

A closed port means Nmap received a response saying nothing is listening there. Both filtered and closed are improvements over open.

Still seeing open ports you expected to be blocked?

For lab-server, confirm UFW is still active by running sudo ufw status verbose over SSH. If UFW was disabled during a reboot, re-enable it with sudo ufw enable.

For Luthadel, make sure the block rules target the correct port numbers. Run netsh advfirewall firewall show rule dir=in to list all inbound rules and check for typos.

Need help? My Nmap scan still shows open ports after I configured firewall rules.

Run individual service tests to confirm allowed traffic still works

Blocking ports is only half the job. A lockdown that breaks legitimate services is worse than no lockdown at all. You need to verify that DNS, SSH, and ICMP still work as expected.

  • Test DNS resolution from Kali by running:
nslookup lab-server.lab 192.168.67.10
  • You should see lab-server's IP address resolved successfully. This confirms UFW's allow rule for port 53 is working.
  • Test SSH access to lab-server from Kali by running:
ssh [[USERNAME="your lab-server username"]]@192.168.67.10
  • The SSH connection should succeed. This confirms UFW's allow rule for port 22 from the lab subnet is working.
  • Type exit to close the SSH session and return to Kali's terminal.
  • Test ICMP to both hosts by running:
ping -c 3 192.168.67.10
  • Run the same for Luthadel:
ping -c 3 192.168.67.50
  • Both should return three successful replies. ICMP is allowed by UFW's default before.rules on lab-server and by Luthadel's existing ICMP allow rules from the previous project.

Now for the final test. Before you run the next command, what do you think will happen when you try to connect to Luthadel's SMB port with netcat?

  • Attempt a banner grab against Luthadel's blocked SMB port by running:
nc -v 192.168.67.50 445

The connection fails. During your baseline audit, this port was open and responding. Now the firewall silently drops the traffic before it ever reaches the SMB service. That is your block rule in action.

What just happened?

You just completed a full before-and-after security audit of your home lab. Your baseline scans documented the wide-open state. Your lockdown scans prove that the firewalls are doing their job.

Lab-server's UFW enforces default-deny with targeted allow rules for DNS, DHCP, and SSH. Luthadel's Windows Defender Firewall blocks specific ports that were exposed in the baseline. Both servers still pass the essential service tests.

Netcat connected to port 445 instead of failing?

Switch to the Luthadel VM and verify the block rule exists by running netsh advfirewall firewall show rule name="Block SMB Inbound" in your Administrator PowerShell window. If the rule is missing, re-create it.

Also check that no other rule higher in the priority list is explicitly allowing port 445 inbound. Run netsh advfirewall firewall show rule dir=in and look for allow rules on port 445.

Still stuck? Help me figure out why my Windows Firewall block rule is not stopping netcat connections.

Secret mission

Enable UFW Logging and Analyze Blocked Probes

Your firewalls are blocking traffic, but can you prove it? In this secret mission, you will enable UFW logging, launch an aggressive scan from Kali, and read the raw firewall logs to see exactly which probes were blocked. This is a core skill for security monitoring and incident response.

Clean Up Your Resources

Clean Up Your Resources

Decide whether to keep your resources running, pause them to come back later, or delete them entirely. This project runs entirely on local VMs and open-source tools, so there are no ongoing cloud costs.

Resources you used:

  • Kali Linux VM in VirtualBox.
  • UFW firewall rules on lab-server.
  • Windows Defender Firewall rules on Luthadel.
  • Baseline and lockdown scan files on Kali (baseline-labserver.txt, baseline-luthadel.txt, lockdown-labserver.txt, lockdown-luthadel.txt).
  • VirtualBox snapshot "Clean Import" on the Kali VM.
  • 7-Zip installed on your Windows host.

Keep everything running

No action needed. Choose this if you plan to continue building on your home lab in a future project. Everything stays as you configured it.

  • Your Kali Linux VM stays in VirtualBox, ready to boot when you need it.
  • UFW stays active on lab-server, enforcing your default-deny policy.
  • Windows Defender Firewall rules stay in place on Luthadel.
  • Your baseline and lockdown scan files remain on Kali for future reference.
  • 7-Zip stays installed on your Windows host. It is a general-purpose archive tool you may find useful beyond this project.

Pause - I'll come back to this later

Shut down running VMs to free up system memory and CPU. Your files, firewall rules, and snapshots are preserved on disk.

  • In the Kali Linux VM, open a terminal and run:
  • Or right-click the Kali VM in VirtualBox and select Close > Save State to freeze it in its current state.
  • Do the same for lab-server and Luthadel if they are running.
  • When you are ready to return, open VirtualBox and start the VMs again. Your firewall rules and scan files will still be there.
sudo shutdown now

Save State vs Power Off

Save State freezes the VM exactly where you left off, including open terminals and running processes. Power Off (or sudo shutdown now) does a clean shutdown. Both preserve your disk and configuration.

Delete - I don't want to use this again

Remove all project resources and start fresh. Follow each item below to fully clean up.

Remove the Kali Linux VM
  • In VirtualBox, right-click the Kali Linux VM and select Remove.
  • When prompted, select Delete all files to remove the virtual disk and configuration from your system.
Reset UFW on lab-server
  • SSH into lab-server from Luthadel or your host machine and run:
sudo ufw reset
  • Type y when prompted to confirm. This disables UFW and deletes all the rules you created.
Remove Windows Defender Firewall rules on Luthadel
  • On Luthadel, open a PowerShell window as Administrator and run:
netsh advfirewall firewall delete rule name="Block SMB Inbound"
netsh advfirewall firewall delete rule name="Block RPC Inbound"
  • Repeat for any additional block rules you created during the project.
Delete the scan files on Kali
  • If you have not yet removed the Kali VM, boot it and run:
rm ~/baseline-labserver.txt ~/baseline-luthadel.txt ~/lockdown-labserver.txt ~/lockdown-luthadel.txt

Scan files live on the Kali VM

If you already deleted the Kali VM in the step above, the scan files were removed along with the virtual disk. No extra action needed.

Uninstall 7-Zip from your Windows host
  • On your Windows host, open Settings.
  • Select Apps, then Apps & features.
  • Find 7-Zip in the list, click it, and select Uninstall.
  • Follow the prompts to complete the uninstall.

Nice Work!

Nice Work!

You just built a fully operational security testing lab and then used it to lock down your own network. Your home lab now has three VMs, two hardened firewalls, and documented proof that the lockdown works.

You learned how to:

  • Deployed a Kali Linux security workstation and used netdiscover, Nmap, and netcat to map every host on your subnet and audit every open port, service version, and banner.
  • Enforced a default-deny security posture on lab-server using UFW, allowing only the traffic your server needs to function: SSH from the lab subnet, DNS, and DHCP.
  • Locked down Luthadel with Windows Defender Firewall with Advanced Security, then re-ran your full audit to produce before-and-after scan results proving both firewalls block unauthorized traffic while keeping essential services operational.
  • Secret Mission: Enabled UFW logging and analyzed raw firewall log entries to identify exactly which probes were blocked, building real incident-response skills.

Ready to quiz yourself?