Skip to content

Latest commit

 

History

History
108 lines (77 loc) · 7.14 KB

File metadata and controls

108 lines (77 loc) · 7.14 KB

Mitigation Strategies Analysis for inconshreveable/ngrok

  1. Choose Authentication Method: Decide between --basic-auth (username/password) or --oauth (using a provider like Google or GitHub). --oauth is generally preferred.
  2. Basic Auth: If using --basic-auth, generate a strong, unique password. Use a password manager. Command: ngrok http --basic-auth="username:very_strong_password" 8080.
  3. OAuth: If using --oauth, select a supported provider. Configure the OAuth provider correctly, obtaining client ID and secret from the provider's developer console. Command: ngrok http --oauth=google --oauth-allow-domain=yourdomain.com 8080 (adjust parameters). Ensure minimum necessary permissions.
  4. Authtoken: Always use an authtoken. Obtain it from the ngrok dashboard: ngrok config add-authtoken YOUR_AUTHTOKEN.
  5. Regular Rotation: Rotate the basic-auth password or OAuth client secret regularly (e.g., every few months). For --oauth, revoke and regenerate the client secret.
  6. Documentation: Document the method, credentials (securely!), and rotation schedule.
  • Threats Mitigated:

    • Unauthorized Access (Severity: Critical): Prevents access without credentials.
    • Brute-Force Attacks (Severity: High): Strong passwords/OAuth make brute-forcing difficult.
    • Credential Stuffing (Severity: High): Unique passwords prevent reuse of stolen credentials.
    • Session Hijacking (Severity: High): Adds a layer of protection (though HTTPS is primary).
  • Impact:

    • Unauthorized Access: Risk reduced from Critical to Low.
    • Brute-Force Attacks: Risk reduced from High to Low.
    • Credential Stuffing: Risk reduced from High to Low.
    • Session Hijacking: Risk reduced.
  • Currently Implemented: Partially. --authtoken is configured. --basic-auth is used with a moderately strong password in start_dev.sh.

  • Missing Implementation: Password rotation is not implemented. --oauth is not used. Documentation is incomplete.

Mitigation Strategy: Minimize Tunnel Lifetime

  1. Start on Demand: Only start the tunnel when absolutely necessary.
  2. Stop Immediately: Shut down the tunnel immediately after use.
  3. Scripting: Use scripts to automate starting and stopping (e.g., start_dev.sh, stop_dev.sh).
  4. Time Limits: Consider automatic shutdown after a period (e.g., 2 hours) using scripts or external tools.
  5. Monitoring: Periodically check for unnecessarily running tunnels.
  • Threats Mitigated:

    • Opportunistic Attacks (Severity: Medium): Reduces the window for attackers to find the service.
    • Persistent Threats (Severity: High): Makes establishing persistence harder.
    • Resource Exhaustion (Severity: Low): Reduces ngrok resource consumption.
  • Impact:

    • Opportunistic Attacks: Risk reduced from Medium to Low.
    • Persistent Threats: Risk reduced.
    • Resource Exhaustion: Risk reduced.
  • Currently Implemented: start_dev.sh starts the tunnel, but no stop_dev.sh exists. Manual stopping is instructed, but not enforced.

  • Missing Implementation: Dedicated stop script missing. Automatic time limits not implemented. Monitoring not formalized.

Mitigation Strategy: Expose Only Necessary Ports

  1. Identify Required Port: Determine the exact port the application listens on (e.g., 8080).
  2. Specific Command: Use ngrok http with the specific port: ngrok http 8080. Do not use ngrok http without a port.
  3. Verification: After starting, verify only the intended port is exposed (using netstat or ss).
  • Threats Mitigated:

    • Unintended Service Exposure (Severity: Medium): Prevents exposing other services.
    • Port Scanning (Severity: Low): Makes discovering other services harder.
  • Impact:

    • Unintended Service Exposure: Risk reduced from Medium to Low.
    • Port Scanning: Risk slightly reduced.
  • Currently Implemented: start_dev.sh correctly specifies the port (8080).

  • Missing Implementation: Verification after tunnel start is not automated.

Mitigation Strategy: Never Use ngrok for Production

  1. Development/Testing Only: ngrok is strictly for development, testing, and demos.
  2. Production Deployment: Use proper methods (cloud platforms, dedicated servers, Kubernetes, etc.).
  3. Policy Enforcement: Enforce a policy prohibiting ngrok in production.
  4. Alternative Solutions: Provide alternatives for sharing work (staging environments, etc.).
  • Threats Mitigated:

    • All Production-Related Risks (Severity: Critical): ngrok is unsuitable for production security, reliability, and scalability.
  • Impact:

    • All Production-Related Risks: Risk eliminated.
  • Currently Implemented: Understood in principle, but no formal policy exists.

  • Missing Implementation: Written policy needed. Guidelines on production deployment alternatives needed.

  1. Reserved Domains/TCP Addresses: If using a paid plan, reserve a domain or TCP address for a stable endpoint. Command example (domain): ngrok http --domain=your-reserved-domain.ngrok.io 8080.
  2. Connection Limits: Set limits on simultaneous connections to mitigate DoS attacks. This is configured through the ngrok dashboard or API.
  3. IP Whitelisting/Restrictions: Restrict access to the tunnel based on IP address. Configure through the ngrok dashboard or API.
  4. Webhooks: Use webhooks to receive real-time notifications about tunnel events (connections, disconnections, errors). This allows for proactive monitoring and response.
  5. ngrok Dashboard Monitoring: Regularly check the dashboard for unusual activity.
  • Threats Mitigated:

    • DoS Attacks (Severity: Medium): Connection limits help mitigate.

    • Unauthorized Access (Severity: High): IP whitelisting restricts access.

    • Tunnel Discovery (Severity: Low): Reserved domains make guessing the tunnel URL harder (but rely on obscurity, not security).

    • Lack of Visibility (Severity: Medium): Webhooks and dashboard provide monitoring capabilities.

    • Impact:

      • DoS Attacks: Risk reduced (depending on limit configuration).
      • Unauthorized Access: Risk significantly reduced (with proper IP whitelisting).
      • Tunnel Discovery: Risk slightly reduced.
      • Lack of Visibility: Improved monitoring and alerting.
  • Currently Implemented: Not applicable (currently using the free tier).

  • Missing Implementation: All paid features are not utilized. If a paid plan is adopted, these features should be evaluated and implemented as appropriate.