How to Find Your Company on Shodan (Before an Attacker Does): A Founder's 15-Minute Guide

Attackers almost never start by hacking you. They start by searching for you — and Shodan is the search box they type into. Before anyone tries a password or fires off an exploit, they run a query to build a list of targets that are already wide open, and your company might quietly be on it.

Here's the reassuring part: the exact same search box is free for you to use too. In about 15 minutes, with no security background, you can run a handful of filters to see what an attacker would see when they look up your company — and fix it first. This post is a short, hands-on self-audit. The rule for the whole thing is simple: search for yourself, not for strangers.

The short version:

• Shodan is a search engine for internet-connected devices. It indexes the public "banner" — the little bit of metadata a server hands back to anyone who connects — for services like web servers, SSH, databases, and remote-desktop endpoints. If Shodan can see it, the door is already open to everyone, because your own server volunteers that banner to every visitor. Reading the index is passive and legal: you're browsing data Shodan already collected, not scanning anyone.
• Search for yourself with four filters. hostname: and ssl.cert.subject.cn: run on a free account and do the bulk of a founder's work; org: and net: (your IP ranges) are a paid power-up worth it only if you own IP space. What you find is your real external attack surface.
• Triage with the risky-ports table. Exposed databases and caches (MySQL 3306, PostgreSQL 5432, MSSQL 1433, MongoDB 27017, Redis 6379, Elasticsearch 9200, Memcached 11211) plus plaintext FTP 21 / Telnet 23 are critical; RDP 3389, SSH 22, and admin panels are high. Identity beats the port number — a database is dangerous wherever it listens.
• Most exposures are forgotten staging boxes, not breaches. The fix is usually a firewall rule, a VPN, or turning on auth. Confirm the door is closed with a live Nmap or redis-cli self-test — Nmap is live; Shodan is a stale index.
• A one-off search is a great first move, not a finish line. Shodan is point-in-time and never sees cloud buckets, DNS hygiene, expiring certs, takeovers, or exposed .env files — and even Shodan Monitor only watches IPs you already gave it. We'll be honest about that gap at the end.

What Shodan actually is (and why you should look yourself up)

Shodan is a search engine that indexes the public banners of internet-connected devices. A banner is just the metadata a server sends back when something connects to it — things like "I'm nginx 1.18 running on Ubuntu," "I'm an OpenSSH server," or "I'm a MongoDB instance." Where Google crawls web pages, Shodan crawls services: HTTP and HTTPS, SSH, FTP, Telnet, SNMP, SMTP, and dozens more.

It was launched in 2009 by John Matherly — who'd been kicking the idea around since 2003 — and first shown off at DEFCON 17. (The name is a nod to SHODAN, the rogue AI from the System Shock games.) If you want the full backstory, the Wikipedia entry on Shodan is a solid primer. For our purposes, one mechanical detail matters more than the history.

How it works: banner-grabbing, not break-ins

Shodan does something called banner-grabbing. It connects to public IP addresses across a huge range of ports, records whatever banner each service returns, and then fingerprints it — product, version, operating system, location, and any known vulnerabilities tied to that version. That's the whole trick. It's passive: Shodan reads what the server voluntarily hands over and indexes it. It doesn't log in, doesn't guess passwords, and doesn't run exploits.

This is the single idea to take away: the server hands out the banner itself, to anyone who asks. Shodan isn't a magic X-ray that peers inside your network. It's a polite visitor that knocked on your public-facing doors and wrote down what answered. So if a service of yours shows up on Shodan, that's not Shodan being clever — it's your server being reachable and chatty. Visibility on Shodan equals visibility to attackers, because they're knocking on the exact same doors. (One nice side effect: because Shodan fingerprints the service, not the port number, a database hiding on some unusual port still gets identified for what it is. More on that later.)

Is it legal to look myself up? Yes.

Quick reassurance, no lawyer-speak: searching Shodan is passive and legal. You're reading already-public data that Shodan collected, not scanning or touching anyone's systems yourself. When you query your own company, you're simply looking at a list of doors that are already open to the entire internet — about as low-risk as it gets. The grey area in security is active scanning of systems you don't own; browsing a search index isn't that.

