Internet scanner IP list: Shodan, Censys, Shadowserver and how to identify them

Put a new server on a public IP and watch the firewall log. Within minutes you will see connection attempts on ports you never opened, and HTTP requests for /, /.env or /wp-login.php. Some of that traffic is malicious. A large share comes from internet-wide scanning projects: search engines for devices (Shodan, Censys), security research groups (Shadowserver, university labs) and attack-surface-management vendors that scan the whole IPv4 space on a schedule.

Knowing which is which matters. A probe from Censys is not an attack on you. A probe from an unknown VPS that tries ten exploit paths might be. This guide explains how to identify the well-known scanners and where their operators publish identifying information.

Why research scanners exist

Internet-wide scanners build a map of what is exposed: which IPs run which services, which TLS certificates they present, which software versions answer. That map is used for:

• Search engines for devices, such as Shodan and Censys, which sell or share the index.
• Vulnerability notification. The Shadowserver Foundation and national CERTs scan for exposed vulnerable services and send free reports to network owners.
• Attack surface management (ASM), where vendors scan to find their customers' forgotten assets.
• Academic measurement, such as research on TLS adoption or IPv6 deployment.

Most of these projects behave predictably: low request rates, identifiable infrastructure, and an opt-out process. That is what makes them identifiable.

How scanner operators identify themselves

There is no common standard like the JSON files search engines and AI crawlers use. Scanner operators use three mechanisms, and some combine them:

1. Published IP ranges. The operator lists the networks it scans from on a web page or in a text file.
2. Reverse DNS. Scanner IPs have PTR records under a domain the operator controls (for example, Shadowserver scanners resolve to names under shadowserver.io). As with Googlebot, a PTR record only counts if the forward lookup of that hostname returns the same IP.
3. A descriptive user agent on HTTP probes, such as Censys's CensysInspect/1.1. Like any user agent, this can be copied.

Known scanners and where they document themselves

Below are some of the best-known projects and the first-party pages that identify their traffic. Ranges change, so always use the operator's current page rather than a copy.

Censys's page is a good model. It lists the exact IPv4 /24s and IPv6 ranges it scans from, its ASNs, and the user agent its HTTP scanner sends. Shodan is the opposite case. We could not find an official list, so the only first-party signal is the reverse DNS its scanners carry. That is still checkable with forward confirmation, but it can't be turned into a static firewall list.

Check an IP from your logs

By reverse DNS (any scanner that uses PTR names)

$ host 198.51.100.23
23.100.51.198.in-addr.arpa domain name pointer scanner-07.example-scanner.com.

$ host scanner-07.example-scanner.com
scanner-07.example-scanner.com has address 198.51.100.23

Both lookups must agree. The example uses documentation addresses. Run it against a real IP from your log.

By published ranges (Python)

For operators that publish ranges, put the networks in a file you refresh from their pages and match locally:

import ipaddress

# One CIDR per line, refreshed from the operators' own pages.
with open("scanner-ranges.txt") as f:
    NETWORKS = [ipaddress.ip_network(line.split("#")[0].strip())
                for line in f if line.split("#")[0].strip()]

def is_known_scanner(ip):
    addr = ipaddress.ip_address(ip)
    return any(addr in net for net in NETWORKS if net.version == addr.version)

for line in open("/var/log/nginx/access.log"):
    ip = line.split(" ", 1)[0]
    if is_known_scanner(ip):
        print("research scanner:", line.strip()[:120])

The hard part is keeping scanner-ranges.txt accurate. Every operator publishes in its own format (HTML tables, text files, JSON), and some change their ranges without notice.

Should you block internet scanners?

There's no single right answer. Consider:

Reasons to allow them

• Shadowserver and national CERTs use their scans to warn network owners about vulnerable services. Blocking them can mean you stop getting those warnings.
• Your own security team or ASM vendor may rely on Censys- or Shodan-style data to find exposed assets.
• They don't hide, so they're easy to measure and filter in analytics.

Reasons to block them

• You don't want your services listed in public search engines, which attackers also use to find targets.
• You want quieter logs and fewer false alarms.
• Compliance or policy requires minimising exposure.

A middle ground many teams choose: don't block, but label. Tag requests from verified scanners, keep them out of analytics and alerting, and spend your attention on unlabelled probes. If you do want to opt out, use the operator's own opt-out process too. Censys and Shadowserver both describe one.

With the IPAPI.GR API

The risk.is_scanner flag in the IPAPI.GR lookup API matches an IP against our internet-scanner catalogue. That catalogue covers dozens of projects, built from operator-published ranges, forward-confirmed reverse DNS and reviewed network registrations. Shared hosting networks are never flagged just because a scanner once rented a server there. The full list is on the bot signals page.

curl "https://fast.ipapi.gr/api/lookup/198.51.100.23?key=YOUR_API_KEY"

{
  "ip": "198.51.100.23",
  "country_code": "US",
  "asn": "64500",
  "organization": "Example Scanner Inc.",
  "risk": { "is_ai": false, "is_crawler": false, "is_scanner": true }
}

In a Node.js log pipeline:

async function label(ip) {
  const res = await fetch(`https://fast.ipapi.gr/api/lookup/${encodeURIComponent(ip)}?key=${process.env.IPAPI_KEY}`);
  if (!res.ok) return 'unknown';
  const { risk } = await res.json();
  if (risk?.is_scanner) return 'research-scanner';
  if (risk?.is_crawler) return 'crawler';
  if (risk?.is_ai) return 'ai';
  return 'unlabelled';
}

As with the other flags, false only means "no current match". Newly seen scanners can be added after background verification, but a scanner that publishes nothing and has no verifiable hostname will not match. The flags are part of the Pro plan. Response fields are documented in the docs.

FAQ

Is a request from Censys or Shodan an attack?

No. They connect to services and record what answers, in the same way for every address. What someone later does with that index is another matter, which is why some teams prefer not to be listed.

Why does a scanner request /.env or /wp-login.php?

Research scanners mostly fetch the root page and read banners and certificates. Requests for specific sensitive paths usually come from opportunistic attackers or less careful scanning tools. Those are the ones to look at.

Can I opt out instead of blocking?

Several projects offer opt-out. Censys documents one on its opt-out page, and Shadowserver describes how to request exclusion. Opting out and blocking can be combined.

Do scanners use IPv6?

Some do. Censys, for example, lists IPv6 ranges. Full IPv6 space can't be scanned exhaustively the way IPv4 can, so IPv6 scanning works from hitlists of known addresses.

Summary

• A large part of the probe traffic every server sees comes from known research and ASM scanners.
• Operators identify themselves with published ranges, forward-confirmable reverse DNS and descriptive user agents. Censys documents all three. Shodan publishes no IP list.
• Decide your policy deliberately. Labelling is often more useful than blocking.
• Keep lists current, or use a lookup that does it for you.

Related reading: verifying Googlebot and Bingbot uses the same reverse DNS technique, and verifying AI crawlers covers published IP files.