Network Security Basics

Every attack crosses a network at some point. Malware phones home. Attackers move laterally between systems. Credentials travel across connections. Data gets exfiltrated. The network is both the highway attackers use and the place defenders have the clearest view of what's happening. Understanding how traffic moves — and where it can be intercepted, filtered, or blocked — is foundational to every security role from SOC analyst to penetration tester.

The TCP/IP model — a security lens

The TCP/IP model describes how data moves across networks in four layers. Security controls map directly onto these layers — understanding which layer a control operates at tells you what it can and can't see, and what it can and can't stop.

Ports and protocols — the attacker's map

Ports are logical endpoints — numbers from 0 to 65535 that tell the OS which service a packet is destined for. Well-known ports (0–1023) are assigned to standard services. Knowing which services run on which ports, and which of those services have common vulnerabilities, is part of the basic mental model every security professional carries.

Packet capture — seeing the traffic

Packet capture is the practice of recording raw network traffic for analysis. It's used in incident response to understand what data left a network, in penetration testing to intercept credentials, and in network troubleshooting to diagnose communication failures. tcpdump is the command-line tool. Wireshark is the GUI equivalent.

# Capture all traffic on interface eth0
tcpdump -i eth0

# Capture only traffic to/from a specific host
tcpdump -i eth0 host 192.168.1.50

# Capture only DNS traffic (port 53)
tcpdump -i eth0 port 53

# Capture HTTP traffic and show packet contents
tcpdump -i eth0 -A port 80

# Save capture to file for Wireshark analysis
tcpdump -i eth0 -w /tmp/capture.pcap

# Read a saved capture and filter for failed TCP handshakes (SYN with no SYN-ACK)
tcpdump -r /tmp/capture.pcap 'tcp[tcpflags] & tcp-syn != 0 and tcp[tcpflags] & tcp-ack == 0'

DNS — the protocol that leaks everything

DNS translates domain names into IP addresses. It's also one of the most abused protocols in offensive security — used for command and control communication, data exfiltration, and network reconnaissance. Most organisations allow DNS traffic to pass their firewalls without inspection because blocking it would break the internet. Attackers know this.

DNS tunnelling encodes arbitrary data inside DNS queries and responses, effectively creating a covert communication channel through a protocol that firewalls almost never block. Malware that can't make a direct TCP connection out can still exfiltrate data by encoding it into subdomains: aGVsbG8.attacker-domain.com — the subdomain is base64-encoded payload.

# Manual DNS queries — understand what's resolving
dig example.com A          # A record — IPv4 address
dig example.com MX         # Mail servers
dig example.com TXT        # Text records (SPF, DKIM, domain verification)
dig example.com NS         # Nameservers

# Reverse DNS lookup — who owns this IP?
dig -x 8.8.8.8

# Detect potential DNS tunnelling — look for unusually long subdomains
# Legitimate DNS queries rarely exceed 50 characters in the subdomain
tcpdump -i eth0 -l port 53 | awk '{
  if (length($NF) > 50) print "SUSPICIOUS LONG DNS QUERY: " $NF
}'

# Check your system's DNS resolver config
cat /etc/resolv.conf

# Flush DNS cache (useful after DNS poisoning)
systemd-resolve --flush-caches

TLS — encrypted but not invisible

TLS encrypts the content of network connections — preventing anyone intercepting the traffic from reading the payload. But TLS doesn't hide everything. The TLS handshake exposes the Server Name Indication (SNI) — the hostname the client is connecting to — in plaintext. IP addresses and connection metadata are always visible. Certificate details are visible. Timing and volume patterns are visible.

An analyst watching encrypted HTTPS traffic can't read the content, but can still see that a machine inside the network connected to a known malware C2 domain — the SNI gives it away. This is why DNS and SNI logging is part of modern network security monitoring even in fully encrypted environments.

# Inspect a TLS certificate — what is this server presenting?
openssl s_client -connect example.com:443 -servername example.com 2>/dev/null |
  openssl x509 -noout -text | grep -E "Subject:|Issuer:|Not Before:|Not After:"

# Check what TLS versions and ciphers a server supports
nmap --script ssl-enum-ciphers -p 443 example.com

# Capture TLS SNI fields from live traffic (plaintext in handshake)
tcpdump -i eth0 -A port 443 2>/dev/null |
  grep -oP '(?<=\x00\x00)[\x20-\x7e]{4,}' | grep '\.' | head -20

# Test for weak TLS configuration (requires testssl.sh)
./testssl.sh example.com

Practice Questions

Quiz