SECURESPHERE®
Migration Guide Version 10.0 September 2013
www.imperva.com
COPYRIGHT NOTICE © 2002 - 2013 Imperva, Inc. All Rights Reserved. This document is for informational purposes only. Imperva, Inc. makes no warranties, expressed or implied. No part of this document may be used, disclosed, reproduced, transmitted, transcribed, stored in a retrieval system, or translated into any language in any form or by any means without the written permission of Imperva, Inc. To obtain this permission, write to the attention of the Imperva Legal Department at: 3400 Bridge Parkway, Suite 200, Redwood Shores, CA 94065. Information in this document is subject to change without notice and does not represent a commitment on the part of Imperva, Inc. The software described in this document is furnished under a license agreement. The software may be used only in accordance with the terms of this agreement. This document contains proprietary and confidential information of Imperva, Inc. This document is solely for the use of authorized Imperva customers. The information furnished in this document is believed to be accurate and reliable. However, no responsibility is assumed by Imperva, Inc. for the use of this material.
TRADEMARK ATTRIBUTIONS Imperva and SecureSphere are trademarks of Imperva, Inc.
All other brand and product names are trademarks or registered trademarks of their respective owners. Follow this link to see a complete statement of Imperva, Inc.’s copyrights, trademarks and acknowledgements: https://www.imperva.com/sign_in.asp?retURL=/articles/Reference/SecureSphere-Trademark-Attributions
PATENT INFORMATION The software described by this document is covered by one or more of the following patents: US Patent Nos. 7,752,662, 7,743,420, 7,640,235, 8,024,804, 8,051,484, and 8,056,141.
Imperva Contact Information US Headquarters Imperva Inc. 3400 Bridge Parkway, Suite 200 Redwood Shores, CA 94065 USA Tel: (650) 345 9000 Fax: (650) 345 9004
SecureSphere Migration Guide 10.0 V1
Email:
[email protected] Website: www.imperva.com
END USER LICENSE AND SERVICES AGREEMENT BY CLICKING ON THE "ACCEPT" BUTTON, TAKING AN ACTION TO INDICATE ACCEPTANCE, OR USING THE PRODUCTS (AS DEFINED BELOW) END USER AGREES TO THE TERMS OF THIS END USER LICENSE AND SERVICES AGREEMENT ("AGREEMENT") WITH IMPERVA, INC. ("IMPERVA"). IF END USER DOES NOT AGREE TO ALL OF THE TERMS OF THIS AGREEMENT, CLICK THE "CANCEL" BUTTON, DISCONTINUE THE SET-UP AND INSTALLATION OR DISCONTINUE USE OF THE PRODUCT. IF THE TERMS OF THE AGREEMENT ARE CONSIDERED AN OFFER, ACCEPTANCE IS EXPRESSLY LIMITED TO THESE TERMS. IMPERVA MAY MODIFY OR AMEND THIS AGREEMENT AT ANY TIME AND MAY PROVIDE NOTICE OF SUCH CHANGES BY POSTING A REVISED AGREEMENT AT HTTP://WWW.IMPERVA.COM/OTHER/LICENSE_AGREEMENT.ASP. YOUR CONTINUED USE OF SERVICES WILL CONSTITUTE YOUR ACCEPTANCE OF ANY SUCH CHANGES. 1.
Definitions. The following capitalized terms shall have the meanings set forth below: a. "Appliance" means the Imperva branded computer hardware on which the Software operates. b. "Delivery" shall mean, (i) in the case of Software, when the Software is made available by Imperva for End User to electronically download; (ii) in the case of Services, when the Service has been provisioned and made available to End User to access; and (iii) in the case of an Appliance, when the Appliance has been tendered by Imperva for shipment. c. "Documentation" means Imperva's technical specifications that accompany and describe the installation, use and operation of a Product. d. "End User" means the party that has purchased the Products for its own use, either directly from Imperva or thru an authorized third party. e. "Licensed Volume" means the volume or other measurement of permitted use for the Products as agreed to by Imperva. f. "Open Source Software" means third party software that Imperva distributes with the Software pursuant to a license that requires, as a condition of use, modification and/or distribution of such software, that the software or other software combined and/or distributed with it be (i) disclosed or distributed in source code form; (ii) licensed for the purpose of making derivative works; or (iii) redistributable at no charge. g. "Product" mean Appliances, Software or Services as the case may be. h. "Software" means Imperva's or its licensors' software (in object code format) or content, any updates or upgrades thereto provided to End User by Imperva and any Documentation pertaining thereto. Software may be delivered to End User on Appliances or on a standalone basis. Software does not include any Open Source Software. i. "Services" means the subscription services, including content, updates and upgrades thereto, offered by Imperva or that may be made available to End User by Imperva directly or thru its partners and suppliers. Services include, without limitation, the ThreatRadar service and Imperva offered services that are "powered by Incapsula." j. "Support and Maintenance" means the technical support services and periodic bug fixes and updates that Imperva may make available to End Users. k. "Professional Services" means the installation and configuration services that Imperva may provide to an End User.
2.
Licenses and Restrictions. a. Software. Subject to the terms and conditions of this Agreement, Imperva grants End User a nonexclusive, nontransferable, nonsublicensable, perpetual license to use the Software only for End User's internal business purposes on the Appliances or in the Licensed Volume purchased by End User. If End User purchases Software on a standalone basis, the license granted herein shall include the right to copy the Software. b. Services. Subject to the terms and conditions of this Agreement, Imperva grants End User a nonexclusive, nontransferable, nonsublicensable, revocable license to use and access the Services only for End User's internal business purposes. c. Restrictions. End User may not (and may not permit any third party to): (i) modify, incorporate or use in any other works, translate, reverse engineer (except to the limited extent applicable statutory law expressly prohibits reverse engineering restrictions), decompile, disassemble, otherwise attempt to derive source code from or create derivative works based on the Products; (iii) make unauthorized copies of the Products; (iv) disclose, distribute, transfer or market the Products to third parties; (v) remove any proprietary notices, labels or marks on or in any copy of the Products; or (vi) use the Products other than as permitted herein.
3. Support and Maintenance. Provided End User has an active and fully paid contract for Support and Maintenance, Imperva will provide Support and Maintenance in accordance with its standard Support and Maintenance terms then in effect.
4.
Additional Terms for Services. a. Accessing Services. Except as explicitly set forth herein, End User is solely responsible for acquiring and maintaining all of the equipment, software, services and items necessary to access and make use of the Services, including without limitation paying all charges, taxes, and other costs and fees related to the Internet access. End User may access the Services only through the interfaces and protocols provided or authorized by Imperva and its partners and agrees to set-up, maintain and use the Services in strict compliance with Imperva's and its partners' instructions. End User is solely responsible for maintaining the confidentiality of any passwords and account information required to access Services, for all acts that occur in connection with End User's account and to immediately notify Imperva of any unauthorized use of End User's account. In the event of expiration or termination of any Services that require DNS routing, End User will be solely responsible for rerouting its DNS traffic and Imperva, its partners and suppliers shall have no liability for End User's failure to do so. b. Authorization. Certain Services are offered to cache, serve, monitor and optimize web pages and web sites. As such, End User hereby grants Imperva and its partners a nonexclusive, worldwide, fully paid-up, royalty-free license to use, host, transfer, display, make available to the public, modify and otherwise exploit the content and material on End User websites ("End User Content"), in any media formats, solely for the purpose of providing of the Services. Imperva and its partners do not provide backup services for End User Content and if End User's use of the Services terminates for any reason, Imperva and its partners may, without notice, delete or deny End User access to any of content or meta data that may remain in its/their possession or control. In addition, End User agrees that if, at Imperva's and its partners' sole discretion, End User is using the Services in a manner that violates laws, rules or regulations or creates an excessive burden or potential adverse impact on Imperva's, its partners' or its suppliers' systems, business or customers, Imperva, its partners or its suppliers may suspend or terminate End User's access to the Services without notice to or liability to End User.
5. Professional Services. Professional Services, if any, to be provided by Imperva to an End User will be subject to a separate a statement of work ("SOW") agreed to by Imperva and Imperva's standard Professional Services terms then in effect. 6. Fees, Payment Terms. End User shall pay Imperva (or its authorized reseller) the applicable fees designated by Imperva (or its authorized reseller). Overage fees may apply if End User exceeds its allowance for any Product. Any fees payable to Imperva are non-refundable and payable in US Dollars. End User shall also pay all sales, use, value-added and other taxes, tariffs and duties of any type assessed against End User, except for taxes on Imperva's income. Fees shall be invoiced as follows: (a) fees for all Services and Support and Maintenance shall be invoiced in advance of the applicable Service or Support and Maintenance period, (b) fees for Software licenses and Appliance purchases will be invoiced upon Delivery. Title to Appliances and risk of loss shall pass to End User upon Delivery and Products shall be deemed accepted by End User upon Delivery. All payments from End User to Imperva are due net thirty (30) days of date of receipt of invoice. If End User's account for Services and Maintenance and Support Services is thirty (30) days or more overdue, in addition to any of its other rights or remedies, Imperva reserves the right to suspend the Services provided to End User, without liability to End User, until such amounts are paid in full. Imperva shall have the right to conduct and/or direct an independent accounting firm to conduct, during normal business hours, an audit of End User's facilities, computers and records to confirm End User's use of Products is in compliance with this Agreement. End User shall provide reasonable cooperation with any such audit. 7. Confidentiality; Privacy. End User agrees to hold confidence, during the term of this Agreement and for three (3) years after the termination hereof, any and all confidential and proprietary information of Imperva and its partners (the "Confidential Information"). Confidential Information includes, without limitation, the Products, their performance (including any benchmarking information) and Imperva's pricing of the Products. End User agrees not to use the Confidential Information except as necessary to fulfill its obligations or exercise its express rights hereunder, and not to disclose the Confidential Information to any person (other than End User's personnel having a need to know) without the prior written consent of Imperva. Without granting any right or license, Imperva agrees that the foregoing shall not apply with respect to any information that End User can document (i) is or becomes (through no improper action or inaction by End User or any affiliate, agent, consultant or employee of End User) generally available to the public, or (ii) was in its possession or known by it without restriction prior to receipt from Imperva. End User may make disclosures required by law or court order provided End User uses diligent reasonable efforts to limit disclosure and to obtain confidential treatment or a protective order and allows Imperva to participate in the proceeding. Imperva may collect, store and use information obtained from End Users to provide and improve the Products. Please read our Privacy Policy available at www.imperva.com/other/legal. 8. Proprietary Rights. All title and intellectual property rights in and to the Products and Confidential Information is owned exclusively by Imperva and its partners and suppliers. Other than as expressly set forth in this Agreement, no license or other rights in or to the Products and intellectual property rights thereto are granted to End User, and all such licenses and rights are hereby expressly reserved.
9.
Warranty and Disclaimer. a. Imperva warrants that during the sixty (60) day period commencing on the date of first Delivery, the Software and the Appliances will perform materially in accordance with their Documentation. In the event of a breach of the foregoing warranty with respect to the Software, as End User's sole and exclusive remedy, Imperva shall, at its sole expense, use reasonable efforts to modify the Software, so that it performs materially in accordance with its Documentation. In the event of a breach of the foregoing warranty with respect to an Appliance, as End User's sole and exclusive remedy, Imperva shall, at its sole expense and at its option, repair the Appliance or replace the Appliance with a new or reconditioned Appliance that performs materially in accordance with its Documentation. The foregoing warranty extends only to the original purchaser and will not apply to the misuse of or damage to the Products. The rights and remedies granted End User under this Section state Imperva's entire liability, and End User's exclusive remedy, with respect to any breach of the warranty set forth in Section 9(a). b. EXCEPT AS EXPRESSLY SET FORTH IN SECTION 9(a), THE PRODUCTS, THE SUPPORT AND MAINTENANCE SERVICES OR THE PROFESSIONAL SERVICES ARE PROVIDED "AS IS' AND IMPERVA MAKES NO WARRANTY OF ANY KIND, WHETHER EXPRESS, IMPLIED, STATUTORY, OR OTHERWISE. IMPERVA, ITS PARTNERS AND SUPPLIERS MAKE NO WARRANTY THAT USE OF THE PRODUCTS, THE SUPPORT AND MAINTENANCE SERVICES OR PROFESSIONAL SERVICES WILL BE UNINTERRUPTED, ERROR-FREE OR DEFECT-FREE, OR AVAILABLE AT ALL TIMES. IMPERVA HEREBY SPECIFICALLY DISCLAIMS, ON BEHALF OF ITSELF AND ITS PARTNERS AND SUPPLIERS, ALL IMPLIED WARRANTIES, INCLUDING ANY WARRANTY OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE, TO THE MAXIMUM EXTENT PERMITTED BY APPLICABLE LAW.
10. Limitations of Liability. IN NO EVENT WILL IMPERVA'S (AND ITS PARTNERS OR SUPPLIERS') LIABILITY FOR DIRECT DAMAGES HEREUNDER EXCEED THE TOTAL VALUE OF AMOUNTS TO BE PAID BY END USER FOR THE PRODUCT OR SERVICE AT ISSUE. IN NO EVENT SHALL IMPERVA HAVE ANY LIABILITY TO END USER FOR ANY LOST PROFITS, LOSS OF USE, INTERRUPTION OF THE SERVICES, COSTS OF PROCUREMENT OF SUBSTITUTE GOODS OR SERVICES, OR FOR ANY INDIRECT, SPECIAL, INCIDENTAL, PUNITIVE, OR CONSEQUENTIAL DAMAGES HOWEVER CAUSED AND, WHETHER IN CONTRACT, TORT OR UNDER ANY OTHER THEORY OF LIABILITY, WHETHER OR NOT THE PARTY HAS BEEN ADVISED OF THE POSSIBILITY OF SUCH DAMAGE. 11.
Term and Termination. a. The term of this Agreement will commence upon Imperva making the Products available to End User and will continue in effect for such time as End User continues to have the right to access the Products. Support and Maintenance for Software and/or Appliances will automatically renew at the end of the applicable Support and Maintenance term unless either party gives the other at least thirty (30) days notice of non-renewal prior to the end of the then current term. b. Either party may terminate this Agreement due to a material breach of this Agreement by the other party if such material breach remains uncured for a period of thirty (30) days following receipt of written notice by the breaching party; provided that Imperva may terminate this Agreement and/or all licenses granted to End User hereunder immediately upon written notice to End User if End User breaches any provision of Section 2 (License & Restrictions), Section 4 (Additional Terms for Services) or Section 7 (Confidentiality). In addition, Imperva may terminate any trial, evaluation or demonstration rights granted to End User at any time, with or without notice. c. Upon the earlier of expiration of End User's rights or termination of the Agreement, Imperva will cease providing all Services, Support and Maintenance and any Professional Services, and each party shall promptly return or destroy the other party's Confidential Information. Termination shall not relieve End User of the obligation to pay any fees accrued or payable to Imperva prior to the effective date of expiration or termination. The following sections shall survive termination of this Agreement: Sections 2(c), 4, 6 -13, and 15.
12. Government End User. If End User is part of an agency, department, or other entity of the United States Government ("Government"), the use, duplication, reproduction, release, modification, disclosure or transfer of the Software and Product is restricted in accordance with the Federal Acquisition Regulations as applied to civilian agencies and the Defense Federal Acquisition Regulation Supplement as applied to military agencies. The Product and Software are each a "commercial item," "commercial computer software" and "commercial computer software documentation." In accordance with such provisions, any use of the Product or Software by the Government shall be governed solely by the terms of this Agreement. All other use is prohibited. 13. Compliance With Laws; Export. End User agrees to abide by all applicable local, state, national and international law and regulations, and not to use the Services for any purpose that is unlawful, not contemplated or prohibited under this Agreement. End User shall comply with all export laws and restrictions and regulations of the Department of Commerce, the United States Department of Treasury Office of Foreign Assets Control ("OFAC"), or other United States or foreign agency or authority, and End User shall not export, or allow the export or re-export of the Software, Appliance Product or Services in violation of any such restrictions, laws or regulations. End User agrees to the foregoing and
represents and warrants that End User is not located in, under the control of, or a national or resident of any restricted country. End User agrees to indemnify and hold Imperva, its partners and suppliers harmless against any claims, losses or expenses arising out of End User's breach of this Agreement or use of the Products. 14. End User Mention. End User consents to Imperva using its name and logo to identify End User as a customer of Imperva, such as use on Imperva's website. Any use shall be subject to Imperva complying with any guidelines that End User may deliver to Imperva from time-to-time regarding the use of its name and logo. This consent terminates upon termination of the Agreement. 15. Miscellaneous Provisions. The parties are independent contractors under this Agreement and nothing in this Agreement authorizes a party to act as an agent of the other or bind the other to any transaction or agreement. This Agreement may not be assigned in whole or in part, by operation of law or otherwise, without the prior written consent of the other party, provided that a party may freely assign this Agreement in connection with a merger, acquisition, reorganization or reincorporation of such party with notice to the non-assigning party. In the event any provision of this Agreement shall be determined to be invalid or unenforceable under law, all other provisions of this Agreement shall continue in full force and effect. This Agreement contains the entire agreement of the parties with respect to the subject matter of this Agreement and supersedes all previous communications, representations, understandings and agreements, either oral or written between the parties with respect to said subject matter. This Agreement may only be modified or waived in a written instrument signed by both parties. A waiver of any breach under this Agreement shall not constitute a waiver or any other breach or future breaches. Notwithstanding the foregoing, if a separate, written and signed agreement for the license of the Products exists between End User and Imperva, the terms of that written agreement (excluding any pre-printed terms of any Purchase Order, confirmation or similar document, all of which will have no effect and will not be considered agreed to by Imperva) shall take precedence over this Agreement. All notices, requests, demands and other communications hereunder shall be in writing and shall be deemed to have been duly given if delivered or mailed by certified mail, return receipt requested or by any other means of delivery which generates a written receipt at the addresses set forth on the cover sheet. This Agreement will be interpreted and construed in accordance with the laws of the State of California and the United States of America, without regard to conflict of law principles. The parties hereby consent to the exclusive jurisdiction and venue of the state and federal courts located in San Francisco County, California for resolution of any disputes arising out or relating to this Agreement. 16. Open Source Software. Open Source Software is copyrighted and licensed under the GPL/LGPL and other licenses. Copies of or references to those licenses are included with Software in the "Help" section. You may obtain the complete corresponding Open Source Software source code from us for a period of three years after our last shipment of the Software, by sending a money order or check for $10 to: Legal Department - Open Source Software Request, Imperva, Inc., Redwood Shores, CA 94065, United States.
Last updated: May 10, 2011
Table of Contents About This Document ......................................................................................................... 10 Scope .................................................................................................................................. 10 Intended Audience ................................................................................................................ 10 Assumptions ......................................................................................................................... 10 Reference Documents ........................................................................................................... 10 Imperva Support .................................................................................................................. 10 Document Conventions ......................................................................................................... 11 Introduction ....................................................................................................................... 12 Upgrades and Patches ........................................................................................................... 12 Patches ......................................................................................................................... 12 Upgrading ............................................................................................................................ 12 Obtaining the SecureSphere Software Packages ...................................................................... 12 Estimated Migration Time ...................................................................................................... 12 How to Use this Document .................................................................................................... 13 The SecureSphere Operating System................................................................................. 14 Upgrading from Version 7.0.0.7061 and Higher ................................................................ 15 Upgrading from SecureSphere Standard Edition ...................................................................... 15 Backup Directory .................................................................................................................. 15 Upgrade Sequence - What to Upgrade First ............................................................................ 15 Upgrading From Versions Prior to Version 9.0 .................................................................. 15 Upgrading From Version 9.0 and Later ............................................................................ 15 Upgrading SOM ............................................................................................................. 15 Before Starting the Upgrade Procedure .................................................................................. 16 Limitations ........................................................................................................................... 19 Action Sets .................................................................................................................... 19 Plugins .......................................................................................................................... 19 Non-Admin CLI Users ..................................................................................................... 19 URL Patterns ................................................................................................................. 19 SharePoint .................................................................................................................... 20 MySQL .......................................................................................................................... 20 NTP .............................................................................................................................. 20 Audit Policies - Archive Enabled ...................................................................................... 20 SSH Keys ...................................................................................................................... 20 Connectivity to the Protected Servers .............................................................................. 20 DNS Settings ................................................................................................................. 20 Routes .......................................................................................................................... 21 IP Rules ........................................................................................................................ 21 Gateway High Availability of Type STP ............................................................................. 21 Files .............................................................................................................................. 21 System Events Archiving ................................................................................................ 21 Archive Settings ............................................................................................................. 21 Discovery Results ........................................................................................................... 21 File .barshrc .................................................................................................................. 22 Licenses ........................................................................................................................ 22 Version 7.5 Remote Agents ............................................................................................ 22 Activate Settings ............................................................................................................ 22 Gateway Groups ............................................................................................................ 22 KRP - Onboard Interface ................................................................................................ 22 nCipher Card ................................................................................................................. 22 nCipher NetHSM ............................................................................................................ 23 SafeNet LunaSA ............................................................................................................. 24 ARP (Apache Reverse Proxy) - Keys ................................................................................ 25 Log Collector ................................................................................................................. 25 SSL Keys ....................................................................................................................... 25 Host Names ................................................................................................................... 25 SecureSphere / VM ........................................................................................................ 25 SNMP ............................................................................................................................ 25
Table of Contents
Read-Only User ............................................................................................................. 25 Execution History ........................................................................................................... 25 Behavioral Changes ............................................................................................................... 25 Hard Disk Identifier ........................................................................................................ 25 Learning Statistics .......................................................................................................... 25 Revoking Permissions on SharePoint URM Scan ................................................................ 25 Revoking Permissions on File URM Scan .......................................................................... 26 Synchronizing with Active Directory Users before File/SharePoint URM Scan ....................... 26 Static URL Profiling ........................................................................................................ 26 Upgrade Procedures .............................................................................................................. 26 Upgrading a SecureSphere Management Server or Onebox ............................................... 26 Upgrading a SecureSphere Gateway (not relevant to Onebox Deployment) ........................ 34 Post Upgrade Procedures ....................................................................................................... 39 Enable Dual-core on Aspen-Hill Appliances ....................................................................... 39 Restore the Reverse Proxy Apache Configuration ............................................................. 39 Patch Update ...................................................................................................................... 41 Backing Up and Restoring the System ............................................................................... 42 Introduction ......................................................................................................................... 42 The Backup Process .............................................................................................................. 42 SecureSphere 6.x and Higher .......................................................................................... 42 Backup Audit Files .......................................................................................................... 43 The Restore Process .............................................................................................................. 43 SecureSphere 7.x and Higher .......................................................................................... 43 Appendix A – Monitoring Installation Status with VNC ..................................................... 45 Appendix B – Mounting a USB Key ..................................................................................... 46 Appendix C - Configuring Apache Reverse Proxy............................................................... 47 Uploading the Encryption Keys ............................................................................................... 47 nss.conf and http.conf files .................................................................................................... 49 Appendix D - Enabling Activate Settings............................................................................ 50 Enabling the Activate Settings Option ..................................................................................... 50 Applying Settings Which Have Not Yet Been Applied ................................................................ 50 Appendix E – Guidelines for MX-HA Upgrade..................................................................... 51 Appendix F - Upgrade Procedure for the Kernel Reverse Proxy Configuration ................. 53 Appendix G - SecureSphere Agent Upgrade....................................................................... 57 Upgrading the SecureSphere Agents ...................................................................................... 57
8
SecureSphere Version 10.0 Migration Guide
SecureSphere Version 10.0 Migration Guide This Migration Guide is intended as a guide for administrators tasked with migrating installations of earlier versions of Imperva SecureSphere to version 10.0, and includes the following information: •
About This Document on page 10
•
Introduction on page 12
•
The SecureSphere Operating System on page 14
•
Upgrading from Version 7.0.0.7061 and Higher on page 15
•
Patch Update on page 41
•
Backing Up and Restoring the System on page 42
•
Appendix A – Monitoring Installation Status with VNC on page 45
•
Appendix B – Mounting a USB Key on page 46
•
Appendix C - Configuring Apache Reverse Proxy on page 47
•
Appendix D - Enabling Activate Settings on page 50
•
Appendix E – Guidelines for MX-HA Upgrade on page 51
•
Appendix F - Upgrade Procedure for the Kernel Reverse Proxy Configuration on page 53
•
Appendix G - SecureSphere Agent Upgrade on page 57
Chapter 1 - SecureSphere Version 10.0 Migration Guide
1.
About This Document 1.1
Scope This Migration Guide comprises full explanations of the migration process to SecureSphere version 10.0 from SecureSphere version 7.x and higher. The document details the specific tasks involved in the migration process. Note: This Migration Guide describes how to upgrade from an appliance on which the First Time Login has already been successfully completed. If you are installing SecureSphere version 10.0 on an appliance on which an earlier version is installed but the First Time Login has never been run, then simply install the new version and run the First Time Login; you do not need this Migration Guide in this case.
1.2
Intended Audience This document is intended for administrators setting up and provisioning the SecureSphere system. This document can also be used as reference to the migration conversion rules from previous versions of SecureSphere.
1.3
Assumptions The document assumes basic understanding of system administration and knowledge of how to operate the SecureSphere system.
1.4
Reference Documents •
SecureSphere User Manual The User Manual documents tasks for administering the domain protected by the SecureSphere system, together with short reminders of the relevant concepts. Full explanations are covered in the Reference Manual.
•
SecureSphere Administration Manual The Administration Manual documents only tasks for administering SecureSphere.
•
Deployment Guides These deployment guides are intended for use during the first month after installation, to reduce false positives and establish best practices.
•
Quick Start Guides The separate Quick Start Guides are supplied with the appliances and should be used for the installation process itself.
1.5
Imperva Support Imperva Technical Support can be contacted by telephone, email or using the self service portal. All communication methods are detailed at www.imperva.com/services/support.html.
10
Version 10.0 Migration Guide
1. About This Document
1.6
Document Conventions In this document, the following typographical and formatting conventions are used: Table 1 Typographical and Formatting Conventions Convention
Meaning
Example
command
The monospaced font is used for CLI commands or output, and for file names.
cd /tmp
|
separates optional values in lists
oranges | apples
indicates a placeholder which must be replaced with a relevant value
[]
indicates a placeholder which must be replaced with a relevant value
[the name of the file]
Version 10.0 Migration Guide
11
Chapter 1 - SecureSphere Version 10.0 Migration Guide
2.
Introduction 2.1
Upgrades and Patches 2.1.1
Patches
Before starting the upgrade process, you must install the latest patch to your current version.
Note: The upgrade package release date (the date that appears next to the upgrade package file on the FTP) must be the same or later than the release date of the patch that you install.
The installation file includes the latest patches, so there is no need to install a patch after the upgrade process.
2.2
Upgrading The following table describes the upgrade path, which depends on the SecureSphere version from which you are upgrading. .
Version from which you are upgrading 7.0.0.7061 and higher
2.3
Upgrade Path •
Upgrade directly to this version, as described in Upgrading from Version 7.0.0.7061 and Higher on page 15.
Obtaining the SecureSphere Software Packages The SecureSphere upgrade software packages are on the FTP server at: /Downloads/SecureSphere_Upgrades/V10.0/ There are two directories, one for 32 bit and the other for 64 bit, and each directory contains one package.
Note: If your appliance has at least 4GB of RAM, you must upgrade to the 64-bit version of SecureSphere.
2.4
File Name
Version
32Bit/upgrade-10.0.0._0.i686-noarch.rpm
SecureSphere 10.0 32-bit version
64Bit/upgrade-10.0.0._0.x86_64-noarch.rpm
SecureSphere 10.0 64-bit version
Estimated Migration Time Experience has shown that the average migration takes about 2 hours, with migrations of extremely large amounts of data or migrations in high-load environments sometimes taking as long as 5 hours.
12
Version 10.0 Migration Guide
2. Introduction
2.5
How to Use this Document To successfully upgrade previous versions of the SecureSphere system to the current version, perform the following: 1.
Backup your system for rollback purposes.
2.
When used, archive all audit information.
3.
Read carefully all the prerequisites and limitations.
4.
Upgrade your system.
Version 10.0 Migration Guide
13
Chapter 1 - SecureSphere Version 10.0 Migration Guide
3.
The SecureSphere Operating System This version of SecureSphere uses an OS based on CentOS 5.4, as have all versions of SecureSphere beginning with build 8.0.0.8265. Whenever you upgrade to this version of SecureSphere, CentOS 5.4 will be installed from scratch. The motivation in upgrading SecureSphere to this OS was: •
Hardware Support: The previous operating system did not support several of the new hardware components, such as mother-boards and network cards.
•
Improved management: The new operating system provides better memory and disk management, as well as performance improvement.
•
Ability to integrate with 3rd party products. Note: • If you have modified any system files (such as hades.cfg), the modified file (the file from before the upgrade) will be saved in the backup directory. It is your responsibility to edit the newlyinstalled system file and modify it accordingly. • The backup directory is: /var/SecureSphere/upgrades/upgrade-10.0.0._0./backup
14
Version 10.0 Migration Guide
4. Upgrading from Version 7.0.0.7061 and Higher
4.
Upgrading from Version 7.0.0.7061 and Higher 4.1
Upgrading from SecureSphere Standard Edition There no longer are two version of SecureSphere: Standard Edition and Enterprise Edition. There is now only one version. Whether you are upgrading from Standard Edition or Enterprise Edition, follow the instructions given in this documents. If you previously had Standard Edition, you will still have the same capabilities as you had earlier, which are enforced by your license.
4.2
Backup Directory In the course of the upgrade to the new version, SecureSphere saves the configuration files from the previous version in the following directory: /var/SecureSphere/upgrades/upgrade-10.0.0._0./backup
4.3
Upgrade Sequence - What to Upgrade First 4.3.1
Upgrading From Versions Prior to Version 9.0
When upgrading SecureSphere Server and SecureSphere Gateway separately from versions prior to version 9.0, first upgrade the SecureSphere Management Server. Once the upgrade of the SecureSphere Management Server is completed, upgrade the Gateway. The reason is that when the SecureSphere Gateway is installed, it must register with the Management Server, so the Management Server must already be available and running. After the Management Server is running with the newer version, the Gateways should be running with last known good configuration until they are upgraded and receive the new configuration from the Management Server. If you upgrade the Gateway first, then you may receive a warning message that the Gateway has reverted to the last known configuration. In this case, upgrade the Management Server and restart the Gateway.
4.3.2
Upgrading From Version 9.0 and Later
When you are upgrading SecureSphere Server and SecureSphere Gateway separately from version 9.0 and later, you should upgrade the Gateway first. This is because the 9.5 and later Gateway can work with 9.0 and later Management Server. You can then upgrade the Management Server at your convenience.
4.3.3
Upgrading SOM
When upgrading a SOM configuration, the correct upgrade sequence is as follows: 1.
Gateways
2.
SOM
3.
Management Servers
Note: SOM-MX backward compatibility requires SOM 10.0 and MX 9.5 p3.
Version 10.0 Migration Guide
15
Chapter 1 - SecureSphere Version 10.0 Migration Guide
4.4
Before Starting the Upgrade Procedure Before you start the upgrade procedure, perform the following actions: Upgrade Task Checklist Step
V
Action
Description
1
Notify Imperva support.
Notify the Imperva Support Team before upgrading your system.
2
If you are not working in immediate activation mode, apply all settings which have been made to SecureSphere but not yet applied.
For more information, see
Applying Settings Which Have Not Yet Been Applied on page 50 “Activating Settings” in the “Basic Configuration” chapter of the SecureSphere User Guide. The SecureSphere version number is displayed in the status bar (on the right side) in the SecureSphere GUI.
3
4
16
To determine the patch you are using, execute the following CLI (command line interface) command on the appliance: cat /opt/SecureSphere/ etc/patch_level The latest patch available for your version of SecureSphere, as well as instructions for installing the patch (in the Patch Change Log), are available on the SecureSphere support site.
Install the latest patch to the SecureSphere version you are running.
If you are using nCipher netHSM, backup its configuration, and document the parameter settings.
Hardware Security Module devices (HSMs) are specialized external hardware devices which store private encryption keys in specialized key storage devices. They protect the key information by making it impossible to gain access to the keys, even if the device is stolen. This step is required because the nCipher netHSM configuration is not carried over to the upgraded configuration. You will have to partially reconfigure the nCipher configuration.
See the “nCipher HSM Installation” section in the
SecureSphere Administration Guide for information on nCipher netHSM. For more information about how to restore the configuration, see nCipher NetHSM on page 23. For more information about nCipher, see the nCipher documentation.
Version 10.0 Migration Guide
4. Upgrading from Version 7.0.0.7061 and Higher
Upgrade Task Checklist (cont.) Step
5
6
V
Action
If you are using nCipher card, backup its configuration (the directory /opt/nfast/kmdata/ local to an external storage device), and document the parameter settings.
If you are using SafeNet LunaSA, backup its configuration, and document the parameter settings.
Description Hardware Security Module devices (HSMs) are specialized external hardware devices which store private encryption keys in specialized key storage devices. They protect the key information by making it impossible to gain access to the keys, even if the device is stolen. This step is required because the nCipher card configuration is not carried over to the upgraded configuration. You will have to partially reconfigure the nCipher configuration. Hardware Security Module devices (HSMs) are specialized external hardware devices which store private encryption keys in specialized key storage devices. They protect the key information by making it impossible to gain access to the keys, even if the device is stolen. This step is required because the SafeNet Luna configuration is not carried over to the upgraded configuration. You will have to partially reconfigure the SafeNet Luna configuration.
7
If you are using a SAN device, you will have to unmount and disconnect the device during the upgrade. Instructions about how to do this are given later in this procedure.
8
Backup your system.
9
Make sure you know the SecureSphere GUI admin password (for the user “admin”).
At a later point in the upgrade process, you will need to login to the SecureSphere GUI.
10
If you have audit data, archive and backup the audit data.
It is strongly recommended that you archive audit data before upgrading, since in some cases audit data can be lost during the upgrade process.
Version 10.0 Migration Guide
A SAN device is a dedicated network that provides access to consolidated, block level data storage, and is primarily used to make storage devices, such as disk arrays accessible to servers so that the devices appear to the OS as locally attached devices.
For more information, see See the “nCipher HSM Installation” section in the
SecureSphere Administration Guide for information on the nCipher card. For more information about how to restore the nCipher card configuration, see nCipher Card on page 22. For more information about nCipher, see the nCipher documentation.
See the “SafeNet LunaSA” section in the SecureSphere Administration Guide for information on SafeNet LunaSA. For more information about how to restore the SafeNet LunaSA configuration, see SafeNet LunaSA on page 24. For more information about SafeNet LunaSA, see the SafeNet LunaSA documentation.
For more information, see the documentation for your SAN device.
Backing Up and Restoring the System on page 42
17
Chapter 1 - SecureSphere Version 10.0 Migration Guide
Upgrade Task Checklist (cont.) Step
Action
Description
11
If you store your audit files on externally mounted devices, rename the audit directory on the external device to “old_audit”.
This action ensures that your existing audit files will not be over-written by the upgrade process.
12
If you have configured mounts in your system, then un-mount all the mounted devices.
13
Disable all removable media such as USB drives, etc..
14
15
18
V
On a Management Server, verify that the /var partition has at least 18GB of free space.
On a Gateway, verify that the /var partition has at least 18 GB of free space if you are upgrading from version 7.0 or higher
For more information, see
This step ensures that the appliance will not attempt to boot from the removeable media. To check available disk space under the /var partition, execute the following CLI (command line interface) command on the appliance: df –h If the /var partition has less than 18GB of free disk space, contact the Imperva Support Team. This partition is used to backup the system configuration dump file, reports, etc.
This partition is used to hold the audit records. If you are upgrading from version 7.0 or higher, only 18 GB of free space is needed.
Note: When upgrading SecureSphere running on appliances with a hard disk size of 37GB, you can bypass the disk space check in the upgrade validation script by using the force_install option. However, you should not use the force_install option unless you verify with support that there is enough space to continue with the upgrade. The check install script will fail if there is not enough free space. By default, the upgrade script keeps a back up of the audit information until audit upgrade successfully completes. Use the force_install option only after consulting with support. If the force_install option is used, a backup of the audit files is not kept. Each original file that is successfully upgraded is deleted.
Version 10.0 Migration Guide
4. Upgrading from Version 7.0.0.7061 and Higher
Upgrade Task Checklist (cont.) Step
16
17
V
Action
Description This file contains information about ARP settings, IP routes,
If you have modified the etc/rc.local file, back it up.
and IP rules.
If you are using the bash shell, backup the
This file is not migrated to the new configuration, and you will have to manually restore it.
.barshrc file.
This file is not migrated to the new configuration, and you will have to manually restore it.
18
Backup the CA and server keys.
These files are not migrated to the new configuration, and you will have to manually restore them.
19
Backup OS scripts used in action interfaces of type “OS command”.
These scripts are not migrated to the new configuration, and you will have to manually restore them.
4.5
For more information, see
IP Rules on page 21
File .barshrc on page 22
Limitations 4.5.1 1.
Action Sets
When migrating an action set with an action interface of type “Assignment Task” and/or of type “Review Task,” the data under the following fields: •
“Followed action on status change”
•
“Followed action on assignee change”
•
“Followed action on overdue”
will sometimes not be migrated. 2.
OS scripts used in action interfaces of type “OS command” do not survive the upgrade. You must backup these scripts before performing the upgrade and restore them after the upgrade is complete.
4.5.2
Plugins
The order of execution of plugins can be explicitly specified in version 9.5., while in earlier versions, the order was implicit. If there is more than one plugin defined for the same service, the implicit order of earlier versions is not always maintained in the migration to version 9.5, so after the upgrade, review the list of plugins for each service to confirm that they are being executed in the order you want them to execute.
4.5.3
Non-Admin CLI Users
When a non-admin CLI user logs into the appliance using SSH after the upgrade to version 10.0, he will be asked for his password and then will immediately be asked to change his password.
4.5.4
URL Patterns
When migrating from version 7.0, the Learning State of URL patterns is changed to “In Learning”.
Version 10.0 Migration Guide
19
Chapter 1 - SecureSphere Version 10.0 Migration Guide
4.5.5
SharePoint
The SharePoint service and the applications (URL groups) defined under it do not survive the upgrade from version 9.0 to version 9.5. The service and the applications (URL groups) remain in the site tree after the upgrade, but they cannot be used. You must manually delete them. However, you do not have to manually re-define them. To automatically re-define them, right-click the SharePoint service in the site tree and select Auto-Discover Applications. Afterwards, you can use the File Explorer. You must then re-apply scans to the newly-defined services and applications.
4.5.6
MySQL
If you are using one of the following SecureSphere features with a MySQL database: •
DB Data Classification
•
Assessment
•
Credentials Verification
•
Test Connection
After upgrading, you must download and install an MySQL driver on the SecureSphere MX even if you already downloaded the driver when using the previous version of SecureSphere. Instructions for doing this are in the “Basic Configuration” chapter of the SecureSphere User Guide.
4.5.7
NTP
If you have an NTP server configured, the configuration will not be migrated and you will have to reconfigure the NTP after the upgrade is complete.
4.5.8
Audit Policies - Archive Enabled
In version SecureSphere 10.0, the Archive Enabled parameter is not available for Audit Policies, so upgrading to version 10.0 removes this parameter from Audit Policies Configuration reports.
4.5.9
SSH Keys
After upgrading the SecureSphere system, new SSH keys are generated. Therefore, a warning is displayed to the client that the signature has changed. The message is displayed only once after the upgrade, when the user tries to SSH to the appliance for the first time.
4.5.10
Connectivity to the Protected Servers
During the upgrade process, connectivity to the protected servers may be lost, depending on the gateway’s mode: •
Transparent Reverse Proxy/Kernel Reverse Proxy/Apache Reverse Proxy: The connectivity is lost during the upgrade process.
•
STP/IMPVHA Bridge: The connectivity depends on the fail mode configuration. If the fail mode configuration is set to fail open, the network card creates a bypass and the connectivity remains. If the fail mode configuration is set to fail close, the connectivity is lost.
•
Sniffing: Connectivity to the protected servers is not affected when running the SecureSphere Gateway in the Sniffing mode.
4.5.11
DNS Settings
DNS settings are saved before the upgrade process begins. They are restored only at the end of the upgrade process, so during the upgrade process DNS settings are unavailable and connectivity may be temporarily lost. When upgrading from SecureSphere 7.0 using the latest patch (patch 28), check if the file etc/resolv.conf is not empty. If the file is empty, you need to reconfigure the DNS settings.
20
Version 10.0 Migration Guide
4. Upgrading from Version 7.0.0.7061 and Higher
4.5.12
Routes
During the upgrade process, all the manually defined routes are identified. When the upgrade process completes, the routes are restored. Files containing static routes changes are not migrated. Instead, the SecureSphere system maintains all routes defined internally. The new static routes should be configured from impcfg.
Warning: Since routes are removed during the upgrade process, connectivity to the appliance may be lost during part of the process.
4.5.13
IP Rules
Manual changes to /etc/rc.local to configure ARP settings, IP routes, and IP rules, are not migrated. Manual configuration is required after completing of the upgrade process. The files can be viewed after the upgrade process completion at: /var/SecureSphere/upgrades/upgrade-10.0.0._0./backup
4.5.14
Gateway High Availability of Type STP
After upgrading, the gateway high availability mode of type STP will be displayed as “off” in impcfg. This behavior occurs since the HA attribute was not present in impcfg before this build. Effectively, the gateway high availability mode remains as it was before migration. Users should manually turn high availability on after re-registration of the gateway.
4.5.15
Files
Before the migration process, the upgrade script verifies that no changes have been made to /opt/SecureSphere/etc/hades.cfg. If the file has been changed, a message is displayed and the modified file (the file from before the upgrade) is saved in the backup directory. It is your responsibility to edit the newly-installed system file and modify it accordingly. After the upgrade process completes, the modified system files (the files from before the upgrade) can be found in the following directory: /var/SecureSphere/upgrades/upgrade-10.0.0._0./backup The files are: /etc/httpd/conf/httpd.conf /etc/rc.d/rc.local /opt/SecureSphere/etc/impctl/lib/keepalived.sh /opt/SecureSphere/etc/hades.cfg
4.5.16
System Events Archiving
Only the 100,000 most recent system events survive the upgrade. Older system events are deleted without being purged. Version 10.0 stores, by default, the last 100,000 system events. Any system event beyond 100,000 is purged nightly. You can configure archiving for the system events or even change the number of events kept, however if no archive location is defined any event beyond the last 100,000 is purged and not archived. To control the settings after upgrading, go to Admin > Maintenance > System Event Archiving.
4.5.17
Archive Settings
The default and user-defined archive name templates are reset to the new format.
4.5.18
Discovery Results
Existing discovery results are deleted.
Version 10.0 Migration Guide
21
Chapter 1 - SecureSphere Version 10.0 Migration Guide
4.5.19
File .barshrc
The .barshrc file is not migrated, so it must be recreated inafter the upgrade.
4.5.20
Licenses
If both a commercial and later evaluation license are present, you must use the force_install option.
4.5.21
Version 7.5 Remote Agents
After upgrading a VM gateway, version 7.5 remote agents must be restarted in order to communicate with the upgraded gateway.
4.5.22
Activate Settings
After the migration process, the Activate Settings feature is disabled. In order to use Activate Settings, you must enable it first. For information on how to do this, see Enabling the Activate Settings Option on page 50.
4.5.23
Gateway Groups
If a gateway group contains more than one gateway, and Block on Overload is checked under Overload Policy (under Topology Configuration in the Gateway Group Details pane), the gateway may be moved out of the group during the upgrade process. The user must manually return the gateway to the gateway group after the upgrade is complete.
4.5.24
KRP - Onboard Interface
G series appliances: The onboard interface cannot be used in a KRP (Kernel Reverse Proxy) configuration.
4.5.25
nCipher Card
Note: This section is relevant to SecureSphere Gateways only.
The nCipher card configuration is not completely carried over to the upgraded configuration. You will have to partially reconfigure the nCipher card configuration. See the “nCipher Card Installation” section in the “Add Ons” appendix of the SecureSphere Administration Guide for more information. You do not have to do everything described in that appendix, because only the SecureSphere Gateway has to be reconfigured. You only need to perform the procedure below. To reconfigure the nCipher card after the upgrade: 1.
Confirm that you have backed up the nCipher card’s configuration (the directory /opt/nfast/kmdata/local to an external storage device).
Note: The section Before Starting the Upgrade Procedure on page 16 instructed you to do this.
22
2.
Referring to the procedure “nCipher Card” in the “Add-On” Appendix in the SecureSphere Administration Guide, perform the steps in the “Installing the nCipher Card Driver” section.
3.
Next, perform the steps in the “Verifying the Installation” section.
4.
Next, perform steps 1-3 in the “Security World Initialization” section.
Version 10.0 Migration Guide
4. Upgrading from Version 7.0.0.7061 and Higher
5.
Next, instead of steps 4-6 in the “Security World Initialization” section, do the following: 5.1
Copy the contents of the directory /opt/nfast/kmdata/local (which you backed up before beginning this upgrade) from the backup location back to the /opt/nfast/kmdata/local directory
5.2
Execute the following command:
/opt/nfast/bin/new-world --program -m1 5.3
When you are asked to do so, insert the SmartCard into the nCipher reader. The output should resemble the following:
Checking modules and reading cards ... 10:38:15 WARNING: Module #1: preemptively erasing module to see its slots! Indoctrinating Module: Module 1: 0 cards of 1 read Checking modules and reading cards ... Card reading complete. 6.
Continue the Security World Initialization from step 7.
4.5.26
nCipher NetHSM
Note: This section is relevant to SecureSphere Gateways only.
The nCipher netHSM configuration is not completely carried over to the upgraded configuration. You will have to partially reconfigure the nCipher card configuration. See the “nCipher netHSM Installation” section in the “Add Ons” appendix of the SecureSphere Administration Guide for more information. You do not have to do everything described in that appendix, because only the SecureSphere Gateway has to be reconfigured. You only need to perform the procedure below. Referring to the procedure “To integrate between SecureSphere and the netHSM” in the “Setting Up the Integration” section in the “Add-On” Appendix in the SecureSphere Administration Guide, perform the following steps:
Version 10.0 Migration Guide
Step
Action
1
Verify that this is still correct.
2
Verify that this is still correct.
3
Perform this step.
4
Perform this step.
5.1
There is no need to perform this step.
5.2
Perform this step.
5.3
Perform this step.
6
Verify that this is still correct.
23
Chapter 1 - SecureSphere Version 10.0 Migration Guide
4.5.27
Step
Action
7
There is no need to perform this step.
8
There is no need to perform this step.
SafeNet LunaSA
Note: This section is relevant to SecureSphere Gateways only.
The SafeNet LunaSA configuration is not completely carried over to the upgraded configuration. You will have to partially reconfigure the SafeNet LunaSA configuration. See the “LunaSA Software Installation” section in the “Add Ons” appendix of the SecureSphere Administration Guide for more information. You do not have to do everything described in that appendix, because only the SecureSphere Gateway has to be reconfigured. You only need to perform the procedure below. 1.
Connect to LunaSA using the following command: ssh admin@
2.
Delete the old client from the client list using the following command: client delete -client
3.
Verfiy that the old client was deleted using the following command: client list
Note: Detailed instructions for performing each of the following steps are in the “Add Ons” appendix of the SecureSphere Administration Guide.
24
4.
Install the LunaSA Package on the Gateway, as described in the “LunaSA Software Installation” section in the SecureSphere Administration Guide.
5.
Check the connectivity between the SecureSphere Gateway and the HSM, as described in the “Check the Network Connection Between the SecureSphere Gateway and LunaSA” section in the SecureSphere Administration Guide.
6.
Establish NTL between the SecureSphere Gateway and LunaSA, as described in the “Establish NTL Between the SecureSphere Gateway and LunaSA” section in the SecureSphere Administration Guide.
7.
Assign a client (SecureSphere Gateway) to a LunaSA HSM partition, as described in the “Assign a Client (SecureSphere Gateway) to a LunaSA HSM Partition” section in the SecureSphere Administration Guide.
8.
Edit the /etc/Chrystoki.conf file, as described in the “Edit /etc/Chrystoki.conf” section in the SecureSphere Administration Guide.
Version 10.0 Migration Guide
4. Upgrading from Version 7.0.0.7061 and Higher
9.
Restart the SecureSphere Gateway, as described in the “Restart the SecureSphere Gateway” section in the SecureSphere Administration Guide.
10. Test the SSL connection.
4.5.28
ARP (Apache Reverse Proxy) - Keys
The nss.conf file and CA and server keys are not carried over to the upgraded configuration. For more information, see Appendix C - Configuring Apache Reverse Proxy on page 47.
4.5.29
Log Collector
The Log Collector password does not survive the upgrade and must be reconfigured.
4.5.30
SSL Keys
Existing SSL keys are migrated, but their expiration date and other fields not displayed in earlier versions of the SecureSphere are not displayed in this version either, even though these fields are displayed for SSL keys created in this version. These older SSL keys will not be automatically deleted based on their expiration dates (as defined in Admin > System Definitions > SSL Certificate Expiration Monitoring).
4.5.31
Host Names
In a Web profile, a learned host with a space in its name is not migrated.
4.5.32
SecureSphere / VM
After upgrading SecureSphere on VM, the Gateway and MX may no longer be able to communicate. If this happens, un-register the Gateway from the MX and then register it again.
4.5.33
SNMP
The default SNMP setting for SecureSphere is off, so if you had SNMP enabled, you will have to re-enable it after upgrading.
4.5.34
Read-Only User
In version 8.5 and earlier it was possible to set a user as a read-only (in Admin > Users and Permissions > Users & Roles). This option was removed in versions 9.0 and 9.5 and was re-created in version 10.0. The limitation is that when upgrading from version 8.5 or earlier to version 10.0, the Read-Only User setting is not migrated.
4.5.35
Execution History
In Admin > Jobs Status > Execution History: The Execution History tab contains information about all the previous executions of the specific job. After an upgrade, only the last week executions history is kept and the rest is deleted.
4.6
Behavioral Changes 4.6.1
Hard Disk Identifier
Hard disks previously identified as HDE and HDA are identified as SDA after the upgrade.
4.6.2
Learning Statistics
Learning statistics in the profile overview are reset to zero after the upgrade.
4.6.3
Revoking Permissions on SharePoint URM Scan
When upgrading from 9.0: After the upgrade, first run application discovery on the SharePoint service and only then revoke permissions on URM scan. You cannot revoke permissions on the pre-upgrade data.
Version 10.0 Migration Guide
25
Chapter 1 - SecureSphere Version 10.0 Migration Guide
When upgrading from 9.5: After the upgrade you can run the URM scan in order to revoke permissions on URM scan and see additional data in URM results. You do not need to run application discovery on the SharePoint service.
4.6.4
Revoking Permissions on File URM Scan
When upgrading to 10.0: After the upgrade you can revoke permissions on file URM scans. You cannot revoke permissions on the pre-upgrade data.
4.6.5
Synchronizing with Active Directory Users before File/SharePoint URM Scan
When upgrading to 10.0: After the upgrade you need to make sure Active Directory data is contained in the Windows Domains global object. To synchronize the Active Directory data, follow the instructions in the Configuring Active Directory Integration for Data Enrichment section in the File/ SharePoint Security User Guide.
4.6.6
Static URL Profiling
When upgrading from versions 7.0 - 9.5 to version 10.0 patch 1: Learning of static URLs during profiling is disabled by default. You can enable static URL profiling at any time. For more information, see the article in the Customer Portal titled StaticURLs-How-to-Enable-Static-URL-Profiling-inSecureSphere-v10-0.
4.7
Upgrade Procedures 4.7.1
Upgrading a SecureSphere Management Server or Onebox
To upgrade a SecureSphere Management Server or Onebox: 1.
Login as root.
2.
Backup your SecureSphere Server. For more information, see Backing Up and Restoring the System on page 42.
3.
Back up your audit files.
4.
Download the upgrade RPM of the current release from the FTP server (see Obtaining the SecureSphere Software Packages on page 12) and copy it to /tmp.
Note: If your appliance has at least 4GB of RAM, you must upgrade to the 64-bit version of SecureSphere.
5.
If your appliance has a SAN device attached, proceed as follows:
Note: A SAN device is a dedicated network that provides access to consolidated, block level data storage, and is primarily used to make storage devices, such as disk arrays accessible to servers so that the devices appear to the OS as locally attached devices.
26
Version 10.0 Migration Guide
4. Upgrading from Version 7.0.0.7061 and Higher
5.1
Execute the following commands: impctl gateway stop umount /mnt/ where is your SAN mount name.
5.2
Open the bootstrap.xml file using a text editor.
5.3
Change the var-dir and audit-base-path parameters to point to /var/SecureSphere.
5.4
Save bootstrap.xml.
5.5
Disconnect the cable of the SAN device.
Warning: If you do not disconnect the cable, the reboot process will detect the SAN device and ask you whether to ignore the device or to format it. Do not format the SAN storage, because it contains data you want to keep.
6.
Install the package with the following command:
cd /tmp/ rpm -ivh /tmp/
Note: The file you should execute is one of the files listed in step 4 above, based on the amount of RAM you have.
Follow the instructions on the screen. 7.
Users can choose to first test the installation script by first running the test_install script. This means that all tests performed by the pre-install script will run whether or not there are warnings, and the script aborts before making any changes to the system. The user can then review the results.
Note: The test_install script stops the Management Server, and you must restart it after
the test_install script completes. To run the test_install script, execute the following commands: cd /var/SecureSphere/upgrades/upgrade-10.0.0._0./bin ./test_install You will be asked for the server and database passwords.
Note: If you are using an SSH client (for example, putty), it is recommended to change the keep alive time on the SSH client to 1, thus making sure to send NULL packets to keep session active. This is usually possible to tune under the connection menu in the SSH tool configuration properties.
Version 10.0 Migration Guide
27
Chapter 1 - SecureSphere Version 10.0 Migration Guide
The pre-install script checks some pre-requisites such as whether: •
the /var partition on the gateway contains at least 18 GB of free space if you are upgrading from version 7.0 or higher
•
no files have been changed (see Files on page 21).
If the script identifies any modified files, the following message is displayed: Install: ERROR: Manual changes have been detected in local files Additional information is displayed with the file name in which changes were detected. Differences are saved to [filename].diff in the backup directory (see Backup Directory on page 15). The message indicates that extra attention is needed. Please contact Imperva Support for further instructions. 8.
Execute the following commands:
cd /var/SecureSphere/upgrades/upgrade-10.0.0./bin ./install You will be asked for the following passwords: •
current server password
•
current database password
•
new root password
Warning: Do not press Ctrl-C at any point during the upgrade process.
Also, if the hostname is localhost, you will be asked to provide another name for the machine. If you do not provide another name, the hostname will be changed to “secure”. If you are upgrading from a SecureSphere version prior to 8.5, you will also be asked: •
to provide a Bootloader (GRUB) password
•
to define a new CLI user and provide a password
Note: Starting with version 10.0 the following special characters are supported in passwords: * ( ) - + = | # % ^ : / ~ . , [ _. This password policy is applied during the upgrade procedure and if an unsupported special character is identified, then the procedure is stopped.
Note: The following notes apply when you are upgrading from a SecureSphere version prior to 8.5: • To login to the appliance over SSH after upgrading, you must (by default) login as a CLI user (for example, as the CLI user you just created) and then switch to the admin user by entering the admin command. • By default, user root can login to the appliance only locally, not over SSH. However, you can specify an IP address from which user root is allowed to login over SSH using the following command: impctl hardening config --root-source-ip-exception=
The standard output of the install command is written to the screen and also to the file: /var/SecureSphere/upgrades/upgrade-10.0.0./bin/ Upgrade-10.0.0..log
28
Version 10.0 Migration Guide
4. Upgrading from Version 7.0.0.7061 and Higher
9.
Wait until the message that the system is going down for reboot appears. This may take some time, so please wait patiently. At this point, you can monitor the progress of the OS upgrade by using VNC (see Appendix A – Monitoring Installation Status with VNC on page 45) or wait until the SSH connection is reestablished.
10. When the OS installation is finished the system goes down for reboot. After reboot, connect to the appliance using SSH as user root. You are still able to login as root over SSH because the upgrade has not completed yet. Note: Because of the new hardening features in this version, to login as admin over SSH you must first login as a CLI user (for example, as the CLI user you just created) and then switch to the admin user by entering the admin command.
11. Check the upgrade log using the following commands: cd /var/SecureSphere/upgrades/upgrade-10.0.0./bin tail -f Upgrade-10.0.0.log 12. Wait until the following message appears. install: ################################################################################### install: ## install: ## The upgrade from version install: ## to version 10.0 is complete. install: ## install: ## Backup of some files can be found at var/SecureSphere/upgrades/upgrade10.0.0./backup. install: ## install: ## Please reboot the appliance. install: ## install: #########################################################################
Version 10.0 Migration Guide
29
Chapter 1 - SecureSphere Version 10.0 Migration Guide
This message indicates that the upgrade was successful. In this event, proceed as follows: 12.1
Reboot the appliance, as indicated in the message.
12.2
Connect to the appliance using SSH as the CLI user you defined earlier.
12.3
You will be asked to change the password.
12.4
The SSH session will be terminated.
12.5
Once again, connect to the appliance using SSH as the CLI user you defined earlier.
12.6
Enter the new password.
12.7
Enter the admin command to switch to the admin user using the CLI password.
12.8
Continue with step 14.
13. If instead of the message indicating that the upgrade was successful, you receive the following message, do not continue with the upgrade and contact Imperva Support for further instructions. install: ################################################################################### install: ## install: ## Warnings have been detected. install: ## Please contact support before continuing with the upgrade Process. install: ## install: ## The upgrade from version install: ## to version 10.0 has completed with warnings. install: ## install: ## Backup of some files can be found at var/SecureSphere/upgrades/upgrade10.0.0./backup. install: ## install: ## PLEASE DO NOT REBOOT THE APPLIANCE install: ## install: #########################################################################
Note: • If you receive any errors or warnings, contact Imperva Support. • Reboot and continue with the following steps only if the upgrade process completes without any warnings of manual changes in the system.
14. When mounts are used, re-mount all previously configured mounts. Follow the instructions in the relevant configuration guide. You must change the var-dir parameter in the bootstrap.xml file to point to the mounted directory where old_audit is located.
30
Version 10.0 Migration Guide
4. Upgrading from Version 7.0.0.7061 and Higher
15. If your appliance has a SAN device, proceed as follows: 15.1
Reconnect the cable you disconnected earlier.
15.2
If the directory /mnt/ does not exist, execute the following command: mkdir -p /mnt/ where is your SAN mount name.
15.3
Open the file /etc/fstab with a text editor (such as vi) and add the following line to the file: /dev/sdX
15.4
/mnt/external-storage
ext3
defaults
0 0
Confirm that the SAN device is mounted by executing the following commands: mount -a mount
15.5
Open the bootstrap.xml file using a text editor.
15.6
Change the var-dir and audit-base-path parameters to point to the external partition, for example, to /mnt/. Warning: Do not format the SAN storage, because it contains data you want to keep.
16. When the SecureSphere Management Server is started and its status is running, browse to: https://[Management Server IP address]:8083 17. Read the End User License Agreement (Figure 1) and click Accept.
Figure 1 End User License Agreement
Version 10.0 Migration Guide
31
Chapter 1 - SecureSphere Version 10.0 Migration Guide
18. Enter the password for the user “admin” (Figure 2).
Note: You may have several GUI users with administrative privileges, but the user whose password you should enter here is the one named “admin”.
Figure 2 admin Password
19. Confirm that you would like to upgrade from the previous version (Figure 3).
Figure 3 Confirm Upgrade
•
If you would like to upgrade click Yes.
•
If you choose not to upgrade, all previous data is lost.
In this step, the migrated profile that was copied into a temporary schema (secure_old) on the Management Server internal database is now copied to the secure schema. The following message appears once the upgrade is complete:
20. If the following message appears (Figure 4), do not continue but instead contact Imperva support for further instructions.
32
Version 10.0 Migration Guide
4. Upgrading from Version 7.0.0.7061 and Higher
Figure 4 Upgrade Failed
21. Login to the machine as admin. 22. Execute the following command: tail –n 200 /opt/SecureSphere/server/SecureSphereWork/logs/server_log.txt 23. Verify that there are no warnings that partial failure occurred. If any messages of partial failure appear in the file, contact Imperva Support. These messages are of the following form: ### UPGRADE STATUS: PARTIAL FAILURE - The system can be used, but a reconciliation process is required. Please save this upgrade log and contact support. ### 24. Examine the upgrade log file /var/SecureSphere/upgrades/mx_post_upgrade.log. If the patch installation was successful, the following message appears in the log, and you can continue to the next step: ############################################################################## ## ## Management server post upgrade operations completed successfully. ## Please proceed and reboot the appliance. ## ##############################################################################
If the installation was not successful, the following message appears in the log, and you should contact support before you continue: ############################################################################## ## ## Management server post upgrade operations failed. ## ## Please do NOT reboot the appliance and contact support. ## ##############################################################################
25. If no errors occurred, reboot the appliance.
Version 10.0 Migration Guide
33
Chapter 1 - SecureSphere Version 10.0 Migration Guide
26. Update the ADC content as follows: 26.1
Start the SecureSphere GUI.
26.2
Go to Admin > ADC.
26.3
Download the ADC content file from the Imperva web site.
26.4
Upload it to the system. Note: • If the gateway includes audit data, it is converted in the background. The Gateways tab in the GUI reflects the progress of this procedure.
4.7.1.1
OS Hardening
The appliance OS has been hardened so that by default, it is not possible to login to the appliance as the root user over SSH. To login to the appliance over SSH, you must (by default) login as a CLI user (for example, as the CLI user you created in step 8 of this procedure) and then switch to the admin user by entering the admin command. By default, user root can login to the appliance only locally, not over SSH. However, you can specify an IP address from which user root is allowed to login over SSH using the following command: impctl hardening config --root-source-ip-exception=
4.7.2
Upgrading a SecureSphere Gateway (not relevant to Onebox Deployment)
To upgrade a SecureSphere Gateway: 1.
Login as root.
2.
Download the upgrade RPM of the current release from the FTP server (see Obtaining the SecureSphere Software Packages on page 12) and copy it to /tmp.
Note: If your appliance has at least 4GB of RAM, you must upgrade to the 64-bit version of SecureSphere.
34
Version 10.0 Migration Guide
4. Upgrading from Version 7.0.0.7061 and Higher
3.
If your appliance has a SAN device attached, proceed as follows: 3.1
Execute the following commands: impctl gateway stop umount /mnt/ where is your SAN mount name.
3.2
Open the bootstrap.xml file using a text editor.
3.3
If either the var-dir or audit-base-path parameters point to the external partition (for example, to /mnt/ Processor.
4.
Press Return.
5.
Select and enable Core multi-processing.
4.8.2
Restore the Reverse Proxy Apache Configuration
To restore the Reverse Proxy Apache configuration: 1.
On the gateway, login as root after the SecureSphere Server is up.
2.
Using a text editor, open the /opt/SecureSphere/etc/bootstrap.xml file.
3.
Modify the listener port to the value defined before the upgrade.
4.
Save the file.
5.
Execute the following command:
impcfg 6. 7.
Modify the gateway’s mode to Reverse Proxy Apache. Define new aliases. The aliases replace the old configuration, which is lost during the upgrade process.
8.
Retrieve the previous configuration defined in httpd.conf from the backup directory (see Backup Directory on page 15).
9.
Edit the new httpd.conf file at /etc/httpd/conf/httpd.conf with the previous configuration.
Version 10.0 Migration Guide
39
Chapter 1 - SecureSphere Version 10.0 Migration Guide
10. Recreate routes as follows: 10.1
Log in to the gateway as user root.
10.2
Execute the following command:
impcfg
40
10.3
Navigate to Top > Gateway > Manage interfaces and routes > Manage reverse proxy (apache) routes
10.1
Define the static routes.
10.1
If VRRP is defined, you must associate the route with the virtual instance.
Version 10.0 Migration Guide
5. Patch Update
5.
Patch Update The installation file includes the latest patches, so there is no need to install a patch after the upgrade process.
Version 10.0 Migration Guide
41
Chapter 1 - SecureSphere Version 10.0 Migration Guide
6.
Backing Up and Restoring the System 6.1
Introduction Before running the upgrade process, backup the SecureSphere system. The backup process guarantees that the system can be restored, if needed. Save the backup file on another machine.
6.2
The Backup Process 6.2.1
SecureSphere 6.x and Higher
To backup your system in version 6.x and higher: 1.
Login to the Management Server as user root.
2.
Execute the following commands:
cd /tmp chmod 755 full_expimp.sh 3.
To start the full export/import utility, execute the following commands:
impctl server stop /full_expimp.sh 4.
To fully export the SecureSphere server for backup purposes, set the following parameters: 4.1
Operation: option - 1
4.2
Password: the password you chose for the system user in the first-time login.
4.3
Export Type: option - 1
5.
Enter a response (y or n) to the question: “Would you like to export failed archives data [y/n] (default is n)?”.
6.
Enter a name for the backup file or use the default name. Make sure to type a full path when not using the default, which is /var/tmp/SecureSphere_.tgz
7.
Enter Y to confirm the export action.
8.
Wait for the process to end. This may take some time when there is a large number of events to export. You can follow the log file created in the same directory as the backup file by using the tail command in a different shell. If the export was successful, you will see the following message at the end of the file:
full_expimp completed successfully on 9.
Save the backup file to an external location.
10. Restart the server using the following command: impctl server start
42
Version 10.0 Migration Guide
6. Backing Up and Restoring the System
11. Copy all the reports from /opt/SecureSphere/server/SecureSphere/jakarta-tomcat-secsph/webapps/ SecureSphere/WEB-INF/reptemp to a different machine for backup purposes.
Note: It is not possible to use the new full_expimp.sh utility to import data exported with the old expimp.sh utility.
6.2.2
Backup Audit Files
Backup audit files by archiving them to an external location. See SecureSphere User Guide for details on the exact operation steps. It is possible to back up the audit directory to an external location. If the gateway continues to audit, information collected after the directory was copied or information was archived is not backed up.
6.3
The Restore Process Obtain the installation CDs for the build corresponding to your backup data and install the SecureSphere system. To install SecureSphere from the black CDs (from scratch): 1.
Insert SecureSphere Disc#0 when connected to the appliance with a screen and keyboard.
2.
reboot the appliance.
3.
To start the installation, type install and press Enter.
4.
Insert SecureSphere Disc#1 when requested.
5.
Remove the CD and click Enter once, installation is completed.
6.
After the system reboots, login with the username secure.
7.
Follow the SecureSphere first-time login and configuration process as described in the Quick Start Guide of your appliance.
6.3.1
SecureSphere 7.x and Higher
After you install the system from scratch, you must restore the system from the backup dump file. To restore the system: 1.
Copy the exported dump file and the full_expimp.sh utility to /tmp
2.
Login to the Management Server as user root.
3.
Execute the following commands:.
impctl server stop cd /tmp chmod 755 full_expimp.sh 4.
To start the full export/import utility, execute the following command:.
./full_expimp.sh
Version 10.0 Migration Guide
43
Chapter 1 - SecureSphere Version 10.0 Migration Guide
5.
To fully import the SecureSphere server from a backup file, set the following parameters:
Note: If you are using an earlier version of full_expimp.sh, there will be a different set of parameters. If you need assistance, please contact Imperva support.
Parameter
Select
Select operation
2. Import
Please select operation to perform before the import
1: Drop target schema (if it exists)
Please select configuration files option
2. Copy configuration files during the import
Enter a file for the operation
Enter the name of the tgz file you want to import. Enter it with its full path that is, /tmp/SecureSphere_.tgz
Note: You will also have to enter two passwords, the system password and the secure user password.
6.
7.
Wait for the process to complete. This may take some time when there are a lot of events to import. You can follow the log file created in the same directory as the backup file by using the tail command in a different shell. When complete, start the server by executing the following command:
su secure start-server
Note: • Use only the full_expimp.sh utility to export or import your SecureSphere Server. • It is not possible to use the new full_expimp.sh utility to import data exported with the old expimp.sh utility. • If you import the dump file to another appliance, all SSL keys must be re-entered.
44
Version 10.0 Migration Guide
7. Appendix A – Monitoring Installation Status with VNC
7.
Appendix A – Monitoring Installation Status with VNC In release 8.0.0.8265, the SecureSphere operating system was upgraded to CentOS 5.4. (For more information, see The SecureSphere Operating System on page 14). Installing a new operating system may take some time. If the upgrade is done through a remote connection the users do not have visibility into the process and cannot watch the installation screens. To allow user visibility to the operating system installation process it is possible to connect to the upgraded appliance using VNC viewer software. The appliance and the VNC client must be on the same subnet. In order to connect to the machine with VNC, enter :1 in Server and install in password.
Figure 5 VNC Viewer
1.
Monitor the installation of the CentOS Operating System.
Figure 6 CentOS
2.
When the VNC connection is terminated, the system goes down for reboot.
3.
After the reboot, connect to the machine using SSH as user root.
4.
Continue the upgrade according to the instructions.
Version 10.0 Migration Guide
45
Chapter 1 - SecureSphere Version 10.0 Migration Guide
8.
Appendix B – Mounting a USB Key To mount a USB key: 1.
Insert a USB drive into the USB port in the front of the appliance.
2.
Login into the appliance as user root. If is done before the first time login, use the password webco123 if requested.
3.
Execute the following command:
mkdir /mnt/usb1 4.
Execute the following command:
mount /dev/sda1 /mnt/usb1 5.
To copy the file, execute the following command:
cp /mnt/usb1/ // 6.
To un-mount, execute the following command:
umount /dev/sda1
Note: /dev/* can be different based on hardware. For example with the SR1530CL platform: • step 4 should be "mount /dev/sdb1 /mnt/usb1" • step 6 should be "umount /dev/sdb1"
46
Version 10.0 Migration Guide
9. Appendix C - Configuring Apache Reverse Proxy
9.
Appendix C - Configuring Apache Reverse Proxy Read this section only if your deployment involves the use of Apache reverse Proxy (known as Apache Reverse Proxy mode) and your configuration uses encryption. Imperva SecureSphere includes and supports modes and operation modes that run under FIPS 140-2 Level 1 encryption algorithms. SecureSphere Apache reverse Proxy mode is included in the above support. With FIPS 140 support, the encryption module for httpd “mod_nss” replaces the “mod_ssl” that was used previously.
9.1
Uploading the Encryption Keys
Note: If you are not using SSL, start with 9.2.
To upload the encryption keys: 1.
Convert the OpenSSL key and certificate into a PKCS#12 file by executing the following command:
openssl pkcs12 -export -in /tmp/ -inkey /tmp/ –out /tmp/ -name -passout pass: Where: Parameter
Description
-export
Specifies that a PKCS#12 file is created
-in
The name of the file that contains certificates
-inkey
The name of the file that contains the private key
–out
The name of the file that will contain the PKCS#12 key
-name
The key name that must be the same as the name specified in the nss.conf file under the NSSNickname parameter.
-passout
The output key password
For example if source key file name is inputkey.pem and certificate file is input.cert the command is as follows: openssl pkcs12 -export -in /tmp/input.cert -inkey /tmp/inputkey.pem -out /tmp/ outputkey.p12 -name mykey -passout pass:1234 2.
Create an NSS database. You must specify the database directory.
certutil -N -d /etc/httpd/alias
Version 10.0 Migration Guide
47
Chapter 1 - SecureSphere Version 10.0 Migration Guide
Where: Parameter
Description
-N
Creates a new certificate database
-d
Cert database directory path that must be the same as the name specified in the nss.conf file under the NSSCertificateDatabase parameter.
3.
Enter a password or leave the text box empty. If you are adding a password, the password must contain at least 8 characters one of which should be a non-alphabetic character.
4.
Load the PKCS #12 file into your NSS database by executing the following command:
pk12util pk12util -i /tmp/ -d /etc/httpd/alias –W Where: Parameter
Description
-i
Imports files
-d
Cert database directory path that must be the same as the name specified in the nss.conf file under the NSSCertificateDatabase parameter.
Based on the above example it should be similar to: pk12util pk12util -i /tmp/outputkey.p12 -d /etc/httpd/alias –W 1234 You are asked to enter the certificate NSS DB password — see Uploading the Encryption Keys on page 47 - step 2 5.
Import the certificate of the CA server which issued the server certificate. This is used as local certificate authority. You do not need the key of the CA, just the certificate. Assuming you have its ASCII representation (e.g., a PEM file), you can load it as follows:
certutil -A -d /etc/httpd/alias/ -n "My Local CA" -t CT -i /tmp/ Where:
48
Parameter
Description
-A
Adds a certificate to the database
-d
Cert database directory path that must be the same as the name specified in the nss.conf file under the NSSCertificateDatabase parameter.
-n
The nickname of the certificate to add
-t
Sets the certificate trust attributes
-i
The BINARY certificate request file
Version 10.0 Migration Guide
9. Appendix C - Configuring Apache Reverse Proxy
For example, if your CA server certificate name is CAserver.cer the command should look like: certutil -A -d /etc/httpd/alias/ -n "My Local CA" -t CT -i /tmp/CAserver.cer 6.
When using FIPS, run the following additional steps: a.
Edit the file /etc/httpd/alias/phrases file. It should contain a single line:
NSS FIPS 140-2 Certificate DB: The password is the one you set in Uploading the Encryption Keys on page 47 - step 2 b.
Turn on the FIPS mode in the certificate database by executing the following command:
modutil –dbdir /etc/httpd/alias –fips true
Note: FIPS mode should be false if you change the NSS certificate DB settings.
This completes the first step of creating the certificate DB and uploading the keys to it. With the new ‘mod_nss’ module you can work either in FIPS mode enabled or disabled.
Note: The parameter NSSProxyProtocol may need to contain TLSv1. For example: NSSProxyProtocol SSLv3,TLSv1.
9.2
nss.conf and http.conf files The nss.conf and http.conf files are not carried over to their proper locations during the upgrade process, and you will have to manually copy them from the backup directory (see Backup Directory on page 15) after the upgrade has successfully completed. 1.
Copy the original httpd.conf file from the upgrade backup folder to /etc/httpd/conf
2.
Copy the original nss.conf file from the upgrade backup folder to /etc/httpd/conf.d
3.
Restart the httpd service by executing the following command:
service httpd restart 4.
To enable the HTTP service start after reboot, execute the following command:
chkconfig httpd on
Version 10.0 Migration Guide
49
Chapter 1 - SecureSphere Version 10.0 Migration Guide
10.
Appendix D - Enabling Activate Settings
10.1
Enabling the Activate Settings Option
1.
Wait for the SecureSphere Management Server to load. Actions must execute after the Management Server status is running.
2.
Login as root to the Management Server.
3.
Use a text editor to edit the configuration file. For example, enter the following command:
vi /opt/SecureSphere/server/SecureSphere/jakarta-tomcat-secsph/webapps/ SecureSphere/WEB-INF/bootstrap.properties 4.
Set the activate-settings.activation-mode attribute to OnActivateSettings
5.
Edit: activate-settings.activation-mode
6.
Pay attention to the spaces separating the attribute from its value.
7.
Restart the Management Server for changes to take effect.
10.2
=
OnActivateSettings
Applying Settings Which Have Not Yet Been Applied
To apply settings which have been configured and saved but not yet applied:
50
1.
In any SecureSphere window, click Activate. The Activate Settings window appears, displaying detailed information about all changes that have not yet been activated.
2.
In the Activate Settings window, click Activate. The Activate Settings window closes and the progress bar appears, indicating the status of activation.
3.
Click OK. All changes are applied.
Version 10.0 Migration Guide
11. Appendix E – Guidelines for MX-HA Upgrade
11.
Appendix E – Guidelines for MX-HA Upgrade This section describes the procedure for upgrading MX-HA configurations. 1.
On the primary server, uninstall MX-HA by executing the following command: impctl server ha uninstall
2.
After the previous step successfully completes (and not before!), perform the following actions on the secondary server: 2.1
Start the DB by executing the following command: impctl db start
2.2
Start the server by executing the following command: impctl server start
3.
Connect to the secondary Management Server using the web interface and upload the license.
Primary Server 4.
Upgrade to the new SecureSphere version by running the relevant RPM according to the instructions given earlier in this document.
Secondary Server 5.
Upgrade as follows: From Version 7.0 and below – Install the new SecureSphere version from scratch. Because this is the secondary server, it does not matter that the data will not be migrated, as all the data will be restored from the primary server. From Version 7.5 and higher – Either: •
Upgrade to the new SecureSphere version by running the relevant RPM, or
•
Install the new SecureSphere version from scratch. Because this is the secondary server, it does not matter that the data will not be migrated, as all the data will be restored from the primary server.
6.
Download new Oracle RPMs and prepare the servers by performing the following steps on both servers: 6.1
Create a new mxha directory by executing the following command: mkdir /var/tmp/mxha
Version 10.0 Migration Guide
51
Chapter 1 - SecureSphere Version 10.0 Migration Guide
6.2
From the Imperva FTP server, download the Oracle RPMs to the /var/tmp/mxha directory. There are two directories, one for 32 bit and the other for 64 bit. If your appliance has at least 4GB of RAM, download the 64-bit version of SecureSphere. Otherwise, download the 32-bit version.
File Name
Version
/Downloads/SecureSphere_Setup/v10.0/32Bit/MX-HA/
32-bit version
/Downloads/SecureSphere_Setup/v10.0/64Bit/MX-HA/
64-bit version
6.3
Execute the following command: impctl server ha preparerpm
7.
On both Management Servers, execute the following commands:
impctl hardening config --root-source-ip-exception= impctl hardening config --root-source-ip-exception= impctl hardening config --root-source-ip-exception=
where: •
is the floating IP address, that is, the IP address shared by both Management Servers.
•
is the IP address of the interconnect on the other Management Server; for example when you are running this command on the primary Management Server, specify the IP address of the interconnect on the secondary Management Server.
•
is the public IP address of the other Management Server; for example, when you are running this command on the primary Management Server, specify the public IP address of the secondary Management Server.
8.
Re-establish SSH trust for the root user and the oracle user.
9.
On the primary server, install MX-HA by executing the following command: impctl server ha install
10. After the previous step successfully completes (and not before!), upgrade the gateway.
52
Version 10.0 Migration Guide
12. Appendix F - Upgrade Procedure for the Kernel Reverse Proxy Configuration
12.
Appendix F - Upgrade Procedure for the Kernel Reverse Proxy Configuration To upgrade from SecureSphere version earlier than 9.0 to version 10.0 with the KRP configuration: 1.
Upgrade the MX, see Upgrading a SecureSphere Management Server or Onebox on page 26. After the MX upgrade, all KRP connections are terminated until the next steps are performed.
2.
Upgrade the Gateway, see Upgrading a SecureSphere Gateway (not relevant to Onebox Deployment) on page 34.
3.
Connect to the Gateway using SSH and copy CSV files located in: /var/SecureSphere/upgrades/upgrade-/backup/ReverseProxyData/ The CSV file contains the KRP configuration before upgrade.
4.
Review the Aliases CSV file to make sure there are no Aliases with the same external interface and IP address.
5.
To upload CSV files to the MX, click Setup > Gateways. The Gateways window appears.
6.
In case of VRRP configuration: a.
Select the relevant gateway and click IP Addresses from the Details pane. The IP Addresses table appears. b. In the IP Addresses table, click New. The IP Address window appears. c. From the Network Interface drop-down list, select the external interface that you want to use for this gateway. d. In the IP Address/Mask (CIDR) text box, type a static IP Adress for the external interface. e. Click Save. The IP Address dialog box closes. f. Click Close. The IP Addresses table closes. g. Select the relevant gateway and click Virtual Routers from the Details pane. The Virtual Routers table appears. h. In the Virtual Routers table, click Upload from CSV. The Upload Virtual Routers from CSV dialog box appears. i. Click Browse and locate the VRRP CSV file. j. In the Advanced tab, select Use first line as header and click Upload. k. Once the upload is successfully completed, click Close. The Upload Virtual Routers from CSV dialog box closes. l. Close the Virtual Routers table. m. Repeat steps a-k for another gateway that participates in the VRRP configuration. Make sure to define a static IP Address in the same subnet. 7.
In the Gateway window, select the relevant gateway and click Aliases in the Details pane. The Aliases table appears.
8.
In the Aliases table, click Upload from CSV. The Upload aliases from CSV progress box appears.
9.
Click Browse and locate the Alias CSV file.
10. In the Advanced tab, select Use first line as header and click Upload. 11. Once the upload is successfully completed, click Close. The Upload Aliases from CSV dialog box closes. 12. Close the Aliases table. 13. When using VRRP configuration, repeat steps 7-11 for the second Gateway.
Version 10.0 Migration Guide
53
Chapter 1 - SecureSphere Version 10.0 Migration Guide
Note: After uploading CSV files to the MX, new KRP xml configuration file will be downloaded to the GW and MX with GW will be in sync - terminated connections should become active again.
To upgrade from SecureSphere version 9.0 and later to version 10.0 with the KRP configuration: 1.
Upgrade the Gateway, see Upgrading a SecureSphere Gateway (not relevant to Onebox Deployment) on page 34.
2.
Upgrade the MX, see Upgrading a SecureSphere Management Server or Onebox on page 26. After the MX upgrade, all KRP connections are terminated until the next steps are performed.
Note: Once the Gateway is upgraded, the KRP configuration is read from bootstrap.xml and KRP in IMPCFG is disabled (Impossible to add new KRP aliases/routes/vrrp instances).
3.
Connect to the Gateway using SSH and copy CSV files located in: /var/SecureSphere/upgrades/upgrade-/backup/ReverseProxyData/ The CSV file contains the KRP configuration before upgrade.ile to make sure there are no Aliases with the same external interface and IP address.
4.
Review the Aliases CSV file to make sure there are no Aliases with the same external interface and IP address.
5.
Review the Routes CSV file to make sure there are no illigal Routes.
6.
To upload CSV files to the MX, click Setup > Gateways. The Gateways window appears.
7.
In case of VRRP configuration: a.
Select the relevant gateway and click IP Addresses from the Details pane. The IP Addresses table appears. b. In the IP Addresses table, click New. The IP Address window appears. c. From the Network Interface drop-down list, select the external interface that you want to use for this gateway. d. In the IP Address/Mask (CIDR) text box, type a static IP Adress for the external interface. e. Click Save. The IP Address dialog box closes. f. Click Close. The IP Addresses table closes. g. Select the relevant gateway and click Virtual Routers from the Details pane. The Virtual Routers table appears. h. In the Virtual Routers table, click Upload from CSV. The Upload Virtual Routers from CSV dialog box appears. i. Click Browse and locate the VRRP CSV file. j. In the Advanced tab, select Use first line as header and click Upload. k. Once the upload is successfully completed, click Close. The Upload Virtual Routers from CSV dialog box closes. l. Close the Virtual Routers table. m. Repeat steps a-k for another gateway that participates in the VRRP configuration. Make sure to define a static IP Address in the same subnet. 8.
In the Gateway window, select the relevant gateway and click Aliases in the Details pane. The Aliases table appears.
9.
In the Aliases table, click Upload from CSV. The Upload aliases from CSV progress box appears.
10. Click Browse and locate the Alias CSV file.
54
Version 10.0 Migration Guide
12. Appendix F - Upgrade Procedure for the Kernel Reverse Proxy Configuration
11. In the Advanced tab, select Use first line as header and click Upload. 12. Once the upload is successfully completed, click Close. The Upload Aliases from CSV dialog box closes. 13. Close the Aliases table. 14. In the Gateway window, select the relevant gateway and click Routes in the Details pane. The Routes table appears. 15. In the Routes table, click Upload from CSV. The Upload routes from CSV progress box appears. 16. Click Browse and locate the Routes CSV file. 17. In the Advanced tab, select Use first line as header and click Upload. 18. Once the upload is successfully completed, click Close. The Upload Routes from CSV dialog box closes. 19. Close the Routes table. 20. When using VRRP configuration, repeat steps 7-18 for the second Gateway.
Notes:
• •
After uploading CSV files to the MX, new KRP xml configuration file will be downloaded to the GW and MX with GW will be in sync - terminated connections should become active again. If static routes are configured outside of IMPCFG (Linux), you must reconfigure them after the upgrade.
To minimize Gateway down time: 1.
Disconnect the management link from the Gateway before the MX upgrade.
2.
Reconnect the management link after MX is upgraded and all the CSV files were uploaded to it. That way the first configuration deletes the existing KRP entries from the bootstrap and restores them in the new KRP xml configuration file.
To minimize down time of High Availability Gateway: 1.
Upgrade both Gateways, see Upgrading a SecureSphere Gateway (not relevant to Onebox Deployment) on page 34.
2.
Disconnect the management link from the backup Gateway.
3.
Upgrade the MX, see Upgrading a SecureSphere Management Server or Onebox on page 26.
Note: Once the MX is upgraded, KRP connections are terminated only on the main Gateway (the backup Gateway is disconnected from the MX), the traffic is directed to the backup Gateway.
4.
Select the relevant gateway and click Virtual Routers from the Details pane. The Virtual Routers table appears.
5.
In the Virtual Routers table, click Upload from CSV. The Upload Virtual Routers from CSV dialog box appears.
6.
In the Advanced tab, select Use first line as header and click Upload.
7.
Once the upload is successfully completed, click Close. The Upload Virtual Routers from CSV dialog box closes.
8.
Close the Virtual Routers table.
Version 10.0 Migration Guide
55
Chapter 1 - SecureSphere Version 10.0 Migration Guide
9.
In the Gateway window, select the relevant gateway and click Aliases in the Details pane. The Aliases table appears.
10. In the Aliases table, click Upload from CSV. The Upload aliases from CSV dialog box appears. 11. In the Advanced tab, select Use first line as header and click Upload. 12. Once the upload is successfully completed, click Close. The Upload Aliases from CSV dialog box closes. 13. Close the Aliases table. 14. In the Gateway window, select the relevant gateway and click Routes in the Details pane. The Routes table appears. 15. In the Routes table, click Upload from CSV. The Upload routes from CSV progress box appears. 16. Click Browse and locate the Routes CSV file. 17. In the Advanced tab, select Use first line as header and click Upload. 18. Once the upload is successfully completed, click Close. The Upload Routes from CSV dialog box closes. 19. Close the Routes table. 20. When using VRRP configuration, repeat steps 7-18 for the second Gateway. 21. Connect the management link on the backup Gateway.
56
Version 10.0 Migration Guide
13. Appendix G - SecureSphere Agent Upgrade
13.
Appendix G - SecureSphere Agent Upgrade Agents are upgraded separately from SecureSphere. SecureSphere version 8.0 and later can work with agent versions 8.0 and later.
13.1
Upgrading the SecureSphere Agents
Starting with SecureSphere 10.0, there is no need to uninstall the existing agent prior to installing a new agent. If you do not upgrade the agent, the agent with an earlier version will work, but without the new capabilities. To upgrade a Unix Agent: 1.
Install the new Remote Agent using the following upgrade parameters: •
to perform the upgrade, use -u
•
to start the agent after the upgrade, use -s
•
for SUSE: in addition to the instructions above, use the Supported kernel versions file, as explained in the Admin Guide.
To upgrade a Windows Agent: •
Install the agent without uninstalling the existing agent.
Version 10.0 Migration Guide
57