And why bother at all? Because the most dangerous assets are the ones you've forgotten you have. A staging box a contractor spun up "just to test," a demo VM nobody decommissioned, a database that was supposed to be internal-only until a firewall rule quietly exposed it — these don't appear in any spreadsheet, but they do appear on Shodan. The same filters a pentester uses to find victims, you can use to find yourself first.

Shodan for beginners: free account vs. paid membership

Good news before we touch a single filter: you do not need to pay anything to find most of what matters. A free Shodan account is enough to run the two filters that do the heavy lifting in this guide, and you can have one created in under a minute. The paid tier exists, and it's genuinely useful if you own IP space — but for a typical early-stage startup, it's a nice-to-have, not a gate.

What you get for free

Create a free account on Shodan. That free tier lets you run filtered searches and gives you a small monthly query quota — enough for a focused self-audit, not enough to crawl the internet all afternoon. Each search shows you roughly the first couple of pages of results rather than the full firehose, which is fine when you're searching for your own assets and not trying to enumerate the planet. Crucially, the two most reliable filters for a founder — hostname: and ssl.cert.subject.cn: — both work on the free tier, and they catch the bulk of what a non-security owner needs to find.

What needs a paid membership

Three filters are gated behind Shodan's paid membership: org: (search by the network-owner name in WHOIS), net: (search a CIDR range of IPs you own), and os: (filter by operating system). The vuln: filter — which flags hosts matching known CVEs — sits even higher, on the Small Business plan and up.

The important nuance: Shodan's paid membership is a one-time purchase — a lifetime license, not a recurring subscription. Shodan runs frequent promotions, so rather than quote a figure that'll be wrong next week, just check the current free-vs-membership breakdown and pricing before you decide. If you own dedicated IP blocks, the membership pays for itself the first time net: surfaces a box you forgot about. If you don't, you can skip it without missing much.

Why org: probably won't help you

Here's the part that trips up nearly every founder who reads a generic Shodan tutorial. Those guides lead with org:"Your Company Inc" as the headline move — and for an early-stage company, it's frequently the least useful filter of the four. The reason is where your infrastructure actually lives. If you run on AWS, GCP, DigitalOcean, or any other cloud, you don't own the IP addresses your servers sit on — the provider does. So in the WHOIS and ASN records that org: reads from, your production box shows up under Amazon or Google, not under your company name. Search org:"Your Startup" and you may get a near-empty page even though you have plenty exposed.

That's why, for most startups, the reliable filters are the ones tied to your identity rather than your IP registration. The assets org: misses are exactly the ones that hurt: the staging box a contractor spun up on their own DigitalOcean droplet, the demo VM nobody tore down, the one-off test instance with a real certificate still attached. Those forgotten staging boxes and contractor VMs are classic shadow IT — provisioned outside your main account, invisible to a name-based search, and very much reachable by anyone scanning the internet. Searching by domain and certificate is how you find them.

The filters that find your own assets (2 free, 2 paid)

Here's the honest version of the "four filters" promise before you start. Two of them are free and do the bulk of a founder's work — they catch shadow IT, the forgotten staging box, the contractor's VM nobody decommissioned. The other two (org: and net:) are a paid power-up that only pays off if your company actually owns IP address space. So the realistic free path is two filters, and that is genuinely enough to start. Think of the four as a layered sweep: begin broad with what you can run for free, then go precise with what you provably own.

Every query below is copy-paste ready. Swap in your real domain or IP range, paste it into the Shodan search box, and read the results. The full list of supported filters lives in the official Shodan filter reference if you want to go deeper.

Filter 1 — hostname: (free)

What it does: matches any indexed service whose reverse-DNS (PTR) hostname contains your domain — including subdomains, which is exactly where forgotten boxes like to hide. It also accepts a comma-separated list, so you can sweep several domains in one shot.

hostname:yourcompany.com

hostname:yourcompany.com,yourcompany.io,yourcompany-staging.com

When to use it: first, always. It's free, it covers subdomains, and it's the fastest way to see "what does the internet think is mine?" One caveat: hostname: depends on reverse-DNS being configured, so a box with no PTR record won't appear here even if it's wide open. That gap is exactly why you also run the next filter.

Filter 2 — ssl.cert.subject.cn: (free)

