How to remediate – sslh Detection

1. Introduction

sslh Detection identifies instances where a multiplexing service is running on a port. sslh allows both SSH and SSL connections on the same port, often used to bypass firewall restrictions for internal access. This can create an unexpected attack surface if not managed correctly. A successful exploit could lead to confidentiality, integrity, or availability compromise of systems behind the firewall.

2. Technical Explanation

The vulnerability arises from running the sslh daemon, which listens on a port and forwards connections based on protocol detection. An attacker can connect to this port expecting either SSH or SSL, potentially gaining access to services they shouldn’t be able to reach directly. There is no specific CVE associated with simply *running* sslh; the risk depends on its configuration and intended use. A realistic example would involve an attacker connecting to port 443, bypassing firewall rules designed for HTTPS traffic, and then attempting SSH authentication if sslh is configured to forward SSH connections.

• Root cause: The presence of a multiplexing service accepting multiple connection types on the same port.
• Exploit mechanism: An attacker connects to the exposed port (e.g., 443) and attempts to establish an SSH or SSL connection, exploiting potential misconfigurations or weak authentication.
• Scope: Systems running sslh on Linux distributions are affected. Specific versions aren’t directly vulnerable; the risk is configuration-dependent.

3. Detection and Assessment

Confirming whether a system runs sslh can be done with network scanning or by checking listening ports. A thorough method involves examining process lists and configurations.

• Quick checks: Use `netstat -tulnp | grep sslh` to check for the sslh process listening on a port.
• Scanning: Nessus plugin ID 16384 can detect running sslh instances, but results should be manually verified.
• Logs and evidence: Check system logs (e.g., `/var/log/syslog` or `/var/log/auth.log`) for messages related to sslh startup or connection attempts.

netstat -tulnp | grep sslh

4. Solution / Remediation Steps

Fixing this issue involves ensuring the use of sslh aligns with security policies, and if not needed, removing it.

4.1 Preparation

• Dependencies: Ensure no critical applications rely on the multiplexing functionality provided by sslh. A roll back plan involves restoring the backed-up configuration files and restarting affected services.
• Change window needs: Coordinate with relevant teams to minimise disruption, especially for production systems.

4.2 Implementation

1. Step 1: If sslh is not required, uninstall it using your distribution’s package manager (e.g., `apt remove sslh` or `yum remove sslh`).
2. Step 2: If sslh is needed, review its configuration file (`/etc/sslh/sslh.conf`) to ensure secure settings and appropriate access controls.

4.3 Config or Code Example

Before

# /etc/sslh/sslh.conf
listen 443
users nobody
# No authentication configured

After

# /etc/sslh/sslh.conf
# Disable sslh if not required
# listen 443
# users nobody
# Authentication enabled (example)
# password /etc/sslh/passwords

4.4 Security Practices Relevant to This Vulnerability

Several security practices can mitigate the risks associated with sslh. Least privilege reduces impact, while input validation prevents malicious data from being processed. Safe defaults and a regular patch cadence help maintain system security.

• Practice 1: Least privilege limits the potential damage if sslh is compromised.
• Practice 2: Input validation can prevent attacks targeting vulnerabilities in underlying services exposed through sslh.

4.5 Automation (Optional)

If using configuration management, you can automate the removal or disabling of sslh.

# Ansible example - remove sslh package
- name: Remove sslh package
  package:
    name: sslh
    state: absent

5. Verification / Validation

Confirm the fix by checking that sslh is no longer running and that relevant ports are closed. A smoke test verifies essential services remain functional.

• Post-fix check: Run `netstat -tulnp | grep sslh` – there should be no output.
• Re-test: Re-run the initial detection method (e.g., Nessus scan) to confirm the vulnerability is resolved.
• Smoke test: Verify that HTTPS traffic continues to function as expected if port 443 was used by sslh.
• Monitoring: Monitor system logs for unexpected connection attempts on ports previously handled by sslh.

netstat -tulnp | grep sslh

6. Preventive Measures and Monitoring

Update security baselines to include checks for unnecessary services like sslh. Implement CI/CD pipeline scans to identify misconfigurations during deployment. A regular patch or config review cycle helps maintain system security.

• Baselines: Update your security baseline to disallow running unapproved multiplexing services on standard ports.
• Pipelines: Add checks in your CI/CD pipeline to scan for the presence of sslh and flag any unexpected installations or configurations.
• Asset and patch process: Review system configurations regularly (e.g., quarterly) to identify and address potential security issues like running unnecessary services.

7. Risks, Side Effects, and Roll Back

• Roll back: Restore the backed-up configuration files and restart affected services to revert to the previous state.

8. References and Resources

• Vendor advisory or bulletin: http://www.rutschle.net/tech/sslh.shtml