It is undeniable if you read the news these days – many enterprises are moving data centers applications to the public cloud. In my experience, many security organizations aren’t prepared for the fundamental shift in security models that comes with the cloud. They may opt to build a WAN into the cloud provider to extend their existing and traditional security controls. They may opt for a premium cloud service provider that offers managed security services. Or, they may run software based network function virtualization such as Cisco’s Nexus 1000V. The reality is, with this movement comes a new paradigm in perimeter security. Major cloud providers leave network security to the Enterprise and don’t offer any more capability than security groups or SLB endpoints.
A natural progression of perimeter security is moving all of the security back to the host operating system. However, there isn’t feature parity from hardware based appliances used in traditional data centers to software applications use din the cloud. For example, line rate filtering isn’t a reality on software functions and, when done in software, packet filtering is competing for the same CPU cycles as the application itself.
What surprised me is how little information there is on the Internet about one of these software security functions – Windows Firewall Performance – virtually none. So, I took the time recently to do performance testing myself.
The testing I performed was on a Windows Server 2012 R2 guest running within Hyper-V 2012 R2 host. This is a common virtualization option for many enterprise organizations. The NIC was a 10G NIC with no SR-IOV support, however, most of the testing I did was from VM to VM within the same host. In order to test the “minimum expected performance”, I used a guest with a single 2.27Ghz core and 2GB ram. While most host firewall configurations will have approximately 20-40 firewall rules, I tested in various increments up to 1000 rules. All firewall rules were inbound rules – no outbound rules were set. It’s worth calling out that firewall is probably a loose term in this case. Perhaps packet filter is better.
I did various test with both the IPERF suite, IXIA traffic generator and IIS and home grown scripts with IIS. All results were really the same from scenario to scenario.
Here is a summary of some of my observations:
Windows firewall has very little, if any, noticeable impact on packet processing
The number of firewall rules did not directly impact connection RTT
The number of firewall rules had a slight impact on total throughput
Individual simple firewall rules consume about 12kbytes of memory each
Full firewall logging had an approximate 5-8% impact on increased CPU utilization
In my first test, I initiated a number of TCP connections using a variable number of threads and connection attempts per thread and match/accept placement at various places in the firewall policy. The X axis in this example is match placement within the firewall policy. Each line represents a different number of threads and connection attempts per the legend.
In my second test, I did essentially the same tests as the first test, but with full HTTP transactions for a single web page. Again, X axis is where the policy matched and the lines represents various thread/transaction rates.
In my third test, I measured the impact of logging enabled and disabled at the same thread and transaction rate but the firewall match at different places within the policy. As you can see, there was a pretty predictable CPU % impact (about 5-8%) by enabling logging.
In my fourth test, I measured the total throughput impact of matching traffic at different places in the firewall policy. This was pure bit-blasting from VM to VM. As you can see, there is a minor, but measurable, CPU and throughput impact by matching traffic at different places in the firewall policy. The lines are different in this example. The BLUE line is throughput and the RED line is CPU impact.
My fourth test was simply to measure memory consumption of the firewall by loading large amounts of firewall rules. In this scenario, they were simply port based match accepts with no subnets configured.
All in all, Windows Firewall performed well. I noted a number of other observations (limitations?) throughout my testing as noted below:
Windows firewall filters do not apply to traffic forwarding through Windows when Windows firewall is in “LAN routing” (aka forwarding) mode
Performance is not necessarily predictive as there is resource contention for many different operating system functions – leads to some variability in results
At least 10,000 transactions were needed to reduce some of the variability and smooth out average transaction times
Each firewall log packet is ~70 bytes. 32meg maximum log size = 400,000ish logs
The reality is – Windows Firewall performance impact is negligible. However, Windows can’t perform packet processing at line rate as shown in #4. So, Windows Firewall can provide good packet filtering capabilities, but it can not protect a site from a large scale DDoS attack.