What it does: finds anything presenting a TLS certificate issued for your domain — keyed off the certificate's Subject Common Name. ("Common Name" is just the domain the cert was issued for, e.g. vpn.yourcompany.com or a *.yourcompany.com wildcard.)

ssl.cert.subject.cn:yourcompany.com

When to use it: immediately after hostname:, and treat this one as your shadow-IT catcher. Certificates literally name the domain they were issued for, so this filter surfaces hosts the others miss entirely — an HTTPS admin panel on an odd port like 8443, a service with no reverse-DNS record, or a box still serving a reused wildcard cert long after everyone forgot it existed.

Shodan is one lens for cert-based discovery; the certificate-transparency public ledger is another. If this filter turns up subdomains you'd forgotten, it's worth seeing how attackers (and you) can find forgotten subdomains in Certificate Transparency logs — the two techniques overlap and catch different blind spots, so run both.

Before the paid filters: find your own ASN and IP ranges

The next two filters search by who owns an IP block and by the block itself — so you cannot run them until you know which addresses are actually yours. Spend five minutes pinning this down:

• Open your cloud console and list every static / elastic public IP — these hang off load balancers, NAT gateways, and any instance you gave a public address. In AWS that's Elastic IPs plus your ALB/NLB addresses; in GCP, reserved external addresses; in DigitalOcean, your reserved IPs and droplet public IPs.
• Note any CIDR blocks your company owns directly (e.g. 203.0.113.0/24). Most startups own none — that's fine, it just means org: and net: will be thin and your two free filters do the real work.
• Cross-reference the two lists. Because hostname: coverage depends on how your reverse-DNS is set up, comparing "IPs I know I own" against "what the free filters returned" is how you spot gaps — an owned IP that never showed up in either free search is exactly the kind of asset worth a closer look.

Filter 3 — org: (paid)

What it does: searches the network-owner name recorded in WHOIS — the organization an IP block is registered to.

org:"Your Company Inc"

When to use it: when your company owns IP blocks under its own legal name. It's fast and broad in that case, much weaker if your infrastructure sits inside a cloud provider's range. For most early-stage companies, treat org: as a bonus rather than a primary filter.

Filter 4 — net: (paid, most accurate)

What it does: enumerates every Shodan-indexed service inside a CIDR range you specify. CIDR is just the address/prefix notation for a block of IPs — net:203.0.113.0/24 covers 203.0.113.0 through 203.0.113.255.

net:203.0.113.0/24

When to use it: the moment you have a confirmed range from the step above. This is the highest-confidence filter you have, because it's anchored to addresses you provably control rather than to a name or a DNS record that might be stale. If you only run one paid filter, run this one against each range you own.

Bonus combo: hunt open database doors inside your range

Filters stack. Once you have a range, layer a port: hunt on top to go straight for the most dangerous open doors — databases and caches — in a single query:

net:203.0.113.0/24 port:6379,27017,3306,5432,9200

That's Redis (6379), MongoDB (27017), MySQL (3306), PostgreSQL (5432), and Elasticsearch (9200) in one sweep — services that should essentially never face the public internet. You can also pivot by service identity rather than port, which catches a database that's been moved to a non-standard port to "hide" it:

product:MongoDB port:27017

Single-host deep look: the Shodan CLI

When a search points you at one specific IP and you want the full picture — every open port and the raw banner for each — the Shodan command-line tool is faster than clicking through the web UI:

pip install shodan
shodan init <your-api-key>
shodan host 203.0.113.10

That last command prints all of Shodan's indexed open ports and service banners for that single address — a clean, scriptable way to audit one box you've flagged. Keep one limitation in mind for everything above: Shodan reports what it saw the last time it crawled that IP, which can be days or weeks ago. It's a fast, free starting move — just not live ground truth, a gap we'll come back to.

Is my server (or database) exposed to the internet? A red-flag ports cheat sheet

Once your search returns a list of your own hosts, the next question is the one that actually matters: which of these open ports should make you put down your coffee? Here is the one principle that separates people who panic from people who triage well: severity is about what an attacker gets if they walk through the door, not how easy the door was to find. An open port that fronts a public website is a normal front door. An open port that fronts your production database with no password is an unlocked vault. Shodan finds both the same way; your job is to tell them apart.

The cheat sheet

