Skip to content

Latest commit

 

History

History
116 lines (95 loc) · 10.3 KB

threat-modeling.md

File metadata and controls

116 lines (95 loc) · 10.3 KB

Threat Model Analysis for valkey-io/valkey

Threat: Unauthenticated Access

  • Description: An attacker connects to a Valkey instance that has no authentication enabled (requirepass is not set). The attacker uses a standard Valkey client or a network scanning tool to discover the exposed instance. They then issue commands to read, write, or delete data.
    • Impact: Complete data compromise. The attacker can steal sensitive information (session data, cached credentials, API keys, etc.), modify application data, or delete all data, leading to application malfunction or data loss.
    • Valkey Component Affected: Core server configuration; authentication mechanism.
    • Risk Severity: Critical
    • Mitigation Strategies:
      • Configuration: Always set a strong, randomly generated password using the requirepass directive in valkey.conf.
      • Network Security: Restrict network access to the Valkey port (default 6379) using firewalls, allowing only trusted application servers to connect.

Threat: Weak Authentication

  • Description: An attacker attempts to brute-force the Valkey password using a dictionary attack or other password-guessing techniques. They repeatedly connect to the Valkey instance, trying different passwords until they find the correct one.
    • Impact: Complete data compromise, identical to unauthenticated access. The attacker gains full control over the data stored in Valkey.
    • Valkey Component Affected: Core server configuration; authentication mechanism.
    • Risk Severity: Critical
    • Mitigation Strategies:
      • Password Strength: Use a long (at least 20 characters), complex (mixed-case letters, numbers, symbols), and randomly generated password. Avoid dictionary words or easily guessable patterns.
      • Password Management: Use a password manager to generate and store the Valkey password securely.
      • Rate Limiting/Account Lockout: Implement rate limiting or account lockout with caution. While this can prevent brute-force attacks, it can also be abused by an attacker to lock out legitimate users. A more sophisticated approach that temporarily blocks IPs based on failed attempts is preferable.

Threat: Network Eavesdropping (No TLS)

  • Description: An attacker passively monitors network traffic between the application and the Valkey server. They use a network sniffer (e.g., Wireshark) to capture unencrypted data, including the authentication password (if sent in plain text) and any data being exchanged.
    • Impact: Complete data compromise. The attacker can intercept the authentication password and all data transmitted between the application and Valkey.
    • Valkey Component Affected: Network communication layer; client-server protocol.
    • Risk Severity: Critical
    • Mitigation Strategies:
      • TLS Encryption: Always enable TLS encryption for Valkey connections. Configure Valkey with valid TLS certificates and private keys.
      • Client Configuration: Ensure the application's Valkey client library is configured to use TLS and to verify the server's certificate.
      • Network Segmentation: Isolate the Valkey server and application servers on a separate, secure network segment to minimize the risk of eavesdropping.

Threat: Data Persistence Exposure (RDB/AOF without Encryption)

  • Description: An attacker gains access to the server's filesystem where Valkey's RDB snapshots or AOF files are stored. This could be through a separate vulnerability (e.g., OS-level compromise, misconfigured file sharing). The attacker then directly reads the data from these files, bypassing Valkey's authentication.
    • Impact: Data compromise. The attacker can access all data stored in Valkey, even if authentication is enabled.
    • Valkey Component Affected: Persistence mechanisms (RDB and AOF).
    • Risk Severity: High
    • Mitigation Strategies:
      • Disable Persistence (if possible): If data persistence is not required, disable both RDB and AOF in valkey.conf.
      • Filesystem Encryption: Use full-disk encryption (e.g., LUKS on Linux) to encrypt the entire filesystem where Valkey's data directory is located.
      • File Permissions: Ensure that the Valkey data directory and its contents have strict file permissions, allowing access only to the user running the Valkey process.
      • Regular Backups and Secure Storage: If using persistence, regularly back up the RDB/AOF files and store them securely in a separate, encrypted location.

