Skip to content

Latest commit

 

History

History
71 lines (52 loc) · 5.41 KB

mitigations.md

File metadata and controls

71 lines (52 loc) · 5.41 KB

Mitigation Strategies Analysis for wg/wrk

Mitigation Strategy: Rate Limiting in wrk

  • Description:

    1. Determine Target Request Rate: Analyze the application's expected capacity to determine a safe request rate for benchmarking.
    2. Utilize -r Flag: When executing wrk, use the -r <requests/sec> command-line option followed by the calculated request rate. Example: wrk -r 100 https://example.com. This limits requests per second.
    3. Test and Adjust Rate: Start with a low rate and gradually increase while monitoring application performance. Observe response times and errors.
    4. Document Rate Limits: Document chosen rates for different scenarios to ensure consistency and prevent overloading.

  • Threats Mitigated:

    • Denial of Service (DoS) (High Severity): Unintentionally overwhelming the application, causing service disruption.
    • Performance Degradation (Medium Severity): Causing slowdowns, impacting legitimate users.

  • Impact:

    • DoS: Significantly reduces risk by controlling load, preventing accidental overload.
    • Performance Degradation: Significantly reduces risk by keeping load manageable, minimizing negative performance impact.

  • Currently Implemented: Not consistently implemented as standard practice. May be used ad-hoc.

  • Missing Implementation:

    • Benchmarking Scripts: Integrate -r flag into standard scripts.
    • Developer Training: Educate developers on using -r for rate limiting.
    • CI/CD Pipelines: Configure rate limiting in automated benchmarking scripts in CI/CD.

Mitigation Strategy: Controlled Ramp-Up of Load using wrk Scripting

  • Description:

    1. Avoid Abrupt Load Spikes: Instead of immediate max load, gradually increase load to simulate realistic traffic.
    2. Lua Scripting for Ramp-Up: Utilize wrk's Lua scripting to create load profiles with ramp-up phases. Script can incrementally increase threads/connections over time.
    3. Step-Wise Manual Ramp-Up: Alternatively, manually run wrk multiple times, increasing threads/connections in steps, observing application response at each step.
    4. Monitor During Ramp-Up: Monitor application performance during ramp-up to identify instability as load increases.

  • Threats Mitigated:

    • Application Instability (Medium Severity): Causing crashes due to sudden load spikes the application can't handle gracefully.
    • Inaccurate Benchmark Results (Low Severity): Less realistic results if load pattern isn't real-world, misrepresenting performance.

  • Impact:

    • Application Instability: Reduces risk by allowing gradual application adaptation to load, minimizing sudden failures.
    • Inaccurate Benchmark Results: Improves accuracy by simulating realistic load, better understanding performance under typical usage.

  • Currently Implemented: Not consistently implemented. Manual ramp-up may occur, but not standardized.

  • Missing Implementation:

    • Standard Ramp-Up Scripts: Develop example Lua scripts for ramp-up scenarios.
    • Benchmarking Guidelines: Recommend ramp-up procedures in documentation.
    • Automated Ramp-Up in CI/CD: Incorporate ramp-up phases into automated scripts.

Mitigation Strategy: Resource Limits on wrk Execution using -t and -c

  • Description:

    1. Optimize -t and -c Values: Carefully choose threads (-t) and connections (-c). Avoid excessive values that overload the wrk client machine.
    2. Monitor Client Resources: Monitor CPU, memory, network on the wrk client during execution. If client is bottleneck, reduce -t and -c.
    3. Iterative Adjustment of -t and -c: Experiment to find optimal balance for load on target application without client exhaustion.
    4. Document Client Resource Limits: Document recommended -t and -c values for scenarios and client configurations to prevent exhaustion.

  • Threats Mitigated:

    • Benchmarking Client Resource Exhaustion (Medium Severity): Overloading the wrk client, causing performance issues or crashes on the client.
    • Inaccurate Benchmark Results (Low Severity): Inaccurate results if client becomes bottleneck, as it can't generate intended load.

  • Impact:

    • Benchmarking Client Resource Exhaustion: Significantly reduces risk by preventing client overload, ensuring stable benchmark execution.
    • Inaccurate Benchmark Results: Improves accuracy by ensuring client can generate intended load without bottleneck, providing realistic performance assessment.

  • Currently Implemented: Not consistently implemented. Developers may adjust -t and -c based on experience, but not formalized.

  • Missing Implementation:

    • Guidelines for -t and -c: Develop guidelines for choosing -t and -c based on client resources and application capacity.
    • Client Resource Monitoring Recommendations: Recommend monitoring client resources and adjusting -t and -c if needed.
    • Automated Client Resource Checks: Consider automated checks in scripts to detect client exhaustion and adjust -t and -c dynamically.