1. Home
  2. Network Vulnerabilities
  3. How to remediate – SLP Server Detection (UDP)
Searching...

How to remediate – SLP Server Detection (UDP)

Contents

1. Introduction

The SLP Server Detection (UDP) 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 gather details about running systems. This affects servers running SLP implementations, often found in older Windows versions or specific networking devices. A successful exploit could lead to information disclosure.

2. Technical Explanation

The server understands the Service Location Protocol (SLP), which operates over UDP. An attacker can send crafted requests to query service details from the server. This allows them to map network services without authentication. There is no known CVE associated with simply running SLP, but it’s considered a risk due to its potential for reconnaissance. For example, an attacker could discover internal hostnames and application versions.

  • Root cause: The server listens for UDP requests on the SLP port (typically 67/UDP) without requiring authentication or authorization.
  • Exploit mechanism: An attacker sends a crafted SLP request to enumerate services running on the network, potentially revealing sensitive information about internal systems and applications.
  • Scope: Windows operating systems with enabled SLP service are affected. Networking devices supporting SLP may also be vulnerable.

3. Detection and Assessment

You can confirm if a system is running SLP by checking for the listening port or using network scanning tools. A quick check involves examining open ports, while thorough assessment requires analysing network traffic.

  • Quick checks: Use netstat -an | findstr ":67" on Windows to see if anything is listening on UDP port 67.
  • Scanning: Nessus plugin ID 10384 can detect SLP services. OpenVAS also has relevant scans, but results may vary.
  • Logs and evidence: Windows Event Logs do not typically record SLP activity directly. Network traffic analysis using Wireshark or similar tools is the most reliable method.
netstat -an | findstr ":67"

4. Solution / Remediation Steps

The best way to fix this issue is to disable the SLP service if it’s not required, or restrict incoming traffic to the port. These steps are small and can be rolled back easily.

4.1 Preparation

  • Change window: A standard change window is recommended, with approval from the IT manager.

4.2 Implementation

  1. Step 1: Stop the ‘Service Location Protocol’ service using net stop "Service Location Protocol".
  2. Step 2: Disable the service to prevent automatic restart using sc config "Service Location Protocol" start= disabled.
  3. Step 3: If disabling is not possible, restrict incoming traffic on UDP port 67 using your firewall.

4.3 Config or Code Example

Before

sc query "Service Location Protocol"

After

sc query "Service Location Protocol"  (should show 'SERVICE_DISABLED')

4.4 Security Practices Relevant to This Vulnerability

Several security practices can help prevent this issue. Least privilege reduces the impact of exploitation, while network segmentation limits exposure.

  • Practice 1: Apply least privilege principles to services. Only run necessary services with minimal permissions.
  • Practice 2: Network segmentation isolates vulnerable systems and prevents lateral movement by attackers.

4.5 Automation (Optional)

# PowerShell example to disable SLP service on remote machines
$computers = @("computer1", "computer2") # Replace with your computer names
foreach ($computer in $computers) {
  Invoke-Command -ComputerName $computer -ScriptBlock {
    Stop-Service -Name "ServiceLocationProtocol" -Force
    Set-Service -Name "ServiceLocationProtocol" -StartupType Disabled
  }
}

5. Verification / Validation

Confirm the fix by checking that the SLP service is stopped and no longer listening on UDP port 67. A negative test involves attempting to query the server using an SLP client tool.

  • Post-fix check: Run netstat -an | findstr ":67" again; it should return no results.
  • Re-test: Re-run the initial scan (Nessus plugin ID 10384) to verify that SLP is no longer detected.
  • Monitoring: Monitor firewall logs for blocked traffic on UDP port 67 as an indicator of attempted SLP queries.
netstat -an | findstr ":67" (should return no results)

6. Preventive Measures and Monitoring

Update security baselines to include disabling unnecessary services like SLP. Implement regular vulnerability scanning during the build process to catch similar issues early.

  • Baselines: Update your Windows security baseline or Group Policy Object (GPO) to disable the SLP service by default.
  • Asset and patch process: Review running services regularly as part of a standard asset management process.

7. Risks, Side Effects, and Roll Back

  • Risk or side effect 2: No known direct security risks from disabling the service.
  • Roll back: Restart the ‘Service Location Protocol’ service using net start "Service Location Protocol", or restore the system snapshot taken before making changes.

8. References and Resources

Updated on December 27, 2025

Was this article helpful?

Yes No

Related Articles