Skip to content

Latest commit

 

History

History
133 lines (123 loc) · 14.7 KB

mitigations.md

File metadata and controls

133 lines (123 loc) · 14.7 KB

Mitigation Strategies Analysis for apache/zookeeper

Mitigation Strategy: Enable ZooKeeper Authentication (SASL)

  • Mitigation Strategy: Enable ZooKeeper Authentication (SASL)
  • Description:
    1. Choose a SASL Mechanism: Select between DIGEST-MD5 (simpler) or Kerberos (more robust, enterprise-grade). For demonstration, we'll use DIGEST-MD5.
    2. Generate Credentials: Create usernames and passwords for ZooKeeper clients and servers. Use strong, unique passwords.
    3. Configure ZooKeeper Server:
      • Edit the zoo.cfg file for each ZooKeeper server.
      • Add the following lines to enable SASL authentication: 
        authProvider.1=org.apache.zookeeper.server.auth.SASLAuthenticationProvider
requireClientAuthScheme=sasl
      • Optionally, set a superuser for administrative tasks using a system property (use with caution): 
        -Dzookeeper.DigestAuthenticationProvider.superUser.username=password
        Replace username and password with your chosen credentials.
      • Restart all ZooKeeper servers in the cluster for the changes to take effect.
    4. Configure ZooKeeper Clients:
      • When establishing a connection from your application code using a ZooKeeper client library, provide authentication credentials. For example, in Java: 
        ZooKeeper zk = new ZooKeeper("localhost:2181", 3000, watcher);