This table mirrors the severity scale we use internally, so the ratings are consistent with what a real attack-surface tool would flag. Scan it top to bottom: the CRITICAL rows are the ones to fix today.

That list isn't exhaustive, and it doesn't need to be — the principle is what matters, not memorizing every number. Any database, cache, message broker, or admin panel you find facing the open internet belongs near the top of your fix list, whether or not it appears in this table.

Why databases and caches are the worst case

The data stores are CRITICAL for a specific, unglamorous reason: an exposed one with no or weak authentication gives an attacker direct, credential-free read and write access to your primary data. There is no clever exploit to develop — they just connect, like you would. Worse, they're found in bulk with a single filter and then hit by fully automated mass-ransom campaigns that wipe data and leave a note.

This isn't theoretical, and it isn't new. Back in 2017, attackers used Shodan to sweep up roughly 28,000 internet-exposed MongoDB databases running the default no-auth config, wiping them and demanding ransom — with many victims' data destroyed even after they paid. It never stopped. Recent scans count 200,000+ MongoDB servers exposed to the internet, and researchers found that around 45.6% of unauthenticated exposed instances had already been wiped by automation. Elasticsearch tells the same story — DarkBeam left an unauthenticated cluster on a public IP and leaked over 3.8 billion records before a researcher reported it. If you want the full breakdown of how exposed databases like MongoDB, Redis and Elasticsearch lead to full compromise, that pillar piece covers the mechanics and the body count.

Redis earns its CRITICAL rating on the same logic and then some. It listens on 6379 with no password by default, and an attacker who reaches it can do more than read your cache — abusing CONFIG SET to write a malicious cron job or SSH key turns a cache exposure into remote code execution on the host. Around 40,000 Redis servers were still publicly reachable with no password in 2025. Here's why an exposed Redis on port 6379 is a full-server compromise waiting to happen.

Why SSH and admin panels are "only" HIGH

SSH (22), RDP (3389), and admin panels sit one rung below the databases — but don't relax. They're HIGH not because they auto-compromise the way an open database does, but because they are the most-attacked surfaces on the internet, and one weak credential equals full control. SSH is relentlessly brute-forced; admin panels like cPanel, Webmin, Kibana, and phpMyAdmin are constantly probed for default passwords.

