Skip to content

Latest commit

 

History

History
123 lines (110 loc) · 14.3 KB

File metadata and controls

123 lines (110 loc) · 14.3 KB

Mitigation Strategies Analysis for kong/kong

Mitigation Strategy: Keep Kong Updated

  • Description:
    • Step 1: Regularly check for new Kong Gateway releases on the official Kong website or GitHub repository.
    • Step 2: Review the release notes for each new version to identify security patches and bug fixes specific to Kong.
    • Step 3: Plan a maintenance window for upgrading Kong.
    • Step 4: Follow the official Kong upgrade documentation for your deployment method (e.g., package manager, Docker, Kubernetes).
    • Step 5: After upgrading, thoroughly test Kong to ensure functionality and stability, specifically focusing on Kong's core features and plugins.
  • List of Threats Mitigated:
    • Exploitation of Known Kong Vulnerabilities - Severity: High
  • Impact:
    • Exploitation of Known Kong Vulnerabilities: High risk reduction. Addresses publicly known vulnerabilities within Kong itself that attackers could exploit to compromise the gateway or backend systems via Kong.
  • Currently Implemented: Yes, Automated checks for new Kong versions are in place, and a quarterly update schedule is followed. Location: DevOps pipeline and infrastructure management documentation.
  • Missing Implementation: Proactive vulnerability scanning specifically targeting Kong components and plugins is not yet fully automated and integrated into the CI/CD pipeline.