zk.addAuthInfo("digest", "username:password".getBytes());
        Replace "username:password" with the actual username and password.
    5. Verification: Test the setup by attempting to connect to ZooKeeper both with and without valid credentials to confirm that authentication is enforced correctly.
  • Threats Mitigated:
    • Unauthorized Access (High Severity): Prevents unauthorized clients from connecting to the ZooKeeper ensemble and performing operations.
    • Data Manipulation by Unauthorized Parties (High Severity): Reduces the risk of malicious actors altering or deleting critical application data stored in ZooKeeper.
    • Denial of Service (DoS) via Connection Flooding (Medium Severity): Limits the ability of unauthenticated attackers to overwhelm ZooKeeper with connection requests.
  • Impact:
    • Unauthorized Access: High Reduction - Authentication is the primary defense against unauthorized entry.
    • Data Manipulation by Unauthorized Parties: High Reduction - Significantly restricts who can interact with ZooKeeper data.
    • Denial of Service (DoS) via Connection Flooding: Medium Reduction - Mitigates simple connection-based DoS attacks.
  • Currently Implemented: [Specify if SASL authentication is currently enabled in your ZooKeeper deployment and which mechanism is used (e.g., "Yes, DIGEST-MD5 is enabled in production and staging environments."). If not, state "No, SASL authentication is not currently enabled."]
  • Missing Implementation: [If not fully implemented, describe where it's missing (e.g., "SASL authentication is enabled in production but not yet in development environments.", "Kerberos authentication is planned but not yet implemented, DIGEST-MD5 is currently used."). If fully implemented, state "N/A".]

Mitigation Strategy: Implement Fine-Grained Access Control Lists (ACLs)

  • Mitigation Strategy: Implement Fine-Grained Access Control Lists (ACLs)
  • Description:
    1. Identify Access Control Needs: Determine which users, applications, or services require access to specific znodes and the necessary permissions (read, write, create, delete, admin).
    2. Define ACL Rules: For each znode or znode path, define ACL rules that grant the minimum required permissions. Utilize ZooKeeper's ACL schemes (e.g., sasl, auth, ip, world). Focus on sasl for authenticated users.
    3. Apply ACLs during Znode Creation: When creating znodes programmatically or via the ZooKeeper CLI, explicitly set the desired ACLs. Example using ZooKeeper CLI: 
      create /sensitive_data "confidential" sasl:user_app1:r,sasl:admin_user:cdrwa
      This command creates /sensitive_data with read permission for user_app1 and create, delete, read, write, admin permissions for admin_user (both authenticated via SASL).
    4. Update ACLs as Requirements Change: Modify ACLs using the setAcl command in the ZooKeeper CLI or the corresponding API in your client library when access needs evolve.
    5. Regular ACL Audit: Periodically review and audit existing ACL configurations to ensure they remain appropriate and adhere to the principle of least privilege. Identify and rectify any overly permissive ACLs.
  • Threats Mitigated:
    • Privilege Escalation within ZooKeeper (High Severity): Prevents users or applications with legitimate access from gaining unauthorized access to other parts of the ZooKeeper data tree.
    • Data Integrity Compromise due to Unauthorized Modification (High Severity): Reduces the risk of accidental or malicious data corruption or deletion by restricting write and delete access.
    • Confidentiality Breach of Specific Data (Medium Severity): Limits access to sensitive information stored in specific znodes to only authorized entities.
  • Impact:
    • Privilege Escalation within ZooKeeper: High Reduction - ACLs are the core mechanism for enforcing least privilege within ZooKeeper.
    • Data Integrity Compromise due to Unauthorized Modification: High Reduction - Directly controls who can modify or delete data, protecting integrity.
    • Confidentiality Breach of Specific Data: Medium Reduction - Provides granular control over data access, enhancing confidentiality for specific data points.
  • Currently Implemented: [Describe the current state of ACL implementation (e.g., "ACLs are implemented for all critical znodes in production, using SASL scheme.", "Basic ACLs are in place, but fine-grained control is still being rolled out."). If not implemented, state "No, ACLs are not currently implemented beyond default permissions."]
  • Missing Implementation: [If not fully implemented, specify areas needing improvement (e.g., "ACLs need to be implemented for non-critical znodes as well.", "More granular ACLs based on application roles are required.", "Automated ACL management and auditing are missing."). If fully implemented, state "N/A".]

Mitigation Strategy: Enable TLS Encryption for Client and Server Communication in ZooKeeper

  • Mitigation Strategy: Enable TLS Encryption for Client and Server Communication in ZooKeeper
  • Description:
    1. Generate TLS Certificates and Keystores/Truststores: Obtain or generate TLS certificates for each ZooKeeper server and client. Use a trusted Certificate Authority (CA) for production or self-signed certificates for development/testing. Create Java Keystores (.jks) containing server certificates and private keys, and Truststores containing trusted CA certificates (or server certificates for self-signed).
    2. Configure ZooKeeper Server for TLS:
      • Edit the zoo.cfg file for each ZooKeeper server.
      • Add or modify the following properties to enable TLS: 
        serverCnxnFactory=org.apache.zookeeper.server.NIOServerCnxnFactory
secureClientPort=2281 # Choose a dedicated secure port (e.g., 2281)
ssl.keyStore.location=/path/to/server-keystore.jks # Path to server keystore
ssl.keyStore.password=server_keystore_password # Password for server keystore
ssl.trustStore.location=/path/to/server-truststore.jks # Path to server truststore
ssl.trustStore.password=server_truststore_password # Password for server truststore
ssl.client.cnCheck=true # Enable hostname verification (recommended for production)
        Replace placeholders with actual paths and passwords. Adjust ssl.client.cnCheck based on your certificate setup.
      • Restart all ZooKeeper servers in the cluster.
    3. Configure ZooKeeper Clients for TLS:
      • When creating ZooKeeper client connections in your application, enable TLS and provide necessary TLS configuration. For example, in Java, set system properties before creating the ZooKeeper object: 
        System.setProperty("zookeeper.ssl.keyStore.location", "/path/to/client-keystore.jks"); // Path to client keystore
System.setProperty("zookeeper.ssl.keyStore.password", "client_keystore_password"); // Password for client keystore
System.setProperty("zookeeper.ssl.trustStore.location", "/path/to/client-truststore.jks"); // Path to client truststore
System.setProperty("zookeeper.ssl.trustStore.password", "client_truststore_password"); // Password for client truststore
System.setProperty("zookeeper.ssl.hostnameVerification", "true"); // Enable hostname verification (recommended for production)

ZooKeeper zk = new ZooKeeper("localhost:2281", 3000, watcher); // Connect to the secure port
        Replace placeholders with actual paths and passwords. Ensure the client connects to the secureClientPort defined on the server.
    4. Verification: Test client connections to the secure port to confirm TLS encryption is active. Use network monitoring tools to verify encrypted traffic.
  • Threats Mitigated:
    • Eavesdropping of ZooKeeper Communication (High Severity): Prevents attackers from intercepting and reading sensitive data exchanged between clients and ZooKeeper servers.
    • Man-in-the-Middle (MitM) Attacks on ZooKeeper Connections (High Severity): Protects against attackers intercepting and manipulating communication, potentially leading to data breaches or service disruption.
    • Data Tampering during Transmission (Medium Severity): Ensures the integrity of data in transit by preventing unauthorized modifications.
  • Impact:
    • Eavesdropping of ZooKeeper Communication: High Reduction - TLS encryption makes it extremely difficult to passively intercept and decrypt communication.
    • Man-in-the-Middle (MitM) Attacks on ZooKeeper Connections: High Reduction - TLS provides strong encryption and authentication, making MitM attacks significantly harder.
    • Data Tampering during Transmission: Medium Reduction - TLS includes mechanisms to detect data tampering during transmission, ensuring data integrity.
  • Currently Implemented: [Describe the current TLS implementation status (e.g., "TLS is enabled for client-server communication in production and staging.", "TLS is enabled for inter-server communication but not client-server.", "TLS is planned but not yet implemented."). If not implemented, state "No, TLS encryption is not currently enabled for ZooKeeper communication."]
  • Missing Implementation: [If not fully implemented, specify areas needing improvement (e.g., "TLS needs to be enabled for inter-server communication as well.", "Client-side hostname verification needs to be enforced.", "Automated certificate management for ZooKeeper TLS is missing."). If fully implemented, state "N/A".]

Mitigation Strategy: Implement ZooKeeper Quotas

  • Mitigation Strategy: Implement ZooKeeper Quotas
  • Description:
    1. Determine Quota Requirements: Analyze application usage patterns and resource capacity to determine appropriate quota limits for znodes and data size. Consider different quotas for different application namespaces or client groups if necessary.
    2. Set Znode Quotas: Use the setquota command in the ZooKeeper CLI or the setQuota API in client libraries to enforce znode quotas. Example using ZooKeeper CLI: 
      setquota -n 5000 /app_namespace
      This command sets a znode quota of 5000 for the path /app_namespace. Clients will be unable to create more than 5000 znodes directly under or within this path.
    3. Set Data Quotas: Use the setquota command with the -b option to enforce data quotas (in bytes). Example using ZooKeeper CLI: 
      setquota -b 10485760 /app_namespace # 10MB quota
      This command sets a data quota of 10MB for the path /app_namespace. Clients will be unable to store more than 10MB of data in total under or within this path.
    4. Monitor Quota Usage: Implement monitoring to track quota usage for different paths. Set up alerts to notify administrators when quota limits are approaching or exceeded. ZooKeeper JMX metrics can be used for monitoring.
    5. Enforce Quota Policies in Applications: In your application code, handle potential QuotaExceededException exceptions that may be thrown when attempting to create znodes or store data beyond quota limits. Implement appropriate error handling and logging.
  • Threats Mitigated:
    • Resource Exhaustion Denial of Service (DoS) (Medium Severity): Prevents malicious or misconfigured clients from consuming excessive ZooKeeper resources (znodes, memory, disk space), leading to service degradation or outage for other applications or clients.
    • "Runaway" Application Bugs Leading to Resource Exhaustion (Low Severity): Protects against unintentional resource exhaustion caused by application errors or unexpected behavior that might lead to excessive znode creation or data storage.
  • Impact:
    • Resource Exhaustion Denial of Service (DoS): Medium Reduction - Quotas provide a mechanism to limit resource consumption, mitigating resource-based DoS attacks.
    • "Runaway" Application Bugs Leading to Resource Exhaustion: Low Reduction - Acts as a safeguard against unintentional resource exhaustion, limiting the impact of certain application-level issues.
  • Currently Implemented: [Describe the current status of quota implementation (e.g., "Znode quotas are implemented for all application namespaces in production.", "Data quotas are not yet implemented.", "Quotas are in place in production but not consistently enforced in development."). If not implemented, state "No quotas are currently implemented in ZooKeeper."]
  • Missing Implementation: [If not fully implemented, specify areas needing improvement (e.g., "Data quotas need to be implemented in addition to znode quotas.", "More granular quotas based on client roles or application criticality are needed.", "Automated quota management and alerting are missing."). If fully implemented, state "N/A".]