Firewall rule base design

DevilWAH

Just curious how people organised there rule bases.

I have been a fan of zones for a while now. where network is logical devices in to zones and then the rule base is split based on traffic between zones.

Inside to outside
outside to inside
inside to DMZ
dmz to inside
..
..
..
..

at the end of each a deny all rule. I fine this way its easy to see where to look for a rule, and with in each "zone policy" rules are created based on protocol.

what other structures do people go for to help keep the rule base tidy and understandable?

elTorito

Zones all the way. Some firewall brands may label it differently, but I don't see how else one can create structure in the rulebase while still keeping things easy to oversee. It's the DNS of firewalling!

yzT

By application:

Http in
Http out

Ssh in
Ssh out

...
...

DevilWAH

yzT wrote: »

By application:

Http in
Http out

Ssh in
Ssh out

...
...

how many devices and networks are you managing? that gets very messy after a few thousand hosts and dozen or more networks, and a few hundred protocols.

if I say can you tell me how may devices in network 192.168.3.0 / 24 have incoming access and what are the protocols allowed. with a rule based based on protocols you need to check very rule to find out. its easy to set up rules but not so easy to trouble shot and monitor.

Christian.

I'm not a fan of zones at all. I prefer Checkpoint's approach where you don't have zones or the full concept of inside/outside/ratings. You configure the different interfaces on the box, and then the OS handles incoming traffic according to your rules. It will forward the traffic or not according to what you defined. So, if a package arrives with src x.x.x.x and with dest y.y.y.y on port abc, the firewall will process it if you have a rule for just that, regardless of the interface were it arrived. Of course, you can configure antispoofing to define what networks he is going to see coming from each interface to avoid spoofing, but you don't have to configure interfaces into the rules. It's one big policy that you can divide with labels depending on business units, applications or similar.

If you have a firewall will many interfaces (let's say 8 ) and one server behind eth1 has to talk to many hosts that are behind many of those other interfaces (before it's implemented you don't know if that will be used or not), you will need to define rules for each pair of interfaces (eth1 to eth2, eth1 to eth3, eth1 to eth4, etc). If those destination hosts also have to talk with that source server, you will need more rules on each pair to allow that traffic. It's a mess for something simple, and worse if you need to modify that in a future, or even remove it in a future on a rule base that has been building over time. With checkpoint you only need 2 rules. One where the server is the source and all those servers are the destination. Then, another rule with the opposite, the hosts as source and server as destination. That's it, much easier to setup and you avoid ending with a gazillion rules.

If you have to handle a large amount of firewalls (I'm doing over 60, most of them in HA so over 30 environments with multiple interfaces on each device), it can get really messy really fast when you have rules that sometimes have to be deployed in 2 or 3 firewalls at the same time because they are crossing each other. Internal customers don't know any of this or the topology, so it's your job to identify the firewalls that have to be modified and keep requests clean. If you also have to determine pairs for each rule on several firewalls, it would be a full time job just to submit that into forms for approvals and then to deploy them.

That's how I see things at least.

Trifidw

DevilWAH wrote: »

how many devices and networks are you managing? that gets very messy after a few thousand hosts and dozen or more networks, and a few hundred protocols.

if I say can you tell me how may devices in network 192.168.3.0 / 24 have incoming access and what are the protocols allowed. with a rule based based on protocols you need to check very rule to find out. its easy to set up rules but not so easy to trouble shot and monitor.

I concur. I use these very sparingly to achieve a specific objective (i.e. this application with these servers need these ports to talk to these servers). The alternative here would be hundreds of rules and a nightmare to add or remove any servers from the list. I try to do this ip needs to talk to this ip on this port all the time and avoid groups or any rules like the plague (even outbound)

DevilWAH

Christian. wrote: »

I'm not a fan of zones at all. I prefer Checkpoint's approach where you don't have zones or the full concept of inside/outside/ratings. You configure the different interfaces on the box, and then the OS handles incoming traffic according to your rules. It will forward the traffic or not according to what you defined. So, if a package arrives with src x.x.x.x and with dest y.y.y.y on port abc, the firewall will process it if you have a rule for just that, regardless of the interface were it arrived. Of course, you can configure antispoofing to define what networks he is going to see coming from each interface to avoid spoofing, but you don't have to configure interfaces into the rules. It's one big policy that you can divide with labels depending on business units, applications or similar.

If you have a firewall will many interfaces (let's say 8 ) and one server behind eth1 has to talk to many hosts that are behind many of those other interfaces (before it's implemented you don't know if that will be used or not), you will need to define rules for each pair of interfaces (eth1 to eth2, eth1 to eth3, eth1 to eth4, etc). If those destination hosts also have to talk with that source server, you will need more rules on each pair to allow that traffic. It's a mess for something simple, and worse if you need to modify that in a future, or even remove it in a future on a rule base that has been building over time. With checkpoint you only need 2 rules. One where the server is the source and all those servers are the destination. Then, another rule with the opposite, the hosts as source and server as destination. That's it, much easier to setup and you avoid ending with a gazillion rules.

If you have to handle a large amount of firewalls (I'm doing over 60, most of them in HA so over 30 environments with multiple interfaces on each device), it can get really messy really fast when you have rules that sometimes have to be deployed in 2 or 3 firewalls at the same time because they are crossing each other. Internal customers don't know any of this or the topology, so it's your job to identify the firewalls that have to be modified and keep requests clean. If you also have to determine pairs for each rule on several firewalls, it would be a full time job just to submit that into forms for approvals and then to deploy them.

That's how I see things at least.

We are talking organising rule bases not configuration. I have done the managing global checkpoint firewalls rule bases for one of the largest Oil companies and work on checkpoint now to. We are talking about the best way to organise the "labels" as you call them. Zone based on a check point would be setting lables like

"Restricted traffic in to data centre A"


a good rule base needs to make it easy to make sense of, and put the orders in the right order for performance, and its a balancing game, you need a structure that you can manage, but you need to be able to move "rules around with out ruining the structure.

PS on a zone based firewall you don't need more rules than check point if you conside the design early on of the zones.

CSCOnoob

We do not, unfortunately, tidy up the rule base because of the fact that we get about 30K rule requests per year. A good chunk of that is actually done by automation (developed in house). For making sense of the rules, there is a front end (developed in house) that you just input source and destination addresses and will spit out the rules associated to those addresses. A lot of self-service tools so less human interaction from the networking group as much as possible.

+1 on zones
+1 on vsys