CPUG: The Check Point User Group

Resources for the Check Point Community, by the Check Point Community.


First, I hope you're all well and staying safe.
Second, I want to give a "heads up" that you should see more activity here shortly, and maybe a few cosmetic changes.
I'll post more details to the "Announcements" forum soon, so be on the lookout. -E

 

Results 1 to 18 of 18

Thread: Firewall Policy Achitecture and Best Practices

  1. #1
    Join Date
    2005-11-25
    Location
    United States, Southeast
    Posts
    857
    Rep Power
    15

    Default Firewall Policy Achitecture and Best Practices

    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:
    Code:
    [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:
    Code:
    [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:
    Code:
    [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:
    Code:
    [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:
    Code:
    [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:
    Code:
    [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):
    Code:
    [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):
    Code:
    [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):
    Code:
    [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:
    Code:
    [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:
    Code:
    [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:
    Code:
    [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:
    Code:
    [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.
    Last edited by alienbaby; 2011-11-10 at 19:23.

  2. #2
    Join Date
    2011-07-16
    Posts
    5
    Rep Power
    0

    Default Re: Firewall Policy Achitecture and Best Practices

    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

  3. #3
    Join Date
    2009-04-14
    Location
    Ohio
    Posts
    405
    Rep Power
    12

    Default Re: Firewall Policy Achitecture and Best Practices

    Quote Originally Posted by nr2258 View Post
    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

  4. #4
    Join Date
    2005-11-25
    Location
    United States, Southeast
    Posts
    857
    Rep Power
    15

    Default Re: Firewall Policy Achitecture and Best Practices

    Quote Originally Posted by nr2258 View Post
    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.

  5. #5
    Join Date
    2009-04-30
    Location
    Colorado, USA
    Posts
    2,252
    Rep Power
    15

    Default Re: Firewall Policy Achitecture and Best Practices

    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.

  6. #6
    Join Date
    2007-07-12
    Posts
    143
    Rep Power
    14

    Default Re: Firewall Policy Achitecture and Best Practices

    Quote Originally Posted by ShadowPeak.com View Post
    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.

  7. #7
    Join Date
    2013-01-31
    Posts
    62
    Rep Power
    8

    Default Re: Firewall Policy Achitecture and Best Practices

    Very useful information !!!!!

    Thanks,

    Nilesh

  8. #8
    Join Date
    2016-04-06
    Location
    Germany
    Posts
    57
    Rep Power
    5

    Default Re: Firewall Policy Achitecture and Best Practices

    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

  9. #9
    Join Date
    2006-03-08
    Location
    Lausanne
    Posts
    1,030
    Rep Power
    16

    Default Re: Firewall Policy Achitecture and Best Practices

    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.
    -------------

    Valeri Loukine
    CCMA, CCSM, CCSI
    http://checkpoint-master-architect.blogspot.com/

  10. #10
    Join Date
    2005-11-25
    Location
    United States, Southeast
    Posts
    857
    Rep Power
    15

    Default Re: Firewall Policy Achitecture and Best Practices

    Quote Originally Posted by varera View Post
    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?

  11. #11
    Join Date
    2006-03-08
    Location
    Lausanne
    Posts
    1,030
    Rep Power
    16

    Default Re: Firewall Policy Achitecture and Best Practices

    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
    -------------

    Valeri Loukine
    CCMA, CCSM, CCSI
    http://checkpoint-master-architect.blogspot.com/

  12. #12
    Join Date
    2005-11-25
    Location
    United States, Southeast
    Posts
    857
    Rep Power
    15

    Default Re: Firewall Policy Achitecture and Best Practices

    Quote Originally Posted by varera View Post
    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.

  13. #13
    Join Date
    2014-10-10
    Posts
    250
    Rep Power
    6

    Default Re: Firewall Policy Achitecture and Best Practices

    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.

  14. #14
    Join Date
    2005-08-14
    Location
    Gig Harbor, WA, USA
    Posts
    2,494
    Rep Power
    17

    Default Re: Firewall Policy Achitecture and Best Practices

    Quote Originally Posted by Irek_Romaniuk View Post
    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.
    http://phoneboy.org
    Unless otherwise noted, views expressed are my own

  15. #15
    Join Date
    2005-11-25
    Location
    United States, Southeast
    Posts
    857
    Rep Power
    15

    Default Re: Firewall Policy Achitecture and Best Practices

    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..

  16. #16
    Join Date
    2014-10-10
    Posts
    250
    Rep Power
    6

    Default Re: Firewall Policy Achitecture and Best Practices

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

  17. #17
    Join Date
    2006-03-08
    Location
    Lausanne
    Posts
    1,030
    Rep Power
    16

    Default Re: Firewall Policy Achitecture and Best Practices

    Quote Originally Posted by Irek_Romaniuk View Post
    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
    -------------

    Valeri Loukine
    CCMA, CCSM, CCSI
    http://checkpoint-master-architect.blogspot.com/

  18. #18
    Join Date
    2014-10-10
    Posts
    250
    Rep Power
    6

    Default Re: Firewall Policy Achitecture and Best Practices

    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 ?

Similar Threads

  1. This New Forum About Firewall Policy Management Best Practices
    By Barry J. Stiefel in forum Firewall Policy Management Best Practices
    Replies: 0
    Last Post: 2011-05-09, 03:14
  2. Firewall Policy not showing up
    By kmhendress in forum SmartPortal
    Replies: 3
    Last Post: 2011-03-24, 05:35
  3. Installing Policy Firewall-1
    By chris.vincent in forum Miscellaneous
    Replies: 2
    Last Post: 2009-02-09, 23:07
  4. Firewall Policy
    By scottlsattler in forum Check Point Backup Procedures
    Replies: 5
    Last Post: 2008-06-22, 15:53
  5. Policy retreival from firewall
    By desiac in forum Check Point Backup Procedures
    Replies: 0
    Last Post: 2007-11-08, 02:21

Bookmarks

Posting Permissions

  • You may not post new threads
  • You may not post replies
  • You may not post attachments
  • You may not edit your posts
  •