Since we explained in this article how to create generic security policies/firewall rules, we want to use this article here to provide you some helpful insight and tips and tricks regarding setting up the perfect firewall strategy to keep you and your customers protected!
1. Top to Bottom!
Security policies, or policies in general on our security gateway portfolio, run in a cyclic fashion, meaning the first rule is applied, followed be the second etc.
This allows for an easy and logic insight onto the security policies once you see the policy table.
At the very bottom, you can see a default rule, which by default denies basically everything. So this means that all traffic is blocked, unless an exceptation is defined above this default rule. By Default, we have plenty of rules already preconfigured to ensure smooth communication from internel networks, but still offering a good set of protection.
2. Table sorting and Filtering
Overwhelmed by the sheer amount of Policy rules you set up, and searching for a very specific rule? No worries, wie the filter categories you can easily find the rule you are searching for (or finding out, that the rule is missing) at one glance. For this, press the "Show Filter" at the very top of the policy control menu - this will collapse the filter menu:
In the filter menu, you can now search for rules which match the parameters you have defined above. In the above example, we want to find out if we have any rules which define WAN access to our device (the ZyWall) on Port 443. Since we added 443 to the Service Object-Group "Default_Allow_WAN_to_ZyWall", wen can see all rules which follow these parameters. Taking a deeper look, we can see that we actually allowed 443 from the WAN - it is now on us to decide whether or not this is desired or deemed a security issue, which we want to resolve. But this example shows the power of quick filtering.
3. Make your life easier, use Zones!
Normally, access control lists, or firewall rules, or in our case, security policies, are defined via the IP source and destination addresses, in combination with other factors such as ports etc.
But, imagine you have five networks with scattered subnets, and you want to allow the access between all of them to each other. With a generic, stiff firewall setup, you would be left with creating 5 rules for the first network, 4 remaining for the next subnet, 3 for the third subnet, 2 for the fourth subnet and another rule for the fifth subnet to cover every single possible setup. That would leave you with 15 firewall rules to create! Adding another subnet would even mean bigger trouble... not very feasable, right?
With our firewall appliances, no problem! Our firewall has so-called Zones - these are object references, in which you can add interfaces. By adding for example freshly created VLAN10 and VLAN20 into their own zone, you can have the same firewall rules applied to both networks.
This can be done via creating a new zone and dragging over the networks you want to be within the zone via
Configuration > Object > Zone
After that, you can assign the Zone to firewall rules:
So in this example, we are allowing both VLANs to allow both themselves, the other VLAN, any other LAN, the device itself, the internet by two simple rules. Convenient, isn't it?
4. The Power of Security - adding UTM features
The real magic of our firewall appliances however do not lie within the normal firewall setup, but the UTM profiles. A lot of the UTM features however also follow an object-oriented programming flow, so just like address, service and Zone objects, they are basically created at one place, waiting to be embedded into a firewall rule:
More on this topic can be found in the knowledgebase articles explicitely tailored toward these services, such as (among many others):