Port Security Rules

victor nkereuwem — Sun, 18 Oct 2026 22:22:19 GMT

The Rule of Least Exposure

When configuring network firewalls or assessing endpoint risk, one principle holds true: if a service isn't meant for public consumption, it shouldn't be publicly reachable.

Guidelines:

1. Public Exposure (YES): Only services intended for unauthenticated/public access (e.g., HTTP/HTTPS, public DNS).

2. Restricted Exposure (NO / VPN / IP Allowlist): Administrative (SSH, RDP) and Database (MySQL, SMB) ports.

3. Plaintext Protocols (NO): Insecure protocols (Telnet, FTP) that transmit credentials unencrypted must be disabled/replaced.

Port	Protocol	Service	Internet-Facing?	Justification & Security Guidance
21	TCP	FTP	NO	Transmits credentials and data in plaintext. Replace with SFTP (Port 22) or FTPS (Port 990).
22	TCP	SSH	NO (VPN/IP Only)	High-value admin target. Restrict to internal management VPN or explicit source IP allowlist + key auth.
23	TCP	Telnet	NO	Obsolete and insecure. Transmits data/passwords in cleartext. Replace with SSH.
25	TCP	SMTP	RESTRICTED	Allow publicly ONLY if operating an inbound Mail Transfer Agent (MTA). Block or require auth/TLS.
53	TCP/UDP	DNS	YES (If Public)	Required for public domain name resolution. Restrict recursive queries to prevent DNS amplification.
80	TCP	HTTP	YES	Public web server port. Must auto-redirect all incoming traffic to HTTPS (Port 443).
443	TCP	HTTPS	YES	Standard encrypted public web traffic (TLS). Default baseline for facing the public internet.
445	TCP	SMB	NO	Critical Windows file-sharing protocol. High risk for wormable exploits (e.g., EternalBlue). Internal only.
3306	TCP	MySQL	NO	Database management. Should only accept local loopback connections or requests from app servers.
3389	TCP	RDP	NO (VPN/IP Only)	High-priority target for brute-force/ransomware. Limit strictly to Zero Trust/VPN or Jump Box gateways.

I’m documenting my journey through an 84-day DFIR & Security Engineering sprint. Follow my daily lab updates and playbooks on my GitHub Repository.

What I Found Inside a Forensic Disk Image Using Autopsy & Zimmerman Tools

victor nkereuwem — Sat, 17 Oct 2026 23:17:07 GMT

When investigating an active security breach or insider threat, a disk image is a digital crime scene frozen in time. During my DFIR and Security Engineering sprint, I analyzed a practice disk image (2020JimmyWilson.E01 sourced from the NIST CFReDS repository) using Autopsy, Eric Zimmerman’s Registry Explorer, and Windows Event Viewer. Here is what I uncovered.

(a) What I Was Investigating

I investigated a suspect workstation assigned to a domain user (jimmy wilson) to determine whether sensitive corporate pricing files and address lists were staged, encoded, and exfiltrated to unauthorized external media.

(b) Chain of Custody: Why the SHA-256 Hash Comes First

Before analyzing a single file, I computed and recorded the evidence image's SHA-256 cryptographic hash:

a1102c70a50768b588225fdcad6efa5d5d57341b

A SHA-256 hash acts as a unique digital fingerprint. Recording it first establishes chain of custody: if a single bit of data changes during analysis, the hashes mismatch, making the evidence inadmissible in court or internal audits. Matching hashes prove the evidence was never altered.

(c) Two Key Forensic Artifacts

User Hive Registry Artifacts (NTUSER.DAT): Extracted and parsed using Eric Zimmerman's Registry Explorer. Examining the Most Recently Used (MRU) keys tracked administrative tool execution, specifically the launching of Task Scheduler (taskschd.msc) and Computer Management (compmgmt.msc).
USB & File Artifacts (USBSTOR & LNK Files): Parsed directly inside Autopsy. Autopsy's artifact extraction parsed USBSTOR keys to prove physical connection of external USB flash drives (including serial numbers for SanDisk and Kingston drives), while LNK files proved target document interaction on the user’s Desktop.

(d) How Timestamps Tied Everything Into a Story

Correlating timestamps across artifacts transformed isolated logs into an undeniable narrative:

Initial Intent (Feb 2014): IE browser history logged searches for "how to steal identities" and visits to zebra.com to download datasheets for ID card printers (drivers were later found installed on the host).
Collusion: Parsed EML email files revealed communications with jose.badguy@hushmail.com containing instructions to encode staging files.
Rapid Staging Burst (May 26, 2015): LNK timestamps captured a rapid, 3-second sequence at 13:46:13 WAT where name that need addresses.xls was accessed, followed immediately by NewPrices.txt and New Price List Encoded.TXT.
Exfiltration: USB connection timestamps parsed in Autopsy directly coincided with this file-encoding window, establishing the physical vector used to exfiltrate the staged data.

[2014-02-10] Web Research (Zebra ID Printers & Identity Theft)
     │
[2015-05-26 13:46:12] Rapid File Access (XLS → TXT → Encoded TXT in 3s)
     │
[2015-05-26 13:52:41] USBSTOR Timestamps in Autopsy (Exfiltration to Kingston USB)

(e) What I Would Do Next in a Real Case

In a live enterprise incident response scenario, my next steps would be:

Revoke & Contain: Immediately disable the user's Active Directory credentials and revoke active session tokens.
Network Sweep: Convert extracted file hashes and domain IOCs (hushmail.com) into YARA & Sigma rules to sweep endpoints across the enterprise.
Policy Enforcement: Update Active Directory Group Policy (GPO) to block unauthorized USB mass storage devices company-wide.