M09 - SMTP, FTP, and DHCP

NETWORKING MASTERY · PHASE 2 · MODULE 09 · WEEK 7 · PHASE 2 FINAL

📨 SMTP, FTP, and DHCP

Email delivery · FTP active/passive · DHCP DORA · ALG internals · Spoofing · NGFW email inspection

Beginner → Intermediate Prerequisite: M05 TCP, M06 UDP RFC 5321 · RFC 959 · RFC 2131 ALG-Heavy Protocols 2 Labs

THREE PROTOCOLS AN NGFW MUST DEEPLY UNDERSTAND

🎯

Why These Three Protocols Together

OVERVIEW

SMTP, FTP, and DHCP represent three different categories of protocol that an NGFW must handle in special ways. Each exposes a different class of firewall challenge:

📨 SMTP (TCP 25/587/465)

Email transfer. An NGFW must parse SMTP to enforce email policies — anti-spam, anti-phishing, attachment scanning, content filtering, and sender authentication (SPF/DKIM/DMARC verification). Email is the number one attack vector for malware delivery and phishing.

📁 FTP (TCP 21 + dynamic port)

File transfer. FTP is the classic ALG challenge protocol — it uses two separate TCP connections (control on port 21, data on a negotiated dynamic port). A stateful firewall must inspect the control channel to know which data connection to permit. FTP is largely replaced by SFTP/HTTPS but still found in legacy environments and internal networks.

🖥️ DHCP (UDP 67/68)

IP address assignment. DHCP is the protocol that bootstraps all other protocols — a device has no IP address until DHCP assigns one. An NGFW must understand DHCP to: detect rogue DHCP servers, prevent DHCP starvation attacks, correlate IP-to-MAC-to-hostname mappings for logging, and enforce DHCP snooping.

The ALG Problem

Both SMTP and FTP embed IP addresses or port numbers inside their application payloads — information a simple L3/L4 firewall cannot see. When NAT rewrites the outer IP header, the embedded address in the payload is wrong. Application Layer Gateways (ALGs) must inspect and rewrite payload content — a stateful, deep inspection operation that lies at the heart of NGFW design.

📋

Port and Protocol Quick Reference

REFERENCE

Protocol	Port(s)	Transport	Purpose	Encrypted variant
SMTP	25	TCP	Server-to-server mail relay (MTA to MTA)	STARTTLS (upgrades on same port)
SMTP Submission	587	TCP	Client to mail server (MUA to MSA)	STARTTLS mandatory
SMTPS	465	TCP	SMTP wrapped in TLS from connection start	TLS from first byte
POP3	110 / 995	TCP	Download mail from server (delete from server)	POP3S on 995
IMAP	143 / 993	TCP	Sync mail (leave on server)	IMAPS on 993
FTP Control	21	TCP	Commands, authentication, directory listing	FTPS (explicit or implicit TLS)
FTP Data	20 (active) or dynamic	TCP	Actual file transfer	Same TLS session as control
SFTP	22	TCP (SSH)	Secure file transfer over SSH — not FTP at all	Always encrypted (SSH)
DHCP Server	67	UDP	DHCP server listens here	No encryption (network-local)
DHCP Client	68	UDP	Client sends/receives on this port	No encryption
DHCPv6	546/547	UDP	IPv6 DHCP (client 546, server 547)	No encryption

SMTP — SIMPLE MAIL TRANSFER PROTOCOL (RFC 5321)

📧

How Email Moves — The SMTP Pipeline

ARCHITECTURE

Email delivery involves multiple agents. Understanding which component speaks to which — and on which port — is essential for NGFW policy:

/* Email delivery pipeline */

Your mail client (MUA — Mail User Agent)
  |
  | TCP 587 (SMTP Submission, STARTTLS + AUTH)
  ↓
Your outgoing mail server (MSA — Mail Submission Agent)
  |                     e.g., smtp.gmail.com, smtp.jio.com
  | TCP 25 (SMTP relay between servers)
  ↓
Recipient's MX server (MTA — Mail Transfer Agent)
  |                     found via DNS MX lookup on recipient domain
  | Stores in mailbox
  ↓
Recipient's mail client (MUA)
  ← TCP 993/IMAP or 995/POP3 (client downloads mail)

/* Why three different ports? */
Port 25:  Server-to-server relay. NOT for clients (ISPs block outbound 25 to prevent spam from compromised machines).
Port 587: Client submission. Requires AUTH (login). Most ISPs and firewalls allow this.
Port 465:  Legacy SMTPS — TLS from connection open. Superseded by 587+STARTTLS but still used.

/* DNS MX lookup before SMTP connection */
dig gmail.com MX
; gmail.com MX 5 gmail-smtp-in.l.google.com.
; gmail.com MX 10 alt1.gmail-smtp-in.l.google.com.
# Sender's MTA connects to lowest-preference (highest priority) MX server

💬

SMTP Session — Command by Command

SESSION

