Writing Sample
Security / Hardening Guide

Security Documentation Sample

Linux Server Hardening Baseline (CIS-aligned, practical)

This guide provides a pragmatic hardening baseline for Ubuntu/RHEL-like systems. It focuses on controls that reduce risk quickly without breaking common workloads. Use your organization’s policy as the source of truth and validate changes in a staging environment.

Scope and assumptions

  • Target: Linux servers (VMs or bare metal) running production workloads.
  • Access: privileged admin access with change window.
  • Goal: reduce attack surface + improve auditability with minimal disruption.

Outcome checklist

  • Only required network services exposed
  • Strong authentication, minimal privileged access
  • Auditable logs with retention and time sync
  • Host firewall enforced, brute-force mitigation enabled
  • OS patching cadence defined

1) Reduce exposed services (attack surface)

List listening ports and identify what must be publicly reachable:

ss -lntup
# or
netstat -lntup

Action: disable services you do not need.

  • Remove legacy or unused daemons (FTP, Telnet, rsh, older RPC services).
  • Prefer modern, encrypted protocols (SSH, HTTPS).
  • Bind internal-only services to private interfaces.

2) SSH: secure remote administration

Recommended baseline (adjust to your environment):

  • Disable password login (use keys / SSO where available)
  • Disable direct root login
  • Limit allowed users/groups
  • Use modern ciphers/kex (OS defaults are usually fine on current distros)

Example configuration snippets (/etc/ssh/sshd_config):

PermitRootLogin no
PasswordAuthentication no
PubkeyAuthentication yes
AllowUsers opsadmin deploy
# Optional: restrict by group
# AllowGroups ssh-users

Reload safely (avoid locking yourself out):

sshd -t && systemctl reload sshd

3) Privilege management: least privilege by default

  • Create named admin accounts; avoid shared credentials.
  • Use sudo with explicit, auditable rules.
  • Require MFA where your access layer supports it (bastion/SSO/VPN).

Quick audit:

getent group sudo || getent group wheel
sudo -l -U <username>

4) Host firewall: enforce inbound policy

Use your distro’s standard firewall tooling. The key is to encode rules as policy: “only ports X/Y are allowed from networks A/B.”

Example (UFW on Ubuntu):

ufw default deny incoming
ufw default allow outgoing
ufw allow 22/tcp
ufw allow 443/tcp
ufw enable
ufw status verbose

Example (firewalld on RHEL-like distros):

firewall-cmd --set-default-zone=public
firewall-cmd --permanent --add-service=ssh
firewall-cmd --permanent --add-service=https
firewall-cmd --reload
firewall-cmd --list-all

5) Brute-force mitigation

Use a tool like fail2ban for SSH on internet-exposed hosts (or rely on upstream controls like a bastion). 

apt-get install -y fail2ban
systemctl enable --now fail2ban
fail2ban-client status

6) Logging, auditing, and time sync

For incident response, you need trustworthy timestamps and logs. At minimum: enable time sync and ensure logs are retained and queryable.

Time synchronization

timedatectl status
# common services:
systemctl status systemd-timesyncd || systemctl status chronyd

Audit and auth logs

  • Ensure authentication events are logged (SSH, sudo)
  • Forward logs to a central system where possible (SIEM/ELK)
  • Protect logs from tampering; define retention

7) Patching and vulnerability hygiene

  • Define a patch SLA (e.g., critical in 7 days, high in 14 days).
  • Automate updates for non-breaking packages where possible.
  • Scan periodically and track remediation to closure.

8) Baseline verification (quick checks)

After changes, validate the system’s posture:

# check listening services again
ss -lntup

# verify firewall
ufw status verbose || firewall-cmd --list-all

# confirm SSH settings (look for PasswordAuthentication/PermitRootLogin)
sshd -T | egrep 'passwordauthentication|permitrootlogin|allowusers|allowgroups'

# confirm time sync
timedatectl status

Change management notes

  • Apply hardening as code when possible (Ansible/Terraform) for repeatability.
  • Document exceptions explicitly (why, risk accepted, owner, review date).
  • Validate with a canary host before broad rollout.

This is a sample article to demonstrate how I write.