Finding Exposed Services (and Fixing Them) with ScanSearch

Ever wondered what parts of your infrastructure are accidentally visible to the entire internet? It's a common blind spot. We spend a lot of time securing applications and servers, but sometimes a misconfigured port or an old, forgotten service can leave a gaping hole for attackers to walk right through.

This article will walk you through how to use ScanSearch, an internet-wide search engine for network devices, services, and vulnerabilities, to identify these exposed services. More importantly, we'll discuss practical steps to address what you find.

The Problem: Unintended Exposure

Imagine you set up a new Redis instance for a quick dev project, and in your haste, you accidentally bind it to 0.0.0.0 instead of 127.0.0.1. Or perhaps a test API server that was never taken down, still running on an obscure port. These aren't hypothetical scenarios; they happen all the time. Attackers actively scan the internet for exactly these kinds of misconfigurations, looking for anything listening that shouldn't be.

Manually scanning your entire allocated IP range is tedious and often misses things that aren't directly linked to your current projects. This is where tools like ScanSearch become incredibly useful.

Introducing ScanSearch

ScanSearch allows you to query the internet for specific services, banners, and even known vulnerabilities. It's essentially a search engine, but for network-accessible information. Think of it as Google, but for ports and protocols.

You can access ScanSearch at https://scansearch.net.

Let's dive into some practical examples.

Practical Example 1: Finding Exposed Redis Instances

Redis is a fantastic in-memory data store, but if left exposed without authentication, it's a huge security risk. Attackers can wipe data, inject malicious keys, or even use it for remote code execution.

To find exposed Redis instances, we can search for the default Redis port (6379) and its common banner.

Go to https://scansearch.net and in the search bar, type:

port:6379 "Redis"

This query tells ScanSearch to look for devices listening on port 6379 that also contain the string "Redis" in their banner or service information. You'll likely see a lot of results. While most won't be your specific server, this gives you a sense of the scale of the problem. If you manage a specific IP range, you could refine this further, for example:

ip:YOUR_IP_RANGE port:6379 "Redis"

Replace YOUR_IP_RANGE with your actual IP address or CIDR block (e.g., 192.168.1.0/24).

Actionable Steps:

• Bind to Localhost: Ensure your Redis instance is bound to 127.0.0.1 (or a specific internal IP) in your redis.conf file.
• Authentication: Always enable requirepass in redis.conf and use a strong password.
• Firewall Rules: Restrict access to Redis's port (6379) only from trusted internal IPs using your server's firewall (e.g., ufw or firewalld).

Practical Example 2: Identifying Open SSH Ports Beyond Standard 22

While SSH on port 22 is common, some administrators move SSH to a different port to reduce automated probing. However, if this new port is still open to the internet and vulnerable, it's still a risk. Let's say you moved your SSH to port 2222.

Search on ScanSearch for:

port:2222 "SSH-2.0"

Again, if you manage specific IPs:

ip:YOUR_IP_RANGE port:2222 "SSH-2.0"

This would show you if any of your servers are exposing SSH on that non-standard port.

Actionable Steps:

• Key-based Authentication: Disable password authentication entirely in sshd_config (PasswordAuthentication no).
• Strong Passwords (if needed): If you absolutely must use passwords, enforce strong, unique ones.
• IP Whitelisting: Use firewall rules to restrict SSH access to only specific trusted IP addresses (e.g., your office IP, VPN IP).
• MFA: Implement Multi-Factor Authentication if possible.

Practical Example 3: Searching for Common Vulnerabilities

ScanSearch can also help you find devices running services with known vulnerabilities, though it's important to remember that such search engines provide a snapshot and immediate remediation is key.

For instance, if you're concerned about an old version of Nginx that might have a known vulnerability, you could search for its banner:

"nginx/1.10.3"

This is a generic example, but if a specific CVE (Common Vulnerabilities and Exposures) is tied to a particular service banner or version, you can leverage this to find potentially vulnerable instances.

Actionable Steps:

• Patch Regularly: Keep all your software, especially internet-facing services, up to date with the latest security patches.
• Remove Old Services: Decommission and remove any services that are no longer needed.
• Security Audits: Regularly perform security audits and vulnerability scans on your infrastructure.

Integrating into Your Workflow (Beyond Manual Search)

While the web interface is great for quick checks, for ongoing monitoring, you might want to integrate ScanSearch's capabilities into your scripts or CI/CD pipelines. While ScanSearch's official API documentation isn't publicly available on their site, many developers use web scraping libraries or browser automation tools (with caution and respect for their terms of service) to automate data collection from similar platforms.

For instance, a Python script using requests and BeautifulSoup could technically parse results, though direct API access would be more robust if it becomes available.

import requests
from bs4 import BeautifulSoup

def search_scansearch(query):
    # This is a simplified example and might break if ScanSearch's HTML structure changes.
    # For a robust solution, an official API is preferred.
    base_url = "https://scansearch.net/search"
    params = {'query': query}
    headers = {
        'User-Agent': 'Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/91.0.4472.124 Safari/537.36'
    }
    try:
        response = requests.get(base_url, params=params, headers=headers, timeout=10)
        response.raise_for_status() # Raise an exception for HTTP errors
        soup = BeautifulSoup(response.text, 'html.parser')

        # This part is highly dependent on ScanSearch's specific HTML structure.
        # You'd need to inspect the page to find the correct CSS selectors.
        # Example: looking for <div class="result-item"> elements
        results = []
        for item in soup.find_all('div', class_='result-item'): # Placeholder class
            ip_address = item.find('span', class_='ip-address').text.strip() # Placeholder class
            port = item.find('span', class_='port').text.strip() # Placeholder class
            banner = item.find('pre', class_='banner-text').text.strip() # Placeholder class
            results.append({'ip': ip_address, 'port': port, 'banner': banner})
        return results
    except requests.exceptions.RequestException as e:
        print(f"Error during request: {e}")
        return []

# Example Usage:
# found_services = search_scansearch('port:6379 "Redis"')
# for service in found_services:
#    print(f"Found Redis on {service['ip']}:{service['port']} - Banner: {service['banner'][:50]}...")

Disclaimer: The Python code above is illustrative and would require detailed inspection of ScanSearch's HTML to correctly parse results. Relying on web scraping for critical security monitoring isn't ideal due to potential breakage with website updates. Always check a service's terms of use regarding automated access.

Conclusion

Understanding your external attack surface is a fundamental part of a robust security posture. Tools like ScanSearch provide a powerful way to gain an attacker's perspective, helping you identify and remediate unintended exposures before they become a problem. Regularly querying for common misconfigurations or specific service banners across your IP ranges can save you a lot of headache down the line. Stay vigilant, patch often, and always assume your services are being probed.