To Centralize or Not To Centralize

In my last post I discussed how Windows Filtering Platform auditing can generate the necessary log records for creating outbound rule sets, continuing my theme of applying outbound restrictions to specific applications that are abused to bypass mitigations such as pre-defined application allow lists. With this audit configuration, along with a rule set that defaults to allow and doesn't have any block entries, machines can run for a while to start generating a list of IP addresses to allow.

While that is simmering on the back burner now is a good time to think about how we would like to deploy should we choose to accept this mission (how's that for mixing metaphors?). There are two methods that I am aware of that this can be configured.

1. Local workstation policy
2. Group Policy

I think that there are benefits and disadvantages to both approaches, so they are both worth some consideration. I have yet to run into any feature differences when deploying it GPO vs. locally (or vice-versa), but I do think that there are some tactical advantages to using GPOs. If GPOs aren't available to you (for example, home/standalone computers or a workgroup) then a local configuration still provides benefit beyond having nothing at all.

Local Policy

This is where I started getting my feet wet when working with Windows Firewall with Advanced Security. The biggest benefit to me at the time was that if I misconfigured something it only affected my test device and I had direct access to the machine to undo any changes. It allowed me to experiment and verify rules worked as expected while getting comfortable with the options and interface.

The local firewall policy can be configured using the MMC console. This can be opened in several ways, here are two:

1. Control Panel > System and Security > Windows Firewall > Advanced Settings
2. MMC Console > File - Add/Remove Snap-in... > Windows Firewall with Advanced Security - Add > Local Computer - Finish.

(Note: depending on the settings on your computer, these will only work if you have access to a local administrator account and/or with UAC elevation.)

Once the GUI is open we have the ability to add or remove rules that affect the local computer. If necessary the policy can be created and then exported, allowing us to import it on another computer or back it up in case it needs to be restored.

Group Policy

The GPO configuration can be managed with the Group Policy Management utility. A new group policy has to be created or an existing one edited. Right click the policy to be modified, and then navigate to Computer Configuration > Policies > Windows Settings > Security Settings > Windows Firewall with Advanced Security. This GUI is very similar to the local configuration.

When making GPOs it can be helpful to create multiple firewall specific GPOs that have similar rule sets depending on the security requirements of the machines that they are applied to. These can then be selectivly applied using WMI filters or security filters, but this won't work in some environments so YMMV.

Pros and Cons
Choosing which method (or even a combination of the two) to deploy depends on the needs of the environment. It is possible to use Local or GPO, as well as GPO with a merge of a local policy. I can't think of a scenario where I would ever want to use the merge option - I usually disable that capability by removing the selection for "Allow local firewall rules". (This can be found by selecting a profile in a GPO configuration, selecting "Customize...", and under "Rule merging" setting "Apply local firewall rules" to "No").

So which one works best in a corporate environment? I think that local policies carry some very substantial risks.

1. If malicious code executes on a machine and is able to obtain admin privileges it can create policy rules allowing the traffic out or turning the firewall off and bypassing restrictions. 
2. Local policies can also be changed by local administrators, allowing them to turn it on or off or add/remove rules which can quickly lead to configuration drift. 
3. A lot of programs will also create very liberal outbound policies when they are installed. 

When all of these are combined the result is an unpredictable and difficult to manage firewall configuration that I wouldn't recommend in a corporate environment.

That said, there are two critical cons to using GPOs that must be considered and mitigated appropriately if this deployment method is used.

1. If it is misconfigured, outbound GPOs can prevent machines from receiving future GPOs and prevent them from communicating with critical services. This is probably the largest deterrent to using this technology and would probably be a resume generating event in most environments. It is why I spent so much time focusing on the block list capabilities with inverse ranges that I talked about in a previous post.
2. There is a psuedo-random delay (sometimes up to several hours) between when a change is made to the policy and when it takes affect on an endpoint. This could be a problem if something needed to be rolled out rapidly.

If appropriately configured (not allowing local rule merging) and tested, a GPO can be much more difficult to bypass or disable and can be implemented safely and effectively. This raises the difficulty and cost for attackers, forcing them to abandon many of the mechanisms that are used with malware today.

That said, if admin rights are obtained it could be possible to disable the firewall regardless of the chosen deployment method. At that point it would also be possible (and maybe easier) to just overwrite or attack a permitted application than trying to disable the firewall.

A lot of this hinges on obtaining local admin rights. If end users are browsing the internet and using office productivity applications with local admin privileges there are many options for getting around this (and many other) controls regardless of how they are applied. It is also important to apply security patches in a timely manner to limit the ability of code to elevate privileges using exploits. Windows Firewall with Advanced Security outbound controls can only work if they are a part of a larger ecosystem of controls that work in concert. I believe these outbound controls (or any endpoint firewall with this type of capability) are a critical part of the ecosystem, but can't stand without it.

Regardless of which method is chosen for deployment, PowerShell is has been my friend. Both local and group policies can be directly created, viewed, edited, and deleted with PowerShell. This allows routine tasks to be saved as scripts (for example, modifying the destination IP allowed list to accomodate for a previously unseen destination or removing a destination IP that is no longer necessary). Large lists of IP addresses can be maintaned as files and then imported with PowerShell and applied to the appropriate policy, saving time and difficulty navigating these in the GUI.

I plan to cover PowerShell specifics in a future post - it has saved me an immense amount of time and allowed me to scale and deploy this as a mitigation tool where it otherwise wouldn't have been practical.

Until then, work hard and spend time with your family.
Branden
@limpidweb

Audit Logs, XML Filters, and PowerShell, Oh My!

My last post documented the big breakthrough for me - being able to limit internet access for a few specific programs that had little business accessing the internet and were being abused by malware, pen testers, and researchers alike. Now I had a flexible tool that I could use to greatly limit this abuse.

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?

My heart sank. There is some useful information in this log, but the application entry was missing! The key feature that drove me to use this tool was the fact that it could be configured to control application access to IP addresses. In order to effectively do that without the rollout becoming a resume generating event I needed a candidate configuration that allowed everything, but logged it, so I could create a baseline; and this wasn't going to let me do that. The other piece of information that this was missing was the rule that it matched against. Lots of data, but nothing to see here. I disabled this log and moved on.

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:
Local Security Policy\Security Settings\Advanced Audit Policy Configuration\System Audit Policies - Local Group Policy Object\Object Access
GPO:
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 ID Edit 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
• Direction
• Source Address/Port
• Destination Address/Port
• Protocol
• 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 the username from the credentials used to launch a process along with the process name and path is a dream come true and provides valuable troubleshooting and forensics data that can be analyzed and consumed later.

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.

Branden
@limpidweb