How to secure NGINX on all Linux systems
What is NGINX?
NGINX (Engine X) is a well known open source project originally written by Igor Sysoev, a Russian engineer. Igor started the project in 2002 and made it public in 2004. Since that time NGINX has become a de‑facto standard for high‑performance, scalable websites. Tens of millions of active websites use NGINX, including the majority of the 100,000 busiest websites in the world. Companies like Airbnb, Box, Dropbox, Netflix, Tumblr, WordPress.com, and many others deploy NGINX for scalability and performance reasons.
NGINX is overtaking Apache for deployment on the web. In a survey conducted by NETCRAFT we'll find that the market share of NGINX is increasing compared to other Web Servers.
What are the Goals of these procedures?
The goal of this procedure is to create a secure environment that could be used for ecommerce Payment Card Industry Data Security Standard (PCI DSS), Encrypt II, German Government Encryption Standards, France Government Encryption Standards, United Kingdom Government Encryption Standards, United States (US) National Institute of Standards and Technology (NIST), International Organization for Standardization (ISO), United States (US) National Security Agency (NSA), United States (US) Department of Defense (DoD) and etc. based compliant security stance that will garner an A+ on any/every security pen testing application. This procedure has taken quite a bit of time and painful attempts at refining and perfecting this security posture.
This procedure was completed using two (1 - RSA & 1 - Elliptical Curve) $8 USD Certificate Authority (CA) signed certificate from Sectigo (previously Comodo) and RapidSSL (Digicert) for the domain zombiesecured.com. The server used was an old desktop (2.4 GHz, 8 Gig RAM), DDNS (Dynamic DNS) and a slow home Internet connection. External performance stats were not collected since the server is on a less than optimal setup for such things. This site was not developed to be amazing or appealing, it is just straight forward to minimize its already vastness. There is a lot of information contained in the informational section for guidance and understanding of the concepts. The example domain used for this procedure is www.EXAMPLE.com and should be changed to suit your needs.
This configuration will offset the following vulnerabilities:
The various sections discuss preferences and why or how they will be implemented. Alternative configurations are proposed for granular or global control of things. This procedure is very comprehensive, time intensive, and produces a solid/secure stance for NGINX. The resulting configuration is not too restrictive and has all of the latest improvements included to ensure completeness. Some of the proposed settings might have to be altered to fit your environments needs.
Check for these vulnerabilities here
- Timing Attack (TIME)
- Browser Reconnaissance and Exfiltration via Adaptive Compression of Hypertext (BREACH)
- Browser Exploit Against SSL/TLS Tool (BEAST)
- Compression Ratio Info-leak Made Easy (CRIME)
- Heartbleed
- Padding Oracle On Downgraded Legacy Encryption (Poodle)
- TLS Downgrade (TLS-FALLBACK-SCSV)
- Security Losses from Obsolete and Truncated Transcript Hashes (SLOTH)
- Factoring RSA-EXPORT Keys (FREAK) Attack & Mobile Device FREAK
- Perfect Forward Secrecy (FS)
- Logjam (DH Export) explained
- Weak Diffie-Hellman Test
- Cipher RC4
- Decrypting RSA with Obsolete and Weakened eNcryption (DROWN)
- OpenSSL Vulnerabilities
***One note of caution -
Without the use of Domain Name System Security (DNSSEC) to accompany this procedure, you are open to man in the middle attacks! Stay tuned for the step by step procedure for setting up BIND DNSSEC to follow!
The following are the required technologies or infrastructure to be considered "Secured" for Web communications:
- Domain Name System (DNS) Security (DNSSEC)
- Hypertext Transfer Protocol (HTTP) Strict Transport Protocol (HSTS) & other Security Headers
- Hypertext Transfer Protocol Secure (HTTPS)
- Current Valid SSL/TLS Certificate
- Current SSL/TLS Cipher and Protocols usage that meet standards
- All applicable and appropriate application/operating system (OS) patch/kernel updates are maintained up to date
- Appropriate minimal permissions/modules in order to operate without impacting or limiting performance
- Preference for Hypertext Transfer Protocol (HTTP) version 2 (H2), http/1.1 with upgrade support
- Clients are using newer browsers and operating systems if possible