How to secure Apache on all Linux systems

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. 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.

Apache is fading away

NGINX (Engine X) is overtaking Apache for deployment on the web. The Apache Foundation documents are horrible and we have been complaining about it for years.

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.

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 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

  • 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

Who can use this procedure?

Anyone and everyone!!!

Please choose the Operating System (OS):

Debian/Ubuntu
Fedora/Centos/Suse/RedHat