9.2 OS Hardening and Attack Surface Reduction

OS Hardening and Attack Surface Reduction

Core Hardening Principle: Default operating system installations are engineered for broad hardware compatibility and administrative convenience, not hardened security. Out of the box, server operating systems enable dozens of background services, open non-essential network listening sockets, provision default administrative accounts with well-known identifiers, and permit legacy network protocols. Every unnecessary daemon, unmonitored listening port, and unpatched binary expands the server's attack surface—the aggregate total of all entry points through which an unauthorized user or malicious payload can enter or extract data.

Server hardening is the disciplined, systematic process of minimizing that attack surface by disabling superfluous functionality, enforcing stringent authentication parameters, restricting host network boundaries, and validating patch integrity.

---

Attack Surface Reduction: Auditing and Disabling Unnecessary Roles and Daemons

The fundamental operational rule of server hardening states: If an operating system role, service, protocol, or feature is not strictly required for the server's designated business function, it must be audited, stopped, and permanently disabled or uninstalled.

+-----------------------------------------------------------------------------+
|                        Attack Surface Reduction Matrix                      |
|                                                                             |
|   RISK / ATTACK VECTOR                  HARDENING REMEDIATION               |
|   * Cleartext Remote Access (Telnet/FTP) -> Disable; Enforce SSHv2 / SFTP   |
|   * Legacy Protocols (SMBv1, NetBIOS)   -> Uninstall SMBv1; Block NBT       |
|   * Superfluous Daemons (Print Spooler) -> Stop & Disable on non-print hosts|
|   * Unused OS Roles (IIS/Apache on DB)  -> Remove web server roles          |
+-----------------------------------------------------------------------------+

High-Risk Services and Legacy Protocols to Eliminate

• Cleartext Remote Management (Telnet, RSH, RLOGIN): Telnet (TCP Port 23) and legacy BSD r-commands (TCP Ports 512, 513, 514) transmit all session keystrokes, administrative usernames, and passwords across the network in cleartext. They must be uninstalled and replaced exclusively with SSHv2 (TCP Port 22).
• Cleartext File Transfer Protocol (FTP): Standard FTP (TCP Ports 20 and 21) exposes credentials and payload data in transit. It must be replaced with Secure Shell File Transfer Protocol (SFTP) running over SSH port 22 or FTPS (FTP over TLS, ports 989/990).
• Server Message Block Version 1 (SMBv1): SMBv1 is an archaic 1980s network file sharing protocol plagued by architectural security flaws. It was the primary propagation vector for the devastating WannaCry and NotPetya ransomware attacks (exploiting the EternalBlue vulnerability, CVE-2017-0144). SMBv1 lacks packet signing integrity and encryption. Systems administrators must ensure SMBv1 is uninstalled across all Windows and Linux (Samba) servers, enforcing a minimum of SMBv3 with end-to-end encryption.
• NetBIOS over TCP/IP (NBT): NetBIOS Name Service (UDP Port 137), Datagram Service (UDP Port 138), and Session Service (TCP Port 139) generate unnecessary broadcast chatter and expose servers to NetBIOS name spoofing (e.g., via Responder). NBT must be disabled on all network interfaces in favor of pure DNS and direct SMB over TCP Port 445.
• The Windows Print Spooler (spoolsv.exe): By default, Windows Server enables the Print Spooler service. Unless a server is a dedicated print server, running the Print Spooler on domain controllers, database servers, or web servers introduces extreme risk. The Print Spooler has historically suffered from high-impact remote code execution and local privilege escalation flaws (most notably PrintNightmare, CVE-2021-34527). Hardening baselines mandate stopping and disabling the Print Spooler on all infrastructure servers.

Service Auditing Commands across Operating Systems

# Linux: List all enabled background unit services
systemctl list-unit-files --type=service --state=enabled

# Linux: Stop and permanently disable a superfluous service (e.g., CUPS print daemon)
sudo systemctl stop cups.service
sudo systemctl disable cups.service
sudo systemctl mask cups.service

# Windows PowerShell: Query all running services configured for Automatic startup
Get-Service | Where-Object {$_.StartType -eq 'Automatic' -and $_.Status -eq 'Running'} | Format-Table -Property Name, DisplayName, Status

# Windows PowerShell: Stop and disable the Print Spooler service
Stop-Service -Name "Spooler" -Force
Set-Service -Name "Spooler" -StartupType Disabled