Mitigation Strategy: Restrict Admin API Access

  • Description:
    • Step 1: Identify the network interfaces where the Kong Admin API is currently exposed.
    • Step 2: Configure Kong to bind the Admin API only to internal network interfaces, not public-facing ones. Modify nginx_admin.conf or environment variables to set admin_listen within Kong's configuration.
    • Step 3: Implement firewall rules or network policies around the Kong instance to restrict access to the Admin API port (default 8001/8444) to only authorized IP addresses or networks (e.g., management network, jump hosts). This is about network controls specifically for Kong's Admin API.
    • Step 4: If remote access is absolutely necessary, use a VPN or bastion host to securely access the internal network where the Kong Admin API is available. This is about secure access to the network where Kong's Admin API is accessible.
    • Step 5: Regularly review and audit firewall rules and network policies related to Kong's Admin API access to ensure they remain restrictive and accurate.
  • List of Threats Mitigated:
    • Unauthorized Access to Kong Configuration via Admin API - Severity: High
    • Admin API Credential Brute-forcing - Severity: Medium
    • Remote Code Execution via Admin API Vulnerabilities - Severity: Critical (if vulnerabilities exist and are exploitable in Kong's Admin API)
  • Impact:
    • Unauthorized Access to Kong Configuration via Admin API: High risk reduction. Prevents unauthorized users from modifying Kong settings, routes, plugins, and potentially compromising the entire API gateway through Kong's Admin API.
    • Admin API Credential Brute-forcing: Medium risk reduction. Reduces the attack surface for brute-force attacks targeting Kong's Admin API by limiting network exposure.
    • Remote Code Execution via Admin API Vulnerabilities: High risk reduction. Limits the potential for exploiting vulnerabilities specifically in Kong's Admin API from the public internet.
  • Currently Implemented: Yes, Admin API is bound to internal network interface and firewall rules are in place specifically for Kong. Location: Kong configuration files and network infrastructure configuration related to Kong.
  • Missing Implementation: More granular network segmentation specifically for the Kong Admin API network is planned but not yet fully implemented.
  • Description:
    • Step 1: Enable the RBAC plugin within Kong. This might require Kong Enterprise or Kong Gateway OSS with RBAC plugin installed.
    • Step 2: Define roles within Kong that correspond to different levels of administrative access (e.g., admin, developer, read-only) for Kong management.
    • Step 3: Assign specific permissions within Kong RBAC to each role, granting only the necessary privileges for each role's responsibilities within Kong. For example, developer role might be allowed to manage routes and services but not modify global Kong settings.
    • Step 4: Create users within Kong RBAC and assign them to appropriate roles based on their job function related to Kong administration.
    • Step 5: Enforce RBAC for all Admin API access, ensuring that every request is authenticated and authorized against the user's assigned role and permissions within Kong RBAC.
    • Step 6: Regularly review and update roles and permissions in Kong RBAC as organizational needs and responsibilities change regarding Kong administration.
  • List of Threats Mitigated:
    • Privilege Escalation within Kong Admin API - Severity: High
    • Accidental Misconfiguration of Kong by Unauthorized Personnel - Severity: Medium
    • Insider Threats targeting Kong Configuration - Severity: Medium
  • Impact:
    • Privilege Escalation within Kong Admin API: High risk reduction. Prevents users from gaining unauthorized administrative privileges within Kong and performing actions beyond their intended scope in Kong management.
    • Accidental Misconfiguration of Kong by Unauthorized Personnel: Medium risk reduction. Reduces the likelihood of accidental errors in Kong configuration by limiting configuration access to authorized personnel within Kong RBAC.
    • Insider Threats targeting Kong Configuration: Medium risk reduction. Limits the potential damage from compromised or malicious internal users accessing Kong Admin API by enforcing least privilege within Kong RBAC.
  • Currently Implemented: Partial, RBAC plugin is enabled, and basic roles are defined in Kong. Location: Kong Admin API configuration and RBAC plugin configuration.
  • Missing Implementation: More granular permission definitions within Kong RBAC are needed, and integration with an external Identity Provider (IdP) for user management for Kong Admin API users is planned.

Mitigation Strategy: Secure Plugin Configurations

  • Description:
    • Step 1: Review the configuration of each enabled Kong plugin.
    • Step 2: Ensure plugins are configured with secure and recommended settings as per Kong and plugin documentation. For example:
      • For authentication plugins in Kong, use strong encryption algorithms and secure credential storage within Kong or integrated systems.
      • For rate limiting plugins in Kong, set appropriate limits to prevent abuse without impacting legitimate users of APIs managed by Kong.
      • For request transformer plugins in Kong, sanitize inputs and outputs to prevent injection vulnerabilities at the Kong gateway level.
    • Step 3: Avoid using default or insecure plugin configurations in Kong. Customize configurations to meet specific security requirements for Kong and the APIs it manages.
    • Step 4: Regularly audit plugin configurations in Kong to identify and rectify any misconfigurations or deviations from security best practices for Kong plugins.
    • Step 5: Document plugin configurations and security rationale for each setting within Kong plugin configurations.
  • List of Threats Mitigated:
    • Plugin-Specific Vulnerabilities due to Kong Plugin Misconfiguration - Severity: Medium to High (depending on the plugin and misconfiguration)
    • Bypass of Security Policies enforced by Kong Plugins due to Misconfiguration - Severity: Medium to High
    • Data Exposure due to Kong Plugin Misconfiguration - Severity: Medium to High
  • Impact:
    • Plugin-Specific Vulnerabilities due to Kong Plugin Misconfiguration: Medium to High risk reduction. Prevents exploitation of vulnerabilities arising from insecure plugin settings within Kong.
    • Bypass of Security Policies enforced by Kong Plugins due to Misconfiguration: Medium to High risk reduction. Ensures that security policies enforced by Kong plugins are effective and not easily bypassed due to misconfiguration.
    • Data Exposure due to Kong Plugin Misconfiguration: Medium to High risk reduction. Prevents unintended data leaks or exposure due to plugin settings within Kong.
  • Currently Implemented: Partial, Basic review of Kong plugin configurations has been done. Location: Kong plugin configurations in database or declarative configuration files.
  • Missing Implementation: Automated configuration checks against security best practices for Kong plugins and a more in-depth security audit of all Kong plugin configurations are needed.

Mitigation Strategy: Implement Rate Limiting

  • Description:
    • Step 1: Identify APIs and routes managed by Kong that are susceptible to abuse or denial-of-service attacks.
    • Step 2: Choose an appropriate Kong rate limiting plugin (e.g., rate-limiting-advanced, rate-limiting) based on requirements for granularity and features offered by Kong.
    • Step 3: Configure the rate limiting plugin in Kong for the identified routes or services. Define limits based on:
      • Requests per second, minute, hour, etc. within Kong's rate limiting plugin.
      • Consumer identifiers (API keys, OAuth tokens, etc.) managed by Kong or integrated systems.
      • IP addresses (with caution, as IP-based limiting can be bypassed) using Kong's rate limiting features.
    • Step 4: Set appropriate rate limiting policies within Kong. Start with conservative limits and adjust based on monitoring and traffic patterns through Kong.
    • Step 5: Implement appropriate error handling for rate limiting within Kong. Return informative error messages to clients when rate limits are exceeded by Kong.
    • Step 6: Monitor rate limiting effectiveness and adjust configurations as needed to optimize security and usability of Kong's rate limiting.
  • List of Threats Mitigated:
    • Denial of Service (DoS) Attacks against APIs managed by Kong - Severity: High
    • Brute-force Attacks against APIs managed by Kong - Severity: Medium
    • API Abuse and Resource Exhaustion of Upstream Services protected by Kong - Severity: Medium
  • Impact:
    • Denial of Service (DoS) Attacks against APIs managed by Kong: High risk reduction. Significantly reduces the impact of DoS attacks on APIs behind Kong by limiting the rate of requests at the Kong gateway.
    • Brute-force Attacks against APIs managed by Kong: Medium risk reduction. Makes brute-force attacks less effective against APIs behind Kong by slowing down the rate of attempts at the Kong gateway.
    • API Abuse and Resource Exhaustion of Upstream Services protected by Kong: Medium risk reduction. Prevents excessive API usage going through Kong that could lead to resource exhaustion and service degradation of upstream services.
  • Currently Implemented: Yes, Basic rate limiting is implemented on public-facing APIs using the rate-limiting-advanced plugin in Kong. Location: Kong route and service configurations.
  • Missing Implementation: More granular rate limiting policies based on consumer types and API tiers within Kong are planned. Dynamic and adaptive rate limiting strategies using Kong features are also under consideration.

Mitigation Strategy: Enforce HTTPS Everywhere

  • Description:
    • Step 1: Obtain SSL/TLS certificates for Kong's Admin API and Proxy ports.
    • Step 2: Configure Kong to listen for HTTPS on both Admin API and Proxy ports (ports 8444 and 443/other) within Kong's Nginx configuration.
    • Step 3: Configure Kong to redirect HTTP traffic to HTTPS for both Admin and Proxy ports. This can be done in nginx_http.conf within Kong's configuration or using Kong plugins.
    • Step 4: Ensure that upstream services also support HTTPS and configure Kong to communicate with upstream services over HTTPS in Kong's upstream service definitions.
    • Step 5: Enable HSTS (HTTP Strict Transport Security) in Kong using Kong's configuration or plugins to instruct browsers to always use HTTPS for connections to Kong.
    • Step 6: Regularly renew and manage SSL/TLS certificates used by Kong to prevent expiration.
  • List of Threats Mitigated:
    • Man-in-the-Middle (MITM) Attacks targeting traffic to/from Kong - Severity: High
    • Data Interception of traffic passing through Kong - Severity: High
    • Session Hijacking of sessions managed by Kong - Severity: Medium
    • Credential Sniffing of credentials passing through Kong - Severity: High
  • Impact:
    • Man-in-the-Middle (MITM) Attacks targeting traffic to/from Kong: High risk reduction. Encrypts communication channels to and from Kong, making it significantly harder for attackers to intercept and manipulate traffic at the Kong gateway.
    • Data Interception of traffic passing through Kong: High risk reduction. Protects sensitive data transmitted between clients, Kong, and upstream services from eavesdropping as it passes through Kong.
    • Session Hijacking of sessions managed by Kong: Medium risk reduction. Reduces the risk of session hijacking by encrypting session identifiers and cookies handled by Kong.
    • Credential Sniffing of credentials passing through Kong: High risk reduction. Prevents attackers from sniffing credentials transmitted over unencrypted HTTP connections going through Kong.
  • Currently Implemented: Yes, HTTPS is enforced for Proxy ports and Admin API in Kong. Location: Kong Nginx configuration and SSL certificate management.
  • Missing Implementation: HSTS is enabled but needs further configuration tuning for optimal security within Kong. mTLS between Kong and upstream services configured in Kong is planned but not yet implemented.