Improving Web Security Through Apache Hardening

Challenge

A customer's public-facing web infrastructure received a poor external security assessment due to missing HTTP security headers, outdated TLS settings and inconsistent Apache configuration.

The objective was to improve the overall security posture without affecting application compatibility or introducing unnecessary operational complexity.

Approach

A comprehensive Apache hardening strategy was developed based on current security best practices.

The implementation included:

• Modern TLS configuration

• Secure cipher selection

• HTTP Strict Transport Security (HSTS)

• Content Security Policy (CSP)

• X-Frame-Options

• X-Content-Type-Options

• Referrer Policy

• Permissions Policy

• Secure cookie configuration where applicable

• Removal of unnecessary information disclosure

• Consolidation of all security settings into a reusable security.conf include file

Particular attention was paid to maintaining compatibility while significantly improving the externally visible security posture.

Result

The resulting configuration provided a standardized security baseline that could easily be reused across multiple Apache installations.

Benefits included:

• Improved external security assessment results

• Consistent security configuration across environments

• Reduced administrative effort

• Simplified maintenance through centralized configuration

• Better compliance with current web security recommendations

Technologies

Apache HTTP Server • TLS • HTTP Security Headers • CSP • HSTS • PKI • Linux • Bash

Infrastructure Standardization Across Mixed Linux Distributions

Challenge

Many enterprise environments evolve over time and end up running a heterogeneous mix of Linux distributions, including Red Hat Enterprise Linux, Debian, Ubuntu and SUSE.

While each platform serves its purpose, differences in package management, service handling, configuration layouts and operational procedures often lead to unnecessary complexity, increased maintenance effort and inconsistent security standards.

The objective was to establish a unified operational model without forcing organizations into a single distribution.

Approach

A distribution-independent management strategy was developed, focusing on standardization rather than replacement.

Key design principles included:

• POSIX-compliant administration scripts

• Automatic operating system detection

• Unified configuration structures

• Common service management procedures

• Standardized Apache, Squid and Postfix configurations

• Reusable Ansible roles

• Consistent security baselines

• Centralized documentation and operational guidelines

Where platform-specific behaviour was unavoidable, it was abstracted behind common interfaces to provide a consistent administrative experience.

Result

The standardized approach significantly reduced operational complexity while preserving the flexibility to support multiple Linux distributions.

Key benefits included:

• Simplified system administration

• Faster onboarding of new administrators

• Reduced configuration drift

• Improved maintainability

• Consistent security configuration

• Easier automation

• Faster operating system migrations

• Lower long-term operational costs

The resulting framework enabled administrators to manage heterogeneous Linux infrastructures using largely identical operational procedures, regardless of the underlying distribution.

Technologies

Debian • RHEL • AlmaLinux • Ubuntu • SUSE • Bash • POSIX Shell • Ansible • Apache • Squid • Postfix • Git

Security Assessment and Hardening

Challenge

A security assessment identified a number of weaknesses across an enterprise web infrastructure. The findings included outdated TLS configurations, missing HTTP security headers, unnecessary information disclosure and inconsistent security settings across Apache installations.

The challenge was not simply to address individual scanner findings, but to establish a consistent and maintainable security baseline that could be applied across multiple systems without breaking existing applications.

Approach

The assessment results were analyzed from an operational and architectural perspective rather than treating each finding in isolation.

The hardening process included:

• Reviewing TLS protocols and cipher configurations

• Removing obsolete and insecure protocol options

• Implementing HSTS and modern HTTP security headers

• Introducing Content Security Policy where technically appropriate

• Adding protections such as X-Content-Type-Options and X-Frame-Options

• Reducing unnecessary server and version information disclosure

• Reviewing Apache modules and exposed functionality

• Standardizing security-related configuration across virtual hosts

• Separating security policy from application-specific configuration

• Validating changes against existing application requirements

A reusable Apache security.conf configuration was developed to provide a common security baseline while keeping individual virtual host configurations clean and maintainable.

The configuration was designed as an operational standard rather than a one-off remediation, allowing the same security principles to be applied consistently across the environment.

Result

The project transformed individual security findings into a reusable infrastructure security standard.

Key benefits included:

• Improved external security assessment results

• Consistent security configuration across Apache servers

• Reduced configuration drift

• Improved TLS and HTTP security posture

• Reduced information disclosure

• Easier auditing and compliance verification

• Simplified deployment and maintenance

• A reusable baseline for future Apache installations

The approach also established a clear separation between application configuration and infrastructure security policy, making future security improvements significantly easier to implement.

Technologies

Apache HTTP Server • Linux • TLS / SSL • PKI • HTTP Security Headers • HSTS • CSP • Security Hardening • Bash • Configuration Management

CVE Assessment and Threat Model Analysis

Challenge

Enterprise security environments generate a continuous stream of CVE notifications from vulnerability scanners, vendor advisories and security monitoring systems.

A CVE score alone, however, does not determine the actual risk to a particular infrastructure. A vulnerability may be critical in one environment while presenting little or no practical attack path in another.

The challenge was therefore to distinguish between theoretical vulnerability severity and actual environmental risk, while providing a technically defensible remediation decision.

Approach

CVE findings were analyzed using a structured threat-model approach rather than relying solely on the published CVSS score.

For each vulnerability, the analysis considered:

• Affected software and package versions

• Vendor remediation and fixed versions

• Attack vector and required privileges

• Local versus remote exploitability

• Required authentication

• Network exposure

• Available attack surfaces

• Relevant kernel modules, services and configuration options

• Presence or absence of vulnerable functionality

• Potential attacker capabilities

• Existing network and security controls

• Realistic attack paths within the customer's environment

Particular attention was given to the distinction between a vulnerability being present in a package and the vulnerable functionality actually being enabled, loaded or reachable.

Where appropriate, technical verification was performed directly on affected systems. This included checking installed package versions, kernel configuration, loaded modules, listening services and relevant system configuration.

The resulting analysis documented not only whether a system was technically vulnerable, but also whether a realistic threat path existed from the assumed attacker position.

Risk Assessment

The assessment separated several questions that are often conflated during vulnerability management:

Is the vulnerable software installed?

Is the vulnerable functionality enabled?

Can an attacker reach it?

What privileges are required?

Can the assumed attacker obtain those privileges?

What controls already prevent or limit exploitation?

This allowed CVEs to be classified according to the actual threat model of the affected environment rather than treating every scanner finding as an equivalent security incident.

Remediation

Where remediation was required, the preferred solution was to install the vendor-provided fixed package or update.

Where immediate patching was not possible, compensating controls were evaluated, including:

• Disabling unused functionality

• Removing unnecessary kernel modules

• Restricting network exposure

• Limiting access to affected services

• Strengthening authentication and privilege boundaries

• Monitoring relevant attack surfaces

Remediation decisions were documented together with their technical justification and residual risk.

Result

The approach transformed large volumes of CVE findings into actionable, evidence-based security decisions.

Key benefits included:

• Reduced vulnerability-management noise

• Clear distinction between theoretical and practical exposure

• Better prioritization of remediation work

• Technically documented risk decisions

• Improved communication between security and infrastructure teams

• Reproducible assessment methodology

• Reduced risk of both under- and over-remediation

The resulting threat-model analysis provided a common technical language for security teams, infrastructure engineers and management when deciding how individual CVEs should be handled.

Technologies & Methodology

CVE / CVSS • Threat Modeling • Linux • RHEL • Debian • Kernel Configuration • Package Management • Network Exposure Analysis • Security Hardening • Vulnerability Management • Bash • Ansible