Network Security & Packet Analysis Lab

Lab Overview

This lab documents hands-on exercises in protocol analysis and network inspection. Using a private virtual network, I captured and analyzed network packets during various scanning techniques, inspected raw protocol headers, and verified how host-based firewall rules (iptables / nftables) alter traffic signatures.

Environment & Topology

Subnet: 192.168.10.0/24 isolated virtual bridge.
Scanner / Analyst Workstation: Kali Linux (192.168.10.15).
Target Server: Debian 12 Minimal (192.168.10.50) running OpenSSH (port 22), Nginx (port 80), and an unencrypted test FTP server (port 21).
Packet Capture: tcpdump on the target interface and Wireshark 4.2 on the workstation.

Exercises & Technical Findings

1. TCP Handshake & SYN Scanning Mechanics

I compared the packet-level footprint of a full TCP Connect scan (-sT) against a SYN Stealth scan (-sS) against port 80:

[ Full TCP Connect (-sT) ]
Client ------------ SYN -----------> Target
Client <-------- SYN/ACK ----------- Target
Client ------------ ACK -----------> Target  (Connection Established)
Client ---------- RST/ACK ---------> Target  (Clean Teardown)

[ SYN Stealth Scan (-sS) ]
Client ------------ SYN -----------> Target
Client <-------- SYN/ACK ----------- Target
Client ------------ RST -----------> Target  (Aborted before socket opens)

Observation in Wireshark:

With -sT, the operating system's network stack completes the three-way handshake before immediately closing it. This generates application-level connection logs in Nginx (access.log).
With -sS, the scanner transmits an immediate RST upon receiving SYN/ACK. The TCP connection never transitions to ESTABLISHED, meaning application-level daemons rarely log the probe unless packet filtering or low-level socket monitors are running.

2. Identifying Plaintext Credential Exposure

To understand why unencrypted protocols are dangerous on untrusted subnets, I initiated a test FTP session to port 21 on the target and captured traffic:

wireshark — follow tcp stream (port 21)

$ 220 (vsFTPd 3.0.3)
$ USER labuser
$ 331 Please specify the password.
$ PASS LabTestPass2024!
$ 230 Login successful.

Using Wireshark filter tcp.port == 21, both the username and password appeared directly in plaintext in packet payloads. This reinforced why secure protocols (SFTP / SSH) or IPsec/TLS tunnels are non-negotiable for administrative and file transfer traffic.

3. Testing Host Firewall Policies (REJECT vs DROP)

I tested how client tools react when a firewall drops traffic versus when it actively rejects it:

Scenario A: REJECT Rule
```
sudo iptables -A INPUT -p tcp --dport 8080 -j REJECT --reject-with tcp-reset
```
Result: The target responds immediately with RST, ACK. Nmap marks the port closed within milliseconds.
Scenario B: DROP Rule
```
sudo iptables -A INPUT -p tcp --dport 8080 -j DROP
```
Result: The target silently ignores incoming packets. The scanner retransmits SYN packets at exponential intervals (1s, 2s, 4s) until reaching the timeout threshold. Nmap marks the port filtered.

bash — nmap comparison output

$ nmap -p 8080 192.168.10.50
$ PORT     STATE    SERVICE
$ 8080/tcp filtered http-proxy
$ Nmap done: 1 IP address (1 host up) scanned in 2.08 seconds

Problems Encountered & Lessons Learned

Packet Capture Checksum Offloading Anomaly

Problem: When examining captured packets on the transmitting machine in Wireshark, many TCP packets displayed checksum errors ([TCP Checksum Incorrect]).
Cause: Network interface cards (NICs) use TCP Checksum Offload (Tx Checksum Offload), where the packet is handed to the capture driver before the hardware calculates the actual checksum.
Fix: Disabled hardware checksum validation in Wireshark preferences (Preferences > Protocols > TCP > Validate checksum if possible = false) during virtual interface analysis to eliminate false alarms.

Key Takeaways

Dropping packets silently slows down automated scanners significantly more than rejecting packets with an active reset.
Wireshark display filters (tcp.flags, ip.addr, frame.len) are essential for cutting through background broadcast noise in shared network segments.
Plaintext protocols expose critical credentials to anyone with passive access to the same local collision/broadcast domain.