---

Port Security: Identifying and Closing Open Listening Ports

A server network port is a communication endpoint defined by a 16-bit integer (0 to 65535). A port is in a LISTEN state when an active operating system process binds to that port and waits for incoming network connections. Every open listening port represents an open door into the server operating system.

Active Socket Inspection

Systems administrators must regularly audit active sockets to identify rogue daemons, unauthorized listening services, or backdoor connections established by malicious software.

+-----------------------------------------------------------------------------+
|                        Socket Inspection Architecture                       |
|                                                                             |
|   [Remote Client] ---> [Network Interface] ---> [Kernel Socket Table]      |
|                                                        |                    |
|                                                        v                    |
|                                             Local Address & Port:           |
|                                             0.0.0.0:443 (LISTEN)            |
|                                                        |                    |
|                                                        v                    |
|                                             Owning Process: PID 2418        |
|                                             Binary: /usr/sbin/nginx         |
+-----------------------------------------------------------------------------+

• ss (Socket Statistics): In modern enterprise Linux, ss directly queries kernel socket structures, completely replacing the obsolete netstat utility.
• netstat (Network Statistics): Traditional diagnostic utility available across Windows and legacy Unix platforms.
• PowerShell Get-NetTCPConnection: Modern, pipeline-capable Windows cmdlet for socket analysis.

Common Socket Auditing CLI Commands

# Linux: Display all TCP (-t) and UDP (-u) listening (-l) sockets with numeric ports (-n) and process IDs (-p)
ss -tulnp

# Expected Linux ss output:
# Netid  State   Recv-Q  Send-Q   Local Address:Port   Peer Address:Port  Process
# tcp    LISTEN  0       128            0.0.0.0:22          0.0.0.0:*      users:(("sshd",pid=1042,fd=3))
# tcp    LISTEN  0       511            0.0.0.0:443         0.0.0.0:*      users:(("nginx",pid=2104,fd=6))

# Windows Command Prompt: List all listening connections with Owning Process ID (PID)
netstat -ano | findstr LISTENING

# Windows PowerShell: Identify all listening TCP sockets and resolve the owning process name
Get-NetTCPConnection -State Listen | Select-Object LocalAddress, LocalPort, OwningProcess, @{Name="ProcessName";Expression={(Get-Process -Id $_.OwningProcess).ProcessName}} | Format-Table -AutoSize

Enterprise Port Hardening Reference

---

Default Account Security and Administrative Access Controls

Default accounts created during operating system installation represent high-value reconnaissance targets because their names and Security Identifiers (SIDs) are globally predictable.

Hardening Default Administrative Accounts

• The Windows Administrator Account: Windows assigns the built-in Administrator account a fixed, well-known Relative Identifier (RID) of -500 (e.g., S-1-5-21-...-500). Attackers utilize tools to query RID -500 regardless of whether the account has been renamed. Hardening steps include:
  1. Rename the Account: Change Administrator to an obscure, non-standard administrative alias (configured via Group Policy: Computer Configuration → Windows Settings → Security Settings → Local Policies → Security Options).
  2. Disable the Account: In domain environments, disable the local built-in Administrator account on all member servers and deploy Microsoft LAPS (Local Administrator Password Solution), which generates unique, rotating random passwords for each server's local administrator and stores them in Active Directory.
• The Linux root Account (UID 0): The root account possesses unrestricted superuser authority. Direct interactive remote login as root must be prohibited. Administrators must connect using individual, named accounts and elevate privileges via sudo (SuperUser DO):
  • Edit /etc/ssh/sshd_config and set: PermitRootLogin no.
  • Configure /etc/sudoers using visudo to grant granular, command-specific privileges to authorized groups (e.g., %wheel or %sudo) rather than blanket root shells.
• Default Guest Accounts: The built-in Guest account (RID -501 in Windows, or anonymous guest profiles in Linux) must remain permanently disabled and stripped of all network access rights.

Password Policies and Authentication Restrictions

Brute-force password guessing, dictionary attacks, and credential stuffing are mitigated by enforcing centralized password policies via Active Directory Group Policy Objects (GPOs) or Linux PAM (pam_pwquality):

