Network Security

Network Security#

In the World Wide Web chapter, we briefly touched on DNS and the layers that make internet communication possible. Now it’s time to dig deeper into the network itself.

The main observation about network security is simple: you can write whatever you want in the packets you send. There’s nothing that prevents a computer from crafting a packet with a forged source address, fake headers, or other nasty things. Moreover, most of network protocols we use daily were designed in a more trusting era, and while some security mechanisms have been added to them over the years, they are not perfect.

Passive vs. Active Attacks#

Before we dive into specific attack techniques, let’s establish an important distinction. Network attacks can be broadly categorized as passive or active.

Passive attacks involve only observing network traffic without modifying it. An attacker positioned on your local network, at your ISP, or anywhere along the path your packets travel can potentially see what you’re sending and receiving. This is often called eavesdropping or sniffing.

Active attacks involve actually modifying, injecting, or blocking network traffic. This includes the Man-in-the-Middle (MITM) attack, where an attacker positions themselves between two communicating parties and can read, modify, or inject messages.

Encryption (like TLS) defeats passive attackers – even if they can see your traffic, they can’t understand it. However, encryption alone doesn’t defeat active attackers. An active attacker can perform a MITM attack by establishing separate encrypted connections with each party. This is why authentication is equally important – you need to verify you’re actually talking to who you think you’re talking to. We already covered this in the Cryptography chapter.

Protocol Vulnerabilities#

Let’s explore how various network protocols can be abused. We’ll start from the local network and work our way up.

ARP Spoofing#

The Address Resolution Protocol (ARP) is used on local networks to map IP addresses to MAC (hardware) addresses. When your computer wants to send a packet to 192.168.1.1, it needs to know the MAC address of that device so it can address the Ethernet frame correctly.

ARP works by broadcasting a question: “Who has IP 192.168.1.1? Tell me your MAC address.” The device with that IP responds with its MAC address, and your computer caches this mapping.

However, ARP has no authentication whatsoever. Any device on the local network can respond to ARP requests – even if it’s not the device being asked about. An attacker can send unsolicited ARP replies claiming that they are the gateway and if a devices receives this fake ARP reply before they receive the legitimate one, traffic from that device will flow to attacker’s machine.

Normal situation:
  Victim -> Gateway -> Internet

After ARP spoofing:
  Victim -> Attacker -> Gateway -> Internet
              ^^^
             MITM!

The attacker can now see all traffic, modify it, or selectively drop packets. Tools like Bettercap and arpspoof make this very easy on a local network.

A defense is to monitor your network for rogue ARP packets, and block them entirely if possible. Segmenting your network, for example using VLANs, can help divide devices with different levels of trust.

DNS Spoofing/Cache Poisoning#

We covered DNS in the WWW chapter. DNS is the distributed database that translates human-readable hostnames to IP addresses. Given its critical role in directing traffic, it’s a prime target for attackers.

DNS responses are cached to reduce load on nameservers. If an attacker can inject a false response into a DNS cache, all users of that cache will be directed to the attacker’s server.

The classic attack works like this:

  1. Attacker sends many DNS queries to a resolver for bank.com
  2. Simultaneously, attacker floods the resolver with forged responses pretending to be from bank.com’s authoritative nameserver
  3. If a forged response arrives before the real one and matches the query ID, it gets cached
  4. Now everyone using that resolver is directed to the attacker’s server for bank.com

This works because DNS uses UDP and a query and response are one packet each. If you can successfully predict the source port and transaction ID which the resolver used AND get your spoofed answer before the real one, the server has no way of knowing which one is correct and will most likely use the first one.

Modern defenses against DNS spoofing include using randomized source ports and transaction IDs, which makes it harder to guess the right values for a forged response. DNSSEC provides cryptographic signatures for DNS records, allowing verification of authenticity. Additionally, DNS over HTTPS (DoH) and DNS over TLS (DoT) encrypt DNS traffic, preventing MITM attacks on the DNS protocol itself.

UDP#

UDP (User Datagram Protocol) is a connectionless protocol. Unlike TCP, there’s no handshake, no sequence numbers, and no acknowledgments. You simply send a packet with a source address, destination address, and data.

This simplicity makes UDP perfect for certain applications (DNS, video streaming, gaming), but it also makes it trivially easy to spoof. Since there’s no connection state to verify, the recipient has no way to confirm that a UDP packet actually came from the claimed source.

Amplification and Reflection Attacks#

This brings us to one of the most common DDoS (Distributed Denial of Service) techniques: amplification attacks. The idea is quite simple:

  1. Find a service that responds to small requests with much larger responses
  2. Send requests to that service with the victim’s IP as the source (spoofing)
  3. The service sends the large responses to the victim, not the attacker

Popular amplification vectors include:

