Firewall Policy Achitecture and Best Practices

[alienbaby]

Security Policy Best Practices
Version 0.3

A good starting point for good firewall policy is good network design. The ability to use network objects instead of many node objects will result in a more supportable policy. Establish an architecture to your network. Allocate blocks for each part of you network. Use a different IP block for you DMZ than you use for you Internal users, and a different block for Internal servers. Think about potential usage 10 years out. Allocate more IP space for each need than you believe you'll ever use in a decade. A nice roomy network design will allow for flexibility and easier management over time. This will not only help you make efficient, supportable firewall policy, but also nice small summarized and human recognizable routing tables.

Guide lines:

1. Don't use 'Any' in the Source, Destination, or Service fields for Accept rules. There may be good reasons, but they are few and far between.

2. Create a group object that represents either the DMZ subnets, or a network object for the larger network block from which DMZ subnets are allocated.

3. Create a group object that represents either the Internal subnets, or a network object for the larger network block from which Internal subnets are allocated.

4. Create a group object that contains the Internal and DMZ subnets/blocks. Use this group in it's negated form to represent the Internet. A group with exclusion will work as well. Many people don't realize that when they use 'Any' for source or destination, they are including their Internal and DMZ subnets. Do you really need some DMZ server to http/ftp to all Internal servers and workstations? Do you really mean all other DMZ servers can http/ftp/etc. to the publicly accessible DMZ server?

5. Utilize a naming convention. It will make finding/using/reading/supporting objects and policy easier.

6. Use those section titles and description fields. Even you will forget why, and for whom, you wrote that rule 18 months from now.


Firewall Policy; Major Sections

Firewall Management

Allow the firewall(s) to be managed. Allow any service to the firewall from various management platforms. Depending on your environment, you may want to allow the firewalls to connect to each other.

Example:

[Source]                     [Destination]             [Service]    [Action]

Denver-Firewalls (Group)     VRRP-MCAST                vrrp         Accept
Denver-Firewalls (Group)     Denver-Firewalls (Group)  ssh          Accept
Firewall-Admins (Group)      Denver-Firewalls (Group)  ssh,https    Accept
FirewallManagementServer     Denver-Firewalls (Group)  ssh          Accept
NetworkManagementServer      Denver-Firewalls (Group)  snmp         Accept

Stealth Rule
. Any to Firewall, Drop

A staple in the firewall community. Protect the firewalls.

Example:

[Source]           [Destination]             [Service]    [Action]

Any                Denver-Firewalls (Group)  Any          Drop

Client VPN Rules (SecuRemote/SecurClient)

I've found that putting the user vpn rules directly following the stealth prevents so many future problems. If you plan to manage the firewalls via a VPN, then you'll need to place a specific rule in Firewall Management section of the policy.

Here, we want to be specific about the source IPs a VPN will use. If you're using SecuRemote, then IP Pool NAT is assumed to be in use.
At the end of this section

Example:

[Source]                             [Destination]             [Service]    [Action]  [VPN]

SecureClientUsers@ClientVPN-IP-Pool  Internal-Servers (Group)  TCP-3389     Accept    SecurRemote
SecureClientUsers@ClientVPN-IP-Pool  Internal-DNS (Group)      dns (Group)  Accept    SecurRemote

SecureClientUsers@Any                Any                       Any          Drop      Any
ClientVPN-IP-Pool                    Any                       Any          Drop      Any
Any                                  ClientVPN-IP-Pool         Any          Drop      Any

Site-to-Site VPN rules
. Specific hosts/networks within Encyption Domains to other hosts/network in Encryption Domains, Accept
. VPN Encryption Domains to VPN Encryption Domains, Drop
. Any to Remote VPN Encryption Domains, Drop

Example:

[Source]                    [Destination]             [Service]                 [Action]  [VPN]

LocalServer                 RemoteServer              TCP-12132_WackyDevGuys    Accept    Customer1-VPN
LocalEncryptionDomain       RemoteEncryptionDomain    Any                       Drop      Any
RemoteEncryptionDomain      LocalEncryptionDomain     Any                       Drop      Any
Any                         RemoteEncryptionDomain    Any                       Drop      Any

