What happens to a client on a public network

Windows Firewall
Security
nodeProtect
Azure
May 13, 2020

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 image above shows the standard firewall rules on a Windows 10 client.

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.

The image above shows the custom (any) rule added to allow all inbound traffic.

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.

The image above shows the allowance of RDP (3389) and shows the warning information that explains why this should only be done in a testing environment.

Both clients have the nodeProtect Agent installed in order to collect and analyse network and firewall statistical data.

Scenario

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.

Network Security Group Default Rules.

To simulate a public location, we added a new rule that overrides the default rules, and allows all inbound traffic.

Network Security Group override that 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.

nodeProtect collected statistics

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.

PortProtocolIPsConnectionsComment
3389TCP11090134RDP. 90 134 connections from 110 external sources
137UDP13NetBIOS Name Service. 3 connection from 1 internal (known) source

Now, lets see what happened to the Windows Client that allowed all inbound traffic.

nodeProtect collected statistics when any rule is applied

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.

PortProtocolIPsConnectionsComment
3389TCP11052637RDP. 52 637 connections from 110 external sources.
8ICMP3693942Ping. 3942 connections from 369 external sources.
445TCP2579SMB. 79 connections from 25 external sources.
138UDP19NETBIOS Datagram Service. 9 connections from 1 internal (known) source.
137UDP34NetBIOS Name Service. 4 connection from 1 internal, and 2 external sources.
1900UDP13UPnP Simple Service Discovery Protocol. 3 connections from 1 external source.
5353UDP11Multicast DNS. 1 connection from 1 external source.
123UDP11Network Time Protocol. 1 connetion from 1 external source.

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).

Power BI visual map representing external communications

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.

Port activity from Windows Client that allows RDP traffic.

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:

Port activity from Windows Client that allows any traffic.

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.

NamePercent
8:0:ICMP72.21%
3389:TCP21.53%
445:TCP4.89%
137:UDP0.59%
123:UDP0.2%
138:UDP0.2%
1900:UDP0.2%
5353:UDP0.2%

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:

NamePercent
3389:TCP92.87%
8:0:ICMP6.69%
445:TCP0.14%
138:UDP0.2%
137:UDP0.02%
1900:UDP0.01%
123:UDP0.005%
5353:UDP0.005%

Conclusion

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

//nodeProtect Team

Appendix

Take full control of your systems
need a secure and modern way of managing Windows Firewall?
Discover how your systems are interacting with each other and how you can minimize risk against hackers and ransomware with the help of nodeProtect.
Get Started - It's free
Learn & Get Help
DocsVideo TutorialsBlog
contact@nodeprotect.com
© 2020 addlevel - a part of TRUESEC. All rights reserved.
COOKIE DECLARATION AND SETTINGS