The Memcached amplification is particularly absurd – a 15-byte request can generate a 750KB response! In 2018, GitHub was hit with a 1.35 Tbps attack using Memcached amplification.

The defense is primarily at the network level: BCP38 (RFC 2827) recommends that ISPs filter outgoing traffic to ensure packets actually have source addresses from their network (ingress filtering). Unfortunately, adoption is incomplete.

TCP#

TCP (Transmission Control Protocol) is connection-oriented and includes sequence numbers, making spoofing harder.

TCP Session Hijacking#

If an attacker can MITM a TCP connection (via ARP spoofing, for instance), they can inject packets into the session. They know the sequence numbers, port numbers, and all other required values. This allows them to:

  • Inject malicious packets into unencrypted connections (HTTP, Telnet, …)
  • Terminate connections by sending RST (reset) packets

SYN Flood#

The TCP three-way handshake (SYN -> SYN-ACK -> ACK) requires the server to maintain state for pending connections. An attacker can exhaust server resources by sending many SYN packets with spoofed source addresses and never completing the handshake.

Modern defenses include SYN cookies – a clever technique where the server encodes connection state in the sequence number itself, eliminating the need to store state until the handshake completes.

Slowloris#

Slowloris type of attacks exploit how TCP servers handle connections (mostly HTTP). It’s a “slow” attack that keeps many connections to the target web server open and held open as long as possible.

The attacker opens many connections and does the minimum to keep them all alive - sending byte-by-byte, HTTP header by HTTP header. Just in time to not trigger the timeouts, but to prolong the request handling as much as possible.

This has been patched in all the most popular HTTP servers.

BGP Hijacking#

Now we get to the really scary stuff. BGP (Border Gateway Protocol) is the protocol that holds the internet together. It’s how autonomous systems (AS) – large networks like ISPs, universities, and companies – tell each other which IP address ranges they can route traffic to.

BGP was designed in 1989 when the internet was a small, trusted community. It has no built-in authentication. If your AS announces that it can route traffic to Google’s IP ranges… other routers might believe you and start sending Google’s traffic your way.

Notable incidents:

Resource Public Key Infrastructure (RPKI) allows networks to cryptographically attest to which AS is authorized to announce specific IP prefixes. Even with RPKI, BGP hijacking remains possible – just harder.

For more information about BGP and related protocols, we recommend NSWI184 – Computer Network Management.

Defense Mechanisms#

Firewalls#

A firewall filters network traffic based on rules. The simplest form examines packet headers (source/destination IP, ports, protocol) and decides whether to allow, drop, or reject each packet.

Stateful firewalls track connection state. They can enforce rules like “allow outgoing connections but block incoming unless they’re part of an established connection.” This is the default behavior of most NAT routers. On Linux there is for example nftables.

Application-layer firewalls (also called Layer 7 firewalls or WAFs – Web Application Firewalls) inspect the actual content of traffic. They can detect and block SQL injection attempts, XSS payloads, and other application-specific attacks. Although it might sound tempting to “fix” and prevent security issues on WAF-level, it is a bad idea to rely solely on WAFs for that, as usually the malicious payload can have many forms. Some of them even not being representable with regular expressions most WAFs are configured with.

IDS/IPS: Intrusion Detection and Prevention#

An Intrusion Detection System (IDS) monitors network traffic for suspicious patterns and alerts administrators. An Intrusion Prevention System (IPS) goes further – it can automatically block detected threats.

These systems use two main approaches:

  • Signature-based detection: Matches traffic against known attack patterns, (example). Fast way to block the most obvious known attacks, but can’t detect novel threats.
  • Anomaly-based detection: Builds a baseline of “normal” traffic and alerts on deviations.

Snort and Suricata are popular open-source IDS/IPS solutions.

VPNs: Virtual Private Networks#

A VPN creates an encrypted tunnel between your device and a VPN server. All your traffic travels through this tunnel, emerging at the VPN server’s location.

VPNs provide:

  • Confidentiality: Traffic between you and the VPN server is encrypted, your ISP cannot see it
  • Location privacy: Destinations see the VPN server’s IP, not yours

However, VPNs are not magic:

  • The VPN provider can see all your traffic (you’re just moving trust from your ISP to them)
  • Traffic beyond the VPN server to the destination is not protected by the VPN anyway - if you do not use encryption, your traffic will be visible

Enterprise VPNs are commonly used to give remote employees secure access to internal company networks, or to connect multiple networks separated by physical distance together securely.

Tor: The Onion Router#

Tor provides anonymity by routing your traffic through multiple relays, each of which only knows the previous and next hop. This “onion routing” makes it very difficult to trace traffic back to its origin.

Your traffic path through Tor:

You -> Guard Node -> Middle Relay -> Exit Node -> Destination
      (knows you)   (knows nothing)  (knows destination)

