🔄 Topic

Understanding common network protocols, their ports, and why they matter for SOC investigations.

🎯 Goal

Build a stronger mental map of how common protocols behave on a network and how they appear in logs, packet captures, and security alerts.

🛠 What I Did

Today I reviewed several important network protocols from the Google Cybersecurity Certificate material:

  • DHCP
  • ARP
  • Telnet
  • SSH
  • POP3
  • IMAP
  • SMTP
  • DNS
  • HTTPS
  • NAT
  • VPNs
  • firewalls
  • proxy servers

The main focus was not just memorizing protocol names.

The real goal was understanding:

  • what each protocol does
  • which port it usually uses
  • whether it is encrypted or unencrypted
  • where it appears in the TCP/IP model
  • how an attacker may abuse it
  • how a defender would investigate it

Some key examples:

  • DHCP uses UDP ports 67 and 68 to assign IP addresses.
  • ARP does not use TCP or UDP ports because it works at a lower layer.
  • Telnet uses TCP port 23 and is insecure because it sends data in cleartext.
  • SSH uses TCP port 22 and is used for secure remote access.
  • DNS commonly uses UDP port 53, but can also use TCP port 53.
  • HTTP uses TCP port 80.
  • HTTPS uses TCP port 443.
  • SMTP commonly uses TCP port 25 for mail transfer and TCP port 587 for authenticated mail submission.
  • IMAP uses TCP port 143 unencrypted and TCP port 993 encrypted.
  • POP3 uses TCP port 110 unencrypted and TCP port 995 encrypted.

🔗 Key Cybersecurity Connections

This matters because SOC analysts constantly deal with network evidence.

A protocol is not just a definition in a course.

It becomes evidence.

For example:

  • repeated SSH login attempts may indicate brute force
  • Telnet traffic may indicate insecure remote administration
  • strange DNS queries may indicate malware beaconing or DNS tunneling
  • unusual SMTP traffic may indicate spam, phishing, or compromised mail infrastructure
  • unexpected ARP behavior may indicate local network manipulation
  • VPN logs may reveal valid account abuse
  • proxy logs may reveal suspicious web destinations

A weak analyst only memorizes:

SSH = port 22

A stronger analyst asks:

Why is this host using SSH?
Who connected?
Was the login successful?
Is this normal for this user or device?
What happened before and after the connection?

🔍 Investigation Questions

  • What protocol is being used?
  • Is the port normal for that protocol?
  • Is the traffic encrypted or cleartext?
  • Is the source internal or external?
  • Is the destination expected?
  • Is the same source contacting many destinations?
  • Is the same destination receiving traffic from many sources?
  • Is the protocol normal for this type of device?
  • Does the traffic happen at a normal time?
  • Is there authentication involved?
  • Are there failures, errors, or rejected connections?

🚨 Detection Opportunities

Potential detection ideas:

  • repeated SSH failures from one IP
  • Telnet traffic inside the network
  • DNS queries to newly registered or suspicious domains
  • unusually long DNS query names
  • sudden spike in outbound SMTP traffic from a workstation
  • VPN login from unusual geography
  • proxy traffic to known malicious infrastructure
  • ARP table changes involving the default gateway
  • internal host communicating on unexpected ports
  • service listening on a port that should not be exposed

Example SOC pattern:

source_ip=10.0.0.25
destination_port=22
action=failed_login
count=87
timeframe=10 minutes

This is no longer just “SSH traffic”.

It becomes a possible brute-force pattern.

🧭 MITRE ATT&CK Techniques

  • T1046 — Network Service Discovery
  • T1021 — Remote Services
  • T1110 — Brute Force
  • T1071 — Application Layer Protocol
  • T1041 — Exfiltration Over C2 Channel

🗺 Visual Investigation Diagram

Endpoint
    ↓
Local network protocol activity
    ↓
DNS / ARP / DHCP
    ↓
Firewall / NAT / proxy
    ↓
Internet-facing service
    ↓
Logs and alerts
    ↓
SOC investigation

⚠ Challenges

The main challenge was separating memorization from understanding.

It is easy to create a list like:

  • SSH = 22
  • DNS = 53
  • HTTPS = 443

But that is not enough.

In real security work, the useful question is:

Is this protocol behaving normally in this environment?

Another challenge was understanding that some protocols do not use ports.

For example, ARP does not use TCP or UDP ports because it operates at the local network layer.

That matters because looking for an “ARP port” is a wrong mental model.

📚 What I Learned

I learned that protocols are the language of network activity.

Ports help identify services, but they are not proof by themselves.

For example, traffic on port 443 is usually HTTPS, but attackers can also use port 443 to blend malicious traffic into normal encrypted web traffic.

So the port is a clue, not a conclusion.

I also learned that protocol knowledge helps with triage.

When an alert mentions DNS, SSH, SMTP, or VPN activity, I need to quickly understand what normal traffic should look like before deciding whether it is suspicious.

➡ Next Steps

  • Build a personal protocol cheat sheet
  • Memorize the most common ports
  • Create fake logs for each major protocol
  • Practice reading DNS and SSH traffic in Wireshark
  • Link each protocol to one realistic attack scenario
  • Review how Zeek and Suricata expose protocol-level evidence

🧠 Reflection

This felt like a foundation day.

The Google course gives the protocol names, but the SOC mindset comes from asking what those protocols look like when abused.

Networking is not just infrastructure.

For an analyst, networking is evidence.

🧩 Lessons Learned

What worked

Connecting every protocol to a real SOC investigation question.

What broke

Trying to memorize port numbers without understanding the behavior behind them.

Why it broke

Ports alone do not explain intent, context, or risk.

Fix / takeaway

For every protocol, memorize four things:

  • purpose
  • port
  • normal behavior
  • common abuse case

📈 Skill Progression Context

This builds core SOC readiness.

Almost every network alert starts with basic fields:

  • source IP
  • destination IP
  • port
  • protocol
  • timestamp
  • action

Understanding protocols helps turn those fields into an investigation instead of just reading them as raw data.

😄 TL;DR

Ports are not magic numbers.
They are clues.

The analyst’s job is to ask what the traffic is actually doing.