Skip to content

Latest commit

 

History

History
279 lines (208 loc) · 15.7 KB

mitigations.md

File metadata and controls

279 lines (208 loc) · 15.7 KB

Mitigation Strategies Analysis for apache/httpd

Mitigation Strategy: Disable Unnecessary Modules

Mitigation Strategy: Disable Unnecessary Apache Modules.

  • Description:

    1. Identify Required Modules: Analyze your application's functionality to determine the absolute minimum set of Apache modules needed.
    2. List Loaded Modules: Use apachectl -M (or httpd -M).
    3. Locate Configuration Files: Find httpd.conf, apache2.conf, or included configuration files (often in /etc/apache2/mods-enabled/ or /etc/httpd/conf.d/).
    4. Comment Out LoadModule Directives: Comment out lines starting with LoadModule for unnecessary modules using #. Example: 
      #LoadModule dav_module modules/mod_dav.so
    5. Test Configuration: Use apachectl configtest (or httpd -t).
    6. Restart Apache: Restart the Apache service (e.g., systemctl restart apache2).
    7. Verify: Re-run apachectl -M and test your application.

  • Threats Mitigated:

    • Module-Specific Vulnerabilities (High Severity): Exploits targeting vulnerabilities in specific, unused modules.
    • Increased Attack Surface (Medium Severity): Each module adds complexity.
    • Resource Consumption (Low Severity): Unnecessary modules consume resources.

  • Impact:

    • Module-Specific Vulnerabilities: Risk reduced to negligible.
    • Increased Attack Surface: Risk significantly reduced.
    • Resource Consumption: Risk slightly reduced.

  • Currently Implemented: (Example) "Partially implemented. mod_dav disabled. Review pending."

  • Missing Implementation: (Example) "Full audit incomplete. Modules in /etc/apache2/mods-enabled/ need review."

Mitigation Strategy: Configure Server Tokens and Signature

Mitigation Strategy: Minimize Server Information Disclosure.

  • Description:

    1. Locate Configuration File: Open the main Apache configuration file.
    2. Set ServerTokens: Set to Prod: ServerTokens Prod
    3. Set ServerSignature: Set to Off: ServerSignature Off
    4. Test Configuration: apachectl configtest (or httpd -t).
    5. Restart Apache: Restart the service.
    6. Verify: Use curl -I <your_website_url> to check headers.

  • Threats Mitigated:

    • Information Disclosure (Medium Severity): Revealing version and OS details.
    • Targeted Attacks (Medium Severity): Attackers use version info for specific exploits.

  • Impact:

    • Information Disclosure: Risk significantly reduced.
    • Targeted Attacks: Risk moderately reduced.

  • Currently Implemented: (Example) "Fully implemented. Settings in httpd.conf."

  • Missing Implementation: (Example) "Not implemented. Default settings reveal version."

Mitigation Strategy: Disable Directory Listing

Mitigation Strategy: Prevent Directory Browsing.

  • Description:

    1. Identify Webroot: Find the DocumentRoot.
    2. Locate Configuration: Use the main config file (in a <Directory> block) or a .htaccess file (if enabled).
    3. Add Options -Indexes:
      • In httpd.conf: 
        <Directory "/path/to/webroot">
    Options -Indexes
</Directory>
      • In .htaccess: Options -Indexes
    4. Alternative: Ensure Index Files: Ensure every directory has an index file (e.g., index.html).
    5. Test Configuration: apachectl configtest (if using main config).
    6. Restart Apache: Restart if using main config.
    7. Verify: Access a directory without an index file; expect a 403 error.

  • Threats Mitigated:

    • Information Disclosure (Medium Severity): Exposing file/directory structure.
    • Source Code Disclosure (High Severity): Exposing source code if placed in a public directory.

  • Impact:

    • Information Disclosure: Risk significantly reduced.
    • Source Code Disclosure: Risk significantly reduced (with proper file placement).

  • Currently Implemented: (Example) "Partially. Options -Indexes in main block. Subdirectory review needed."

  • Missing Implementation: (Example) "Not implemented. Listing enabled; some directories lack index files."

Mitigation Strategy: Control .htaccess Files

Mitigation Strategy: Restrict or Disable .htaccess Overrides.

  • Description:

    1. Determine Necessity: Decide if .htaccess is needed.
    2. Disable .htaccess (If Possible): In <Directory />, set AllowOverride None.
    3. Restrict .htaccess (If Necessary): Use AllowOverride with specific options (e.g., AllowOverride AuthConfig).
    4. Test Configuration: apachectl configtest.
    5. Restart Apache: Restart the service.
    6. Verify: Test .htaccess behavior (disabled or restricted as intended).

  • Threats Mitigated:

    • Unauthorized Configuration Changes (High Severity): Attackers modifying .htaccess.
    • Bypassing Security Controls (High Severity): Overriding main config settings.

  • Impact:

    • Unauthorized Configuration Changes: Risk eliminated (disabled) or significantly reduced (restricted).
    • Bypassing Security Controls: Risk significantly reduced.

  • Currently Implemented: (Example) "Fully. AllowOverride None globally."

  • Missing Implementation: (Example) "Partially. AllowOverride All allows any override."

