NG with Application Intelligence (R55)

Transcription

1 The Upgrade Guide NG with Application Intelligence (R55) IMPORTANT Check Point recommends that customers stay up-to-date with the latest service packs and versions of security products, as they contain security enhancements and protection against new and changing attacks. For additional technical information about Check Point products, consult Check Point s SecureKnowledge at See the latest version of this document in the User Center at: Part Number November 2003

2 Check Point Software Technologies Ltd. All rights reserved. This product and related documentation are protected by copyright and distributed under licensing restricting their use, copying, distribution, and decompilation. No part of this product or related documentation may be reproduced in any form or by any means without prior written authorization of Check Point. While every precaution has been taken in the preparation of this book, Check Point assumes no responsibility for errors or omissions. This publication and features described herein are subject to change without notice. RESTRICTED RIGHTS LEGEND: Use, duplication, or disclosure by the government is subject to restrictions as set forth in subparagraph (c)(1)(ii) of the Rights in Technical Data and Computer Software clause at DFARS and FAR TRADEMARKS: Check Point, the Check Point logo, ClusterXL, ConnectControl, FireWall-1, FireWall-1 GX, FireWall-1 SecureServer, FireWall-1 SmallOffice, FireWall-1 VSX, FireWall-1 XL, FloodGate-1, INSPECT, INSPECT XL, IQ Engine, MultiGate, Open Security Extension, OPSEC, Provider-1, SecureKnowledge, SecurePlatform, SecureXL, SiteManager-1, SmartCenter, SmartCenter Pro, SmartDashboard, SmartDefense, SmartLSM, SmartMap, SmartUpdate, SmartView, SmartView Monitor, SmartView Reporter, SmartView Status, SmartView Tracker, SmartConsole, TurboCard, Application Intelligence, SVN, UAM, User-to-Address Mapping, UserAuthority, VPN-1, VPN-1 Accelerator Card, VPN-1 Net, VPN-1 Pro, VPN-1 SecureClient, VPN-1 SecuRemote, VPN-1 SecureServer, VPN-1 SmallOffice and VPN-1 VSX are trademarks or registered trademarks of Check Point Software Technologies Ltd. or its affiliates. All other product names mentioned herein are trademarks or registered trademarks of their respective owners. The products described in this document are protected by U.S. Patent No. 6,496,935, 5,606,668, 5,699,431 and 5,835,726 and may be protected by other U.S. Patents, foreign patents, or pending applications. THIRD PARTIES: Entrust is a registered trademark of Entrust Technologies, Inc. in the United States and other countries. Entrust s logos and Entrust product and service names are also trademarks of Entrust Technologies, Inc. Entrust Technologies Limited is a wholly owned subsidiary of Entrust Technologies, Inc. FireWall-1 and SecuRemote incorporate certificate management technology from Entrust. Verisign is a trademark of Verisign Inc. The following statements refer to those portions of the software copyrighted by University of Michigan. Portions of the software copyright Regents of the University of Michigan. All rights reserved. Redistribution and use in source and binary forms are permitted provided that this notice is preserved and that due credit is given to the University of Michigan at Ann Arbor. The name of the University may not be used to endorse or promote products derived from this software without specific prior written permission. This software is provided as is without express or implied warranty. Copyright Sax Software (terminal emulation only). The following statements refer to those portions of the software copyrighted by Carnegie Mellon University. Copyright 1997 by Carnegie Mellon University. All Rights Reserved. Permission to use, copy, modify, and distribute this software and its documentation for any purpose and without fee is hereby granted, provided that the above copyright notice appear in all copies and that both that copyright notice and this permission notice appear in supporting documentation, and that the name of CMU not be used in advertising or publicity pertaining to distribution of the software without specific, written prior permission.cmu DISCLAIMS ALL WARRANTIES WITH REGARD TO THIS SOFTWARE, INCLUDING ALL IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS, IN NO EVENT SHALL CMU BE LIABLE FOR ANY SPECIAL, INDIRECT OR CONSEQUENTIAL DAMAGES OR ANY DAMAGES WHATSOEVER RESULTING FROM LOSS OF USE, DATA OR PROFITS, WHETHER IN AN ACTION OF CONTRACT, NEGLIGENCE OR OTHER TORTIOUS ACTION, ARISING OUT OF OR IN CONNECTION WITH THE USE OR PERFORMANCE OF THIS SOFTWARE. The following statements refer to those portions of the software copyrighted by The Open Group. THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF MERCHANTABILITY, FITNESS FOR A PARTICULAR PURPOSE AND NONINFRINGEMENT. IN NO EVENT SHALL THE OPEN GROUP BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER LIABILITY, WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING FROM, OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR OTHER DEALINGS IN THE SOFTWARE. The following statements refer to those portions of the software copyrighted by The OpenSSL Project. This product includes software developed by the OpenSSL Project for use in the OpenSSL Toolkit ( THIS SOFTWARE IS PROVIDED BY THE OpenSSL PROJECT ``AS IS'' AND ANY * EXPRESSED OR IMPLIED WARRANTIES, INCLUDING, BUT NOT LIMITED TO, THE IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE ARE DISCLAIMED. IN NO EVENT SHALL THE OpenSSL PROJECT OR ITS CONTRIBUTORS BE LIABLE FOR ANY DIRECT, INDIRECT, INCIDENTAL, SPECIAL, EXEMPLARY, OR CONSEQUENTIAL DAMAGES (INCLUDING, BUT NOT LIMITED TO, PROCUREMENT OF SUBSTITUTE GOODS OR SERVICES; LOSS OF USE, DATA, OR PROFITS; OR BUSINESS INTERRUPTION) HOWEVER CAUSED AND ON ANY THEORY OF LIABILITY, WHETHER IN CONTRACT, STRICT LIABILITY, OR TORT (INCLUDING NEGLIGENCE OR OTHERWISE) ARISING IN ANY WAY OUT OF THE USE OF THIS SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF SUCH DAMAGE. The following statements refer to those portions of the software copyrighted by Eric Young. THIS SOFTWARE IS PROVIDED BY ERIC YOUNG ``AS IS'' AND ANY EXPRESS OR IMPLIED WARRANTIES, INCLUDING, BUT NOT LIMITED TO, THE IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE ARE DISCLAIMED. IN NO EVENT SHALL THE AUTHOR OR CONTRIBUTORS BE LIABLE FOR ANY DIRECT, INDIRECT, INCIDENTAL, SPECIAL, EXEMPLARY, OR CONSEQUENTIAL DAMAGES (INCLUDING, BUT NOT LIMITED TO, PROCUREMENT OF SUBSTITUTE GOODS OR SERVICES; LOSS OF USE, DATA, OR PROFITS; OR BUSINESS INTERRUPTION) HOWEVER CAUSED AND ON ANY THEORY OF LIABILITY, WHETHER IN CONTRACT, STRICT LIABILITY, OR TORT (INCLUDING NEGLIGENCE OR OTHERWISE) ARISING IN ANY WAY OUT OF THE USE OF THIS SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF SUCH DAMAGE. Copyright 1998 The Open Group. The following statements refer to those portions of the software copyrighted by Jean-loup Gailly and Mark Adler Copyright (C) Jean-loup Gailly and Mark Adler. This software is provided 'as-is', without any express or implied warranty. In no event will the authors be held liable for any damages arising from the use of this software. Permission is granted to anyone to use this software for any purpose, including commercial applications, and to alter it and redistribute it freely, subject to the following restrictions: 1. The origin of this software must not be misrepresented; you must not claim that you wrote the original software. If you use this software in a product, an acknowledgment in the product documentation would be appreciated but is not required. 2. Altered source versions must be plainly marked as such, and must not be misrepresented as being the original software. 3. This notice may not be removed or altered from any source distribution. The following statements refer to those portions of the software copyrighted by the Gnu Public License. This program is free software; you can redistribute it and/or modify it under the terms of the GNU General Public License as published by the Free Software Foundation; either version 2 of the License, or (at your option) any later version. This program is distributed in the hope that it will be useful, but WITHOUT ANY WARRANTY; without even the implied warranty of MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the GNU General Public License for more details.you should have received a copy of the GNU General Public License along with this program; if not, write to the Free Software Foundation, Inc., 675 Mass Ave, Cambridge, MA 02139, USA. The following statements refer to those portions of the software copyrighted by Thai Open Source Software Center Ltd and Clark Cooper Copyright (c) 2001, 2002 Expat maintainers. Permission is hereby granted, free of charge, to any person obtaining a copy of this software and associated documentation files (the "Software"), to deal in the Software without restriction, including without limitation the rights to use, copy, modify, merge, publish, distribute, sublicense, and/or sell copies of the Software, and to permit persons to whom the Software is furnished to do so, subject to the following conditions: The above copyright notice and this permission notice shall be included in all copies or substantial portions of the Software. THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF MERCHANTABILITY, FITNESS FOR A PARTICULAR PURPOSE AND NONINFRINGEMENT. IN NO EVENT SHALL THE AUTHORS OR COPYRIGHT HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER LIABILITY, WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING FROM, OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR OTHER DEALINGS IN THE SOFTWARE. Check Point Software Technologies Ltd. U.S. Headquarters: 800 Bridge Parkway, Redwood City, CA 94065, Tel: (650) Fax: (650) , info@checkpoint.com International Headquarters: 3A Jabotinsky Street, Ramat Gan, 52520, Israel, Tel: Fax: ,

3 Table Of Contents Chapter 1 Chapter 2 Chapter 3 Introduction to the Upgrade Process Before You Begin 11 Upgrading Successfully 12 Planning Your Upgrade Recommended Upgrade Flows 13 Deployments 13 SmartCenter Upgrade Before You Begin 17 Terminology 17 Tools 18 Built in Safety Measures and Tips 18 Planning SmartCenter Upgrades 19 Select the Basic or the Advanced Upgrade Method 19 Maintaining Backward Compatibility 20 SecurePlatform 20 backup 20 Syntax 20 Parameters 21 Using the Patch Utility to Upgrade Itself 21 Using TFTP 21 Not Using TFTP 21 Upgrading SecurePlatform via the Patch Utility 22 Using the CD 22 Without the CD 22 Basic SmartCenter Upgrade Procedure 23 Basic Upgrade Steps 23 Advanced SmartCenter Upgrade 24 Motivations for Performing Advanced Upgrade 24 Selecting a Manual Upgrade or an Automatic Upgrade 25 Advanced Upgrade Steps 26 Tools for Upgrading SmartCenters 27 Pre-Upgrade Verification 27 Action Items before the Upgrade 29 Action Items after the Upgrade 29 Information Messages 29 Advanced Upgrade on a Spare Machine Using the Command Line Interface 30 Export and Import Commands 32 SecurePlatform s Update Utility 32 Upgrading to a Different IP Address or Domain Name 33 Table of Contents 3

4 Notes, Exceptions and Limitations 37 After Performing an Advanced Upgrade 37 Upgrading with Management High Availability 38 Chapter 4 Chapter 5 Check Point Gateway Upgrades Before You Begin 39 Terminology 39 Tools for Gateway Upgrades 40 Planning a Check Point Gateway Upgrade 40 SecurePlatform 40 Upgrading to Windows 2003 Server from pre-2003 Server 40 Upgrading Modules with SecurePlatform 41 backup 41 Syntax 41 Parameters 41 Using the Patch Utility to Upgrade the Patch Utility Itself 42 Using TFTP 42 Not Using TFTP 42 Upgrading SecurePlatform via the Patch Utility 42 Using the CD 42 Without the CD 43 Using TFTP 43 Without TFTP 43 Using SmartUpdate to Upgrade SecurePlatform 43 Upgrading Check Point Gateways with SmartUpdate 44 Prerequisites for SmartUpdate Upgrade 44 Requirements for Upgrading Gateways from Version 4.1 SP2 44 Requirements for Upgrading Gateways from NG 44 Configuring the SmartCenter Server so that you can use SmartUpdate 44 Using SmartUpdate to Add Products to the Product Repository 45 Using SmartUpdate to Upgrade Remote Check Point Gateways 45 Updating All Products on a Check Point Gateway 45 Using SmartUpdate to Upgrade IPSO 46 Upgrading a Single Product on a Check Point Gateways 46 Upgrading Check Point Gateways In Place 47 First Upgrade your Operating System 47 Special Considerations for Manual Check Point Gateway Upgrade 47 Configuring OPSEC for Check Point Gateways 47 Automatic Update 48 Manual Update 49 ClusterXL Upgrade Before You Begin 51 Terminology 51 Tools for Gateway Upgrades 52 Planning a Cluster Upgrade 52 Working with a Mixed Cluster 53 Upgrading OPSEC Certified Third Party Clusters Products 53 4

5 Performing a Minimal Effort Upgrade on a ClusterXL Cluster 53 Performing a Zero Down Time Upgrade on a ClusterXL Cluster 54 Supported Modes 54 Planning your Zero Down Time Upgrade 54 Upgrade All But One of the Cluster Members 54 Upgrade the Final Cluster Member 56 Performing a Full Connectivity Upgrade on a ClusterXL Cluster 57 Understanding a Full Connectivity Upgrade 57 Supported Modes 57 Terminology 57 Pre-Requisite for using the Full Connectivity Upgrade 57 Full Connectivity Upgrade Limitations 57 Implementing a Full Connectivity Upgrade 59 Upgrading a cluster with 2 members 59 Upgrading a cluster with 3 or more members 59 Monitoring the Full Connectivity Upgrade 60 Reverting to Old Version of SVN Foundation, FireWall-1 or FloodGate-1 61 Nokia - Safely Removing NG 61 Other Product Roll Backs 62 Chapter 6 Chapter 7 SmartView Reporter Upgrade Before you begin 63 Terminology 63 Tools 64 How to back up your reports 64 How to stop log consolidator 64 How to backup the database 65 How to re-establish SIC between SmartCenter and SmartView Reporter 65 Safety 66 Planning 66 Performing a Basic SVR Upgrade 66 Stand Alone configuration 66 Distributed configuration 67 Performing an Advanced Upgrade 67 General notes on advanced upgrade 67 Standalone configuration 68 Distributed configuration 68 More Upgrade Configurations 69 Advance upgrade from one version of NG with Application Intelligence to another 69 Upgrade SmartCenter but leave SmartView Reporter in a previous version 69 NG with Application Intelligence (R54) 69 NG FP3 69 Upgrading the SQL Database 70 Log Server Upgrade Log Server Upgrades 73 SecurePlatform 73 Table of Contents 5

6 Chapter 8 Chapter 9 Upgrading SmartLSM Before You begin 75 Terminology 75 Tools 76 Export 76 LSM CLI 76 Safety 76 Planning 76 Upgrade your ROBO Gateways 76 Adding a ROBO Gateway Upgrade Package to the SmartUpdate Package Repository 77 Upgrading a ROBO Gateway Using SmartLSM 77 Upgrading a VPN-1 Express/Pro ROBO Gateway 77 Full Upgrade 78 Specific Install 78 Upgrading a VPN-1 Edge ROBO Gateway 79 Upgrading a VPN-1 ROBO Gateway Using the LSM CLI 79 Upgrading a VPN-1 Express/Pro ROBO Gateway Using the LSM CLI 79 Upgrading a VPN-1 Edge ROBO Gateway Using the LSM CLI 81 Using the LSMcli in Scripts 81 Upgrading a VPN-1 Express/Pro ROBO Gateway In Place 82 Upgrading Provider-1 Introduction 83 Scope 83 Before You Begin 83 Supported Platforms 84 Supported Versions for Upgrade 84 Summary of Sections in this Chapter 85 Provider-1/SiteManager-1 Upgrade Tools 85 Pre-Upgrade Verifiers and Fixing Utilities 85 Installation Script 86 Pre-Upgrade Verification Only 87 Upgrade 87 Backup 87 cma_migrate 87 Usage 88 Example 88 migrate_assist 89 Usage 89 Example 90 migrate_global_policies 90 Usage 90 Backup and Restore 91 mds_backup 91 Usage 92 mds_restore 92 Usage 92 6

7 Provider-1/SiteManager-1 Upgrade Practices 92 In-place Upgrade 92 Upgrading your Operating System 93 Replicate and Upgrade 93 Gradual Upgrade on the same machine - Version Preparations 94 Gradually Upgrading the Primary MDS 95 Upgrade Steps 96 Gradually Upgrading Additional MDSes 97 Gradual Upgrade to Another Machine 98 Upgrade steps 99 Gradual Upgrade with Global VPN Considerations 99 Migrating from Stand Alone installation to CMA 100 Terminology 100 An Overview of the Stand Alone Installation to CMA Migration Procedure 101 From a Version 4.1 Installation 102 From NG (All Feature Pack) Installation 106 Upgrading in a Multi MDS Environment 109 Pre-Upgrade Verification and Tools 109 Upgrading a Version 4.1 System with an Additional MDS 109 Upgrading an NG with Application Intelligence Multi-MDS System 110 MDS High Availability 110 Before the Upgrade 110 CMA High Availability 111 Restoring your Original Environment 111 Before the Upgrade 111 Restoring your original environment 111 Renaming Customers 112 Identifying Non-Compliant Customer Names 112 High-Availability Environment 112 Automatic Division of Non-compliant Names 112 Resolving the Non-compliance 113 Additional options menu 113 High-Availability 114 Advanced Usage 114 Changing MDS IP address and External Interface 115 IP Address Change 115 Interface Change 115 Appendix A Behavioral Changes in FireWall-1 Introduction to Behavioral Changes in FireWall Behavioral Changes In Stateful Inspection 118 TCP Connection reuse 118 Section Summary 118 Version 4.1 SP5 Solution 118 NG with Application Intelligence Solution 119 TCP Connection Establishment (three-way handshake) 119 Table of Contents 7

8 8 TCP Sequence Verification 120 Connections Recovery After Policy Installation 121 First TCP Packet 122 Stateless Checks 124 Default session timeouts 125 Section Summary 125 Behavioral Changes in NAT 126 Improvements in HIDE NAT Address 126 Version 4.1 SP5 Solution 126 NG with Application Intelligence Solution 126 IP Pools 127 Version 4.1 SP5 Solution 127 NG with Application Intelligence Solution 127 Transparent Server Connection (under NAT) 127 Improvements in Static NAT 128 New NAT properties in FireWall-1 NG 128 Allow Bidirectional NAT 128 Automatic ARP configuration 129 Behavioral Changes for Services Features 129 Match for Any 129 Time-out 130 Protocol Type 130 DNS Enforcement is Used by Default 130 Dynamic Port Negotiation Inspection (Well Known Port) 130 X11 Drop 131 New Service Features 131 Keep Connections During Policy Reload 131 Dropping X11 Traffic 132 SSHv2 and SSLv3 132 FTP Behavioral Changes 132 FTPbidir 132 FTPbasic 132 FTPnew Enforcement 133 FTP Passive and FTP Port 133 Behavioral Changes in INSPECT 133 NAT Rule-Match Performance 133 SmartCenter Behind NAT 133 Client-Side Translation 133 NAT for Dynamic Objects 134 Disable NAT Inside the VPN Community 134 Behavioral Changes in INSPECT 134 Backward compatibility note 134 Unknown established TCP packet 135 Description 135 Solution in Version Solution in NG with Application Intelligence 136 FTP Related INSPECT Solutions 136 FTP control NewLine enforcement 136 Description 136

9 Version 4.1 solution 137 Solution with NG with Application Intelligence 138 Changes to FTP control connection timeout 138 Description 138 Solution in Version Solution in NG with Application Intelligence 139 Preventing FTP data connection failures on server port check 139 Description 139 Solution in Version Solution in NG with Application Intelligence 140 Using FTP on non-standard ports 141 Description 141 Solution in Version Solution in NG with Application Intelligence 142 Backward Compatibility 142 Bi-direction FTP data connection 143 Solution in Version Solution in NG with Application Intelligence 144 Authentication related INSPECT solutions 144 Preventing re-authentication when a policy is installed. 144 Description 144 Version 4.1 Solution 144 Solution in NG with Application Intelligence 144 Removing RADIUS/LDAP/TACACS from Control Connections 145 Description 145 Solution in Version Solution in NG with Application Intelligence 147 Services Related INSPECT Solutions 147 Increasing services session timeout 147 Description 147 Version 4.1 Solution 148 Solution in NG with Application Intelligence 148 Backward Compatibility Issues for Services 148 Custom INSPECT Services 149 Overview 149 What to change 149 prologue 149 match 149 H.323 New service 150 Version 4.1 Solution 150 Solution in NG with Application Intelligence 150 GRE inspection 150 Version 4.1 Solution 150 Solution in NG with Application Intelligence 151 RSH STDERR back connections with ports lower than Description 151 Version 4.1 Solution 152 Solution in NG with Application Intelligence 152 DNS Verification 152 Table of Contents 9

10 10 Description 152 Version 4.1 Solution 152 Solution in NG with Application Intelligence 153 INSPECT Accounting solutions 153 Description 153 Version 4.1 Solution no Version 4.1 Solution no Solution in NG with Application Intelligence 156 Restricting Account Logging to the Account Log Viewer only 156 Description 156 Version 4.1 Solution 156 NG with Application Intelligence Solution 156 INSPECT and Load Balancing 157 Changes to persistency timeouts 157 Description 157 Version 4.1 Solution 157 NG with Application Intelligence Solution 157 INSPECT Tuning solutions 157 Changes to the connections table size 157 Description 157 Version 4.1 solution 157 NG with Application Intelligence solution 158 Changes to Kernel memory settings 158 Description 158 Solution in Version Solution in NG with Application Intelligence 160

11 CHAPTER 1 Introduction to the Upgrade Process In This Chapter Before You Begin Before You Begin page 11 Upgrading Successfully page 12 Welcome to the Upgrade Guide. We created this guide to explain all available upgrade paths for Check Point products from Versions 4.1 SP5 forward. This document is specifically geared towards upgrading to NG with Application Intelligence (R55). Before you begin please: Backup everything you will be upgrading. Make sure that you have the latest version of this document in the User Center at It is a good idea to have the latest version of the NG with Application Intelligence (R55) Release Notes handy. Download them from: If you are wondering what new features are available in NG with Application Intelligence (R55), read the What s New Guide : You can upgrade to NG only from Version 4.1 SP5 and higher. If you are running a version prior to 4.1 SP5, then proceed as follows: Upgrade from that version to Version 4.1 SP5. Upgrade from Version 4.1 SP5 to NG with Application Intelligence. 11

12 Upgrading Successfully Upgrading Successfully All successful upgrades begin with a solid game plan and a full understanding of the steps you need follow in order to succeed. This book provides graphics, tips and instructions to make the upgrade process as clear as possible. It is not necessary to read the entire book. In fact, there may be large portions of the book that do not apply to you because you do not own the product covered. The book is structured to show you common scenarios and then to provide the steps necessary for achieving your unique upgrade. We hope that your upgrade goes smoothly but in the event that you run into unexpected snags, please contact your Reseller or our SecureKnowledge support center at: 12

13 CHAPTER 2 Planning Your Upgrade In This Chapter Recommended Upgrade Flows Successful upgrading begins with a comprehensive upgrade plan, good organizational oversight and understanding your products. The purpose of this chapter is to provide you with a broad understanding of how your upgrade deployment fits into Check Point s products. After reading this short chapter, you will have a clearer idea of how to conceptualize and proceed with your upgrade. Deployments Recommended Upgrade Flows on page 13 What follows are four separate graphics depicting four Check Point upgrade deployments. In all four deployment, we suggest proceeding as follows: 1 Upgrade your management products: SmartCenter Server (and SmartConsole), SmartLSM or Provider-1 then SmartView Reporter and Log Server 2 Upgrade your enforcement products: Check Point gateways (individual modules or ClusterXL, ROBO Gateways) Below, find the graphic that most closely resembles your enterprise s deployment and follow the instructions in each of the corresponding chapters in this Upgrade Guide. 13

14 Recommended Upgrade Flows FIGURE 2-1 Upgrade a SmartCenter with Gateway(s) FIGURE 2-2 Upgrade a SmartCenter Server with SmartView Reporter, Gateway(s) and Cluster(s) 14

15 Deployments FIGURE 2-3 Provider-1 Upgrade FIGURE 2-4 Upgrade a SmartCenter Server with SmartLSM, Gateway(s) and Cluster(s) and ROBO Gateways Chapter 2 Planning Your Upgrade 15

16 Recommended Upgrade Flows 16

17 CHAPTER 3 SmartCenter Upgrade In This Chapter Before You Begin This chapter first goes through the steps to perform a basic upgrade, then goes through the steps to perform an advanced upgrade. Terminology Before You Begin page 17 Planning SmartCenter Upgrades page 19 SecurePlatform page 20 Basic SmartCenter Upgrade Procedure page 23 Advanced SmartCenter Upgrade page 24 Here are some useful terms that you need to be familiar with in order to continue reading this chapter: Security Policy - A Security Policy is created by the system administrator in order to regulate the incoming and outgoing flow of communication. Enforcement module - An Enforcement module is the engine of VPN-1 Pro which actively enforces the Security Policy of the organization. SmartCenter Server - The SmartCenter Server is the server used by the system administrator to manage the Security Policy. The databases and policies of the organization are stored on the SmartCenter Server, and are downloaded from time to time to the Enforcement module. 17

18 Before You Begin SmartConsole Clients - The SmartConsole Clients are different GUI applications which are used to manage different aspects of the Security Policy. For instance SmartView Tracker is a SmartConsole which manages logs. SmartDashboard - SmartDashboard is a SmartConsole which is used by the system administrator to create and manage the Security Policy. Tools Pre-Upgrade Verifier - The Pre-Upgrade verifier is a tool that provides you with a report. Three types of results are displayed in the report: Action items to perform before the upgrade Action items to perform after the upgrade Information Messages This tool is automatically run before both basic and advanced upgrades and can be run in preparation for upgrading. Further details regarding this tool are located in Pre-Upgrade Verification on page 27. Built in Safety Measures and Tips 1 Automatic pre-upgrade verification runs by default during your SmartCenter upgrade. The pre-upgrade verification notifies you of important adjustments to make before upgrading. If you prefer, you can run the pre-upgrade verification from the CD separately from the upgrade in order to prepare yourself for your upgrade. You will be provided with a report. Three types of results can be displayed in the report: action items before the upgrade, action items after the upgrade and information. Detailed explanations of these reports are outlined in SmartCenter Upgrade. We have also provided you with sample output from a pre-upgrade verification. It can be found in Pre-Upgrade Verification on page During the process of upgrading your SmartCenter, an optional automatic online check is performed that confirms that your SmartCenter has the most current upgrade information available. Before running the online check, you are prompted to confirm that you want to run it. 3 To add even more safety measures, upgrade your SmartCenter Server on a second machine. Then either: 18

19 Select the Basic or the Advanced Upgrade Method make the spare machine your production management machine or migrate back to the original machine. The steps for performing either of these types of upgrades are detailed in Advanced SmartCenter Upgrade on page Upgrades can be performed incrementally. You do not have to upgrade SmartCenter Server and all its modules all at once. A First upgrade the SmartCenter Server. B After the upgrade, you can still manage your modules from your SmartCenter Server. C At your convenience, the modules can be upgraded one-by-one. A module that has not been upgraded, will not yet have the latest features. 5 If for any reason you are not pleased with the results, restore your prior work environment. 6 If you have an upgrade that you would like to distribute from a central server, use SmartUpdate. Instructions for using SmartUpdate for upgrading are located in Chapter 4, Upgrading Your Gateway using SmartUpdate. 7 When upgrading SmartCenter Server, the database is adjusted to the format of the new version. This includes the formats for policies, objects, the global properties, etc. In addition, system objects which come with the new version are added to your database. The files containing these elements are not simply copied so you cannot copy these files from a previous version to a newer version. Planning SmartCenter Upgrades Select the Basic or the Advanced Upgrade Method First choose the type of upgrade that is right for you: Basic Upgrade: Perform the upgrade directly on to the production SmartCenter Server or Advanced Upgrade: Perform the upgrade on a spare machine, while the production SmartCenter Server is fully operational. Test the full functionality of the spare machine and either: replace the old server with the new or migrate the upgraded server back to replace the old server. Chapter 3 SmartCenter Upgrade 19

20 SecurePlatform Both the basic and advanced upgrade can be performed automatically from the Check Point CD. Maintaining Backward Compatibility Backwards Compatibility for management of: VPN-1 modules and FireWall-1 modules Is automatically built into NG with Application Intelligence s SmartCenter Server installation. SecurePlatform Upgrade of a SecurePlatform SmartCenter Server and all the Check Point products installed on it is done by simply applying the SecurePlatform upgrade package, which can be found either on the Singe CD containing the new version, or as a separate package downloadable from the download center: backup Before upgrading the SecurePlatform system, back up your system configuration using the backup utility: Syntax backup(system cp all) <name> [tftp <ip-address>] 20

21 Using the Patch Utility to Upgrade Itself Parameters TABLE 3-1 Parameters for SecurePlatform backup parameter system cp all name [tftp <ip-address>] meaning backup system configuration backup Check Point products configuration backup all of the configuration name of backup (to be restored to) IP address of tftp server on which the configuration will be backed up Using the Patch Utility to Upgrade Itself If you upgrade SecurePlatform from a version prior to NG with Application Intelligence (R54), you need to upgrade the Patch utility before using it to upgrade the SecurePlatform machine: Using TFTP 1 Download the Patch utility upgrade package from the download center: 2 Copy this file to a TFTP server Logon to the SecurePlatform machine (using Console or SSH access). Issue the following command line command: patch add tftp <ip> <update_name> <ip> is the <ip> of the TFTP Server s IP address and <update_name> is the name of the package downloaded. Not Using TFTP 1 Download the Patch utility upgrade package from the download center: 2 Logon to the SecurePlatform machine (using Console or SSH access). Enter the Expert shell. 3 Use FTP to transfer the Patch utility upgrade package to the SecurePlatform machine. Chapter 3 SmartCenter Upgrade 21

22 SecurePlatform 4 Issue the following command line command: patch add <Filename> where <Filename> is the exact filename (including full path) of the upgrade package. Upgrading SecurePlatform via the Patch Utility Using the CD If you have the CD of the new version you want to upgrade to, do the following: 1 Insert the CD into the CD ROM Drive on the SecurePlatform machine. 2 Logon to the SecurePlatform machine (using Console or SSH Access). 3 Issue the following command line command: patch add cd 4 Choose the SecurePlatform upgrade package, and follow the upgrade process instructions. Without the CD If you do not have the CD, you need to download the SecurePlatform upgrade package from the download center: Using TFTP 1 Copy the upgrade package file to a TFTP server. 2 Logon to the SecurePlatform machine (using Console or SSH access). Issue the following command line command: patch add tftp <ip> <update_name> <ip> is the <ip> of the TFTP Server s IP address and <update_name> is the name of the package downloaded. 3 Follow the upgrade process instructions. Without TFTP 1 Logon to the SecurePlatform machine (using Console or SSH access). Enter the Expert shell. 22

23 Basic Upgrade Steps 2 Use FTP to transfer the SecurePlatform upgrade package to the SecurePlatform machine. 3 Issue the following command line command: patch add <Filename> where <Filename> is the exact filename (including full path) of the upgrade package. Follow the upgrade process instructions. Basic SmartCenter Upgrade Procedure The Basic SmartCenter upgrade upgrades your installed products in order to replace your prior version of SmartCenter with NG with Application Intelligence. This upgrade automatically performs the pre-upgrade verification before upgrading. Further information on the pre-upgrade verification is offered later in the Pre-Upgrade Verification section. Select Basic Upgrade if your goal is to upgrade installed products in place. Basic Upgrade Steps 1 Access your Check Point CD. 2 Run setup 3 Select Upgrade from the Upgrade Options Screen. 4 You are presented with three upgrade options: A Download Most Updated Upgrade Utilities (recommended method) This download provides the most recent upgrade code available. B I have already downloaded and extracted the Upgrade Utilities. The files are on my local disk. This option is useful in two cases: When the SmartCenter is not connected to the Internet (for security or other reasons). Download the package from another machine and copy it to the SmartCenter. Chapter 3 SmartCenter Upgrade 23

24 Advanced SmartCenter Upgrade When you have already downloaded the package then you can use the package from the disk instead of downloading again. Always check to make sure that the downloaded version is the most recent version available. To check: C Use the CD version. This option can be used in two cases: if there are no updates for the upgrade package or if there are updates, but you prefer not to update. This is not the recommended method since using the most updated upgrade version is the safest choice. 5 The pre-upgrade verification recommendation appears. This is so that you can verify that your pre-upgrade meets the pre-conditions of the new software (see Pre-Upgrade Verification below). 6 Once the pre-upgrade verification completes, proceed with any suggested repairs. 7 Select Upgrade again from the Upgrade Options Screen. Another verification will run. 8 If prompted, reboot your SmartCenter Server. 9 Install SmartConsole Clients on your GUI Client machine. If you have a previous SmartConsole installed select either to: maintain the previous version of SmartConsole Clients or to overwrite the previous SmartConsole Clients. Note - A backwards compatibility package for managing 4.1 Check Point Gateways is installed automatically with the installation wrapper. Advanced SmartCenter Upgrade Moving to a new spare machine during an upgrade with the same IP address and DNS name can be done automatically and smoothly. Like the Basic Upgrade, the Advanced Upgrade automatically performs pre-upgrade verification before upgrading. Motivations for Performing Advanced Upgrade There are two key motivations for performing an advanced upgrade: 1 Moving to a spare machine that will become the primary server because: 24

25 Selecting a Manual Upgrade or an Automatic Upgrade perhaps you have a newer server and/or a more powerful server and/or a server with a different operating system Platform and Operating System Switching While upgrading SmartCenter, you can switch platforms and operating systems. Example If you were running a 4.1 SP5 SmartCenter Server on a Windows operating system, you can upgrade to NG with Application Intelligence on SecurePlatform. For more platform specific information see Platform Specific Upgrade Notes. or 2 To ensure that your production machine is always up and safe you have decided to upgrade a spare machine and then you plan to migrate back to the original machine. Both of these types of advanced upgrades begin with the same steps as presented in TABLE 3-2 on page 26. Selecting a Manual Upgrade or an Automatic Upgrade Any upgrade that you can do automatically via SmartCenter (Chapter 3, SmartCenter Upgrade on page 17) can also be run from the command line. However, for the sake of ease, performing your upgrade from the command line is not recommended when you can use the Automatic Upgrade. There are two types of upgrades that cannot be performed automatically and some valid reasons you may need to consider a manual upgrade: If your SmartCenter Server is IPSO or If you upgraded a spare system and want to migrate your upgraded SmartCenter Server back to your original SmartCenter Server. Chapter 3 SmartCenter Upgrade 25

26 Advanced SmartCenter Upgrade Advanced Upgrade Steps TABLE 3-2 Steps for performing an Advanced upgrade on another SmartCenter Server machine to perform steps on Old SmartCenter Server steps to follow Insert the CD into SmartCenter Server. 2. Select Export in Upgrade Options 3. You are presented with three upgrade options: A Download Most Updated Upgrade Utilities (recommended method) Files are not upgraded they are updated. This download provides the most recent upgrade code available. B I have already downloaded and extracted the Upgrade Utilities. The files are on my local disk. This option is useful: When the SmartCenter is not connected to the Internet (for security or other reasons). Download the package from another machine and copy it to the SmartCenter. When you have already downloaded the package then you can use the package from the disk instead of downloading again. Always check to make sure that the downloaded version is the most recent version available. To check, visit: /ut/r55/index.html C Use the CD version. This option can be used in two cases: if there are no updates for the upgrade package or if there are updates, but you prefer not to update. This is not the recommended method since using the most updated upgrade version is the safest choice. 26

27 Tools for Upgrading SmartCenters TABLE 3-2 Steps for performing an Advanced upgrade on another SmartCenter Server machine to perform steps on Old SmartCenter Server (cont...) spare machine steps to follow Select the destination path of the configuration (.tgz) file. 5. Wait while exporting database files. 6. Copy the exported.tgz file to the spare machine. 7. Insert the CD into the spare machine. 8. Select Installation using Imported Configuration in the Installation Options. This option prompts you for the location of the imported configuration file (.tgz) file and then automatically installs the new software and utilizes the imported.tgz configuration file. Migrating back or changing IP address and DNS name Warning - The configuration file (.tgz) file contains your security configuration. It is highly recommended to delete it after completing the import process. Steps for migrating back to your new server can be found in Upgrading to a Different IP Address or Domain Name on page 33. If you want to change the IP address and DNS name of the SmartCenter during the upgrade see Upgrading to a Different IP Address or Domain Name on page 33. Tools for Upgrading SmartCenters Pre-Upgrade Verification During basic or either of the two phases of advanced upgrades, a pre-upgrade verification is automatically performed. If you prefer, you can run the pre-upgrade verification from the CD separately from the upgrade in order to prepare yourself for your upgrade. Pre-upgrade verification provides you with a report. Three types of results can be displayed in the report and are listed below. Chapter 3 SmartCenter Upgrade 27

28 Advanced SmartCenter Upgrade Pre Upgrade-Verifier CLI Commands Usage: pre_upgrade_verifier.exe -p SmartCenterPath -c CurrentVersion -t TargetVersion [-f FileName] [-w] or pre_upgrade_verifier.exe -p SmartCenterPath -c CurrentVersion -i[-f FileName][-w] Where the currently installed version is one of the following: 4.1 NG NG_FP1 NG_FP2 NG_FP3 NG_AI The target version is one of the following: NG_FP1 NG_FP2 NG_FP3 NG_AI -p Path of the installed SmartCenter Server (FWDIR) -c Currently installed version -t Target version -i Check originality of INSPECT files only -f Output in file -w Web format file NG_AI_R55 (NG_AI represents Next Generation with Application Intelligence) and -f redirects the standard output to a file. 28

29 Tools for Upgrading SmartCenters Sample output from an actual pre-upgrade verification test can be found in Sample of Pre-Upgrade Verifier Output on page 31. Action Items before the Upgrade errors Items that must be repaired before performing the upgrade. If you proceed with the upgrade while errors exist, your upgrade will fail. warning Items that you should consider repairing before performing the upgrade. Action Items after the Upgrade These items should be fixed once the upgrade is completed before the first policy installation. errors Items that must be repaired after performing the upgrade. warning Items that you should consider repairing after performing the upgrade. Information Messages Items that should be noted. Chapter 3 SmartCenter Upgrade 29

30 Advanced SmartCenter Upgrade TABLE 3-3 Advanced Upgrade on a Spare Machine Using the Command Line Interface Steps for performing an Advanced upgrade on another SmartCenter Server via the command line interface machine to perform steps on Old SmartCenter Server spare machine steps to follow Download the most recent files. 2. Run the Pre-upgrade Verifier tool and fix the relevant issues (see Pre Upgrade-Verifier CLI Commands on page 28). 3. Run the Export tool (see Export Usage on page 32). 4. Copy the exported files to the spare machine. 5. Install the NG with Application Intelligence versions of the exact same products that you had on your old SmartCenter Server. 6. Copy the exported file from SmartCenter Server into the spare machine. 7. Run the Import tool. (see Import Usage on page 32) If you wish to migrate back to your original SmartCenter Server continue with the following steps: TABLE 3-4 Command Line Steps to Migrate Back to your Old SmartCenter Server machine to perform steps on spare machine Old SmartCenter Server steps to follow Run the Export tool (see Export Usage on page 32) 9. Copy the exported file to the original machine. 10.Update the software by using the CD Installation Wrapper to select Import from the Upgrade Options Screen or use the command line as explained in the Check Point Individual Installations Guide. If you install products individually, install the NG with Application Intelligence versions of the exact same products that you had on your old configuration. 11.Run the Import tool (see Import Usage on page 32) 30

31 Tools for Upgrading SmartCenters Sample of Pre-Upgrade Verifier Output Action items before the upgrade Errors: Correct the following problems in order to have a working environment. Duplicated Objects Description: The object appears more than once in the database. Impacts: Using duplicate objects will cause problems in the SmartDashboard. To do: Rename one of the objects before starting the upgrade process. This problem will occur in the following objects "shilog" appears twice under network_objects and services Warnings: It is recommended to resolve the following problems. Cluster New Module Description: From FP3 we have centralized the cluster data. Many attributes that were taken from the members are now taken from the cluster object. Impacts: In the upgrade process the cluster data will be taken from one of the cluster members, if the data is not similar on all members it can lead to problems. Todo: Make sure that all members of a cluster are identical. Make sure the following attributes appear: SYNDefender properties, Authentication properties (next http proxy configuration), SAM properties, NAT IP Pools properties, SMTP properties Information: Embedded Devices Description: This type of Embedded Device is not supported any more. Impacts: After upgrade the objects will appear as 4.0 modules with the same name. The objects will still be visible via SmartDashboard (as 4.0 modules), but Install Policy on these modules will be blocked. Todo: Not applicable. This problem will occur in the following Embedded Devices: "Chicago-Dallas-FW" "Dallas-Chicago-FW" Chapter 3 SmartCenter Upgrade 31

32 Advanced SmartCenter Upgrade Export and Import Commands Import and Export tools are located under $FWDIR/bin/upgrade_tools. Export Usage Where: upgrade_export [-d] [-h] [-v] <exported file path> <exported file path> - the path to export the DB (default-local path) -d - prints debug information -h - prints this usage -v - prints the version Import Usage upgrade_import [-d] [-h] <path> Where: <path> - The location of the exported file -v - Prints the version -d - Prints debug information -h - Prints this usage SecurePlatform s Update Utility Upgrades to SecurePlatform can be done In Place using the Update utility. The upgrade process upgrades the SecurePlatform Operating System and all Check Point components are automatically installed. Upgrading individual components, such as upgrading only FloodGate-1, is not a supported feature on SecurePlatform. Using the Local Patch utility The Update utility uses a package in the CD: 1 Login to the SecurePlatform machine, and enter the expert command to enter Expert mode. Issue the following command line command: patch add cd <update_name> In this case<update_name> is the name of the package downloaded. 32

33 Upgrading to a Different IP Address or Domain Name Upgrading SecurePlatform via the Patch Utility This method of upgrading SecurePlatform uses a package downloaded from the download center: 1 Download the package to another computer that has a TFTP server running on it. 2 Logon to the SecurePlatform machine. Issue the following command line command: patch add tftp <ip> <update_name> <ip> is the <ip> of the TFTP Server s IP address and <update_name> is the name of the package downloaded. Using the Patch Utility to Upgrade Itself The patch utility can upgrade itself: 1 Upgrade the patch utility itself by using the patch upgrade package. 2 Upgrade the SecurePlatform machine (by using the SecurePlatform upgrade package). Using Advanced Upgrade Utilities (Pre-Upgrade Verifier, Export and Import) These utilities are available for SecurePlatform s use only through the local update utility. From a Pre-NG with Application Intelligence machine Run the patch add cd... command and choose to update SecurePlatform. The Upgrade wrapper will appear and all the utilities will be available. From a NG with Application Intelligence machine Run the update wrapper command to get access to the Upgrade Wrapper (that's already installed on your machine). From an Image File If you want to import an image you have exported from another computer, install SecurePlatform. During the First Time Installation Wizard runs, you'll get the option to import an image instead of specifying which packages to install. Upgrading to a Different IP Address or Domain Name This section specifies the steps that should be taken in case the spare machine has a different IP address or host name or you migrate back with a different IP address. Chapter 3 SmartCenter Upgrade 33

34 Advanced SmartCenter Upgrade TABLE 3-5 Advanced Upgrade Options for Different IP Address or Domain Name machine to perform steps on SmartCenter Server Spare Machine steps to follow Add rules that will allow the new spare machine to access the modules it is managing. Do this by creating a SmartCenter Object that includes the spare machine's IP address according to your software version: From the Policy Editor: Manage > Network Objects > New > Workstation and mark it as a Management Station. NG FP1 - From the Policy Editor: Manage > Network Objects > New... > Workstation and mark it as a Secondary Management. NG FP2 or higher - From SmartDashboard (Policy Editor) Manage > Network Objects > New > Check Point > Host/Gateway and mark it as Secondary SmartCenter. If this object already exists Make sure it is marked as a Management. 2. Create a rule, on the SmartCenter Server, which allows FireWall-1 and CPD (NG only) services from the above object you have just created, to go to all managed gateways. 3. Install the rule on all managed gateways. 4. Delete the rule once you have completed this process: Via the Wrapper: AInsert the CD into SmartCenter Server. B.Select Export configuration to another machine. C.Select the destination path of the configuration (.tgz) file. D.Copy the exported file to the spare machine. Via the Command Line: AUse steps 1-4 in TABLE 3-3 on page 30. Via the Wrapper: AInsert the CD into the spare machine. B.Select Advanced Upgrade This option prompts you for the location of the imported configuration file (.tgz) file and then automatically installs the new software and utilizes the imported.tgz configuration file. 34

35 Upgrading to a Different IP Address or Domain Name machine to perform steps on Spare Machine (cont...) steps to follow... Via the Command Line: Use steps 5-7 in TABLE 3-3 on page Reboot 2. If you are using a spare machine and plan on migrating back to your original SmartCenter Server skip to TABLE 3-6 on page From the UserCenter move your licenses from the original SmartCenter Server. The license of the SmartCenter should be updated with the new IP Address. If central licenses are used for the modules they should also be updated to the new IP Address. This can be done via the User Center at: by choosing the action License / Move IP / Activate Support and Subscription 4. Start the SmartCenter Server on the spare machine by applying the cpstart command 5. Connect to the SmartDashboard (Policy Editor) 6. If you upgraded from: 4.1- Replace all occurrences of the production object with the newly created spare machine object. You can find all occurrences with the Where Used utility (right-click on the object to choose the command). If your SmartCenter is Stand Alone then: 1 After upgrading, open the Spare Machine object and select VPN-1. 2 Manually set all VPN-1 settings. 3 Define the Traditional Mode configuration so that Backwards Compatibility to Version 4.1 is selected. DNS Server 4 Create Internal CA using cpconfig and create IKE certificates for all modules. NG-Update the primary SmartCenter object, with its IP Address and topology to match its new configuration. 7. Remove the object you created in TABLE 3-3 on page If you are using a spare machine and plan on migrating back to your original SmartCenter Server you are done. Otherwise see Upgrading to a Different IP Address or Domain Name on page On the DNS Server map the Primary SmartCenter Server s DNS to the new IP Address. Chapter 3 SmartCenter Upgrade 35

36 Advanced SmartCenter Upgrade If you wish to migrate back to your original SmartCenter Server (that has the original IP Address) continue with the following steps: TABLE 3-6 Migrating back to your original SmartCenter Server machine to perform steps on steps to follow... SmartCenter Server 1. Add rules that will allow the new spare machine to access the modules it is managing. Do this by creating a SmartCenter Object that includes the spare machine's IP address according to your software version: From the Policy Editor: Manage > Network Objects > New > Workstation and mark it as a Management Station. NG FP1 - From the Policy Editor: Manage > Network Objects > New... > Workstation and mark it as a Secondary Management. NG FP2 or higher - From SmartDashboard (Policy Editor) Manage > Network Objects > New > Check Point > Host/Gateway and mark it as Secondary SmartCenter. If this object already exists Make sure it is marked as a Management. 2. Create a rule, on the SmartCenter Server, which allows FireWall-1 and CPD (NG only) services from the above object you have just created, to go to all managed gateways. 3. Install the rule on all managed gateways. 4. Delete the rule once you have completed this process. 5. Use steps 1-4 in TABLE 3-3 on page 30. Spare Machine 6. Use steps 5-7 in TABLE 3-3 on page Reboot 8. Start the SmartCenter Server on the spare machine by applying the cpstart command 9. Connect to the SmartDashboard (Policy Editor) 10.Update the primary SmartCenter Object, with its IP Address and topology to match its new configuration. 11.Remove the object you created in Step 1 in this section. 36

37 Notes, Exceptions and Limitations Notes, Exceptions and Limitations 1 Adjust masters and log servers for each module before installing a policy on it. You should add the spare machine's object to the masters list, and if needed, add it to the log servers list on each module. 2 Re-establish trust with any 4.1 module by using the putkey command. 3 If both SmartCenter Servers are used simultaneously and have two IP addresses, and changes are done to both, these changes cannot be merged automatically. To synchronize them, manually apply all changes to objects and policies. 4 Special care should be given to operations that involve Check Point internal CA modifications, like issuing or revoking certificates. These changes cannot be merged, even manually, and will result in different CA databases on both servers. For example, revoking a certificate on one SmartCenter Server will add it to the CRL on that SmartCenter Server, but there is no way to add this certificate to the other CRL. It is highly recommended not to perform any such changes as long as both SmartCenter Servers are in use. After Performing an Advanced Upgrade Checking to make sure your Database Works Properly 1 Install the Security Policy on all Modules Fetch information is removed during upgrade. After upgrading, you must start SmartConsole and install the Security Policy on all modules, even if there has been no change in the Security Policy. Otherwise the module will try to fetch an old policy from the SmartCenter Server and after the upgrade, the module will not have a policy to fetch. 2 Open the two Check Point monitoring clients: SmartView Status - to check that your connections with modules is correct and SmartView Tracker - to check that you are receiving logs from modules correctly. Flush ARP Tables After swapping the machines, flush the ARP tables on the router (if it is a gateway) and on other hosts that communicate with the new machine. Otherwise it can take a few minutes until the ARP entries are renewed and subsequently, connectivity is resumed. Chapter 3 SmartCenter Upgrade 37

38 Upgrading with Management High Availability Upgrading with Management High Availability To upgrade the Check Point software on a group of High Availability SmartCenter Servers, proceed as follows: 1 Synchronize all the SmartCenter Servers (from Global Properties > Management High Availability). 2 Upgrade the Management Server software on all the SmartCenter Servers. 3 Open the Check Point s SmartConsole Client on one of the SmartCenter Servers. 4 In the General page of each of the other SmartCenter Server s Gateway Properties window, set the correct Check Point Products Version. 5 Once again, synchronize all the SmartCenter Servers (from Global Properties > Management High Availability). 38

39 CHAPTER 4 Check Point Gateway Upgrades In This Chapter Before You Begin Terminology Before You Begin page 39 Planning a Check Point Gateway Upgrade page 40 Upgrading Check Point Gateways with SmartUpdate page 44 Upgrading Modules with SecurePlatform page 41 Upgrading Check Point Gateways In Place page 47 Configuring OPSEC for Check Point Gateways page 47 Check Point Gateway - otherwise known as an Enforcement module or sometimes module is the VPN-1 Pro engine that actively enforces your organizations Security Policy. SmartUpdate - SmartUpdate allows you to centrally upgrade and manage Check Point software and licenses. Product Repository - This is a SmartUpdate repository on the SmartCenter Server that stores uploaded products (like VPN-1 Pro or FloodGate-1). These products are then used by SmartUpdate to perform upgrades of Check Point Gateways. In Place - In Place upgrades are upgrades performed directly on a product without the benefit of SmartUpdate. SmartUpdate is the recommended Check Point upgrade tool. 39

40 Planning a Check Point Gateway Upgrade ClusterXL - There is a separate ClusterXL Upgrade chapter if you have clusters to upgrade. ClusterXL is a software-based load sharing or high availability solution for Check Point gateway deployments. Tools for Gateway Upgrades SmartUpdate is the primary tool used for upgrading Check Point Gateways. Within SmartUpdate, there are some features and tools for your convenience: 1 SmartUpdate s Upgrade All Products Feature - This feature allows you to upgrade all products installed on a gateway. For IPSO and SecurePlatform, this feature also allows you to upgrade your Operating System as a part of your upgrade. 2 SmartUpdate s Add New Product Tools - SmartUpdate provides three tools for adding products to the Product Repository: Add From Download Center - an online download Add From CD - add a new product from the Check Point CD Import File - add a new product that you have stored locally. 3 SmartUpdate s Get Check Point Gateway Data - This tool updates SmartUpdate with the current Check Point or OPSEC third party products installed on a specific gateway or for your entire enterprise. Planning a Check Point Gateway Upgrade There are two options available to you when upgrading a Check Point Gateway: SmartUpdate - SmartUpdate is the recommended upgrade procedure because it allows you to centrally upgrade your Check Point Gateways quickly and safely. In Place - If you did not purchase SmartUpdate, you can upgrade your Check Point Gateways in place by performing a local upgrade on each individual Check Point Gateway. SecurePlatform If you use SecurePlatform, please go directly to the Upgrading Modules with SecurePlatform instructions. Upgrading to Windows 2003 Server from pre-2003 Server If you are upgrading either a Check Point FireWall-1 Module or a Stand Alone implementation from pre-windows 2003 Server to a Windows 2003 Server, proceed as follows: 40

41 backup 1 Upgrade Check Point software to NG with Application Intelligence (R55) without upgrading your operating system. 2 Then upgrade your Operating System to Windows Switch to the %FWDIR%\boot\modules directory. 4 Run the following command on the Check Point module machine: fwkern.exe -update CP_FW1MP %FWDIR%\boot\modules\netfw1xpm.inf Upgrading Modules with SecurePlatform Upgrade of a SecurePlatform module machine (and all the Check Point products installed on it) is done by simply applying the SecurePlatform upgrade package, which can be found either on the Singe CD containing the new version, or as a separate package downloadable from the download center: backup Before upgrading the SecurePlatform system, back up your system configuration using the backup utility: Syntax backup(system cp all) <name> [tftp <ip-address>] Parameters TABLE 4-1 Parameters for SecurePlatform backup parameter system cp all name [tftp <ip-address>] meaning backup system configuration backup Check Point products configuration backup all of the configuration name of backup (to be restored to) IP address of tftp server on which the configuration will be backed up If you purchased SmartUpdate, the simplest way to upgrade your SecurePlatform based Check Point Gateway is through the Upgrade All Products feature in SmartUpdate. Upgrading Check Point Gateways with SmartUpdate on page 44. If you prefer not to use SmartUpdate, access the SecurePlatform machine via Console or SSH and upgrade it through the Patch utility. Chapter 4 Check Point Gateway Upgrades 41

42 Upgrading Modules with SecurePlatform Using the Patch Utility to Upgrade the Patch Utility Itself If you upgrade SecurePlatform from a version prior to NG with Application Intelligence R54, you need to upgrade the Patch utility before using it to upgrade the SecurePlatform machine: Using TFTP 1 Download the Patch utility upgrade package from the download center: 2 Copy this file to a TFTP server. 3 Logon to the SecurePlatform machine (using Console or SSH access). Issue the following command line command: patch add tftp <ip> <update_name> <ip> is the IP address of the TFTP Server s IP address and <update_name> is the name of the package downloaded. Not Using TFTP 1 Download the Patch utility upgrade package from the download center: 2 Logon to the SecurePlatform machine (using Console or SSH access). Enter the Expert shell. 3 Use FTP to transfer the Patch utility upgrade package to the SecurePlatform machine. 4 Issue the following command line command: patch add <Filename> where <Filename> is the exact filename (including full path) of the upgrade package. Upgrading SecurePlatform via the Patch Utility Using the CD If you have the CD of the new version you want to upgrade to, do the following: 1 Insert the CD into the CD ROM Drive on the SecurePlatform machine. 2 Logon to the SecurePlatform machine (using Console or SSH Access). 42

43 Using SmartUpdate to Upgrade SecurePlatform 3 Issue the following command line command: patch add cd 4 Choose the SecurePlatform upgrade package, and follow the upgrade process instructions. Without the CD If you do not have the CD, you need to download the SecurePlatform upgrade package from the download center: Using TFTP 1 Copy the upgrade package file to a TFTP server. 2 Logon to the SecurePlatform machine (using Console or SSH access). Issue the following command line command: patch add tftp <ip> <update_name> <ip> is the IP address of the TFTP Server s IP address and <update_name> is the name of the package downloaded. 3 Follow the upgrade process instructions. Without TFTP 1 Logon to the SecurePlatform machine (using Console or SSH access). Enter the Expert shell. 2 Use FTP to transfer the SecurePlatform upgrade package to the SecurePlatform machine. 3 Issue the following command line command: patch add <Filename> where <Filename> is the exact filename (including full path) of the upgrade package. 4 Follow the upgrade process instructions. Using SmartUpdate to Upgrade SecurePlatform Once you are familiar with this chapter outlining the SmartUpdate upgrade process, proceed as follows: 1 Add the SecurePlatform upgrade package to the SmartUpdate repository. Chapter 4 Check Point Gateway Upgrades 43

44 Upgrading Check Point Gateways with SmartUpdate 2 Select Products > Upgrade All Products and select the target SecurePlatform machine. Upgrading Check Point Gateways with SmartUpdate Prerequisites for SmartUpdate Upgrade For the Check Point Gateways and the SmartCenter Server, obtain licenses from the User Center at Requirements for Upgrading Gateways from Version 4.1 SP2 VPN-1/FireWall SP2 (or higher). An fw putkey connection between the SmartCenter Server and version 4.1 SP2 remote Check Point Gateways. CPutil must be installed and configured. This is required for CPRID, which is needed for all remote product operations. The CPutil package and associated Release Notes are available on the Check Point 2000 CD and from In order to establish the CPRID connection with the 4.1 Check Point Gateway, a utility was added to the SmartCenter Server called opsec_putkey. The command should be executed from the utility directory $CPDIR/database/cprid/cprid_util_keys after configuring the CPutil on the remote Check Point Gateway: opsec_putkey -ssl -p <password - as configured on module> -port <module IP> Requirements for Upgrading Gateways from NG Ensure that there is Secure Internal Communication between the SmartCenter Server and the Check Point Gateways to be upgraded. Reboot your upgraded SmartCenter Server. Configuring the SmartCenter Server so that you can use SmartUpdate 3 Install the latest version of the SmartConsole, including SmartUpdate. 4 For a new SmartCenter Server installation, install on the SmartCenter Server (using the CPConfig configuration tool or the cplic put command): the NG SmartCenter license and 44

45 Using SmartUpdate to Upgrade Remote Check Point Gateways the SmartUpdate license. The SmartUpdate license is needed for product management capabilities. 5 Define the remote Check Point Gateways in SmartDashboard (for a new SmartCenter Server installation). 6 Make sure that the Administrator SmartUpdate permissions (as defined in the cpconfig configuration tool) are Read/Write. Alternatively, log in as root. 7 To upgrade version NG and above Check Point Gateways, ensure that in SmartDashboard, in the Policy Global Properties window in the FireWall-1 Implied Rules page, Accept CPRID Connections (SmartUpdate) is checked. By default, it is checked. 8 To upgrade version 4.1 Check Point Gateways, add a rule in the SmartDashboard to Accept CPRID Connections (ANY ANY FW1_CPRID Accept) Using SmartUpdate to Add Products to the Product Repository Use SmartUpdate to add products to (and delete) products from the Product Repository. Products can be added to the Repository: directly from the Check Point Download Center web site (by selecting Product > New Product > Add From Download Center...), by adding them from the Check Point CD (Product > New Product > Add From CD...), and by importing a file (Product > New Product > Import File...). When adding the product to the Product Repository, the product file is transferred to the SmartCenter Server. The Operation Status window opens. Use it to verify the success of the operation. The Product Repository is then updated to show the new product object. Using SmartUpdate to Upgrade Remote Check Point Gateways Updating All Products on a Check Point Gateway All Check Point NG products on a Check Point Gateway, including the operating system for Nokia IPSO and SecurePlatform can be remotely updated to the latest version in a single operation. 1 From SmartUpdate > select Products > Upgrade All Products and select one or more Check Point Gateways. The requested operation is verified by checking the following: Chapter 4 Check Point Gateway Upgrades 45

46 Upgrading Check Point Gateways with SmartUpdate The required products of the latest version are in the Product Repository. All Check Point products installed on the Check Point Gateways are of the same NG version. Verification of the installation logic, sufficient disc space, and a cprid (Check Point Remote Installation Daemon) connection to the Check Point Gateway. 2 If verification is successful, the Upgrade All Products window opens showing the currently installed products and the products to be installed on the chosen Check Point Gateways. If one or more of the required products are missing from the Product Repository, SmartUpdate will open the Download Products window. You can then download the required product directly to the Product Repository. Note that the Reboot Check Point Gateway After Installation option (checked by default) is required in order to activate the newly installed product. 3 Click Upgrade. The Operation Status window opens and shows the progress of the operation. Each operation is represented by a single entry. Double click the entry to open the Operation Details window which shows the operation history. Using SmartUpdate to Upgrade IPSO Proceed as follows: 1 Add the Nokia IPSO image package to the SmartUpdate repository. Nokia IPSO images can be obtained from the Nokia website: 2 Check Point Product Packages for IPSO. 3 Make sure that the $SUDIR/conf/IPSO_VER.txt file on the SmartCenter Server is updated with the IPSO OS Package version you want to install and exists in the repository. 4 Select Products > Upgrade All Products and select the target Nokia machine. Upgrading a Single Product on a Check Point Gateways Use this procedure to upgrade version 4.1 SP2 products. Proceed as follows: 1 Drag and drop the latest version of SVN Foundation from the Product Repository over the Check Point Gateway object in the Products tab. Follow the progress of the operation in the Operation Status window 46

47 First Upgrade your Operating System 2 Drag and drop the latest version of each of the desired Check Point products, one at a time, from the Product Repository over the Check Point Gateway object in the Products tab. Follow the progress of the operation in the Operation Status window. Upgrading Check Point Gateways In Place Upgrading Check Point s enforcement Check Point Gateways manually for distributed installations without the benefit of using SmartUpdate requires you to take care of some of the steps that are taken care of automatically by SmartUpdate. This chapter outlines a basic upgrade and includes special steps to use if you are upgrading manually. It also offer some advice for minimizing your downtime during an upgrade. First Upgrade your Operating System If you plan to upgrade your operating system, do it before upgrading your Check Point Gateway. Place the CD in your CD ROM drive and follow the straightforward instructions in the installation wizard. Once you have successfully completed the installation, reboot your machine. During an In Place (or SmartUpdate) Check Point Gateway upgrade only the kernel and daemons are replaced, SIC is maintained. Special Considerations for Manual Check Point Gateway Upgrade 1 If you manually upgrade the Check Point Gateway, update the version of the objects representing the Check Point Gateways in SmartDashboard to NG with Application Intelligence (R55) via the General page of its Check Point Gateway window. 2 SAM (Suspicious Activities Monitoring) dynamic rules are not automatically upgraded from 4.1 to NG with Application Intelligence. Instructions follow: Configuring OPSEC for Check Point Gateways This section addresses users who upgraded VPN-1 Pro Check Point Gateways from 4.1 SP5 which have CVP or UFP servers. The CVP or UFP servers may be in a load sharing configuration. The section also addresses users who use the SAM proxy feature. During the VPN-1 Pro Check Point Gateway upgrade, some of the data contained in the fwopsec.conf is moved or modified. The rest of the data in this file should be either manually or automatically updated in the SmartCenter s database. Chapter 4 Check Point Gateway Upgrades 47

48 Upgrading Check Point Gateways In Place Automatic Update The upgrade_fwopsec tool automatically performs the set of updates that you can read about in detail in the following Manual Update section. The tool works on the fwopsec.v4x file. This is a backup of the original fwopsec.conf file before it is modified by the VPN-1 Pro Check Point Gateway upgrade. 1 Make sure that the SmartDashboard application is closed before running upgrade_fwopsec. 2 Confirm that SIC communication is established between the SmartCenter Server and the VPN-1 Pro Check Point Gateway. 3 Run upgrade_fwopsec on the SmartCenter Server Sample command run from SmartCenter where SIC has been established: upgrade_fwopsec -fw <module object name> -fetch -f conf/fwopsec.v4x Explanation of Sample Command: This command fetches $FWDIR/conf/fwopsec.v4x from the Check Point Gateway and updates SmartCenter's database. The program will print the operations and the results. 4 Install the policy on the Check Point Gateway. TABLE 4-2 upgrade_fwopsec options parameter -mgmt mgmt_host meaning The name of the SmartCenter Server (default is localhost). -u user The administrator s name. The administrator must have write permission. -p password The user s password (the password used for the GUI Management Client). 48

49 Manual Update parameter [-fwm fw_obj_name [-fetch]] Manual Update meaning fw_obj_name is the name of the Check Point Gateway object (as specified in the VPN-1/FireWall-1 SmartDashboard) to which the configuration information applies. If -fetch is specified, then the information will be retrieved from fwopsec_file on the Check Point Gateway; otherwise upgrade_fwopsec will retrieve it from the SmartCenter Server (the local machine on which this command is run). -f fwopsec_file The path to the file containing the configuration information, usually fwopsec.v4x. If the -fetch option is used, then fwopsec_file specifies the file s path relative to the remote Check Point Gateway s $FWDIR. [-log log_file -nolog] Log the upgrade process to log_file (default is $FWDIR/tmp/<fw_obj_name>.upg_opsec.log). If nolog is specified, the log will be directed to stderr. If the upgrade is successful, the log will be appended to $FWDIR/tmp/mgmt.upg_opsec.log. The data that needs manual updating are as follows: CVP and UFP backwards compatibility communication methods. The lines in the file begin with server. This data should be moved to the relevant CVP or UFP OPSEC application object. SAM backwards compatibility communication methods. The lines in the file begin with server. There will also be a line that begins with sam_allow_remote_request This data should be moved to the SAM tab in the SmartDashboard for the relevant VPN-1 Pro Check Point Gateway s object. CVP and UFP load sharing definitions. The relevant blocks contain the word load_sharing.these load sharing definitions should be migrated into new objects of type CVP or UFP Collection objects. If Collection members are not defined, they should be created. Modify the Resource objects that referenced the old CVP or UFP load sharing objects to referencing to the new Collection objects. Chapter 4 Check Point Gateway Upgrades 49

50 Upgrading Check Point Gateways In Place 50

51 CHAPTER 5 ClusterXL Upgrade In This Chapter Before You Begin Terminology Before You Begin page 51 Planning a Cluster Upgrade page 52 Performing a Minimal Effort Upgrade on a ClusterXL Cluster page 53 Performing a Zero Down Time Upgrade on a ClusterXL Cluster page 54 Performing a Full Connectivity Upgrade on a ClusterXL Cluster page 57 module - otherwise known as an Enforcement module or sometimes module is the VPN-1 Pro engine that actively enforces your organization s Security Policy. SmartUpdate - SmartUpdate allows you to centrally upgrade and manage Check Point software and licenses. Product Repository - This is a SmartUpdate repository on the SmartCenter Server that stores uploaded products (like VPN-1 Pro or FloodGate-1). These products are then used by SmartUpdate to perform upgrades of Check Point Gateways. In Place - In Place upgrades are upgrades performed directly on a product without the benefit of SmartUpdate. SmartUpdate is the recommended Check Point upgrade tool. ClusterXL - ClusterXL is a software-based load sharing and high availability solution for Check Point gateway deployments. It distributes traffic between clusters of redundant gateways so that the computing capacity of multiple machines may be combined to increase total throughput. In the event that any individual gateway becomes unreachable, all connections are re-directed to a designated backup without 51

52 Planning a Cluster Upgrade interruption. Tight integration with Check Point's SmartCenter management and enforcement point solutions ensures that ClusterXL deployment is a simple task for FireWall-1, VPN-1, and FloodGate-1 administrators. Tools for Gateway Upgrades 1 SmartUpdate s Upgrade All Products Feature - This feature allows you to upgrade all products installed on a gateway. For IPSO and SecurePlatform, this feature also allows you to upgrade your Operating System as a part of your upgrade. 2 SmartUpdate s Add New Product Tools - SmartUpdate provides three tools for adding products to the Product Repository: Add From Download Center - an online download Add From CD - add a new product from the Check Point CD Import File - add a new product that you have stored locally. 3 SmartUpdate s Get Check Point Gateway Data - This tool updates SmartUpdate with the current Check Point or OPSEC third party products installed on a specific gateway or for your entire enterprise. Planning a Cluster Upgrade In order to upgrade ClusterXL there are three options available to you: Minimal Effort Upgrade - Choose this option if you have a period of time during which network downtime is allowed. The minimal effort method is much simpler because the clusters are upgraded as gateways and can be upgraded as individual gateways. Therefore, the instructions for this method are located in the Check Point Gateway Upgrades chapter. Zero Downtime - Choose this option if your gateway needs to remain active. The zero downtime method assures both inbound and outbound network connectivity at all time during the upgrade. There is always at least one active member that handles traffic. Full Connectivity Upgrade - Choose this option if your gateway needs to remain active and your connections must be maintained. Full Connectivity Upgrade with Zero Down Time assures both inbound and outbound network connectivity at all time during the upgrade. There is always at least one active member that handles traffic and open connections are maintained during the upgrade. 52

53 Working with a Mixed Cluster Working with a Mixed Cluster When there are cluster members of different versions on the same synchronization network, the cluster members with the previous version will turn active and the cluster members with the newer version will remain in a special state called Ready. In this state the newer version cluster members do not process any traffic destined for the cluster IP. During the upgrade this behavior is the expected one. If wish to avoid such a situation, for example during downgrade, you should physically (or using ifconfig) disconnect the cluster interfaces and the synchronization network of that cluster member prior to the downgrade process. Upgrading OPSEC Certified Third Party Clusters Products When upgrading Nokia clustering (VRRP and IP Cluster) follow either of the regular procedures (Zero downtime or Minimal effort). When upgrading other thir party clustering products it is recommended to use the minimal effort procedure. Zero downtime upgrade (with or without FCU) is not supported using the regular procedure. The third party may supply an alternative upgrade procedure to achieve a zero downtime upgrade. Consult the third party documentation. When upgrading from a Version 4.1 SP5 cluster, configure the Synchronization Network from the Synchronization tab. Check the Support Non-sticky Connections check box in the Third Party Configuration tab when the third party solution does not assure full connection stickiness (meaning that packets from client-to-server and from server-to-client pass through the same cluster member), Consult the Third Party Vendor's documentation for information regarding whether or not you should check the boxes: Hide cluster members' outgoing traffic behind the cluster's IP address and Forward cluster's incoming traffic to cluster members' IP address. Performing a Minimal Effort Upgrade on a ClusterXL Cluster If it is your intention to perform a Minimal Effort Upgrade, meaning you can afford to have a period of time during which network downtime is allowed, you will basically be treating cluster members as individual gateways. In other words, each cluster member can be upgraded in the same way you upgrade an individual gateway member. Please refer to the Check Point Gateway Upgrades chapter for gateway upgrade instructions. Chapter 5 ClusterXL Upgrade 53

54 Performing a Zero Down Time Upgrade on a ClusterXL Cluster Performing a Zero Down Time Upgrade on a ClusterXL Cluster Supported Modes Zero Downtime is supported on all modes of ClusterXL including IPSO s IP clustering and VRRP. For other third party clustering solutions please consult your third party solution s guide. Planning your Zero Down Time Upgrade Assume you have a cluster of several VPN-1 Pro machines (called A, B and C in this example) with any version from 4.1 SP5 to NG with Application Intelligence. The upgrade is divided into three parts: 1 Upgrade the SmartCenter Server (see the SmartCenter Upgrade chapter) Note - When upgrading from a 4.1 SP5 cluster reconfigure the Cluster Object in Smart Dashboard. When working with an upgraded SmartCenter management and Version 4.1 cluster members do not perform this reconfiguraton until right before you perform the upgrade of the cluster members. Then, configure the Synchronization Network in the Synchronization tab and select the ClusterXL checkbox in the product installed list in the General tab of the Cluster Object. 2 Upgrade all but one of the cluster members. 3 Upgrade the last cluster member. Upgrade All But One of the Cluster Members 1 Run cphaconf set_ccp broadcast on all cluster members. This will turn the cluster control protocol to broadcast instead of multicast and will insure that during the upgrade the new upgraded members stay in the ready state as long as a previous version member is active. In previous versions, there was a message that tells you to reboot the cluster members in order to fully activate the change. This message should be ignored, no reboot is required. 2 Suppose cluster member A is the active member, and members B and C are standby members. In Load Sharing mode, randomly choose one of the cluster members, to upgrade last. Upgrade cluster members B and C either: using SmartUpdate (see the Check Point Gateway Upgrades chapter) or In Place (see the Check Point Gateway Upgrades chapter) When the upgrade of B and C has finished, reboot both of them. 54

55 Planning your Zero Down Time Upgrade 3 Skip to the next step if you are upgrading from NG with Application Intelligence (R54). When machines B and C are up again, in the SmartDashboard, change the cluster version to NG with Application Intelligence. 4 Skip to step 6 if you are running SmartUpdate. SmartUpdate compiles and installs an updated policy on the new member, once it is rebooted. Note - Do not change any cluster parameters from the current policy in this stage (e.g. if the cluster was running in New High Availability mode, do not change it to LS), changes can be made after the upgrade completes. 5 Installing the policy: If you are upgrading from NG with Application Intelligence (R54) Install the policy. Be aware that policy installation on the old Check Point Gateway may cut connections for services that do not survive policy installation. This can be avoided by configuring the Check Point Gateway > Advanced > Connection Persistence tab to either Keep all connections or Keep data connections. For complete instructions, when you are in the Connection Persistence tab click on the help button. If you are upgrading from previous versions, follow these steps: A From the Policy Installation window, deselect the For Gateway Clusters, install on all the members, if it fails do not install at all checkbox located under the Install on each selected Module independently radio button. B Install the security policy on the cluster. C The policy will be successfully installed on cluster members B and C, and will fail on member A. 6 SmartView Status should show the status of cluster member A as Active or Active Attention (the latter may happen due to member A's sync interface reporting that its outbound status is down, because it is not communicating with the other cluster members anymore), and the other cluster members as Ready. 7 Execute the command cphastop on cluster member A. At this point machines B and/or C will start processing traffic (depending on whether this is a Load Sharing or High Availability configuration). For FCU users see Performing a Full Connectivity Upgrade on a ClusterXL Cluster on page 57. Installations on IPSO versions before 3.8 only Chapter 5 ClusterXL Upgrade 55

56 Performing a Zero Down Time Upgrade on a ClusterXL Cluster When you upgrade a VRRP cluster and the IPSO version is below 3.8 it is required to manually failover the IPSO when moving from the old version to the new version. With the minimum delay after cphastop has been run on the active member, change the priority of the OM in IPSO s configuration manager (for example, Voyager) to be less than the priority of the other member. This will force a failover to the new upgraded member. 8 From now on, it is recommended that you do not install a new policy on the cluster, until the last member has been upgraded. If you must install a new policy, please take the following steps: A Run cpstop on the old Check Point Gateway B Run fw ctl set int fwha_conf_immediate 1 on all new Check Point Gateways C Install policy. It should be noted that it is highly recommended to keep the time in which cluster members are running different versions to a minimum. Upgrade the Final Cluster Member Upgrade cluster member A, either: Using SmartUpdate (see Upgrading Check Point Gateways with SmartUpdate on page 44 of the Check Point Gateway Upgrades Chapter) or In Place (see the Check Point Gateway Upgrades chapter) 9 Reboot cluster member A. 10 Run cphaconf set_ccp multicast followed by cphastart on all cluster members. This will turn the cluster control protocol back to multicast instead of broadcast. This step can be skipped if you prefer to remain working with cluster control protocol in the broadcast mode. 56

57 Understanding a Full Connectivity Upgrade Performing a Full Connectivity Upgrade on a ClusterXL Cluster Understanding a Full Connectivity Upgrade The Full Connectivity Upgrade (FCU) method assures that during an upgrade from versions NG with Application Intelligence (R54 to R55 and above) synchronization is possible from old to new cluster members without losing connectivity. Connections that have been opened on the old cluster member will continue to live on the new cluster member without interrupting your clients. Note - Prior to NG with Application Intelligence (R55): Due to the absence of synchronization between old and new members of a cluster, during upgrade, existing connections were cut when switching from an old to a new member. Supported Modes FCU is supported on all modes of ClusterXL including IPSO s IP clustering and VRRP. Legacy High Availability is not supported in FCU. For other third party s support please refer to the third party s documentation. Terminology FCU - An abbreviation for Full Connectivity Upgrade. NM - An abbreviation for the already upgraded member during the upgrade. This Check Point Gateway contains a newer version. It is in the non-active state. OM - An abbreviation for the old member that has not yet been upgraded. It carries all the traffic. It is in the active state. Pre-Requisite for using the Full Connectivity Upgrade Make sure that the NM and the OM contain the same firewall policy and product installation. Do not change the policy during the upgrade from the last policy installed on the Check Point Gateway prior to its upgrade. Make sure the upgraded version is at least NG with Application Intelligence (R54) or higher. Full Connectivity Upgrade Limitations 1 This upgrade procedure is equivalent to a failover in a cluster where both members are of the same version. Therefore, whatever would not normally survive failover also will not survive a Full Connectivity Upgrade. This includes security servers and services that are marked as non-synced or local connections. Chapter 5 ClusterXL Upgrade 57

58 Performing a Full Connectivity Upgrade on a ClusterXL Cluster 2 The exact same products must be installed on the OM and on the NM. For example, it is not possible to perform FCU from a Check Point Gateway that has Floodgate-1 installed to a newer Check Point Gateway that does not have Floodgate-1 installed. Verify by running the command fw ctl conn on both cluster members. An example output on NG with Application Intelligence (R55): Registered connections modules: No. Name Newconn Packet End Reload Dup Type Dup Handler 0: Accounting d08ff Special d08fed58 1: Authentication d Special d0975e7c 3: NAT d Special d : SeqVerifier d091e d091e114 Special d091e708 6: Tcpstreaming d0913da d09732d None 7: VPN d155a8d Special d1553e48 Verify that the list of Check Point Gateway names is the same for both cluster members. The indices for Accounting and Authentication should be exactly the same between the NG with Application Intelligence (R54) and the NG with Application Intelligence (R55) Check Point Gateways. Beginning with NAT the index in NG with Application Intelligence (R55) should be greater by 1 than the index number was in NG with Application Intelligence (R54). For example NAT is number 3 in the table above which is NG with Application Intelligence (R55) but it has an index of 2 in NG with Application Intelligence (R54). 3 Verify that all the Firewall-1 Check Point Gateway configuration parameters have the same values on NG with Application Intelligence (R54) and NG with Application Intelligence (R55) Check Point Gateways. The same rule applies to any other local configurations you may have set. For example having the attribute block_new_conns with different values on the NM and on the OM might fail your FCU because FireWall-1 behavior cannot be changed during the upgrade. 4 When you upgrade a VRRP cluster and the IPSO version is below 3.8 you must manually failover the IPSO when moving from the old version to the new version. First upgrade the standby machine using the Performing a Zero Down Time Upgrade on a ClusterXL Cluster on page 54. Complete instructions are listed after step 7 on page A cluster that performs static NAT using Firewall-1 s automatic proxy ARP feature requires special considerations: cpstop the old Check Point Gateway right after running cphastop. Running cphastop is part of the upgrade procedure listing in Performing a Zero Down Time Upgrade on a ClusterXL Cluster on page

59 Implementing a Full Connectivity Upgrade Not doing so may fail some of the connections that rely on proxy ARP and may cause other connections that rely on proxy ARP not to open, until the upgrade process completes. However note that doing cpstop on the old Check Point Gateway rules out the option to rollback to the OM while maintaining all live connections that were originally created on the OM. Implementing a Full Connectivity Upgrade Upgrading a cluster with 2 members Follow the steps outlined in Performing a Zero Down Time Upgrade on a ClusterXL Cluster on page 54. Before you get to step 7 on page 55 (executing cphastop), run this command on the upgraded member: fw fcu <other member ip on sync network>(e.g. fw fcu ). then continue with step 7 on page 55. Upgrading a cluster with 3 or more members Choose one of the following two methods: 1 Upgrade the two NMs by following the steps outlined in Performing a Zero Down Time Upgrade on a ClusterXL Cluster on page 54. Before you get to step 7 on page 55 (executing cphastop), run this command on all the upgraded members: fw fcu <other member ip on sync network> then continue with step 7 on the single OM. or 2 First upgrade one member only, by following the steps outlined in Performing a Zero Down Time Upgrade on a ClusterXL Cluster on page 54. Before you get to step 7 on page 55 (executing cphastop), run this command on all the upgraded members: fw fcu <other member ip on sync network> then continue with step 7 on all remaining OMs. With more than 3 members divide the upgrade of your members so that the active cluster members can handle the amount of traffic during the upgrade. Note - cphastop can also be performed from the Cluster object in the SmartView Status SmartConsole. Once cphastop is performed do not run cpstart or cphastart again or try rebooting the machine. Chapter 5 ClusterXL Upgrade 59

60 Performing a Full Connectivity Upgrade on a ClusterXL Cluster Monitoring the Full Connectivity Upgrade Displaying Upgrade Statistics (cphaprob fcustat) cphaprob fcustat displays statistical information regarding the upgrade process. Run this command on the new member. Here is a typical output after running the command: During FCU... yes Number of connection modules Connection module map (remote -->local) 0 --> 0 (Accounting) 1 --> 1 (Authentication) 2 --> 3 (NAT) 3 --> 4 (SeqVerifier) 4 --> 5 (SynDefender) 5 --> 6 (Tcpstreaming) 6 --> 7 (VPN) Table id map (remote->local)... (none or a specific list, depending on configuration) Table handlers > 0xF98EFFD0 (sip_state) > 0xF (connections) Global handlers... none Explanation of Output During FCU This should be yes only after running the fw fcu command and before running cphastop on the final OM. In all other cases it should be no. Number of connection modules Safe to ignore. Connection module map The output reveals a translation map from NG with Application Intelligence (R54) to NG with Application Intelligence (R55). See Full Connectivity Upgrade Limitations on page 57 for further information. Table id map This shows the mapping between FireWall-1 kernel table indices on the OM and on the NM. Having a translation is not mandatory. Table handlers This should include a sip_state and connection table handlers. In a VPN-1 Pro/Express configuration a VPN handler should also be included. Global handlers Reserved for future use. 60

61 Implementing a Full Connectivity Upgrade Display the Connections Table (fw tab -t connections -u [-s]) This command displays the connection table. If everything was synchronized correctly the number of entries in this table and the content itself should be approximately the same in the old and new cluster members. This is an approximation because between the time that you run the command on the old and new members new connections may have been created or perhaps old connections were deleted. Options -t - table -u - unlimited entries -s - (optional) summary of the number of connections For further information on the fw tab -t connections command see the Command Line Interface Book. Making adjustments after checking the Connection Table It is safe to run the fw fcu command more than once. Make sure to run both cpstop and cpstart on the NM before re-running the fw fcu command. The reason for running cpstop and cpstart is that the table handlers that deal with the upgrade are only created during policy installation (cpstart installs policy). Reverting to Old Version of SVN Foundation, FireWall-1 or FloodGate-1 When you uninstall these three products after upgrading from a previous version the uninstall automatically rolls back to the previous version. Example You have just installed SVN Foundation, FireWall-1, and FloodGate-1 to NG with Application Intelligence and need to roll back to 4.1 SP5: 1 Perform an uninstall in this order: FloodGate-1, FireWall-1 and SVN Foundation. 2 Reboot. Since the SVN Foundation was not part on 4.1 SP5, it will be not be restored. Nokia - Safely Removing NG All of the IPSO uninstall scripts use SVN utilities and if you deactivate SVN it is no longer in the PATH and LD_LIBRARY_PATH. To safely remove an NG version for a Nokia platform follow these steps in order: Chapter 5 ClusterXL Upgrade 61

62 Performing a Full Connectivity Upgrade on a ClusterXL Cluster 1 Disable all Check Point products except the SVN. 2 Remove all your packages. 3 Remove the SVN. Other Product Roll Backs 4 All components of your system must be in the same version to work correctly. For example, you cannot have an NG with Application Intelligence FloodGate-1 Check Point Gateway installed and a NG FP3 FireWall-1 Check Point Gateway installed. For all products other than the SVN Foundation, FireWall-1, and FloodGate-1, uninstall the current version and reinstall previous versions. 62

63 CHAPTER 6 SmartView Reporter Upgrade In This Chapter Before you begin SmartView Reporter (SVR) is a complete reporting system. It enables managers at every level to make intelligent decisions by delivering in-depth network security activity and event information from Check Point log data. SmartView Reporter can be configured in two ways: via a distributed configuration or via a standalone configuration. In the distributed configuration the SVR Server resides on one machine and the SmartCenter Server resides on another machine. In the standalone configuration both the SVR Server and the SmartCenter Server reside on the same machine. SmartView Reporter cannot be upgraded via SmartUpdate so you must upgrade it In Place. Terminology Before you begin page 63 Planning page 66 Performing a Basic SVR Upgrade page 66 Performing an Advanced Upgrade page 67 More Upgrade Configurations page 69 Logs - In SmartView Reporter logs refer to the VPN-1 Pro logs. Log Consolidator - A process that reads logs from the Log Server, compresses them and stores them in a database on the SmartView Reporter Server. 63

64 Before you begin Generator - A process that generates reports from data that was stored in the database on the SmartView Reporter Server. SmartView Reporter Add-on - The name given to SmartView Reporter data that is stored on the SmartCenter Server. SmartView Reporter Client - The SmartView Reporter s Smart Console. Tools The following section describes how to perform some of the tasks that are specific to SmartView Reporter and are needed during the different phases of upgrade. How to back up your reports Backup all files $FWDIR/conf/reporting*.C except reporting_unification_scheme.c Backup the file FWDIR/conf/lcrulebases_5_0.fws How to stop log consolidator From SmartDashboard: 1 Select Engine > Stop > Shutdown. 2 Check the status (from the Status menu select Engine and Database status). 3 Re-check it until the status is Stopped. It may take a long time. 64

65 Tools How to backup the database Move the database files to a location on your machine that will not be deleted when uninstalling Check Point products, and not be overridden by installing new Check point products: TABLE 6-1 Advanced Configuration Database Backup machine SmartCenter Server steps 1 Run cpstop 2 Backup the entire folder $RTDIR/Database The backup does not need to occur under a Check Point directory. New Machine 1 Perform the Advanced Upgrade 2 Run cpstop 3 Overwrite the database files (*.db) with the copy you made from SmartCenter Server to the $RTDIR/Database folder. If your solid.ini *.db files point to a different location, further instructions are located in the Changing the SmartView Reporter Database Data and Log Files Location section of the SmartView Reporter User Guide. 4 Overwrite the database log files (*.log) with the copy you made from SmartCenter Server to the $RTDIR/Database/Log folder. 5 Run cpstart How to re-establish SIC between SmartCenter and SmartView Reporter 1 In SmartView Reporter machine: A Run cpconfig B Select Secure Internal Communications C Select Reset D Enter a new activation key E Restart all check point services on this machine Chapter 6 SmartView Reporter Upgrade 65

66 Planning Safety Planning 2 In SmartCenter machine A Open SmartDashboard to the SmartCenter machine. B Select the object that represents the SmartView Reporter Server machine C Click communications D Select Reset E Enter activation key and click Initialize F Verify that trust was established between the two machines. Before beginning any SVR Upgrade: Stop the log consolidator. Back up your database to different medium. Instructions for performing a complete SVR database backup can be found in the SmartView Reporter User Guide. On an advanced SmartCenter upgrade in a standalone configuration: back up the solid.ini file found in the $RTDIR/Database directory of the SmartView Reporter machine and any logo files (.png or.jpg) in the $RTDIR/bin directory of the SmartView Reporter machine. The pre-upgrade verifier does not verify SmartView Reporter objects. In a distributed installation of SmartView Reporter, first upgrade your SmartCenter Server, then upgrade SmartView Reporter. SmartView Reporter will begin working again once the SmartView Reporter Server has completed upgrading. Performing a Basic SVR Upgrade Stand Alone configuration To perform a simple upgrade on SmartCenter machine that has SmartView Reporter NG FP3, run a simple upgrade on the SmartCenter machine, similar to the instructions in section Basic SmartCenter Upgrade Procedure on page 23. The upgrade process will identify that SmartView Reporter is installed, and upgrade it automatically with the following steps: Stop the log consolidator. 66

67 Distributed configuration Back up your reports. Run simple upgrade from the CD. Restart the machine after the upgrade process completes. Open SmartView Reporter Client and see that all your report definitions were preserved. Open SmartDashboard and install a new Log consolidator policy. It is highly recommended that you select a new database table. Refer to the release notes for some special cases, including URL related reports lhttp:// Distributed configuration 1 SmartCenter machine Stop the log consolidator. This is necessary before you upgrade SmartCenter. Back up your reports Run simple upgrade from the CD. Restart the machine after the upgrade process completes. 2 Reporting Server Make sure you previously stopped the log consolidator (before upgrading the management). Run upgrade from CD. Restart the machine when finished. [Re-SIC with SmartCenter - there is no need] 3 Checking the configuration after upgrade: Open SmartView Reporter Client and see that all your report definitions were preserved. Open SmartDashboard install a new Log consolidator policy. It is highly recommended that you select a new database table. Performing an Advanced Upgrade General notes on advanced upgrade If you wish to perform advanced upgrade on a SmartCenter that has SmartView Reporter installed, be aware of possible limitations. Refer to the release notes for final information and limitations: Chapter 6 SmartView Reporter Upgrade 67

68 Performing an Advanced Upgrade Advanced upgrade can be performed only on SmartCenter machines, which may or may not have either SmartView Reporter Add-on or the full SmartView Reporter Server installed. SmartView Reporter Server in distributed configurations can only be upgraded using simple upgrade, not advanced upgrade. Advanced upgrade of SmartCenter with full (standalone) SmartView Reporter Server does not handle the SmartView Reporter SQL database. You should manually transfer it between machines, or backup the database when performing advanced upgrade on the same machine. Standalone configuration Advanced upgrade (NG FP3 to NG with Application Intelligence (R55)) 1 On the old machine A Stop log consolidator B Backup your reports C Backup or move your SQL database D Export your configuration. 2 On the new machine, use the import option to install SmartCenter NG with Application Intelligence and also install SmartView Reporter Add-on with the configuration file you created in step 1. 3 If you changed IP addresses, open SmartDashboard and modify the machine's IP address. 4 Restore the backed up database 5 Open SmartView Reporter Client and verify that all your reports have transferred correctly. 6 Start the Log Consolidator install new log consolidator policy through SmartDashboard and install a new consolidator policy to a new database table. Distributed configuration Upgrading the SmartView Reporter Server in distributed configuration can only be performed though simple upgrade (see Performing a Basic SVR Upgrade on page 66). Upgrading SmartCenter with SmartView Reporter Add-on through advanced upgrade, has similar steps to the advanced upgrade of SmartCenter with full SmartView Reporter. 68

69 Advance upgrade from one version of NG with Application Intelligence to another 1 Backup your reports. 2 Export your configuration (Advanced Upgrade Steps). 3 Import your configuration to the new machine. 4 If you changed IP addresses, open SmartDashboard and modify the machine's IP address. 5 If you have not upgraded SmartView Reporter Server yet, upgrade it now. Then re-establish SIC between the two machines. 6 Start Log Consolidator - install new log consolidator policy through SmartDashboard, install a new consolidator policy to a new database table. 7 Open SmartView Reporter Client and verify that all your reports have transferred correctly. More Upgrade Configurations Advance upgrade from one version of NG with Application Intelligence to another You can use an advanced upgrade procedure to transfer an existing configuration of SmartCenter NG with Application Intelligence to another machine. Export the configuration from the old SmartCenter machine, and import it to the new machine. The steps are similar to the advanced upgrade steps described in Performing an Advanced Upgrade page 67, for both standalone and distributed configuration. Upgrade SmartCenter but leave SmartView Reporter in a previous version This feature is available on the Windows platform only. NG with Application Intelligence (R54) 1 Perform a SmartCenter Upgrade (Basic or Advanced) to NG with Application Intelligence (R55). 2 Leave the SmartView Reporter Server in NG with Application Intelligence (R54). Use the SmartView Reporter Client from the NG with Application Intelligence (R55). NG FP3 Upgrade the SmartCenter Server to NG with Application Intelligence (R55) while leaving SmartView Reporter in NG FP3. Chapter 6 SmartView Reporter Upgrade 69

70 More Upgrade Configurations Limitations: this is possible only in distributed configuration and upgrade SmartCenter but leave the SmartView Reporter Add-on on the previous version. SmartView Reporter Server can then continue to function partially, until you decide to complete its upgrade as well. On SmartCenter machine 1 Run a simple upgrade, select Upgrade and install new products 2 In the product list deselect SmartView Reporter. You will get a warning. Ignore it and continue the upgrade process. 3 Complete the upgrade process. 4 Run the following commands: A cpstop B SVRTablesUpgrade FP3 FP3 C cpstart When you finish this, SmartView Log consolidator will continue reading logs and SmartView Reporter Server will keep running scheduled reports. However, SmartView Reporter client will fail to connect until you upgrade both SmartView Reporter Add-on and SmartView Reporter Server to NG with Application Intelligence (R55). Upgrading the SQL Database Please refer to the latest version of the Release Notes at: for up-to-date information on upgrading the database. It is highly recommended when you install a new Log Consolidator policy, that you choose a new database table. If you nevertheless choose to consolidate logs to a table that contains old NG FP3 logs, please note that when producing NG with Application Intelligence reports from NG FP3 data, you may get inaccurate results in some cases. If you wish to improve report results, you can manually run the database upgrade utility. This utility will upgrade the contents of any table you select in your database. Run the utility from Check Point products: \SmartView Reporter\NG_AI\BIN SVR_DBUpgrade [Table-name "*"] 70

71 Upgrading the SQL Database You can run the database upgrade utility on one table, by specifying its name, or on all the tables, using "*". Before running this utility, run: 1 cpstop 2 rmdstart -db 3 SVR_DBUpgrade [table name "*"] 4 cpstart Chapter 6 SmartView Reporter Upgrade 71

72 More Upgrade Configurations 72

73 CHAPTER 7 Log Server Upgrade Log Server Upgrades Upgrading Log Server is the same as upgrading in SmartCenter. The same tools, safety tools and terminology apply. The only difference between performing a Log Server upgrade and a SmartCenter upgrade is that you only have the Basic option when upgrading. Please refer to the SmartCenter Upgrade chapter to perform this upgrade. SecurePlatform When installing SecurePlatform, check the Log Server option if you want Log Server to be upgraded. 73

74 Log Server Upgrades 74

75 CHAPTER 8 Upgrading SmartLSM In This Chapter Before You begin SmartLSM is the industry s first solution that enables enterprises to easily scale, deploy and manage VPNs and security for thousands of remote office or branch office gateways (ROBO). Terminology Before You begin page 75 Planning page 76 Adding a ROBO Gateway Upgrade Package to the SmartUpdate Package Repository page 77 Upgrading a ROBO Gateway Using SmartLSM page 77 ROBO Gateways - A Remote Office/Branch Office Gateway. ROBO Profile - An object that you define to represent properties of multiple ROBO Gateways. Profile objects are version dependent; therefore, when you plan to upgrade ROBO Gateways to a new version, first define new Profile objects for your new version. In general, you will want to keep the Profile objects of the previous versions until all ROBO Gateways of the previous version are upgraded to the new version. For further information about defining a ROBO Profile see the Defining Policies for the Gateway Profile Objects chapter in the SmartLSM Guide. LSM - Large Scale Manager. SmartLSM enables enterprises to easily scale, deploy and manage VPNs and security for thousands of remote locations. CLI - The Command Line Interface. 75

76 Planning Tools Product Repository - This is a SmartUpdate repository on the SmartCenter Server that stores uploaded products (like VPN-1 Pro or FloodGate-1). These products are then used by SmartUpdate to perform upgrades of Check Point and ROBO Gateways. Export Export is located in your SmartLSM GUI application, File > Export to File. Use this tool to export your ROBO Gateway s properties into a text file that you can turn into a script in order to perform batch upgrades. LSM CLI The LSM Command Line Interface allows you to upgrade a ROBO Gateway. When used in scripts it allows you to perform batch upgrades. It can be run either on your SmartCenter Server or on another host (which must be defined as a GUI Client). For general usage and help, type the command LSMcli --help. Safety Planning The exact same safety precautions that apply to SmartCenter also apply to SmartLSM. Once you have upgraded your SmartCenter Server, you have upgraded your SmartLSM was upgraded as well. The rest of this chapter describes how to upgrade your ROBO Gateways. Upgrade your ROBO Gateways The general upgrade flow for upgrading your ROBO Gateways is as follows: 1 In SmartDashboard, define new Profile objects for the new version and install the respective policies on these objects. This Install operation only compiles the policy, it does not send it to any Gateway. The compiled policy is automatically fetched later by the relevant ROBO Gateways, following their upgrade. 2 Add the upgrade package to the SmartUpdate package repository (see Adding a ROBO Gateway Upgrade Package to the SmartUpdate Package Repository ). 3 Upgrade your ROBO Gateways in one of the following ways: using the SmartLSM (see Upgrading a ROBO Gateway Using SmartLSM ) or 76

77 Upgrading a VPN-1 Express/Pro ROBO Gateway using the SmartLSM Command Line Interface (see Upgrading a VPN-1 ROBO Gateway Using the LSM CLI ). Similar to ordinary gateways, a remote upgrade of a ROBO Gateway (using SmartLSM or the LSM CLI) can only upgrade the gateway to the version of the SmartCenter Management Server. It is not possible to upgrade the gateway to a previous (or to a more advanced) version. The upgrade process removes the initial Plug & Play license from your gateway. Trying to perform a remote upgrade on a gateway without a valid license will succeed, but this gateway will not be able to load the correct policy after the upgrade. Make sure that all gateways have valid permanent licenses installed. Adding a ROBO Gateway Upgrade Package to the SmartUpdate Package Repository Once you have launched SmartUpdate, add the packages needed for the upgrade to the SmartUpdate repository. For VPN-1 Express/Pro Gateways, make sure you add the packages for both the SVN-1 Foundation and for Firewall-1. VPN-1 Edge Firmware packages are added the same way. For instructions on adding products to the Product Repository refer to Tools for Gateway Upgrades on page 40. Upgrading a ROBO Gateway Using SmartLSM Upgrading a VPN-1 Express/Pro ROBO Gateway There are two methods for upgrading a VPN-1 Express/Pro Gateway, Full Upgrade and Specific Install: The Full Upgrade method - This method automatically performs all the required checks and actions for you. When it successfully completes, the upgraded ROBO Gateway is ready for use. This is the recommended method to upgrade VPN-1 Express/Pro ROBO Gateways. The Specific Install method - This method can be used when you want to install a specific product on a ROBO Gateway. Use this method if you want to update the operating system package on a Nokia box, or to add a new product to a gateway. This method can also be used to upgrade the Check Point products (SVN-1 Foundation and VPN-1 Express/Pro) one at a time. However this is not recommended for normal operations because the gateway remains non-operational until the whole upgrade process is complete. Chapter 8 Upgrading SmartLSM 77

78 Upgrading a ROBO Gateway Using SmartLSM Full Upgrade 1 From SmartLSM, select the line representing the VPN-1 Express/Pro ROBO Gateway that you want to upgrade. Choose Actions > Products > Upgrade All Products. This selection can also be done through the right-click menu, or the Install Product icon in the toolbar. 2 The Upgrade process begins with a verification stage, checking which version is currently installed on the gateway, and whether the required packages exist in your Package Repository. When it completes, a Verification Details dialog box opens, showing you the verification results. 3 Select the Change to a new Profile after upgrade checkbox, and select the appropriate new Profile from the list. 4 Check the Reboot VPN-1 Express/Pro ROBO gateway after upgrade checkbox. 5 Click the Continue button. 6 The Upgrade process begins. Its stages and completion status can be seen in the Action Status pane, on the lower side of the SmartLSM GUI. The whole progress report can be seen at any time by viewing the Action History (right click on the respective line in the Action Status pane, and select Action History). Specific Install 1 In SmartLSM, select the line representing the VPN-1 Express/Pro ROBO Gateway you want to upgrade. Choose Actions > Products > Install Product. This selection can also be done through the right-click menu, or the Install Product icon in the toolbar. 2 The Install Product dialog appears, showing you the relevant packages, from the Package Repository, which can be installed on your ROBO Gateway. Select the package you want to install. 3 If you are upgrading the SVN-1 Foundation, you need to check the Change to a new Profile after upgrade checkbox, and select the appropriate new Profile from the list. Otherwise, do not check this box. 4 The Reboot VPN-1 Express/Pro ROBO gateway after upgrade checkbox should be checked only when upgrading VPN-1 Pro. Fail to do so and you will have to manually reboot the gateway from its console. Note - If you are doing a step-by-step upgrade, do not check this box 78

79 Upgrading a VPN-1 Edge ROBO Gateway 5 Click the Install button. 6 The Install process begins. Its stages and completion status can be seen in the Action Status pane, on the lower side of the SmartLSM GUI. The whole progress report can be seen at any time by viewing the Action History (right click on the respective line in the Action Status pane, and select Action History). Note - You can always verify if the installation will succeed before actually upgrading the ROBO Gateway by choosing Actions > Products > Verify Installation. Upgrading a VPN-1 Edge ROBO Gateway 1 In SmartLSM, select the line representing the VPN-1 Edge ROBO Gateway you want to upgrade, and choose Edit > Edit ROBO gateway This selection can also be done through the right-click menu, or the Edit ROBO gateway icon in the toolbar, or by double-clicking the ROBO line. 2 Select the Firmware tab. 3 Select the Use the following firmware option, select the desired firmware from the list, and Click OK. The VPN-1 Edge ROBO Gateway will fetch and install the new firmware the next time it automatically checks for updates. If you want the firmware update to take effect immediately, select Actions > Restart gateway. Upgrading a VPN-1 ROBO Gateway Using the LSM CLI Upgrading a VPN-1 Express/Pro ROBO Gateway Using the LSM CLI The LSMcli commands can be run either on your SmartCenter server or on another host, which is defined as a GUI Client. In both cases, you must specify the Server, User and Password arguments. To verify that a Full Upgrade of a ROBO Gateway will succeed, execute: LSMcli [-d] Server User Password VerifyUpgrade ROBO To perform a Full Upgrade of a ROBO gateway, execute: LSMcli [-d] Server User Password Upgrade ROBO [-P=Profile] [-boot] To see which product packages are available in your package repository, execute: LSMcli [-d] Server User Password ShowRepository Chapter 8 Upgrading SmartLSM 79

80 Upgrading a ROBO Gateway Using SmartLSM To verify that a Specific Install on a ROBO gateway will succeed, execute: LSMcli [-d] Server User Password VerifyInstall ROBO Product Vendor Version SP To perform a Specific Install on a ROBO gateway, execute: LSMcli [-d] Server User Password Install ROBO Product Vendor Version SP [-P=Profile] [-boot] Note - Similar to the Upgrade from SmartLSM, it is recommended to use the Full Upgrade method to upgrade VPN-1 Express/Pro ROBO Gateways. TABLE 8-1 Command line argument descriptions argument meaning... -d (Optional) Run the command with debug output. Server The IP or hostname of the SmartCenter Server. User The username and password of a SmartCenter Administrator. Password ROBO The name of the ROBO Gateway to be upgraded. -P=Profile (Optional) The Profile name the ROBO Gateway will be mapped to after a successful upgrade. You must specify the new Profile when performing a Full Upgrade or when you install the SVN-1 Foundation. -boot (Optional) Indicate that a boot should occur after the upgrade. You must include this option when performing a Full Upgrade, or when installing VPN-1 Pro. Product Identify a specific package in the repository. Vendor Version SP Example: Using the LSM CLI to upgrade one VPN-1 Express/Pro ROBO Gateway % LSMcli MyServer John mypassword VerifyUpgrade ROBO17 % LSMcli MyServer John mypassword Upgrade ROBO17 -P=MyNewProfile Where: MyServer = the name of my SmartCenter Server John = the administrator s name 80

81 Using the LSMcli in Scripts mypassword = the administrator s password Ver ifyupgrade = the Full Upgrade verification command Upgrade = the Full Upgrade command ROBO17 = the VPN-1 Express/Pro ROBO Gateway to be upgraded MyNewProfile = the new profile that ROBO17 will be mapped to after the upgrade. Upgrading a VPN-1 Edge ROBO Gateway Using the LSM CLI To see which product packages are available in your package repository, execute: LSMcli [-d] Server User Password ShowRepository To upgrade a VPN-1 Edge ROBO gateway, execute: LSMcli [-d] Server User Password ModifySW ROBO [-P=Profile] [-F=Firmwarename] If you want the firmware update to take effect immediately, execute: LSMcli [-d] Server User Password Restart ROBO Example: Using the LSM CLI to upgrade one VPN-1 Edge ROBO Gateway % LSMcli MyServer John mypassword ModifySW ROBO101-P=EdgeNewProfile -F= % LSMcli MyServer John mypassword Restart ROBO101 Where: MyServer = the name of my SmartCenter Server John = the administrator's name mypassword = the administrator's password ModifySW = the command to modify a property on a VPN-1 Edge ROBO gateway ROBO101 = the Edge ROBO Gateway to be upgraded EdgeNewProfile = the new profile that ROBO101 will be mapped to after the upgrade = the name of the new Firmware package Restart = the command to restart the gateway Using the LSMcli in Scripts Scripting can be very handy when you want to upgrade multiple ROBO Gateways in batches. Chapter 8 Upgrading SmartLSM 81

82 Upgrading a ROBO Gateway Using SmartLSM Example: Using the LSM CLI to write a script to upgrade multiple ROBO Gateways Create the following script and run it: LSMcli MyServer John mypassword Upgrade ROBO17 -P=MyNewProfile LSMcli MyServer John mypassword Upgrade ROBO18 -P=MyNewProfile LSMcli MyServer John mypassword Upgrade ROBO19 -P=MyOtherProfile Upgrading a VPN-1 Express/Pro ROBO Gateway In Place It is possible to upgrade a ROBO gateway In Place (from the ROBO Gateway's console), just like an In Place upgrade of a regular gateway (see Upgrading Check Point Gateways In Place on page 47). Following the upgrade, update the new version on the SmartLSM side, and select a new Profile for the gateway. Note - Unlike the remote upgrade procedures described above, an In Place upgrade can be performed on any version that is higher than the existing version. You are not limited by the version of the SmartCenter server that you are using. 1 In SmartLSM, select the line representing the VPN-1 Express/Pro ROBO Gateway you just upgraded, and choose Edit > Edit ROBO gateway This selection can also be done through the right-click menu, or the Edit ROBO gateway icon in the toolbar, or by double-clicking the ROBO line. The Edit dialog box opens in the General tab. 2 From the Version menu select the new version of the upgraded gateway. 3 From the Profile menu select a new Profile for the upgraded gateway. 4 Click OK to close the dialog. 5 The Policy and properties of the new Profile will be applied on the ROBO Gateway the next time it automatically checks for updates. If you want the Profile change to take effect immediately, select Actions > Push Policy. 82

83 CHAPTER 9 Upgrading Provider-1 Introduction Scope In This Chapter Provider-1/SiteManager-1 Upgrade Tools page 85 Provider-1/SiteManager-1 Upgrade Practices page 92 Upgrading in a Multi MDS Environment page 109 Restoring your Original Environment page 111 Renaming Customers page 112 Changing MDS IP address and External Interface page 115 This document describes methods and utilities for upgrading Provider-1/SiteManager-1 to NG with Application Intelligence. Before You Begin 1 Before performing a Provider-1/SiteManager-1 upgrade read: the latest Provider-1/SiteManager-1 release notes: and the latest Check Point suite release notes: 2 If difficulties in the upgrade process require that you restore your original environment, follow the step in Restoring your Original Environment on page 111. Read the restoration instructions before you begin, as several actions needs to be taken before the upgrade in order to allow the restoration. 83

84 Introduction 3 If you are upgrading a multi-mds environment refer to Upgrading in a Multi MDS Environment on page 109. Supported Platforms The latest information about supported platforms is always available in the Check Point Release Notes. Download them from: Supported Versions for Upgrade Upgrade of MDS is supported from the following versions: NG with Application Intelligence (R54) - You can directly upgrade from NG with Application Intelligence (R55) from with Application Intelligence (R55). NG FP3 HF2 - If you have NG FP3 Edition 1, NG FP3 Edition 2, NG FP3 Edition 3 or NG FP3 HF1: first install the Provider-1/SiteManager-1 NG FP3 HF2 Hotfix or the Hotfix Accumulator Build (HFA). NG FP2 - Upgrade directly to NG with Application Intelligence. NG FP1 HF1 - If you need to upgrade from a NG FP1 installation, upgrade to NG FP1 HF1 then upgrade to NG with Application Intelligence. 4.1 SP5 and SP6 - If you need to upgrade from a Version 4.1 installation prior to Version 4.1 SP5, upgrade to 4.1 SP5 or 4.1 SP6 (Solaris 8). Then upgrade to NG with Application Intelligence. Version If you are currently working in Version 4.0, upgrade to at least version 4.1 SP6 before continuing. You cannot upgrade directly from Version 4.0 to NG with Application Intelligence. 84

85 Summary of Sections in this Chapter Summary of Sections in this Chapter TABLE 9-1 Introduction page 83 Provider-1/SiteManager-1 Upgrade Tools page 85 Provider-1/SiteManager-1 Upgrade Practices page 92 Upgrading in a Multi MDS Environment page 109 Restoring your Original Environment page 111 Renaming Customers page 112 Changing MDS IP address and External Interface page 115 This Section Describes the utilities used in different stages of upgrading and migrating. Specifies the usage of each utility. Description of the upgrade practices supported in MDS. Covers when to use each upgrade practice and how it is implemented using the upgrade tools. Considerations for the multi-mds environment. Such as the order of the upgrade, synchronization and minimizing server downtime. Special considerations for restoration. How to return to the original version in the middle of the upgrade process. Starting NG with Application Intelligence, Customer names cannot contain special characters or spaces. This section explains how to rename your Customers during the upgrade. Instructions for moving MDS installation from one machine to a second machine with another IP address and/or an external interface name. Provider-1/SiteManager-1 Upgrade Tools This section describes the different upgrade and migrate utilities and explains when and how each one of them is used. Pre-Upgrade Verifiers and Fixing Utilities Before performing the upgrade of Provider-1/SiteManager-1, Check Point verifies readiness of your current version for the upgrade. Provider-1/SiteManager-1 upgrade script, mds_setup, runs a list of pre-upgrade utilities. The utilities search for well known upgrade problems that might be present in your existing installation. The output of the utilities is also saved to a log file. The full path of this is given at the end of installation. There are three types of messages given by the pre-upgrade utilities: 1 Action Items before the Upgrade Chapter 9 Upgrading Provider-1 85

86 Provider-1/SiteManager-1 Upgrade Tools These include errors and warnings. Errors have to be repaired before the upgrade. Warnings are left for the user to check and conclude whether they should be fixed or not. In some cases fixing utilities are suggested to be run during the pre-upgrade check, but in most cases the fixes are done manually from SmartDashboard. Example of an error to be fixed before the upgrade is when an invalid policy name is found in your existing installation. In that case you will be required to rename the policy. 2 Action Items after the upgrade Also includes errors and warnings, but to be handled after the upgrade. 3 Information Messages This section includes items to be noted. For example if a specific object type that is not supported anymore is found in your database, if this object is converted during the upgrade process, you will get a message stating that this change is going to occur. The Provider-1/SiteManager-1 Pre-Upgrade Verifier uses Provider-1/SiteManager-1 specific verifications as well s verifications checked by SmartCenter s Pre-Upgrade Verifier. See Pre-Upgrade Verification on page 21. Installation Script Starting from NG with Application Intelligence, the installation script to use for MDS is mds_setup. To run mds_setup: 1 Unzip the MDS package: gunzip <package_name>.tgz 2 Untar tar xvf <package_name>.tar 3 A new directory with the same name of the tar file has been created. Change to it: cd <package_name>. 4 Run the installation script:./mds_setup. When mds_setup is executed, it first checks for an existing installation of MDS: If no such installation exists, mds_setup asks you to confirm a fresh installation of MDS. If a previous version of MDS is detected, you are prompted to select one of the following options (Pre-Upgrade Verification Only, Upgrade or Backup) listed below. 5 Exit all shell sessions. Open a new shell in order for the new environment to be set. 86

87 cma_migrate Pre-Upgrade Verification Only Allows you to run pre-upgrade verification without upgrading your existing installation. No fixing utilities are executed. Use this option at least once before you upgrade. It provides you with a full report of upgrade issues, some of which should be handled before the upgrade. In a multi-mds environment it is required to run the pre-upgrade verification on all MDSes (and MLMs) before upgrading the first MDS. Upgrade Using this option mds_setup runs the Pre-Upgrade Verifier and if no errors are found, the upgrade process proceeds. In case of errors mds_setup stops the installation until all the errors are fixed. In some cases mds_setup suggests to automatically fix the problem using a fixing utility. Fixing utilities that affect your existing installation can also be executed from command-line. You can choose to stop the installation at this point and execute the fixing utility from command-line. There are two important things to remember after changing your existing installation: Verify your changes in the existing installation before you upgrade. Synchronization: If you make changes in global policies, reassign these global policies to customers. If you have a multi-mds environment: Synchronize databases between MDSes in High Availability. Synchronize databases between CMAs in High Availability. Install the database on CLMs. Backup Prior to upgrading backup your MDS. This option from mds_setup, will run mds_backup (see mds_backup). Backup is also used for replication of your MDS to another machine. Manual operations are necessary if you are switching IP addresses, or network interface names. For more details see Changing MDS IP address and External Interface on page 115. cma_migrate This utility is used to import an existing SmartCenter Server or CMA into an NG Provider-1/SiteManager-1 MDS to become one of its CMAs. The platform of the source management to be imported can be Solaris, Linux or Windows. The list of available versions is located in Supported Versions for Upgrade on page 84. Before running cma_migrate create a new customer and a new CMA. Do not start the CMA, cma_migrate will fail. Chapter 9 Upgrading Provider-1 87

88 Provider-1/SiteManager-1 Upgrade Tools Usage cma_migrate <source management directory path> <target CMA FWDIR directory> Example cma_migrate /tmp/orig_mgmt_dir /opt/cpmds-54/customers/cma2/cpfw1-54 The first argument (<source management directory path>)specifies a path on the local MDS machine, where the data of the source management resides. Use migrate_assist to build this source directory or build it manually. Set the structure under the source management directory to: TABLE 9-2 directory conf database log conf.cpdir Source Management Structure contents This directory contains the information that resides under $FWDIR/conf of the source management. This directory contains the information that resides under $FWDIR/database of the source management. This directory contains the information that resides under $FWDIR/log of the source management or empty if you do not wish to maintain the logs. This directory is required when the source management is NG FP1 or higher. It contains the information that resides under $CPDIR/conf of the source management. The second argument (<target CMA FWDIR directory>) is the FWDIR of the newly created CMA. The cma_migrate utility can also be performed from the MDG: 1 Right click a CMA 2 select Import Customer Management Add-on from the menu. It is also available within the mdscmd utility. When running cma_migrate, pre-upgrade verification takes place. If no errors are found, then the migration continues. If errors are found, changes must be performed on the original SmartCenter Server. The original Certificate Authority and putkey information is maintained when using cma_migrate. This means that SmartCenter Server that was migrated using cma_migrate should not re-generate certificates to gateways and SIC should continue to work with NG gateways. If the IP of the CMA is different from that of the original 88

89 migrate_assist management, then putkey should be redone. Use putkey -n to reestablish trust. For further information on putkey see the Check Point Command Line Interface documentation. If you have VPN with externally managed gateways (or Global VPN-1 Communities) maintain the original FQDN of the management, so that the CRL server location is not changed. This is not a requirement for a VPN between Check Point internal gateways. The default FQDN of a CMA is its IP address, so if you migrated from CMA and changing its IP address, you should change its FQDN to the new IP address by executing: mdsenv <CMA>, cpconfig, option 4 - Certificate Authority If your purpose is to split a management or CMA into two or more CMAs, reinitialize their Internal Certificate Authority so only one of the new CMAs will employ the original ICA: 1 mdsstop_customer <CMA NAME> 2 mdsenv <CMA NAME> 3 Remove current Internal Certificate Authority by executing the fwm sic_reset command. This may require some preparation that is described in detail from the command prompt and also in the Secure Knowledge solution sk Create new Internal Certificate Authority by executing: mdsconfig -ca <CMA NAME> <CMA IP> 5 Run the command: mdsstart_customer <CMA NAME> migrate_assist This utility is a helper utility for cma_migrate. It can be used to pull the original management directories to the current disk storage using FTP. Once you finish running migrate_assist, it is possible to run cma_migrate (see cma_migrate on page 87), whose input directory will be the output directory of migrate_assist. Usage migrate_assist <source machine name/ip> <source FWDIR folder> <user name> <password> <target folder>[<source CPDIR folder>] Chapter 9 Upgrading Provider-1 89

90 Provider-1/SiteManager-1 Upgrade Tools Example If you want to import a SmartCenter server with the IP address of version NG FP1 you will use the following command: migrate_assist /opt/cpfw1-53 FTP-user FTPpass/EMC1/opt/CPshared/5.0 Where /EMC1 is the name of the directory you have created on the MDS server machine. migrate_assist will access the source machine and import the source FWDIR and CPDIR folders to the specified target folder according to the structure described above. User name and password are needed to gain access to the remote machine via FTP. The source CPDIR parameter is required in case that the original management is NG FP1 and higher. Note - migrate_assist does not affect the source database, however it is highly recommended to stop it before running migrate_assist so that no SmartConsole Clients accidentally edit the database during migration. migrate_global_policies The migrate_global_policies utility is available starting with NG FP3. This utility transfers (and upgrades, if necessary) a global policies database from one MDS to another. migrate_global_policies replaces all existing global policies and Global Objects. Each of the existing global policies is saved under the name *.pre_migrate. If the global policies database on the target MDS has polices that are assigned to customers, migrate_global_policies aborts. This is done to ensure that the Global Policy used at the Customer's site is not deleted. Usage migrate_global_policies <path to original global policies files> <original files version> The original files version should be one of the following taken from the $MDSDIR/conf folder of the originating MDS: 4.1 FP1 FP2 FP3 R54 - for NG with Application Intelligence R55 - for NG with Application Intelligence The original file names depend on the version used: 90

91 Backup and Restore Version 4.1 requires the following files: objects.c rulebases.fws fwauth.ndb Version NG (all Feature Packs) - requires the following files: objects_5_0.c rulebases_5_0.fws fwauth.ndb Example /opt/cpmds-53/scripts/migrate_global_policies /tmp/global_files 4.1 Note - migrate_global_policies fails if there is a global policy assigned to a Customer, Do not to create and assign any Global Policy to a Customer before you run migrate_global_policies. Backup and Restore The purpose of the backup/restore utility is to backup an MDS as a whole, including all the CMAs that it maintains, and to restore it when necessary. The restoration procedure brings the MDS to the state it was at when the backup procedure was executed. The backup saves both user data and binaries. Restoration can be done on the original machine or, if your intention is to upgrade by replicating your MDS for testing purposes; to another machine. When performing a restoration to another machine, if the machine s IP address or interface has changed, refer to Changing MDS IP address and External Interface on page 115 for instructions on how to adjust the restored MDS to the new machine. During backup, it is okay to view but do not write using MDGs, GUIs or other clients. If the Provider-1/SiteManager-1 system consists of several MDSes, the backup procedure takes place manually on all the MDSes concurrently. Likewise, when the restoration procedure takes place, it should be performed on all MDSes concurrently. mds_backup This utility stores binaries and data from your MDS installation. Running mds_backup requires super-user privileges. This is done by running the gtar command on the root directories of data and binaries. Any extra information located under these directories is backed up except from files that are specified in mds_exclude.dat ($MDSDIR/conf) file. The collected information is wrapped in a single zipped tar file. The name of the created backup file is constructed by the date and time of the backup, followed by the Chapter 9 Upgrading Provider-1 91

92 Provider-1/SiteManager-1 Upgrade Practices extension.mdsbk.tgz. For example: 13Sep mdsbk.tgz. The file is put in the current working directory, thus it is important not to run mds_backup from one of the directories that will be backed up. For example, when backing up a NG FP3 MDS, do not run mds_backup from /opt/cpmds-53 since you cannot zip the directory you ll need to write into. Usage mds_backup mds_restore Restores a MDS that was previously stored with mds_backup. For correct operation, mds_restore requires a fresh installation of a MDS from the same version of the MDS to be restored. Usage for NG with Application Intelligence since (R54) mds_restore <backup file> for NG prior to NG with Application Intelligence since (R54) mds_restore <backup file> $MDSDIR/bin/set_mds_info -b -y Provider-1/SiteManager-1 Upgrade Practices The Provider-1/SiteManager-1 upgrade process supports several upgrade practices to answer different upgrade scenarios. In-place Upgrade The upgrade process occurs on the existing MDS machine. The MDS with all CMAs are upgraded during a single upgrade process. To employ in-place upgrade see mds_setup ( Installation Script on page 86). Steps for In-place Upgrade: 1 Run the Pre-upgrade verification only option from mds_setup. In a multi-mds environment, perform this step on all MDSes (see Upgrading in a Multi MDS Environment page 109). 2 Make the required changes and if you have High Availability, do the required synchronizations. 3 Test your changes: 92

93 Replicate and Upgrade A assign global policy B install policy C verify logging (through SmartView Tracker) D view status (through MDG or SmartView Status) 4 Backup your system either by selecting the backup options from mds_setup or by running mds_backup. 5 After the upgrade completes, retest using the sub-steps in step 3 above. Upgrading your Operating System If your current operating system is not supported by the new Provider-1/SiteManager-1 installation you will be required to upgrade the operating system first. For example, if you have a Version 4.1 MDS on Solaris 2.6 and you wish to upgrade to NG MDS Solaris 2.9: 1 Upgrade your operating system to the Solaris 2.8 platform because it is supported by both NG with Application Intelligence and Version Upgrade your MDS to NG with Application Intelligence. 3 Then upgrade your operating system to Solaris 2.9. Replicate and Upgrade Choose this type of upgrade if you intend to change hardware as part of the upgrade process or if you wish to test the upgrade process first. The existing MDS installation is copied to another machine (referred to as the target machine) by using the mds_backup and mds_restore commands. Steps for employing Replicate and Upgrade: 1 Backup your existing MDS. This can be done by running mds_backup or by running mds_setup and selecting the Backup option. 2 Install a fresh MDS on the target machine. In order to restore your existing MDS, first install a fresh MDS on the target machine that is the exact same version as your existing MDS. Note - The target machine should be on an isolated network segment so that modules connected to the original MDS are not affected until you switch to the target machine. Chapter 9 Upgrading Provider-1 93

94 Provider-1/SiteManager-1 Upgrade Practices 3 Restore the MDS on the target machine. Copy the file created by the backup process to the target machine and run mds_restore, or run mds_setup and select the Restore option. 4 If your target machine and the source machine have different IP addresses, follow the steps listed in IP Address Change on page 115 to adjust the restored MDS to the new IP address. If your target machine and the source machine have different interface name (e.g. hme0 and hme1), follow the steps listed in Interface Change on page 115 to adjust the restored MDS to the new interface name. 5 Test to confirm that the replication has been successful: A Start the MDS. B Verify that all CMAs are running and that you can connect to the MDS with MDG and Global SmartDashboard. C Connect to CMAs using SmartDashboard. 6 Upgrade your MDS. Stop the MDS on the target machine and employ an In-Place Upgrade (see In-place Upgrade on page 92 for further information). Gradual Upgrade on the same machine - Version 4.1 The upgrade process allows you to run the new NG MDS in parallel with Version 4.1 s MDS on the same machine, gradually moving the management of remote modules from 4.1 customers to NG CMAs. Choose this method if you are upgrading from Version 4.1 and you intend to continue using your existing hardware. Preparations To prepare your environment for the upgrade: 1 Make sure your machine meets the minimal hardware requirements for Provider-1/SiteManager-1 NG with Application Intelligence. Verify that you have enough disk space to allow for both versions to run concurrently. These requirements are listed in the Installing MDS chapter of the Provider-1 User Guide. 2 Stop the MDS and run an In-Place Upgrade (see In-place Upgrade on page 92). 3 In NG with Application Intelligence, the.profile and.cshrc files of user root, are modified by default during the installation. While installing, NG with Application Intelligence when prompted, refuse to change the.profile and.cshrc files during installation. 94

95 Gradual Upgrade on the same machine - Version When the upgrade ends and you are asked whether you want to run the MDS now, select No. 5 You should have two shell configurations for the Provider-1/SiteManager-1 machine: A The first shell should have the Version 4.1 MDS environment. As long as both MDSes are on the same host, you must have both of the above shell configuration types: one for the Version 4.1 MDS and one for the NG with Application Intelligence MDS. Run the following commands from the cshell: i setenv FWDIR /opt/cpmds-41 ii setenv FWDIR_BASE $FWDIR iiiset path=($fwdir/bin $path) iv source $FWDIR/bin/setmdsenv The last line defines the aliases mdsenv and mcd. B In the second shell set up the NG MDS environment run: source /opt/cpshared/5.0/tmp/.cpprofile.csh (for csh) or. /opt/cpshared/5.0/tmp/.cpprofile.sh (for sh). 6 On the NG with Application Intelligence shell, run the script prepare_gradual_upgrade that was provided with the Provider-1/SiteManager-1 NG with Application Intelligence installation. This script creates the disable_cma file for each CMA under $FWDIR/conf sub-directory. The mdsstart_customer and mdsstop scripts look for these disabling files, and know not to start disabled customers and not to remove virtual IP addresses of disabled customers during the mdsstop operation. The prepare_gradual_upgrade script also modifies the Version 4.1 mdsstart_customer and mdsstop scripts to support the gradual upgrade, so the Version 4.1 scripts can also detect disabled Version 4.1 CMAs. In addition, it adds the mds_enable_cma and mds_disable_cma scripts to the Version 4.1 scripts. 7 You can now start your Version 4.1 MDS, which will still manage all the CMAs. Gradually Upgrading the Primary MDS After the above preparations for upgrading your Version 4.1 MDS, the Provider-1 Version 4.1 MDS manages CMAs like it did prior to the upgrade. Two shells are open: one for the Version 4.1 MDS and the other for the NG with Application Intelligence MDS. The mdsstart and mdsstop scripts are modified to control the process of moving the Version 4.1 CMAs to NG with Application Intelligence. Chapter 9 Upgrading Provider-1 95

96 Provider-1/SiteManager-1 Upgrade Practices All NG with Application Intelligence CMAs are disabled at this point. This lock prevents the CMAs from running in almost all cases, including mdsstart, mdsstart_customer and the mdgstart commands. You can now safely move your CMAs one by one from Version 4.1 to NG with Application Intelligence. For each CMA you move: 1 Stop it in Version Disable it in Version Enable it in NG with Application Intelligence. 4 Start it in NG with Application Intelligence. Two CMAs should not run at the same time. The disabling mechanism helps ensure that once you disable a CMA, it is locked and will not start by any manual or automatic methods. Both the NG with Application Intelligence and the Version 4.1 environments have two new scripts: mds_disable_cma and mds_enable_cma These scripts add and remove the disable_cma file (add it for disabling the CMA and remove it for enabling the CMA). Upgrade Steps 1 Start the NG with Application Intelligence MDS for the first time by running the mdsstart command in the NG with Application Intelligence shell. 2 Log into the Provider-1/SiteManager-1 machine with both the Version 4.1 and the NG with Application Intelligence MDGs (this assumes that both MDSes are running). 3 Install the NG with Application Intelligence license for the first NG with Application Intelligence CMA you are going to run. 4 Stop the Version 4.1 CMA you want to move to NG with Application Intelligence. 5 Disable the Version 4.1 CMA by running mds_disable_cma <CMA vip> in the Version 4.1 shell. 6 At this point, you may wish to perform the cma_migrate (see cma_migrate on page 87) command to update the NG with Application Intelligence CMA with all latest changes done in the Version 4.1 CMA. This is required if after the Provider-1/SiteManager-1 NG with Application Intelligence upgrade you continued to work on a certain CMA in the Version 4.1 MDS and made changes 96

97 Gradual Upgrade on the same machine - Version 4.1 to its database. This migration ports all these changes to the parallel NG with Application Intelligence CMA. If you have not made any changes in the 4.1 CMA, cma_migrate is not necessary. Note - If, by mistake, the NG with Application Intelligence CMA was started before the migration, cma_migrate is not possible. If this is the case, remove the NG with Application Intelligence CMA, create a new one and then migrate it. It is very important to create the NG with Application Intelligence CMA immediately after removing it. If you remove several CMAs and then try to create them, the VIP index may change, so that corresponding CMAs from Version 4.1 and NG with Application Intelligence have different VIP indexes. 7 Enable the corresponding NG with Application Intelligence CMA, by running the command mds_enable_cma <CMA name or CMA vip> from the NG with Application Intelligence shell. 8 Start the NG with Application Intelligence CMA. 9 Make sure that you can login to the NG with Application Intelligence CMA via SmartDashboard. 10 Repeat this procedure for all CMAs (at your convenience). Warning - Running the Version 4.1 CMA and the corresponding NG with Application Intelligence CMA simultaneously is not recommended, since most operations will not work. For this reason, CMAs are disabled; thereby helping to maintain, which CMA is currently the operational one. 11 You can revert back to the Version 4.1 CMA as follows: A Stop the NG with Application Intelligence CMA. B Disable it. C Enable and start the corresponding Version 4.1 CMA. D If any changes were made in the NG with Application Intelligence CMA, you will have to repeat them manually on the Version 4.1 CMA. Gradually Upgrading Additional MDSes The gradual upgrade procedure supports Provider-1/SiteManager-1 systems with Additional MDSes: 1 Start the procedure on the primary MDS, up until the point where you have both the Version 4.1 and the NG with Application Intelligence MDSes running on the primary MDS host. 2 Port as many CMAs as needed on the primary MDS from Version 4.1 to NG with Application Intelligence. Chapter 9 Upgrading Provider-1 97

98 Provider-1/SiteManager-1 Upgrade Practices 3 Upgrade one of the additional MDSes, (see Upgrading in a Multi MDS Environment on page 109). In summary, this includes the following operations: A Copy the scheme.c file from the primary MDS to the additional MDS. B Run the upgrade on the additional MDS. C Copy the file <mds host name>_secondary_upgrade_data.tar back to the primary MDS. D Run mds_merge on the primary MDS. Each of these steps needs to take place on the NG with Application Intelligence shell (and not the Version 4.1 shell) on both MDSes. 4 From the NG with Application Intelligence shell, run the prepare_gradual_upgrade script on the additional MDS. 5 From the Version 4.1 shell window of the Additional MDS, start the Version 4.1 MDS and verify that it is working properly. 6 Start the NG with Application Intelligence MDS from the shell window of the additional MDS and verify that it is working properly and that all its CMAs are stopped. 7 CMAs are ported onto the additional MDS the same way they are ported onto the primary MDS: A Stop and disable the Version 4.1 CMA (mds_disable_cma for Version 4.1) B Enable and start the corresponding NG with Application Intelligence CMA (mds_enable_cma from the NG with Application Intelligence shell). C If necessary, perform the cma_migrate command (see step 6 on page 96 to decide if cma_migrate is necessary). Gradual Upgrade to Another Machine Information that is not retained If you are upgrading to another machine, one CMA at a time, the following information is not remained: 1 Provider-1/SiteManager-1 Administrators To do: Redefine and reassign to customers after the upgrade. 2 Provider-1/SiteManager-1 SmartConsole Clients To do: Redefine and reassign to customers after the upgrade. 98

99 Gradual Upgrade to Another Machine 3 Policy assignment to customers To do: Assign policies to customers after the upgrade, 4 Global Communities statuses. To do: execute the command: mdsenv; fwm mds rebuild_global_communities_status all Upgrade steps 1 Install MDS of the target version onto the target machine. 2 Create a customer and CMA but do not start the CMA. 3 Use the migrate_assist utility to copy the CMA directories and files from the source machine to the destination machine. For further information see migrate_assist on page 89. During the migration of CMAs, the CMA IP address can change. Read cma_migrate ( cma_migrate on page 87) for considerations regarding CMA IP address changes. 4 Use migrate_global_policies to import the global policies. Gradual Upgrade with Global VPN Considerations A gradual upgrade process in an MDS configuration that uses the Global VPN Communities (GVC) is not fundamentally different from the gradual upgrade process described above, with a few exceptions: 1 Global VPN community setup involves the Global database and the CMAs that are managing gateways participating in the global communities. When gradually upgrading a GVC environment split the upgrade into two parts: one for all the CMAs that do not participates in the GVC and one for CMAs that do. 2 If some of your CMAs have already been migrated and some have not and you would like to use the Global Policy, make sure that it does not contain gateways of non-existing customers. To test whether you have non-existing customers, assign this Global Policy to a customer. If the assignment operation fails and the error message lists problematic gateways, you have at least one non-existing customer. If this occurs: A Run the where used query from the Global SmartDashboard > Manage > Network Objects > Actions to figure out where the problematic gateway(s) are used in the Global Policy. Review the result set and edit or delete list items as necessary. Make sure that no problematic gateways are in use. Chapter 9 Upgrading Provider-1 99

100 Provider-1/SiteManager-1 Upgrade Practices B the gateways must be disabled from global use: i ii From the MDG s General View, Right Click on a gateway and select Disable Global Use. If the globally used gateway refers to a gateway of a customer that was not migrated, you can remove the gateway from the global database by issuing a command line command. First make sure that the Global SmartDashboard is not running, then execute the command: mdsenv; remove_globally_used_gw <Global name of the gateway> 3 When issuing the command: migrating_global_policy where the existing Global Policy contains Global Communities, the resulting Global Policy contains: the globally used gateways from the existing database and the globally used gateways from the migrated database. As a result of the migration, the Global Communities are overridden by the migrated database. 4 The gradual upgrade does not restore the Global Communities statuses; therefore, if: the existing Global Policy contains Global Communities or the migrated Global Policy contains Global Communities reset the statuses from the command line (with MDS live): mdsenv; fwm mds rebuild_global_communities_status all Migrating from Stand Alone installation to CMA This section describes how to migrate the management part of a Stand Alone Gateway to a CMA, and then manage the Stand Alone Gateway (as a module only) from the CMA. Terminology Stand Alone Gateway (SGW) - management and module installed on the same host. modulea - the module on Machine A during and after the separation procedure. Machine A - the machine on which the SGW is installed. Machine B - the machine on which the MDS is installed (with the target CMA). Note - If you want the option to later undo the separation process, backup your SGW before migrating. 100

101 Migrating from Stand Alone installation to CMA An Overview of the Stand Alone Installation to CMA Migration Procedure Here is a broad overview of the steps performed in TABLE 9-3 (for Version 4.1 Stand-alone Station) and TABLE 9-4 for (for NG Stand-alone Station): 1 Migrating the Management part of the SGW into the target CMA. This requires some adjustments to the SGW before export and to the CMA after migration. 2 Uninstalling the SGW and reinstalling a module on Machine A. 3 Maintaining trust between the CMA and all the modules previously managed by the SGW: A For NG modules, SIC is automatically maintained. B For Version 4.1 modules, re-establish trust manually. Note - This procedure also covers cases where the SGW manages additional modules other than itself. Chapter 9 Upgrading Provider-1 101

102 Provider-1/SiteManager-1 Upgrade Practices From a Version 4.1 Installation TABLE 9-3 Migrating from Stand Alone to CMA from Version 4.1 machine steps Prepare SGW for Export Machine A 1 Make sure that: A FTP access is allowed from Machine B (machine on which the MDS is installed with the target CMA) to Machine A (machine on which SGW is installed). This is only necessary if you plan to use migrate_assist. B CMA (On Machine B) will be able to communicate with and install policy on all managed modules. 2 Launch the Policy Editor. The Policy Editor is the Version 4.1 terminology for SmartDashboard. 3 If changes were made to the rule base in step 1: A Install policy on all relevant managed gateways. B Delete any objects or access rules you created in step 1. 4 Edit the object representing the SGW: A Give it the name and IP address of the target CMA. B Under Modules Installed, uncheck VPN-1 & Firewall-1. 5 Save and close the Policy Editor. Do not install the policy. 102

103 Migrating from Stand Alone installation to CMA TABLE 9-3 Migrating from Stand Alone to CMA from Version 4.1 machine steps Export the management database from Machine A and import it to CMA on the MDS on Machine B Machine B 1 Run the command: migrate_assist <SGW_NAME> <SGW_FWDIR> <username> <password> <target_dir> 2 Create a new CMA on the MDS but do not start it. 3 Migrate the exported database into CMA from the target directory of migrate_assist (<target_dir>). Configure CMA. Start managing all modules from CMA, except module A Machine B 1 Start the CMA and on the CMA, launch SmartDashboard. In SmartDashboard under Network Objects find: A An object with the name and IP address of the CMA which is the primary management object (migrated). B An object for each module managed by the SGW (except for modulea). 2 Edit the Primary Management Object and remove all interfaces (Network Object > Topology > Remove). Chapter 9 Upgrading Provider-1 103

104 Provider-1/SiteManager-1 Upgrade Practices TABLE 9-3 Migrating from Stand Alone to CMA from Version 4.1 machine steps Machine B (cont...) 3 Create an Object representing modulea (From New > Check Point > Gateway): A Assign a Name and IP address for modulea. B Select the appropriate Check Point product version. C Check the appropriate Check Point products installed on it. D Do not initialize communication. 4 Run Where Used on the primary Management Object and in each location, consider changing to the gateway object (modulea). 5 Adjust the Masters and log servers. For each Version 4.1 module, add the new CMA to the Masters list. 6 Run the fw putkey command (both from gateway to CMA and from CMA to gateway) to re-establish trust with Version 4.1 modules (if you have any), except for modulea. 7 Install Policy on all modules, except for modulea. Any warning messages you receive regarding modulea occur because it is not yet configured and can be safely ignored. Reinstall module on Machine A and Prepare for SIC with the CMA 104

105 Migrating from Stand Alone installation to CMA TABLE 9-3 Migrating from Stand Alone to CMA from Version 4.1 machine steps Machine A 1 Uninstall the Check Point SGW. 2 Install the module: A choose the distributed deployment B choose the enforcement module C run the setup intructions according the SmartCenter User Guide. Start managing modulea from CMA Machine B 1 Re-establish trust with modulea. 2 Define modulea s topology in the CMA SmartDashboard. 3 Install the Policy on modulea. Chapter 9 Upgrading Provider-1 105

106 Provider-1/SiteManager-1 Upgrade Practices From NG (All Feature Pack) Installation TABLE 9-4 Migrating from Stand Alone to CMA from NG forward machine steps Prepare SGW for Export Machine A 1 Make sure that: A FTP access is allowed from Machine B (machine on which the MDS is installed with the target CMA) to Machine A (machine on which SGW is installed). This is only necessary if you plan to use migrate_assist. B CMA (On Machine B) will be able to communicate with and install policy on all managed modules. 2 Add an object representing the CMA (name and IP address) and define it as a Secondary SmartCenter Server. 3 Install policy on all managed gateways. 4 Delete all objects or access rules created in steps 1 and 2. 5 If the SGW has VPN-1 installed: A Uncheck VPN-1 from the Check Point Products section of the SGW object. You may have to first remove it from the Install On column of your rulebase (and then add it again). B If the SGW participates in a VPN-1 community: in the VPN tab, remove it from the community and erase its certificate. Note these changes in order to undo them after the migration. 6 Save and close SmartDashboard. Do not install policy.. 106

107 Migrating from Stand Alone installation to CMA TABLE 9-4 Migrating from Stand Alone to CMA from NG forward machine Export the management database from Machine A and import it to CMA on the MDS on Machine B Machine B (cont...) steps 1 Run the migrate_assist <SGW_NAME> <SGW_FWDIR> <username> <password> <target_dir> <SGW_CPDIR> command. Do not forget to supply the last parameter <SGW_CPDIR>, this parameter is mandatory when running migrate_assist on NG. 2 Create a new CMA on the MDS but do not start it. 3 Migrate the exported database into CMA from the target directory of migrate_assist (<target_dir>). Configure CMA. Start managing all modules from CMA, except modulea Machine B 1 Start the CMA and on the CMA, launch SmartDashboard. In SmartDashboard under Network Objects find: A An object with the Name and IP address of the CMA which is the primary management object (migrated). Previous references to the SGW management object now refer to this object. B An object for each module managed by the SGW (except for modulea). 2 Edit the Primary Management Object and remove all interfaces (Network Object >Topology > Remove). Chapter 9 Upgrading Provider-1 107

108 Provider-1/SiteManager-1 Upgrade Practices TABLE 9-4 machine Migrating from Stand Alone to CMA from NG forward steps 3 Create an Object representing modulea (From New > Check Point > Gateway): A Assign a Name and IP address for modulea. B Select the appropriate Check Point version. C Check the appropriate Check Point Products you have installed. D If the Object previously belonged to a VPN-1 Community, add it back. E Do not initialize communication. 4 Run Where Used on the primary Management Object and in each location, consider changing to the gateway object (modulea). 5 Adjust masters and log servers: For each Version 4.1 module, add the new CMA to the masters list. 6 Run fw putkey to re-establish trust with Version 4.1 modules (if any), using fw putkey command. 7 Install Policy on all modules, except for modulea. You may get warning messages about modulea because it is not yet configured. Ignore these. Reinstall module on Machine A and prepare for SIC with the CMA Machine A 1 Uninstall the SGW. 2 Install the module. Start managing modulea from CMA Machine B 1 Re-establish trust with modulea. 2 Define modulea s topology in the CMA SmartDashboard. 3 Install the Policy on modulea. 108

109 Pre-Upgrade Verification and Tools Upgrading in a Multi MDS Environment Multi-MDS environments may contain components of High Availability in MDS or at the CMA level. It may also contain different types of MDSes: managers, containers or combinations of the two. In general, High Availability helps to reduce the down-time during the upgrade. This section explains guideline for performing an upgrade in a multi-mds environment. Specifically, it explains the order of upgrade and synchronization issues. Pre-Upgrade Verification and Tools Run pre-upgrade verification on all MDSes before applying the upgrade to a specific MDS by choosing the Pre-Upgrade Verification Only option from mds_setup (for further information see Pre-Upgrade Verifiers and Fixing Utilities on page 85). Only start upgrading the first MDS after you have fixed all the errors and reviewed all the warnings on all your MDSes. Upgrading a Version 4.1 System with an Additional MDS 1 Perform pre-upgrade verification for all MDSes. 2 If the pre-upgrade verifier requires a modification be done to the global database, then after modifying the global database, reassign it to all the customers. 3 Upgrade the Version 4.1 primary MDS by running the installation on the primary MDS. Once this installation is completed, you may run the primary MDS while you are upgrading the additional MDS. 4 Manually copy the scheme.c file from the primary MDS to the additional MDS (the path in both MDSes is: /opt/cpmds-41/conf). 5 Upgrade the additional MDS by running the installation on the additional MDS. Once this installation has completed, you can run the additional MDS. After copying the scheme.c file as mentioned in the prior step, run upgrade in place and execute the mds_setup script. 6 Copy the file $MDSDIR/tmp/<mds host name>_secondary_upgrade_data.tar from the additional MDS to the primary MDS (the path in both MDSes is: $MDSDIR/tmp). 7 Stop the primary MDS (using the mdsstop command). 8 Run the mds_merge script on the primary MDS to merge necessary data from the additional MDSes. Backup files can be found at $MDSDIR/tmp/premerge_backup. 9 Start the primary MDS and connect it to an MDG. The Additional MDS object should now be displayed in the MDG. Chapter 9 Upgrading Provider-1 109

110 Upgrading in a Multi MDS Environment 10 From the Multi-Domain Server Configuration window of the additional MDS object, click Communication and initiate trust with the additional MDS. 11 Perform the initial synchronization of the additional MDS. This MDS is known as the MDS Container in NG with Application Intelligence. This operation is performed from the MDG. If this operation fails, restart the additional MDS. 12 After upgrading the MDS containers and after the new SIC with the primary MDS has been initialized, restart the CMA's of the container. 13 Upgrading an MLM is not supported. Uninstall the Version 4.1 MLM and install a new NG with Application Intelligence MLM. Then define the MLM and redefine the CLMs from the MDG. 14 If you are upgrading a system with more than one additional MDS, repeat steps 2 through 10 for each additional MDS. Upgrading an NG with Application Intelligence Multi-MDS System MDS High Availability Communication between MDSes can take place only for MDSes of the same version. In a system with a single Manager MDS, there is a period of time when the container MDSes are not accessible. If more than one Manager MDS exists, follow these steps: 1 Upgrade one manager MDS. At this point all other containers are managed from the other manager MDS. 2 Upgrade all container MDSes. Each container MDS that you upgrade is managed from the already upgraded manager MDS. 3 Upgrade your second manager MDS. Following these steps promises continuous manageability of your container MDS. While containers do not accept SmartCenter connections, the CMAs on the container MDSes do. This means that even if you cannot perform global operations on the container MDS you can still connect to the CMAs that reside on it. Before the Upgrade 1 Perform pre-upgrade verification for all MDSes. 2 If the pre-upgrade verifier requires a modification to the global database, then after modifying the global database, all other MDSes should be synchronized. 110

111 Before the Upgrade 3 If this modification affects a global policy that is assigned to customers, then the global policy should be reassigned to the relevant customers, in order to repair the error in the CMA databases. 4 If a modification is required at the CMA level, then if it exists after modifying the CMA database, synchronize the mirror CMA. If the customer also has a CLM (on MLM) then install the database on the CLM to verify that the modification is applied to the CLM as well. Note - When synchronizing, make sure to have only one active MDS and one active CMA for each customer. Modify the active MDS/CMA and synchronize to Standby. CMA High Availability If you have CMA High Availability, this can help you to minimize the period of time in which gateways have no active CMA managing them. During the upgrade, you make changes to only one CMA, which is the Active CMA. After the upgrade of both CMAs, the High Availability status of the CMAs will appear as Collision. Synchronize the CMAs from the active CMA (the CMA to which you have made all the changes) to the standby CMA. Restoring your Original Environment Before the Upgrade Pre-upgrade utilities are an integral part of the upgrade process. In some cases, you will be required to change your database before the actual upgrade can take place or the Pre-Upgrade Verifier will suggest you execute utilities that perform the required changes automatically. Even if you decided restore your original environment, keep the changes you made as a result of pre-upgrade verification. Prepare a backup of your current configuration using the mds_backup utility from the currently installed version. Prepare a backup as first step of the upgrade process and prepare a second backup right after the Pre-Upgrade Verifier successfully completes with no further suggestions. Restoring your original environment 1 Removing a new installation: Chapter 9 Upgrading Provider-1 111

112 Renaming Customers A If the installation finished successfully, execute the mds_remove utility from the new version. This restores your original environment just before the upgrade, after the pre-upgrade verification stage. Despite this, you may need to install the backwards compatibility packages of the original environment by executing the pkgadd command. B If the installation stopped or failed before its completion, manually remove the new software packages by running the pkg_rm command. It may be easier for you to remove all Check Point installed packages and a perform fresh installation of the original version. 2 Perform mds_restore. Renaming Customers Previous Provider-1 versions allowed customer names or CMA names in Check Point 2000 to contain illegal characters, such as spaces and certain keyword prefixes. In NG with Application Intelligence, all customer names must adhere to the same restrictions as CMA names or any other network objects. Identifying Non-Compliant Customer Names The mds_setup utility performs several tests on the existing installation before an upgrade takes place. One of the tests is a test for customer names compliance with the new naming restrictions. If all customer names comply with the restrictions, no message is displayed. When a non-compliant customer name is detected, it is displayed on the screen, detailing the reason why the name was rejected. High-Availability Environment In an MDS High Availability environment, non-compliance is detected on the first MDS you upgrade. The mds_setup utility identifies non-compliant names as more than a single MDS. Since this is non-compliant, an error message is issued. Automatic Division of Non-compliant Names If the number of customers with non-compliant names is large, the translation task may automatically divide into several sessions. By default, all the intermediate work is saved. 112

113 Resolving the Non-compliance Resolving the Non-compliance During the upgrade procedure, after selecting Option 2 - Upgrade to NG with Application Intelligence on the mds_setup menu, the resolution to compliant names is performed. The translation prompt is only displayed if a non-compliant name is detected. Note - Nothing will be changed in the existing installation when translating customer names. Any changes are applied only to the upgraded installation. Translation prompt - Enter a name to replace the non-compliant name, or enter the '-' sign to get a menu of additional options. The new name is checked for naming restrictions compliance and is not accepted until you enter a compliant name. Additional options menu Both CMAs in Check Point 2000 and customers in NG with Application Intelligence are referred to as customers in this section. Edit another name - The customer names are presented in alphabetic order. Choose this option to edit a customer name that was already translated, or any other customer name. Skip this name - Choose this option if you are not sure what to do with this name to come back to it later. The upgrade cannot take place until all non-compliant customer names are translated. Quit session and save recent translations - Choose this option if you want to save all the work that was done in this session and resume later. Quit session and throw away recent translations - Choose this option if you want to abort the session and undo all the translations that you entered during this session. Return to translation prompt - Choose this option if you want to return to the customer name you were prompted with when you entered '-'. Note - The pre-upgrade tool allows only non-compliant customer names to be translated. If the session is exited before all the translations are done, the mds_setup utility exits with an error message stating that the MDS verification failed. To return to the tool, simply run mds_setup again and choose Option 2 - Upgrade to NG with Application Intelligence. Chapter 9 Upgrading Provider-1 113

114 Renaming Customers High-Availability After completing the translations on the first MDS, copy the following files to the other MDSes. If the MDSes are properly synchronized, no additional work will be required on them. Files to be copied: /var/opt/cpcustomers_translated.txt /var/opt/cpcustomers_translated.md5 When running the tool a second time, the customer names that were already translated will be shown before the first non-compliant name is displayed. This will also be the case when running on an additional MDS. Advanced Usage An advanced user may choose to directly edit the translation file, /var/opt/cpcustomers_translated.txt. In this case, all the translations will be verified when mds_setup is run again. Translations file format - The file is structured line-wise. Each line's meaning is indicated by its first character. An empty line is ignored. Any line that does not obey the syntax causes the file to be rejected with an appropriate message. TABLE 9-5 Line Prefixes Line Prefix Meaning Comment # A comment line. May be inserted anywhere. - Existing non-compliant name. + A translation for the preceding '-' line. Must exactly match an existing non-compliant name, otherwise it will be rejected. If the entry does not comply with the naming restrictions, it is ignored. The '-' and '+' lines must form pairs. Otherwise, the file is rejected. If the translations file is manually modified, the mds_setup will detect it and will display the following menu: 1 Use the translations file anyway - Choose this option only if an authorized person modified it. This option will read the file, verify its content and use the translations therein. 114

115 IP Address Change 2 Ignore the translations file and generate a new one - Choose this option if you want to overwrite the contents of the file. 3 Quit and leave the translations file as it is - Choose this option if you wish to exit mds_setup and leave the translations file as is for now. Run mds_setup again when you are sure that option 1 or option 2 is suitable. Changing MDS IP address and External Interface IP Address Change If your target machine and the source machine have different IP addresses, please follow the steps listed below in order to adjust the restored MDS to the new IP address: 1 The MDS must be stopped. Stop the MDS by running mdsstop. 2 Change the IP address in $MDSDIR/conf/LeadingIP file to the new IP address. 3 Edit the $MDSDIR/conf/mdsdb/mdss.C file. Find the MDS object that has the source MDS IP address and change its IP address to the new IP address. Do not change the name of the MDS. 4 Due to the change of IP address install a new license on the target MDS with the new MDS IP address. 5 Edit the $MDSDIR/conf/mgmtha.conf file. Find the MDS objects that has the source MDS IP address and change its IP address to the new IP address. 6 Update all other MDSs and MLMs to notify them about the IP address change. A Stop the MDS by mdsstop -m (no need to stop the CMAs) B Edit the $MDSDIR/conf/mdsdb/mdss.C file. Find the MDS object that has the source MDS IP address and change its IP address to the new IP address. Do not change the name of the MDS. C Edit the $MDSDIR/conf/mgmtha.conf file. Find the MDS objects that has the source MDS IP address and change its IP address to the new IP address. D Start the MDS by mdsstart -m (no need to start the CMAs). Interface Change If your target machine and the source machine have different interface name (e.g. hme0 and hme1), follow the steps listed below in order to adjust the restored MDS to the new interface name: Chapter 9 Upgrading Provider-1 115

116 Changing MDS IP address and External Interface 1 Change the interface name in file $MDSDIR/conf /external.if to the new interface name. 2 For each CMA replace the interface name in $FWDIR/conf/vip_index.conf. For example if this is an NG FP3 installation and you have a CMA named cma1, edit /opt/cpmds-53/customers/cma1/cpfw1-53/conf/vip_index.conf. 116

117 Appendix A Behavioral Changes in FireWall-1 In This Chapter Introduction to Behavioral Changes in FireWall-1 page 117 Behavioral Changes In Stateful Inspection page 118 Behavioral Changes in NAT page 126 Behavioral Changes for Services Features page 129 New Service Features page 131 Behavioral Changes in INSPECT page 134 FTP Related INSPECT Solutions page 136 Authentication related INSPECT solutions page 144 Services Related INSPECT Solutions page 147 Custom INSPECT Services page 149 INSPECT Accounting solutions page 153 INSPECT and Load Balancing page 157 Introduction to Behavioral Changes in FireWall-1 Since Version 4.1 the many FireWall-1 features have changed and improved and many new features have been added. 117

118 Behavioral Changes In Stateful Inspection In This Section TCP Connection Establishment (three-way handshake) page 119 TCP Sequence Verification page 120 Connections Recovery After Policy Installation page 121 First TCP Packet page 122 Stateless Checks page 124 Default session timeouts page 125 TCP Connection reuse In some cases, FireWall-1 may encounter a SYN packet that appears to belong to an already established TCP connection. This often happens when the state of the connection within FireWall-1's session table does not reflect the client's real state, and the client attempts to reuse the same port for a new connection. For instance, if a client machine crashed in the middle of a connection, without terminating it properly and then attempts to recover it by opening an identical connection from the same source port, both FireWall-1 and the server assume there is an already existing connection when the client's SYN packet is encountered. Section Summary There are possible security implications when allowing TCP connection reuse, because the SYN packet may be spoofed by an attacker trying to interrupt the connection. Both Version 4.1 and NG with Application Intelligence allow TCP connection reuse, but NG with Application Intelligence uses much smarter and secure mechanism that determines if the reuse attempt is authentic or not. Version 4.1 SP5 Solution Because a malicious user can hijack a connection by sending a spoofed SYN packet, FireWall-1 cannot trust a SYN packet and then simply reuse the previous connection. Version 4.1 ascribed the SYN packet to the existing connection, by keeping the original connection entry within the sessions table. However, passing the SYN packet on the previous connection entry may cause the following problems: Since Firewall-1 uses the same connection entry, it is impossible to initialize data, which is required whenever a new connection is recorded (e.g. TCP sequences). Firewall-1 may not distinguish correctly between different connections for the purposes of accounting, monitoring etc. 118

119 NG with Application Intelligence Solution FireWall-1 for NG with Application Intelligence offers a much better solution to this problem. When a SYN packet is encountered on an established connection, FireWall-1 changes it into an ACK packet, forwards it to the server and waits for the server's reply. If the server replies with an RST packet, it means that the server is not familiar with such an established connection matching the SYN packet. Therefore the client's original SYN packet is valid. FireWall-1 deletes the previous connection s entry, and the client s next SYN retransmission is treated like a regular new connection attempt and the connection would be established after completing a full TCP 3-way handshake. If the server replies with an ACK packet, it means that the server has an established connection matching the SYN packet (the server "agrees" with the FireWall). In this case, FireWall-1 forwards the ACK packet to the client. If the first SYN packet was sent by the client (i.e. not spoofed by an attacker), the client sends an RST packet followed by a new SYN packet, and a connection re-establishes. TCP Connection Establishment (three-way handshake) A TCP connection starts with a sequence of three packets, referred to as "three-way handshake". The process starts with a SYN packet, sent by the client, to which the server replies with a SYN-ACK. The client then sends an ACK packet, and only then the connection is considered established. Once the connection becomes established, FireWall-1 increases the connection's timeout from TCP start timeout (normally about a minute or less) to TCP session timeout (an hour by default). Section Summary FireWall-1 for NG with Application Intelligence enforces additional security, by not letting suspicious server-to-client packets pass during the three-way handshake. This additional security does not affect connectivity, because FireWall-1 produces the expected behavior on behalf of the client without actually letting the suspicious packets through. FireWall-1 enables additional sanity checks upon three-way handshake packets, which are disabled by default. Version 4.1 Solution In Version 4.1, FireWall-1 follows the three-way handshake in order to find out when connections became established. However, FireWall-1 did not enforce any sanity checks upon the packets that are encountered during the handshake. Examples of possible violations are: Appendix A 119

120 A client that sends the SYN packet followed by data packets, without receiving any reply from the server A server that responds with an ACK packet instead of a SYN-ACK packet A server that starts sending data before the connection's establishment. NG with Application Intelligence Solution In NG with Application Intelligence, there is a mechanism that allows strict enforcement of the TCP three-way handshake. By default, most of the enforcement is off, except for a case where a server replies to a SYN packet with an ACK packet instead of a SYN-ACK packet. In such cases, FireWall-1 sends an RST packet to the server on behalf of the client, and waits for the client's retransmission to re-start the connection. In Version 4.1 FireWall-1 would have let the server's ACK packet pass, and the client would have sent the RST packet itself, followed by a new SYN packet. Disable the NG with Application Intelligence feature to let server packets pass by setting the FireWall-1 kernel s global parameter fw_allow_out_of_state_syn_resp to 1. TCP Sequence Verification Since NG FP3, FireWall-1 performs sequence verification on TCP packets. The default mode for NG with Application Intelligence is that packets are not dropped or logged on the basis of wrong sequence numbers. However, FireWall-1 still performs decisions according to the validity of TCP sequences. Section Summary Additional security checks were added upon connection establishment and tear down. By default, out of sequence packets pass FireWall-1, but FireWall-1 is less vulnerable to attacks that can be prevented by sequence verification. FireWall-1 for NG with Application Intelligence also offers full sequence verification mode, where out of sequence TCP packets are dropped and logged. This mode is disabled by default. DOS attack on connections table A malicious user can send a spoofed SYN packet to an open port, followed by a spoofed ACK packet. Since the packet is spoofed, the attacker does not know the sequence number of the server's SYN-ACK packet. If you have a FireWall that does not perform sequence verification, it may wrongly assume the connection is established, and increase the connection's timeout to the TCP session timeout (one hour by default). FireWall-1 for NG with Application Intelligence makes sure the client's ACK number 120

121 matches the SYN-ACK packet that was sent by the server. If the client's ACK number does not match, the packet passes FireWall, but the connection's timeout is not increased. Disable the feature and do not verify sequences upon the connection's three way handshake, by using the dbedit utility to set FireWall-1's attribute fw_trust_suspicious_estab to 1. Spoofed RST attack A malicious user can send spoofed RST packets over a range of ports. Such an attack can cut existing connections if there is a FireWall on the way that does not perform sequence verification, since RST packets represent connection tear down. In NG with Application Intelligence, when an RST packet is received, FireWall-1 makes sure the packet does not contradict the connection's sequences. An RST packet with contradictory sequences passes FireWall-1, but the connection's timeout is not decreased to TCP end-session s timeout. Disable the feature, and do not verify sequences of RST packets, by using the dbedit utility to set the FireWall-1's attribute fw_trust_suspicious_rst to 1. Connections Recovery After Policy Installation When a security policy is installed, it is not clear whether existing connections are still allowed in the newly installed policy. To address this issue, FireWall-1 marks all existing connections as inconsistent. Once a client-to-server packet is encountered on such an inconsistent connection, FireWall-1 performs a rule-base match again, and decides whether the connection should be revived or not. This approach can be problematic for two reasons: 1 If the first packet encountered after policy installation comes from the server, it cannot be matched against the rulebase. If it is a TCP connection, FireWall-1 changes the packet in such a way that encourages the client to reply. In other protocols, the server packet is simply dropped. 2 Data connections are pre-recorded, based upon the inspection of control connections' commands. Once a data connection begins, it is not matched against the rulebase, and it passes due to the pre-recorded connection entry. Therefore, in many cases, data connections do not match the rulebase. Consequently, there is no way to know whether a data connection is allowed after a policy is installed. Appendix A 121

122 Section Summary FireWall-1 for NG with Application Intelligence offers new capabilities for keeping connections open through policy installation. For further information see Keep Connections During Policy Reload on page 131. However, the default behavior in NG has stricter enforcement by default when compared to Version 4.1 SP5, since data connections are deleted upon policy installation, and are not given the chance to be re-matched against the rulebase. This may affect security policies that are permissive enough to accept data connections (e.g. allow any traffic between certain IP addresses). Version 4.1 SP5 Solution In Version 4.1 SP5, the solution to these problems was to match every connection against the rulebase after policy installation. This caused problems for non-tcp connections that relied on server-to-client packets, and to data connections, which in many cases did not match the rulebase despite being allowed. NG with Application Intelligence Solution In NG with Application Intelligence, the default behavior is to simply delete data connections upon policy installation. This means the default behavior can affect connectivity of data connections if a rulebase is permissive enough to allow them, since they are deleted anyway upon policy installation. In FireWall-1 for NG with Application Intelligence, it is possible to choose between three different modes: 1 Delete data connections after policy installation and rematch all other connections (the default). 2 Keep all connections after policy installation. If a previous connection does not match the new security policy, it still passes FireWall-1 after policy installation. 3 Keep data connections after policy installation and rematch all other connections. In addition, it is possible to decide per service whether connections should be kept across policy installation, this may be important for services like Voice over IP so that your phone connection is not disconnected when the policy is reloaded. For further information see Keep Connections During Policy Reload on page 131. First TCP Packet TCP connections always start with a SYN packet. However, there are some cases in which the first packet FireWall-1 encounters in a connection is not a SYN packet, and yet the packet should pass. 122

123 One example of this is low-traffic connections. FireWall-1 records each connection with a certain timeout, which is refreshed every time a packet that belongs to the connection is encountered. When no traffic is encountered for a long time, the connection entry may expire. If a packet is encountered after expiration, FireWall-1 treats it as the first packet of a new connection, and may drop it since it is not a SYN packet. Similar problems can happen when FireWall-1 encounters traffic that belongs to connections that were not inspected before (e.g. when FireWall-1's machine recovers from a boot, or after the FireWall-1 module is re-installed). This problem specifically concerns FireWall internal connections, which must survive the module re-installation. Section Summary NG with Application Intelligence offers new ways that allow starting connections inspection from the middle, or at least informing the peers of a previous connection that something went wrong. However, the solution for starting the inspection from the middle of connection is not complete, and user may still experience connectivity problems in such cases, unless the rulebase is permissive enough. Version 4.1 SP5 Solution In Version 4.1 SP5, it was possible to edit the INSPECT code and allow non-syn packets for required services, but there was no comprehensive solution to the problem. NG with Application Intelligence Solution NG with Application Intelligence offers two different approaches: 1 Do not allow connections to start with a non-syn packet, but notify the packet s sender that something has gone wrong, by replying with an RST packet. Enable this feature by setting the FireWall kernel global parameter fw_reject_non_syn to 1. 2 Allow connections to start with a non-syn packet. This can be done in one of the following ways: a. Select the checkbox allow out of state TCP packets in the Stateful Inspection tab of the Global Properties dialog. Appendix A 123

124 b. Manually edit the INSPECT script user_accept_non_syn, located in base.def file under $FWDIR/lib on the SmartCenter Server. The script should contain specific scenarios where connections can be initialized by non-syn packets. This approach (for both a and b above) has severe implications: The connection's entry holds important information that cannot be reproduced simply by opening a new connection on the fly (e.g. NAT hide port). When the first packet that FireWall-1 encounters comes from server to client, the service is usually not recognized correctly. If this occurs, the packet may not match the rulebase, or pass on a different rule. This may have both security and connectivity implications. Stateless Checks One of the features that was added in NG with Application Intelligence is a strict enforcement of TCP flags. Specifically, FireWall-1 drops SYN-RST packets (packets with both SYN and RST flags turned on). However, in certain TCP stacks, a SYN-RST packet may serve as a "hard reset" for the server, enabling all clients to resume connectivity with that server. In such configurations, clients always use the same source ports, until at some stage the server stops replying to new connection attempts. At this stage the client sends a SYN-RST packet, releases the server's "stuck" connection, and is then able to reconnect. Section Summary Additional security checks were added to FireWall-1 for NG with Application Intelligence, which verify the flags of all TCP packets. These checks may affect connectivity in case of certain TCP stacks that send non-standard packets. A special work around exists for SYN-RST packets. It is possible to change the default behavior, by setting the kernel s global parameter fw_accept_syn_rst to one of the following values: -2 means that the feature is disabled. SYN-RST packets are dropped (default). -1 means that the feature is enabled for all services. Any other values are only enabled for the specific service that the port specifies by entering the value of fw_accept_syn_rst. Example: If fw_accept_syn_rst is set to X, then a SYN-RST packet is accepted when the destination port is X (assuming X is not equal to -1 or -2). 124

125 When the feature is enabled, a SYN-RST packet passes FireWall-1, and any existing relevant connection entries in FireWall-1's connections table are closed. Warning - Enabling the feature opens a security hole, since a malicious person can cut existing connections by sending spoofed SYN-RST that match these connections, with random sequence numbers. Therefore, enabling this feature is not recommended, and should only be done if it is required for relevant connectivity issues. The TCP stacks that are mentioned above are not compliant with RFC 793, since: According to the RFC, when the connection's state is established, the first field that should be checked upon an incoming segment is the sequence number. In this case, the SYN-RST packet contains a sequence number that does not necessarily match the connection, so the RST flag should be ignored. If the connection's state is closed (i.e. connection's first packet is SYN-RST), the server should first check the RST field, and ignore the packet if it has been set. Default session timeouts Each TCP connection is recorded with a certain start-session timeout. When a connection is established, the timeout increases to session timeout and the default value can be overridden per service. After RST packet or both FIN packets are encountered, the timeout decreases to end-session timeout. Section Summary The default TCP session timeouts were decreased since Version 4.1 SP5, to improve FireWall-1's ability to handle traffic loads. If this causes the un-desired behavior of FIN packets being dropped, it is advised to manually increase the TCP end-session timeout. The Timeout attributes can be configured via FireWall-1's SmartDashboard (Global Properties Dialog > Stateful Inspection). The default values have changed since Version 4.1 SP5, as follows: TCP start-session timeout has changed from 60 to 25 seconds. TCP end-session timeout has changed from 50 to 20 seconds. If the end session timeout is set for too short a time, FireWall-1 may remove the connection entry before the connection's tear down is complete. Here is an illustration of the problem: Client/Server 1 Client: FIN 2 Server: ACK 3 Server: FIN Appendix A 125

126 4 Client: ACK (lost on the way to server) 5 Server: FIN retransmission FireWall-1 decreases the connection's timeout after the second FIN packet is encountered (step 3 above). The following ACK packet (step 4 above) may be lost on the way to the server. When this occurs, the server retransmits the FIN packet. However, if that retransmission arrives after the connection entry has expired, FireWall-1 drops it, since it is a FIN packet that does not match an existing connection. Consequently, if FireWall-1 generates log messages indicating First packet isn't SYN, tcp_flags=fin-ack, it is recommended to increase the TCP end-session timeout to about seconds. Behavioral Changes in NAT In This Section Improvements in HIDE NAT Address page 126 IP Pools page 127 Transparent Server Connection (under NAT) page 127 Improvements in Static NAT page 128 New NAT properties in FireWall-1 NG page 128 Improvements in HIDE NAT Address The Hide NAT Address is the address behind which the network, address range or node is hidden. It is possible to either hide behind the interface of the Install on Gateway, or to hide behind a specified IP address. Version 4.1 SP5 Solution In Version 4.1 and earlier releases, you were limited to 50,000 connections per hiding IP used for HIDE NAT. NG with Application Intelligence Solution In NG, the limit for connections is now 50,000 connections per destination. This effectively means you can support any number of connections through HIDE NAT as long as no more than 50,000 of them do not go to the same destination at the same time. 126

127 IP Pools An IP Pool is a range of IP addresses (an Address Range, a network or a group of one of these objects) routable to the gateway. IP Pool NAT ensures proper routing for two connection scenarios: SecuRemote/SecureClient to MEP (Multiple Entry Point) Gateways Gateway to MEP Gateways In the IP Pools setup, this feature allows you to allocate a specific period of time that a user holds on to an IP address. There are behavioral changes in this feature that increases the scalability of the pool. Version 4.1 SP5 Solution If the pool gets exhausted, there are no IPs left even though a situation may well exist wherein no one is using these IPs, they are all taken. NG with Application Intelligence Solution If there are no available IP addresses, you can set your IP Pool to take a pending IP address. From Gateway > Return Unused Addresses to IP Pool After... you can indicate that your preference is to allow a user to hold on to an IP address for an hour but if the pool is exhausted, recycle this IP after 30 seconds (for example). Transparent Server Connection (under NAT) This is a Security Server feature that is implemented in NAT. Transparent means that the Security Server is invisible to the client that originates the connection, and to the server. This is achieved by applying NAT on the connection from the Security Server to the Server so that the Server sees the source address and source port that was used by the client in the original connection. This is used by default with all of the Security Servers, except the SMTP Security Server. The properties that control the activation of this feature are: ftp_transparent_server_connection http_transparent_server_connection smtp_transparent_server_connection rlogin_transparent_server_connection telnet_transparent_server_connection Change them via dbedit. Appendix A 127

128 Improvements in Static NAT Version 4.1 SP5 Solution In Version 4.1 SP5 and earlier releases, NAT occurs on the server side, meaning: 1 A packet enters the firewall, 2 passes the inbound anti-spoofing and rule checks, 3 gets routed, 4 passes the outbound anti-spoofing and rule checks, 5 and is then subjected to NAT. The result is that you must have a static route for each destination static NAT address. When upgrading from Version 4.1 the appropriate property is enabled for new installs. NG with Application Intelligence Solution In NG with Application Intelligence the server s address can be translated on the client-side (for manual rules this feature is supported from NG FP3 forward). This feature is activated from Global Properties > NAT. New NAT properties in FireWall-1 NG In versions NG forward FireWall-1 introduced several new properties that can be applied to automatically generated NAT rules. These are enabled by default in new installations, but disabled by default when upgrading from previous versions so that the behavior of the rulebase remains the same. After the upgrade, this can be enabled in the Network Address Translation page of the Global Properties window. Allow Bidirectional NAT Bidirectional NAT applies to automatic NAT rules in the Address Translation Rule Base, and allows two automatic NAT rules to match a connection. Without Bidirectional NAT, only the first automatic NAT rule matching the connection is applied. When NAT is defined for a network object, an automatic NAT rule is generated which performs the required translation. If there are two such objects and one applies to the client of a connection and the other applies to the server, then without Bidirectional NAT, only one of these objects is translated, because only one of the automatically generated NAT rules is applied. With Bidirectional NAT, both automatic NAT rules are applied so both ends are translated. 128

129 The operation of Bidirectional NAT can be tracked using the SmartView Tracker, using the fields NAT Rule Number and NAT Additional Rule Number. The "additional rule" is the rule that matches the automatic translation performed on the second object in Bidirectional NAT. Automatic ARP configuration In NAT configurations where the translated (NATed) addresses belong to the network of the external interface of the FireWall-1 gateway doing the translation, the FireWall-1 Gateway needs to operate as a Proxy ARP for the translated address. For example if the translated address is and the Gateway's external address is This is necessary because the Gateway needs to answer (on behalf of the client) to ARP requests sent on the external LAN by the router on behalf of the internal machine. In this version, FireWall-1 automatically configures its own Proxy ARP mechanism when automatic NAT rules are used, so there is no need for any additional configuration steps. This eliminates the need in Version 4.1 for a manual Proxy ARP configuration (using the OS native Proxy ARP functionality, like the arp command on Unix platforms or the local.arp configuration file in Windows platforms). The command fw ctl arp on a Gateway can be used to display the entries in the Proxy ARP table. Behavioral Changes for Services Features In This Section Match for Any Match for Any page 129 Time-out page 130 Protocol Type page 130 DNS Enforcement is Used by Default page 130 Dynamic Port Negotiation Inspection (Well Known Port) page 130 X11 Drop page 131 In NG many times there are more than one service that uses the same port. The difference between them is contained in the Action property and helps define: what protocol type they use, what their time-out is, if they can accept UDP or if it is one way, Appendix A 129

130 if they should be kept through policy reload. other properties... When you create a rule matching Any service, suppose you have more than one service with the same port, it is important to know which of these services to choose. The Match for Any check box is new- only one service for a specific port can be Match for Any. This feature is supported for: TCP, UDP and services of type other that do not have a match expression. Time-out The feature of time-outs per service existed in Version 4.1 but was difficult to use. In NG with Application Intelligence, the feature is now streamlined in the SmartCenter in each specific service. Protocol Type For each Service in NG with Application Intelligence you can specify a protocol type that guides FireWall-1 in how to relate to traffic matching to the Service. For example, if FTP is used on a high port such as port 5000, we can define a new service matching port 5000 and specify that the Protocol Type is FTP. The result is that FireWall-1 inspects traffic on port 5000 as FTP capable of opening data connections etc. DNS Enforcement is Used by Default In Version 4.1 DNS inspection was possible for UDP but was not used by default. In NG with Application Intelligence it is used by default for UDP DNS. The DNS inspection is applied for traffic matching services with the: DNS_UDP protocol type. To disable this feature for specific traffic, match the traffic to a service that does not have a protocol type. To disable this feature altogether: SmartDefense > Application Intelligence > DNS > deselect UDP Protocol Enforcement. Dynamic Port Negotiation Inspection (Well Known Port) In Version 4.1 FireWall-1 automatically enforced dynamically negotiated ports in control connections not belonging to an existing service. This caused undesired drops resulting from ports that were defined in the service database but were not actually being used. In NG with Application Intelligence, by default only low ports are checked and FireWall-1 allows full control over the ports that are forbidden from being dynamic ports. The choices are: check only low ports (NG with Application Intelligence default) 130

131 check all services (old Version 4.1 default) configure your own list of services to check X11 Drop From Version NG FP3 forward if the X11 port range is matched on a rule with Service Any the traffic is dropped and a log is issued. See Dropping X11 Traffic on page 132 for further information. New Service Features In This Section Keep Connections During Policy Reload You can specify that certain connections are exempt from the effects of policy reload. This is useful for data connections that get deleted when the policy is reloaded. The default is that all connections are affected. Exemption is available according to the following criteria: per service - specify that all traffic belonging to a service (including its data connections) are not affected by the policy reload all data connections all connections To find this feature in: TCP Service Properties > Select Keep Connections after Policy has been Installed or in Keep Connections During Policy Reload page 131 Dropping X11 Traffic page 132 SSHv2 and SSLv3 page 132 FTP Behavioral Changes page 132 Behavioral Changes in INSPECT page 133 NAT Rule-Match Performance page 133 SmartCenter Behind NAT page 133 Client-Side Translation page 133 NAT for Dynamic Objects page 134 Disable NAT Inside the VPN Community page 134 Appendix A 131

132 Check Point Gateways and Hosts > Advanced > Connection Persistence chose Keep All Connections, Keep Data Connections or Rematch Connections Dropping X11 Traffic Technically if an X11 connection is opened from A to B you would assume that the transaction is going from A to B. However, the reality is reversed, B actually goes to A. Because of this confusion, X11 must be explicitly enabled. From Version NG FP3 forward if the X11 port range is matched on a rule with Service Any the traffic is dropped and a log is issued. To enable X11 traffic, match to a rule with one of the FireWall-1 services (presumably X11). SSHv2 and SSLv3 These services protect your server by disallowing the use of unsafe versions of these protocols: SSLv3 - Protects the server against malicious clients. SSHv2 - In the SSHv2 protocol it is assumed that either the client or the server is malicious. This service protects one from the other. If unallowed versions (versions prior to V2 of SSH and V3 of SSL) of these protocols are used the connection is dropped. If you do not want to use SSLv3 or SSHv2, use the SSL or SSH service (respectively) instead. SSHV2 and SSLV3 services are not used by default. FTP Behavioral Changes Each of the items in this section change a specific aspect of FireWall-1 s FTP enforcement in order to enhance either security or connectivity for specific needs: FTPbidir This service allows FTP data connections to flow in both ways (server to client and vice versa) thus allowing SSL data connections. FTPbasic This is a new protocol type provides FTP inspection without some security checks (such as the new line check that appears in the standard FTP inspection) that may not be necessary for you if you trust your connection (such as dedicated lines with a partner) or for troubleshooting FTP connectivity problems. To use FTPbasic define a new TCP Service > Advanced > FTP_BASIC Protocol Type, deselect Match for Any and use it in your rulebase for the relevant traffic. 132

133 FTPnew Enforcement This is a new experimental enforcement algorithm for NG with Application Intelligence. FTPnew Enforcement achieves all the security that standard FTP does without the known connectivity issues of the standard FTP enforcement. To activate this feature edit the base.def file on the following line: #define FTP_CHECK_PACKET and remove the comment symbol (//), install the security policy. FTP Passive and FTP Port The FTP Passive (ftp-pasv) new services allow only connections that result from Passive commands. The FTP Port (ftp-port) new services allow only connections that result from Port commands. The advantage to adding this service is that you can limit the way FTP data connections are opened. For example, you can avoid FTP connections from the outside from opening into your organization. Behavioral Changes in INSPECT Changes that people do in Version 4.1 INSPECT files that they did due to Support or SecureKnowledge articles and how they should apply the same changes in NG with Application Intelligence. There will be between items. NAT Rule-Match Performance In NG FP3 the back-end of NAT Rule-Match was revised resulting in greatly increased performance. The new rule match uses a new matching algorithm and caches previous rule-match results. You can now use large NAT rule bases with reduced performance penalties. SmartCenter Behind NAT This feature is new in NG with Application Intelligence. SmartCenter can be in a network with hide NAT or static NAT. Even if SmartCenter is in a hidden network it still allows Enforcement Modules to connect to it. To use the feature, edit your SmartCenter Object via the NAT tab define the desired NAT then Apply for VPN-1 & FireWall-1 Control Connections. For further information see the FireWall-1 and SmartDefense Guide. Client-Side Translation In FireWall-1 NG it is possible to translate server addresses on the Client-side. This is supported for manual rules since NG FP3 and for automatic rules on all NG versions enabling easier integration of Server-NAT with FireWall-1 Enforcement Module routing. Appendix A 133

134 NAT for Dynamic Objects From NG FP3 forward you can do NAT on dynamic objects. This can save you rulebase logic by using your dynamic object rule as a template. For example you can define, for each Enforcement Module, the address of the local network. Then define one rule hiding your local network behind the address of the Enforcement Module. Recycling the same rule for similar tasks on many Enforcement Modules saves you rulebase logic. Disable NAT Inside the VPN Community There is a common VPN deployment where you want to apply NAT the internal networks when communicating with the outside world but you do not want to apply NAT within the VPN community. Beginning in NG FP3 it is possible to disable NAT for all community traffic. To enable this feature from your Community Object select Advanced Properties and select Disable NAT within the VPN Community. Behavioral Changes in INSPECT This section describes common support solutions and workarounds that can be used in FireWall-1 Version 4.1 that involve changes in INSPECT (.def) files and their equivalent solutions in NG with Application Intelligence. Due to the fact that such changes are relevant for a specific release they are not upgraded, between different versions. As a result, you should manually change the INSPECT files. During the process of Next Generation with Application Intelligence installation, the installation wrapper will notify you if a change was made to one of the INSPECT files. In this case, examine the files that changed in order to perform a manual change. In some instances the change are relevant only for Version 4.1 and there is no need to change anything in NG with Application Intelligence. Changes to INSPECT files are always performed on the management server and require a policy installation in order to be effective. Changes to INSPECT files on Enforcement Modules have no effect. Backward compatibility note When managing Version 4.1 Enforcement Modules from an NG with Application Intelligence SmartCenter Server, the Backward Compatibility package (BC package) is used. The Backward Compatibility package includes a fresh copy of all Version 4.1 INSPECT files and these files are used when installing a policy on the Version 4.1 modules. Usually the same changes that were performed on the Version 4.1 INSPECT files need to be applied on the INSPECT files installed by the Backward Compatibility package. The location of these files is: 134

135 On the Unix platform: $FWDIR/FW1_4.1_BC/lib On the Windows platform: %fwdir%\fw1_4.1_bc\lib More details are available in SecureKnowledge solution ski3660. Some of the solutions below also have equivalent solution for NG with Application Intelligence modules, this solution is normally relevant only for NG modules (some may require a minimal NG feature pack level). When managing Version 4.1 and NG modules from the same management, you will need to apply both the NG and the Version 4.1 solution to the management. In some rare cases, an additional procedure may be required to the solution used in Version 4.1, if such procedure is required; it is stated in the specific solution details below. Unknown established TCP packet Description By default, FireWall-1 allows new TCP connections to be established only with SYN packets that indicate a new connection attempt. When processing a non-syn packet, FireWall-1 tries to find out if there is an already established connection that matches this packet, the packet is dropped and the above log message is generated. In NG the log text is out of state TCP packet. In some situations this default setting was changed in order to allow also non-syn packets to be matched against FireWall-1 rule base and establish new connections. For example, when the state of a previously established connection is lost (because of a timeout, or the FireWall-1 module was rebooted and etc ). It is not recommended to change this setting due to potential security implications. Solution in Version 4.1 To disable this security enhancement and allow Non SYN packets to be matched against the rule base follow these steps: 1 On the Management station, open the file $FWDIR/lib/fwui_head.def 2 Find the line: /*#define ALLOW_NON_SYN_RULEBASE_MATCH*/ 3 Uncomment the line. Change it to: #define ALLOW_NON_SYN_RULEBASE_MATCH 4 Install the Policy. Appendix A 135

136 A similar solution exist for just disabling the Logging of these packets, this solution includes the following steps: 1 Find this line: #define NON_SYN_RULEBASE_MATCH_LOG 2 Add a comment. Change the line to: /*#define NON_SYN_RULEBASE_MATCH_LOG*/ Solution in NG with Application Intelligence NG with Application Intelligence contains new connectivity features. For up-to-date information see the What's New documentation: The new connectivity features allow recovery of established connections, even if FireWall-1 lost their state. These improvements do not require that rule matching of non-syn packets be allowed like in Version 4.1 and therefore it is not recommended to make the same changes in NG with Application Intelligence. There are possible scenarios where disabling this restriction is required. Typically, the problem in these scenarios is that packets belonging to the same connection do not all go through the FireWall-1 module, for example: Consider an asymmetric routing scenario where incoming packets are received from a satellite down link, outgoing packets are sent via a ground link and the FireWall module is located only on one of these links. The FireWall-1 module may not see the first SYN packet of a connection, but it will see its SYN-ACK response, this response will be treated as an out-of-state packet. Disabling this check is possible from SmartDashboard, Global Properties > Stateful Inspection > in the Out of state packets section. FTP Related INSPECT Solutions FTP control NewLine enforcement Description By default, FireWall-1 FTP services enforce that each packet on an FTP control connection (port 21) is terminated by a new line sequence ("\r\n") and that each PORT command is followed by a new line sequence. This enforcement is done for security reasons, but sometimes it creates connectivity problems for legitimate connections. Examples: Server that send a big welcome message that spans more than one packet or 136

137 Keep alive packets Version 4.1 solution When using the following procedure note that FireWall-1 does not prevent malicious port commands sent in specially crafted packets. In FireWall-1 Version 4.1, the following procedure was performed on the management server: From SecureKnowledge solution no Solutions are available for both Active and Passive FTP connections: For Active FTP Connections Edit the $FWDIR/lib/base.def file to allow FTP headers without "\r\n". 1 Stop FireWall-1 management by running fwstop 2 Edit the $FWDIR/lib/base.def (found on the management module in a distributed environment) 3 Comment out the following line by adding //: #define FTP_ENFORCE_NL to: //#define FTP_ENFORCE_NL 4 Start FireWall-1 management by running fwstart 5 Re-install the policy For Passive FTP connection 1 Stop the FireWall-1 management by running fwstop 2 Edit the $FWDIR/lib/base.def (found on the management module in a distributed environment) Change it by commenting the first line, and uncommenting the last one: From: #define FTPPORT(match) (call KFUNC_FTPPORT <0x1 (match)>) // // Use this if you do not want the FireWall module to insist on a newline at the // end of the PORT command: // #define FTPPORT(match) (call KFUNC_FTPPORT <(match)>) Appendix A 137

138 To: //#define FTPPORT(match) (call KFUNC_FTPPORT <0x1 (match)>) // // Use this if you do not want the FireWall module to insist on a newline at the // end of the PORT command: #define FTPPORT(match) (call KFUNC_FTPPORT <(match)>) 3 Start the FireWall-1 management by running fwstart 4 Re-install the policy Solution with NG with Application Intelligence In NG with Application Intelligence, a new FTP protocol enforcement option was added. This protocol enforcement option protects against malicious port commands without requiring each packet to be terminated by a new line sequence. In order to enable this protocol enforcement the following procedure is needed on SmartCenter: 1 Change the following line in base.def From: // #define FTP_CHECK_PACKET To: #define FTP_CHECK_PACKET 2 Reinstall the Security on all FireWall-1 Enforcement Modules. Note - The Version 4.1 solution (by changing the #define FTP_ENFORCE_NL line) is still possible in NG, but it is not recommended. Changes to FTP control connection timeout Description In FireWall-1 Version 4.1 and earlier versions it is sometimes needed to extend the default TCP timeout for FTP control connection, because when transferring very big files the control connection times out and expires, this causes the entire data transfer to fail. Solution in Version 4.1 This section relates to SecureKnowledge solution : This solution is applicable for all Operating Systems. To increase the FTP control connection timeout, complete the following steps on SmartCenter: 1 Edit the file $FWDIR/lib/init.def on the management. 138

139 2 Find the line: #define FTP_CONTROL_TIMEOUT TCP_TIMEOUT. 3 Replace TCP_TIMEOUT with a numerical value representing the desired timeout in seconds for FTP control connections. 4 Save the init.def file. 5 Re-install the policy. Example Original Line: #define FTP_CONTROL_TIMEOUT TCP_TIMEOUT Changed to: #define FTP_CONTROL_TIMEOUT 7200 This changes the FTP control connection timeout to 7200 seconds (2 hours). Note - In some builds of VPN-1 Pro, the line "#define FTP_CONTROL_TIMEOUT TCP_TIMEOUT" may not exist by default in the init.def file. In this case, simply add the line to the init.def file Solution in NG with Application Intelligence In NG with Application Intelligence this solution is usually not needed because the control connection is kept alive as long as its associated data connections are active. If changes for the default TCP timeout are needed (for any service), they are possible using SmartDashboard: 1 Open the Service Properties dialog. 2 Click on Advanced > in the Timeout section select other and define the desirable value in seconds. Preventing FTP data connection failures on server port check Description By default FireWall-1 drops block an FTP PORT command issued if it tries to open a TCP port that is listed as a Service inside the Firewall-1 services. This is a security implementation to keep anyone from injecting false PORT commands and opening up high ports through an FTP session. For example Malicious JAVA applets can take advantage of this situation, causing the FTP client to send a PORT command with ports like TELNET, X, REXEC, etc. This leads FireWall-1 to open this port, and a certain server on the machine could become vulnerable to hacking. By default FireWall-1 also blocks access to any port below 1024 (these ports are allocated for well-known services, and should not be used for data Appendix A 139

140 connections). The problem is that sometimes this check is too restrictive because the services database may contain high ports that can be used for legitimate data connections. Note - This check is performed also for other protocols' data connections. Solution in Version 4.1 This solution is taken from SecureKnowledge solution Change: to: <base.def> original : // ports which are dangerous to connect to define NOTSERVER_TCP_PORT(p) { (not ( ( p in tcp_services, set sr10 RCODE_TCP_SERV, set sr11 0, set sr12 p, set sr1 0, log bad_conn) or ( p < 1024, set sr10 RCODE_SMALL_PORT, set sr11 0, set sr12 p, set sr1 0, log bad_conn) ) ) }; // ports which are dangerous to connect to define NOTSERVER_TCP_PORT(p) { (not ( ( p < 1024, set sr10 RCODE_SMALL_PORT, set sr11 0, set sr12 p, set sr1 0, log bad_conn) ) ) }; 2 Reinstall the policy for the changes to take effect. Solution in NG with Application Intelligence In NG with Application Intelligence a new option is introduced in SmartDashboard to define a list of services that are checked when a new data connection is initiated. The configuration for the dynamic server ports checks is done in SmartDefense under Network Security > Dynamic ports. 140

141 Using FTP on non-standard ports Description The standard ports used in FTP are: 21 for the control connections and 20 for the data connections. FireWall-1 Version 4.1 installs with pre-configured FTP service that uses these ports. Sometimes an administrator needs to run (for either the control connection and/or the data connections) an FTP server on non-standard ports. Securing servers that run on non-standard ports using FireWall-1 Version 4.1 requires special configuration involving INSPECT files manipulations. Solution in Version 4.1 There are a number of different variations of this solution (depending on the exact scenario), the generic solution is described in SecureKnowledge solution ski1908 as follows: Under $FWDIR\lib, in the file called base.def perform the following changes: 1 Remove the remark sign (//) located before the line "// #define FTP_NON_STANDARD" 2 Define a new service of type Other. (Manage > Services > New > Other) 3 Fill in the fields as follows: Match: tcp,dport=<new ftp_control_port> Prologue: ftp_accept_serv 4 If the FTP control port is not the standard one (21), then: In the second occurrence of the macro ftp_accept_port (between the "#else" and the "#endif"), replace the line: dport = SERV_ftp or origdport = SERV_ftp with dport = SERV_ftp or origdport = SERV_ftp or dport = <required ftp_control_port> or origdport = <required ftp_control_port> 5 In the second occurrence of the ftp_accept_port macro, change the two occurrences of FTPPASV_ANTICIPATE to FTPPORT_ANTICIPATE. 6 Install the Security Policy. Appendix A 141

142 For Example If port 5001 is my ftp-control port and port 5000 is the ftp-data port 1. The new service will be defined like this: Name: ftp_5001 Match: tcp,dport=5001 Prologue: ftp_accept_serv; Note: Do not forget the semicolon (;) at the end of the prolog. 2. In $FWDIR/lib/base.def file perform the following changes: 2.1. Remove the remark sign (//) located before the line "// #define FTP_NON_STANDARD" 2.2. Replace the line "dport = SERV_ftp or origdport = SERV_ftp," with the line: "dport = SERV_ftp or origdport = SERV_ftp or dport = 5001 or origdport = 5001," 2.3 Replace the FTPPASV_ANTICIPATE with FTPPORT_ANTICIPATE in the two places where it appears within ftp_accept_port. 3. Install the Security Policy. Solution in NG with Application Intelligence When managing NG modules, INSPECT changes are not required. By default, NG with Application Intelligence supports FTP data connections coming from any port and there is no need for additional configuration. NG with Application Intelligence comes with a default FTP service that support FTP control connection on the default 21 port. New FTP services supporting other ports can be easily defined in SmartDashboard by adding a new TCP service for the requested port and then specifying the FTP Protocol Type in its Advanced TCP Service Properties window. Backward Compatibility When managing Version 4.1 modules from an NG with Application Intelligence management, an INSPECT change is still needed in the Backward Compatibility installed files, this procedure is detailed in SecureKnowledge solution sk9642 as follows: On the SmartCenter Server, proceed as follows: 1 Backup the classes.c file in the $FWDIR/conf directory. 2 Backup the base.def file in the $FWDIR/FW1_4.1_BC/lib directory. 3 Run the command cpstop. 4 Open classes.c in a text editor (not Microsoft Word), and under other_service, find fields. Under fields add the line: : (prolog :type (string) :defvalue ()) 5 Save the file and exit the editor. 142

143 6 Run the command cpstart. 7 Open base.def (in the $FWDIR/FW1_4.1_BC/lib directory) in a text editor (not Microsoft Word), and change the line //#define FTP_NON_STANDARD to: 8 Open SmartDashboard and define a new Service type of Other with these settings: Name: control_21 IP Protocol: 6 Match: tcp,dport=21 9 Run dbedit and run the following commands: 10 Quit. /* INSPECT modification - sk9642 */ #define FTP_NON_STANDARD /* End of INSPECT modification */ modify services control_21 prolog "ftp_accept_serv;" update services control_21 Note - The above procedure updates the objects_5_0.c file on the SmartCenter Server. 11 Add this new service to your Rule Base to be installed on the VPN-1 Pro Enforcement Module. 12 Install the Policy. Bi-direction FTP data connection Normally FTP data connection are unidirectional, i.e. data is sent only in one way (for example: from server to client when getting a file), by default FireWall-1 enforces that there is no data flowing the other way for security reasons. In some configurations (when using SSL for example) bi-directional data connections are needed. Solution in Version 4.1 This solution relates to SecureKnowledge solution Upgrade to FireWall SP8 or VPN-1/FireWall-1 Version 4.1 SP2 2 After the installation is complete in order to allow FTP connection to be bidirectional, define a new service of type Other (possible name bi_ftp) with the following fields: prologue: #define FTP_PORT_RESTR Appendix A 143

144 match: tcp, dport=21, record <conn;x> in ftp_restrictions where x should be: i 5 in the case of command line FTP, ii 6 in the case of passive FTP, or iii 7 for both. 3 Place the new service in the relevant FTP rules and install the policy. Note - To view the comparable solution for Firewall-1 NG, refer to the SecureKnowledge solution. Solution in NG with Application Intelligence NG with Application Intelligence come with a default ftp-bidir service that supports this functionality. Authentication related INSPECT solutions Preventing re-authentication when a policy is installed. Description FireWall-1 maintains certain attributes in its state tables for all connections. During policy install, any tables with the keep attribute remain loaded. Tables without the keep attribute are deleted. The client_auth table, where client authentication information is stored, does not have the keep attribute. Version 4.1 Solution This solution is taken from SecureKnowledge solution: Under $FWDIR/lib/table.def file, modify the following line: to: client_auth = dynamic sync expires AUTH_TIMEOUT 3; client_auth = dynamic sync expires AUTH_TIMEOUT 3 keep; 2 Install the Security Policy. Solution in NG with Application Intelligence The same solution is required in NG with Application Intelligence, the line to change looks slightly different: 144

145 1 Under: $FWDIR/lib/table.def file, modify the following line: client_auth = dynamic sync expires AUTH_TIMEOUT kbuf 3 \ expcall KFUNC_CLIENT_AUTH_EXPIRE; To: client_auth = dynamic sync expires AUTH_TIMEOUT kbuf 3 \ expcall KFUNC_CLIENT_AUTH_EXPIRE keep; 2 Install the Security Policy Removing RADIUS/LDAP/TACACS from Control Connections Description RADIUS queries are defined as connections originating from VPN-1 Pro and destined to the Radius Server. These queries are part of the VPN-1 Pro Control Connections and are therefore performed before any of the rules defined in the Rule Base. This means that these connections are not encrypted. When a user attempts to authenticate, these Radius queries are performed between the remote VPN-1 Pro and the Radius server. Because the Radius server has a non-routable address, the remote VPN-1 Pro is not able to reach it if the connections are unencrypted. VPN-1 Pro will only be able to reach the RADIUS server if the connection is encrypted. A similar issue exists with LDAP connections. Solution in Version 4.1 This solution is taken from SecureKnowledge solution : Radius Queries Remove the Radius queries from the Control Connections and manually define these connections in your Rule Base as encrypted, as follows: 1 Stop the VPN-1 Pro SmartCenter Server (fwstop) 2 Create a backup copy of the $FWDIR/lib/base.def file 3 Edit the base.def file as follows: search for the word radius and replace the lines: #define enable_radius_queries { eitherbound all@all accept src in firewalled_list, <dst,dport> in radius_servers_list, set sr3 0, RECORD_CONN(0xffffff09); } Appendix A 145

146 with: 4 Start the FireWall-1 SmartCenter Server (fwstart) 5 Install the Security Policy. LDAP Queries LDAP connections require the following solution (from SecureKnowledge solution : Remove the LDAP queries from the control connections and manually define these connections in your rulebase as encrypted. This is done as follows: 1 fwstop the FireWall SmartCenter Server 2 Make a backup of the $FWDIR/lib/base.def file 3 Edit the base.def file: search for the word LDAP and replace the lines: with: #define enable_radius_queries 0 #define enable_ldap_queries { \ eitherbound all@all accept \ src in firewalled_list, \ <dst,dport> in ldap_servers_list, \ set sr3 0, RECORD_CONN(0xffffff0b); \ } #define enable_ldap_queries 0 4 fwstart the FireWall SmartCenter Server 5 Install the Security Policy. TACACS Queries The TACACS solution is similar (SecureKnowledge solution ): 1 Stop the FireWall SmartCenter Enforcement Module (fwstop). 2 Make a backup of the $FWDIR/lib/base.def file. 3 Edit the base.def file as follows: 146

147 search for the word TACACS and replace the lines: with: #define enable_tacacs_queries { \ eitherbound all@all accept \ src in firewalled_list, \ <dst,dport, ip_p> in tacacs_servers_list, \ set sr3 0, RECORD_CONN(0xffffff0c); IMPLIED_LOG \ } #define enable_tacacs_queries 0 4 Start the FireWall SmartCenter Enforcement Module (fwstart). 5 Install the Security Policy. Solution in NG with Application Intelligence In NG with Application Intelligence the following changes is required in $FWDIR/lib/implied_rules.def RADIUS Change the following line: #define ENABLE_RADIUS_SERVER to: // #define ENABLE_RADIUS_SERVER LDAP Change the following line: #define ENABLE_LDAP_SERVER to: // #define ENABLE_LDAP_SERVER TACACS Change the following line: #define ENABLE_TACACS_SERVER to: // #define ENABLE_TACACS_SERVER Services Related INSPECT Solutions Increasing services session timeout Description FireWall-1 uses a default session timeout for established connection (e.g. the default for TCP connections is 1 hour) in certain scenario the default timeout is not enough for specific services and it has to be increased. Appendix A 147

148 Version 4.1 Solution In FireWall-1 Version 4.1 changing the default timeout requires a manual change in the init.def file located in $FWDIR/lib. The solution in this section is also described in SecureKnowledge solution number To increase the session timeout for specific services other than FTP control connections, proceed as follows: 1 From the Management Module issue the fwstop command. 2 Edit the $FWDIR/lib/init.def file on the management module, adding the following statement (including the comma): ADD_TCP_TIMEOUT (port,timeout), directly before the line: ADD_TCP_TIMEOUT (0,0) where port specifies the service TCP port and timeout specifies the desired timeout in seconds. Example The following line would be added in order to specify a session timeout of 7200 for port 80: ADD_TCP_TIMEOUT (80,7200), 3 Save the edited file. 4 Issue the fwstart command. 5 Install the security policy from the Policy Editor to enable the new session timeout. Solution in NG with Application Intelligence In NG with Application Intelligence the timeout for a specific services can defined in SmartDashboard. From the Services Object Other > in the Session Timeout section select Advanced Other Service Properties select Virtual Session Timeout radio button and specify the new timeout in seconds. Install the policy for the new settings to take effect. Backward Compatibility Issues for Services When managing Version 4.1 modules from an NG with Application Intelligence SmartCenter the Version 4.1 solution is still needed, only the file init.def has a different location: On Unix platforms: /opt/cpfwbc-41/lib/init.def On Windows platforms: C:\WINNT\FW1\NG\FW1_4.1_BC\lib\init.def 148

149 Custom INSPECT Services Overview FireWall-1 allows users to write their own INSPECT services, these services often require INSPECT code to be run on each packet that uses these services. In NG some changes were introduced to FireWall-1 architecture and the INSPECT Virtual Machine is no longer run on each packet, the INSPECT Virtual Machine is run only on the first packet of a connection in order to match it against the rule base. Once there is a rule base resolution and the connection is matched, the following packets are handled by lower level FireWall-1 routines or they are offloaded by SecureXL. This is done for efficiency reasons and greater performance is achieved than in Version 4.1. These changes require user defined services that run INSPECT code on each packet to be defined differently in NG, these must performed manually after the upgrade for the services to function properly. What to change prologue In NG services no longer have the prologue field that defines the INSPECT code to run. In NG the relevant code should be included in an INSPECT handler function. This function should not accept any parameters. For example: deffunc my_prologue_code () { ([TCPDATA,b]=0x44524f50,drop) or LOG<long, LOG_NOALERT, 0> }; About these handler functions: When you want packet to be dropped or rejected, drop or reject must be used explicitly. Otherwise the packet is accepted. accept/drop/reject cause the function to immediately exit. match The match field should be the same as in was Version 4.1 with the addition of the assignment of the INSPECT handler defined in prologue on page 149 to the r_mhandler register. This assignment tells FireWall-1 that you wish to run this INSPECT handler on every packet belonging to connections that were matched for this service. By default FireWall-1 does not run the INSPECT Virtual Machine on each packet like in Version 4.1. Appendix A 149

150 Example If the match field in Version 4.1 is: dport = In NG it should be: dport = 31337, set r_mhandler &my_prologue_code H.323 New service In Version 4.1 in some H.323 configurations, a new" H.323 service was required. Version 4.1 Solution The content of this section was taken from SecureKnowledge solution : 1 Create a new user defined service called H323_new and define it as follows: Match: tcp,dport=1720 Pre-Match: h323_prematch_new Prolog: h323_prolog_new 2 Remove the service T.120 from the database. 3 Download SAVE_H245_PORT_NEW and edit $FWDIR/lib/h323.def as described in the downloaded file. 4 Restart VPN-1/ FireWall-1. Note - Do not use both previous and new version of H323 in the same Security Policy. Solution in NG with Application Intelligence In NG with Application Intelligence this solution is not needed. GRE inspection In FireWall-1 Version 4.1 GRE connections (IP protocol 47) are not entered into the connection table, this causes each GRE packet to be matched against the rule base, this may have a performance impact. Version 4.1 Solution The following solution is taken from SecureKnowledge solution ski

151 1 On the FireWall-1 management edit the $FWDIR/lib/base.def file: Browse to the end of the file. The last line looks like: #endif /* base_def */ Add the following text before the last line: // ***************************************** // * GRE code * // ***************************************** #define IP_TIMEOUT 40 /* timeout for the ip_conns table */ ip_conns = dynamic sync expires IP_TIMEOUT; #define ip_match_gre(proto) (ip_p=proto, record <src,dst,ip_p> in ip_conns, record\ <dst,src,ip_p> in ip_conns) #define ip_prologue accept <src,dst,ip_p> in ip_conns 2 Save the file. 3 In the Policy Editor, define a new service of type other. Name the service gre_inspect. 4 Add the following to the relevant fields: match: ip_code(47) prologue: ip_prologue; 5 Add the service you created to the Rule Base for the GRE rules. Save the rulebase. 6 Close SmartDashboard and only then edit the $FWDIR/conf/objects.C file. Search for the service name you defined (gre_inspect), and add in the line below the service name the following line: :weight (100) 7 Save the file. 8 Open the Policy Editor and install the Policy. Solution in NG with Application Intelligence In NG with Application Intelligence, this solution is not needed. GRE connections are entered into the connection table just like any other service, there is no need for any additional configuration steps. RSH STDERR back connections with ports lower than 601 Description By default FireWall-1 allows RSH back connection between ports 600 and Appendix A 151

152 Sometime different ports are needed. Version 4.1 Solution This solution is taken from SecureKnowledge solution ski Backup the $FWDIR\lib\base.def file on the management station. 2 Find the line (sr2 = RSH_MAGIC, sr1 > 600, sr1 < 1024) 3 Change the value under sr1 > 600 to 300 or to another number (it is not recommended to use a number less than 400). 4 Save the file. 5 Reinstall the Security Policy. Solution in NG with Application Intelligence 1 Similar to the Version 4.1 solution, backup the $FWDIR/lib/base.def file on SmartCenter. Find the line (dport = SERV_shell, sr1 > 600, sr1 < 1024, 2 Change the value under sr1 > 600 to 300 or to another number (it is not recommended to use a number less than 400). 3 Save the file. 4 Reinstall the Security Policy. DNS Verification Description FireWall-1 is can perform deep application layer inspection of DNS packets. In FireWall-1 Version 4.1 this inspection is disabled by default. Version 4.1 Solution This solution is taken from SecureKnowledge solution sk1024: 152

153 1 Add the property :dns_verification (true) to the :props section in the FWDIR/conf/objects.C file. Once this property has been added, each DNS query will be written in the FireWall-1 tables and will be removed after the query's reply is sent. Note - Please follow the instructions in how to manually edit the objects.c file in SecureKnowledge solution sk294. The entry in the table has a timeout which is set in the $FWDIR/lib/table.def file at the bottom of the file under stateful DNS. (dns_requests = dynamic refresh expires 30). The value of the timeout can be set from 1 second to 52 days (in seconds). Solution in NG with Application Intelligence In NG with Application Intelligence, DNS verification is enabled by default and there is no need for any additional configuration steps. DNS verification is now controlled in SmartDefense. INSPECT Accounting solutions Description These solution are performed to address issues related to the: failed to add connection to accounting tables error message. Version 4.1 Solution no. 1 This solution involves changes in the base.def INSPECT files to the timeout of entries added to the "tracked" table as detailed in SecureKnowledge solution no. sk9384. By default, a log entry timeout of a Security Server used in a Resource is 3600 seconds (hard coded) in the tracked table. 1 Back up the file $FWDIR/lib/base.def 2 Edit the existing $FWDIR/lib/base.def file using a simple text editor. Do not use Microsoft Word. Appendix A 153

154 3 Search for the word PROXY and then for the * PROXY CONNECTIONS MECHANISM * * * ********************************************************************** ***/ deffunc PROXY_DO(act) { set sr3 0, ( ( act & 2, /* ACCOUNT */ set sr3 IS_TRACKED_UNK, ( ( /* ACCOUNT + INSIDE */ act & 4, direction = 0, <conn> not in tracked, record <conn;date+tod,1,packetlen,-(direction+1),0,-1, in tracked ) or ( direction = 1, <conn> not in tracked, record <conn;date+tod,1,packetlen,-(direction+1),0,-1, in tracked 4 Modify the date+tod line Example 154

155 To modify the date+tod line to 900 seconds: PROXY CONNECTIONS MECHANISM * * * **************************************************************** ***/ deffunc PROXY_DO(act) { set sr3 0, ( ( act & 2, /* ACCOUNT */ set sr3 IS_TRACKED_UNK, ( ( /* ACCOUNT + INSIDE */ act & 4, direction = 0, <conn> not in tracked, record <conn;date+tod,1,packetlen,-(direction+1),0,-1, in tracked ) or ( direction = 1, <conn> not in tracked, record <conn;date+tod,1,packetlen,-(direction+1),0,-1, in tracked 5 Save the file. 6 Reinstall the policy. 7 To verify, run the following command on the Module: fw tab -t tracked -u Version 4.1 Solution no 2 This solution changes the size of the tracked table in table.def, according to SecureKnowledge solution sk8657. The Tracked table in the table.def file is responsible for holding the Account logs. By default this table is limited to entries. In order to change it (for example to entries) proceed as follows on the Management Server: 1 Back up the table.def file under: $FWDIR/lib directory on both the Management Server and the Module. Appendix A 155

156 2 Search for the following line under: $FWDIR/lib directory on both the Management Server and the Module: tracked = dynamic refresh expires expcall KFUNC_END_ACCT_CONN; Change it to the following: tracked = dynamic refresh expires expcall KFUNC_END_ACCT_CONN limit 75000; 3 Install the Policy. 4 To verify the changes, run the following command on both the Management Server and the Module: C:\>fw tab -t tracked -u more Solution in NG with Application Intelligence These solution are not needed in NG with Application Intelligence. Restricting Account Logging to the Account Log Viewer only Description A request for Accounting via the FireWall-1 security policy gets two kinds of log tracking for the same connection by default; a normal Log entry and an Accounting Log entry. It is possible to restrict the account logging to generate only Account logs and not the regular Logs. Version 4.1 Solution This section is taken from SecureKnowledge solution In order to restrict the account logs you should edit the $FWDIR/lib/fwui_head.def file as follows: 1 Go to the ACCOUNT macro and add "/*" at the beginning of the line: LOG(name,alert,rule) and "*/" at its end (i.e., comment the line out). 2 run the fwstop and fwstart commands. 3 Re-install the policy. NG with Application Intelligence Solution The same solution is required in NG with Application Intelligence that was documented in the Version 4.1 Solution. 156

157 INSPECT and Load Balancing Changes to persistency timeouts Description When using the persistent server mode for a logical server, a default of 30 minutes persistency timeout is used. This timeout can be changed in the table.def INSPECT file. Version 4.1 Solution This solution is taken from SecureKnowledge solution : The default persistency timeout is 30 minutes and can be refreshed (every new connection to the persistent server will reset the timer). It is defined in the $FWDIR/lib/table.def file on the management module machine as follows: #define LOGICAL_CACHE_TIMEOUT 1800 To change the default timeout, change the value 1800 (seconds) to the desired value in seconds and reinstall the policy. NG with Application Intelligence Solution The same change is required in NG with Application Intelligence. INSPECT Tuning solutions Changes to the connections table size Description By default FireWall-1 installs with connections table size of 25,000 connections. In some situations this limit need to be increased. Changing this limit often requires changing the hash size of the connections table for performance reasons. Version 4.1 solution This solution refers to the SecureKnowledge solution In the connection table size is set in the table.def INSPECT file. Edit the $FWDIR/lib/table.def file on the FireWall-1 management module. Insert the attribute limit followed by the limit value (for instance, limit for connections) after the hash size 8192 attribute of the Connection Table. In 4.0, insert it at the two locations within the $FWDIR/lib/table.def file: the two lines which begin with connections =, in Version 4.1 there is only one location. Appendix A 157

158 Version 4.0 Example connections = dynamic refresh expires TCP_START_TIMEOUT expcall KFUNC_EXPIRE implies tracked kbuf 1 hashsize 8192 limit 50000; Version 4.1 Example connections = dynamic refresh sync expires TCP_START_TIMEOUT expcall KFUNC_CONN_EXPIRE kbuf 1 #ifdef SECUREMOTE #else #endif implies userc_verified_connections implies ftp_restrictions hashsize limit 50000; NG with Application Intelligence solution In NG with Application Intelligence the connection table size is set in SmartDashboard in Check Point Gateway Object > Capacity Optimization > and change the value of Maximum concurrent connections. The hash size of the connections table is calculated automatically and there is no need to set it manually like in there was in Version 4.1. Changes to Kernel memory settings Description Changes to the connections table size usually also require changes to the memory FireWall-1 kernel allocates for tables and other dynamic storage, because the amount of memory needed is affected by the number of concurrent connections. Solution in Version 4.1 The amount of memory to be allocated has to be calculated manually. This section refers to SecureKnowledge solution These are the guidelines for calculating this value: 1 Validate that enough memory has been allocated to the Check Point kernel to handle the increased connections table. 2 Using a general rule of: connection table size = ([memory] - X)/60, where: X should be a value between Mbytes (depending on the amount of logging and accounting done by FireWall-1), [memory] is the internal memory allocated for the FireWall-1 (use $FWDIR/bin/fw ctl pstat to get this number). 158

159 If the connection table size is less then your desired limit, you may need to increase kernel memory. 3 The configuration of this value is done differently on each platform as detailed in SecureKnowledge solution : The UNIX Platforms 1 Stop the FireWall using the fwstop command 2 Perform the following commands, depending on the platform flavor: IPSO - Refer to SecureKnowledge Solution : How to modify values in the FireWall-1 kernel module on the Nokia IP Series Appliance Solaris - Add to /etc/system "set fw:fwhmem = 0x500000" and reboot SunOS - echo "fwhmem?w500000" adb -w $FWDIR/modules/fwmod.4.1.x.o HPUX 9.x - echo "fwhmem?w500000" adb -w /hp-ux and reboot HP-UX 10.x - echo "fwhmem?w500000" adb -w /stand/vmunix and reboot HP-UX 11.x - echo "fwhmem?w500000" adb -w /stand/vmunix and reboot Linux - Refer to SecureKnowledge Solution sk1077 How to modify values in the FireWall-1 kernel module on the Linux platform AIX - echo "fw_heap_size?w " adb -w $FWDIR/modules/fwmod.4.x.o echo "fwhmem?w " adb -w $FWDIR/modules/fwmod.4.x.o The Windows Platform (NT) 1 Run regedt32 (the registry editor). 2 Go to HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\FW1\Parameters 3 Select from the main menu Edit > Add Value 4 The value's name is Memory, and the data type is REG_DWORD 5 Enter the new amount of kernel memory (in bytes) Note - The value should be in Hex. For example equals 6 MB. 6 Reboot 7 Start FireWall-1 by running the fwstart command. Appendix A 159