Skip to content

Latest commit

 

History

History
100 lines (71 loc) · 6.83 KB

mitigations.md

File metadata and controls

100 lines (71 loc) · 6.83 KB

Mitigation Strategies Analysis for apache/incubator-brpc

Mitigation Strategy: Robust Authentication (bRPC Authenticator)

  • Mitigation Strategy: Implement Strong Authentication using bRPC's Authenticator Interface.

  • Description:

    1. Create an Authenticator Implementation: Create a new class that implements the brpc::Authenticator interface. This interface has a single method, VerifyCredential, which takes the authentication string, client address, and an AuthContext as input.
    2. Implement VerifyCredential: Within the VerifyCredential method:
      • Receive authentication data from the incoming request (typically in the authentication field of the request metadata).
      • Validate the credentials against your chosen authentication system (OAuth 2.0/OIDC, mTLS, custom token). This part is not bRPC-specific, but the interface is.
      • Populate AuthContext (if successful) with information about the authenticated user.
      • Return 0 for success, a non-zero error code for failure.
    3. Register the Authenticator: In your bRPC server setup, register your Authenticator implementation using Server::AddService or Server::AddProtobufService, passing an instance of your authenticator.
    4. Client-Side Authentication: On the client-side, include the authentication data in the request metadata using Controller::set_authentication.

  • Threats Mitigated:

    • Unauthorized Access (Severity: Critical): Prevents attackers from accessing services without valid credentials.
    • Spoofing (Severity: High): Makes it difficult to impersonate legitimate users/services.
    • Man-in-the-Middle (MitM) Attacks (Severity: High): When combined with TLS (which bRPC supports), prevents interception.

  • Impact:

    • Unauthorized Access: Risk significantly reduced (near elimination with proper implementation).
    • Spoofing: Risk significantly reduced.
    • MitM Attacks: Risk significantly reduced (when used with TLS).

  • Currently Implemented: Describe where the Authenticator is implemented and registered (e.g., "Authenticator in auth/MyAuthenticator.cpp, registered in server/main.cpp").

  • Missing Implementation: Describe where authentication is missing or incomplete (e.g., "Authenticator not registered for all services").

Mitigation Strategy: Connection and Request Limits (max_concurrency)

  • Mitigation Strategy: Configure bRPC's max_concurrency setting.

  • Description:

    1. Locate Server Configuration: Find where your bRPC Server is being configured (likely in your server's main function or initialization code).
    2. Set max_concurrency: Use the ServerOptions::max_concurrency member to set the maximum number of concurrent requests the server will handle. Choose a value appropriate for your server's resources and expected load. Start conservatively and adjust based on monitoring. Example: options.max_concurrency = 100;

  • Threats Mitigated:

    • Denial of Service (DoS) (Severity: High): Prevents attackers from overwhelming the server with connections.
    • Resource Exhaustion (Severity: High): Prevents the server from running out of resources.

  • Impact:

    • DoS: Risk significantly reduced.
    • Resource Exhaustion: Risk significantly reduced.

  • Currently Implemented: Describe where max_concurrency is set (e.g., "Set in server/main.cpp").

  • Missing Implementation: State if max_concurrency is not set or is set to an unreasonably high value.

Mitigation Strategy: Timeout Management (timeout_ms)

  • Mitigation Strategy: Set Appropriate Timeouts using Controller::set_timeout_ms.

  • Description:

    1. Client-Side Implementation: Before making a bRPC call, use the Controller::set_timeout_ms method to set a timeout (in milliseconds) for the request. This is done on the client side.
    2. Choose Appropriate Timeout: Select a timeout value that is reasonable for the expected response time of the service, plus some buffer for network latency.
    3. Example:
    brpc::Controller cntl;
cntl.set_timeout_ms(5000); // 5-second timeout
MyService_Stub stub(&channel);
stub.MyMethod(&cntl, &request, &response, nullptr);

  • Threats Mitigated:

    • Denial of Service (DoS) (Severity: Medium): Prevents slow clients from tying up resources.
    • Resource Exhaustion (Severity: Medium): Prevents long-running requests from consuming resources.
    • Deadlocks (Severity: Medium): Helps to prevent deadlocks.

  • Impact:

    • DoS: Risk reduced.
    • Resource Exhaustion: Risk reduced.
    • Deadlocks: Risk reduced.

  • Currently Implemented: Describe where timeout_ms is set (e.g., "Set in client code for each RPC call").

  • Missing Implementation: Describe where timeouts are missing (e.g., "No timeouts set for Service B").

Mitigation Strategy: Disable Debugging Endpoints (bvar, /status)

  • Mitigation Strategy: Disable or Restrict Access to bRPC's Debugging Endpoints (/status, bvar).

  • Description:

    1. Identify Build Configuration: Determine how bRPC is being built. Often, debugging features are enabled or disabled through build flags (e.g., CMake options, compiler defines).
    2. Disable Debugging Features: Modify the build configuration to disable the compilation of the debugging endpoints (/status, bvar) for production builds. This is the most secure option. The exact method depends on your build system.
    3. (Less Preferred) Restrict Access: If disabling is absolutely not possible, use network-level controls (firewalls, reverse proxies, outside of bRPC) and bRPC's Authenticator (if possible, though this might be tricky for these built-in endpoints) to strictly limit access. This is a fallback approach, and disabling is strongly preferred.

  • Threats Mitigated:

    • Information Disclosure (Severity: High): Prevents attackers from accessing sensitive server information.
    • Reconnaissance (Severity: Medium): Makes it harder for attackers to gather information.

  • Impact:

    • Information Disclosure: Risk significantly reduced.
    • Reconnaissance: Risk reduced.

  • Currently Implemented: Describe how debugging endpoints are handled (e.g., "Disabled via CMake build flags in production builds").

  • Missing Implementation: Describe where debugging features are still exposed (e.g., "/status endpoint accessible").