SofaWare Management Architecture Basics The SofaWare management architecture is made up of several software components. These components are similar to components in FW-1/NG. Some aspects of the SofaWare architecture are very different. SofaWare is well suited to manage a large number of firewalls with group based firewall policies. Using SofaWare Management provides an important benefit of reducing the cost of managing gateways. The SofaWare Management architecture is designed with management scaling in mind. Whether you are managing 10 Safe@ gateways or 1,000, the SofaWare Management designs scales without the associated increase in staffing requirements. A single administrator with the SofaWare Management Portal components running on a single Server could manage thousands of SofaWare Safe@ firewalls. Load balancing and high availability features are built in making SofaWare very scalable. To understand how this ties in with the existing Check Point infrastructure you must first understand how SofaWare works. Like FW-1/NG there is a separation of the enforcement point (Safe@ device, S-box as an example) and the management (SMP). Also, the enforcement point is using the same Stateful Inspection used within other Check Point products. Unlike the traditional model, SofaWare firewall policies are not specific to the enforcement point or it s network addresses. SofaWare is designed to work in DHCP environments. SofaWare firewall policies are created for a group or class of user. The use of dynamic objects within the firewall policy eliminates the need for specific network topology information in the rules. This greatly simplifies policy management and returns the benefit of reducing the operational cost. SofaWare Management Portal The SofaWare Management Portal (SMP) is the center of the SofaWare model. The SMP is made up of several software components. The SMP software components may be installed to run on one server or distributed across several servers to provide redundancy. The SMP functions as a distribution center for controlling Safe@ gateway devices. This includes; configuration settings, admin controls, firewall policies, firmware upgrades and receiving logs. Configuration settings include turning on features like VPN client or the ability to create custom rules. The SMP also provides access to services like email anti-virus and URL filtering. The SMP controls features in the gateways through Plans. SMP Software Components SofaWare Management Server (SMS) Runs on Windows 2000 Server. Communicates with Safe@ gateways (S-boxes) via a authenticated and encrypted management tunnel. Sets features and sends policy, firmware and GUI files. Receives logs from the gateways. Communicates with CVP and UFP servers and provides those services to the gateways. SofaWare Management Center (SMC) Web based and runs under Apache on Windows 2000. This is the administration interface to add data to the LDAP database. You can add users, gateways, policy/gui/firmware files and plans to the database via this user interface. This may run on the same machine as the SMS. (See Figure 1) Service Configuration Portal (SCP) Formerly Self Provisioning Portal (SPP) - Optional Web based and runs under Apache on Windows 2000. This is an end user interface for S-box users. It can be provided to end users as a way of choosing the features enabled on their S-box. This may run on the same machine as the SMS. (See Figure 2) 2002 Check Point Software Technologies Inc. Page: 1/5
LDAP Directory Server (iplanet or Active Directory) The LDAP Directory may be installed on any OS that the LDAP vendor supports, but to date has only been tested with iplanet and Active Directory on Windows 2000. This database contains all the information used by the SMP. The LDAP directory may run on the same machine as SMS in our demos but might be run on a separate machine for performance in a large-scale deployment. In a high availability deployment the LDAP database must be replicated outside the control of SofaWare. The SofaWare load balancing and HA features provide HA to the SofaWare Management Servers, and do not handle the database replication. OPSEC Content Scanning Products (Anti-Virus & URL Filtering) - Optional These can be run locally or distributed. In our demos we run them on the same machine as the SMP. In the real world at least the anti-virus component should be run on separate hardware for performance reasons. We have tested, and use in our demos, Trend Interscan VirusWall and SuperScout Check Point FireWall-1 Edition. We have additional whitepapers on how SofaWare handles CVP and UFP in detail. Figure 1 SofaWare Management Center 2002 Check Point Software Technologies Inc. Page: 2/5
Figure 2 - Service Configuration Portal SofaWare Architecture SMP uses an LDAP directory to store all Customer, Safe@ gateway and configuration information. Data for customer/users, Safe@ gateways, firewall policies, firmware and more is stored in an LDAP database for use by the SMP. When an administrator uses the SofaWare Management Console (SMC), additions and changes are stored in LDAP. The SofaWare Management Server (SMS) uses this data to configure and send the correct files to Safe@ gateways, such as the S-box. The SMC is not the only way to populate this database. This is an integration point. Any software that can act as a LDAP client can talk to and manipulate the LDAP database. A service provider might populate data to or read data from the LDAP database from their customer service/billing systems. The SofaWare Management Server (SMS) uses the data to configure the gateways. The files SMP sends to gateways come from various sources, but once added to SMP are stored as part of the LDAP database. Firmware The firmware files are basically the Safe@ device OS and firewall software. Firmware changes are like new releases of the firewall software or like service packs or feature packs. When new firmware is loaded into the Safe@ device (S-box) it is similar to installing a new release of FW-1 or NG. Firmware files currently only come from SofaWare. There will likely be a time when other hardware devices will work in the SofaWare environment. Firmware for these devices might come from the manufacturer. User Interface User interface files are the UI that the end user sees at http://my.firewall. A new interface file might be cosmetic or it might be required to provide the controls for a new feature from new firmware. The UI files are created as web pages and then compressed into a single file and signed by SofaWare. There is currently 2002 Check Point Software Technologies Inc. Page: 3/5
no method to create your own GUI files. We can work with customers to help them create custom GUIs when needed. Currently all the GUI files come from SofaWare. Security Policy Policy files actually contain 3 separate security policies. To the end user at http://my.firewall they appear in the Security menu as the High, Medium and Low settings. Policies are not created using the SMP. Policies are created using a SofaWare modified FW-1 4.1 policy editor. There is more detail in the Policy Editor section. The SofaWare policies are a single compressed, signed file. From the SMP point of view it is just another file that can be sent to a gateway or group of gateways. The SMP does not control the content of the policy file just it s distribution. Plans A Plan is a table of the features and services turned on for a particular gateway or group of gateways. This includes licensed features as well. If a gateway is licensed for Safe@HomePro, then assigning a plan that includes VPN client turned on would apply that license and the user would have VPN capabilities. In the Plan we turn on or off encrypted communication from SMP to gateway, Firewall, user custom rules (none, Simple or Advanced), NAT, VPN, logging (none, Remote, or Local) and node limit/grace Amount (Grace Amount allows use of 1 or 2 more IPs than licensed for). Figure 2 Plan editor Policy Editor In most firewalls the management is centered on the policy editor. This is not the case with SofaWare. Remember, the whole point is to be able to manage thousands of Safe@ gateways without the associated cost in operational management. If the administrator needs to spend time defining specific security policies in a policy editor for each firewall then the scalability is lost and the operational cost increases. The Check Point Policy Editor is used to create the security policy. Once the security policy is created it is loaded into the SMP. Creating policies is a separate task and is dependant on how often you need to modify your security policies. Today the SofaWare policy editor uses the Check Point 4.1 policy editor. Additional objects are loaded to enable the Policy Editor to create SofaWare Safe@ security policies. The SofaWare policy editor does not have to be located on the same machine as the SofaWare Management Portal (SMP). When you create a policy for a SofaWare Safe@ (S-box) device, the policy editor checks and compiles the policy just as normal, but then instead of installing the policy on an enforcement point it creates a single, compressed, signed policy file. This security policy file is loaded into the SMP for download to the Safe@ devices (S-boxes). In addition, each policy file actually contains three complete policies, labeled High, Medium and Low. Figure 3 is a screen shot of the policy editor with the default policy shipping with the S-box. Notice in the Install On column the firewall object named High, Medium and Low. Off and Block All are setting which are normally used by the Ericsson HM204 cable modem and are not currently used by the Safe@ S-box. When the install policies button is clicked, the policies will be checked and compiled as if for a normal Check Point firewall, but instead of sending the new policies to the respective firewalls they are saved in a single compressed, signed file with a.pfz extension. This policy file, when added to the SMP, 2002 Check Point Software Technologies Inc. Page: 4/5
and can be assigned to all, or any group of, Safe@ gateways (S-boxes). With the current version of SofaWare, the modifications made to the FW-1 policy editor render it non-functional for standard FW-1 use. In the near future this will be integrated with the NG policy editor. The same GUI interface that manages NG firewalls will be able to create policies for the Safe@ device (S-box). When the Install button is clicked the policy will still be saved in a single compressed, signed file. There will be a choice to just save the file or automatically transfer it to the SMP for distribution to Safe@ gateways Figure 3 - Policy Editor For questions and/or comments regarding this document contact Keith Lewis at klewis@us.checkpoint.com 2002 Check Point Software Technologies Inc. Page: 5/5