Networking fundamentals for security

Every cyberattack travels over a network. Whether it is a SQL injection, a brute force attempt, or data exfiltration, the payload moves through network protocols. Understanding these protocols tells you what is normal, what is suspicious, and what is clearly malicious. This article covers the networking fundamentals that security professionals use daily.

Prerequisites

You should read How attackers think to understand why networking knowledge matters for security. For the Linux-specific networking tools, see The Linux networking stack.

The TCP/IP model

The internet works on a layered model. Each layer handles one responsibility and passes data to the next.

graph TD
  A["Application Layer<br/>HTTP, DNS, SSH, SMTP, FTP"] --> B["Transport Layer<br/>TCP, UDP"]
  B --> C["Internet Layer<br/>IP, ICMP, ARP"]
  C --> D["Network Access Layer<br/>Ethernet, Wi-Fi"]
  style A fill:#64b5f6,stroke:#1976d2,color:#000
  style B fill:#81c784,stroke:#388e3c,color:#000
  style C fill:#ffb74d,stroke:#f57c00,color:#000
  style D fill:#ef5350,stroke:#c62828,color:#fff

Ports and sockets

A port is a number (0-65535) that identifies a specific service on a machine. A socket is the combination of IP address + port + protocol.

Ports you must know

TCP: the reliable protocol

TCP guarantees delivery and ordering. It uses a three-way handshake to establish connections.

The TCP handshake

Client                    Server
  |                         |
  |------- SYN ----------->|     "I want to connect"
  |                         |
  |<------ SYN-ACK --------|     "OK, I'm ready"
  |                         |
  |------- ACK ----------->|     "Let's go"
  |                         |
  |====== DATA ============|     Connection established

This handshake reveals information:

• The server is alive and listening on that port
• The server’s OS can sometimes be fingerprinted from TCP behavior
• The handshake takes time, which port scanners use to detect open ports

What a TCP connection reveals

# See all established TCP connections
ss -tnp

Every TCP connection tells you:

• Who is talking to whom (source and destination IPs)
• Which service is involved (destination port)
• How much data has been transferred
• How long the connection has been open

UDP: the fast protocol

UDP has no handshake and no delivery guarantee. It is faster but less reliable. Used by DNS, DHCP, video streaming, and VoIP.

From a security perspective, UDP is harder to monitor. There is no connection state, so firewalls cannot track “established” connections the same way they do with TCP.

DNS: the internet’s phone book

DNS converts domain names to IP addresses. It is one of the most abused protocols in security:

• DNS spoofing: return a fake IP for a domain, redirecting users to a malicious server
• DNS tunneling: encode data in DNS queries to bypass firewalls
• DNS enumeration: discover subdomains, mail servers, and other infrastructure (OSINT)

# Standard DNS query
dig example.com A +short

Output:

93.184.216.34

# Check for zone transfer (should be denied)
dig axfr example.com @ns1.example.com

Output:

; Transfer failed.

If a zone transfer succeeds, the attacker gets a complete list of all DNS records, revealing the entire infrastructure.

HTTP and HTTPS

HTTP is plaintext. Anyone on the network path can read the full request and response, including URLs, headers, cookies, and form data.

HTTPS wraps HTTP in TLS encryption. The network observer sees only the destination IP and the amount of data transferred, not the content.

# HTTP request (plaintext, visible to network observers)
curl -v http://example.com 2>&1 | head -15

# HTTPS request (encrypted)
curl -v https://example.com 2>&1 | head -20

Even with HTTPS, some information leaks:

• The destination IP address
• The domain name (via SNI in the TLS handshake)
• The timing and size of requests/responses
• DNS queries (unless using DNS over HTTPS)

ICMP

ICMP is used for network diagnostics (ping, traceroute) and error messages. It operates at the Internet layer.

# Ping: is the host alive?
ping -c 3 192.168.1.1

Output:

PING 192.168.1.1 (192.168.1.1) 56(84) bytes of data.
64 bytes from 192.168.1.1: icmp_seq=1 ttl=64 time=1.23 ms
64 bytes from 192.168.1.1: icmp_seq=2 ttl=64 time=0.98 ms
64 bytes from 192.168.1.1: icmp_seq=3 ttl=64 time=1.05 ms

# Traceroute: what path do packets take?
traceroute example.com

Security notes:

