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. The is a lot of information contained in the informational sections 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.
The best analogy is Unix and Linux. Unix was too big, clunky, did not update fast enough, and expensive. Linux was developed by Linus Torvalds which quickly removed Unix from most organizations. NGINX has better documentation, faster updates and is growing by leaps and bounds. We here at Zombie will be moving to NGINX and create a securing NGINX procedure soon. F5 just acquired NGINX and lets hope F5 does not interfere with the business practices and success of NGINX. We love startups challenging the status quo and Zombie will be a supporter of NGINX going forward.
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 Apache 2.4. 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
***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: