Skip to content

Latest commit

 

History

History
157 lines (120 loc) · 8.6 KB

mitigations.md

File metadata and controls

157 lines (120 loc) · 8.6 KB

Mitigation Strategies Analysis for influxdata/influxdb

Mitigation Strategy: Enforce Strong Authentication (Within InfluxDB)

Description: 1. Enable Authentication: In the InfluxDB configuration file (influxdb.conf or environment variables), set auth-enabled = true. Restart InfluxDB. 2. Create Admin User: Immediately after enabling, create an admin user with a strong, unique password via the influx CLI or HTTP API: bash influx CREATE USER admin WITH PASSWORD 'your-very-strong-password' WITH ALL PRIVILEGES 3. Create Non-Admin Users: Create additional users with specific roles and permissions. 4. Password Management (Limited within InfluxDB): InfluxDB itself has limited built-in password policy features. You can set passwords, but complex policies (length, complexity, rotation, lockout) are typically handled externally (at the application or network layer). Focus on strong, unique passwords within InfluxDB.

  • Threats Mitigated:

    • Unauthorized Data Access (Severity: Critical): Prevents access without valid credentials.
    • Unauthorized Data Modification (Severity: Critical): Prevents unauthorized changes.
    • Privilege Escalation (Severity: High): Reduces risk of gaining admin privileges.
    • Brute-Force Attacks (Severity: High): Strong passwords make these harder.
    • Credential Stuffing (Severity: High): Unique passwords prevent reuse of stolen credentials.

  • Impact:

    • Unauthorized Access/Modification: Risk reduced from Critical to Low (with strong passwords and RBAC).
    • Privilege Escalation: Risk reduced from High to Low.
    • Brute-Force/Credential Stuffing: Risk reduced from High to Low.

  • Currently Implemented:

    • Authentication enabled in influxdb.conf.
    • Admin user with a strong password created.
    • Basic user accounts for read/write access created.

  • Missing Implementation:

    • No direct InfluxDB configuration for advanced password policies (handled externally).

Mitigation Strategy: Fine-Grained Authorization (RBAC within InfluxDB)

Description: 1. Identify Roles: Define roles based on needed access (e.g., "read-only-sensor-data"). 2. InfluxDB 2.x (Buckets & Tokens): Create separate buckets for data categories. Generate tokens with specific read/write permissions for those buckets. This is the primary authorization mechanism in 2.x. 3. InfluxDB 1.x (GRANT/REVOKE): Use CREATE USER and GRANT commands: sql GRANT READ ON "mydb" TO "readonlyuser" GRANT WRITE ON "mydb" TO "writeonlyuser" 4. Assign Roles: Assign appropriate roles/tokens to users. 5. Regular Review: Periodically review roles and permissions within InfluxDB.

  • Threats Mitigated:

    • Unauthorized Data Access (Severity: Critical): Limits access to authorized data.
    • Unauthorized Data Modification (Severity: Critical): Prevents unauthorized changes.
    • Privilege Escalation (Severity: High): Makes escalation harder.
    • Data Breaches (Severity: High): Reduces the scope of potential breaches.

  • Impact:

    • Unauthorized Access/Modification: Risk reduced from Critical to Low.
    • Privilege Escalation: Risk reduced from High to Medium.
    • Data Breaches: Breach impact significantly reduced.

  • Currently Implemented:

    • Basic roles (read-only, write-only) implemented.

  • Missing Implementation:

    • Granular roles for different data types/measurements are not defined.
    • Regular, documented review of roles is not performed.

Mitigation Strategy: Query Timeouts (InfluxDB Configuration)

Description: 1. Configure Timeouts: In the influxdb.conf file, set appropriate query timeouts. Relevant settings (may vary slightly by version): * query-timeout: Sets a maximum duration for a query to run. Example: query-timeout = "30s" (30 seconds). * log-queries-after: Logs queries that take longer than a specified duration. Example: log-queries-after = "10s". This helps identify slow queries. 2. Restart InfluxDB: Restart the service for changes to take effect.

  • Threats Mitigated:

    • Denial of Service (DoS) (Severity: Medium): Prevents long-running queries from consuming excessive resources.
    • Resource Exhaustion (Severity: Medium): Limits resource consumption by runaway queries.

  • Impact:

    • DoS/Resource Exhaustion: Risk reduced from Medium to Low.

  • Currently Implemented:

    • A default query-timeout is set in the configuration.

  • Missing Implementation:

    • The log-queries-after setting is not configured, making it harder to identify slow queries proactively.
    • The timeout value may not be optimal and should be reviewed based on typical query patterns.

Mitigation Strategy: Resource Limits (InfluxDB Configuration)

Description: 1. Configure Limits: In influxdb.conf, set limits on resources InfluxDB can use. Key settings: * max-concurrent-queries: Limits the number of queries running simultaneously. * max-select-point: Limits number of points. * max-select-series: Limits number of series. * max-select-buckets: Limits number of buckets. 2. Restart InfluxDB: Restart for changes to take effect.

  • Threats Mitigated:

    • Denial of Service (DoS) (Severity: High): Prevents resource exhaustion.
    • Resource Exhaustion (Severity: Medium): Limits overall resource consumption.

  • Impact:

    • DoS/Resource Exhaustion: Risk reduced from High/Medium to Low.

  • Currently Implemented:

    • Some default limits are set.

  • Missing Implementation:

    • Limits are not comprehensively tuned based on the specific hardware and expected workload. They should be reviewed and adjusted.

Mitigation Strategy: Encryption in Transit (HTTPS within InfluxDB)

Description: 1. Obtain TLS Certificate: Get a valid certificate (e.g., Let's Encrypt). 2. Configure InfluxDB: In influxdb.conf: * https-enabled = true * https-certificate = "/path/to/certificate.pem" * https-private-key = "/path/to/private-key.pem" 3. Restart InfluxDB. 4. Enforce HTTPS (Ideally done externally, but mentioned for completeness): While best practice is to enforce this at a reverse proxy, InfluxDB can be configured to only listen on the HTTPS port. This is less robust than a reverse proxy solution.

  • Threats Mitigated:

    • Man-in-the-Middle (MitM) Attacks (Severity: High): Prevents interception/modification of data.
    • Eavesdropping (Severity: High): Prevents data theft in transit.
    • Data Breaches (Severity: High): Reduces breach risk.

  • Impact:

    • MitM/Eavesdropping/Data Breaches: Risk reduced from High to Low.

  • Currently Implemented:

    • InfluxDB configured for HTTPS with a Let's Encrypt certificate.

  • Missing Implementation:

    • Strict HTTPS enforcement is handled by the external Nginx proxy, not within InfluxDB's configuration itself.

Mitigation Strategy: Enable Detailed Logging (InfluxDB Configuration)

Description: 1. Configure Logging: In influxdb.conf, adjust logging settings: * log-level: Set to debug or info for more detailed logs. warn or error are less verbose. * Ensure logs are written to a persistent location. 2. Restart InfluxDB.

  • Threats Mitigated:

    • Undetected Intrusions (Severity: High): Provides data for investigation.
    • Insider Threats (Severity: Medium): Can help identify malicious actions.
    • Data Breaches (Severity: High): Aids in post-breach analysis.

  • Impact:

    • Improves detection and investigation capabilities.

  • Currently Implemented:

    • Basic logging is enabled.

  • Missing Implementation:

    • log-level is not set to a sufficiently detailed level (debug or info). Log analysis is handled externally.