Network Security and Defense Questions

A man-in-the-middle (MITM) attack is when an attacker inserts themselves between two communicating parties, either just observing the traffic (passive interception) or actively changing it (active manipulation), without either legitimate party realizing a third party is involved.

Passive vs active techniques

• Passive interception: the attacker taps traffic without altering it, for example by mirroring a switch port, running a rogue access point, or using ARP spoofing purely to redirect traffic through themselves for silent capture. This is a confidentiality violation only.
• Active manipulation: the attacker changes what each side sees.
  • ARP spoofing (ARP poisoning): since the Address Resolution Protocol has no authentication, the attacker sends forged ARP replies mapping a real IP (often the default gateway) to the attacker's own MAC address, so victim traffic is routed through the attacker.
  • TLS stripping: the attacker sits between the client and server and intercepts the client's initial plaintext HTTP request before it upgrades to HTTPS, keeping the client on cleartext HTTP while the attacker proxies the real connection to the server over HTTPS. The user's browser shows a working connection, but everything between the client and attacker is unencrypted.

Detection telemetry

• Network layer: ARP table and gateway-MAC monitoring (one MAC suddenly claiming an IP it never has, or the gateway's MAC changing), unsolicited/gratuitous ARP replies, rogue DHCP (Dynamic Host Configuration Protocol) servers, switch port-security violations, and traceroute or latency anomalies suggesting an extra hop.
• Application layer: certificate mismatches or downgrade attempts in browser/proxy logs, requests arriving over plain HTTP where HTTPS was expected, violations of HTTP Strict Transport Security (HSTS) policy, and session tokens being used from two different IP addresses or user agents within seconds of each other.

Worked example

Attacker on the same LAN as the victim broadcasts a gratuitous ARP reply: "10.0.0.1 (the gateway) is at AA:BB:CC:DD:EE:FF (attacker's NIC)." The victim's ARP cache updates, so all of the victim's gateway-bound traffic now flows through the attacker first. If the switches run Dynamic ARP Inspection (DAI) against a DHCP-snooped IP-to-MAC binding table, that same forged reply is compared to the trusted binding, found not to match, and dropped and logged instead of being accepted, which is exactly the detection signal described above.

Two immediate mitigations

1. Enable Dynamic ARP Inspection plus DHCP snooping on access switches, so ARP replies are validated against a trusted binding table and spoofed ones are dropped at the switch.
2. Enforce HSTS and disable any HTTP fallback on externally reachable services, so a stripping attempt has no plaintext path to downgrade to.

Trade-offs and pitfalls

Dynamic ARP Inspection only protects the Layer 2 segment it is deployed on, it does nothing for MITM happening outside your own switches (a public Wi-Fi hotspot, for example). HSTS only protects repeat visits unless the domain is preloaded in browsers, so there is a first-visit gap. Detection controls alone (without prevention) still leave a real exposure window between the attack starting and someone acting on the alert.

A denial of service (DoS) attack makes a service unavailable to legitimate users by overwhelming or disrupting it from one source. A distributed denial of service (DDoS) attack does the same thing from many distributed sources at once, usually a botnet, which makes it both larger and much harder to stop by simply blocking one source address.

The three attack categories

Immediate mitigation for an external-facing web service

• Volumetric: reroute traffic through an upstream scrubbing or anycast provider so the flood is absorbed before it ever reaches your link.
• Protocol: enable SYN cookies at the edge so half-open connections stop consuming connection-table memory.
• Application: put a web application firewall (WAF) and a request-shape-aware rate limiter in front of the specific endpoint under attack, and add a challenge (CAPTCHA or a JavaScript check) for suspicious clients if it continues.

Worked example

Baseline traffic to a checkout site's search endpoint is around 200 requests per second. During an application-layer attack, that jumps to 20,000 requests per second, a 100x increase, coming from 8,000 distinct source addresses, averaging only 2.5 requests per second per address. No single address looks abusive on its own, which is exactly why this class of attack cannot be caught by per-IP volume alone. What gives it away is the request shape: all of the traffic concentrates on one expensive endpoint, and the requests never fetch the CSS, JavaScript, or images a real browser would load alongside the page, unlike a genuine flash-crowd traffic spike.

Trade-offs and pitfalls

Blocking purely on volume risks throttling a real, legitimate surge in popularity along with an actual attack, so good mitigation distinguishes attack traffic from a real spike by shape (endpoint concentration, missing follow-on requests, source diversity) rather than count alone. Aggressive layer-7 challenges reduce false negatives but annoy or lock out real users, and upstream scrubbing adds cost and a small amount of latency even to legitimate traffic.

A secure Software-Defined Wide Area Network (SD-WAN, an overlay network where a central controller programs encrypted tunnels and routing policy across many sites rather than each site being hand-configured) for 200 branches needs a policy model that segments by application rather than by branch, centralized key management the controller drives rather than manual per-site work, and a default-deny posture between segments enforced locally at every branch edge.

Policy model

Define a small number of application-level segments (for example: point-of-sale, corporate IT, guest/BYOD, IoT/building systems), independent of which branch a device sits in, and express policy as segment-to-segment rules rather than branch-to-branch rules. A compromised guest-segment device at branch 12 should be unable to reach the point-of-sale segment at branch 87 by default, regardless of the underlying encrypted overlay connecting those two sites. Default-deny between segments, with a short, auditable allow-list of the specific cross-segment paths the business actually needs (for example, point-of-sale needs to reach a central payment gateway segment, nothing else).

Key distribution and rotation

Each branch edge device is provisioned with a unique device identity certificate at onboarding, issued by an internal certificate authority the SD-WAN controller manages or delegates to. Tunnels (built on IPsec, or the vendor's own encrypted overlay protocol) authenticate using these certificates rather than a single shared pre-shared key across all 200 sites, so compromising one branch's key material does not expose the others. The controller drives automated, scheduled key/security-association rotation and certificate renewal well before expiry, which matters specifically because 200 sites makes manual rotation impractical and error-prone.

Orchestration

A centralized controller computes and pushes the segment policy and tunnel configuration to every branch edge as policy-as-code, so a new branch can be zero-touch provisioned (ship the device, it phones home to the controller, receives its identity and policy, and is live) instead of an engineer configuring it by hand. Branch edges report policy compliance and drift back to the controller, so a device whose local configuration has diverged from the centrally-computed intent is visible rather than silently inconsistent.

Inter-branch traffic and exception workflows

Enforcement happens locally at each branch edge, not only centrally: the edge device itself computes and applies the same policy the controller pushed, so even a branch that's temporarily disconnected from the controller keeps enforcing its last-known-good policy rather than failing open. Exceptions (a specific application at a specific branch needing a cross-segment path not covered by the standard policy) go through a scoped, time-limited approval workflow: a request ties to a specific source segment, destination segment, and expiry, is approved by a named owner, and is pushed only to the branches actually involved, with automatic expiry and an audit log entry, never a blanket or permanent carve-out.

Trade-offs

Centralizing policy computation creates a single point of control whose compromise or outage is high-impact; mitigate with controller high-availability and by ensuring branch edges cache and keep enforcing their last policy during any controller outage rather than depending on constant connectivity to the controller to remain secure. Keeping the segment count small (application-level, not branch-level) is what keeps the 200-site policy matrix tractable; a bespoke per-branch ruleset at this scale becomes unauditable and is the more common real-world failure mode than any cryptographic weakness in the design.

Several widely-deployed legacy protocols transmit everything, including credentials, in plaintext, and each has a secure, encrypted successor that should replace it. The right approach to migration is a short-term compensating control paired with a tracked long-term replacement, not an instant rip-and-replace that a legacy environment often cannot support on day one.

The pairs

Migration strategy per pair

• Telnet to SSH: short-term, restrict Telnet to an isolated management network with strict access control and close monitoring if some legacy device firmware cannot be upgraded immediately; long-term, disable the Telnet daemon entirely and enforce SSH-only management.
• FTP to SFTP/SCP: short-term, confine any remaining FTP service to internal-only networks and never expose it to the internet; long-term, migrate transfer scripts and workflows to SFTP and decommission the FTP service.
• HTTP to HTTPS: short-term, add an HTTP-to-HTTPS redirect and obtain a valid TLS certificate; long-term, enforce HTTPS-only with HTTP Strict Transport Security (HSTS) so browsers refuse to fall back to plaintext even if an attacker tries to intercept the initial redirect.

Worked example

An analyst runs a network scan and finds 40 internal hosts still answering on port 23 (Telnet) and 12 legacy file servers on port 21 (FTP), while the customer-facing website already redirects HTTP to HTTPS. Short-term mitigation applied immediately: a firewall rule restricts ports 23 and 21 to the management subnet only, cutting exposure to the general LAN and internet to zero without waiting for a change window. Long-term: a tracked migration ticket per host group targets a move to SSH and SFTP with a decommission date, and any device whose firmware genuinely cannot be updated in time gets its own documented compensating control (isolation plus logging) rather than being quietly left exposed.

Trade-offs and pitfalls

Some embedded or legacy hardware genuinely cannot support SSH or TLS, so isolation is a legitimate interim step, not an excuse to defer the migration indefinitely. And enabling HTTPS without also enforcing a redirect and HSTS still leaves the plaintext path reachable, which defeats much of the purpose of migrating in the first place.

Direct answer

A state-exhaustion attack doesn't need to saturate bandwidth; it only needs to open, or half-open, more connections than a stateful device can track at once, so the device's connection table fills up and starts dropping legitimate traffic. The classic case is a SYN flood: the attacker sends a stream of TCP SYN packets and never completes the three-way handshake, leaving each one occupying a half-open slot until it times out.

Structured elaboration

• Mechanism. Every stateful device (a firewall, a load balancer, or a host's own TCP stack) keeps a finite table sized in entries, not bandwidth. A half-open connection occupies a slot until the handshake completes or an embryonic-connection timeout expires, so even a modest packet rate can fill the table without generating much traffic volume at all.
• Device metrics that indicate state exhaustion:
  • Current connection or session table utilization against its configured maximum, usually exposed directly by firewalls and load balancers.
  • A rising count of half-open or embryonic connections specifically, distinct from established sessions.
  • A "session table full" or connection-drop counter incrementing, separate from ordinary access-control-list deny counters.
  • Control-plane CPU or memory pressure correlated with the connection-table spike, since state tracking has a per-entry cost.
  • New connections per second rising sharply while completed handshakes or established sessions do not rise proportionally.
• Immediate edge mitigations:
  • SYN cookies. Instead of allocating a table entry on the first SYN, the device encodes connection state cryptographically into the SYN-ACK sequence number and only allocates a real entry once the final ACK proves the handshake is genuine, making the device effectively stateless until a handshake actually completes.
  • Shorter embryonic timeouts, so abandoned half-opens free their slot faster.
  • Per-source rate limiting on new SYNs, though this is weaker against spoofed source addresses (see pitfalls below).
  • Upstream offload to a scrubbing appliance or cloud DDoS mitigation service when the device's own table is the actual bottleneck, so the flood never reaches the constrained device.

Worked example

An edge firewall has a session table sized for 500,000 concurrent entries, and each half-open SYN occupies one entry until a 60-second embryonic timeout expires. An attacker sustaining 20,000 spoofed SYNs per second fills that table in

$\frac{500{,}000 \text{ entries}}{20{,}000 \text{ SYNs/sec}} = 25 \text{ seconds}$

which is well before the 60-second timeout would have freed anything, so every new legitimate connection attempt gets dropped once the table fills. Notice this happens despite modest bandwidth: 20,000 bare SYN packets per second at roughly 60 bytes each is only about 1.2 megabytes per second, far below what a volumetric flood would need, which is exactly why state exhaustion is a distinct attack category from bandwidth saturation.

Trade-offs and pitfalls

SYN cookies trade away carrying some TCP options negotiated in the original SYN in exchange for statelessness; modern implementations narrow this gap but it's a real trade-off, not a free win. Lowering embryonic timeouts too aggressively can drop legitimate slow clients on high-latency links as collateral damage. Per-source-IP rate limiting is largely defeated when the attacker spoofs many different source addresses, which SYN floods commonly do, so it needs to be paired with device-wide limits or upstream scrubbing capacity rather than relied on alone.