Create a Post
cancel
Showing results for 
Search instead for 
Did you mean: 
CaseyB
Collaborator

R81.10 Rulebase creation

R77.30 Reference - sk106597 

Does such a thing exist for R81.10? I've looked at the R81.10 Security Management Administration Guide and R81.10 Logging and Monitoring Administration Guide per the suggestion of the R77.30 reference article, but nothing concrete jumps out at me.

The main thing I am wondering is, is it still best practice to have VPN (site-to-site) rules at the top of the rulebase, or should it follow more of a hit count approach now? 

0 Kudos
8 Replies
the_rock
Legend
Legend

I will tell you approach I have and works perfectly fine, but, everyone is different.

-generic rules, such as geo blocks, vpn rules, blocking known bad IPs etc, top of the rulebase

-for each interface that belongs to specific zone, inline layer inside default network layer

-separate ordered layer that has appc+urlf enabled for those rules (MAKE SURE that layer has any any allow at the bottom, otherise all traffic would be blocked)

-any additional ordered layer for specific blade if needed

Alsom keep in mind, link you gave is indeed good reference, but, it was written when layers with CP did not exist back in the day, unlike some other vendors.

Hope that helps.

Andy

0 Kudos
Bob_Zimmerman
Authority
Authority

Computers are really, really fast. The only rule order optimization worth caring about is stuff which disables SecureXL templates. Check 'fwaccel stat' to see if it says templates are "disabled from rule ###" or something similar, and consider moving that rule lower.

Otherwise, arrange your rules to make sense for the humans who have to deal with them.

0 Kudos
Chris_Atkinson
Employee Employee
Employee

The Admin guide contains guidance on crafting the Access Policy:

https://sc1.checkpoint.com/documents/R81.10/WebAdminGuides/EN/CP_R81.10_SecurityManagement_AdminGuid...

CCSM R77/R80/ELITE
0 Kudos
CaseyB
Collaborator

Yes, I went over that in my original post. The section of the Admin guide you linked to and that I've read as well, does not spell out VPN rule placement like the R77.30 SK did, that's why I made this post, to see if VPN rules should still be placed at the top of the rulebase as was once suggested in R77.30. This appears to no longer be a thing from the feedback I am getting due to the evolution of the software, which is great.

emmap
Employee
Employee

Alongside all the other advice in this thread, I'd suggest that putting VPN rules into an inline layer (one layer per VPN community) is a good idea, as it means you can manage that traffic without having to be concerned about it accidently matching any general rules lower down in the policy. A parent rule with 'any any any' but with the VPN community specified probably would work, but I've not personally tested that.

0 Kudos
the_rock
Legend
Legend

It does work, I tried that before, but honestly, I always prefer to have VPN rules in general section, BEFORE any inline layers, but again, thats just me.

Andy

0 Kudos
CaseyB
Collaborator

I've started doing this recently and I've been a big fan. Easier to manage and I feel better about getting more granular with the security policy as it doesn't add to the overall length of the main policy, just uh the inline, which is fine.

0 Kudos
the_rock
Legend
Legend

It was not easy to get used to from R77 code, but it makes so much more sense. Cisco had layered approach for who knows how long now, but obviously, as their web filtering feature is not that great, thats where CP comes in.

Andy

0 Kudos

Leaderboard

Epsum factorial non deposit quid pro quo hic escorol.

Upcoming Events

    CheckMates Events