RDP gets special attention because it combines both problems: it's a leading ransomware entry point and it has a pre-authentication wormable flaw in BlueKeep (CVE-2019-0708, CVSS 9.8) that needs no credentials or user interaction at all. CISA's guidance is blunt: patch it, and block TCP 3389 at the perimeter firewall — RDP should never be directly exposed to the internet (see CISA's BlueKeep advisory for the full remediation list).

The one rule non-experts miss: identity beats the port number

Here's the trap. People look up "port 27017 = MongoDB," then assume that MongoDB running on some random port like 9876 is somehow safer because it's "hidden." It is not. A database is dangerous wherever it listens. Shodan and attackers alike fingerprint the actual service from its banner, not from the port number — so MongoDB on a non-standard port shows up in a service search just as cleanly, and is just as exploitable. The same goes for the whole list: Postgres on port 5555 is exactly as exposed as Postgres on 5432. Use the table as guidance for the common cases, but internalize the rule behind it — identity beats default classification.

One accuracy caveat before you panic

If your results show ports 80, 443, 8080, or 8443 open on an asset that sits behind a CDN like Cloudflare, take a breath — those are very likely the CDN's edge ports, not your origin server's open ports. The CDN terminates that traffic on your behalf, so a "port behind Cloudflare" isn't necessarily a hole in your own infrastructure. Confirm what's actually reachable on your origin before treating an edge port as a finding. The doors worth worrying about are the database, cache, remote-access, and admin-panel ports above.

Found something? The fix checklist

First, breathe. If a search just lit up one of your IPs with an open database or a login page, the odds are overwhelming that you found a forgotten asset, not an active breach. The usual suspects are a staging box someone spun up for a demo, a contractor's VM, or a "temporary" debug port that nobody ever closed. Boring mistakes, not a kicked-in door. The good news: you found it before anyone used it, and almost everything below is a configuration change you can make this afternoon. Each fix follows the same principle — default-deny. A service should be reachable only by the people and machines that genuinely need it, and the public internet is not on that list unless you put it there on purpose.

If you found an exposed database or cache (3306, 5432, 27017, 6379, 9200)

This is the most urgent category, and the fix is almost always the same root cause: the service is bound to 0.0.0.0 (all network interfaces) instead of staying private. Bind it to localhost or a private subnet, and firewall the port so only your application servers can reach it.

• Redis: set bind 127.0.0.1, protected-mode yes, and requirepass <strong-password> (or use ACLs in Redis 6+). Redis ships with no authentication by default, which is exactly why an open one is so dangerous.
• MongoDB: enable security.authorization: enabled and set net.bindIp to private interfaces only.
• PostgreSQL (5432), MySQL/MariaDB (3306), Elasticsearch (9200): same playbook — require auth, bind private, firewall the public port. Elasticsearch 8.0+ (released 2022) turns security on by default, but anything older needs it enabled explicitly.

If you found remote admin exposed (22 SSH, 3389 RDP)

Remote-access ports shouldn't face the open internet at all. Put them behind a VPN or an IP allowlist so only your team's known addresses can even start a connection.

• RDP (3389): put it behind a VPN, enable Network Level Authentication (NLA, which forces authentication before a session is established), and patch BlueKeep (CVE-2019-0708) — a wormable, pre-authentication flaw that needs no password and no clicks to exploit.
• SSH (22): restrict source IPs at the firewall or security-group level, switch to key-based auth (PasswordAuthentication no), and disable root login (PermitRootLogin no).

If you found an admin panel (phpMyAdmin, Kibana, Jenkins, Grafana)

A login page reachable by the whole internet is a standing invitation to credential-stuffing and default-password attacks — one weak password equals full control of whatever sits behind it. Put every admin and management UI behind a VPN or SSO. Don't rely on the login form being the only thing between an attacker and your dashboards.

What can't be patched gets blocked at the perimeter

Sometimes you can't immediately fix the service itself — a legacy Windows box that can't take the BlueKeep patch, a vendor appliance you don't control. In that case, block it at the edge. This is literally CISA's own guidance: CISA advisory AA19-168A recommends blocking TCP port 3389 at the enterprise perimeter firewall to stop BlueKeep exploitation. Apply the same default-deny to every data-store port — 3306, 5432, 27017, 6379, 9200 — at your perimeter firewall or cloud security group.

And then: decommission discipline

If the exposure turned out to be a forgotten staging box or a contractor's leftover VM, don't just close the port — tear the whole thing down. Then clean up after it: remove the DNS records that point to it and revoke or let expire the certificates issued for it. A dangling DNS record or a stray certificate is enough to drag the problem back from the dead.

Shodan vs. Nmap, in one line

Before you confirm your fix, it helps to know why the self-test below uses a different tool than the one you started with. Shodan is a passive, pre-collected index — it shows you what its crawler saw the last time it visited your IP, which can be days or weeks ago. Nmap is an active probe that connects to your host right now and tells you what's actually open this second. That's exactly why you don't trust Shodan to confirm a door is closed — its snapshot might be stale and still show the old open port. You verify with a live probe.

Confirm the door is actually closed

Don't take Shodan's word that you fixed it. Test from outside your network — a coffee-shop laptop, a phone hotspot, or any machine that isn't on your VPN — so you're seeing what an attacker sees:

• Redis: run redis-cli -h YOUR_IP PING. If it returns PONG with no password prompt, it's still wide open. A connection error or auth challenge means you're good.
• Any database: try connecting with a normal client (psql, mysql, mongosh) from a machine off your VPN. If it connects, it's internet-exposed.
• Everything at once: run an Nmap port scan from an external host:

nmap -Pn -p 22,3389,3306,5432,6379,9200,27017 YOUR_IP

Ports reported as open are still reachable from the internet; filtered or closed means your firewall or binding change is working. Re-run it after every change until the list is clean.

Where the free method runs out: what Shodan (and Shodan Monitor) can't see

Here's the honest part most guides skip. A 15-minute Shodan pass is a genuinely good first move — you'll almost certainly turn up something you forgot about, and that alone is worth the afternoon. But Shodan is one scanner's snapshot, not ground truth, and it's important you know exactly what you're still blind to after you close the tab. Three gaps, in plain language.

Limit 1 — It's point-in-time, and it's stale

Shodan doesn't scan your servers when you search. It shows you the results of the last time Shodan's crawlers happened to reach those IPs — which could be days or weeks ago. That cuts both ways. A port you firewalled yesterday may still show as open in your results, and a port you opened this morning won't appear at all until Shodan re-crawls it. An attacker doesn't have that lag. When they scan your range live, they see what's open right now. So a clean Shodan result is reassuring, but it's reassurance about your perimeter as it looked last week — not today.

Limit 2 — It's manual, and the filters miss what you don't already know about

The four filters only find assets that tie back to something you already know — your org name, your CIDR ranges, your domain in reverse DNS, your certificates. They are, by design, blind to the assets you've forgotten: the staging box a contractor spun up and never tore down, the demo VM in a cloud region you don't normally use, the marketing microsite a different team launched on a provider IP tagged to the cloud vendor, not to you. That's shadow IT, and it's precisely where exposure hides. Worse, your attack surface drifts daily — every deploy, every new environment, every "just testing this" security-group rule changes it. A manual pass captures a single moment.

Limit 3 — Whole categories of exposure are simply invisible to it

This is the most important one, because everything Shodan does show is ports and banners. Open ports are a real slice of your attack surface — but a slice, not the whole thing. Shodan does not find:

• Open cloud storage — Shodan indexes services on IPs; it does not enumerate public S3, GCS and Azure buckets leaking data. A misconfigured bucket has no "port" to grab a banner from, so it's invisible to a port search entirely.
• DNS hygiene gaps — missing or broken SPF, DMARC, and DNSSEC are exposure (they let attackers spoof your mail and tamper with name resolution), but they live in DNS records, not a service banner.
• Certificate posture — an expiring cert, a weak TLS protocol, a cert quietly revealing internal hostnames. Shodan stores the cert it saw; it doesn't grade it or warn you before it lapses.
• Subdomain takeovers — a dangling CNAME pointing at a deprovisioned SaaS account is a one-click takeover, but there's no open port to give it away.
• Exposed sensitive files — an exposed .env file leaking production secrets, an open .git directory, a stray database backup. These sit behind a perfectly ordinary web server on port 443 — Shodan sees "HTTPS," not the prod database password sitting at /.env.

Every one of these sits on the same severity scale as an open port. An exposed .env with live credentials is every bit as critical as an open MongoDB — arguably worse, because it hands over the keys directly. Treating ports as the headline and these as afterthoughts is how breaches happen on the surface nobody was looking at.

"Why not just use Shodan's own Monitor?"

Fair question — Shodan offers a product called Shodan Monitor that watches a set of IPs you supply and alerts you when something changes. It's genuinely useful, and if you're already paying for Shodan it's worth turning on. But it doesn't close the three gaps above — it narrows one of them slightly:

• It still runs on Shodan's crawl cadence, not live. Monitor alerts when Shodan next sees a change, not the instant it happens. The staleness gap shrinks; it doesn't disappear.
• It can only watch what you give it. Monitor needs you to supply the IPs up front. It cannot discover the forgotten staging box or the cloud IP nobody tagged — the exact assets that cause trouble. If it's not in your inventory, Monitor never looks at it.
• It's still ports and banners only. Monitor inherits Shodan's blind spots wholesale: no buckets, no DNS hygiene, no cert grading, no takeover detection, no exposed-file scanning.

The honest bridge: continuous, active, and broader than ports

The gaps above describe what continuous external attack surface monitoring is for: not a stale crawl you happen to query, but active, scheduled probes that maintain a living inventory of your assets and cover the categories a port search can't. This is the part of the job FortWatch watches these ports and services for you continuously — it runs its own active nmap probes on a schedule (by default, daily) rather than waiting on someone else's crawl, and grades what it finds against a fixed port-risk taxonomy so a critical is a critical no matter where it listens. To be clear, FortWatch isn't a Shodan front-end or alternative; it scans your assets directly, which is why it can see things Shodan structurally can't.

And because ports are only one slice, the same continuous coverage extends to the categories Shodan misses entirely: a DNS scanner for SPF/DMARC/DNSSEC and dangling records, an SSL scanner for cert expiry and weak ciphers, a cloud-exposure scanner for public buckets, a takeover scanner for dangling CNAMEs, and a sensitive-files scanner for exposed .env and .git paths. These aren't add-ons to a port scanner — they're peers, each on the same severity scale, because real exposure doesn't care which category it falls into. None of which makes your 15-minute Shodan pass a waste. It's a smart, free first move — just necessary, not sufficient.

What do I do with this?

You don't need a security background to do this — you need about 15 minutes and the will to look. Work through the list below in order. The first two steps are free and do most of the work; the rest is triage and fixing what you find.

1. Create a free Shodan account. Sign up at shodan.io. The free tier shows you more than enough to spot the obvious problems, and it unlocks the two filters you'll lean on most.
2. Run the two free filters first. Search hostname:yourcompany.com and then ssl.cert.subject.cn:yourcompany.com, swapping in your real domain. Write down every IP and every service that comes back — especially anything you don't recognize. The cert filter is the sneaky-good one: it catches forgotten and non-HTTPS hosts that still present a certificate issued for your domain.

   hostname:yourcompany.com
   ssl.cert.subject.cn:yourcompany.com

3. If you own IP ranges, scope and stack. Find your CIDR blocks first (your hosting/cloud console lists your public IPs; a WHOIS lookup of one shows the owning block). Then, with a paid Membership, run net: and org:"Your Company Inc" against what you own, and stack a database-port hunt straight onto your range:

   net:203.0.113.0/24 port:6379,27017,3306,9200

   Most early-stage infra lives inside your provider's IP space (AWS, GCP, DigitalOcean), so it shows up under their org in WHOIS — which is exactly why net: and the cert/hostname filters beat org: for young companies.
4. Triage against the red-flag ports. For every service, ask: is this a database, cache, RDP, SSH, or admin login facing the open internet? A live database or cache (MongoDB 27017, Redis 6379, Elasticsearch 9200, MySQL 3306) is critical — direct, often credential-free read/write to your data store. Remote-access and admin doors (SSH 22, RDP 3389, panels like Kibana, phpMyAdmin, Jenkins, Grafana) are high: one weak password or one unpatched pre-auth bug, like BlueKeep on RDP, equals full control. Remember identity beats the port number — a database is dangerous wherever it listens. One reassurance for skim readers: ports behind Cloudflare or another CDN (typically 80/443/8080/8443) are the CDN's edge, not your origin's open port. Don't panic over those.
5. Fix the criticals first. For exposed data stores: firewall the public port and bind the service to localhost or a private subnet, then turn on authentication and TLS (Redis: bind 127.0.0.1, protected-mode yes, requirepass; MongoDB: security.authorization: enabled). For remote admin: never expose RDP or SSH directly — put them behind a VPN or IP allowlist, enable Network Level Authentication on RDP, switch SSH to key-based auth with root login off. Per CISA's BlueKeep guidance, block TCP 3389 at the perimeter for anything you can't immediately patch. And rotate any credentials, keys, or secrets that were sitting open.
6. Confirm each door is actually closed with a live self-test. This is the step Shodan's stale index can't do for you — it tells you the ground truth right now. For a suspected-open Redis, run redis-cli -h YOUR_IP PING from off your network; a PONG with no auth prompt means it's still wide open. Try connecting to a database with a normal client from a machine off your VPN. Or scan from an external host: nmap -Pn -p 22,3389,3306,6379,9200,27017 YOUR_IP. Same one-liners an attacker uses; use them on yourself.
7. Remember this is a snapshot, and put something durable in place. Shodan only shows what it saw the last time it crawled your IPs — a port you closed may still show, a port you opened yesterday may not appear yet. Even Shodan Monitor only watches the IPs you already told it about, so it can't catch the shadow IT and new cloud assets that aren't in your inventory. And a port search never sees open cloud buckets, DNS hygiene gaps, expiring certs, or subdomain takeovers — all real exposure on the same severity scale. So either set a recurring reminder to repeat this sweep, or let something continuous cover the drift and the categories a banner search can't see. That's the whole point of mapping your entire external attack surface on a schedule rather than once.

Doing this once already puts you ahead of most companies your size. If you'd rather not keep it in your head, you can run a free scan of your own assets and see what's exposed without running a single query yourself.