Is it really bad to expose your infrastructure to the Internet?

Probably you heard a phrase “Don’t expose your server to Internet!” and some even used that to tell others what they should not do. And we all understand that it is something bad and all industry standards are against that. 

However, during my conversations with some project teams I heard questions “What is going to happen? Bad guys are not aware that my server is being exposed”. And since it is a logical argument, it can be quite hard to fight it. 

So, I decided to perform an experiment and create server with management port (SSH) exposed to internet and storage account with Public access enabled. And I’m going to observe how many authentication attempts/scan activities are going to happen. 

First, we need to create required resources with “not proper settings”. 

VM with exposed management port

Next, we need to configure required logging to be sent to Log Analytics Workspace (which you need to create first, free tier should be enough for our exercise). In logs we are interested in anything related to authentication. In case of VM we can get that from syslog, and for storage account we need to configure diagnostic settings

Now we just need to wait a bit to see the results.

Storage account

Looking into storage account was something really interesting for me, especially after BlueBleed. And if I look into authentication something is really happening. Especially considering that I just created this storage account and didn’t touch it since creation.

But we need to look deeper to see what is going on. In my situation I just created one container names “docs” (and $logs was created automatically), but I’m curious about what was actually accessed.

As you can see, connections to containers “docs” and “$logs” were happening, but also there were attempts to read data from $blobchangefeed(created if Data Protection was enabled) and $purview(used by Azure Purview).

But even more interesting thing is that connection attempts started to happen on the same day as I created this storage account.

Interesting? Now let’s move to our VM.

Virtual Machine

With VM I just created it today couple of hours ago, but it should be enough.

First, I’m quite curious to see if there are any connection attempts.

No surprise there are quite a few. But what exactly is happening? After checking I saw a few events like this:

After exporting data I got a list of usernames that were used during authentication attempts.


As you also noticed, connections were happening from different IPs. Using external data I tried to find out countries of origin for these attempts.

let CIDRRanges = (externaldata (CIDRCountry:string, CIDR:string, CIDRCountryName:string, CIDRContinent:string, CIDRContinentName:string, CIDRSource:string) [''] with (ignoreFirstRecord=true));
| where Facility contains "auth"
| extend IPaddr = extract("(([0-9]{1,3})\\.([0-9]{1,3})\\.([0-9]{1,3})\\.(([0-9]{1,3})))",1,SyslogMessage)
| evaluate ipv4_lookup(CIDRRanges, IPaddr, CIDR, return_unmatched=true)
//| join kind=leftouter (Syslog) on IPaddr
| summarize count() by CIDRCountryName

So, it is safe to assume that connection attempts are happening from everywhere. And by nature of them these are automated scans.


This amount of connection attempts is something expected, because most “hacking” activities are now automated and someone needs to be very interested in you to perform actual attack. Difference in numbers between connections to VM and storage account probably can be explained by attacks on storage accounts being more recent and not so widely automated.

This simulation confirmed several points (and now I have actual data to use in my arguments): 

  • Exposed infrastructure going to be scanned almost immediately. That is why it is crucial to know what exactly are you going to expose and understand the risks.
  • If you need to expose something for various reasons, you must use strong authentication methods or other ways to mitigate the risk. 
  • You cannot tell that attacks are happening from some specific countries. There are some “usual suspects”, but connection can happen from everywhere. 
  • Industry standards and recommendations are not something made up just for fun, so please use them.