When sending a packet, you first figure out a route (usually called a “circuit”) of publicly known nodes which will deliver the packet to the destination. Then, you create a packet with instructions on how to communicate with your destination and encrypt it with the public key of the last node in the circuit (the exit node). Then, you craft a new packet, with instructions on how to send this encrypted payload to the exit node and encrypt it with the public key of the second-to-last node in your chosen circuit. You continue to add layers until you’ve got a packet you can send directly to the first node in the circuit.

Each node then decrypts one layer using its private key and only learns the about the address about the next node in the circuit (and also knows the previous one, since it knows where the packet came from). The exit node also has access to the full unencrypted message you want to send the server, so you should secure it using other means.

The whole communication also has to be stateful – all the nodes need to remember where the packets came from so they can send the response back.

It’s used for hidden services (.onion addresses) that can be accessed only through Tor, providing anonymity for servers as well as clients – this is called the dark net.

While Tor provides some form of anonymity by obfuscation, it’s not perfect. Advanced adversaries who can observe large portions of the internet might correlate traffic timing. Even worse, certain three-letter agencies are suspected of running large parts of the onion network by themselves.

Reconnaissance: Mapping the Network Attack Surface#

Before attacking a target over the network, an attacker needs to understand what’s there. This reconnaissance phase uses various tools to discover hosts, services, and potential vulnerabilities.

Nmap: The Network Mapper#

Nmap is the industry-standard tool for network discovery and security auditing. It can:

  • Discover live hosts: Find which IP addresses have active devices
  • Port scanning: Determine which ports are open and what services are running
  • Service detection: Identify the specific software and version on each port
  • OS detection: Fingerprint the operating system
  • Script scanning: Run specialized scripts to detect vulnerabilities
# Basic scan of a single host
nmap 192.168.1.1

# Scan a subnet, detect services and OS
nmap -sV -O 192.168.1.0/24

# Aggressive scan with scripts
nmap -A target.com

# Stealth SYN scan (doesn't complete TCP handshake)
nmap -sS target.com

DISCLAIMER: Port scanning infrastructure without permission is in the grey-area legally. While a lot of scanning happens all the time all over the internet, you should not be surprised if your ISP doesn’t like it.

Shodan: The Search Engine for Everything#

While Google indexes web pages, Shodan indexes internet-connected devices. It continuously scans the entire internet, recording what services are running and their responses (banners).

The Relationship with Cryptography#

Network security and cryptography are deeply intertwined. As we discussed in the Cryptography chapter, encryption provides confidentiality and integrity, while authentication ensures you’re talking to the right party.

Transport Layer Security#

As we’ve discussed at the end of the Cryptography chapter, maintaining a secure communication channel with someone once you exchanged your keys in private is easy (well, easy in the sense that someone already figured out how to do it), but exchanging keys without a secure channel is by definition impossible. TLS aims to solve this issue by creating a hierarchy of digital certificates. Each party you want to communicate with (for simplicity, let’s say a website, like google.com) sends you their public key alongside a certificate signed by someone you trust that the public key really belongs to them. But who can you trust for signing public keys and how can you get their public key in a secure way? TLS establishes Certification Authorities, organizations, which the community at large agrees can be trusted to only give out certificates to their rightful owners (for instance by verifying the requester owns a specific domain). These CAs have their own certificates issued by other CAs higher in the hierarchy, up to the root CA, the public key of which is placed into your device by the manufacturer, or the maintainer of your OS or browser. When you try to connect to a website, it gives you the full chain of certificates, so you can verify it yourself just using the root CA keys in your device.

TLS is most commonly used to secure HTTP, but is also commonly used for other TCP protocols, and in theory can be used to establish an arbitrary secure channel over TCP.

Since a server might serve multiple websites with different hostnames and thus different certificates, the client has to send it the hostname of the website it wants to connect, so the server can send back the right certificate. This however allows any eavesdropping party to figure out the hostname of the server you’re connecting to, not just the IP address.

There are multiple versions of TLS. There are SSL 2.0 and 3.0 and TLS 1.0, 1.1, 1.2 and 1.3 (SSL was renamed to TLS). All but TLS 1.2 and 1.3 are considered more or less insecure and should not be used.

TLDR#

  • You can write whatever you want in packets you send.
  • Passive attacks (eavesdropping) are defeated by encryption; active attacks (MITM) require both encryption and authentication.
  • ARP spoofing enables MITM on local networks by forging MAC-to-IP mappings.
  • DNS attacks can redirect traffic by poisoning caches or hijacking records.
  • UDP’s lack of connection state enables amplification attacks for massive DDoS.
  • BGP hijacking can redirect traffic at the internet backbone level – there’s no authentication.
  • Reconnaissance tools like Nmap and Shodan help both attackers and defenders understand the attack surface.
  • TLS is nice – use it where possible and verify certificates.

Further Resources#