- CheckMates
- :
- Products
- :
- Quantum
- :
- Management
- :
- Dynamic Updates in the R80.10 Policy
- Subscribe to RSS Feed
- Mark Topic as New
- Mark Topic as Read
- Float this Topic for Current User
- Bookmark
- Subscribe
- Mute
- Printer Friendly Page
Are you a member of CheckMates?
×
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
Dynamic Updates in the R80.10 Policy
In R80.10 the rule base is represented as a database table in the kernel which automatically adapts to changes in dynamic objects and results in a more efficient policy installation process.
The policy installation process on R80.10 gateways consumes less time and resources than on R77 gateways. Instead of a compilation process the management server does a database scheme conversion. Each gateway receives only the objects required for the local rule base.
On the gateway a separate preparation and commit phase provides recovery and fallback if needed. The current policy is stored in the $FWDIR/state/local/FW1 directory. During the policy installation files containing the information about the new policy are transferred from the management server to the gateway and stored in the. $FWDIR/state/__tmp/FW1 directory. The next step is to create and/or update the table structure in the SQLite database. If a failure or reboot occurs at this point, then the gateway continues to run the current policy. During the final commit stage, the pointers in kernel memory are changed to point to the new policy and objects. The gateway continues to run the current policy until the new table pointers are loaded.
In addition to supporting fallback and recovery the new structure automatically adapts to changes in dynamic objects and adds SecureXL support for Dynamic, Domain and Time objects. In R77 these objects would disable SecureXL accept templates at that point in the policy.
# fwaccel statAccelerator Status : onAccept Templates : disabled by Firewall disabled from rule #<N>
In R80.10 security enforcement is done based upon the kernel table arrays and the policy stored in the kernel memory. As network and dynamic objects change in the SQLite database the kernel tables are updated. When the objects change the SecureXL template is revoked and then SecureXL goes through the process of recreating the connection providing acceleration template support for these dynamic objects in the R80.10 policy.
In addition to the above, the infrastructure still supports legacy commands such as “fw unloadlocal” and “fw fetch localhost” and enables future enhancements such as partial policy installs, i.e. installing a policy layer or sublayer.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
Hi and thanks for the another "hidden" gem in R80 that I somehow missed through all CP presentations and CPX last year.. - I knew that domain objects now worked happily with SecureXL but you made me even more happy with time & dynamic objects! The usability of domain objects has made massive difference for us - we only allow users to access internet via proxies, so any exemptions were very hard and tricly to manage (statically mapped IPs to names). Same goes to defining O365 access - can avoid crazy groups with thousands of subnets, use URLs instead without impact to Secure XL. Awesome.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
Yep, the chances of your entire Network policy layer being eligible for SecureXL Session Rate Acceleration (i.e. "templating") without any policy tuning whatsoever increases dramatically just by upgrading to R80.10 gateway.
--
My Book "Max Power: Check Point Firewall Performance Optimization"
Second Edition Coming Soon
CET (Europe) Timezone Course Scheduled for July 1-2