Mitigation Strategy: Limit Request Sizes

Mitigation Strategy: Configure Request Size Limits.

  • Description:

    1. Locate Configuration File: Open the main Apache configuration file.
    2. Set LimitRequestBody: Limit POST data size (in bytes). Example: LimitRequestBody 10485760 (10MB)
    3. Set LimitRequestFields: Limit the number of header fields. Example: LimitRequestFields 100
    4. Set LimitRequestFieldSize: Limit individual header field size. Example: LimitRequestFieldSize 8190
    5. Set LimitRequestLine: Limit the request line size. Example: LimitRequestLine 8190
    6. Test Configuration: apachectl configtest.
    7. Restart Apache: Restart the service.
    8. Verify: Test with requests exceeding limits; expect 413 or 400 errors.

  • Threats Mitigated:

    • Denial of Service (DoS) (Medium Severity): Large requests consuming resources.
    • Buffer Overflow Exploits (High Severity): Excessively large values triggering overflows.

  • Impact:

    • Denial of Service: Risk moderately reduced.
    • Buffer Overflow Exploits: Risk reduced (not a primary defense).

  • Currently Implemented: (Example) "Partially. LimitRequestBody set. Others at defaults."

  • Missing Implementation: (Example) "Not implemented. No limits configured."

Mitigation Strategy: Configure Timeouts

Mitigation Strategy: Adjust Timeout Settings.

  • Description:

    1. Locate Configuration File: Open the main Apache configuration file.
    2. Set Timeout: Time (seconds) for operations (e.g., Timeout 60).
    3. Set KeepAliveTimeout: Time (seconds) for persistent connections (e.g., KeepAliveTimeout 5).
    4. Consider mod_reqtimeout (Optional): For finer control, enable and configure mod_reqtimeout.
    5. Test Configuration: apachectl configtest.
    6. Restart Apache: Restart the service.
    7. Verify: Monitor performance and logs.

  • Threats Mitigated:

    • Slowloris Attacks (Medium Severity): Holding connections open.
    • Resource Exhaustion (Low Severity): Long timeouts tying up resources.

  • Impact:

    • Slowloris Attacks: Risk moderately reduced.
    • Resource Exhaustion: Risk slightly reduced.

  • Currently Implemented: (Example) "Partially. Timeout and KeepAliveTimeout set. mod_reqtimeout not enabled."

  • Missing Implementation: (Example) "Not implemented. Default timeouts used."

Mitigation Strategy: Keep Apache Updated

Mitigation Strategy: Regularly Update Apache and Modules.

  • Description:

    1. Establish an Update Process: Define a schedule for updates.
    2. Subscribe to Security Announcements: Use the Apache httpd security list and OS/module lists.
    3. Use Package Manager (Recommended): Use apt, yum, dnf, etc.
    4. Test Updates in a Staging Environment: Test before production.
    5. Apply Updates Promptly: Apply security updates quickly after testing.
    6. Verify Updates: Check Apache and application functionality.

  • Threats Mitigated:

    • Known Vulnerabilities (High to Critical Severity): Updates patch known exploits.
    • Zero-Day Vulnerabilities (Unknown Severity): Reduces the window of vulnerability.

  • Impact:

    • Known Vulnerabilities: Risk significantly reduced.
    • Zero-Day Vulnerabilities: Risk indirectly reduced.

  • Currently Implemented: (Example) "Partially. Updates are periodic, no formal schedule/staging."

  • Missing Implementation: (Example) "Not implemented. No updates since installation."

Mitigation Strategy: Secure mod_rewrite Usage

Mitigation Strategy: Carefully Craft and Validate mod_rewrite Rules.

  • Description:

    1. Minimize Complexity: Avoid overly complex rules.
    2. Validate Input: Validate and sanitize input used in rewrite conditions/targets. Use regex.
    3. Avoid Open Redirects: Validate redirect URLs; use a whitelist if possible.
    4. Test Thoroughly: Test with various inputs, including invalid data. Use RewriteLog.
    5. Regular Review: Periodically review rules.

  • Threats Mitigated:

    • Open Redirects (High Severity): Redirecting to malicious sites.
    • Path Traversal (High Severity): Accessing files outside the webroot.
    • Code Injection (Critical Severity): Possible with poor input validation.
    • Denial of Service (Medium Severity): Inefficient rules consuming resources.

  • Impact:

    • Open Redirects: Risk significantly reduced.
    • Path Traversal: Risk significantly reduced.
    • Code Injection: Risk significantly reduced.
    • Denial of Service: Risk moderately reduced.

  • Currently Implemented: (Example) "Partially. Basic rules, not fully reviewed. Inconsistent input validation."

  • Missing Implementation: (Example) "Not Implemented. Rules used extensively, no security focus."

