Skip to content

Latest commit

 

History

History
153 lines (136 loc) · 19.6 KB

mitigations.md

File metadata and controls

153 lines (136 loc) · 19.6 KB

Mitigation Strategies Analysis for ossrs/srs

Mitigation Strategy: Input Validation and Sanitization for Stream Names and Paths (SRS Context)

Mitigation Strategy: SRS Stream Name and Path Validation

  • Description:
    1. Utilize SRS's Lua Plugin for Custom Validation (Advanced): If SRS's built-in validation is insufficient, develop a Lua plugin for SRS to implement custom validation logic for stream names and paths. This plugin can intercept stream creation requests and enforce stricter validation rules.
    2. Configure SRS to Reject Invalid Names (Basic): While SRS might not have granular validation configuration, ensure that your application logic interacting with SRS generates stream names and paths that adhere to a defined safe format. Document these format requirements for developers.
    3. Sanitize Input in Application Layer Before SRS: Implement input sanitization in the application layer before passing stream names and paths to SRS for publishing or playback. This ensures that only validated and sanitized names reach SRS.
  • List of Threats Mitigated:
    • Path Traversal (High Severity): Attackers could potentially access or manipulate files outside of the intended stream directory by crafting malicious stream paths passed to SRS.
    • Command Injection (Medium Severity): If stream names or paths are used in system commands by SRS (less likely directly by SRS core, more likely in custom extensions), attackers might inject malicious commands.
    • Denial of Service (DoS) (Medium Severity): Malformed stream names could potentially cause errors or crashes in SRS processing logic.
  • Impact:
    • Path Traversal: High risk reduction. Effectively prevents path traversal attacks related to stream names processed by SRS.
    • Command Injection: Medium risk reduction. Reduces the attack surface for command injection via stream names handled by SRS.
    • Denial of Service (DoS): Medium risk reduction. Prevents DoS caused by trivially malformed stream names processed by SRS.
  • Currently Implemented: Unknown. Needs to be checked if any custom Lua plugins for validation are in place or if application layer sanitization is implemented before interacting with SRS.
  • Missing Implementation: Likely missing if relying solely on default SRS behavior without explicit validation either in a Lua plugin or in the application layer before SRS interaction.

Mitigation Strategy: Control Command Validation for HTTP APIs (SRS Context)

Mitigation Strategy: SRS HTTP API Input Validation

  • Description:
    1. Review SRS API Documentation: Thoroughly review the SRS HTTP API documentation to understand the expected input parameters, data types, and formats for each API endpoint.
    2. Implement Validation in API Clients: In your application code that interacts with SRS HTTP APIs, implement validation logic to ensure that all API requests sent to SRS conform to the documented specifications.
    3. Utilize SRS Authentication for API Access: Secure SRS HTTP APIs with strong authentication (see dedicated mitigation strategy below) to limit access to authorized users and reduce the risk of malicious API requests.
    4. Monitor SRS API Logs: Monitor SRS API access logs for any unusual or suspicious API requests that might indicate attempted exploitation or misuse.
  • List of Threats Mitigated:
    • Command Injection (High Severity): Attackers could inject malicious commands through API parameters if SRS API handlers are vulnerable and input is not validated.
    • Server Misconfiguration (Medium Severity): Invalid API input could potentially lead to unintended SRS server misconfigurations if validation is lacking in API clients or SRS itself.
    • Denial of Service (DoS) (Medium Severity): Malformed API requests could cause errors or resource exhaustion in SRS, leading to DoS.
  • Impact:
    • Command Injection: High risk reduction. Effectively prevents command injection through SRS API parameters if client-side validation is robust and SRS API is secure.
    • Server Misconfiguration: Medium risk reduction. Reduces the risk of misconfiguration via SRS API, relying on client-side validation and secure API access.
    • Denial of Service (DoS): Medium risk reduction. Mitigates DoS from malformed SRS API requests through client-side validation and monitoring.
  • Currently Implemented: Partially implemented. Relies on the security of SRS's API implementation itself. Client-side validation in applications using SRS APIs might be missing or incomplete.
  • Missing Implementation: Likely missing robust client-side validation in applications that interact with SRS HTTP APIs. Focus on implementing validation in API clients and monitoring SRS API logs.

