H4CK0R Network Security · Recon · Education

🧱 Hardening That Is Worth Doing

Recon, Defence & Ethics Intermediate 10 min read 1,977 words

Hardening Checklists That Are Actually Worth Doing

Most published hardening guides run to hundreds of controls, which is precisely why they do not get implemented. What follows is the short version: the items that remove whole classes of attack, the reasoning for each, and the tool here that verifies it afterwards. Verification is the part people skip — an untested control is a belief, not a defence.

If you only do five things Key-only SSH with no root login · automatic security updates · default-deny inbound firewall · multi-factor authentication on the registrar, DNS provider and cloud console · offline backups you have actually restored from.

1 · Linux host

SSH: keys only

Internet-facing SSH is under constant automated password attack. Key-only authentication ends that category outright — no password to guess, spray or reuse. Put overrides in a drop-in file so package upgrades do not clobber them:

# /etc/ssh/sshd_config.d/99-hardening.conf
PermitRootLogin no
PasswordAuthentication no
KbdInteractiveAuthentication no
PubkeyAuthentication yes
AuthenticationMethods publickey
MaxAuthTries 3
LoginGraceTime 20
AllowGroups ssh-users
X11Forwarding no

# Validate BEFORE restarting, and keep your current session open:
#   sshd -t && systemctl reload ssh     # unit is "sshd" on RHEL-family

PermitRootLogin no forces attribution: people log in as themselves and escalate, so auth.log names a human. AllowGroups is an allow-list, which fails safe when somebody adds a service account later. On older releases the keyboard-interactive setting is named ChallengeResponseAuthentication.

Patching, firewall, surface

Verify: port scan → the host from outside and compare against the services you intended to expose — this is the single fastest way to find a listener you forgot. TCP latency check → distinguishes filtered from slow.

2 · Web server and application

TLS

RFC 8996 (2021) formally deprecates TLS 1.0 and 1.1. Floor at TLS 1.2, prefer 1.3, and use only AEAD suites with ephemeral key exchange so a future compromise of the server key cannot decrypt recorded traffic:

ssl_protocols TLSv1.2 TLSv1.3;
ssl_prefer_server_ciphers off;
# one directive, one line — nginx rejects a wrapped argument list
ssl_ciphers ECDHE-ECDSA-AES128-GCM-SHA256:ECDHE-RSA-AES128-GCM-SHA256:ECDHE-ECDSA-AES256-GCM-SHA384:ECDHE-RSA-AES256-GCM-SHA384:ECDHE-ECDSA-CHACHA20-POLY1305:ECDHE-RSA-CHACHA20-POLY1305;
ssl_session_tickets off;
ssl_stapling on;
ssl_stapling_verify on;
add_header Strict-Transport-Security "max-age=31536000; includeSubDomains" always;

Notes that matter: TLS 1.3 suites are not set by ssl_ciphers in nginx — they negotiate separately and are fine at defaults. max-age=31536000 is one year; add preload only when every subdomain is HTTPS, because removal from the preload list is slow. Drop RC4 (prohibited by RFC 7465), 3DES, and any export, NULL or anonymous suite.

Response header baseline
HeaderValueWhat it stops
Strict-Transport-Securitymax-age=31536000; includeSubDomainsDowngrade to HTTP and SSL-stripping on later visits
Content-Security-PolicyStart with default-src 'self'; add sources deliberatelyThe impact of an XSS — the biggest single win, and the most work
X-Content-Type-OptionsnosniffMIME sniffing turning an upload into executable script
Content-Security-Policy: frame-ancestorsframe-ancestors 'none' (or X-Frame-Options: DENY for old clients)Clickjacking
Referrer-Policystrict-origin-when-cross-originLeaking paths and query strings (tokens!) to third parties
Permissions-Policygeolocation=(), camera=(), microphone=()Embedded content reaching for device APIs
Cross-Origin-Opener-Policysame-originCross-window references from other origins

X-XSS-Protection is obsolete; modern browsers ignore it or it is set to 0. Do not add it as a "score booster".

The rest of the web checklist

Verify: grade security headers →, analyse the CSP →, audit cookie flags →, probe allowed methods →, test CORS →, inspect negotiated cipher suites →, check the certificate → and check for exposed paths → (authorised targets only).

3 · DNS and email

Domain control is authentication for everything else — mail, certificates, password resets. Losing it is worse than losing a server.

Verify: full DNS audit →, DNSSEC validation →, SPF/DKIM/DMARC check →, MX, STARTTLS and MTA-STS →, and build records with the SPF builder → and DMARC builder →. If you run outbound mail, check the sending address against blocklists → too.

4 · Cloud

Verify: cloud posture needs provider-native tooling, because those checks live in the control plane rather than on the wire. What this site confirms is the internet-facing result: what is reachable →, what the edge returns →, whether a WAF or CDN is in front →, and whether certificates are about to expire →.

Key takeaways
  • Key-only SSH, automatic security updates and a default-deny firewall remove more real risk than any other three host controls.
  • A TLS 1.2 floor with ECDHE + AEAD suites plus the header baseline covers most transport and browser-side work. CSP is the expensive one, and the one worth doing.
  • .git in the webroot leaks the entire source history — deploy artefacts, and exclude dotfiles without breaking /.well-known/.
  • Domain control is the root of trust: registrar lock, MFA, CAA, DMARC at p=reject. Domains that send no mail must say so.
  • In cloud: short-lived credentials, IMDSv2, and audit logs stored where an attacker in production cannot delete them.
  • A control you have not verified from outside is a belief. Every block above names the tool that checks it.