Now what do I do with it?
Initially I thought it would be sufficient to allow all inside network access for the applications that I chose to limit and then just allow internet access as needed. I had a policy ready to go that would enforce this, but after some initial testing I learned that there was more activity by these applications than I initially thought. To deploy this it would be critical to log connections in the production environment and collect the information needed to make informed baselines before enforcing any application specific rules.
Easy enough, there was a place in the policy configuration where I could set up a log file which would output to a simple text file.
Looks pretty straight forward. Once the configuration was enabled I browsed to the log file to see what I had to work with. Here is a sample:
|What's missing here?|
After some time searching I found something that had potential: Windows Filtering Platform Auditing. Windows Filtering Platform is a set of services and an API in the Windows OS that allows traffic to be filtered. It is the underlying set of features that Windows Firewall with Advanced Security runs on top of. (For more, see MSDN) Auditing can be enabled by a policy located in the following areas:
Local Security Policy\Security Settings\Advanced Audit Policy Configuration\System Audit Policies - Local Group Policy Object\Object Access
Computer Configuration\Policies\Windows Settings\Security Settings\Advanced Audit Policy Configuration\Audit Policies\Object Access
In these audit policies there is a subcategory for Audit Filtering Platform Connection. If Success and Failure are configured for this subcategory an event will be created in the system Security log with information about both blocked (event ID 5157) and allowed (event ID 5156) connections. These logs are much more detailed, including the following information:
Source User IDEdit 5/9/2017: After additional research I have learned that the source user ID is not in these logs. :-(
- Process ID
- Application Name and Path
- Source Address/Port
- Destination Address/Port
- Filter Run-Time ID (rule ID match)
...and a handful of other pieces of information. Having this information allows us to create a policy that allows all connections but audits them. We can then go through the audit logs and use them to determine a baseline to use when creating our application rules - of course only after thoroughly vetting the source application and every destination IP... right?
These logs have the type of information I was only able to dream about when working with network firewalls - with those I could trace traffic back to a machine and make a good guess at which user it was from but that was about the limit of what I could do. Seeing these logs take
Now that we have the data we need, how do we make use of it? On a single computer this is pretty straight forward. These audit settings generate a large volume of events (size log files for retention appropriately), but can be quickly filtered in or out of the event viewer console with the basic filter or with the XML filters.
For example, if you can find a sample event for an application you would like to write a rule for, an XML filter can be used to limit the packets to just what matches one or a few fields. Here is part of the XML view of an event where chrome.exe is connecting to www.google.com over port 443:
|This can be obtained by opening the event in the Security event log, selecting the Details tab, and then selecting the "XML View" radio button.|
The fields that are shown can be used in the XML filter to get only the specific log entries we might be looking for, even allowing us to use things like =, !=, multiple matches with AND/OR, etc. (see this TechNet blog for more info). I have been able to use up to 7 conditions to narrow down what I was looking for. (As a side note, more than 7 conditions seems to cause the filter to start behaving unexpectedly, but I can't find any information on why that is. If anyone knows why I would be very interested in hearing it.)
But let's not stop there! GUIs don't scale well. Let's imagine we would like to automate this process and have it generate some interesting data for us across thousands of machines so that we could build a GPO and have the confidence to enforce it! I ♥ PowerShell for this - "Get-WinEvent" with the "FilterXPath" switch allows us to write this all in a script to generate a match and then output it to a file for later consumption. If we use an event centralizing technology like Windows Event Forwarding then we have all of these logs in one place and the tools to make them useful! If we have access to a SIEM or logging platform that can take the logging hit, we have a recipe for large scale success.
Hopefully more on Get-WinEvent, WEF, and maybe event ELK in the next couple of posts.
Until then, work hard and spend time with your family.