Mitigation Strategy: Strong Authentication for Publishing (SRS Configuration)

Mitigation Strategy: SRS Publisher Authentication

  • Description:
    1. Enable SRS Authentication: Configure SRS to enforce authentication for publishers. Choose an appropriate authentication method supported by SRS, such as:
      • HTTP Callback Authentication: Configure SRS to use an HTTP callback URL to authenticate publishers against an external authentication service.
      • Authentication Plugins: Utilize or develop SRS authentication plugins for custom authentication mechanisms.
    2. Configure Authentication Settings in SRS: Properly configure the chosen authentication method within SRS configuration files (e.g., srs.conf). This includes setting callback URLs, plugin paths, and any necessary authentication parameters.
    3. Test Authentication Configuration: Thoroughly test the configured authentication mechanism to ensure it is working as expected and effectively prevents unauthorized publishing.
    4. Regularly Review Authentication Configuration: Periodically review the SRS authentication configuration to ensure it remains secure and aligned with security policies.
  • List of Threats Mitigated:
    • Unauthorized Stream Injection (High Severity): Prevents unauthorized users from publishing malicious or inappropriate content to SRS streams.
    • Stream Hijacking (High Severity): Prevents attackers from taking over legitimate streams published to SRS.
    • Reputation Damage (Medium Severity): Unauthorized content injection via SRS can damage your application's reputation.
  • Impact:
    • Unauthorized Stream Injection: High risk reduction. Effectively prevents unauthorized publishing to SRS if authentication is correctly configured and enforced by SRS.
    • Stream Hijacking: High risk reduction. Significantly reduces the risk of stream hijacking within SRS.
    • Reputation Damage: Medium risk reduction. Protects against reputation damage from unauthorized content published through SRS.
  • Currently Implemented: Unknown. Needs to be checked in SRS configuration files (srs.conf) for authentication-related settings within vhost configurations.
  • Missing Implementation: Potentially missing if default SRS configurations are used without enabling any authentication for publishing, leaving publishing endpoints open to unauthorized access.

Mitigation Strategy: Authorization for Publishing and Subscribing (SRS Configuration)

Mitigation Strategy: SRS Stream-Level Authorization

  • Description:
    1. Define Authorization Policies in SRS: Configure SRS to enforce authorization policies that control access to specific streams or stream patterns. Utilize SRS authorization features like:
      • HTTP Callback Authorization: Configure SRS to use an HTTP callback URL to authorize publisher and subscriber access based on stream names and user roles.
      • Authorization Plugins: Utilize or develop SRS authorization plugins for custom authorization logic.
    2. Configure Authorization Settings in SRS: Properly configure the chosen authorization method within SRS configuration files (srs.conf). This includes setting callback URLs, plugin paths, and defining authorization rules.
    3. Test Authorization Configuration: Thoroughly test the configured authorization mechanism to ensure it is working as expected and effectively controls access to streams based on defined policies.
    4. Regularly Review Authorization Policies: Periodically review and update SRS authorization policies to reflect changes in access requirements and security policies.
  • List of Threats Mitigated:
    • Unauthorized Access to Sensitive Streams (High Severity): Prevents unauthorized users from accessing confidential or restricted content streams managed by SRS.
    • Data Leaks (High Severity): Unauthorized access to SRS streams could lead to leaks of sensitive information contained within the media content.
    • Compliance Violations (Medium Severity): Lack of proper authorization in SRS can lead to violations of data privacy regulations.
  • Impact:
    • Unauthorized Access to Sensitive Streams: High risk reduction. Effectively prevents unauthorized access to SRS streams based on defined policies configured in SRS.
    • Data Leaks: High risk reduction. Significantly reduces the risk of data leaks through unauthorized access to SRS streams.
    • Compliance Violations: Medium risk reduction. Helps in achieving compliance by controlling access to sensitive data within SRS streams.
  • Currently Implemented: Unknown. Needs to be checked in SRS configuration files (srs.conf) for authorization-related settings within vhost configurations.
  • Missing Implementation: Likely missing if default SRS configurations are used without enabling any stream-level authorization, making all streams potentially accessible to anyone.