SMTP is a line-oriented text protocol. Commands come from the client; replies from the server always start with a 3-digit code. Reply codes: 2xx=success, 4xx=temporary failure (retry later), 5xx=permanent failure (don't retry).

220 mail.example.com ESMTP Postfix (Ubuntu)          ← Server greeting

EHLO sending-server.jio.com                           ← Extended HELLO — announces capabilities
250-mail.example.com
250-PIPELINING                                        ← Multiple commands without waiting
250-SIZE 52428800                                     ← Max message size: 50 MB
250-STARTTLS                                          ← Can upgrade to TLS
250-AUTH LOGIN PLAIN XOAUTH2                         ← Supported auth mechanisms
250 DSN                                               ← Delivery Status Notification support

STARTTLS                                              ← Upgrade connection to TLS
220 2.0.0 Ready to start TLS
[TLS handshake occurs — all subsequent SMTP is encrypted]
EHLO sending-server.jio.com                           ← Must re-EHLO after STARTTLS
250 mail.example.com ...

AUTH LOGIN                                            ← Authenticate (client to server only)
334 VXNlcm5hbWU6                                     ← "Username:" base64 encoded
YWpheUBqaW8uY29t                                     ← username base64 encoded
334 UGFzc3dvcmQ6                                     ← "Password:" base64 encoded
cGFzc3dvcmQxMjM=                                     ← password base64 encoded
235 2.7.0 Authentication successful

MAIL FROM:<ajay@jio.com>                             ← Envelope sender (RETURN-PATH)
250 2.1.0 Ok

RCPT TO:<colleague@example.com>                      ← Envelope recipient
250 2.1.5 Ok

RCPT TO:<boss@example.com>                           ← Multiple recipients allowed
250 2.1.5 Ok

DATA                                                  ← Start message body
354 End data with <CR><LF>.<CR><LF>
From: Ajay Kumar <ajay@jio.com>                      ← Message headers (RFC 5322)
To: Colleague <colleague@example.com>
Subject: Meeting tomorrow
Date: Wed, 18 Mar 2026 10:00:00 +0530
MIME-Version: 1.0
Content-Type: text/plain; charset=UTF-8

Hi, can we meet at 2pm tomorrow?
.                                                     ← Single dot on line = end of message
250 2.0.0 Ok: queued as A1B2C3D4

QUIT
221 2.0.0 Bye

💡 Envelope vs Message headers: SMTP has two separate sets of addressing. The envelope (MAIL FROM, RCPT TO commands) is what the mail servers use for routing — like the address written on the outside of a letter. The message headers (From:, To:, CC: inside the DATA section) are what email clients display — like the letter's own header. These can differ, which is how email spoofing works: MAIL FROM can say one address while From: header shows another.

📋

SMTP Reply Codes — Complete Reference

CODES

Code	Meaning	Action
`220`	Service ready	Server greeting — connection accepted
`221`	Service closing	Response to QUIT
`235`	Authentication successful	AUTH accepted
`250`	Requested action OK	Most commands succeed with this
`334`	Server AUTH challenge	Prompt for username/password (base64)
`354`	Start mail input	Response to DATA — send message until "."
`421`	Service unavailable	Server shutting down — retry later
`450`	Mailbox unavailable	Temporary — try again (greylisting)
`451`	Action aborted	Server error — retry later
`452`	Insufficient storage	Server disk full — retry later
`500`	Syntax error	Unrecognised command
`501`	Syntax error in parameters	Bad MAIL FROM or RCPT TO format
`503`	Bad sequence	Command out of order (RCPT before MAIL FROM)
`535`	Authentication failed	Wrong credentials
`550`	Mailbox unavailable	Permanent — user doesn't exist or blocked
`551`	User not local	Relay denied — not accepting for this domain
`552`	Exceeded storage allocation	Recipient mailbox full
`553`	Mailbox name not allowed	Invalid email address format
`554`	Transaction failed	Spam or policy rejection

SMTP SECURITY — SPOOFING, SPAM, AND AUTHENTICATION

⚠️

Email Spoofing — Why From: Can Lie

SPOOFING

The original SMTP protocol (1982) has no authentication. Anyone can connect to a mail server and claim to be anyone. The From: header in the message body is just text — there is no cryptographic verification that the sender is who they claim to be. This enables email spoofing, which underlies nearly all phishing attacks.

/* Email spoofing — trivially easy */
telnet mail.victim.com 25
220 mail.victim.com ESMTP
EHLO legitimate-looking-domain.com
250 Ok
MAIL FROM:<ceo@real-company.com>          ← Envelope sender — can be anything!
250 Ok
RCPT TO:<employee@victim.com>
250 Ok
DATA
From: CEO Real Name <ceo@real-company.com> ← Message header — identical to envelope
Subject: Urgent wire transfer needed
.

/* Without SPF/DKIM/DMARC the receiving server has no way to detect this */
/* Employee sees ceo@real-company.com — looks completely legitimate */

🔐

SPF, DKIM, and DMARC — The Email Authentication Trinity

AUTHENTICATION

Mechanism	What It Checks	Where Stored	Verifies	Fails When
SPF Sender Policy Framework	Envelope sender IP vs authorised sender list	DNS TXT record of sender domain	"Did this email come from an authorised server?"	Legitimate email forwarded through a relay not in SPF record. SPF fails on indirect mail flow.
DKIM DomainKeys Identified Mail	Cryptographic signature over message headers and body	DNS TXT at `selector._domainkey.domain`	"Was this message signed by the domain it claims to be from? Was it altered in transit?"	Message modified after signing. Signature mismatch = tampering detected.
DMARC Domain-based Msg Auth, Reporting and Conformance	SPF or DKIM alignment with From: header domain	DNS TXT at `_dmarc.domain`	"If SPF/DKIM fail, what should the receiver do? Quarantine? Reject? Report?"	SPF and DKIM both fail, or pass for a different domain than the From: header domain.

/* SMTP receiving server checks — in order */

1. Connect from IP 1.2.3.4, MAIL FROM:<ajay@jio.com>

2. SPF check: DNS lookup TXT jio.com → "v=spf1 include:_spf.jio.com -all"
   Is 1.2.3.4 in _spf.jio.com? If yes: SPF PASS. If no: SPF FAIL.

3. DKIM check: Find DKIM-Signature header in message DATA.
   Lookup DNS TXT selector._domainkey.jio.com → get public key.
   Verify signature over specified headers + body. Match? DKIM PASS.

4. DMARC check: DNS TXT _dmarc.jio.com → "v=DMARC1; p=reject; rua=mailto:..."
   Does SPF domain or DKIM d= tag align with From: header domain?
   If p=reject and both fail → REJECT the message (return 5xx).
   If p=quarantine → deliver to spam folder.
   If p=none → deliver but send report.

/* Verify SMTP auth headers in received email */
# In Gmail: "Show original" → look for:
Authentication-Results: mx.google.com;
   dkim=pass header.i=@jio.com header.s=selector1;
   spf=pass smtp.mailfrom=jio.com;
   dmarc=pass (p=REJECT) header.from=jio.com

🛡️

NGFW Email Inspection Capabilities

NGFW

SMTP proxy — NGFW terminates the SMTP connection, inspects the entire message, then re-originates to the real server. Full visibility into all commands, headers, and body
Attachment scanning — decompress ZIP/RAR, decode Base64 MIME attachments, scan for malware signatures. Block password-protected archives (common malware evasion)
Content filtering — scan email body for DLP keywords (credit card numbers, NIN/PAN numbers, confidential), block messages matching patterns
SPF/DKIM/DMARC enforcement — reject or quarantine emails that fail authentication regardless of recipient server's policy. Add header stamping with verification results
Anti-spam scoring — combine: SPF fail, DKIM fail, blacklisted sending IP (RBL/DNSBL), suspicious subject line patterns, URL reputation in body
Greylisting — temporary reject (4xx) on first delivery attempt. Legitimate servers retry, spam bots usually don't. Cheap and effective anti-spam with 10–15 minute delivery delay
URL reputation — scan URLs in email body against threat intelligence feeds. Rewrite URLs to pass through a proxy that checks at click-time (time-of-click protection)

FTP — FILE TRANSFER PROTOCOL (RFC 959)

📁

FTP's Two-Connection Architecture

ARCHITECTURE

FTP is unique among common protocols in using two separate TCP connections: one for commands (control channel) and one for actual data transfer (data channel). This separation was designed for efficiency but creates significant headaches for firewalls and NAT.

Control channel — TCP connection to server port 21. Carries all commands (USER, PASS, LIST, RETR, STOR) and replies. Stays open for the entire FTP session.
Data channel — a separate TCP connection opened for each data transfer (directory listing, file upload, file download). The port used depends on whether FTP is in Active or Passive mode.

The critical insight for NGFW: the data channel port number is negotiated inside the control channel payload. A firewall must inspect L7 content to know which port to permit for the data channel.

🔄

Active FTP vs Passive FTP

ACTIVE VS PASSIVE

Active FTP (PORT command)

CLIENT                SERVER

/* Control channel */
  → TCP connect to :21
  ← 220 FTP Ready
  → USER ajay
  ← 331 Password:
  → PASS secret
  ← 230 Logged in

/* Client tells server where to call back */
  → PORT 10,0,0,5,196,160
  ← IP: 10.0.0.5
    Port: 196*256+160 = 50336
  ← 200 PORT command OK

  → LIST
  ← 150 Opening data connection
/* Data channel — server initiates! */
  ← TCP connect from :20 to client :50336
  /* directory listing transferred */
  ← 226 Transfer complete

Problem: Server connects back to client on a high port. Client-side firewall must allow INBOUND connections from server. Behind NAT, the embedded IP in PORT is a private address — server cannot reach the client. Active FTP is incompatible with client-side NAT without ALG.

Passive FTP (PASV command)

CLIENT                SERVER

/* Control channel */
  → TCP connect to :21
  ← 220 FTP Ready
  → USER ajay
  ← 331 Password:
  → PASS secret
  ← 230 Logged in

/* Client asks server to listen */
  → PASV
  ← 227 Entering Passive Mode
    (192,168,1,100,200,45)
    IP: 192.168.1.100
    Port: 200*256+45 = 51245

  → LIST
  ← 150 Opening data connection
/* Data channel — CLIENT initiates */
  → TCP connect to server :51245
  /* directory listing transferred */
  ← 226 Transfer complete

Why passive is better: Client always initiates. Works through client-side NAT and firewalls (outbound TCP is usually allowed). Standard for modern FTP clients. Problem: Server's embedded IP in PASV response may be a private address if server is behind NAT — client cannot connect to 192.168.x.x from the internet. Server-side ALG needed.

💬

FTP Commands and Reply Codes

REFERENCE

Command	Meaning	Example
`USER`	Username	`USER ajay`
`PASS`	Password (sent in plaintext!)	`PASS mysecret`
`PORT`	Active mode — specify data channel address	`PORT 10,0,0,5,196,160`
`PASV`	Enter passive mode	`PASV` → server replies with IP,port
`EPSV`	Extended passive mode (IPv6-compatible)	`EPSV` → `229 Entering Extended Passive Mode (\|\|\|51245\|)`
`LIST`	Directory listing (opens data channel)	`LIST /home/ajay`
`RETR`	Download a file	`RETR report.pdf`
`STOR`	Upload a file	`STOR backup.tar.gz`
`DELE`	Delete a file	`DELE oldfile.txt`
`MKD`	Create directory	`MKD newdir`
`CWD`	Change working directory	`CWD /pub/software`
`PWD`	Print working directory	Reply: `257 "/home/ajay"`
`TYPE`	Set transfer type	`TYPE I` = binary, `TYPE A` = ASCII
`QUIT`	End session	`QUIT`

FTP reply codes follow the same 2xx/4xx/5xx pattern as SMTP: 125=data connection open, 150=opening data connection, 200=command ok, 226=transfer complete, 227=entering passive mode, 230=logged in, 331=username ok send password, 425=can't open data connection, 530=login incorrect.

FTP ALG — HOW FIREWALLS HANDLE FTP THROUGH NAT

🔧

The ALG Problem — Why FTP Breaks Through NAT

ALG CONCEPT

FTP embeds IP addresses and port numbers inside the application payload — in PORT and PASV command responses. When a NAT device rewrites the IP header (changing private IP 10.0.0.5 to public IP 203.x.x.x), the embedded address inside the FTP data remains 10.0.0.5. The remote server tries to connect to the private address — which fails.

An Application Layer Gateway (ALG) solves this by inspecting the FTP control channel payload and rewriting embedded addresses to match the NAT-translated address. This requires the firewall to:

Identify the FTP control connection (TCP dst port 21)
Maintain state for the FTP session
Parse PORT/PASV commands in the control channel payload
Rewrite the embedded IP/port in the payload to the post-NAT address
Dynamically add a firewall rule to permit the data channel connection
Remove the firewall rule when the data channel closes

💻

FTP ALG in Action — Passive FTP Through NAT

ALG WALKTHROUGH

/* Passive FTP through NAT — without ALG (broken) */

Client private IP:  10.0.0.5
Client public IP:   203.0.113.5 (NAT)
FTP server:         198.51.100.10

Client → NAT → Server: PASV
Server → NAT → Client: 227 Entering Passive Mode (198,51,100,10,200,45)
                         ← Server's real IP + port (this part is fine)
Client → NAT → Server: TCP connect to 198.51.100.10:51245
                         Works! Client always initiates in passive mode.

/* Now the problem: Active FTP through NAT (broken) */
Client → NAT → Server: PORT 10,0,0,5,196,160
                         ← Client sends its PRIVATE IP!
Server tries to connect to 10.0.0.5:50336 ← private, unreachable!
Connection fails.

/* Active FTP through NAT — with FTP ALG */
Client → NAT (ALG sees PORT command):
  Original: PORT 10,0,0,5,196,160
  ALG rewrites to: PORT 203,0,113,5,196,160   ← replaces private IP with public IP
  ALG adds dynamic firewall rule:
    PERMIT TCP from 198.51.100.10:20 to 203.0.113.5:50336

Client → NAT (ALG-rewritten) → Server: PORT 203,0,113,5,196,160
Server → NAT → Client: TCP connect from :20 to 203.0.113.5:50336
                        NAT translates to 10.0.0.5:50336  Works!
ALG removes dynamic rule when data channel closes.

/* PASV through NAT with server behind NAT (also needs ALG) */
Server is at private 192.168.1.100, public 203.0.113.10
Server responds: 227 Entering Passive Mode (192,168,1,100,200,45)
                 ← server's private IP in response — client can't reach it
ALG on server-side NAT rewrites to: (203,0,113,10,200,45)
                 ← public IP — client can now connect

⚠️ FTPS (FTP over TLS) breaks the ALG. When FTP uses TLS (FTPS), the control channel is encrypted — the ALG can no longer read PORT/PASV commands to rewrite them. This is why FTPS is often problematic through NAT firewalls. Solutions: use SFTP instead (SSH file transfer — completely different protocol, single connection), use FTPS with explicit passive mode and restrict the passive port range to something the firewall can statically permit.

🛡️

FTP Security and NGFW Policy

SECURITY

FTP sends credentials in plaintext — USER and PASS commands are ASCII text. Anyone sniffing the network sees the username and password. Block plain FTP at the internet perimeter; require SFTP (SSH-based, always encrypted) or FTPS.
Anonymous FTP — servers that allow USER anonymous with any password are a data exfiltration risk. Block outbound connections to anonymous FTP servers.
FTP bounce attack — an attacker uses the PORT command to make the FTP server connect to an arbitrary third-party host/port (port scanning via proxy). Mitigated by requiring PORT destination to match the client IP.
NGFW FTP policy — enable FTP ALG for internal users accessing external FTP, disable it at internet perimeter (block plain FTP), require SFTP or FTPS for all external transfers, scan uploaded/downloaded files for malware using the ALG inspection capability.

# Linux FTP client usage
ftp ftp.example.com          # plain FTP (avoid)
sftp user@sftp.example.com   # SFTP over SSH (recommended)

# Check FTP ALG status in Linux conntrack
sudo modprobe nf_conntrack_ftp
sudo cat /proc/net/nf_conntrack | grep ftp

# VPP FTP ALG (conceptual)
# vppctl: set ftp alg enable  — loads ftp-alg plugin
# Plugin inspects TCP port 21 streams, rewrites PORT/PASV payloads

DHCP — DYNAMIC HOST CONFIGURATION PROTOCOL (RFC 2131)

🖥️

What DHCP Does — And Why It's Critical

OVERVIEW

DHCP (RFC 2131) automatically assigns IP configuration to hosts joining a network: IP address, subnet mask, default gateway, DNS servers, lease duration, and optional parameters. Without DHCP, every device would need manual static IP configuration — impractical at any scale.

DHCP also gives your NGFW crucial identity information: by snooping DHCP exchanges, the firewall learns the mapping between IP address, MAC address, and hostname — enabling meaningful per-host logging and policy. "IP 10.0.0.5 visited malware-c2.com" becomes "Ajay's laptop visited malware-c2.com".

🔄

The DORA Exchange — Discover, Offer, Request, Acknowledge

DORA

DISCOVER — Client broadcasts "I need an IP"

Client has no IP yet. Sends DHCP Discover as a broadcast (src=0.0.0.0, dst=255.255.255.255, UDP sport=68, dport=67). Packet contains the client's MAC address (chaddr field) and optionally a hostname (Option 12) and requested parameters list (Option 55).

0.0.0.0:68 → 255.255.255.255:67 DHCP DISCOVER xid=0x12345678

OFFER — Server responds with an available IP

DHCP server receives Discover (via broadcast or DHCP relay agent for remote subnets). Selects an available IP from its pool, reserves it temporarily. Replies with DHCP Offer (broadcast or unicast to MAC, src=server IP). Contains: offered IP (yiaddr), lease time, subnet mask, gateway, DNS servers as options.

192.168.1.1:67 → 255.255.255.255:68 DHCP OFFER IP=192.168.1.50 lease=86400s

REQUEST — Client claims the offered IP

Client receives one or more Offers (multiple DHCP servers may respond). Client selects one and broadcasts DHCP Request — announcing its choice to all servers. Includes: requested IP (Option 50), server ID (Option 54) of chosen server. Other servers see this and release their reserved offers.

0.0.0.0:68 → 255.255.255.255:67 DHCP REQUEST IP=192.168.1.50 server=192.168.1.1

ACKNOWLEDGE — Server confirms assignment

Server confirms the lease. Client can now use the IP address. ACK contains the full configuration: IP, mask, gateway, DNS (options 1, 3, 6), lease time (option 51), renewal time T1 (50% of lease), rebind time T2 (87.5% of lease). Client configures its interface.

192.168.1.1:67 → 255.255.255.255:68 DHCP ACK IP=192.168.1.50 lease=86400s GW=192.168.1.1 DNS=8.8.8.8

/* After lease assignment — lease lifecycle */
T1 (renewal time = lease/2 = 43200s):
  Client unicasts DHCP Request to same server → DHCP ACK → lease renewed

T2 (rebind time = lease × 0.875 = 75600s):
  If T1 renewal failed: client broadcasts DHCP Request to any server
  Any server can renew the lease at this point

Lease expiry:
  If rebind failed: client must release IP, restart DORA from scratch
  Client cannot use the IP after lease expires

/* DHCP Release — client relinquishing IP */
# When client disconnects gracefully, sends DHCP Release
# Server returns IP to available pool immediately
# Many mobile clients DON'T send Release on WiFi disconnect (battery saving)

/* Check DHCP on Linux */
dhclient eth0                              # request DHCP lease
dhclient -r eth0                           # release lease
journalctl -u systemd-networkd | grep DHCP # view DHCP events
cat /var/lib/dhcp/dhclient.leases          # lease file

📦

DHCP Packet Format

PACKET FORMAT

DHCP packets have a fixed 236-byte base header (inherited from BOOTP) plus a variable-length options field. All four DORA messages use the same packet format — the message type is distinguished by DHCP Option 53.

1 byte

Message type: 1=BOOTREQUEST (client→server), 2=BOOTREPLY (server→client)

htype / hlen

1 + 1 bytes

Hardware type (1=Ethernet) and length (6 for MAC). Identifies address format.

xid

4 bytes

Transaction ID — random number client sets. Server copies into reply. Client matches replies to requests.

secs

2 bytes

Seconds elapsed since client started DHCP process. Used by relay agents for load balancing.

ciaddr

4 bytes

Client's current IP address (only in RENEW/REBIND — 0 in initial Discover)

yiaddr

4 bytes

"Your IP" — the IP address the server is offering to the client

siaddr

4 bytes

Server IP. Set in Offer and ACK to identify the DHCP server.

chaddr

16 bytes

Client hardware address (MAC address). First 6 bytes for Ethernet. This is how the server identifies the client before it has an IP.

options

variable

Tag-Length-Value (TLV) encoded options. Magic cookie (4 bytes: 99.130.83.99) marks start. Option 53=DHCP message type, 51=lease time, 1=subnet mask, 3=gateway, 6=DNS, 12=hostname, 55=parameter request list

DHCP SECURITY — ATTACKS AND DEFENCES

⚠️

DHCP Attack Taxonomy

ATTACKS

Attack	How It Works	Impact	Defence
Rogue DHCP Server	Attacker runs an unauthorised DHCP server. Responds to Discover messages faster than the legitimate server. Assigns itself as the gateway or DNS server.	MITM — all client traffic routed through attacker. DNS spoofing — attacker controls name resolution.	DHCP Snooping — switch port-level protection: only permit DHCP server responses on trusted ports (uplink to real server). All other ports are untrusted — DHCP server packets from untrusted ports are dropped.
DHCP Starvation	Attacker sends thousands of DHCP Discover requests with spoofed MAC addresses (chaddr field). Server allocates all available IPs to fake clients. Pool exhausted.	Denial of Service — legitimate clients cannot get IP addresses.	DHCP Snooping rate limiting: limit DHCP requests per physical switch port per second. Source MAC validation — verify chaddr matches the Ethernet frame's source MAC.
DHCP Relay Agent Spoofing	Attacker spoofs DHCP Relay Agent messages (Option 82) to claim a client is on a different subnet, getting an IP from a different pool.	IP address spoofing, policy bypass.	Validate relay agent IP. Drop Option 82 from untrusted sources. Configure relay on managed switches only.
IP Conflict Attack	Attacker sends gratuitous ARP claiming the IP that a victim just received from DHCP. Victim gets conflicting ARP responses, may lose connectivity.	Denial of service, IP address conflict.	Dynamic ARP Inspection (DAI) — validates ARP packets against DHCP snooping binding table.

🔍

DHCP Snooping — The Core Defence

DHCP SNOOPING

DHCP Snooping is a switch-level security feature that builds a binding table of verified IP-to-MAC-to-port mappings. This table is used by both DHCP Snooping itself and by Dynamic ARP Inspection (DAI) and IP Source Guard (IPSG).

/* DHCP Snooping binding table */
MAC Address        IP Address      Lease     VLAN  Interface
─────────────────  ──────────────  ────────  ────  ─────────
aa:bb:cc:dd:ee:ff  192.168.1.50   86400s    10    GigE0/1
11:22:33:44:55:66  192.168.1.51   86400s    10    GigE0/2
# Built by snooping DHCP ACK messages on trusted ports
# Only the real DHCP server (trusted port) should send ACKs

/* NGFW uses this for identity-based logging */
# DNS query from 192.168.1.50 → look up in DHCP snooping table
# → hostname "ajay-laptop" (from Option 12 in Discover)
# → MAC aa:bb:cc:dd:ee:ff
# Log: "ajay-laptop (aa:bb:cc:dd:ee:ff / 192.168.1.50) queried malware.com"

/* Dynamic ARP Inspection uses the binding table */
# ARP from GigE0/1: "aa:bb:cc:dd:ee:ff owns 192.168.1.50"
# Match binding table → VALID, forward
# ARP from GigE0/1: "aa:bb:cc:dd:ee:ff owns 192.168.1.1" (gateway!)
# Not in binding table → DROP → ARP poisoning attack blocked

NGFW POLICY — SMTP, FTP, AND DHCP TOGETHER

🛡️

Complete NGFW Policy Reference for These Protocols

POLICY

Protocol	Direction	Ports	NGFW Action	Why
SMTP (server relay)	Outbound	TCP 25	Allow from mail server IP only. Block from all other internal hosts.	Prevent spam from compromised internal hosts (only your MTA should send port 25)
SMTP Submission	Outbound	TCP 587	Allow with SSL inspection	Employee mail clients. SSL inspection enables credential theft detection
SMTP inbound	Inbound	TCP 25	Proxy mode — SMTP ALG. Full inspection: SPF/DKIM/DMARC, antivirus, anti-spam, attachment policy	Primary malware and phishing delivery channel
Plain FTP	Both	TCP 21	Block at internet perimeter. Allow internally with ALG and file scanning.	Plaintext credentials. Use SFTP externally.
SFTP	Both	TCP 22	Allow with DPI for known-good destinations. Log all file transfers.	Secure replacement for FTP. Still log for DLP.
DHCP client	Inbound/Outbound	UDP 67/68	Allow on internal interfaces. Enable DHCP snooping on switch ports.	Required for IP assignment. Snooping prevents rogue servers.
DHCP server from external	Inbound	UDP 67	Block at internet perimeter	External DHCP servers have no business sending to internal networks
SMTP AUTH brute force	Inbound	TCP 587	Rate-limit per source IP. Block after 5 AUTH failures in 60 seconds.	Credential stuffing against email accounts
Open SMTP relay	Inbound	TCP 25	Block RCPT TO for domains not hosted on your server (relay blocking)	Open relays used by spammers to abuse your server's reputation

📊

Protocol-Specific NGFW Inspection Architecture

ARCHITECTURE

/* SMTP inspection pipeline in NGFW */

Inbound SMTP:
  1. TCP accept on :25 (SMTP proxy mode)
  2. Banner response: "220 ngfw.example.com ESMTP"
  3. Parse EHLO → log sender hostname
  4. Parse MAIL FROM → SPF check (DNS lookup)
  5. Parse RCPT TO → check recipient against policy
  6. Greylisting check (first time from this IP+from+to?)
  7. Receive DATA → buffer entire message (DKIM verify requires full message)
  8. Run antivirus on attachments (decode MIME, decompress, scan)
  9. Run content/DLP scan on body
  10. DKIM verify → check DNS signature
  11. DMARC policy enforcement
  12. Apply spam score (RBL check, heuristics, ML model)
  13. If allowed: forward to internal mail server
  14. Log result: allowed/blocked/quarantined + scores

/* FTP ALG pipeline */

Outbound FTP:
  1. Track TCP connections to :21 as FTP control sessions
  2. Parse commands in control stream
  3. On PASV response: rewrite server IP if needed
  4. On PORT command: rewrite client private IP → public IP
  5. Add dynamic conntrack entry for data channel
  6. On data channel connection: apply file inspection policy
  7. On data channel close: remove dynamic entry
  8. Log: client, server, files transferred (via CWD/RETR/STOR tracking)

/* DHCP identity tracking */

On DHCP ACK intercept:
  Extract: client MAC (chaddr), offered IP (yiaddr), hostname (option 12)
  Update identity table: IP → MAC → hostname → lease_expiry
  Notify NGFW policy engine: "10.0.0.50 is now ajay-laptop (aa:bb:cc:dd:ee:ff)"
  Policy can now reference "ajay-laptop" in rules, not just IP

LAB 1

SMTP Session Analysis and SPF/DKIM Verification

Objective: Send a real SMTP session manually using telnet/openssl, capture and decode the exchange, and verify email authentication headers.

Interact with a local SMTP server manually using netcat: nc -v localhost 25. If you have postfix installed (sudo apt install postfix, choose "Local only"), type the full SMTP sequence: EHLO, MAIL FROM, RCPT TO, DATA with headers and body, ending with a single dot. Watch the reply codes at each step.

Capture the session: sudo tcpdump -i lo -A 'port 25' in parallel. Observe the plaintext commands and responses in the capture. Identify: MAIL FROM envelope address, DATA section start/end (354 → single dot), reply codes.

SPF checking: write a Python script that takes a domain and sending IP, fetches the SPF TXT record (using dnspython: pip install dnspython), and evaluates whether the IP is permitted. Test: check_spf("google.com", "209.85.220.41") should return PASS. Test with a random IP — should return SOFTFAIL or FAIL.

DKIM verification: take a real email from your inbox (in a desktop client, "Show Source" or "View Headers"). Find the DKIM-Signature header. Extract the selector and domain (s= and d= fields). Fetch the public key: dig TXT {selector}._domainkey.{domain}. Verify the signature using Python's dkimpy library or just understand the components.

DMARC policy lookup: write a script that fetches and parses _dmarc.{domain} TXT records for 5 domains (google.com, amazon.com, github.com, a small company, your own domain if you have one). Display: policy (none/quarantine/reject), rua report address, pct (percentage), and interpret what would happen to a spoofed email from each domain.

Bonus — STARTTLS upgrade: Connect to an SMTP server that supports TLS: openssl s_client -starttls smtp -connect smtp.gmail.com:587. After the TLS handshake, you're at an SMTP prompt over encrypted connection. Type EHLO and verify the capabilities. Note the certificate presented.

LAB 2

FTP ALG Analysis and DHCP Dissection

Objective: Set up a local FTP server, observe the two-channel architecture and PORT/PASV commands in Wireshark. Then capture and decode a complete DHCP DORA exchange.

FTP setup: Install vsftpd: sudo apt install vsftpd. Configure for local user access. Start: sudo systemctl start vsftpd. Connect: ftp localhost. Run ls and get /etc/hostname.

Capture with Wireshark: filter ftp or ftp-data. In the FTP stream, find the PASV or PORT command. For PASV: decode the 6 numbers in the response (IP = first 4 numbers as octets, Port = 5th×256 + 6th). Verify that Wireshark shows a separate TCP stream for the data channel on the calculated port.

Compare active vs passive: configure your FTP client to use active mode: ftp -A localhost. Capture the PORT command — find your IP and ephemeral port encoded in it. Compare the data channel initiation direction: in active mode the server connects to the client; in passive the client connects to the server.

DHCP capture: Start a Wireshark capture on a VM's interface with filter bootp or dhcp. Force a DHCP renewal: sudo dhclient -r eth0 && sudo dhclient eth0. You should see all four DORA packets. For each: identify the message type (Option 53), the transaction ID (xid), and the offered IP (yiaddr in Offer/ACK).

Decode DHCP options: in Wireshark, expand the "Bootstrap Protocol" section in the DHCP ACK packet. Find and record: Option 1 (subnet mask), Option 3 (router/gateway), Option 6 (DNS servers), Option 12 (hostname), Option 51 (lease time in seconds), Option 53 (DHCP message type). Convert the lease time from seconds to hours.

Bonus — DHCP starvation simulation (safe, on your own VM only): Use scapy to send multiple DHCP Discovers with random MAC addresses:

from scapy.all import *; [sendp(Ether(src=RandMAC())/IP(src="0.0.0.0",dst="255.255.255.255")/UDP(sport=68,dport=67)/BOOTP(chaddr=RandString(6))/DHCP(options=[("message-type","discover"),"end"])) for _ in range(20)]

. Observe: does your DHCP server's lease pool shrink? How many genuine IPs can still be assigned?

M09 MASTERY CHECKLIST

Know the email protocol stack: MUA → port 587 → MSA → port 25 → MTA → IMAP/POP3 → MUA
Know the three SMTP ports and their purposes: 25=server-to-server relay, 587=client submission (AUTH), 465=SMTPS (TLS from connect)
Know why ISPs block outbound TCP 25: prevent spam from compromised machines
Can walk through a complete SMTP session: EHLO → STARTTLS → AUTH → MAIL FROM → RCPT TO → DATA → dot → QUIT
Know SMTP reply code categories: 2xx=success, 4xx=temporary (retry), 5xx=permanent (don't retry)
Know 8 specific SMTP reply codes: 220, 221, 235, 250, 354, 421, 535, 550
Understand envelope vs message headers: MAIL FROM/RCPT TO (routing) vs From:/To: (display) — these can differ enabling spoofing
Know SPF: DNS TXT record listing authorised sending IPs; checked against MAIL FROM envelope sender
Know DKIM: cryptographic signature over message headers+body; public key in DNS at selector._domainkey.domain
Know DMARC: policy (none/quarantine/reject) applied when SPF and DKIM both fail; stored in _dmarc.domain TXT
Know 7 NGFW email inspection capabilities: SMTP proxy, attachment AV, content/DLP, SPF/DKIM/DMARC enforce, anti-spam, greylisting, URL reputation
Know FTP's two-connection architecture: control channel (TCP 21 — persistent) + data channel (dynamic port — per-transfer)
Know Active FTP: client sends PORT command with its IP:port; server connects back to client (breaks client NAT)
Know Passive FTP: client sends PASV; server provides its IP:port; client connects to server (works through client NAT)
Know why EPSV was added: IPv6-compatible passive mode that only returns port number, not IP
Understand the ALG problem: FTP embeds IP:port in payload; NAT changes outer IP but not payload; ALG must rewrite payload
Know 6 steps of FTP ALG operation: identify control connection, parse PORT/PASV, rewrite IP, add dynamic firewall rule, scan data, remove rule on close
Know why FTPS breaks ALG: encrypted control channel — ALG cannot read PORT/PASV; solution: use SFTP instead
Know FTP security issues: plaintext credentials, anonymous FTP abuse, FTP bounce attack, ALG requirement
Know DHCP DORA: Discover (broadcast, no IP yet) → Offer (server reserves IP) → Request (client claims IP) → ACK (server confirms)
Know DHCP uses UDP 68 (client) → UDP 67 (server) with broadcast addressing (0.0.0.0 → 255.255.255.255)
Know the xid field: transaction ID matching Discover to Offer/ACK
Know key DHCP option numbers: 1=subnet mask, 3=gateway, 6=DNS, 12=hostname, 51=lease time, 53=message type
Know DHCP lease lifecycle: T1 (50% of lease) = unicast renewal, T2 (87.5%) = broadcast rebind, expiry = restart DORA
Know 4 DHCP attacks: rogue DHCP server, DHCP starvation, relay agent spoofing, IP conflict
Know DHCP snooping: switch blocks DHCP server responses from untrusted ports; builds IP-MAC-port binding table
Know how DHCP snooping enables DAI and identity-based logging: IP → MAC → hostname correlation
Completed Lab 1: sent manual SMTP session via netcat, wrote SPF checker in Python, decoded DKIM header fields
Completed Lab 2: captured FTP active/passive sessions, decoded PORT/PASV port calculation, captured full DHCP DORA, decoded all DHCP options

🎉 Phase 2 Complete — Transport and Application Protocols

You have completed all 5 modules of Phase 2: TCP (M05), UDP and ICMP (M06), DNS (M07), HTTP/1.1–3 and QUIC (M08), and SMTP, FTP, DHCP (M09). You now understand every major protocol that an NGFW must inspect, filter, and protect. Move to Phase 3 — Routing and Forwarding, starting with M10 - Routing Fundamentals and FIB.

← M08 HTTP 🗺️ Roadmap Next: M10 - Routing and FIB →