High Traffic Rules

Example:

[Source]            [Destination]                [Service]   [Action]

DNS-Servers(Group)  ! Internal-Subnets(Group)    dns(Group)  Accept
                    {Negated}

Network Management
. Network Admins to Management subnets, Accept
. Network Management server to Internal/DMZ subnets, Accept

Example:

[Source]                     [Destination]                  [Service]    [Action]

NetworkManagementServer      Internal-Networks (Group)      snmp,icmp    Accept
NetworkManagementServer      DMZ-Networks (Group)           snmp,icmp    Accept
ServerAdmins (Group)         Internal-Server-Nets (Group)   ssh,TCP-3389 Accept
NetworkAdmins (Group)        Internal-Networks (Group)      ssh,telnet   Accept

DMZ Rules (Part 1 of 3, Inter-DMZ)
. DMZ to DMZ Rules, Accept
. Inside to DMZs, Accept
. DMZs to Inside, Accept

There are many schools on creation of DMZ rules. Your preference should be influenced by the supportability and scalability within your environment. Smaller environments may combine the first two DMZ sections together. Larger environments will likely further divide by Application, DMZ, Application components, DMZ purpose, among other criteria. Below, I'll given basic examples for both small and large environments.

Example (small):

[Source]                                           [Destination]        [Service]    [Action]

Internet (Negated Group of Internal/DMZ subnets)   WebServer            http,https   Accept
WebServer                                          Internal-Database    oracle2      Accept
Internet (Negated Group of Internal/DMZ subnets)   MailServer-Inbound   smtp         Accept
MailServer-Inbound                                 Internal-MailServer  smtp         Accept
MailServer-Outbound                                Internet             smtp         Accept

Example (large):

[Source]                                           [Destination]        [Service]      [Action]

SECTION TITLE - E-Mail

MailServer-Inbound                                 Internal-MailServer  smtp           Accept
MailServer-Outbound                                Internet             smtp           Accept
OWA-WebMail                                        ExchangeServer       http,AD-Group  Accept


SECTION TITLE - Ecommerce App

WebServerFarm(Group)                               DMZ-Database-Server  oracle2        Accept

SECTION TITLE - SSL VPN App

SSLvpnApplicance                                   Resources(Group)     ServicesGRP    Accept

DMZ Rules (Part 2 of 3, Internet to/from DMZs)
. DMZ Hosts/Subnets to Internet (Negated Group of Internal/DMZ subnets), Accept
. Internet (Negated Group of Internal/DMZ subnets) to DMZ Hosts/Subnets, Accept

Example (large):

[Source]                                           [Destination]        [Service]      [Action]

SECTION TITLE - E-Mail_Internet

Internet (Negated Group of Internal/DMZ subnets)   MailServer-Inbound   smtp           Accept
Internet (Negated Group of Internal/DMZ subnets)   OWA-WebMail          https          Accept


SECTION TITLE - Ecommerce App Internet

Internet (Negated Group of Internal/DMZ subnets)   WebServerFarm(Group) http,https     Accept

SECTION TITLE - SSL VPN App Internet

Internet (Negated Group of Internal/DMZ subnets)   SSLvpnApplicance     https          Accept

DMZ Rules (Part 3 of 3, Drop all DMZ traffic)
. DMZ subnets to Any, Drop
. Any to DMZ subnets, Drop


Example:

[Source]                  [Destination]        [Service]    [Action]

DMZ-Subnets(Group)        Any                  Any          Drop
Any                       DMZ-Subnets(Group)   Any          Drop

Internal Out - Specific
. Internal Hosts/Subnet to Specific Internet Hosts, Accept


Example:

[Source]                     [Destination]              [Service]    [Action]

Internal-Server              Microsoft-Updates(Group)   http         Accept
workstation_rpeterman        remote-extranet-server     ftp          Accept
restrictedUsers@UsersSubnet  remote-server              telnet       ClientAuth
UsersSubnet                  remote-server              telnet       Drop

