Introduction
A firewall rule is useful only when it produces the intended access boundary while preserving required service. Adding an allow rule under a default ACCEPT policy alone does not prove that anyone has been restricted.
This lab supplies a dedicated Kali service and two practice clients. You will inspect their initial access, apply ordered source-based rules in Kali, save and restore the exercise policy, and test both client paths.
Observe the Training Network Before Restricting Access
In this step, you will test two supplied client views and inspect the firewall that protects their training service.
This lab supplies a small dedicated network inside the VM. The Kali training service is at 172.30.77.10:8080; the allowed client uses 172.30.77.20, and the client to block uses 172.30.77.30. Both initially have access. These are practice-network addresses, not public targets.
Begin in the initial Ubuntu host Terminal. The prepared training-client command makes a request from a named practice client. It runs on the host, while firewall administration will happen inside Kali. Choose the shared workspace:
cd /home/labex/project
Save the allowed client's initial HTTP status:
training-client allowed > allowed-before.txt
cat allowed-before.txt
The status line should contain 200 OK. Record the other client's initial access:
training-client blocked > blocked-before.txt
cat blocked-before.txt
It should also report 200 OK; the label names the client you will block, not its initial state.
Now enter Kali to inspect its firewall:
kali
Iptables evaluates packet-filtering rules in chains. INPUT handles packets destined for this environment, OUTPUT handles locally generated packets, and FORWARD handles routed packets. -L INPUT lists the input chain; -n keeps numeric addresses and ports, while -v includes counters:
sudo iptables -L INPUT -n -v
The practice chain initially has policy ACCEPT. A chain policy applies when no rule has already decided the packet's fate. In this lab you will add narrow rules for the dedicated service, leaving default policies and the host's firewall alone.
Apply and Save an Ordered Service Policy
In this step, you will permit the assigned client before rejecting other practice-network sources for the same service.
Stay in Kali. -A INPUT appends a rule to the input chain, -p tcp matches TCP, -s matches a source address, --dport selects the destination port, and -j chooses the action. Add the narrow allow rule first:
sudo iptables -A INPUT -p tcp -s 172.30.77.20 --dport 8080 -j ACCEPT
Next reject other sources in the dedicated practice subnet for that same port. The /24 prefix identifies the 172.30.77.0 network range:
sudo iptables -A INPUT -p tcp -s 172.30.77.0/24 --dport 8080 -j REJECT
Rules are evaluated in order. The allowed source matches the first terminating ACCEPT rule; the other practice client reaches the later REJECT rule. Reversing those rules would reject the allowed client too. Other ports and sources still follow the unchanged default policy.
Show the rule order and counters. --line-numbers includes each rule's position:
sudo iptables -L INPUT -n -v --line-numbers
The first rule should allow the assigned client on TCP 8080, and the later rule should reject that service's remaining practice-subnet traffic.
iptables-save prints the active rules in a format that can be restored. Save this exercise's configuration in the shared workspace:
sudo iptables-save > /home/labex/project/training.rules
The shell's < operator supplies a file as a command's standard input. iptables-restore reads that saved configuration; here you restore exactly the exercise rules you just saved:
sudo iptables-restore < /home/labex/project/training.rules
This operates only in the dedicated Kali network environment. Do not flush the host firewall or replace default policies to accomplish a narrow service restriction.
Verify Allowed and Denied Client Access
In this step, you will test the policy from both client sources and confirm that the training service remains available.
Return from Kali to the Ubuntu host Terminal so you can use the supplied client views:
exit
The host prompt names labex. Record the allowed client's new result:
training-client allowed > /home/labex/project/allowed-after.txt
cat /home/labex/project/allowed-after.txt
It should still report 200 OK.
The next command is expected to fail with a refused connection or another connection error: this is the client you deliberately blocked. Continue after the intentional failure:
training-client blocked
A failed request from the blocked client is meaningful only while the allowed path still works. Stopping the web service would break both paths and would not demonstrate the required policy.
Return to Kali and inspect counters after the tests:
kali
sudo iptables -L INPUT -n -v --line-numbers
The relevant rule counters should have increased. You have checked actual traffic behavior as well as rule text, and the LabEx host Terminal remains available throughout the exercise.
Summary
You inspected chain policies, added ordered source-based rules for one service, saved and restored the exercise configuration, and tested actual access from two clients. The allowed source and service remained available while the designated source was denied.
