Skip to content

Latest commit

 

History

History
163 lines (146 loc) · 15 KB

mitigations.md

File metadata and controls

163 lines (146 loc) · 15 KB

Mitigation Strategies Analysis for cesanta/mongoose

Mitigation Strategy: Disable Unnecessary Features

  • Mitigation Strategy: Disable Unnecessary Features
  • Description:
    1. Review the mongoose.c configuration options or mongoose.conf file.
    2. Identify features that are not essential for the application's functionality. Examples include CGI, SSI, Lua scripting, MQTT, WebSockets, directory listing if not used.
    3. Use configuration options (e.g., commenting out lines in mongoose.conf or removing flags in command-line arguments) to disable these features. For example, remove -cgi_pattern, -ssi_pattern, -lua_script, -mqtt_enable, -websocket_timeout, and set -dir_list no.
    4. Restart the Mongoose server for changes to take effect.
    5. Test the application thoroughly to ensure disabling these features hasn't broken required functionality.
  • Threats Mitigated:
    • Increased Attack Surface (Severity: High) - By disabling features, you reduce the number of potential entry points for attackers.
    • Vulnerabilities in Unused Modules (Severity: Medium) - Unused features might contain vulnerabilities that could be exploited even if you don't intend to use them.
  • Impact:
    • Increased Attack Surface: High - Significantly reduces the attack surface by removing unnecessary code and functionality.
    • Vulnerabilities in Unused Modules: Medium - Reduces the risk of exploitation of vulnerabilities in modules you are not actively using.
  • Currently Implemented: Partially Implemented. Directory listing is disabled in production (-dir_list no in mongoose.conf).
  • Missing Implementation: CGI, SSI, Lua scripting, MQTT, and WebSocket features are still compiled in and potentially enabled by default. Need to explicitly disable them in mongoose.conf or compilation flags if not used.

Mitigation Strategy: Limit Listening Interfaces

  • Mitigation Strategy: Limit Listening Interfaces
  • Description:
    1. Determine the specific IP addresses or network interfaces that should be accessible to the Mongoose server.
    2. Use the -listening_ports configuration option in mongoose.conf or command-line arguments.
    3. Instead of using 0.0.0.0 (listen on all interfaces), specify the exact IP address or interface. For example, -listening_ports 127.0.0.1:8080 for local access only, or -listening_ports 192.168.1.100:80,443s for specific network interface.
    4. If listening on multiple ports, separate them with commas. Use 's' suffix for HTTPS ports (e.g., 443s).
    5. Restart the Mongoose server for changes to take effect.
    6. Verify the server is only listening on the intended interfaces using tools like netstat or ss.
  • Threats Mitigated:
    • Unnecessary Exposure (Severity: Medium) - Binding to all interfaces exposes the server to networks where it shouldn't be accessible, increasing the attack surface.
    • Internal Network Exposure (Severity: Medium) - If the server is intended for internal use, binding to external interfaces can expose internal services to the public internet.
  • Impact:
    • Unnecessary Exposure: Medium - Reduces exposure to unintended networks, limiting potential attack vectors.
    • Internal Network Exposure: Medium - Prevents accidental exposure of internal services to external networks.
  • Currently Implemented: Yes. In production, -listening_ports is set to the specific public IP address of the server.
  • Missing Implementation: For development environments, it's still using 0.0.0.0 for easier testing. Consider using 127.0.0.1 for development unless external access is specifically needed for testing.

Mitigation Strategy: Control Access with access_control_list

  • Mitigation Strategy: Control Access with access_control_list
  • Description:
    1. Identify the IP addresses or network ranges that should be allowed to access the application.
    2. Use the -access_control_list configuration option in mongoose.conf or command-line arguments.
    3. Specify allowed IP addresses or CIDR notation network ranges, separated by commas. For example, -access_control_list 192.168.1.0/24,10.0.0.10. Use -access_control_list -0.0.0.0/0 to deny all by default and then allow specific IPs.
    4. Restart the Mongoose server for changes to take effect.
    5. Test access from allowed and disallowed IP addresses to verify the ACL is working as expected.
  • Threats Mitigated:
    • Unauthorized Access (Severity: High) - Prevents unauthorized users from accessing the application from restricted networks or IP addresses.
    • Brute-Force Attacks (Severity: Medium) - Limiting access to known IP ranges can reduce the effectiveness of distributed brute-force attacks.
  • Impact:
    • Unauthorized Access: High - Provides a basic but effective layer of network-level access control.
    • Brute-Force Attacks: Medium - Makes brute-force attacks slightly harder by limiting the source IPs.
  • Currently Implemented: Partially Implemented. access_control_list is used in staging environments to restrict access to internal IPs only.
  • Missing Implementation: Not implemented in production yet. Should be implemented in production to restrict access to specific geographic regions or known user IP ranges if applicable to the application's access model.

