05
Every time you scan a target with Nmap, intercept a request with Burp Suite, or set up a listener for a reverse shell — you are working with networking concepts at a fundamental level. If you don’t understand what’s happening under the hood, you’re following instructions blindly. Blind instruction-following breaks down the moment something goes differently than expected.
Today we build your mental model of how networks work — from the physical cable all the way up to your browser. By the end of this lesson, when a packet travels from your Kali VM to a target machine, you’ll know exactly what’s happening at every step.
This lesson has a reputation for being dry. I’m going to make it the opposite. We’re going to trace a real connection — from you typing a URL in a browser to receiving the page — and explain every networking concept through that single journey. No abstract theory divorced from reality. Just the real thing, explained clearly.
Why Networking Is Non-Negotiable for Ethical Hackers
Here is the honest truth: almost every attack in ethical hacking is a networking operation. When you scan for open ports, you’re sending TCP packets and reading responses. When you intercept traffic with Burp Suite, you’re acting as a proxy in an HTTP conversation. When you set up a listener for a reverse shell, you’re opening a TCP socket and waiting for a connection. When you perform a man-in-the-middle attack, you’re manipulating ARP tables.
The students who struggle most in this field are the ones who skipped networking basics and jumped straight to tools. They can run Nmap but can’t explain what a SYN packet is. They can intercept HTTP with Burp but don’t know why HTTPS is different. Tools without understanding is a dead end — you hit the first unexpected result and have no idea why.
📡
Scanning
Nmap sends TCP/UDP packets and reads responses — pure networking
🔀
Interception
Burp Suite proxies HTTP — requires knowing how HTTP works
🐚
Shells
Reverse shells are TCP connections — socket, port, listener
🎭
MITM Attacks
ARP poisoning manipulates Layer 2 — needs ARP understanding
The OSI Model — 7 Layers That Explain Everything
The OSI (Open Systems Interconnection) model is a conceptual framework with 7 layers that describes how network communication works. Each layer has a specific job and communicates with the layers immediately above and below it. When data travels from your browser to a server, it passes through all 7 layers — twice.
I’m going to give you the hacker’s take on each layer — not a textbook definition, but what each layer means for the attacks and defences you’ll encounter over the next 95 days.
OSI Model — Hacker’s Edition
Application Layer
Where user-facing apps communicate. Protocols: HTTP, HTTPS, FTP, SSH, DNS, SMTP. Hacker target: web vulnerabilities, credential theft, phishing.
Presentation Layer
Data translation, encryption, and compression. SSL/TLS lives here. Hacker angle: SSL stripping, downgrade attacks, certificate spoofing.
Session Layer
Manages sessions between applications — start, maintain, end. Hacker angle: session hijacking, session fixation attacks.
Transport Layer
TCP and UDP live here — ports, reliable delivery, segmentation. Hacker angle: port scanning, SYN floods, TCP session attacks.
Network Layer
IP addressing and routing — getting packets to the right destination. Hacker angle: IP spoofing, ICMP attacks, routing manipulation.
Data Link Layer
MAC addresses, frames, local network delivery. Switches operate here. Hacker angle: ARP poisoning, MAC spoofing, VLAN hopping.
Physical Layer
Actual cables, radio waves, electrical signals. Hardware. Hacker angle: wireless sniffing, physical access attacks, hardware implants.
Memory aid: “All People Seem To Need Data Processing” (Application → Physical, top to bottom)
💡 The hacker shortcut: In practice, most people work with a simplified 4-layer TCP/IP model (Application, Transport, Internet, Network Access) rather than all 7 OSI layers. But knowing the OSI model is essential for interviews, certifications, and understanding documentation. When someone says “Layer 3 attack” or “Layer 7 firewall” — now you know exactly what they mean.
TCP vs UDP — The Two Protocols Every Hacker Works With
At the Transport Layer (Layer 4), two protocols carry the vast majority of all internet traffic: TCP and UDP. Understanding the difference between them is not optional — Nmap’s scan types, reverse shell selection, and service fingerprinting all depend on it.
| Property | TCP | UDP |
|---|
| Connection | Connection-oriented (3-way handshake) | Connectionless (fire and forget) |
| Delivery | Guaranteed — retransmits lost packets | Not guaranteed — packets may be lost |
| Speed | Slower (overhead for reliability) | Faster (no connection overhead) |
| Use cases | HTTP, HTTPS, SSH, FTP, SMTP | DNS, VoIP, video streaming, gaming |
| Hacker relevance | Port scanning (SYN scan), reverse shells, exploits | DNS enumeration, UDP service discovery |
| Nmap flag | -sS (SYN) or -sT (TCP connect) | -sU (UDP scan) |
The TCP Three-Way Handshake — How Connections Are Established
Every TCP connection begins with a handshake. When Nmap does a SYN scan, it deliberately doesn’t complete this handshake — and understanding why requires knowing what the handshake looks like.
TCP 3-way handshake — what happens when you connect to a server
# Step 1: Client sends SYN (I want to connect)
Your machine → Target:80 [SYN] Seq=0
# Step 2: Server responds SYN-ACK (OK, I’m listening)
Target:80 → Your machine [SYN, ACK] Seq=0 Ack=1
# Step 3: Client sends ACK (Connection established)
Your machine → Target:80 [ACK] Seq=1 Ack=1
# Connection is now ESTABLISHED — data can flow
# Nmap SYN scan (-sS): sends SYN, reads SYN-ACK, then RST
Nmap → Target:80 [SYN]
Target:80 → Nmap [SYN, ACK] ← port is OPEN
Nmap → Target:80 [RST] ← never completes the handshake
# RST = Reset. Nmap drops the connection before it fully opens.
# This is why SYN scan is “stealth” — connection never fully forms.
# If port is CLOSED: Target responds RST immediately
Nmap → Target:81 [SYN]
Target:81 → Nmap [RST, ACK] ← port is CLOSED
# If port is FILTERED (firewall): No response at all
Nmap → Target:82 [SYN]
…no response… ← port is FILTERED
IP Addresses — Public, Private, and Why the Difference Matters
An IP (Internet Protocol) address is a number that uniquely identifies a device on a network. Think of it as a postal address — without it, nobody knows where to send data. There are two types that matter enormously in ethical hacking: public and private.
🌍 Public IP Addresses
Globally routable — visible on the internet. Your router’s IP. When you visit a website, the server sees your public IP. These are assigned by ISPs and managed by IANA. Range: everything not in the private ranges.
🏠 Private IP Addresses
Only routable within a local network. Not visible on the internet. Your laptop’s IP in your home network (192.168.x.x). Three reserved private ranges exist — used in every home and corporate network.
Private IP ranges — memorise these
# Class A — Large networks (enterprises, cloud providers)
10.0.0.0 – 10.255.255.255 (10.0.0.0/8)
# 16 million addresses. Common in corporate environments.
# Class B — Medium networks
172.16.0.0 – 172.31.255.255 (172.16.0.0/12)
# Often used by VMs, Docker, and VPNs
# Class C — Small networks (most home routers)
192.168.0.0 – 192.168.255.255 (192.168.0.0/16)
# Your home WiFi is almost certainly 192.168.0.x or 192.168.1.x
# Special addresses
127.0.0.1 # Loopback / localhost — “this machine itself”
0.0.0.0 # All interfaces — used by listeners
255.255.255.255 # Broadcast — send to all devices on network
# Check your own IP addresses
ip a # All interfaces on your Kali VM
curl -s ifconfig.me # Your PUBLIC IP (needs internet)
203.0.113.45 ← your real internet IP
Ports — The Service Directory of Every Host
An IP address gets you to the right machine. A port gets you to the right service on that machine. Every server runs multiple services simultaneously — web server, SSH server, database, email. Ports (numbered 0–65535) allow all of these to coexist on one IP address. Port scanning is the act of knocking on each door and seeing who answers.
| Port | Protocol | Service | Hacker Relevance |
|---|
| 21 | TCP | FTP | Often anonymous auth, cleartext credentials |
| 22 | TCP | SSH | Brute force target, key-based auth |
| 23 | TCP | Telnet | Completely cleartext — dangerous if open |
| 25 | TCP | SMTP | Email — phishing infrastructure |
| 53 | TCP/UDP | DNS | DNS enumeration, zone transfers |
| 80 | TCP | HTTP | Web attacks — unencrypted traffic visible |
| 110 | TCP | POP3 | Email retrieval — often cleartext |
| 139/445 | TCP | SMB | EternalBlue, pass-the-hash, shares |
| 443 | TCP | HTTPS | Web attacks — encrypted but still vulnerable |
| 3306 | TCP | MySQL | DB exposed to network? Major finding. |
| 3389 | TCP | RDP | Windows remote desktop — brute force, BlueKeep |
| 8080/8443 | TCP | HTTP Alt | Dev servers, admin panels, web proxies |
Port ranges — understanding the categories
# Well-known ports (system ports)
0 – 1023 # Reserved for common services. Require root to open.
# Registered ports
1024 – 49151 # Assigned to specific apps (MySQL: 3306, RDP: 3389)
# Dynamic / ephemeral ports
49152 – 65535 # Assigned dynamically when your OS opens a connection
# View services listening on your Kali machine right now
ss -tuln
tcp LISTEN 0.0.0.0:22 ← SSH is listening on all interfaces
DNS — The Internet’s Phone Book (And a Hacker’s Gold Mine)
DNS (Domain Name System) translates human-readable domain names — securityelites.com — into IP addresses that computers use. Without DNS, you’d have to memorise the IP address of every website you visit. DNS is also one of the most commonly exploited services in real-world attacks, because it’s almost always allowed through firewalls.
DNS in action — run these in your Kali terminal
# Basic lookup — what IP does this domain resolve to?
nslookup google.com
Name: google.com
Address: 142.250.185.46
# dig — more detailed DNS query
dig securityelites.com
;; ANSWER SECTION:
securityelites.com. 300 IN A 203.0.113.10
# Query specific record types
dig google.com MX # Mail server records
dig google.com NS # Name server records
dig google.com TXT # Text records (SPF, DKIM, verification codes)
dig -x 8.8.8.8 # Reverse lookup — IP → domain name
# Zone transfer — try to download entire DNS zone
dig axfr @ns1.target.com target.com
# If successful = lists ALL subdomains and records (big misconfiguration)
# Most servers block this — but worth trying in CTFs and assessments
# See your current DNS resolver
cat /etc/resolv.conf
nameserver 8.8.8.8 ← Google’s DNS resolver
🎯 Why DNS matters for hackers: DNS enumeration reveals subdomains, mail servers, name servers, and infrastructure details that aren’t visible on the main website. Many bug bounty findings start with thorough DNS enumeration — discovering forgotten subdomains (dev.target.com, staging.target.com) that run older, unpatched software. We’ll dedicate an entire day to DNS enumeration on Day 22.
ARP — How Devices Find Each Other on a Local Network
ARP (Address Resolution Protocol) bridges the gap between Layer 3 (IP addresses) and Layer 2 (MAC addresses). When your computer wants to send data to 192.168.1.1 (the router), it needs to know the router’s physical MAC address to actually deliver the frame. ARP handles this lookup — and its trusting nature is exactly what makes ARP poisoning attacks possible.
ARP — how it works and where it breaks
# ARP resolution process:
Your PC broadcasts: “Who has 192.168.1.1? Tell 192.168.1.100”
Router replies: “192.168.1.1 is at AA:BB:CC:DD:EE:FF”
Your PC caches this mapping. Done.
# View your ARP table (IP → MAC mapping cache)
arp -a
? (192.168.56.1) at 08:00:27:xx:xx:xx [ether] on eth0
? (192.168.56.2) at 52:54:00:xx:xx:xx [ether] on eth0
# The problem: ARP is completely trusting
# Any device can broadcast: “192.168.1.1 is at MY MAC ADDRESS”
# Other devices will believe it and update their ARP cache
# Result: all traffic intended for the router flows through attacker
# This is ARP poisoning — the foundation of MITM attacks (Day 17+)
HTTP vs HTTPS — Why the Lock Icon Is Not Enough
HTTP (Hypertext Transfer Protocol) is the language web browsers use to communicate with web servers. It’s the protocol at Layer 7, and it’s completely cleartext — meaning anyone who can see the traffic can read it. HTTPS adds TLS encryption to HTTP, which protects the content in transit.
🔓 HTTP (Port 80) — Cleartext
- Everything visible to anyone on the network path
- Passwords, cookies, and form data readable in plaintext
- Trivially captured with Wireshark or a network tap
- Still used on internal networks and legacy systems
🔒 HTTPS (Port 443) — TLS Encrypted
- Content encrypted — interceptors see ciphertext only
- Server identity verified by trusted certificate
- Still vulnerable to application-level attacks (XSS, SQLi)
- Can be stripped or certificate-spoofed without pinning
HTTP request anatomy — what Burp Suite shows you
# A basic HTTP GET request
GET /login HTTP/1.1
Host: target.com
Cookie: session=abc123; user=admin
Accept: text/html
# A POST request with credentials (login form)
POST /login HTTP/1.1
Host: target.com
Content-Type: application/x-www-form-urlencoded
username=admin&password=Password123
# Over HTTP: any network observer sees this in plaintext
# Over HTTPS: encrypted, but still visible to Burp Suite (your proxy)
# That’s why Burp works on HTTPS — it’s YOUR proxy, trusted by your browser
⚠️ Common misconception: HTTPS protects data
in transit. It does NOT protect against application vulnerabilities. An HTTPS site can still have
SQL injection, XSS, broken authentication, and every other web vulnerability. The lock icon means the connection is encrypted — it says nothing about the security of the application behind it.
🗺️ Tracing a Full Packet Journey — URL to Response
Let’s trace exactly what happens when you type https://securityelites.com into your browser and press Enter. Every concept we covered today appears in this journey — this is the unified picture.
STEP 1 — DNS RESOLUTION (Layer 7)
Browser asks your DNS resolver: “What is the IP of securityelites.com?” DNS returns: 203.0.113.10. Now the browser knows where to connect.
STEP 2 — TCP HANDSHAKE (Layer 4)
Browser opens a TCP connection to 203.0.113.10:443. SYN → SYN-ACK → ACK. Connection established.
STEP 3 — TLS HANDSHAKE (Layer 6)
Browser and server negotiate encryption. Server presents its certificate. Browser verifies it. Encrypted session established. From here, all data is encrypted.
STEP 4 — HTTP REQUEST (Layer 7)
Browser sends: GET / HTTP/1.1 Host: securityelites.com. This travels inside the encrypted TLS tunnel.
STEP 5 — IP ROUTING (Layer 3)
Your router sends the packet toward 203.0.113.10, through multiple hops across the internet. Each router reads the IP header and forwards to the next hop.
STEP 6 — ARP + MAC DELIVERY (Layer 2)
On each local network segment, ARP resolves the next-hop IP to a MAC address. The frame is addressed to that MAC and delivered across the local segment.
STEP 7 — PHYSICAL TRANSMISSION (Layer 1)
Electrical signals over copper wire or light pulses over fibre or radio waves over WiFi carry the actual bits from device to device.
Server sends back the HTML response through the same chain in reverse. Your browser renders the page. That entire journey happens in under 100 milliseconds.
🎯 Day 5 Practical Task — Network Reconnaissance on Your Own Lab
📋 DAY 5 CHECKLIST
1
Identify your Kali VM’s IP address and network range
ip a
ip route
arp -a
Note: What is your VM’s IP? What is the gateway? How many devices in your ARP table?
2
Perform DNS lookups on three different domains
dig google.com
dig securityelites.com
dig google.com MX
dig -x 8.8.8.8
Note the TTL values and what information each record type reveals.
3
Inspect an HTTP response with curl
curl -I http://example.com
curl -I https://google.com
curl -v https://example.com 2>&1 | head -40
The -v flag shows the TLS handshake happening in real time. Can you spot the certificate and cipher suite?
4
Run your first Nmap scan on localhost — see your own open ports
nmap 127.0.0.1
nmap -sV 127.0.0.1
nmap -p 1-1000 127.0.0.1
Scanning your own machine is always legal. What ports are open on your Kali VM? Is SSH running?
⭐ BONUS CHALLENGE — Trace a Real Packet
Use traceroute to trace the path from your Kali VM to Google’s DNS server. Count the hops. Which hop is your router? Which is your ISP? This is the real internet routing you read about today — now you can see it live.
traceroute 8.8.8.8
traceroute securityelites.com
Share your hop count in Telegram with #Day5Done 📡
📡
The internet is no longer a mystery.
You know how every packet moves.
Five days in — you’ve built the mindset, the lab, the command line, the file system map, and now the networking foundation. Day 6 goes deeper into IP addressing and subnetting — the math behind how networks are designed and how pentesters identify target ranges. It’s easier than it sounds, and more useful than you’d expect.
Day 6: IP Addressing & Subnetting →
Frequently Asked Questions — Day 5 Networking Basics for Hackers
Do I need to memorise all 7 OSI layers?
You need to know all 7 layers and their order — certification exams test this, and professional conversations reference layer numbers constantly. The memory aid “All People Seem To Need Data Processing” (Layers 7 to 1) is reliable. More importantly, you need to understand what each layer does and which attacks target which layer — that’s what matters in practice.
Why does HTTP use port 80 and HTTPS use port 443 specifically?
These are convention — the Internet Assigned Numbers Authority (IANA) designated these ports as the standard for HTTP and HTTPS. Servers can technically run HTTP on any port (and many development servers run on port 8080 or 8443), but browsers default to port 80 for http:// and port 443 for https:// unless a different port is specified in the URL.
What is the difference between a router, switch, and hub?
A hub (mostly obsolete) broadcasts all traffic to every connected device — no intelligence. A switch operates at Layer 2, knows which MAC address is on which port, and forwards frames only to the correct port. A router operates at Layer 3, connects different networks (like your home network and the internet), and routes packets based on IP addresses. For ethical hacking: switches are why you need ARP poisoning to sniff other devices’ traffic on a switched network.
Can I scan any IP address with Nmap from my home?
You may only scan IP addresses you own or have explicit written authorisation to scan. Scanning your own Kali VM (127.0.0.1 or its local IP) is always fine. Scanning your home router requires care — check that your ISP’s terms don’t prohibit scanning your own connection. Scanning any external IP without permission is illegal and may also violate your ISP’s terms of service. Throughout this course, all scanning happens within your own virtual lab.
ME
Mr Elite
Founder, SecurityElites.com | Penetration Tester | Educator
Networking was the topic I was most intimidated by when I started. Then someone showed me that a packet is just a digital envelope with an address on it — and suddenly the entire model clicked. If it clicked for you today, you’re right on track. The tools we pick up from Day 10 onwards will make complete sense now.
