Skip to content

Latest commit

 

History

History
83 lines (74 loc) · 8.37 KB

File metadata and controls

83 lines (74 loc) · 8.37 KB

Mitigation Strategies Analysis for envoyproxy/envoy

Mitigation Strategy: Secure Defaults and Hardening

  • Description:
    1. Review the default Envoy configuration and identify any insecure or unnecessary settings within Envoy itself.
    2. Disable default listeners and routes in Envoy configuration if they are not required for the application.
    3. Explicitly configure TLS settings in Envoy listeners, including minimum TLS version (e.g., TLSv1.3), strong cipher suites, and certificate validation. Do not rely on default TLS settings within Envoy.
    4. Disable unnecessary features and filters in Envoy configuration that are not used by the application to reduce the attack surface.
    5. Configure access logging in Envoy to log relevant security events, but carefully consider what data is logged to avoid exposing sensitive information.
    6. Implement resource limits (e.g., connection limits, request limits) directly in Envoy configuration to prevent resource exhaustion attacks.
  • Threats Mitigated:
    • Exploitation of Default Configurations - Severity: Medium
    • Exposure of Unnecessary Features - Severity: Low
    • Weak TLS Configuration - Severity: Medium
    • Resource Exhaustion Attacks - Severity: Medium
  • Impact:
    • Exploitation of Default Configurations: Medium risk reduction
    • Exposure of Unnecessary Features: Low risk reduction
    • Weak TLS Configuration: Medium risk reduction
    • Resource Exhaustion Attacks: Medium risk reduction
  • Currently Implemented: Partial - TLS settings are explicitly configured in Envoy. Default listeners are removed. Basic resource limits are in place in Envoy configuration.
  • Missing Implementation: Comprehensive review and hardening of all Envoy configuration parameters. Disabling unused filters and features in Envoy configuration. Fine-tuning access logging in Envoy for security without over-logging sensitive data.

Mitigation Strategy: TLS Termination and Encryption

  • Description:
    1. Configure Envoy listeners to terminate TLS connections for all external traffic (HTTPS). This is a direct Envoy configuration task.
    2. Use strong TLS ciphers and protocols. Configure tls_params in Envoy listener configuration to specify allowed cipher suites and minimum TLS version (e.g., TLSv1.3). This is Envoy specific configuration.
    3. Disable insecure or outdated ciphers and protocols (e.g., SSLv3, TLSv1.0, TLSv1.1, weak ciphers like RC4) within Envoy's TLS configuration.
    4. Enable HTTP Strict Transport Security (HSTS) by configuring the strict-transport-security header in Envoy's HTTP connection manager. Set appropriate max-age and consider includeSubDomains and preload directives. This is an Envoy HTTP filter configuration.
    5. Ensure TLS certificates are valid, correctly configured in Envoy, and regularly renewed. Monitor certificate expiry.
  • Threats Mitigated:
    • Man-in-the-Middle (MITM) Attacks on User Traffic - Severity: High
    • Data Eavesdropping - Severity: High
    • Session Hijacking - Severity: Medium
  • Impact:
    • Man-in-the-Middle (MITM) Attacks on User Traffic: High risk reduction
    • Data Eavesdropping: High risk reduction
    • Session Hijacking: Medium risk reduction
  • Currently Implemented: Yes - TLS termination is enabled for all external traffic in Envoy. Strong ciphers and TLSv1.3 are configured in Envoy. HSTS is enabled with max-age and includeSubDomains in Envoy.
  • Missing Implementation: preload directive for HSTS is not yet configured in Envoy. Regular review of cipher suites in Envoy configuration to ensure they remain strong and up-to-date.
  • Description:
    1. Utilize Envoy's built-in HTTP filters (e.g., envoy.filters.http.lua, envoy.filters.http.ext_authz) or develop custom filters within Envoy to perform input validation on HTTP requests.
    2. Validate HTTP headers, request bodies, query parameters, and paths against expected formats and values using Envoy filters.
    3. Sanitize input data to remove or escape potentially malicious characters or code before forwarding requests upstream using Envoy filters. For example, encode special characters in URLs, escape HTML entities in headers.
    4. Implement output sanitization in Envoy filters to sanitize responses from upstream services before sending them to clients. This can help prevent XSS attacks if upstream services might inadvertently return unsanitized data.
    5. Configure Envoy to reject requests that fail validation and return appropriate error responses (e.g., HTTP 400 Bad Request). This is Envoy filter behavior.
  • Threats Mitigated:
    • Cross-Site Scripting (XSS) - Severity: Medium to High (depending on context)
    • SQL Injection (if backend vulnerable) - Severity: High (if backend vulnerable)
    • Command Injection (if backend vulnerable) - Severity: High (if backend vulnerable)
    • Path Traversal Attacks - Severity: Medium
  • Impact:
    • Cross-Site Scripting (XSS): Medium risk reduction (Envoy can mitigate some, but backend also needs protection)
    • SQL Injection: Medium risk reduction (Envoy can reduce attack surface, backend needs primary protection)
    • Command Injection: Medium risk reduction (Envoy can reduce attack surface, backend needs primary protection)
    • Path Traversal Attacks: Medium risk reduction
  • Currently Implemented: Partial - Basic input validation is implemented for common HTTP headers and paths using a custom Lua filter in Envoy. Output sanitization is not implemented in Envoy.
  • Missing Implementation: More comprehensive input validation rules covering request bodies and query parameters in Envoy filters. Implementation of output sanitization in Envoy filters. Integration with a dedicated WAF as an Envoy filter for advanced input validation.

Mitigation Strategy: Comprehensive Access Logging

  • Description:
    1. Configure Envoy's access logging to capture sufficient information for security monitoring and incident response. This is direct Envoy configuration.
    2. Log relevant details such as: request timestamp, client IP address, request method, request path, request headers (selectively, avoid logging sensitive headers by default), response status code, response headers (selectively), latency, upstream cluster, and any relevant Envoy filter actions. This is configured within Envoy's access log settings.
    3. Ensure access logs are stored securely and are accessible to security teams for analysis. Use a centralized logging system. While log storage is external, configuring what to log is Envoy related.
    4. Implement log rotation and retention policies to manage log storage and compliance requirements. Log management is generally external, but configuring how much Envoy logs can influence this.
    5. Regularly review access logs for suspicious activity, anomalies, and potential security incidents. Log review is external, but the quality of Envoy logs impacts this.
  • Threats Mitigated:
    • Security Incident Detection (e.g., attacks, breaches) - Severity: High
    • Post-Incident Forensics and Analysis - Severity: High
    • Compliance Violations (if logging is required) - Severity: Medium
  • Impact:
    • Security Incident Detection: High risk reduction (improves detection capability)
    • Post-Incident Forensics and Analysis: High risk reduction (enables effective investigation)
    • Compliance Violations: Medium risk reduction (helps meet logging requirements)
  • Currently Implemented: Yes - Access logging is enabled in Envoy and logs are sent to a centralized logging system (Elasticsearch). Basic request details are logged via Envoy's access log configuration.
  • Missing Implementation: More granular control over logged headers in Envoy's access log configuration to selectively log security-relevant headers while avoiding sensitive data. Automated analysis of access logs for anomaly detection (this is more about tooling around Envoy logs).