Internal Out - General
. Internal Hosts/Subnet to Internet (Negated Group of Internal/DMZ subnets), Accept

Example:

[Source]               [Destination]                                     [Service]    [Action]

UserSubnet             Internet (Negated Group of Internal/DMZ subnets)  http,https   Accept
Executives             Internet (Negated Group of Internal/DMZ subnets)  YahooIM      Accept

Clean up
. Any to Any, Drop

Example:

[Source]          [Destination]   [Service]     [Action]    [Log]

Any               Any             NetBIOS       Drop        Don't_Log
Any               Any             Any           Drop        Log

---
* This post will be edited with additional content and documentation over time.
** For those of you who disable implied rules, I'll be happy add your standard policy to the Firewall Management section if submitted.

Changes:
. Corrected Site-to-Site VPN section.

[nr2258]

Excellent stuff! About your advice to utilize a naming conventions, do you have any advice to prevent every administrator from using their "private" naming conventions.
I almost always notice that when we run our firewall analyzer on client networks, there are loads of duplicate objects. For example db_Server, sql_server, database_srvr - each created by a different admin and all of the same containing the same IPs! It's seems like it's very hard to enforce good naming conventions.

Cheers,
Nimmy Reichenberg - AlgoSec

[bmolnar]

I almost always notice that when we run our firewall analyzer on client networks, there are loads of duplicate objects. For example db_Server, sql_server, database_srvr - each created by a different admin and all of the same containing the same IPs! It's seems like it's very hard to enforce good naming conventions.

My naming convention for host objects is to use the fully qualified server names whenever possible. It fits the 'corporate' naming standard and makes it easier to find out what the server is if an IP address changes. I'm surprised there are duplicate host objects like that because the Dashboard prompts everytime

[alienbaby]

there are loads of duplicate objects. For example db_Server, sql_server, database_srvr - each created by a different admin and all of the same containing the same IPs!

Whenever a node/host object is created that has the same IP as an existing node/host object, a warning will pop up.
Your admins are clicking through the warning dialog. I recommend you teach them how to highlight the Nodes section and sort by IP in the Objects List.

[ShadowPeak.com]

One tip I'd like to propose adding is the color scheme I like to use for objects:

Internal, trusted objects - green
DMZ objects - yellow
External, untrusted objects - red
External Partner/Vendor/Somewhat Trusted - orange

If this color scheme is followed it is very easy at a glance to see the direction (External->DMZ, DMZ->Internal, etc.) that traffic is being allowed by a rule. There really isn't a concept of "directionality" in the Check Point rulebase itself (Security Zones are used by other vendor's firewalls to achieve this effect) and this color scheme is quite handy in that regard.

[marklar]

Internal, trusted objects - green
DMZ objects - yellow
External, untrusted objects - red
External Partner/Vendor/Somewhat Trusted - orange

I'd also suggest adding a variant of Internal and DMZ colours to indicate test/development systems, and give them their own unique rules that are not shared with production systems.

[nilsw007]

Very useful information !!!!!

Thanks,

Nilesh

[Dom2201]

I have another useful suggest.

I like to name my objects as followed:

h-<Name> for Host Objects
hg-<Name> for Host Groups
net-<name> for networks
ng-<name> for network groups

So if you search after a special object you type in "h-" and all single Host objects will show up.





Gesendet von iPhone mit Tapatalk

[varera]

Although I really appreciate the effort, I have to make a note here:

as far as I am concerned, general best practices never work in security and for Check Point specifically. There is always an exception, a limitation or a conflict for each and every suggestion one can made.

[alienbaby]

Although I really appreciate the effort, I have to make a note here:

as far as I am concerned, general best practices never work in security and for Check Point specifically. There is always an exception, a limitation or a conflict for each and every suggestion one can made.

The methodology is open to expansion and is specific to CheckPoint for Simplied Mode and Traditional Mode policy (pre-R80 stuff).. mostly simplified mode. It also does not address several silly features like TCP listeners on the firewall or idiosyncrasies with Resource Objects...

But just the same. Gauntlet Thrown down.

Challenge accepted. :)

Example?