• Many firewalls block ICMP, so a host may be alive but not respond to ping
• ICMP can be used for covert channels (tunneling data in ping packets)
• Ping floods are a simple DoS attack

Example 1: Read a Wireshark capture and identify the protocol

Let’s analyze a packet capture file. In practice, you would use Wireshark (GUI) or tshark (CLI).

# Capture packets on interface eth0 for 30 seconds
sudo tcpdump -i eth0 -w /tmp/capture.pcap -c 100

# Read the capture
tcpdump -r /tmp/capture.pcap -n | head -20

Output:

10:30:01.123456 IP 192.168.1.100.54321 > 93.184.216.34.443: Flags [S], seq 1234567890
10:30:01.145678 IP 93.184.216.34.443 > 192.168.1.100.54321: Flags [S.], seq 987654321, ack 1234567891
10:30:01.145700 IP 192.168.1.100.54321 > 93.184.216.34.443: Flags [.], ack 987654322
10:30:01.146000 IP 192.168.1.100.54321 > 93.184.216.34.443: Flags [P.], seq 1:517, ack 1
10:30:01.234567 IP 192.168.1.100.12345 > 192.168.1.1.53: UDP, length 45
10:30:01.235000 IP 192.168.1.1.53 > 192.168.1.100.12345: UDP, length 89

Reading this capture:

Lines 1-3: TCP three-way handshake to port 443 (HTTPS)

• [S] = SYN (client initiates)
• [S.] = SYN-ACK (server responds)
• [.] = ACK (client confirms)

Line 4: Data transfer begins

• [P.] = PSH-ACK (pushing data, likely the TLS Client Hello)

Lines 5-6: DNS query

• Port 53, UDP: this is a DNS lookup
• The client asks the router (192.168.1.1) to resolve a name

# Filter for specific protocols
tcpdump -r /tmp/capture.pcap -n 'port 53'     # DNS only
tcpdump -r /tmp/capture.pcap -n 'port 443'    # HTTPS only
tcpdump -r /tmp/capture.pcap -n 'tcp[tcpflags] & tcp-syn != 0'  # SYN packets

Example 2: Spot an anomaly in a TCP connection

Here is a suspicious capture:

tcpdump -r /tmp/suspicious.pcap -n

Output:

10:30:01.000 IP 203.0.113.5.45678 > 192.168.1.100.22: Flags [S]
10:30:01.001 IP 192.168.1.100.22 > 203.0.113.5.45678: Flags [S.]
10:30:01.050 IP 203.0.113.5.45678 > 192.168.1.100.22: Flags [.]
10:30:01.100 IP 203.0.113.5.45679 > 192.168.1.100.22: Flags [S]
10:30:01.101 IP 192.168.1.100.22 > 203.0.113.5.45679: Flags [S.]
10:30:01.150 IP 203.0.113.5.45679 > 192.168.1.100.22: Flags [.]
10:30:01.200 IP 203.0.113.5.45680 > 192.168.1.100.22: Flags [S]
10:30:01.201 IP 192.168.1.100.22 > 203.0.113.5.45680: Flags [S.]
10:30:01.250 IP 203.0.113.5.45680 > 192.168.1.100.22: Flags [.]
... (hundreds more like this)

What is suspicious:

1. The source IP (203.0.113.5) is making many rapid connections to port 22 (SSH)
2. Each connection uses a sequential source port (45678, 45679, 45680…)
3. The connections complete the handshake but then close quickly

This is an SSH brute force attack. The attacker is trying different passwords in rapid succession.

What you would check next:

# Check auth.log for failed login attempts
grep "203.0.113.5" /var/log/auth.log | head -5

Output:

Jun 6 10:30:01 devbox sshd[9876]: Failed password for root from 203.0.113.5 port 45678 ssh2
Jun 6 10:30:01 devbox sshd[9877]: Failed password for admin from 203.0.113.5 port 45679 ssh2
Jun 6 10:30:01 devbox sshd[9878]: Failed password for test from 203.0.113.5 port 45680 ssh2

Immediate response: Block the IP with your firewall and ensure fail2ban is running.

sudo ufw deny from 203.0.113.5

What comes next

The next article covers Cryptography fundamentals, where you will learn how encryption protects data in transit and at rest, and where it can fail.

For hands-on network defense, see the Linux networking article for firewall configuration.