Monday, December 19, 2016

What It Isn't

It has been over a month since my last post - life has been very busy at work and at home! I still have 3 posts left on my Windows Firewall with Advanced Security to-do list, and a building list of posts about Windows Event Forwarding, or "How I learned to stop worrying and love endpoint logs". So, with that said, let's chip off another topic from my WFwAS list.

I have hinted at this a few times through several posts, but there are several things that Windows Firewall with Advanced Security doesn't do well. Let's face it - the technology is more or less 10 years old. Aside from the ability to tie traffic to a specific application (which is a big deal by the way, in case you haven't read my other posts) it is essentially a basic layer 4 firewall. There are some significant scenarios where WFwAS starts to show its age. It is still useful, applicable, and with the right tools to assist even manageable. But there are a few limitations that have to be worked around if it is going to be used successfully. Here are a few specifics, in no particular order, of things that it doesn't do well.

1. When writing rules there are often limitations encountered when needing to allow or block CDNs with huge swaths of IP space. The internet started using DNS oh, something like 1984 - a mere 32 years ago. Why? Because IP addresses don't scale!

Yet this firewall, sitting there humming away happily next to the DNS resolver client behaves in a very anti social manner and instead of asking a few simple questions that the DNS resolver would be happy to answer it goes on its own and instead is based simply off of IP address ranges.
     I'm not bitter - not at all.
Don't even get me started on IPv6. Pity the poor being that has to use this to limit access to IP6 and the think of the massive amounts of electrons that would have to be inconvenienced to make it happen. Or not - because even though it can be used with IPv6, I doubt it is very much.

Because of DNS, resource to IP addresses mapping can be umm, dynamic. They can change quickly, they can be load balanced, etc. Static lists of IPs don't always map to a resource I want to allow or deny and if it does now, it might not later, and then might all over again.

Network firewall vendors have heard this loud and clear from their customers and adapted to stay relevant, but WFwAS hasn't. Something like PowerShell can be used to create more dynamic lists that are then imported into the configuration (a topic for a future post), and the firewall itself seems to handle very large lists with ease, but this is bolting on a compensation and can be clunky.

Mitigating control: Use a web proxy or more advanced edge firewall to assist with this where it can.

2. Applications with dynamic names are difficult to manage. Applications have to be explicitly defined, there are no options for wildcards in the path. This makes it difficult to write rules for applications that might need to be allowed, like notorious collaboration "meeting go to" apps or "web ex perience" executables that are saved to temp folders with seemingly random executable names connecting to seemingly random IP addresses. Either a full firewall whitelist has to be implemented, denying anything unknown (which can be a management headache); or a blacklist has to be configured and any unknown application has to be allowed.

Mitigating control: Use application controls (such as AppLocker or better, Device Guard or a 3rd party app white listing tool if you have it available) to limit what applications can be run on a system and use WFwAS to mitigate the most commonly allowed and abused apps.

3. Some applications seem to use addresses scattered all over the entirety of the IPv4 address space! For example, web browsers and HTML email clients connect to seemingly random IP addresses all day long. This is related to item #1. I wouldn't recommend limiting these applications with WFwAS in any but the most restrictive environments, and even then they are probably sufficiently covered by egress whitelists at the network edge.

Mitigating control: Allow any destination IP for apps that are required to interact with the internet as part of their primary functionality. WFwAS can be used to control the ports that these apps have access to, but I wouldn't recommend anything beyond that. Rely on other defenses to help you here.

4. What if there was this scenario where someone could use crazy archaic technology X [such as - oh I don't know - using something like PowerShell to instantiate a COM call to IE to masquerade as an application allowed to get to any IP to do my CnC] to skirt through your App Whitelisting and Endpoint Firewall all in one fell swoop? Ha! All your base are belong to us!

Mitigating control: Don't allow COM capable apps outside of your internal IP range. Like Internet Explorer. Seriously - use a different browser for web browsing. That said, I understand that a stunt like enforcing this policy would raise a few eyebrows at a corporate scrum or change control meeting. I am still investigating other ways to interrupt COM calls where they are not needed, but haven't found anything magical yet. If anyone has, I would love to hear it.

All these things said I still think that this is an effective control that I have been able to demonstrate in a lab and production environments stops malware and malicious activity that few other tools can. This control doesn't function as a "silver bullet" to solve almost all security needs. It solves one or two things very well, but must exist in an ecosystem of other tools to provide a layered approach of security.

I hope to discuss some of these mitigating controls much more in depth in a future post.

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

No comments:

Post a Comment