Learning Shodan: Auditing Exposed Services in Your Own Lab
Shodan is a search engine for internet-facing devices and services. Unlike a traditional search engine, it does not index page content in the usual sense. Instead, it indexes banners, metadata, open ports, and service fingerprints. That makes it useful for defenders who want to understand what their own systems look like from the public internet.
This post is a practical introduction to Shodan from a defensive perspective. The goal here is simple: learn how to inspect your own public-facing lab, identify exposed services, and verify whether those services are protected by authentication. If you are building your baseline first, start with how to learn cybersecurity and structured lab practice with TryHackMe. This is not a guide for attacking systems you do not own.
1. Install the Shodan CLI
The Shodan CLI makes it easier to run quick searches and inspect hosts from the terminal.
python3 -m pip install shodan
shodan init YOUR_API_KEY
If your environment throws Python packaging errors, fix those first before assuming the Shodan CLI itself is broken. This is especially common when Python was installed by Homebrew or another system package manager.
2. Start with Basic Searches
The fastest way to learn Shodan is to start broad and then narrow things down using filters.
shodan search apache
shodan search nginx
shodan search 'port:22 country:US'
shodan search 'city:"Dubai" webcam'
These are only examples to help you understand Shodan query structure. A result appearing in Shodan does not automatically mean it is vulnerable, misconfigured, or accessible without authentication.
3. Useful Filters to Learn Early
Most Shodan queries become useful only after you start combining filters. These are some of the ones worth learning first.
shodan search 'apache port:443'
shodan search 'nginx country:AE'
shodan search 'city:"Dubai" port:554'
shodan search 'http.title:"IP Camera"'
shodan search 'org:"Amazon.com" port:443'
- port: limit results to a service port
- country: filter by country code
- city: filter by city name
- http.title: match the web page title
- org: filter by organization or provider
Quick Example: Inspecting a Web Server
Here’s a simple case. You can use Shodan to identify web servers and their versions.
shodan search 'apache country:AE'
This returns hosts running Apache. From there, you can inspect version numbers and determine whether they are outdated or misconfigured.
4. Find Your Own Public IP
If your goal is to audit your own lab, the first thing you need is your public IP.
curl ifconfig.me
Once you have it, inspect what Shodan knows about that address.
shodan host YOUR_PUBLIC_IP
This is usually much more useful than doing generic searches. It shows what Shodan has seen on your public IP, including open ports and the service banners associated with them.
5. Understanding Host Output
A host result can look noisy at first. The important thing is to break it down as:
- IP address
- Open port
- Service
- Banner or fingerprint
If you see a long list of technologies such as Apache, Nginx, Jetty, Flask, Tomcat, GoAhead, or OpenSSL versions, do not assume they all belong to one clean application stack. Some scans aggregate multiple banners, reverse proxies, or backend services into one messy profile.
6. Identifying IP Cameras in Shodan
Searching the word camera alone returns a lot of junk. A better approach is to look for ports,
titles,
and embedded web servers commonly associated with cameras.
shodan search 'port:554'
shodan search 'http.title:"IP Camera"'
shodan search 'http.title:"Network Camera"'
shodan search 'GoAhead port:80'
Port 554 is especially important because it is commonly used for RTSP, which many IP cameras use
to expose
their video stream.
7. Verifying Whether RTSP Is Protected
An open RTSP port does not automatically mean your feed is public. You still need to test whether it requires authentication.
I used ffmpeg for this because it gives clear output when a stream is reachable, rejected, or
simply using the wrong path.
ffmpeg -rtsp_transport tcp -i 'rtsp://YOUR_PUBLIC_IP:554/PATH' -f null -
Common outcomes:
- 401 Unauthorized - good, authentication is being enforced
- video/stream info appears - bad, the stream is accessible without credentials
- Invalid data found when processing input - usually the wrong RTSP path or a non-RTSP response
One important detail: rtsp://IP:554 often is not enough. Many cameras require a specific path.
8. Common RTSP Path Examples
Different vendors use different URL formats. These are examples of common patterns:
rtsp://YOUR_PUBLIC_IP:554/live
rtsp://YOUR_PUBLIC_IP:554/h264
rtsp://YOUR_PUBLIC_IP:554/stream1
rtsp://YOUR_PUBLIC_IP:554/Streaming/Channels/101
rtsp://YOUR_PUBLIC_IP:554/cam/realmonitor?channel=1&subtype=0
If one path fails with invalid data, that does not prove the stream is safe. It may just mean the endpoint is wrong.
9. Logging In with Valid Credentials
If the stream returns 401 Unauthorized, that is exactly what you want to see when testing without
credentials.
To confirm your own credentials work, include them in the RTSP URL.
ffmpeg -rtsp_transport tcp -i 'rtsp://USERNAME:PASSWORD@YOUR_PUBLIC_IP:554/PATH' -f null -
If the login is accepted, ffmpeg will usually display stream details such as codec information,
resolution,
or frame processing. If credentials are wrong, it should continue rejecting the request.
If your password contains special characters such as @, :, or /,
URL-encode them first.
10. Testing from a VPN vs Testing from the Open Internet
In my case, I tested from outside the local subnet over a VPN. That is useful if your normal path to the camera is through the VPN and you want to validate that workflow. It is not the same thing as verifying whether the service is exposed to the public internet.
If your actual goal is to make sure the stream is not publicly reachable, the most important check is not brute force resistance. It is whether the port is exposed to the internet at all.
nmap -sV -p 554 YOUR_PUBLIC_IP
What you want here is simple: if you do not intend RTSP to be public, the best result is that the port is closed, filtered, or blocked from the WAN entirely.
If you need to inspect packet flow while validating exposure, capture the traffic locally with Wireshark so you can separate a bad RTSP path from an authentication or network policy issue.
11. What Not to Do
There is a big difference between explaining attacker behavior and publishing step-by-step offensive instructions. I am deliberately not including exact brute-force workflows, mass-scanning pipelines, or exploit commands here.
For an informational blog, that is the right line to draw. It is enough to understand that attackers often:
- search for exposed services with Shodan
- test for weak or default credentials
- look for web interfaces or RTSP endpoints
- target old firmware or badly configured admin services
There are many github resources with more in-depth information and search techniques available, such as Shodan Scripts, Awesome Shodan Queries, and Shodan Dorks.
12. Common Misconceptions About Shodan
- An open port means the service is broken. Not necessarily. It may be authenticated and intentionally exposed.
- If Shodan sees it, anyone can use it. Not necessarily. It may require credentials or restrict functionality.
- If RTSP is open, the video feed is public. Not necessarily. You still have to verify authentication.
- One banner equals one clean application stack. Often false. Aggregated results can be messy and misleading.
13. Defensive Checklist for Home Labs
If your goal is to keep a camera or other service private, these are the basics that matter:
- Do not port-forward RTSP unless you truly need it
- Use a VPN for remote access instead of exposing the service directly
- Set a strong unique password
- Change default credentials immediately
- Disable services you do not use
- Keep firmware updated
- Audit your public IP periodically with Shodan and Nmap
14. TL;DR
Shodan is best used as a visibility tool. Start with your own public IP, inspect open ports, identify the
services you actually expose,
and verify whether those services are protected. For cameras, port 554 is only the beginning. The
real question is whether
the RTSP stream is reachable, whether the path is correct, and whether it enforces authentication.
The safest setup is still the simplest one: if you do not intend the stream to be internet reachable, do not expose it to the internet.