Firewall rule base design

DevilWAHDevilWAH Member Posts: 2,997 ■■■■■■■■□□
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?
  • If you can't explain it simply, you don't understand it well enough. Albert Einstein
  • An arrow can only be shot by pulling it backward. So when life is dragging you back with difficulties. It means that its going to launch you into something great. So just focus and keep aiming.

Comments

  • elToritoelTorito Member Posts: 102
    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!
    WIP: CISSP, MCSE Server Infrastructure
    Casual reading: CCNP, Windows Sysinternals Administrator's Reference, Network Warrior


  • yzTyzT Member Posts: 365 ■■■□□□□□□□
    By application:

    Http in
    Http out

    Ssh in
    Ssh out

    ...
    ...
  • DevilWAHDevilWAH Member Posts: 2,997 ■■■■■■■■□□
    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.
    • If you can't explain it simply, you don't understand it well enough. Albert Einstein
    • An arrow can only be shot by pulling it backward. So when life is dragging you back with difficulties. It means that its going to launch you into something great. So just focus and keep aiming.
  • Christian.Christian. Member Posts: 88 ■■■□□□□□□□
    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.
    CISSP | CCSM | CCSE | CCSA | CCNA Sec | CCNA | CCENT | Security+ | Linux+ | Project+ | A+ | LPIC1
  • TrifidwTrifidw Member Posts: 281
    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)
  • DevilWAHDevilWAH Member Posts: 2,997 ■■■■■■■■□□
    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.
    • If you can't explain it simply, you don't understand it well enough. Albert Einstein
    • An arrow can only be shot by pulling it backward. So when life is dragging you back with difficulties. It means that its going to launch you into something great. So just focus and keep aiming.
  • CSCOnoobCSCOnoob Member Posts: 120
    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
Sign In or Register to comment.