Thousands of internet-connected devices and servers are being brought online everyday, many times with little thought to security. The lack of security oversight for these server activations is hugely problematic, but it can be hard to run down reliable industry reports or data that reflect this impact directly. So, I decided to run an experiment to discover the following:

  1. How long does it take from the time you deploy your new application server to when it gets scanned by a potential “bad guy?”
  2. How long does it takes before they start to actually try to break in?

Methodology

To get a general idea if our data changed depending on region, I deployed multiple servers in different locations around the world. I used Amazon Web Services for my experiment, so the countries were selected from regions they offer. These virtual machines made use of software that enabled them to behave as a “honeypot”, pretending to be a vulnerable database, mail or web server. Once I had my virtual servers built, I sat back, waited, and tabulated the results.

What is a Honeypot?

A honeypot is a computer or virtual machine that is configured to behave as a decoy. This system emulates commonly used server applications (Internet Information Server, Apache, SQL Server, etc.) and vulnerabilities within these applications to lure cyber-attackers into attempting to break in. When attacked, the honeypot’s system allows for the monitoring and study of the attempts to penetrate the system. I selected KFSenser from KeyFocus as my honeypot solution. KFSensor provided a free trial for the experiment and comes with simulated server profiles that matched the targets I wanted to emulate. This included profiles for database, mail, proxy and web servers, allowing us to collect data based upon some of the most commonly seen and attacked server types. It also has an easy to use interface, and generates easy to read results.

How long before I become a target?

I defined becoming a “target” as the moment my IP was scanned and a potential vulnerability was identified. I wanted my experiment to be relatively generic, so I ran multiple different services on our target machines and logged the first real scan that probed a viable application.

The results speak for themselves. Across all the regions I tested, it took an average of 7 minutes and 48 seconds before my virtual machines were scanned for vulnerabilities. In some regions, this number was a lot smaller with evidence of quicker identification popping up in all the regions. One server was scanned before I even had time to finish setting up the machine! Hackers, security researchers, automated crawlers, and the occasional curious college student will find your IP and know of any potential vulnerabilities very shortly after you decide to allow them access to your website or server.

How long before they attack?

While my findings for how long it takes to be scanned are certainly shocking, those are still just arbitrary scans. Getting scanned in a massive automated Internet sweep doesn’t mean you are being attacked. In fact, some of those scans are most likely just other security researchers and white hats trying to help identify sick servers. So, if those scans are not necessarily the potential bad guys, how long does it take before a black hat actually shows up and starts poking around?

For these results, I defined an “attack” as any series of requests that tried to make use of the application in an unauthorized manner. This could be trying to guess the system administrator password on a SQL server, using my fake proxy to route unauthorized web requests, or browsing about the web server trying to find potential default vulnerabilities. I considered the moment we were first scanned in our previous results as our “zero” mark, and track the time until attacks begin from there.

On average, across all the regions I tested, we were attacked right before the 20 minute mark. There was some pretty significant variation with these results, with some servers getting hit almost immediately after being scanned, while others took up to an hour or more. In one example, the attack appeared to be a part of the initial scan (or they didn’t bother to scan to begin with). There isn’t enough data in our sample to determine if one region outperforms the others, and that does not appear to matter to much overall. Regardless of the region and the service I was emulating, all the servers were attacked within 2 hours of coming online. It is very important to keep in mind that most, if not all of these attacks are automated. Just like the scans, they are sweeping each target they find one at a time, and making note of everything they find for use later. These automated attacks will undoubtedly occur regardless of any vulnerabilities present on your system, so if you are not prepared for it, you will eventually suffer a breach.

The Takeaway: Do not go online until you are truly, truly ready!

Security cannot be an afterthought. If you are not properly patching, hardening, and auditing your servers, you will eventually regret it. Your servers will get probed and you will get attacked, there is no hiding.

Based upon the traffic seen in just this simple experiment, you can expect automated attacks to begin occurring on your vulnerable servers within a few minutes to just a couple of hours of their coming online.

As part of your deployment, provide for the penetration testing of your servers and application before you expose them to the Internet. Confirm your server software is up to date. Only run services on this server that deliver your application, and prevent traffic to any other port except the ones you need. These are the low hanging fruit that none of us should leave dangling. These forgotten and exposed services, temporary development configurations, and easy to resolve vulnerabilities you should have patched before, they will come back to haunt you.

New exploits and vulnerabilities are cropping up every day. The only truly secure network device is disconnected from the network (and buried in cement). You can make sure you are not an easy target though.

Since 1994, Joshua Hiller has been a professional software developer and security analyst, working as a private contractor, team member, and team leader. Specializing in automation, integration, penetration auditing and forensics, Josh has over 15 years experience working in the non-profit industry in roles such as application developer, department director, and vice president.

A married father of three girls, Josh’s interests include; art, comic books, fantasy, science (and science fiction), application and network security, software development and tropical fish. His favorite type of cichlid is Astronotus ocellatus (Oscar), followed closely by Andinoacara rivulatus (Green Terror). If left alone for long periods of time around new software or technology, Josh is highly likely to take it apart to try and figure out how it works. At random, infrequent intervals, Josh likes to create games out of interesting puzzles he’s encountered.

Since 1994, Joshua Hiller has been a professional software developer and security analyst, working as a private contractor, team member, and team leader. Specializing in automation, integration, penetration auditing and forensics, Josh has over 15 years experience working in the non-profit industry in roles such as application developer, department director, and vice president. A married father of three girls, Josh’s interests include; art, comic books, fantasy, science (and science fiction), application and network security, software development and tropical fish. His favorite type of cichlid is Astronotus ocellatus (Oscar), followed closely by Andinoacara rivulatus (Green Terror). If left alone for long periods of time around new software or technology, Josh is highly likely to take it apart to try and figure out how it works. At random, infrequent intervals, Josh likes to create games out of interesting puzzles he’s encountered.

There's More To Discover

Subscribe today for more thought-provoking content.
  • This field is for validation purposes and should be left unchanged.