Welcome to the CloudPassage Halo for Windows Firewall Overview. In this 5 min video you will learn how to set up a host-based Windows firewall policy in the CloudPassage interface. You will also see how to apply the policy to a group of servers.
From your dashboard, click on “Firewall Policies” in the “Policies” menu.
I’d like to add a new firewall policy to protect my Windows web servers, so I’m going to click Add New Windows Firewall Policy.
The CloudPassage firewall interface allows you to easily configure host-based firewall rules on your servers. I’ll show you how to apply this policy to your servers later. (Write a name and description)
So first I’m going to set up RDP access to my servers, but I just want to limit it to a range of IPs. First, I’ll select a permitted source – I’m going to limit RDP access to an ip range in a second – and selecting RDP from the drop-down service menu. To create an IP zone, click the “Source” drop down menu in a rule, scroll to the IP Zones section, and click “Add New”. You can create an IPzone using a IP addresses and CIDR subnets. We provide a Subnet Mask Calculator for your convenience. After click “Create”, I can re-use this IPzone across policies.
Now I want to quickly set up some rules for my web application. To add new rules, click the green button to the right; to delete them, click the red X. Once again, select a source and service from the drop-down menus on this screen to set up your firewall rule.
My web servers also need to communicate with Windows Patching Servers, so I’ll need to create an outbound rule to allow that (Outbound 80 / 443 Windows Patching Servers)
I would like to log accepted connections as well, so I’ll check the box up top to enable logging – logs will go to the default location on your Windows Directory (likely WindowsSystem32LogFilesFirewallpfirewall.log)
Finally, I need to set the default posture for the inbound and outbound rule sets – that is, what do i want my fw to do when traffic does not match any of my fw rules? I’m going to “block traffic” – if you’re familiar with Linux IP tables, this is the Windows equivalent of a “Deny All” rule.
Now I’m happy with my policy. To review, this policy allows servers to receive and respond to inbound RDP traffic (via port 3389, only from a specified IP zone) and web traffic (via ports 80 and 443). All other inbound connection attempts will be dropped. Servers can also initiate outbound connections to update servers. All other outbound connection attempts will be dropped. Click save to save your firewall policy.
If you ever want to see the Network Services and IP Zones available in those drop down menus, you can get to any of those through these links above the policy list.
Click on “Servers” to return to your dashboard. I would like to apply this new firewall policy to a server group I created earlier for my Windows web servers. I’ll just click “Edit Details”, set my firewall policy, and save. This is the point where Halo takes over your firewall configuration – the Halo daemon will automatically activate your host-based firewall if it is not already running. Existing rules will be deleted, so if you have existing firewall rules, you should add those to the Halo firewall policy before you apply it.
As always, we recommend experimenting on non-production systems.
The policy will then be applied to all servers in this group. It may take a minute or two before the change is implemented and the firewall status icons reflect the new firewall configuration on your servers.
Once the Firewall Status displays as “Active”, you know that your servers’ firewalls are configured.
Any new server that is put in that web server’s group automatically takes on the firewall policy assigned to the group. For example, the server named WindowsServer4 is currently in a group with no firewall policy assigned to it. I’m going to move it to the web servers group, and in a few minutes the firewall policy will be applied automatically.