Awareness and understanding of how your systems communicate, both inbound and outbound, is a very important factor to consider when planning your systems and environments. We all know that connecting a system to the internet opens up a lot of communication, but how much actually happens when a system is exposed to the internet and how does it look?
One way of identifying the traffic is by looking at the windows firewall log.
The sample log in the image above is from a domain controller in our test environment. The logfile has about 50 000 rows of collected data and each row tells us where the connection is coming from and what protocol and port is used.
Collecting and parsing statistical data for the the entire environment can be a tedious and time consuming task.
This is where the nodeProtect agent comes into play. The agents capabilities include collecting statistical data from the windows firewall and this is exactly what we need to identify external communication patterns.
Lets dig into the details and see how we can collect firewall statistics in nodeProtect and visualise the data in a Power BI report. Here's what you need:
- A nodeProtect account
- One or more nodeProtect agents installed
- An Azure subscription
- Power BI Desktop
In this scenario we will look at a demo environment in Azure where the Network Security Group (NSG) is configured to allow inbound traffic during the time frame of the demonstration. This helps us understand how much traffic is generated in an unsecured cloud environment and the importance of configuring the Network Security Group in conjunction with the internal Windows Firewalls.
Collecting Firewall Statistics in nodeProtect
Collecting data and statistics in nodeProtect is simple. Start by clicking on the node that you want to perform a statistics job on.
Click on the Jobs tab > Create a new job > Windows Firewall Statistics.
This tells the agent to start collecting statistics from the node. Once the job completes we can view the data in nodeProtect by clicking on the completed job.
The job result gives us insights and information regarding inbound communications to the node during a specific time period. The following columns are displayed:
- Inbound IP - Source systems IP Address. This tells us if the connection is internal or external.
- Process - Target Service or Process for the connection.
- Connection Count - Number of connections during the time period.
- Protocol - Protocol used for the connection.
- Port - Port number.
If we take a closer look at the Inbound IP Addresses from the first entry in the result we can see that the IP Addresses are both internal and external.
Modeling the data from nodeProtect
Presenting findings in Power BI
Before we can present the data in Power BI we need to export and store it in a custom database. We can extract the data using the nodeProtect SDK described in this post:
Next, we can expand our data model and include geographical data based on the external IP Address.
There are a couple of resources available for identifying an IP Addresses geolocation such as ipstack or geolite2. This example is based on geolite2.
The model used in this post includes:
- Nodes - nodeProtect nodes and node metadata.
- Port - Port, Protocol, and number of connections.
- Process - Process name related Service Name.
- SourceIP - Source IP Address.
- ExternalCommunication - Geographical data (City, Country, Longitude, Latitude)
When the tables are populated with the nodes statistical data we can build a visual report in Power BI.
Presenting findings in Power BI
Based on the collected data from nodeProtect we can build reports and visualisations in Power BI. Adding geographical data (City, Country, Longitude, Latitude) enables us to draw up maps that show where the communication is coming from and helps us identify nodes that are open for external communication in an intuitive way. The report in this demonstration contains the following visualisations:
The Power BI report shown below demonstrates the external communication during the time period of the statistical collection jobs. The external communication was allowed during a couple of hours and the findings tell us that a lot of communication occurs when systems are exposed to the internet.
If we focus on the domain controller we see that, during the time the system was exposed to the internet, 215 external inbound connections occurred.
If we dig deeper into the data we can see that port 445 is at the top of the list at 165 external connections followed by port 3389 with 12 external connections.
Based on the findings in this post we can determine that there is a lot of external communication occurring on a server that is exposed to the internet. The first thing to consider is the importance of having a Network Security Group (NSG) in place and correctly configured for cloud environments. On-prem environments need additional appliance and hardware protection to secure the environment from external communications.
However, the security configurations do not stop here. It’s just as important to protect the systems internally, as close to the server/application as possible, and this can be done by using nodeProtects capabilities to manage the Windows Firewall on all your systems, as easy as one.