Mitigation Strategy: Minimize Exposed Ports (SRS Configuration)

Mitigation Strategy: SRS Port Minimization

  • Description:
    1. Identify Required SRS Ports: Determine the specific ports required for the streaming protocols you are actively using with SRS (e.g., RTMP, HTTP-FLV, HLS, WebRTC). Consult SRS documentation for default port assignments.
    2. Disable Unnecessary SRS Listeners: In the SRS configuration file (srs.conf), disable listeners for protocols and ports that are not required for your application. For example, if you only use HLS, disable RTMP and HTTP-FLV listeners by commenting out or removing their respective listen directives.
    3. Verify SRS Port Configuration: Double-check the SRS configuration to ensure only the necessary ports are configured to listen for connections.
    4. Document Required SRS Ports: Document the minimal set of ports required for SRS operation in your application's deployment documentation.
  • List of Threats Mitigated:
    • Broad Attack Surface (Medium Severity): Reducing exposed SRS ports minimizes potential entry points for attackers targeting vulnerabilities in SRS or related services listening on those ports.
    • Unnecessary Service Exposure (Medium Severity): Disabling unused SRS protocols and ports prevents attackers from targeting services within SRS that are not actually needed.
  • Impact:
    • Broad Attack Surface: Medium risk reduction. Reduces the attack surface of the SRS instance by limiting exposed ports.
    • Unnecessary Service Exposure: Medium risk reduction. Prevents exploitation of vulnerabilities in unused SRS services.
  • Currently Implemented: Partially implemented. Default SRS configuration might expose more ports than necessary. Explicit port minimization in SRS configuration might be missing.
  • Missing Implementation: Likely missing if relying on default SRS port configurations without explicitly disabling unnecessary listeners in srs.conf.

Mitigation Strategy: Disable Unnecessary Protocols and Features (SRS Configuration)

Mitigation Strategy: SRS Feature and Protocol Minimization

  • Description:
    1. Identify Required SRS Features and Protocols: Determine the essential SRS features and streaming protocols needed for your application's core functionality.
    2. Disable Unnecessary SRS Protocols: In the SRS configuration file (srs.conf), disable listeners for streaming protocols that are not being used. For example, if you don't use RTMP, disable the RTMP listener.
    3. Disable Unnecessary SRS Modules (If Applicable): If SRS utilizes modules for optional features, disable any modules that are not required for your application. Consult SRS documentation for module configuration.
    4. Review SRS Configuration for Unused Features: Review the entire SRS configuration file (srs.conf) and comment out or remove any configuration sections related to features that are not actively used.
    5. Document Enabled SRS Features and Protocols: Document the minimal set of SRS features and protocols enabled for your application's deployment.
  • List of Threats Mitigated:
    • Vulnerability Exposure in Unused Features (Medium Severity): Disabling unused SRS features reduces the risk of vulnerabilities in those features being exploited, even if they are not directly used by your application.
    • Complexity and Maintenance Overhead (Low Severity): Minimizing enabled SRS features simplifies the configuration and reduces potential maintenance overhead.
  • Impact:
    • Vulnerability Exposure in Unused Features: Medium risk reduction. Reduces the attack surface of SRS by disabling potentially vulnerable, unused code within SRS.
    • Complexity and Maintenance Overhead: Low risk reduction. Simplifies SRS configuration and maintenance.
  • Currently Implemented: Unknown. Needs to be checked in SRS configuration files (srs.conf) for enabled protocols and features. Default SRS configuration might have many features enabled.
  • Missing Implementation: Likely missing if relying on default SRS configurations without explicitly disabling unnecessary protocols and features in srs.conf.

Mitigation Strategy: Rate Limiting and Connection Limits (SRS Configuration)