+-----------------------------------------------------------------------------+
|                   Enterprise Password Policy Parameters                     |
|                                                                             |
|   * Minimum Password Length: 14 to 16+ Characters                           |
|   * Password Complexity: Uppercase, Lowercase, Digits, Special Characters   |
|   * Password History: Remember 24 previous passwords (prevent reuse)        |
|   * Maximum Password Age: 60 to 90 Days (or NIST 800-63B Passphrase rules)  |
|   * Account Lockout Threshold: 3 to 5 Invalid Attempts                      |
|   * Account Lockout Duration: 15 to 30 Minutes                              |
|   * Reset Lockout Counter After: 15 to 30 Minutes                           |
+-----------------------------------------------------------------------------+

[!WARNING] The Denial-of-Service Lockout Risk: Setting an Account Lockout Threshold to an overly aggressive value (e.g., 1 or 2 attempts) exposes the enterprise to a malicious Denial of Service (DoS) attack. An attacker can write a simple script that intentionally enters 1 incorrect password for every user account in the company directory, locking out the entire enterprise workforce simultaneously. An account lockout threshold of 5 failed attempts paired with a 30-minute lockout duration provides optimal brute-force resistance while mitigating automated lockout griefing.

---

Host-Based Firewall Configurations

While perimeter network firewalls filter traffic entering the data center boundary, Host-Based Firewalls run directly inside the server operating system kernel. They provide east-west micro-segmentation, ensuring that if a single web server is compromised, the attacker cannot pivot laterally across the local broadcast domain to compromise adjacent database or storage servers.

Windows Defender Firewall with Advanced Security

Windows Defender Firewall enforces stateful Layer 4 packet inspection across three distinct network location profiles:

+-----------------------------------------------------------------------------+
|                 Windows Firewall Profile Matching Hierarchy                 |
|                                                                             |
|   1. DOMAIN PROFILE:                                                        |
|      * Applied automatically when the NIC authenticates to an AD DS DC.     |
|      * Least restrictive internally (allows domain RPC, Kerberos, SMB).     |
|                                                                             |
|   2. PRIVATE PROFILE:                                                       |
|      * Manually assigned to isolated, trusted internal/workgroup networks.  |
|      * Permits local network discovery and file/printer sharing.            |
|                                                                             |
|   3. PUBLIC PROFILE:                                                        |
|      * Default assignment for newly detected networks and DMZ subnets.      |
|      * MOST RESTRICTIVE: Blocks all inbound discovery, SMB, and NetBIOS.    |
+-----------------------------------------------------------------------------+

• Default Inbound Policy: Block all unsolicited inbound connections unless explicitly permitted by an active rule.
• Default Outbound Policy: Allow all outbound connections (in hardened high-security environments, outbound traffic is also flipped to default deny, permitting only required destination ports like DNS and HTTPS).

# PowerShell: Create an inbound firewall rule allowing HTTPS on TCP 443 across Domain and Private profiles
New-NetFirewallRule -DisplayName "Enterprise Web Service (HTTPS)" -Direction Inbound -Action Allow -Protocol TCP -LocalPort 443 -Profile Domain, Private -Description "Allows inbound secure web traffic from enterprise clients"

# PowerShell: Enable all firewall profiles
Set-NetFirewallProfile -Profile Domain, Private, Public -Enabled True

Linux Host Firewalls: nftables, firewalld, and ufw

Modern Linux kernels implement network filtering via the nftables subsystem (the successor to legacy iptables). Administrators interact with nftables directly or via high-level front-end management daemons:

• firewalld (Red Hat / CentOS / Rocky Linux / SUSE): A dynamic firewall daemon that organizes network interfaces into Zones (e.g., drop, block, public, external, dmz, internal, trusted):
  • public: Default zone. Allows established connections and explicitly permitted services (e.g., SSH).
  • trusted: All network packets entering the interface are accepted without filtering.
• ufw (Uncomplicated Firewall - Debian / Ubuntu): A streamlined command-line interface designed to simplify packet filtering configuration.

# firewalld: Allow HTTPS traffic permanently in the public zone and reload configuration
sudo firewall-cmd --zone=public --add-service=https --permanent
sudo firewall-cmd --reload

# ufw: Set default policies to deny inbound and allow outbound
sudo ufw default deny incoming
sudo ufw default allow outgoing

# ufw: Allow incoming SSH on port 22 and enable the firewall
sudo ufw allow 22/tcp
sudo ufw enable

---

Patch Management and Vulnerability Scanning

