How to remediate – SLP Server Detection (TCP)

1. Introduction

The SLP Server Detection (TCP) vulnerability means a server on your network is responding to Service Location Protocol requests. SLP helps applications find services, but it can expose information about your network and potentially allow attackers to map your infrastructure. This affects servers running any service that supports SLP, often found in older Windows environments or specific networking devices. A successful exploit could lead to information disclosure on the network.

2. Technical Explanation

• Root cause: The SLP service is enabled and listening for incoming connections without sufficient restrictions.
• Exploit mechanism: An attacker sends an SLP request to the server, receives a list of services, then uses this information for further attacks like targeted exploitation or network mapping. For example, sending a SLPLocate request could reveal service names and IP addresses.
• Scope: Windows servers with SLP enabled are commonly affected. Some networking devices may also run SLP.

3. Detection and Assessment

You can confirm if a system is vulnerable by checking for open SLP ports or running a network scan. A quick check involves using netstat to see if the server is listening on TCP ports 610-612.

• Quick checks: Run netstat -an | findstr ":61" in a command prompt. If you see entries listening on port 610, 611 or 612, SLP is enabled.
• Scanning: Nessus plugin ID 93857 can detect SLP services. OpenVAS also has relevant checks. These are examples only and may require updates.
• Logs and evidence: Windows Event Logs do not typically record SLP activity directly. Network traffic captures will show SLP packets on ports 610-612.

netstat -an | findstr ":61"

4. Solution / Remediation Steps

To fix this issue, limit incoming traffic to the SLP port or disable the service if it’s not needed. These steps are best performed during a scheduled maintenance window.

4.1 Preparation

• Dependencies: Ensure no critical applications rely on SLP for service discovery. Roll back by restoring the snapshot or re-enabling the service.
• Change window: A standard change window is recommended, with approval from the IT manager.

4.2 Implementation

1. Step 1: Open Windows Firewall with Advanced Security.
2. Step 2: Create a new inbound rule to block TCP ports 610, 611 and 612.
3. Step 3: Select “Port” as the rule type and specify the port numbers (610, 611, 612).
4. Step 4: Choose “Block the connection”.
5. Step 5: Apply the rule to all profiles (Domain, Private, Public).
6. Step 6: Give the rule a descriptive name like “Block SLP Traffic”.

4.3 Config or Code Example

Before

netstat -an | findstr ":61"  (shows SLP ports listening)

After

netstat -an | findstr ":61" (should show no SLP ports listening)

4.4 Security Practices Relevant to This Vulnerability

Several security practices can help prevent this issue. Least privilege is important, as limiting the services running on a server reduces the attack surface. Network segmentation also helps contain potential breaches if SLP is exploited.

• Practice 1: Least privilege – only run essential services and disable unnecessary ones like SLP.
• Practice 2: Network segmentation – isolate critical systems to limit the impact of a compromised service.

4.5 Automation (Optional)

You can use PowerShell to block SLP ports using Windows Firewall rules at scale.

New-NetFirewallRule -DisplayName "Block SLP Traffic" -Direction Inbound -Action Block -Protocol TCP -LocalPort 610,611,612 -Profile Domain,Private,Public

5. Verification / Validation

Confirm the fix by checking that SLP ports are no longer listening and re-running your initial detection method. A simple smoke test involves verifying other network services still function correctly.

• Post-fix check: Run netstat -an | findstr ":61". The output should be empty, indicating no SLP ports are open.
• Re-test: Re-run the initial scan (Nessus or OpenVAS) to confirm it no longer detects SLP services.
• Smoke test: Verify DNS resolution and basic network connectivity still work as expected.
• Monitoring: Monitor firewall logs for blocked connections on ports 610-612 as an example of a regression indicator.

netstat -an | findstr ":61" (should show no output)

6. Preventive Measures and Monitoring

Update your security baselines to include blocking SLP ports by default. Consider adding checks in your CI/CD pipeline to prevent the service from being enabled during deployment, for example using a Group Policy or configuration management tool.

• Baselines: Update your CIS benchmark or internal security policy to explicitly block SLP traffic on all systems.
• Pipelines: Add a check in your CI/CD pipeline to ensure SLP is not enabled during server provisioning or deployment.
• Asset and patch process: Review system configurations regularly to identify and disable unnecessary services like SLP. A quarterly review cycle is sensible.

7. Risks, Side Effects, and Roll Back

• Risk or side effect 1: Blocking SLP could break legacy applications – verify compatibility first.
• Roll back:
  1. Step 1: Open Windows Firewall with Advanced Security.
  2. Step 2: Delete the “Block SLP Traffic” rule you created earlier.

8. References and Resources

Refer to the IETF RFC for detailed information about the SLP protocol.

• Vendor advisory or bulletin: Not applicable, this is a configuration issue.
• NVD or CVE entry: Not applicable, this is a configuration issue.
• Product or platform documentation relevant to the fix: http://www.ietf.org/rfc/rfc2608.txt