Blocking Shodan Part 2 | Automating the process for beyond 2017

Previously in my post blocking shodan I wrote about how to bait shodan to scan your infratructure to assist in identifying their IP addresses and mapping out their scanning network. While this was useful it lacked the ability to be automated and a central block list and required me to update the site all the time to keep it current. This is not ideal.

Seeing this as a interesting challange I have created two tools for dealing with Shodan that are at the bottom of the article skip down there for the code. For some more background I wanted to include the reason for the release.

I was on the fence about posting a tool that allows for the detection and automated blocking of Shodan servers as it allows admins to stick their heads in the sand when it comes to securing their infrastructure. However while attending Blackhat 2017 I saw the following slide that changed my opinion.

While this was not my favorite slide from Blackhat/Defcon I feel it may represent the average use of shodan today. I am not trying to paint it their userbase in a negative light. So there came the problem. How do I block the abusive bottom half while leaving the top half useable.

To understand how we can block just the bad users lets look at how the shodan scan process works and how their scanners are divided up.

From what I have seen coming from IP addresses I was able to associate with Shodan I have determined there are 3 different types of scanners.

Shodan Crawler – These crawl the web constantly and are usually identified by the DNS addreses. These are not used when a user initates a scan and are simply there to add to a rolling index. The scan rate varies on how often you are hit by them.
On Demand Scanners – These are utilized when a user iniates a on demand scan using the CLI provided by shodan. These IPs seem to be the number one complaint by orginizations who get scanned daily.  Often harder to identify due to the DNS names.
Project Servers – To the best of my understanding these are servers that look for specific ports / products such as webcams, ICS, or may even be contracted out. DNS names are often the project SMB, Battery, RIM, Malware, etc.

So it occured to me that you could simply just block the on demand servers and that would not be too hard to do. So I came up with SIBL (located at the bottom of the article) and this is how I bait shodan into scanning my VPS hosts to expose all their scanners:

Using this method I am able to capture the IP address that is from their scanners, log it, and then add it to a block list. What is interesting is that if you block Shodan using this method the next time a scan is iniated it will fail to scan. Now on the third scan thats when things get interesting, shodan will provide a new server since you have blocked the old one. Repeating this method can assist in building a up to date list.

You can only initate a scan on a host once every few hours so I reccomend setting a cron job to run every 4 hours plus a random delay or run as often as you need or your credits allow. When using this across mutiple a array of multiple VPS instances you can enumerate a list of all of their IP addresses in a realtivley short period of time.

Using SIBL will allow you to block the bottom half of that netsec triangle and create a list of known Scanning Servers. To ensure the test is accurate tcp dump only runs for the period while the shodan scan takes place. While this does not gaurentee a Chineese bot will not scan you within the 60 seconds the job is running its considered acceptiable losses since we can verify the shodan servers by DNS and by using Shodan.

You can download SIBL from github – Shodan IP Block List
Additional information how it works can be found on the github.

I am also annoucing my own rolling blockist in a text format that people will be able to pull to their VPS using curl or wget. This way if you dont want to sun SIBL you can just get a raw text copy of the latest servers.

The block list will be located here in the next few days:
Please do not configure your jobs to pull the list every minuite of every day, it will only be updated every 12 hours.

I will be automating the updating of this list using my own scanners and it will not include community contributions only the servers I have verified myself.

4 thoughts on “Blocking Shodan Part 2 | Automating the process for beyond 2017”

  1. I agree with most of what the authors views. My personal view on Shodan and other non-solicited scans are a bit harsher however. After 20+ years in Infosec I am about to loose my patience with the ineptitude of these scripters who think filling IPS and firewall logs with a ton of drops are somehow making the internet safer. Qualys and such, although solicited have become reliant on all things automated. The value in these scans, I think occasionally or when major code is changed are warranted if a client decides to employee them. Otherwise they are simply causing false alerts and diverting security Engineering’s time and effort thus making the problem of securing a network much more difficult. Countless times I have blocked some A-hole company that auto scripts intensive scans almost non-stop. The result is seldom appreciated, the scanning companies see actualy stopping detected events as intrusive to their business model. They play the card of “were here to help” but they are interfering with actual information security management to a level and volume they are just as noisy and obvious as any hacker. Bringing me to my second statement, “hacking isn’t hard, getting away with it is the hard part.” If you set off alarms at 4 AM and a security professional black list your IP you have failed! So I say leave the scanning to those that know what they are looking at and let pro-active security take it’s rightful place on the internet. I can NMAP myself all day long and send the output to whoever I want, does that make any one more secure? F*&# no! IMHO

  2. This is some great work. I have a suggestion reference your comment about sysadmins sticking their heads in the sand. When setting up the block list for the Shodan IP’s/Domains, ensure you log and not just drop the traffic. Feed those logs to the security team as a threat intel feed for the port data. This may give the team an idea about what services/applications attackers are looking for at your organization and/or may be an indicator that there is a new vulnerability or exploit. They could then follow that up by checking other source for information or the relevant service/port and might help prioritize patching efforts.

    1. This is a great idea; I had not thought of that it would provide a lot more insight!
      Unfortunately due to the increasing use of other scanning services and self hosted scanning I find blocking shodan is not enough.

Leave a Reply

Your email address will not be published. Required fields are marked *