When working from a public location, such as a mobile broadband, it is important to recognise that there is a possibility that your computer could be exposed to the rest of the internet. This scenario could happen if the mobile broadband gives a public, unfiltered IP Address.
There is a lot of “background noise” out there, consisting of bots that are continuously scanning known vulnerabilities. Some bots try to guess commonly known passwords, some try to exploit security flaws, and some bots scan and collect data about target systems.
To visualise this, and deepen our understanding, we will take a look at what actually happens to misconfigured clients during a period of 3 hours on a public network.
The first client has a standard configured Firewall with the addition of allowing RDP traffic.
The second client is configured to allow all inbound traffic. This is done to simulate what happens if you, for some reason, turn the Firewall off.
Both clients are set up to allow RDP traffic. This is only recommended for testing, and by the end of this post we will see, and understand, why.
Both clients have the nodeProtect Agent installed in order to collect and analyse network and firewall statistical data.
The setup and preparation for this analysis was fairly straightforward. We set up two Windows 10 Clients (1809) and allowed inbound communication in the Network Security Group (NSG) to simulate a public location.
The Network Security Group is an Azure Resource that contains security rules that allow or deny inbound and outbound network traffic. When configured, Azure creates default rules that deny all inbound traffic.
To simulate a public location, we added a new rule that overrides the default rules, and allows all inbound traffic.
We waited for 3 hours and then we performed a nodeProtect Windows Firewall Statistics job to collect the data from the Windows 10 client.
nodeProtect collected statistics
First, lets take a look at the statistics collected by nodeProtect.
The example above shows statistical data from the Windows Client with the default Firewall rules and additional RDP rules. We see that there is a lot of inbound traffic to port 3389 (RDP). We have identified 100 different IP addresses that have tried to connect to the system 90134 times during the time period of 3 hours.
We’ve also identified 3 connections to port 137, but if we look at the IP address, we can see that it is the private IP address of the client and no external communications appeared on this port.
Now, lets see what happened to the Windows Client that allowed all inbound traffic.
The second example shows statistical data from the Windows Client with the firewall configured to allow all inbound traffic. Here we can clearly see that there’s a lot more going on.
nodeProtect external communications visualised in Power BI Map
Next, lets look at some visualisations in Power BI. The Power BI map report only shows systems where we have been able to determine a geographical location, so there might be some minor loss compared to the raw data (If we cant determine an IP address geographical location it does not show up in the map).
We can see that the external communications are coming from all around the world. There’s been a total of 603 connections from 50 different countries against our 2 Windows clients during the time period of 3 hours.
nodeProtect identified port activity visualised in Power BI
The next report demonstrates port activity per Windows Client. The first report shows port activity from the Windows Client with the default firewall rules and additional RDP rules.
Notice that 99.1% of the inbound traffic came from RDP during the time period of 3 hours.
If we look at the Windows Client with the firewall configured to allow all inbound traffic we’ll see more activity going on:
When we look at the communication by connected IP addresses we can determine that the most common activity from unique external sources is ping, at 72%, followed by remote desktop at 21%. We also see activity on port 445 (SMB). The table below is based on the total of 510 source IP addresses.
If we instead look at communication by port (reoccurring communications from IP addresses), we see that there is a lot happening around remote desktop with about 92% of the communications. The table below is based on the total of 56676 communications:
The Windows Firewall plays a big role in protecting your Systems (both Clients and Servers) and it’s important to limit the exposure at the Windows Firewall level.
This test was time boxed to 3 hours, and during this period our clients received over 142 000 communications from external sources.
Misconfigurations in the Windows Firewall not only expose the system at hand but also opens up for lateral movement within your environment: https://www.nodeprotect.com/blog/how-to-prevent-lateral-movement-using-windows-firewall
So how do we avoid misconfigurations, how do we identify systems in our environment that have rules that allow too much, and how do we protect our systems?
We work with these questions on a daily basis, and our recommendation is to start by identifying and analysing your environment, simply put - getting control and understanding how your environment is configured.
We also recommend keeping the Windows Firewall on, at all times, and configuring it using a central process that automatically removes miconfigurations and keeps track of the Windows Firewalls state at a central level.
If you have any questions or want to know more, please feel free to contact us at nodeProtect.
Over and out