Threat: CONFIG GET * Command Exposure

  • Description: An attacker connects to the Valkey instance and issues the CONFIG GET * command. This can expose sensitive configuration details, potentially including the requirepass password (if it was set via CONFIG SET).
    • Impact: Information leakage, potentially including the authentication password.
    • Valkey Component Affected: CONFIG command.
    • Risk Severity: High
    • Mitigation Strategies:
      • Rename Command: Rename the CONFIG command, or at least CONFIG GET *, using rename-command in valkey.conf.
      • ACLs (if supported): Use ACLs to restrict access to the CONFIG command.
      • Configuration Best Practices: Avoid setting the requirepass password using CONFIG SET. Set it directly in the valkey.conf file.

Threat: Resource Exhaustion (Memory) - Denial of Service

  • Description: An attacker sends a large number of requests to Valkey, inserting large keys and values, or a large number of small keys and values. This consumes all available memory on the Valkey server, causing it to crash or become unresponsive.
    • Impact: Application unavailability. The application relying on Valkey becomes unusable.
    • Valkey Component Affected: Memory management.
    • Risk Severity: High
    • Mitigation Strategies:
      • maxmemory Limit: Set a reasonable maxmemory limit in valkey.conf.
      • maxmemory-policy: Configure an appropriate maxmemory-policy (e.g., allkeys-lru, volatile-lru, allkeys-random) to evict keys when the memory limit is reached.
      • Application-Level Rate Limiting: Implement rate limiting on the application side to prevent excessive data insertion into Valkey.
      • Monitoring: Monitor Valkey's memory usage and set up alerts to detect potential memory exhaustion.

Threat: Resource Exhaustion (Connections) - Denial of Service

  • Description: An attacker opens a large number of connections to the Valkey server, exceeding the maxclients limit. This prevents legitimate clients from connecting.
    • Impact: Application unavailability.
    • Valkey Component Affected: Connection handling.
    • Risk Severity: High
    • Mitigation Strategies:
      • maxclients Limit: Set a reasonable maxclients limit in valkey.conf.
      • Connection Pooling: Use connection pooling on the application side to reuse existing connections and avoid exceeding the limit.
      • Firewall Rules: Use firewall rules to limit the number of connections from a single IP address.

Threat: Slow Commands - Denial of Service

  • Description: An attacker issues slow commands like KEYS *, FLUSHALL, or FLUSHDB (on large datasets). These commands can block the Valkey server, preventing it from processing other requests.
    • Impact: Application slowdown or unavailability.
    • Valkey Component Affected: Command processing; single-threaded nature of Valkey.
    • Risk Severity: High
    • Mitigation Strategies:
      • Avoid KEYS *: Use SCAN instead of KEYS * in production code.
      • Rename/Disable FLUSHALL/FLUSHDB: Use rename-command to rename or disable these commands.
      • Slowlog Monitoring: Monitor slow commands using Valkey's slowlog feature and investigate any unusually slow operations.
      • Asynchronous Operations: Use asynchronous operations in the application where possible to avoid blocking the main thread.

Threat: Unauthorized Data Modification

  • Description: An attacker gains unauthorized access to the Valkey instance (through any of the previously mentioned vulnerabilities) and issues commands to modify or delete data.
    • Impact: Data corruption, data loss, application malfunction.
    • Valkey Component Affected: All data storage components.
    • Risk Severity: High
    • Mitigation Strategies:
      • Strong Authentication: Implement strong authentication (as described above).
      • TLS Encryption: Use TLS encryption (as described above).
      • Data Validation: Implement data validation on the application side to ensure that only valid data is written to Valkey.
      • Auditing: Regularly audit Valkey's data for unauthorized changes.

Threat: Replication Issues (if used)

  • Description: If Valkey replication is used, an attacker compromises a replica instance. They then inject malicious data or commands that are replicated to the master instance.
    • Impact: Data corruption across the entire Valkey cluster.
    • Valkey Component Affected: Replication mechanism.
    • Risk Severity: High
    • Mitigation Strategies:
      • Secure Replicas: Secure all replica instances with the same level of security as the master (authentication, TLS).
      • Replication Monitoring: Monitor replication status and integrity.
      • Read-Only Replicas: Configure replicas as read-only to prevent accidental or malicious writes.
      • Network Isolation: Isolate replicas on a separate, secure network segment.