Mitigation Strategy: Set Appropriate Resource Limits

  • Mitigation Strategy: Set Appropriate Resource Limits
  • Description:
    1. Analyze the application's expected resource usage (threads, open files, request rates).
    2. Use configuration options like -max_threads, -max_open_files, and -throttle in mongoose.conf or command-line arguments to set limits.
    3. Set -max_threads to a reasonable number based on server capacity and expected concurrency.
    4. Set -max_open_files to prevent file descriptor exhaustion.
    5. Use -throttle to limit request rates from specific IP addresses or user agents to prevent abuse. Example: -throttle "10.0.0.0/8=10,user-agent=badbot=1".
    6. Monitor server resource usage after setting limits to ensure they are effective and not hindering legitimate traffic.
  • Threats Mitigated:
    • Denial of Service (DoS) Attacks (Severity: High) - Resource limits prevent attackers from overwhelming the server with excessive requests or resource consumption.
    • Resource Exhaustion (Severity: Medium) - Prevents legitimate traffic from causing server instability due to resource exhaustion.
  • Impact:
    • Denial of Service (DoS) Attacks: High - Significantly reduces the impact of simple DoS attacks by limiting resource consumption.
    • Resource Exhaustion: Medium - Improves server stability and availability under heavy load.
  • Currently Implemented: Partially Implemented. -max_threads and -max_open_files are set to reasonable values in production.
  • Missing Implementation: -throttle is not currently implemented. Should be implemented, especially for public-facing endpoints, to mitigate potential abuse and DoS attempts.

Mitigation Strategy: Secure TLS/SSL Configuration

  • Mitigation Strategy: Secure TLS/SSL Configuration
  • Description:
    1. Ensure Mongoose is compiled with TLS/SSL support (using OpenSSL or mbedTLS).
    2. Obtain a valid SSL/TLS certificate from a trusted Certificate Authority (CA) or use Let's Encrypt.
    3. Configure Mongoose to use the certificate and private key using -ssl_cert and -ssl_key options in mongoose.conf or command-line arguments.
    4. Review the underlying TLS/SSL library (OpenSSL or mbedTLS) configuration to ensure strong cipher suites are enabled and weak or outdated ciphers are disabled. This might involve configuring OpenSSL's openssl.cnf or mbedTLS configuration.
    5. Consider enabling HSTS (HTTP Strict Transport Security) at the application level if appropriate, although Mongoose itself doesn't directly manage HSTS headers, you can set them in your application logic or through custom handlers.
    6. Regularly update the TLS/SSL library (OpenSSL or mbedTLS) to patch vulnerabilities.
    7. Test the TLS/SSL configuration using online tools (e.g., SSL Labs SSL Server Test) to verify its strength.
  • Threats Mitigated:
    • Man-in-the-Middle (MITM) Attacks (Severity: High) - TLS/SSL encryption prevents eavesdropping and tampering with communication between clients and the server.
    • Data Interception (Severity: High) - Encrypts sensitive data in transit, protecting confidentiality.
    • Session Hijacking (Severity: Medium) - HTTPS reduces the risk of session hijacking by encrypting session cookies.
  • Impact:
    • Man-in-the-Middle (MITM) Attacks: High - Provides strong protection against MITM attacks.
    • Data Interception: High - Ensures confidentiality of data transmitted over the network.
    • Session Hijacking: Medium - Reduces the risk of session hijacking, especially when combined with other session management security practices.
  • Currently Implemented: Yes. TLS/SSL is enabled in production with a valid certificate and key configured via -ssl_cert and -ssl_key.
  • Missing Implementation: HSTS is not currently implemented. Should be implemented in the application to enforce HTTPS and improve security posture. Cipher suite configuration needs to be reviewed and hardened to ensure only strong ciphers are used.