Mitigation Strategy: SRS Connection and Rate Limiting

  • Description:
    1. Configure Connection Limits in SRS: In the SRS configuration file (srs.conf), set appropriate limits for the maximum number of concurrent connections. Configure both global connection limits and per-IP address connection limits to prevent abuse from single sources. Use configuration directives like max_connections and potentially per-vhost connection limits.
    2. Configure Rate Limiting in SRS: Implement rate limiting within SRS configuration to control the rate at which publishers can send data and potentially subscribers can receive data. Use SRS rate limiting features like in_bytes_limit and out_bytes_limit within vhost configurations.
    3. Tune Limits Based on Expected Traffic: Carefully tune connection and rate limits based on your application's expected traffic patterns and server capacity. Avoid setting limits too low, which could impact legitimate users.
    4. Monitor SRS Metrics for Limit Breaches: Monitor SRS metrics related to connection counts and traffic rates to detect potential DoS attacks or situations where configured limits are being reached.
  • List of Threats Mitigated:
    • Denial of Service (DoS) Attacks (High Severity): SRS connection and rate limiting can effectively mitigate many types of DoS attacks that aim to overwhelm the SRS server.
    • Resource Exhaustion (Medium Severity): Prevents resource exhaustion on the SRS server due to excessive connections or traffic, ensuring stability.
  • Impact:
    • Denial of Service (DoS) Attacks: High risk reduction. Significantly reduces the impact of many DoS attacks targeting SRS.
    • Resource Exhaustion: Medium risk reduction. Prevents resource exhaustion on the SRS server and improves stability under load.
  • Currently Implemented: Partially implemented. SRS might have default connection limits. However, explicit and tuned rate limiting and connection limits in srs.conf might be missing or not optimally configured.
  • Missing Implementation: Likely missing if relying on default SRS configurations without explicitly configuring and tuning connection limits and rate limiting in srs.conf to match application needs and server capacity.

Mitigation Strategy: TLS/HTTPS Encryption (SRS Configuration)

Mitigation Strategy: SRS TLS/HTTPS Configuration

  • Description:
    1. Obtain TLS Certificates for SRS: Obtain valid TLS/SSL certificates for your SRS server's domain or IP address.
    2. Configure TLS for HTTPS in SRS: In the SRS configuration file (srs.conf), configure TLS certificates for HTTPS listeners. Specify the paths to your SSL certificate (ssl_cert) and private key (ssl_key) files within the http_api and http_server sections of your vhost configuration. Enable HTTPS by setting the https_port directive.
    3. Configure TLS for RTMPS in SRS (If Used): If you use RTMPS, configure TLS certificates for secure RTMP connections in the rtmp section of your vhost configuration, similar to HTTPS configuration.
    4. Enforce HTTPS for Web Interfaces and APIs: Ensure that all web interfaces and API access to SRS are served over HTTPS by configuring SRS and any reverse proxies or load balancers accordingly.
    5. Regularly Renew TLS Certificates: Implement a process for regularly renewing TLS certificates before they expire to maintain continuous encryption for SRS.
  • List of Threats Mitigated:
    • Data in Transit Interception (High Severity): SRS TLS/HTTPS encryption prevents eavesdropping on network traffic and intercepting sensitive data transmitted to and from SRS over HTTP-based protocols.
    • Man-in-the-Middle (MitM) Attacks (High Severity): Encryption protects against MitM attacks targeting communication with SRS over HTTP.
    • Credential Theft (Medium Severity): Encrypting communication channels with SRS protects credentials transmitted during authentication processes over HTTP.
  • Impact:
    • Data in Transit Interception: High risk reduction. Effectively prevents eavesdropping on HTTP-based communication with SRS.
    • Man-in-the-Middle (MitM) Attacks: High risk reduction. Prevents MitM attacks targeting HTTP communication with SRS.
    • Credential Theft: Medium risk reduction. Protects credentials transmitted over HTTP to SRS.
  • Currently Implemented: Partially implemented. HTTPS might be enabled for some SRS components, but TLS might not be fully configured for all relevant HTTP-based protocols or RTMPS if used. Self-signed certificates might be in use.
  • Missing Implementation: Likely missing if TLS/HTTPS is not enabled for all HTTP-based protocols and RTMPS in SRS configuration, or if valid certificates from trusted CAs are not used in production SRS deployments. Focus on complete TLS/HTTPS configuration in srs.conf and proper certificate management.