Operating system vendors and open-source communities continuously identify security flaws in server kernels, system libraries, and background daemons. Maintaining an aggressive, disciplined patch management lifecycle is essential to server survival.

Patch Classification and Deployment Rings

Enterprise patch governance organizes software updates into standardized tiers:

1. Security Updates / Critical Fixes: Patches addressing remotely exploitable vulnerabilities, privilege escalation flaws, or active zero-day exploits. Deployed on an accelerated schedule.
2. Cumulative Rollups / General Updates: Monthly bundles containing bug fixes, reliability improvements, and non-security patches.
3. Firmware and Microcode Updates: UEFI BIOS updates and CPU microcode patches addressing hardware-level vulnerabilities (e.g., Spectre, Meltdown, Downfall).

[!IMPORTANT] The Staged Deployment Ring Architecture: Systems administrators must never deploy patches directly into production environments. Patches must progress through progressive deployment rings: Development → Testing/Staging → Pilot Group (Canary) → Broad Production. Each phase must incorporate automated functional validation and a documented Rollback Plan (such as hypervisor VM snapshots, system restore points, or backup recovery targets) in the event an update causes kernel panics or service degradation.

Vulnerability Scanning and CVE / CVSS Analysis

To proactively verify that server hardening and patch deployments are successful, security teams execute scheduled vulnerability assessments using enterprise vulnerability scanners (such as Tenable Nessus, OpenVAS / Greenbone, or Qualys):

• Common Vulnerabilities and Exposures (CVE): A standardized, publicly registered identifier assigned to a specific information security vulnerability (e.g., CVE-2021-44228).
• Common Vulnerability Scoring System (CVSS): A vendor-agnostic numerical framework (scale of 0.0 to 10.0) indicating the severity of a vulnerability based on its exploitability metrics (Attack Vector, Attack Complexity, Privileges Required) and impact metrics (Confidentiality, Integrity, Availability):
  • Low: 0.1 – 3.9
  • Medium: 4.0 – 6.9
  • High: 7.0 – 8.9
  • Critical: 9.0 – 10.0 (Remotely exploitable without privileges; immediate remediation required).

Credentialed vs. Uncredentialed Scans

Application Hardening and Hardware Hardening

OS hardening closes the operating system's attack surface, but SK0-005 treats application hardening and hardware hardening as separate required layers.

Application Hardening

Applications carry their own default-open surface that OS hardening never touches:

• Install the latest patches for the application itself, on its own vendor cadence — an application stack is frequently patched independently of the OS and is the more commonly exploited layer.
• Disable unneeded services, roles, or features within the application: sample databases and demo sites, directory browsing, WebDAV, unused authentication providers, legacy protocol endpoints, and management interfaces bound to public addresses.
• Remove or rename default accounts and change default credentials — vendor defaults are published, indexed, and scanned for continuously.
• Run the service under a least-privileged, non-interactive service account rather than LocalSystem or root, and remove interactive logon rights from it.
• Constrain the runtime: application pool identities, systemd sandboxing directives, chroot/jail confinement, and read-only mounts for content directories.

Hardware Hardening

Hardware hardening removes physical and firmware-level footholds:

• Disable unneeded hardware, physical ports, devices, or functions in firmware — unused USB ports and mass-storage class, optical drives, serial and legacy ports, unpopulated onboard NICs, and wireless or Bluetooth radios on management boards.
• Set a BIOS/UEFI password so an attacker with console access cannot change settings, disable Secure Boot, or enable an alternate boot path.
• Set the boot order to boot only from the intended internal device, and disable USB, optical, and PXE boot on servers that do not require network installation.
• Enable Secure Boot and TPM-backed measured boot, and enable chassis intrusion detection so cover removal is logged.

Host Security: Antivirus, Anti-Malware, and HIDS/HIPS

The blueprint's host security bullet names antivirus, anti-malware, and host intrusion detection/prevention explicitly, and the distinction between the last two is regularly tested:

The operational trade-off is the exam point: HIDS cannot stop an in-progress attack, while HIPS can — and can also break a legitimate application when a false positive lands inline. That is why HIPS is deployed in detect-only mode first, tuned against a baseline, and only then switched to blocking. On servers, all three are additionally scoped with exclusions for database files, transaction logs, and hypervisor virtual disks, because real-time scanning of those paths causes severe I/O degradation and file locking.