Mitigation Strategy: WebSocket Security (If Applicable)

  • Mitigation Strategy: WebSocket Security
  • Description:
    1. Implement authentication and authorization for WebSocket connections. Verify user identity before establishing a WebSocket connection.
    2. Validate and sanitize all data received through WebSocket messages. Treat WebSocket messages as untrusted input.
    3. Implement rate limiting for WebSocket messages to prevent abuse and DoS attacks.
    4. Use TLS/SSL encryption for WebSocket connections (WSS protocol) to protect data in transit.
    5. Regularly review and update WebSocket handling logic for security vulnerabilities.
  • Threats Mitigated:
    • Unauthorized Access (Severity: High) - Authentication and authorization prevent unauthorized users from using WebSocket functionality.
    • Injection Attacks (Severity: High) - Input validation and sanitization prevent injection attacks via WebSocket messages.
    • Denial of Service (DoS) (Severity: Medium) - Rate limiting prevents DoS attacks through excessive WebSocket messages.
    • Data Interception (Severity: High) - WSS encryption prevents eavesdropping on WebSocket communication.
  • Impact:
    • Unauthorized Access: High - Secures WebSocket functionality from unauthorized use.
    • Injection Attacks: High - Prevents injection vulnerabilities through WebSocket messages.
    • Denial of Service (DoS): Medium - Mitigates DoS attacks via WebSocket.
    • Data Interception: High - Ensures confidentiality of WebSocket communication.
  • Currently Implemented: Not Implemented. WebSocket functionality is not currently used in the project.
  • Missing Implementation: If WebSocket functionality is planned for future implementation, all of these security measures should be implemented from the start.

Mitigation Strategy: MQTT Security (If Applicable)

  • Mitigation Strategy: MQTT Security
  • Description:
    1. Implement authentication and authorization for MQTT clients. Use strong passwords or certificate-based authentication.
    2. Use TLS/SSL encryption for MQTT communication (MQTTS protocol) to protect sensitive data in transit.
    3. Follow MQTT security best practices for topic design and access control. Use granular topic-based authorization to restrict client access to specific topics.
    4. Regularly review and update MQTT configuration and access control policies.
  • Threats Mitigated:
    • Unauthorized Access (Severity: High) - Authentication and authorization prevent unauthorized MQTT clients from connecting and subscribing/publishing.
    • Data Interception (Severity: High) - MQTTS encryption prevents eavesdropping on MQTT communication.
    • Data Tampering (Severity: High) - MQTTS encryption protects data integrity during transmission.
    • Topic Hijacking (Severity: Medium) - Topic-based authorization prevents unauthorized clients from publishing to sensitive topics.
  • Impact:
    • Unauthorized Access: High - Secures MQTT functionality from unauthorized use.
    • Data Interception: High - Ensures confidentiality of MQTT communication.
    • Data Tampering: High - Protects the integrity of MQTT data.
    • Topic Hijacking: Medium - Prevents unauthorized publishing to sensitive MQTT topics.
  • Currently Implemented: Not Implemented. MQTT functionality is not currently used in the project.
  • Missing Implementation: If MQTT functionality is planned for future implementation, all of these security measures should be implemented from the start.

Mitigation Strategy: CGI/SSI Specific Security

  • Mitigation Strategy: CGI/SSI Specific Security
  • Description:
    1. If you must use CGI:
      • Run CGI scripts with the least privilege necessary. Consider using a dedicated user account for CGI execution.
      • Carefully audit and secure CGI scripts for vulnerabilities, especially command injection.
      • Disable any unnecessary system commands or functionalities within CGI scripts.
    2. If you must use SSI:
      • Strictly control who can modify SSI files.
      • Sanitize all data included in SSI directives to prevent XSS.
  • Threats Mitigated:
    • Command Injection (CGI) (Severity: High) - Improperly secured CGI scripts can allow attackers to execute arbitrary commands on the server.
    • Cross-Site Scripting (XSS) (SSI) (Severity: High) - Unsanitized data in SSI directives can lead to XSS vulnerabilities.
    • Privilege Escalation (CGI) (Severity: Medium) - If CGI scripts are not run with least privilege, vulnerabilities can lead to privilege escalation.
  • Impact:
    • Command Injection (CGI): High - Can lead to complete server compromise.
    • Cross-Site Scripting (XSS) (SSI): High - Can lead to user account compromise and website defacement.
    • Privilege Escalation (CGI): Medium - Can allow attackers to gain higher privileges on the server.
  • Currently Implemented: Not Applicable. CGI and SSI are not currently used in the project.
  • Missing Implementation: If CGI or SSI functionality is considered for future use, these security measures must be implemented. Ideally, avoid using CGI and SSI due to their inherent security risks and consider modern alternatives.