Network security: eavesdropping, MITM and DDoS
Sniffing and ARP spoofing on a shared segment, how a man in the middle works and how certificate pinning stops it, reflection attacks, and the defensive layers that actually help.
Eavesdropping on a local network
On a shared segment, a host can often see traffic not addressed to it. ARP has no authentication, so an attacker can answer for another host's address and have traffic sent to them instead.
normal client ---> gateway (ARP says this address is at that MAC)
spoofed client ---> attacker ---> gateway
attacker replies to ARP for the gateway address with its own MAC,
then forwards the traffic so nothing looks broken- Unencrypted protocols expose credentials, tokens and content to anyone on the path.
- Even with encryption, metadata such as which hosts are contacted and how much is transferred remains visible.
- Switch port security, DHCP snooping and dynamic ARP inspection raise the cost on a managed network.
- The real fix is end-to-end encryption so that on-path access yields nothing useful.
Man in the middle
| Vector | How it works | Defence |
|---|---|---|
| Rogue access point | The client associates with the attacker's AP | Prefer known networks; verify certificates |
| ARP spoofing | Traffic is redirected on a shared segment | Dynamic ARP inspection, encryption |
| DNS spoofing | A forged answer points to the attacker | DNSSEC, DoH, and certificate validation |
| Corporate TLS interception | A trusted root is installed on the device | Certificate pinning; review the root store |
| BGP hijack | A more specific prefix is announced | RPKI, prefix filtering, monitoring |
| Malicious proxy configuration | The proxy is set by policy or PAC | Pin certificates and validate the path |
pin the public key, not only the certificate
normal validation chain -> trusted root -> hostname matches
pinning adds the leaf or intermediate public key must match a known value
benefit an attacker with a trusted-but-wrong certificate cannot intercept
cost key rotation requires a release unless multiple pins are allowedPinning is powerful and operationally sharp. Always pin at least two keys — the current and the next — and ship an update path, or an emergency rotation locks every installed client out permanently.
Denial of service and reflection
| Attack | Mechanism | Mitigation |
|---|---|---|
| Volumetric flood | Saturate the link with raw traffic | Upstream scrubbing, anycast, CDN absorption |
| SYN flood | Half-open connections exhaust the backlog | SYN cookies, backlog tuning, edge filtering |
| Reflection and amplification | Spoofed source triggers a large reply to the victim | Disable open resolvers and amplifiers, ingress filtering |
| Slowloris | Many partial requests hold connections open | Header timeouts, connection limits per client |
| Application flood | Expensive endpoints called repeatedly | Rate limits, caching, cost-based quotas |
| Cache bypass | A unique query string defeats the cache | Normalise the cache key, ignore irrelevant parameters |
# confirm you are not running an open amplifier
ss -tlnp | grep -E ':53|:123|:1900'
dig +short CHAOS TXT version.bind @your-dns-server
# rate limit at the edge rather than in the application
# nginx example
# limit_req_zone $binary_remote_addr zone=api:10m rate=20r/s;
# limit_req zone=api burst=40 nodelay;⚠️
Defence is layered because no single control stops a determined flood: absorb at the edge, rate limit per identity, time out aggressively, and cap the cost of any single request. Application-level limits on a key you cannot cheaply forge matter more than raw bandwidth.
FAQ
Is HTTPS enough against a man in the middle?
It defeats a passive eavesdropper completely. Against an attacker who can install a trusted root on the device, only pinning or an out-of-band verification helps.
Can I prevent a DDoS attack?
You cannot prevent the traffic being sent, but you can avoid being the amplifier, absorb what you can upstream, and make each request expensive enough for the attacker and cheap enough for you.
Related
TLS and HTTPS: certificates and the handshake Proxies, load balancers and CDNs
Last refreshed 2026-09-18.