[varera]

Example of what?

Say, best practice requires shadow rule for your FW as high as possible. Yet having that rule among the first ones disable acceleration with templates for the rest of the rulebase.
Or, in your example you allow all services through VPN. That is not the best security practice, especially considering there might be some restrictions on VPN tunnel traffic between sites. And so on and so forth. Every statement with a best practice suggestion can be challenged with an example where following such a rule is not a good idea. All, even the very basic ones. Even simplified VPN over traditional. There is always a serious exception for any recommendation you can come up with

[alienbaby]

Example of what?

Say, best practice requires shadow rule for your FW as high as possible. Yet having that rule among the first ones disable acceleration with templates for the rest of the rulebase.
Or, in your example you allow all services through VPN. That is not the best security practice, especially considering there might be some restrictions on VPN tunnel traffic between sites. And so on and so forth. Every statement with a best practice suggestion can be challenged with an example where following such a rule is not a good idea. All, even the very basic ones. Even simplified VPN over traditional. There is always a serious exception for any recommendation you can come up with

You're right that the methodology does not address acceleration. Its about consistency in policy creation and day-to-day management. And I would argue that if your everyday corporate firewall needs acceleration to survive, then the box is way under-sized. Beyond that, if you're in an environment where number of connection setups a second is a big deal, then you're not using a management centered methodology. You're writing a small policy for speed only in a isolated management server/CMA/Domain for speed related customizations.

The example VPN rule shows a service being allowed on the VPN and then multiple Any service drops to prevent some lower rule from allowing traffic across the VPN.
There shouldn't be any 'Any' rules when the source/destination/service are known; and a VPN requires these to be known.

I can say that in my nearly 18 years for Check Point experience.. the methodology addresses about 99% of customers/environments; But I'm always interested in improvements to it. Perhaps I'll add a scope statement.

[Irek_Romaniuk]

These best practices address only initial, manually created part of the policy. In my opinion after this is done, the rest of rules should be created automatically thru API, based on approved requests, added to the bottom of policy, with 1:1 , match between request and rule.

[PhoneBoy]

These best practices address only initial, manually created part of the policy. In my opinion after this is done, the rest of rules should be created automatically thru API, based on approved requests, added to the bottom of policy, with 1:1 , match between request and rule.

Automation in general will increase compliance and efficiency.
A lot of organizations aren't to that point yet, but I generally agree this is the way things are headed.
We can argue about rule placement, though I understand why you're thinking that way.
Makes it easier to validate compliance, but automation should be able to do that too.

[alienbaby]

I agree that ultimately policy creation and management should/will be automated. Be it should be done so using a methodology such as the one above. Otherwise, you're going to encounter self-inflicted outages/wounds etc..

Every firewall vendor has its own limitations/idiosyncrasies/best-practices dictated by their vendor specific implementation/technology. Some methods are common to all vendors, more specific above less specific for example..

But, this methodology could be applied against an automated process quite successfully I think. The result being consistent and human auditable policy.

My NAT policy methodology could also be applied very well in a automated fashion as well..

[Irek_Romaniuk]

I believe that policy creation should be vendor agnostic , even at the cost of having 10k rules...put some of my thoughts together here .

[varera]

I believe that policy creation should be vendor agnostic , even at the cost of having 10k rules...put some of my thoughts together here .

Interesting concept, but I am afraid vendors may not agree. For example, PAN zone concept has no analogy with Check Point. Even with R80.10 where you finally can set interfaces and zones relations, treatment of zone inside traffic is still different. There are many other similar examples.

Applying same techniques of policy creation to different tech vendors will eventually fail

[Irek_Romaniuk]

Of course the module creating a rule based on the source/destination and port has to be vendor API specific. Looking at Checkpoint management API Reference v1.0 I can see 'add access-rule' with parameter names of 'source', 'destination' and 'service' . There is required 'layer' and 'position' names . The latter will be always 'bottom', and 'layer' can be predefined i.e. "Auto" to group automatically provisioned rules in one place, correct ?

Can zones by set to 'any' so they are selected by firewall based on source and destination like in PA ?