Start with a small, supported server
Use a supported Linux distribution and Nginx release, apply security patches on a defined cadence, and subscribe to relevant advisories. Install only the packages and Nginx modules the service needs. Remove sample sites, unused interpreters, development tools, and dormant network services from production images.
Build servers from version-controlled configuration or images rather than relying on undocumented manual changes. Separate production from development and use a tested rollback path. Record the owner, purpose, data classification, public endpoints, dependencies, and recovery requirements for each host or workload.
Restrict users, privileges, and administration
Run Nginx workers and application services as dedicated non-root accounts. Give each service access only to required configuration, certificates, static files, sockets, logs, and upstreams. Keep application code read-only to the web process where practical, and do not make broad directories writable to solve deployment problems.
Restrict SSH to controlled networks or a managed access path. Use individual keys or federated identities, disable direct root login, remove stale keys, and apply multi-factor authentication where supported. Protect sudo access, record privileged changes, and avoid copying private keys between servers.
Host firewalls and cloud security groups should allow only required inbound and outbound traffic. If an edge proxy or CDN fronts the site, consider restricting origin access to that service and validate the mechanism used to identify the original client address.
Configure Nginx as a security boundary
Set explicit server names and a safe default virtual host so unknown hostnames are not routed into an application. Normalize and validate proxy paths carefully, especially where alias, rewrites, uploads, or user-controlled filenames are involved. Do not expose configuration, version-control directories, backups, environment files, logs, or application secrets as static files.
Set request-line, header, body, upload, connection, and timeout limits for the workload. Bound upstream response behaviour and handle proxy errors without exposing internal addresses or stack traces. Rate-limit authentication and abuse-prone endpoints with an approach that accounts for trusted proxy headers.
Add security headers based on the application: HSTS after HTTPS is stable, content-type sniffing protection, a suitable referrer policy, framing restrictions, permissions policy, and an application-specific Content Security Policy. Verify headers at the public endpoint because a CDN or upstream may add, remove, or override them.
Maintain TLS and secrets correctly
Use current TLS protocols and a configuration appropriate to the supported clients. The official Nginx HTTPS documentation notes that private keys require restricted file access while remaining readable to the master process. Automate certificate renewal and alert before expiry.
Keep private keys, deployment credentials, database passwords, and API tokens in a protected secret store or restrictive runtime configuration. Separate secrets by service and environment. Do not include them in images, repositories, shell history, support bundles, or general logs.
Protect logs, applications, and recovery paths
Forward logs to a protected central location and synchronize time. Monitor authentication, privilege changes, service restarts, configuration modifications, unexpected listening ports, integrity changes, resource pressure, Nginx error patterns, upstream failures, and unusual traffic. Logs should omit credentials and unnecessary personal data.
A web application firewall or edge service can reduce automated attack traffic and provide rate controls, but it does not replace patching or safe application code. Document bypass and troubleshooting access and ensure the origin cannot be reached around the control unintentionally.
Back up the configuration and business data required to rebuild, not necessarily the entire compromised server image. Test reconstruction in an isolated environment. Incident procedures should cover containment, snapshots or evidence, credential rotation, clean rebuilding, DNS or edge changes, validation, and monitoring after restoration.
Linux and Nginx review checklist
- Linux, Nginx, modules, and application runtimes are supported and patched.
- Packages, services, ports, modules, accounts, and writable paths are minimized.
- SSH, sudo, keys, firewalls, origin access, and proxy trust are restricted.
- Virtual hosts, paths, request limits, timeouts, TLS, and headers are explicit.
- Secrets and certificates are protected, rotated, and monitored for expiry.
- Central logs detect system, configuration, application, and network anomalies.
- Infrastructure can be rebuilt and data restored through a tested procedure.
