Support This Book
Part III: Hands-On Labs Chapter 4

Transport Attack Labs

TCP attacks, SYN floods, port scanning, and transport layer security exercises

Chapter 4: Transport Attack Labs

Lab Overview

These labs explore TCP/UDP attacks and defenses at the transport layer.

Lab 4.1: TCP Connection States

Objective

Observe TCP connection establishment and states.

Difficulty: Beginner | Time: 20 minutes

Instructions

Part 1: Monitor Connections

# Watch connection states
watch -n 1 'netstat -ant | head -20'

# Or with ss
watch -n 1 'ss -ant | head -20'

Part 2: Generate Connections

# Start a listener
nc -l 8080 &

# Connect
nc localhost 8080

# Observe ESTABLISHED state

# Close connection (Ctrl+C)
# Observe TIME_WAIT

Part 3: Document States

TCP State Progression

TCP State Progression:
LISTEN → SYN_RECV → ESTABLISHED → FIN_WAIT → TIME_WAIT → CLOSED

Count states:
ss -ant | awk '{print $1}' | sort | uniq -c

Verification

  • Observed LISTEN, ESTABLISHED, TIME_WAIT
  • Documented state transitions
  • Counted connection states

Lab 4.2: SYN Flood Analysis

Objective

Understand SYN flood mechanics and detection.

Difficulty: Advanced | Time: 45 minutes

Warning

Only perform on isolated lab systems you own.

Instructions

Part 1: Baseline Measurement

# On target, check current SYN_RECV
ss -ant | grep SYN-RECV | wc -l

# Should be near 0 under normal conditions

Part 2: Low-Rate Test (Observation)

# On attacker - VERY LOW rate for observation
# Use hping3 with delay
sudo hping3 -S -p 80 --flood --rand-source TARGET_IP -c 100

# Immediately stop after ~100 packets

Part 3: Observe Impact

# On target during/after test
ss -ant | grep SYN-RECV | wc -l

# Check dmesg for kernel messages
dmesg | tail

# Note any SYN cookie activation
# Check if SYN cookies enabled
cat /proc/sys/net/ipv4/tcp_syncookies

# Enable if not
echo 1 > /proc/sys/net/ipv4/tcp_syncookies

# Repeat test - observe different behavior

Detection

Wireshark filter:
tcp.flags.syn == 1 and tcp.flags.ack == 0

Signs of SYN flood:
- Many SYN packets from random sources
- Very few corresponding SYN-ACKs or ACKs
- Target shows high SYN_RECV count

Verification

  • Measured baseline SYN_RECV
  • Observed state changes during test
  • Verified SYN cookie protection
  • Identified flood indicators in capture

Lab 4.3: Port Scanning Techniques

Objective

Perform and detect various scan types.

Difficulty: Intermediate | Time: 45 minutes

Instructions

Part 1: TCP Connect Scan

# Full connection scan
nmap -sT -p 22,80,443 192.168.1.100

# Observe in Wireshark:
# - Complete 3-way handshakes
# - RST after connection

Part 2: SYN Scan

# Half-open scan (requires root)
sudo nmap -sS -p 22,80,443 192.168.1.100

# Observe in Wireshark:
# - SYN sent
# - SYN-ACK received
# - RST sent (no ACK)

Part 3: FIN/NULL/Xmas Scans

# FIN scan
sudo nmap -sF -p 22,80,443 192.168.1.100

# NULL scan
sudo nmap -sN -p 22,80,443 192.168.1.100

# Xmas scan
sudo nmap -sX -p 22,80,443 192.168.1.100

# Observe: Different flag combinations

Part 4: Detection

Wireshark filters:

# SYN scan
tcp.flags.syn == 1 and tcp.flags.ack == 0

# FIN scan  
tcp.flags == 0x001

# NULL scan
tcp.flags == 0x000

# Xmas scan
tcp.flags.fin == 1 and tcp.flags.psh == 1 and tcp.flags.urg == 1

Verification

  • Performed each scan type
  • Captured traffic for each
  • Identified patterns in Wireshark
  • Created detection filters

Lab 4.4: Service Banner Grabbing

Objective

Extract service information from open ports.

Difficulty: Beginner | Time: 20 minutes

Instructions

Part 1: Manual Banner Grab

# HTTP banner
echo -e "HEAD / HTTP/1.1\r\nHost: target\r\n\r\n" | nc 192.168.1.100 80

# SSH banner
nc 192.168.1.100 22

# SMTP banner
nc 192.168.1.100 25

# FTP banner
nc 192.168.1.100 21

Part 2: Nmap Version Detection

# Service version detection
nmap -sV -p 22,80,443 192.168.1.100

# Aggressive version detection
nmap -sV --version-intensity 5 192.168.1.100

Part 3: Document Findings

Service Banner Analysis:

Port 22:
- Banner: SSH-2.0-OpenSSH_8.9p1 Ubuntu-3
- Version: OpenSSH 8.9
- OS Hint: Ubuntu

Port 80:
- Server: Apache/2.4.52 (Ubuntu)
- Version: Apache 2.4.52

Verification

  • Grabbed banners manually
  • Used Nmap version detection
  • Documented service versions

Lab 4.5: UDP Analysis

Objective

Analyze UDP traffic and understand scanning challenges.

Difficulty: Intermediate | Time: 30 minutes

Instructions

Part 1: UDP Scan Challenges

# UDP scan (slow due to rate limiting)
sudo nmap -sU --top-ports 20 192.168.1.100

# Observe in Wireshark:
# - UDP packets sent
# - ICMP Port Unreachable = closed
# - No response = open|filtered

Part 2: DNS UDP Analysis

# Capture DNS traffic
tshark -i eth0 -f "udp port 53" &

# Generate queries
dig google.com
dig example.com MX

# Analyze UDP flow
# Note: No handshake, just request/response

Part 3: UDP Service Probing

# Specific UDP service probes
nmap -sU -sV -p 53,161,123 192.168.1.100

# Probes with service-specific payloads
# More reliable than generic UDP scan

Verification

  • Completed UDP scan
  • Understood open|filtered ambiguity
  • Analyzed DNS over UDP

Lab 4.6: Defense Testing

Objective

Test transport layer defenses.

Difficulty: Intermediate | Time: 30 minutes

Instructions

Part 1: Rate Limiting

# Configure iptables rate limit
sudo iptables -A INPUT -p tcp --syn -m limit --limit 10/s --limit-burst 20 -j ACCEPT
sudo iptables -A INPUT -p tcp --syn -j DROP

# Test from attacker
hping3 -S -p 80 --flood TARGET -c 1000

# Observe rate limiting effect

Part 2: Connection Limits

# Limit connections per source
sudo iptables -A INPUT -p tcp --syn -m connlimit --connlimit-above 10 -j DROP

# Test multiple connections
for i in {1..20}; do nc -z TARGET 80 & done

Part 3: Verify Protection

# Check iptables counters
sudo iptables -L -v -n

# Should see dropped packets

Verification

  • Configured rate limiting
  • Tested defense effectiveness
  • Verified packet drops

Lab Summary

Skills Acquired

  • TCP state analysis
  • SYN flood understanding
  • Port scanning techniques
  • Banner grabbing
  • UDP analysis
  • Defense testing

Key Takeaways

  1. TCP states reveal connection health
  2. SYN floods exploit handshake asymmetry
  3. Different scans have different detectability
  4. UDP scanning is unreliable but important
  5. Defenses must be tested to verify effectiveness