8.3 Port Scanning, DDoS, and Man-in-the-Middle

8.3 Port Scanning, DDoS, and Man-in-the-Middle

Network attacks in SAL1 training content include port scanning, distributed denial of service (DDoS), and man-in-the-middle (MitM, also written MiTM). This section treats them as traffic patterns and sensor stories, not as a lab to reproduce. You will not get exploit steps or scanner recipes. You will get what a firewall, netflow collector, or intrusion detection system (IDS) typically shows, and how an analyst writes the ticket.

Port scanning as a traffic pattern

A port scan is reconnaissance: which transport ports on a host or range accept connections. Scanners vary how much of the Transmission Control Protocol (TCP) handshake they complete. Those differences show up in flow records. The three-way handshake itself (SYN, SYN-ACK, ACK) is assumed from earlier networking study; here the question is how incomplete or complete sessions look when someone is enumerating ports.

SYN scan (half-open)

A SYN scan sends TCP segments with the SYN flag to many ports. If a port is open, the target replies SYN-ACK. The scanner then typically emits RST instead of completing with ACK, so an application never fully accepts the session.

Netflow and firewall picture:

• One source IP, many destination ports on one host (vertical scan) or one port across many hosts (horizontal sweep).
• Flows with tiny byte counts and durations of milliseconds.
• Flag combinations: SYN out, SYN-ACK in, RST out. Application logs stay quiet because the handshake never finished.
• Rate: tens to thousands of ports per minute, often sequential or pseudo-random.

IDS signatures historically key on "SYN to more than N ports in T seconds from one source." Tune with care: load balancers and health checks also open many short connections, but they repeat a small port set (80, 443, 8080) toward known targets.

Connect scan (full handshake)

A connect scan completes the three-way handshake and then tears down with RST or FIN. Operating-system socket APIs produce this pattern.

Compared with SYN scans:

• Firewall "connection allowed" counters increment.
• Some application banners may be collected, so IDS may see a payload byte or two.
• Host-based logs (Windows Filtering Platform, Linux sshd pre-auth) may show completed connections that immediately drop.

From a SOC chair, a connect scan is noisier on the destination and more likely to correlate with authentication failures if the scanner also tries logins. The scan itself is still reconnaissance, not yet exploitation.

UDP scans

User Datagram Protocol (UDP) has no handshake. A scanner sends a short datagram to many UDP ports. Closed ports may return ICMP Port Unreachable. Open ports may stay silent or send an application reply. Firewalls often drop UDP, which makes "open or filtered" a common ambiguous result — for operators of scanners that is a tooling problem; for analysts the observation is a burst of small UDP flows to many destination ports, often with empty or cookie-sized payloads, plus a matching burst of ICMP type 3 code 3 if the site generates them.

Do not confuse UDP scanning with UDP DDoS. Scans are many destinations or ports, low bytes. Volumetric floods are few destination ports (or one service), enormous bits per second.

DDoS types at analyst level

Denial of service (DoS) tries to make a service unavailable. Distributed DoS uses many sources (botnet, reflection). Analysts classify by what resource is exhausted, because mitigation differs.

Volumetric

The goal is to fill the circuit: gigabits of junk so legitimate packets cannot enter. Classic shapes include UDP floods and reflection, where small queries to an exposed service produce larger replies toward a spoofed victim. You do not need a construction recipe. You need the telemetry: inbound bits far above baseline, a protocol that is not the business service, source ports that look like well-known amplifier services, and a destination that is one virtual IP (VIP).

Protocol (state exhaustion)

The goal is to fill firewall, load-balancer, or host state tables. A SYN flood of half-open connections is the textbook case: many SYNs, few completed handshakes, table of embryonic connections grows. Compared with a SYN scan, a SYN flood targets one or a few ports (the real service) at a volume meant to hurt, not to enumerate. Fragmented or malformed packets that force expensive reassembly are also protocol-layer.

Application

The goal is to exhaust workers, database queries, or TLS handshakes with requests that look somewhat valid: HTTP GET floods, slow-send connections that hold sockets open, or expensive search URLs. Bits per second may look ordinary while requests per second and backend latency explode. Web application firewall (WAF) and origin logs matter more than netflow bit counters.

Flash crowds (a press hit) can mimic application DDoS. Distinguish with source reputation, geographic scatter versus a known customer base, User-Agent diversity, and whether a marketing event was scheduled.

Man-in-the-middle, conceptually

Man-in-the-middle (MitM) means an attacker or unauthorized device sits on the path and can read or modify traffic. Two pictures matter for SAL1:

1. Link-layer MitM via Address Resolution Protocol (ARP) spoofing on a local segment. Symptoms (duplicate IP, gateway MAC change) are taught in section 8.4 because they are LAN-specific.
2. Transport-layer intercept, especially TLS intercept. A box terminates Transport Layer Security (TLS), inspects plaintext, and opens a second TLS session onward. Enterprise secure web gateways do this with an internal certificate authority (CA) pushed to managed endpoints. A malicious intercept does the same idea without consent: the user sees a certificate issued by an unexpected CA, a hostname mismatch, or a sudden drop from TLS to cleartext HTTP.

Analyst observations without building an intercept:

• Certificate issuer in browser or TLS-inspection logs is not the vendor the user expected.
• HTTP CONNECT volume to an unknown proxy.
• IDS alerts for SSL stripping or expired or self-signed certs on a site that historically used a public CA.
• For LAN MitM, see 8.4: ARP tables and DHCP.

MitM is a position. Scanning is reconnaissance. DDoS is availability impact. Do not collapse them into "network attack" in a case report — name the pattern, the sensor, and the affected resource.

Detection in netflow, firewall, and IDS

Practical hunt observations (observe, do not reproduce):

• Netflow / IPFIX: top talkers, unique destination-port cardinality per source, bytes per flow, TCP flags if exported, duration. High cardinality plus low bytes suggests a scan. High bytes plus few 5-tuples suggests a transfer or a flood.
• Firewall: accept/deny counts by policy rule, SYN timeout counters, session-table utilization, geo or IP reputation hits. A deny storm on unused ports is often a scan hitting default-drop.
• IDS/IPS: rate-based scan signatures, known flood signatures, TLS anomaly signatures. Always corroborate: IDS says "SYN flood" while netflow shows a single partner prefix — that may be a mis-set threshold during a file transfer.

Escalation notes should include start and stop time, targeted CIDR or VIP, protocol and ports, whether sources look spoofed (asymmetric traffic, no return path), and whether availability actually broke (user tickets) versus a noisy recon.

The fictional bar chart in this section is a teaching baseline: a SYN-scan pattern might touch 1800 distinct destination ports in a minute from one source, a connect scan fewer because it is slower, a workstation a handful of services, and a health checker a tiny fixed set. Use cardinality first, then bytes, then application logs. That order keeps you from paging the on-call engineer for a partner's backup job that merely completed many connections to port 443.