Mitigation Strategy: Secure mod_proxy and mod_proxy_http Usage

Mitigation Strategy: Securely Configure Reverse Proxy Settings.

  • Description:

    1. Trusted Backends Only: Proxy only to trusted servers.
    2. Careful ProxyPass and ProxyPassReverse: Use specific paths/URLs, not wildcards.
    3. Header Control:
      • ProxyPreserveHost On (Often Recommended): Passes the original Host header.
      • Sanitize Headers: Remove/sanitize potentially malicious headers.
    4. Avoid Request Smuggling: Ensure consistent HTTP handling (frontend/backend).
    5. Limit Proxy Buffer Sizes: Use ProxyIOBufferSize and LimitRequestBody.
    6. Disable Proxying if Not Needed: Disable mod_proxy and mod_proxy_http if unused.

  • Threats Mitigated:

    • Exposure of Backend Servers (High Severity): Exposing backends to direct attacks.
    • Information Leakage (Medium Severity): Leaking internal network info.
    • Request Smuggling (High Severity): Inconsistent HTTP handling.
    • Open Proxy (Critical Severity): Apache acting as an open relay.

  • Impact:

    • Exposure of Backend Servers: Risk significantly reduced.
    • Information Leakage: Risk moderately reduced.
    • Request Smuggling: Risk reduced.
    • Open Proxy: Risk eliminated.

  • Currently Implemented: (Example) "Partially. Used as reverse proxy, config not fully reviewed. No header sanitization."

  • Missing Implementation: (Example) "Not Applicable. Not used as a reverse proxy."

Mitigation Strategy: Configure MPM (Multi-Processing Module)

Mitigation Strategy: Choose and Configure the Appropriate MPM.

  • Description:

    1. Determine Requirements: Consider your server's resources, expected traffic, and application type.
    2. Choose MPM:
      • Event MPM (Recommended for most modern workloads): Uses a combination of processes and threads, with a dedicated thread for handling keep-alive connections. Generally more efficient and scalable than Prefork.
      • Worker MPM: Also uses processes and threads, but without the dedicated keep-alive handling of Event. A good alternative if Event is not available.
      • Prefork MPM: Uses multiple processes, each handling one connection at a time. Simpler, but less efficient for high-concurrency workloads. Often used for compatibility with non-thread-safe libraries.
    3. Locate Configuration: The MPM configuration is usually in a separate file (e.g., mpm.conf, httpd-mpm.conf) or within the main Apache configuration file.
    4. Configure Directives: Adjust the MPM-specific directives based on your chosen MPM and server resources. Key directives include:
      • MaxRequestWorkers (Event/Worker): The maximum number of simultaneous requests that can be handled.
      • ThreadsPerChild (Event/Worker): The number of threads per child process.
      • MaxConnectionsPerChild (Event/Worker/Prefork): The maximum number of connections a child process will handle before being recycled.
      • StartServers (Prefork): The number of child processes to start initially.
      • MinSpareServers/MaxSpareServers (Prefork): Control the number of idle child processes.
    5. Test Configuration: apachectl configtest.
    6. Restart Apache: Restart the service.
    7. Monitor Performance: Use tools like top, htop, or Apache's mod_status (if enabled and secured) to monitor server resource usage and adjust the MPM configuration as needed.

  • Threats Mitigated:

    • Denial of Service (DoS) (Medium Severity): An appropriately configured MPM can handle a larger number of concurrent connections and be more resilient to certain types of DoS attacks.
    • Resource Exhaustion (Low Severity): Proper MPM tuning can prevent the server from being overwhelmed by excessive resource consumption.
    • Compatibility Issues (Low to High): Choosing the correct MPM can prevent issues with non-thread-safe libraries.

  • Impact:

    • Denial of Service: Risk moderately reduced with a well-tuned MPM.
    • Resource Exhaustion: Risk moderately reduced.
    • Compatibility Issues: Risk reduced or eliminated by choosing the correct MPM.

  • Currently Implemented: (Example) "Partially Implemented. Event MPM is used, but the configuration has not been optimized for the current server resources and traffic load."

  • Missing Implementation: (Example) "Not Implemented. The default MPM (Prefork) is being used without any specific configuration."