Imperva-SecureSphere-10.0-Migration_Guide-v5.0.pdf

May 26, 2018 | Author: frankcoap666 | Category: Encryption, License, Confidentiality, Operating System, Command Line Interface
Share
Report this link


Comments



Description

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 This Agreement may not be assigned in whole or in part. requests. CA 94065. without the prior written consent of the other party. Open Source Software. This Agreement will be interpreted and construed in accordance with the laws of the State of California and the United States of America. A waiver of any breach under this Agreement shall not constitute a waiver or any other breach or future breaches. Redwood Shores. This consent terminates upon termination of the Agreement. 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. Open Source Software is copyrighted and licensed under the GPL/LGPL and other licenses. understandings and agreements. Notwithstanding the foregoing. if a separate. confirmation or similar document. End User Mention. In the event any provision of this Agreement shall be determined to be invalid or unenforceable under law. by operation of law or otherwise. such as use on Imperva's website. The parties hereby consent to the exclusive jurisdiction and venue of the state and federal courts located in San Francisco County. the terms of that written agreement (excluding any pre-printed terms of any Purchase Order. Last updated: May 10. Inc. its partners and suppliers harmless against any claims. 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. 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. End User agrees to indemnify and hold Imperva. losses or expenses arising out of End User's breach of this Agreement or use of the Products.represents and warrants that End User is not located in. 16. This Agreement may only be modified or waived in a written instrument signed by both parties. or a national or resident of any restricted country. 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. California for resolution of any disputes arising out or relating to this Agreement. United States.. Miscellaneous Provisions. 2011 . written and signed agreement for the license of the Products exists between End User and Imperva. All notices. provided that a party may freely assign this Agreement in connection with a merger. Copies of or references to those licenses are included with Software in the "Help" section. 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. without regard to conflict of law principles. either oral or written between the parties with respect to said subject matter.Open Source Software Request. 15. Imperva. End User consents to Imperva using its name and logo to identify End User as a customer of Imperva. under the control of. all of which will have no effect and will not be considered agreed to by Imperva) shall take precedence over this Agreement. by sending a money order or check for $10 to: Legal Department . 14. reorganization or reincorporation of such party with notice to the non-assigning party. representations. acquisition. return receipt requested or by any other means of delivery which generates a written receipt at the addresses set forth on the cover sheet. .............................................. 25 .................................................................................................................0 .......................................................................... 10 Intended Audience ............................. 15 Upgrading From Versions Prior to Version 9........................................................................................................................................ 12 Patches ............................................................................................................................................................................................................. 25 SSL Keys ...... 19 SharePoint ................................................................................................. 10 Reference Documents ............................................................................................................................................ 21 Gateway High Availability of Type STP ........................................................................ 22 Licenses ............ 21 Archive Settings ........................................................................................................................................................................................................................................................................................Keys ..................... 10 Scope ............................ 19 URL Patterns ................... 20 Routes ............ 22 KRP ................................................................................................................................................... 15 Before Starting the Upgrade Procedure ........................... 15 Upgrade Sequence ........................................................................................................................................................... 12 Upgrades and Patches ................. 15 Upgrading from SecureSphere Standard Edition ....................................... 20 MySQL ....................... 15 Upgrading SOM ...... 19 Non-Admin CLI Users ................................................................................... 22 Activate Settings .................................................................................................................................................................................................................. 10 Assumptions ...................................................................... 22 Version 7.................................................................................................................................................................................................................................................... 12 Estimated Migration Time ....................................................................................................................................................................................................................................................... 22 nCipher NetHSM ....................................... 24 ARP (Apache Reverse Proxy) ......................... 12 Obtaining the SecureSphere Software Packages .......................................... 20 NTP .................................................Onboard Interface ........................ 21 File .................. 20 Audit Policies ............5 Remote Agents .............................................................................................................................................................................................................................................. 19 Plugins .................................................................................................................................................................................................................................................................................................................. 14 Upgrading from Version 7......................................................................................................... 21 Discovery Results ..................................................................................................................... 16 Limitations ............................ 22 nCipher Card ....................What to Upgrade First ................................................................................................................................................................................................... 22 Gateway Groups ......................... 20 DNS Settings .................................................................................................................. 10 Document Conventions .......................................................................................................................................................................................................0........................................................................................ 25 SecureSphere / VM ............................ 21 System Events Archiving ................................................................................... 21 Files .......................................... 12 Upgrading ....................................................................... 25 SNMP ....................................................................... 15 Upgrading From Version 9.....................................Archive Enabled ............................... 25 Host Names ....................... 13 The SecureSphere Operating System...................................................7061 and Higher .............................................................................................................. 25 Log Collector ..................................................................................................................................................... 23 SafeNet LunaSA .................................................0 and Later ..................................... 11 Introduction ........................................................................................................................................0............................................................................................................................................................................................................................................................................................................................... 20 SSH Keys ..........................................................................................barshrc ........................ 21 IP Rules .......................... 10 Imperva Support ....................................... 15 Backup Directory ....................................................Table of Contents About This Document .................................................................................. 20 Connectivity to the Protected Servers ..................................................................................... 12 How to Use this Document ......................... 19 Action Sets ........................................................................................................................................... .............................................................................................................. 46 Appendix C ..................................................................................................... 39 Enable Dual-core on Aspen-Hill Appliances ......................................... 41 Backing Up and Restoring the System ... 25 Hard Disk Identifier .. 57 Upgrading the SecureSphere Agents ............................................................................................................. 45 Appendix B – Mounting a USB Key .............................................................. 25 Learning Statistics ................................................................................................................ 50 Applying Settings Which Have Not Yet Been Applied ........Upgrade Procedure for the Kernel Reverse Proxy Configuration ............................... 42 Backup Audit Files .. 39 Restore the Reverse Proxy Apache Configuration ............................................................... 25 Behavioral Changes ...................................................................................................................................................................... 53 Appendix G ......................................... 43 The Restore Process .......................................................................... 43 SecureSphere 7............................................................................................................... 26 Upgrade Procedures ............................................................ 25 Revoking Permissions on File URM Scan ..........................Enabling Activate Settings............................................................. 34 Post Upgrade Procedures ..................................... 26 Synchronizing with Active Directory Users before File/SharePoint URM Scan ...........................................................................................................conf and http............................. 42 SecureSphere 6.......................................................................................... 26 Upgrading a SecureSphere Management Server or Onebox .................................................................................................................. 50 Appendix E – Guidelines for MX-HA Upgrade........................................ 25 Revoking Permissions on SharePoint URM Scan ......................................... 26 Static URL Profiling ........ 26 Upgrading a SecureSphere Gateway (not relevant to Onebox Deployment) ............... 42 The Backup Process ................................................................................................................................Configuring Apache Reverse Proxy........................................................................................................................................................................................................................................................................................Table of Contents Read-Only User .............................................................................................................. 49 Appendix D .conf files .................................................................................. 43 Appendix A – Monitoring Installation Status with VNC ................................. 50 Enabling the Activate Settings Option ..........................SecureSphere Agent Upgrade..................................................... 39 Patch Update .......................................................................0 Migration Guide ..................................................................................... 51 Appendix F .................x and Higher ......... 47 nss.. 57 8 SecureSphere Version 10.................................................................................................................... 25 Execution History ........................................................ 47 Uploading the Encryption Keys ............................................................................................................................................. 42 Introduction ...x and Higher ....................................... SecureSphere Agent Upgrade on page 57 .0.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 .Configuring Apache Reverse Proxy on page 47 • Appendix D .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. 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 . com/services/support.html. • Deployment Guides These deployment guides are intended for use during the first month after installation.imperva.1 Scope This Migration Guide comprises full explanations of the migration process to SecureSphere version 10.3 Assumptions The document assumes basic understanding of system administration and knowledge of how to operate the SecureSphere system. Note: This Migration Guide describes how to upgrade from an appliance on which the First Time Login has already been successfully completed. 1. you do not need this Migration Guide in this case. 1. 10 Version 10. This document can also be used as reference to the migration conversion rules from previous versions of SecureSphere. 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. If you are installing SecureSphere version 10.2 Intended Audience This document is intended for administrators setting up and provisioning the SecureSphere system.0 on an appliance on which an earlier version is installed but the First Time Login has never been run. All communication methods are detailed at www.Chapter 1 .x and higher. together with short reminders of the relevant concepts. then simply install the new version and run the First Time Login.0 from SecureSphere version 7. The document details the specific tasks involved in the migration process.0 Migration Guide .SecureSphere Version 10.4 Reference Documents • SecureSphere User Manual The User Manual documents tasks for administering the domain protected by the SecureSphere system. email or using the self service portal. 1. 1. Full explanations are covered in the Reference Manual. About This Document 1. • SecureSphere Administration Manual The Administration Manual documents only tasks for administering SecureSphere.0 Migration Guide 1.5 Imperva Support Imperva Technical Support can be contacted by telephone. 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.1. About This Document 1. and for file names.0 Migration Guide 11 . cd /tmp | separates optional values in lists oranges | apples <> indicates a placeholder which must be replaced with a relevant value <the name of the file> [] indicates a placeholder which must be replaced with a relevant value [the name of the file] Version 10. 0.7061 and higher 2.0.0 Migration Guide . you must install the latest patch to your current version. Introduction 2.0.0.<patch_number>_0.0.0.rpm SecureSphere 10. 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.<build_number>x86_64-noarch. 12 Version 10.0/ There are two directories.<patch_number>_0. so there is no need to install a patch after the upgrade process.0. you must upgrade to the 64-bit version of SecureSphere.4 File Name Version 32Bit/upgrade-10.0 Migration Guide 2.0. Note: If your appliance has at least 4GB of RAM.2 Upgrading The following table describes the upgrade path.3 Upgrade Path • Upgrade directly to this version. as described in Upgrading from Version 7.1. Version from which you are upgrading 7. The installation file includes the latest patches.rpm SecureSphere 10.SecureSphere Version 10.1 Upgrades and Patches 2.7061 and Higher on page 15.Chapter 1 .1 Patches Before starting the upgrade process. which depends on the SecureSphere version from which you are upgrading.0 32-bit version 64Bit/upgrade-10. with migrations of extremely large amounts of data or migrations in high-load environments sometimes taking as long as 5 hours. one for 32 bit and the other for 64 bit. 2. Obtaining the SecureSphere Software Packages The SecureSphere upgrade software packages are on the FTP server at: /Downloads/SecureSphere_Upgrades/V10. . and each directory contains one package.0 64-bit version Estimated Migration Time Experience has shown that the average migration takes about 2 hours. 2.<build_number>i686-noarch. 2. Version 10. 3. archive all audit information.2. Upgrade your system. When used.0 Migration Guide 13 . Introduction 2. perform the following: 1. Read carefully all the prerequisites and limitations.5 How to Use this Document To successfully upgrade previous versions of the SecureSphere system to the current version. Backup your system for rollback purposes. 4. as well as performance improvement. CentOS 5. as have all versions of SecureSphere beginning with build 8. • Ability to integrate with 3rd party products. • The backup directory is: /var/SecureSphere/upgrades/upgrade-10.8265. It is your responsibility to edit the newlyinstalled system file and modify it accordingly.0.0 Migration Guide . Note: • If you have modified any system files (such as hades.4 will be installed from scratch.<BUILD_NUM>/backup 14 Version 10.SecureSphere Version 10.0 Migration Guide 3.0.0.Chapter 1 . such as mother-boards and network cards. the modified file (the file from before the upgrade) will be saved in the backup directory.4.0.cfg). • Improved management: The new operating system provides better memory and disk management. Whenever you upgrade to this version of SecureSphere. The SecureSphere Operating System This version of SecureSphere uses an OS based on CentOS 5. The motivation in upgrading SecureSphere to this OS was: • Hardware Support: The previous operating system did not support several of the new hardware components.<PATCH_NUM>_0. Whether you are upgrading from Standard Edition or Enterprise Edition. then you may receive a warning message that the Gateway has reverted to the last known configuration. the Gateways should be running with last known good configuration until they are upgraded and receive the new configuration from the Management Server. it must register with the Management Server. If you upgrade the Gateway first.<BUILD_NUM>/backup 4.5 p3. Version 10. first upgrade the SecureSphere Management Server. The reason is that when the SecureSphere Gateway is installed. After the Management Server is running with the newer version. which are enforced by your license. you will still have the same capabilities as you had earlier.What to Upgrade First 4.0. the correct upgrade sequence is as follows: 1.0 and Later When you are upgrading SecureSphere Server and SecureSphere Gateway separately from version 9.<PATCH_NUM>_0.7061 and Higher 4.0. There is now only one version.1 Upgrading from SecureSphere Standard Edition There no longer are two version of SecureSphere: Standard Edition and Enterprise Edition.0 and later Management Server. Gateways 2.3 Upgrading SOM When upgrading a SOM configuration.3. This is because the 9. Once the upgrade of the SecureSphere Management Server is completed.2 Backup Directory In the course of the upgrade to the new version. so the Management Server must already be available and running.0 Migration Guide 15 .7061 and Higher 4.0.0 When upgrading SecureSphere Server and SecureSphere Gateway separately from versions prior to version 9. 4. Management Servers Note: SOM-MX backward compatibility requires SOM 10. SOM 3. Upgrading from Version 7.3 Upgrade Sequence . 4. SecureSphere saves the configuration files from the previous version in the following directory: /var/SecureSphere/upgrades/upgrade-10.5 and later Gateway can work with 9.3.0 and later.1 Upgrading From Versions Prior to Version 9.0 and MX 9.0.4. follow the instructions given in this documents.3.0. If you previously had Standard Edition. you should upgrade the Gateway first. upgrade the Gateway. You can then upgrade the Management Server at your convenience.0. In this case. upgrade the Management Server and restart the Gateway. Upgrading from Version 7.2 Upgrading From Version 9.0. 4. and document the parameter settings. apply all settings which have been made to SecureSphere but not yet applied. 3 4 16 To determine the patch you are using. 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. even if the device is stolen. Notify the Imperva Support Team before upgrading your system.SecureSphere Version 10. 2 If you are not working in immediate activation mode. The SecureSphere version number is displayed in the status bar (on the right side) in the SecureSphere GUI. Hardware Security Module devices (HSMs) are specialized external hardware devices which store private encryption keys in specialized key storage devices. are available on the SecureSphere support site. 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. They protect the key information by making it impossible to gain access to the keys.0 Migration Guide .0 Migration Guide 4.4 Before Starting the Upgrade Procedure Before you start the upgrade procedure. For more information about how to restore the configuration. perform the following actions: Upgrade Task Checklist Step V Action Description 1 Notify Imperva support. as well as instructions for installing the patch (in the Patch Change Log). For more information. Version 10. see nCipher NetHSM on page 23. For more information about nCipher. If you are using nCipher netHSM. backup its configuration. See the “nCipher HSM Installation” section in the SecureSphere Administration Guide for information on nCipher netHSM. see Applying Settings Which Have Not Yet Been Applied on page 50 “Activating Settings” in the “Basic Configuration” chapter of the SecureSphere User Guide.Chapter 1 . see the nCipher documentation. Install the latest patch to the SecureSphere version you are running. You will have to partially reconfigure the nCipher configuration. 9 Make sure you know the SecureSphere GUI admin password (for the user “admin”). If you are using SafeNet LunaSA. backup its configuration. backup its configuration (the directory /opt/nfast/kmdata/ local to an external storage device). 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. It is strongly recommended that you archive audit data before upgrading. archive and backup the audit data. Version 10. For more information about how to restore the nCipher card configuration.0.0. and document the parameter settings. 8 Backup your system. Instructions about how to do this are given later in this procedure. For more information about nCipher.7061 and Higher Upgrade Task Checklist (cont. For more information about SafeNet LunaSA. At a later point in the upgrade process. See the “SafeNet LunaSA” section in the SecureSphere Administration Guide for information on SafeNet LunaSA. This step is required because the nCipher card configuration is not carried over to the upgraded configuration.4. since in some cases audit data can be lost during the upgrade process. 10 If you have audit data. see the SafeNet LunaSA documentation. Hardware Security Module devices (HSMs) are specialized external hardware devices which store private encryption keys in specialized key storage devices. 7 If you are using a SAN device. see the nCipher documentation. block level data storage. This step is required because the SafeNet Luna configuration is not carried over to the upgraded configuration. you will need to login to the SecureSphere GUI. Upgrading from Version 7. For more information. even if the device is stolen. For more information about how to restore the SafeNet LunaSA configuration. even if the device is stolen. For more information. you will have to unmount and disconnect the device during the upgrade. see See the “nCipher HSM Installation” section in the SecureSphere Administration Guide for information on the nCipher card. They protect the key information by making it impossible to gain access to the keys. and document the parameter settings. You will have to partially reconfigure the SafeNet Luna configuration. Description Hardware Security Module devices (HSMs) are specialized external hardware devices which store private encryption keys in specialized key storage devices. Backing Up and Restoring the System on page 42 17 . see SafeNet LunaSA on page 24. see the documentation for your SAN device. They protect the key information by making it impossible to gain access to the keys. see nCipher Card on page 22.) Step 5 6 V Action If you are using nCipher card.0 Migration Guide A SAN device is a dedicated network that provides access to consolidated. However.Chapter 1 .SecureSphere Version 10. 12 If you have configured mounts in your system. By default.. verify that the /var partition has at least 18GB of free space. To check available disk space under the /var partition. you can bypass the disk space check in the upgrade validation script by using the force_install option.0 Migration Guide . This partition is used to hold the audit records. Version 10. etc. This partition is used to backup the system configuration dump file. Use the force_install option only after consulting with support. you should not use the force_install option unless you verify with support that there is enough space to continue with the upgrade.0 Migration Guide Upgrade Task Checklist (cont. etc.) Step Action Description 11 If you store your audit files on externally mounted devices. then un-mount all the mounted devices. verify that the /var partition has at least 18 GB of free space if you are upgrading from version 7. Note: When upgrading SecureSphere running on appliances with a hard disk size of 37GB. The check install script will fail if there is not enough free space.0 or higher For more information. the upgrade script keeps a back up of the audit information until audit upgrade successfully completes. This action ensures that your existing audit files will not be over-written by the upgrade process.0 or higher. 14 15 18 V On a Management Server. see This step ensures that the appliance will not attempt to boot from the removeable media. only 18 GB of free space is needed. contact the Imperva Support Team. If the force_install option is used. rename the audit directory on the external device to “old_audit”. reports. If you are upgrading from version 7. Each original file that is successfully upgraded is deleted. On a Gateway. 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. 13 Disable all removable media such as USB drives. a backup of the audit files is not kept. You must backup these scripts before performing the upgrade and restore them after the upgrade is complete. If there is more than one plugin defined for the same service.5. review the list of plugins for each service to confirm that they are being executed in the order you want them to execute. while in earlier versions. 4. the order was implicit. and you will have to manually restore them.5. back it up. 19 Backup OS scripts used in action interfaces of type “OS command”. the Learning State of URL patterns is changed to “In Learning”. and you will have to manually restore it.4 URL Patterns When migrating from version 7.2 Plugins The order of execution of plugins can be explicitly specified in version 9. backup the This file is not migrated to the new configuration. and you will have to manually restore it. so after the upgrade.) Step 16 17 V Action Description This file contains information about ARP settings. 4.5. and you will have to manually restore them. If you have modified the etc/rc. IP routes. 4.5 For more information.0.local file. OS scripts used in action interfaces of type “OS command” do not survive the upgrade. Version 10.” 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. the implicit order of earlier versions is not always maintained in the migration to version 9.7061 and Higher Upgrade Task Checklist (cont.0. This file is not migrated to the new configuration.5. .0 Migration Guide 19 .5. Upgrading from Version 7.3 Non-Admin CLI Users When a non-admin CLI user logs into the appliance using SSH after the upgrade to version 10. These files are not migrated to the new configuration. 4.barshrc file. 18 Backup the CA and server keys.1 1. and IP rules. Action Sets When migrating an action set with an action interface of type “Assignment Task” and/or of type “Review Task. see IP Rules on page 21 File .4.0.5. he will be asked for his password and then will immediately be asked to change his password.0. If you are using the bash shell. 2.. These scripts are not migrated to the new configuration.barshrc on page 22 Limitations 4. 4. depending on the gateway’s mode: • Transparent Reverse Proxy/Kernel Reverse Proxy/Apache Reverse Proxy: The connectivity is lost during the upgrade process.5. • STP/IMPVHA Bridge: The connectivity depends on the fail mode configuration.0 to version 9. You must then re-apply scans to the newly-defined services and applications. 4. However. 4.5 SharePoint The SharePoint service and the applications (URL groups) defined under it do not survive the upgrade from version 9.0 using the latest patch (patch 28).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. new SSH keys are generated.5. • Sniffing: Connectivity to the protected servers is not affected when running the SecureSphere Gateway in the Sniffing mode. the network card creates a bypass and the connectivity remains. To automatically re-define them. The service and the applications (URL groups) remain in the site tree after the upgrade. right-click the SharePoint service in the site tree and select Auto-Discover Applications. Afterwards. the Archive Enabled parameter is not available for Audit Policies.7 NTP If you have an NTP server configured.8 Audit Policies . check if the file etc/resolv.Chapter 1 .5. the configuration will not be migrated and you will have to reconfigure the NTP after the upgrade is complete. Instructions for doing this are in the “Basic Configuration” chapter of the SecureSphere User Guide. You must manually delete them.5. The message is displayed only once after the upgrade.0 Migration Guide 4. the connectivity is lost. They are restored only at the end of the upgrade process. 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.5.SecureSphere Version 10. you do not have to manually re-define them.0.9 SSH Keys After upgrading the SecureSphere system.conf is not empty. If the fail mode configuration is set to fail open. When upgrading from SecureSphere 7.5. 20 Version 10. connectivity to the protected servers may be lost. 4. If the file is empty. If the fail mode configuration is set to fail close. you need to reconfigure the DNS settings. so upgrading to version 10. when the user tries to SSH to the appliance for the first time.5.5. a warning is displayed to the client that the signature has changed. 4.0 removes this parameter from Audit Policies Configuration reports.Archive Enabled In version SecureSphere 10. but they cannot be used. Therefore. you can use the File Explorer.10 Connectivity to the Protected Servers During the upgrade process.0 Migration Guide . 4.11 DNS Settings DNS settings are saved before the upgrade process begins. so during the upgrade process DNS settings are unavailable and connectivity may be temporarily lost. 0. Older system events are deleted without being purged.0. IP routes. the gateway high availability mode of type STP will be displayed as “off” in impcfg. 4.5. the last 100. the modified system files (the files from before the upgrade) can be found in the following directory: /var/SecureSphere/upgrades/upgrade-10.cfg 4.<BUILD_NUM>/backup 4. Any system event beyond 100.sh /opt/SecureSphere/etc/hades.12 Routes During the upgrade process. a message is displayed and the modified file (the file from before the upgrade) is saved in the backup directory. The files can be viewed after the upgrade process completion at: /var/SecureSphere/upgrades/upgrade-10. by default.000 is purged and not archived. Upgrading from Version 7. This behavior occurs since the HA attribute was not present in impcfg before this build. You can configure archiving for the system events or even change the number of events kept. are not migrated.0. Effectively.000 most recent system events survive the upgrade. 4.0 stores.5.d/rc. It is your responsibility to edit the newly-installed system file and modify it accordingly. and IP rules. go to Admin > Maintenance > System Event Archiving. the gateway high availability mode remains as it was before migration.5. however if no archive location is defined any event beyond the last 100.14 Gateway High Availability of Type STP After upgrading. Warning: Since routes are removed during the upgrade process. 4.16 System Events Archiving Only the 100. To control the settings after upgrading.local /opt/SecureSphere/etc/impctl/lib/keepalived. Manual configuration is required after completing of the upgrade process.cfg. Version 10.7061 and Higher 4. Version 10.conf /etc/rc.0 Migration Guide 21 .4. connectivity to the appliance may be lost during part of the process.17 Archive Settings The default and user-defined archive name templates are reset to the new format. Users should manually turn high availability on after re-registration of the gateway.000 is purged nightly.5.5.local to configure ARP settings.5. Instead.<BUILD_NUM>/backup The files are: /etc/httpd/conf/httpd. The new static routes should be configured from impcfg. the routes are restored. 4.000 system events.13 IP Rules Manual changes to /etc/rc. the SecureSphere system maintains all routes defined internally.0.0.15 Files Before the migration process. all the manually defined routes are identified. the upgrade script verifies that no changes have been made to /opt/SecureSphere/etc/hades.<PATCH_NUM>_0. When the upgrade process completes.<PATCH_NUM>_0. Files containing static routes changes are not migrated. If the file has been changed. After the upgrade process completes.5.18 Discovery Results Existing discovery results are deleted.0. 21 Version 7. 4. In order to use Activate Settings.5 remote agents must be restarted in order to communicate with the upgraded gateway.5.barshrc The . You only need to perform the procedure below.5.24 KRP .5. Next. Confirm that you have backed up the nCipher card’s configuration (the directory /opt/nfast/kmdata/local to an external storage device).25 nCipher Card Note: This section is relevant to SecureSphere Gateways only.0 Migration Guide . the gateway may be moved out of the group during the upgrade process. Next.5 Remote Agents After upgrading a VM gateway. 4. version 7.5. Referring to the procedure “nCipher Card” in the “Add-On” Appendix in the SecureSphere Administration Guide. 22 2. because only the SecureSphere Gateway has to be reconfigured. 4.22 Activate Settings After the migration process. 4. perform the steps in the “Verifying the Installation” section.SecureSphere Version 10.19 File . 4. perform the steps in the “Installing the nCipher Card Driver” section.5. you must enable it first. 3. you must use the force_install option. The nCipher card configuration is not completely carried over to the upgraded configuration. You do not have to do everything described in that appendix.23 Gateway Groups If a gateway group contains more than one gateway. the Activate Settings feature is disabled. See the “nCipher Card Installation” section in the “Add Ons” appendix of the SecureSphere Administration Guide for more information.Onboard Interface G series appliances: The onboard interface cannot be used in a KRP (Kernel Reverse Proxy) configuration. You will have to partially reconfigure the nCipher card configuration. 4.Chapter 1 . The user must manually return the gateway to the gateway group after the upgrade is complete.20 Licenses If both a commercial and later evaluation license are present. Version 10. To reconfigure the nCipher card after the upgrade: 1. so it must be recreated inafter the upgrade.5. perform steps 1-3 in the “Security World Initialization” section. For information on how to do this. 4. and Block on Overload is checked under Overload Policy (under Topology Configuration in the Gateway Group Details pane).barshrc file is not migrated. Note: The section Before Starting the Upgrade Procedure on page 16 instructed you to do this.0 Migration Guide 4.5. see Enabling the Activate Settings Option on page 50. 0.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. You only need to perform the procedure below.4. 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 .2 Perform this step.26 nCipher NetHSM Note: This section is relevant to SecureSphere Gateways only. 23 .0 Migration Guide Step Action 1 Verify that this is still correct. Upgrading from Version 7. You do not have to do everything described in that appendix. 2 Verify that this is still correct. because only the SecureSphere Gateway has to be reconfigured. 4 Perform this step. Card reading complete.3 When you are asked to do so..3 Perform this step. instead of steps 4-6 in the “Security World Initialization” section. perform the following steps: Version 10.5.. insert the SmartCard into the nCipher reader. 5.7061 and Higher 5. The output should resemble the following: Checking modules and reading cards .1 There is no need to perform this step. 5. 5..2 Execute the following command: /opt/nfast/bin/new-world --program -m1 5. 3 Perform this step. 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. 6. Continue the Security World Initialization from step 7. do the following: 5.0.. Next. 4. You will have to partially reconfigure the nCipher card configuration. 6 Verify that this is still correct. The nCipher netHSM configuration is not completely carried over to the upgraded configuration. See the “nCipher netHSM Installation” section in the “Add Ons” appendix of the SecureSphere Administration Guide for more information. because only the SecureSphere Gateway has to be reconfigured.0 Migration Guide 4. as described in the “Edit /etc/Chrystoki. 5. as described in the “Assign a Client (SecureSphere Gateway) to a LunaSA HSM Partition” section in the SecureSphere Administration Guide. SafeNet LunaSA Note: This section is relevant to SecureSphere Gateways only. 1. Connect to LunaSA using the following command: ssh admin@<LunaSA IP> 2. 8. The SafeNet LunaSA configuration is not completely carried over to the upgraded configuration.5. 8 There is no need to perform this step. See the “LunaSA Software Installation” section in the “Add Ons” appendix of the SecureSphere Administration Guide for more information. Delete the old client from the client list using the following command: client delete -client <clientname> 3. as described in the “Check the Network Connection Between the SecureSphere Gateway and LunaSA” section in the SecureSphere Administration Guide. Edit the /etc/Chrystoki. You do not have to do everything described in that appendix.0 Migration Guide . as described in the “Establish NTL Between the SecureSphere Gateway and LunaSA” section in the SecureSphere Administration Guide. 7. You only need to perform the procedure below.SecureSphere Version 10. 6. Establish NTL between the SecureSphere Gateway and LunaSA. Version 10. Check the connectivity between the SecureSphere Gateway and the HSM. You will have to partially reconfigure the SafeNet LunaSA configuration. 24 4.conf” section in the SecureSphere Administration Guide.Chapter 1 .conf file.27 Step Action 7 There is no need to perform this step. Install the LunaSA Package on the Gateway. as described in the “LunaSA Software Installation” section in the SecureSphere Administration Guide. Assign a client (SecureSphere Gateway) to a LunaSA HSM partition. 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. conf file and CA and server keys are not carried over to the upgraded configuration.0. 4.5.6.5 and was re-created in version 10.5.3 Revoking Permissions on SharePoint URM Scan When upgrading from 9. the Read-Only User setting is not migrated. a learned host with a space in its name is not migrated.31 Host Names In a Web profile.0: After the upgrade. the Gateway and MX may no longer be able to communicate.0 Migration Guide 25 .6 Behavioral Changes 4.0. first run application discovery on the SharePoint service and only then revoke permissions on URM scan.Configuring Apache Reverse Proxy on page 47. This option was removed in versions 9.6. After an upgrade.5. 4. even though these fields are displayed for SSL keys created in this version. 4. un-register the Gateway from the MX and then register it again.5 or earlier to version 10. 4.0 and 9. as described in the “Restart the SecureSphere Gateway” section in the SecureSphere Administration Guide.6. Upgrading from Version 7.1 Hard Disk Identifier Hard disks previously identified as HDE and HDA are identified as SDA after the upgrade.5. 4. but their expiration date and other fields not displayed in earlier versions of the SecureSphere are not displayed in this version either. For more information.5.33 SNMP The default SNMP setting for SecureSphere is off. The limitation is that when upgrading from version 8. see Appendix C .Keys The nss.5 and earlier it was possible to set a user as a read-only (in Admin > Users and Permissions > Users & Roles).5. only the last week executions history is kept and the rest is deleted. 4. 10.7061 and Higher 9. If this happens. 4. Version 10. 4.29 Log Collector The Log Collector password does not survive the upgrade and must be reconfigured. 4. so if you had SNMP enabled. You cannot revoke permissions on the pre-upgrade data.5.0. Restart the SecureSphere Gateway. 4. you will have to re-enable it after upgrading.28 ARP (Apache Reverse Proxy) . 4.34 Read-Only User In version 8.35 Execution History In Admin > Jobs Status > Execution History: The Execution History tab contains information about all the previous executions of the specific job.30 SSL Keys Existing SSL keys are migrated.5.4.0. These older SSL keys will not be automatically deleted based on their expiration dates (as defined in Admin > System Definitions > SSL Certificate Expiration Monitoring). Test the SSL connection.2 Learning Statistics Learning statistics in the profile overview are reset to zero after the upgrade.32 SecureSphere / VM After upgrading SecureSphere on VM. Note: If your appliance has at least 4GB of RAM. proceed as follows: Note: A SAN device is a dedicated network that provides access to consolidated. 4. Back up your audit files.6.9. For more information.Chapter 1 . see Backing Up and Restoring the System on page 42.0 Migration Guide When upgrading from 9. follow the instructions in the Configuring Active Directory Integration for Data Enrichment section in the File/ SharePoint Security User Guide. Login as root.SecureSphere Version 10.7. see the article in the Customer Portal titled StaticURLs-How-to-Enable-Static-URL-Profiling-inSecureSphere-v10-0.4 Revoking Permissions on File URM Scan When upgrading to 10. block level data storage. you must upgrade to the 64-bit version of SecureSphere. 4.0: After the upgrade you need to make sure Active Directory data is contained in the Windows Domains global object.0 . such as disk arrays accessible to servers so that the devices appear to the OS as locally attached devices. Backup your SecureSphere Server.5 Synchronizing with Active Directory Users before File/SharePoint URM Scan When upgrading to 10.0: After the upgrade you can revoke permissions on file URM scans. 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.1 Upgrading a SecureSphere Management Server or Onebox To upgrade a SecureSphere Management Server or Onebox: 1. 3. 26 Version 10.7 Upgrade Procedures 4. If your appliance has a SAN device attached. You do not need to run application discovery on the SharePoint service. 4.0 Migration Guide . 4. For more information. 2. 5. To synchronize the Active Directory data.0 patch 1: Learning of static URLs during profiling is disabled by default. and is primarily used to make storage devices.6. You cannot revoke permissions on the pre-upgrade data.5 to version 10. You can enable static URL profiling at any time. 4.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.6.6 Static URL Profiling When upgrading from versions 7. 4 Save bootstrap. Version 10. Note: The test_install script stops the Management Server. Note: If you are using an SSH client (for example.2 Open the bootstrap. thus making sure to send NULL packets to keep session active.3 Change the var-dir and audit-base-path parameters to point to /var/SecureSphere. Upgrading from Version 7.0 Migration Guide 27 . because it contains data you want to keep. execute the following commands: cd /var/SecureSphere/upgrades/upgrade-10. Do not format the SAN storage.4.<patch_number>_0.0. the reboot process will detect the SAN device and ask you whether to ignore the device or to format it.xml file using a text editor.0.5 Disconnect the cable of the SAN device. This is usually possible to tune under the connection menu in the SSH tool configuration properties. 5. 7. Users can choose to first test the installation script by first running the test_install script. based on the amount of RAM you have.xml. Warning: If you do not disconnect the cable. To run the test_install script.<build_number>/bin . 6. putty). Follow the instructions on the screen./test_install You will be asked for the server and database passwords. and you must restart it after the test_install script completes. and the script aborts before making any changes to the system.0. it is recommended to change the keep alive time on the SSH client to 1.0. 5. The user can then review the results.7061 and Higher 5.1 Execute the following commands: impctl gateway stop umount /mnt/<external-storage> where <external-storage> is your SAN mount name. 5. This means that all tests performed by the pre-install script will run whether or not there are warnings. 5. Install the package with the following command: cd /tmp/ rpm -ivh /tmp/<the name of the file you just downloaded> Note: The file you should execute is one of the files listed in step 4 above. <RPM version number>/bin/ Upgrade-10.0. The message indicates that extra attention is needed. not over SSH. you will be asked to provide another name for the machine. If you do not provide another name.Chapter 1 . 8. If you are upgrading from a SecureSphere version prior to 8. .5.<RPM version number>. 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. as the CLI user you just created) and then switch to the admin user by entering the admin command.diff in the backup directory (see Backup Directory on page 15). Please contact Imperva Support for further instructions.0 the following special characters are supported in passwords: * ( ) .0. Note: The following notes apply when you are upgrading from a SecureSphere version prior to 8.0 or higher • no files have been changed (see Files on page 21). • By default.5: • To login to the appliance over SSH after upgrading.0 Migration Guide .<RPM version number>/bin . 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. if the hostname is localhost. Differences are saved to [filename]. 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=<IP address> The standard output of the install command is written to the screen and also to the file: /var/SecureSphere/upgrades/upgrade-10.0.0.log 28 Version 10.0.SecureSphere Version 10. Execute the following commands: cd /var/SecureSphere/upgrades/upgrade-10. you must (by default) login as a CLI user (for example.+ = | # % ^ : / ~ . user root can login to the appliance only locally.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. Also. the hostname will be changed to “secure”. This password policy is applied during the upgrade procedure and if an unsupported special character is identified. If the script identifies any modified files. [ _.0. However. then the procedure is stopped./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. install: ################################################################################### install: ## install: ## The upgrade from version <version number> install: ## to version 10.0.0<RPM version number>. At this point. After reboot. When the OS installation is finished the system goes down for reboot. You are still able to login as root over SSH because the upgrade has not completed yet. as the CLI user you just created) and then switch to the admin user by entering the admin command. This may take some time. install: ## install: ## Backup of some files can be found at var/SecureSphere/upgrades/upgrade10. 10.7061 and Higher 9.0 is complete.0 Migration Guide 29 . to login as admin over SSH you must first login as a CLI user (for example. Wait until the following message appears. so please wait patiently.log 12.0.<RPM build Number>/bin tail -f Upgrade-10. install: ## install: ## Please reboot the appliance. 11. Wait until the message that the system is going down for reboot appears. install: ## install: ######################################################################### Version 10.0. Note: Because of the new hardening features in this version. connect to the appliance using SSH as user root.4.0. 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.0. Upgrading from Version 7.0.0.<RPM build Number>/backup. Check the upgrade log using the following commands: cd /var/SecureSphere/upgrades/upgrade-10. install: ## install: ## The upgrade from version <version number> install: ## to version 10.0.0 has completed with warnings.0. In this event. When mounts are used. 12. 12. • Reboot and continue with the following steps only if the upgrade process completes without any warnings of manual changes in the system.7 Enter the admin command to switch to the admin user using the CLI password. 12. connect to the appliance using SSH as the CLI user you defined earlier.0 Migration Guide This message indicates that the upgrade was successful. You must change the var-dir parameter in the bootstrap.SecureSphere Version 10. 30 Version 10. 12.xml file to point to the mounted directory where old_audit is located. If instead of the message indicating that the upgrade was successful.3 You will be asked to change the password. install: ################################################################################### install: ## install: ## Warnings have been detected. 12. 14. 13. 12.6 Enter the new password. install: ## Please contact support before continuing with the upgrade Process. install: ## install: ## Backup of some files can be found at var/SecureSphere/upgrades/upgrade10. 12.4 The SSH session will be terminated. you receive the following message. Follow the instructions in the relevant configuration guide.0 Migration Guide .8 Continue with step 14.<RPM build Number>/backup.5 Once again.Chapter 1 . as indicated in the message. contact Imperva Support. proceed as follows: 12. install: ## install: ## PLEASE DO NOT REBOOT THE APPLIANCE install: ## install: ######################################################################### Note: • If you receive any errors or warnings. do not continue with the upgrade and contact Imperva Support for further instructions.2 Connect to the appliance using SSH as the CLI user you defined earlier.1 Reboot the appliance. re-mount all previously configured mounts. because it contains data you want to keep. When the SecureSphere Management Server is started and its status is running.xml file using a text editor.0. If your appliance has a SAN device.4. proceed as follows: 15. 16. browse to: https://[Management Server IP address]:8083 17. execute the following command: mkdir -p /mnt/<external-storage> where <external-storage> is your SAN mount name. Upgrading from Version 7. to /mnt/<external-storage>.1 Reconnect the cable you disconnected earlier. 15. 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. for example. 15. Warning: Do not format the SAN storage.6 Change the var-dir and audit-base-path parameters to point to the external partition.0 Migration Guide 31 .2 If the directory /mnt/<external-storage> does not exist.7061 and Higher 15.5 Open the bootstrap. Read the End User License Agreement (Figure 1) and click Accept.0. Figure 1 End User License Agreement Version 10.4 /mnt/external-storage ext3 defaults 0 0 Confirm that the SAN device is mounted by executing the following commands: mount -a mount 15. In this step. Confirm that you would like to upgrade from the previous version (Figure 3).0 Migration Guide .SecureSphere Version 10. but the user whose password you should enter here is the one named “admin”.Chapter 1 .0 Migration Guide 18. Note: You may have several GUI users with administrative privileges. do not continue but instead contact Imperva support for further instructions. Enter the password for the user “admin” (Figure 2). 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. If the following message appears (Figure 4). 32 Version 10. all previous data is lost. The following message appears once the upgrade is complete: 20. • If you choose not to upgrade. Figure 3 Confirm Upgrade • If you would like to upgrade click Yes. Figure 2 admin Password 19. 0. ## ############################################################################## If the installation was not successful.0 Migration Guide 33 . 22.7061 and Higher Figure 4 Upgrade Failed 21. ## ## Please do NOT reboot the appliance and contact support. the following message appears in the log. If the patch installation was successful. Upgrading from Version 7. and you can continue to the next step: ############################################################################## ## ## Management server post upgrade operations completed successfully. but a reconciliation process is required. ### 24. Login to the machine as admin. Execute the following command: tail –n 200 /opt/SecureSphere/server/SecureSphereWork/logs/server_log. Version 10. Examine the upgrade log file /var/SecureSphere/upgrades/mx_post_upgrade. Verify that there are no warnings that partial failure occurred. These messages are of the following form: ### UPGRADE STATUS: PARTIAL FAILURE . ## ############################################################################## 25.0. and you should contact support before you continue: ############################################################################## ## ## Management server post upgrade operations failed.4. ## Please proceed and reboot the appliance.log. Please save this upgrade log and contact support. the following message appears in the log. reboot the appliance. If no errors occurred.The system can be used. If any messages of partial failure appear in the file. contact Imperva Support.txt 23. 2 Upgrading a SecureSphere Gateway (not relevant to Onebox Deployment) To upgrade a SecureSphere Gateway: 1. 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=<IP address> 4. not over SSH. as the CLI user you created in step 8 of this procedure) and then switch to the admin user by entering the admin command.Chapter 1 . you must upgrade to the 64-bit version of SecureSphere.0 Migration Guide 26. it is not possible to login to the appliance as the root user over SSH. Note: • If the gateway includes audit data. 2.1. 26.1 OS Hardening The appliance OS has been hardened so that by default. 26.0 Migration Guide . The Gateways tab in the GUI reflects the progress of this procedure. 4. Note: If your appliance has at least 4GB of RAM.3 Download the ADC content file from the Imperva web site. 34 Version 10. However.7. 26. Update the ADC content as follows: 26.SecureSphere Version 10.7. Login as root.2 Go to Admin > ADC.4 Upload it to the system. it is converted in the background.1 Start the SecureSphere GUI. To login to the appliance over SSH. user root can login to the appliance only locally. you must (by default) login as a CLI user (for example. 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. By default. 2 Open the bootstrap. Note: The test_install script stops the Management Server.3 If either the var-dir or audit-base-path parameters point to the external partition (for example.0. Do not format the SAN storage.1 Execute the following commands: impctl gateway stop umount /mnt/<external-storage> where <external-storage> is your SAN mount name. 4. This means that all tests performed by the pre-install script will run whether or not there are warnings. Upgrading from Version 7.0.0 Migration Guide 35 .0 or higher • no files have been changed (see Files on page 21). it is recommended to change the keep alive time on the SSH client to 1. Warning: If you do not disconnect the cable. 3. 3. • If you are using an SSH client (for example.4 Save bootstrap. execute the following command: cd /var/SecureSphere/upgrades/upgrade-10. to /mnt/<external-storage).7061 and Higher 3. 3. To run the test_install script. because it contains data you want to keep. If your appliance has a SAN device attached. 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. the reboot process will detect the SAN device and ask you whether to ignore the device or to format it. and the script aborts before making any changes to the system. 5. change them so that they point to the default /var/SecureSphere. 3. Install the package with the following command: rpm -ivh /tmp/<the name of the file you just downloaded> Follow the instructions on the screen. putty). Users can choose to first test the installation script by first running the test_install script.4. It is usually possible to tune this under the connection menu in the tool configuration properties.xml file using a text editor.5 Disconnect the cable of the SAN device. The user can then review the results.0/bin . and you must restart it after the test_install script completes./test_install You will be asked for the server password. proceed as follows: 3. Note: • <server-password> is the password of the secure user for the SecureSphere Management Server. Version 10.xml. making sure to send null packets to keep session active. you will be asked to provide another name for the machine. the hostname will be changed to “secure”. it might take some time to get the connection back while the new operating system is installed.0.0.Chapter 1 . However.SecureSphere Version 10. The message indicates that extra attention is needed. user root can login to the appliance only locally. You are still able to login as root over SSH because the upgrade has not completed yet. 8.<RPM version number>/bin/ Upgrade-10. Wait for a message that the system is going down for reboot. Please contact Imperva Support for further instructions./install Warning: Do not press Ctrl-C at any point during the upgrade process. You can monitor the progress (see Appendix A – Monitoring Installation Status with VNC on page 45) or wait until the SSH connection is re-established. Differences are saved to [filename].0 Migration Guide . if the hostname is localhost. 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. If you are upgrading from a SecureSphere version prior to 8. You will be asked for the following passwords: • current server password • new root password Also.0/bin .5: • To login to the appliance over SSH after upgrading. 6. 36 Version 10. When the OS installation is finished the system goes down for reboot. connect to the appliance using SSH as user root. If you do not provide another name.5.<RPM version number>. 9. not over SSH. • By default. 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. Execute the following command: cd /var/SecureSphere/upgrades/upgrade-10. After the reboot. 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=<IP address> The standard output of the install command is written to the screen and also to the file: /var/SecureSphere/upgrades/upgrade-10. you will also be asked: • to provide a Bootloader (GRUB) password • to define a new CLI user and provide a password Note: The following notes apply when you are upgrading from a SecureSphere version prior to 8.log 7. After reboot.0.diff in the backup directory (see Backup Directory on page 15).0.0 Migration Guide If the script identifies any modified files. 12.3 You will be asked to change the password. install: ## install: ## The upgrade from version <version number> install: ## to version 10. connect to the appliance using SSH as the CLI user you defined earlier.4 The SSH session will be terminated. do not continue with the upgrade and contact Imperva Support for further instructions.0.6 Enter the new password. install: ## install: ## Backup of some files can be found at var/SecureSphere/upgrades/upgrade10. install: ## install: ######################################################################### This message indicates that the upgrade was successful. install: ## install: ## Please reboot the appliance.0 is complete.<RPM build Number>/backup. Execute the following command: tail -f Upgrade-10.<RPM build Number>/backup.0 has completed with warnings.0.0. Execute the following command: cd /var/SecureSphere/upgrades/upgrade-10.0.1 Reboot the appliance. 12. 12. install: ## install: ## PLEASE DO NOT REBOOT THE APPLIANCE install: ## install: ######################################################################### Version 10. install: ## Please contact support before continuing with the upgrade Process.log 12.0 Migration Guide 37 . 12. install: ## install: ## Backup of some files can be found at var/SecureSphere/upgrades/upgrade10. install: ################################################################################### install: ## install: ## Warnings have been detected.<RPM version number>.0.0.0. Wait until the following message appears. install: ################################################################################### install: ## install: ## The upgrade from version <version number> install: ## to version 10.5 Once again. 12.0. proceed as follows: 12. 12. Upgrading from Version 7.8 Continue with step 14.0. 13.7 Enter the admin command to switch to the admin user using the CLI password. In this event. 12. as indicated in the message. you receive the following message.0.4. If instead of the message indicating that the upgrade was successful.2 Connect to the appliance using SSH as the CLI user you defined earlier.7061 and Higher 10.<RPM build Number>/bin 11. 7. Audit data located on the Gateway is converted in the background.Chapter 1 . execute the following command: mkdir -p /mnt/<external-storage> where <external-storage> is your SAN mount name. By default. user root can login to the appliance only locally. 4.1 OS Hardening The appliance OS has been hardened so that by default. for example. To login to the appliance over SSH.SecureSphere Version 10.1 Reconnect the cable you disconnected earlier. If your appliance has a SAN device attached.2. re-mount now all previously configured mounts.2 If the directory /mnt/<external-storage> does not exist. 15. because it contains data you want to keep. You must change the var-dir parameter in the bootstrap. 18.6 Change the var-dir and audit-base-path parameters to point to the external partition. 15. Reboot the machine.0 Migration Guide . When mounts are used.5 Open the bootstrap. 16. proceed as follows: 15. However. 17. Warning: Do not format the SAN storage. as the CLI user you created in step 6 of this procedure) and then switch to the admin user by entering the admin command. it is not possible to login to the appliance as the root user over SSH. 14. 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=<IP address> 38 Version 10.0 Migration Guide Note: • If you receive any errors or warnings. Follow the instructions in the relevant configuration guide. to /mnt/<external-storage>. contact Imperva Support. If you are upgrading from a version prior to 6442. The Gateways tab in the GUI reflects the progress of this procedure. • Reboot and continue with the following steps only if the upgrade process completes without any warnings of manual changes in the system.xml file to point to the mounted directory where old_audit is located. rename the old audit directory in the mounted partition from audit to old_audit.4 /mnt/external-storage ext3 defaults 0 0 Confirm that the SAN device is mounted by executing the following commands: mount -a mount 15. not over SSH.3 Open the file /etc/fstab with a text editor (such as vi) and add the following line to the file: /dev/sdX 15. you must (by default) login as a CLI user (for example.xml file using a text editor. 15. 15. 7. Select and enable Core multi-processing.2 Restore the Reverse Proxy Apache Configuration To restore the Reverse Proxy Apache configuration: 1. which is lost during the upgrade process.8. Define new aliases.4.0. For more information. Version 10. Press Return. For more information. Optionally.xml file. Save the file. 4. Execute the following command: impcfg 6. 2.8. perform the following: 1. During the boot. <listeners> <listener ip="<IP Address>" port="443" sslEnabled="true"/> </listeners> 4. The aliases replace the old configuration. 3. select Advanced -> Processor. Retrieve the previous configuration defined in httpd. 5. In the BIOS. open the /opt/SecureSphere/etc/bootstrap. Restore the Reverse Proxy Apache configuration. 2.7061 and Higher 4. Using a text editor. On Aspen-Hill appliances. Upgrading from Version 7. On the gateway. Press F2 to go to Setup/BIOS options. Modify the gateway’s mode to Reverse Proxy Apache. Login as root and reboot the appliance by typing reboot. see Enable Dual-core on Aspen-Hill Appliances on page 39. dual-core can be enabled on Aspen-Hill appliances.conf with the previous configuration.1 Enable Dual-core on Aspen-Hill Appliances Dual-core was disabled on all Aspen-Hill appliances running previous versions of SecureSphere. 3. For more information. enable dual-core. 9.8 Post Upgrade Procedures After upgrading. With the new operating system. see Enabling the Activate Settings Option on page 50. 8. 4. 2. enable the Activate Settings feature.0. Modify the listener port to the value defined before the upgrade. Edit the new httpd. 3. 5.conf from the backup directory (see Backup Directory on page 15).0 Migration Guide 39 . 4. see Restore the Reverse Proxy Apache Configuration on page 39. login as root after the SecureSphere Server is up. To enable dual-core on Aspen-Hill appliances: 1.conf file at /etc/httpd/conf/httpd. Version 10. Recreate routes as follows: 10.1 Define the static routes.0 Migration Guide .Chapter 1 .3 Navigate to Top > Gateway > Manage interfaces and routes > Manage reverse proxy (apache) routes 10. 10. 10.1 If VRRP is defined. you must associate the route with the virtual instance.0 Migration Guide 10.1 Log in to the gateway as user root.SecureSphere Version 10.2 Execute the following command: impcfg 40 10. 0 Migration Guide 41 . Patch Update 5. so there is no need to install a patch after the upgrade process. Version 10.5. Patch Update The installation file includes the latest patches. Backing Up and Restoring the System 6.2. set the following parameters: 4. Login to the Management Server as user root.sh 3.1 4. which is /var/tmp/SecureSphere_<current date>.1 SecureSphere 6. 6. Save the backup file to an external location. Save the backup file on another machine.2 The Backup Process 6. Execute the following commands: cd /tmp chmod 755 full_expimp.1 Introduction Before running the upgrade process.1 Operation: option . 6. You can follow the log file created in the same directory as the backup file by using the tail command in a different shell.1 5.0 Migration Guide . Enter Y to confirm the export action.Chapter 1 . If the export was successful. Enter a name for the backup file or use the default name.x and higher: 1.3 Export Type: option . The backup process guarantees that the system can be restored. Enter a response (y or n) to the question: “Would you like to export failed archives data [y/n] (default is n)?”. execute the following commands: impctl server stop /full_expimp. To fully export the SecureSphere server for backup purposes. Restart the server using the following command: impctl server start 42 Version 10. if needed. you will see the following message at the end of the file: full_expimp completed successfully on <date> 9. 4. 10. Make sure to type a full path when not using the default. Wait for the process to end.tgz 7.SecureSphere Version 10. 8. To start the full export/import utility.2 Password: the password you chose for the system user in the first-time login.x and Higher To backup your system in version 6.sh 4. This may take some time when there is a large number of events to export.0 Migration Guide 6. backup the SecureSphere system. 2. 6. Backing Up and Restoring the System 11.2 Backup Audit Files Backup audit files by archiving them to an external location. 2.3 The Restore Process Obtain the installation CDs for the build corresponding to your backup data and install the SecureSphere system.3.sh 4. .0 Migration Guide 43 . Follow the SecureSphere first-time login and configuration process as described in the Quick Start Guide of your appliance. login with the username secure. It is possible to back up the audit directory to an external location. 4.sh utility. type install and press Enter. After the system reboots.x and Higher After you install the system from scratch. To restore the system: 1. Note: It is not possible to use the new full_expimp. 6.sh Version 10.2. 3. 5. Insert SecureSphere Disc#1 when requested. Copy the exported dump file and the full_expimp. Login to the Management Server as user root. Remove the CD and click Enter once.sh utility to import data exported with the old expimp. 3. execute the following command:. If the gateway continues to audit. To install SecureSphere from the black CDs (from scratch): 1. reboot the appliance. 6. 6. See SecureSphere User Guide for details on the exact operation steps. 7. you must restore the system from the backup dump file.1 SecureSphere 7./full_expimp. installation is completed. impctl server stop cd /tmp chmod 755 full_expimp. To start the installation. Insert SecureSphere Disc#0 when connected to the appliance with a screen and keyboard.sh utility to /tmp 2. Execute the following commands:. To start the full export/import utility. Copy all the reports from /opt/SecureSphere/server/SecureSphere/jakarta-tomcat-secsph/webapps/ SecureSphere/WEB-INF/reptemp to a different machine for backup purposes. information collected after the directory was copied or information was archived is not backed up. 6. Copy configuration files during the import Enter a file for the operation Enter the name of the tgz file you want to import.tgz Note: You will also have to enter two passwords. set the following parameters: Note: If you are using an earlier version of full_expimp. there will be a different set of parameters. /tmp/SecureSphere_<current date>. 44 Version 10. This may take some time when there are a lot of events to import. When complete. Import Please select operation to perform before the import 1: Drop target schema (if it exists) Please select configuration files option 2.Chapter 1 .0 Migration Guide . 6. • It is not possible to use the new full_expimp.sh utility to export or import your SecureSphere Server. all SSL keys must be re-entered. Parameter Select Select operation 2. please contact Imperva support.sh utility. Wait for the process to complete.sh utility to import data exported with the old expimp. To fully import the SecureSphere server from a backup file.SecureSphere Version 10.0 Migration Guide 5. 7. start the server by executing the following command: su secure start-server Note: • Use only the full_expimp. • If you import the dump file to another appliance. If you need assistance. Enter it with its full path that is. the system password and the secure user password. You can follow the log file created in the same directory as the backup file by using the tail command in a different shell.sh. 4.7.0 Migration Guide 45 . In order to connect to the machine with VNC. connect to the machine using SSH as user root. Figure 6 CentOS 2. enter <appliance management IP>:1 in Server and install in password. 3. Version 10.0. Continue the upgrade according to the instructions. Figure 5 VNC Viewer 1.8265. the SecureSphere operating system was upgraded to CentOS 5. the system goes down for reboot. Appendix A – Monitoring Installation Status with VNC 7. If the upgrade is done through a remote connection the users do not have visibility into the process and cannot watch the installation screens. The appliance and the VNC client must be on the same subnet. When the VNC connection is terminated. see The SecureSphere Operating System on page 14).4. (For more information. Installing a new operating system may take some time. Appendix A – Monitoring Installation Status with VNC In release 8.0. After the reboot. To allow user visibility to the operating system installation process it is possible to connect to the upgraded appliance using VNC viewer software. Monitor the installation of the CentOS Operating System. Login into the appliance as user root. 3. To copy the file. 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. Execute the following command: mount /dev/sda1 /mnt/usb1 5. execute the following command: umount /dev/sda1 Note: /dev/* can be different based on hardware. 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. To un-mount. execute the following command: cp /mnt/usb1/<file name> /<path to file>/<file name> 6.0 Migration Guide 8. If is done before the first time login. use the password webco123 if requested.SecureSphere Version 10.0 Migration Guide . 2. Execute the following command: mkdir /mnt/usb1 4.Chapter 1 . 9. To upload the encryption keys: 1. the encryption module for httpd “mod_nss” replaces the “mod_ssl” that was used previously. 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.0 Migration Guide 47 . start with 9. You must specify the database directory.Configuring Apache Reverse Proxy 9. With FIPS 140 support.2.pem -out /tmp/ outputkey. Appendix C .1 Uploading the Encryption Keys Note: If you are not using SSL.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. certutil -N -d /etc/httpd/alias Version 10.cert the command is as follows: openssl pkcs12 -export -in /tmp/input.p12 -name mykey -passout pass:1234 2.cert -inkey /tmp/inputkey. Appendix C .conf file under the NSSNickname parameter.pem and certificate file is input. -passout The output key password For example if source key file name is inputkey. Convert the OpenSSL key and certificate into a PKCS#12 file by executing the following command: openssl pkcs12 -export -in /tmp/<source certificate file name> -inkey /tmp/ <source key file name> –out /tmp/<result key name> -name <descriptive key name> -passout pass:<output key password> 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.9. Create an NSS database. SecureSphere Version 10. Enter a password or leave the text box empty. 3. Assuming you have its ASCII representation (e..0 Migration Guide . You do not need the key of the CA.conf file under the NSSCertificateDatabase parameter.conf file under the NSSCertificateDatabase parameter. Based on the above example it should be similar to: pk12util pk12util -i /tmp/outputkey.conf file under the NSSCertificateDatabase parameter. This is used as local certificate authority. a PEM file).g.step 2 5.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 . 4. Import the certificate of the CA server which issued the server certificate.Chapter 1 . you can load it as follows: certutil -A -d /etc/httpd/alias/ -n "My Local CA" -t CT -i /tmp/<CA certificate> 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.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. -n The nickname of the certificate to add -t Sets the certificate trust attributes -i The BINARY certificate request file Version 10. If you are adding a password. just the certificate. Load the PKCS #12 file into your NSS database by executing the following command: pk12util pk12util -i /tmp/<result key name> -d /etc/httpd/alias –W <output key password> Where: Parameter Description -i Imports files -d Cert database directory path that must be the same as the name specified in the nss. the password must contain at least 8 characters one of which should be a non-alphabetic character. To enable the HTTP service start after reboot.conf file from the upgrade backup folder to /etc/httpd/conf. When using FIPS.cer the command should look like: certutil -A -d /etc/httpd/alias/ -n "My Local CA" -t CT -i /tmp/CAserver. Restart the httpd service by executing the following command: service httpd restart 4.conf and http. Appendix C .conf and http. and you will have to manually copy them from the backup directory (see Backup Directory on page 15) after the upgrade has successfully completed.9.step 2 b. Note: The parameter NSSProxyProtocol may need to contain TLSv1. if your CA server certificate name is CAserver. It should contain a single line: NSS FIPS 140-2 Certificate DB:<< NSS certificate database password > The password is the one you set in Uploading the Encryption Keys on page 47 . This completes the first step of creating the certificate DB and uploading the keys to it. execute the following command: chkconfig httpd on Version 10.2 nss. 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.d 3.0 Migration Guide 49 . run the following additional steps: a.TLSv1.Configuring Apache Reverse Proxy For example. Copy the original httpd.conf files The nss. For example: NSSProxyProtocol SSLv3. Edit the file /etc/httpd/alias/phrases file.cer 6.conf file from the upgrade backup folder to /etc/httpd/conf 2. With the new ‘mod_nss’ module you can work either in FIPS mode enabled or disabled. 1.conf files are not carried over to their proper locations during the upgrade process. 9. Copy the original nss. displaying detailed information about all changes that have not yet been activated.activation-mode attribute to OnActivateSettings 5. 10. 7. 3. Wait for the SecureSphere Management Server to load. click Activate. Pay attention to the spaces separating the attribute from its value. Login as root to the Management Server. Use a text editor to edit the configuration file.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. Version 10. All changes are applied. Actions must execute after the Management Server status is running. The Activate Settings window appears.1 Enabling the Activate Settings Option 1. In the Activate Settings window.properties 4. 2. Edit: activate-settings. indicating the status of activation. In any SecureSphere window. Appendix D . 3. Set the activate-settings.Chapter 1 . Click OK.0 Migration Guide . enter the following command: vi /opt/SecureSphere/server/SecureSphere/jakarta-tomcat-secsph/webapps/ SecureSphere/WEB-INF/bootstrap. The Activate Settings window closes and the progress bar appears. click Activate.activation-mode 6.Enabling Activate Settings 10.0 Migration Guide 10. For example. 2. Restart the Management Server for changes to take effect.SecureSphere Version 10. Secondary Server 5. Upgrade to the new SecureSphere version by running the relevant RPM according to the instructions given earlier in this document. Because this is the secondary server.1 Create a new mxha directory by executing the following command: mkdir /var/tmp/mxha Version 10.1 Start the DB by executing the following command: impctl db start 2.5 and higher – Either: • Upgrade to the new SecureSphere version by running the relevant RPM. 6.0 Migration Guide 51 . Appendix E – Guidelines for MX-HA Upgrade This section describes the procedure for upgrading MX-HA configurations. perform the following actions on the secondary server: 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. After the previous step successfully completes (and not before!). From Version 7. Download new Oracle RPMs and prepare the servers by performing the following steps on both servers: 6. or • Install the new SecureSphere version from scratch. Because this is the secondary server. uninstall MX-HA by executing the following command: impctl server ha uninstall 2. 1. Appendix E – Guidelines for MX-HA Upgrade 11. it does not matter that the data will not be migrated.0 and below – Install the new SecureSphere version from scratch. it does not matter that the data will not be migrated.11. as all the data will be restored from the primary server. as all the data will be restored from the primary server. On the primary server. Upgrade as follows: From Version 7. for example when you are running this command on the primary Management Server. 9. Re-establish SSH trust for the root user and the oracle user. If your appliance has at least 4GB of RAM. • <other_MX private interconnect> is the IP address of the interconnect on the other Management Server. one for 32 bit and the other for 64 bit. 52 Version 10. specify the public IP address of the secondary Management Server. that is.SecureSphere Version 10. when you are running this command on the primary Management Server.0/32Bit/MX-HA/ 32-bit version /Downloads/SecureSphere_Setup/v10. for example. Otherwise. download the Oracle RPMs to the /var/tmp/mxha directory. On both Management Servers.2 From the Imperva FTP server. On the primary server.0 Migration Guide . the IP address shared by both Management Servers. 8. upgrade the gateway. download the 32-bit version.Chapter 1 . File Name Version /Downloads/SecureSphere_Setup/v10.0/64Bit/MX-HA/ 64-bit version 6. There are two directories. specify the IP address of the interconnect on the secondary Management Server.3 Execute the following command: impctl server ha preparerpm 7. download the 64-bit version of SecureSphere.0 Migration Guide 6. • <other_MX physical> is the public IP address of the other Management Server. install MX-HA by executing the following command: impctl server ha install 10. execute the following commands: impctl hardening config --root-source-ip-exception=<vip> impctl hardening config --root-source-ip-exception=<other_MX private interconnect> impctl hardening config --root-source-ip-exception=<other_MX physical> where: • <vip> is the floating IP address. After the previous step successfully completes (and not before!). 13.0 with the KRP configuration: 1. g. In case of VRRP configuration: a. see Upgrading a SecureSphere Management Server or Onebox on page 26. select the relevant gateway and click Aliases in the Details pane. Select the relevant gateway and click Virtual Routers from the Details pane. c. The Virtual Routers table appears. 5. In the Virtual Routers table. click Close. Appendix F .0 to version 10. select Use first line as header and click Upload. Upgrade the MX. In the IP Address/Mask (CIDR) text box. 10. Click Browse and locate the Alias CSV file. 2. 4. The IP Address window appears. The IP Addresses table closes. 11. The IP Address dialog box closes. In the IP Addresses table. From the Network Interface drop-down list. Click Close. Make sure to define a static IP Address in the same subnet. Once the upload is successfully completed. To upload CSV files to the MX. select Use first line as header and click Upload. k. d. Once the upload is successfully completed. click Setup > Gateways. type a static IP Adress for the external interface. j. click Upload from CSV. Repeat steps a-k for another gateway that participates in the VRRP configuration. 6. l. In the Advanced tab. click New. Version 10. In the Aliases table. h. The Upload Virtual Routers from CSV dialog box appears. 3. The Aliases table appears. Review the Aliases CSV file to make sure there are no Aliases with the same external interface and IP address. 8. Close the Virtual Routers table. e. Click Save.Upgrade Procedure for the Kernel Reverse Proxy Configuration 12. b. Select the relevant gateway and click IP Addresses from the Details pane. repeat steps 7-11 for the second Gateway. see Upgrading a SecureSphere Gateway (not relevant to Onebox Deployment) on page 34. Upgrade the Gateway. The IP Addresses table appears. click Close. When using VRRP configuration. all KRP connections are terminated until the next steps are performed. 9. Close the Aliases table. Appendix F . 12. select the external interface that you want to use for this gateway. In the Gateway window. m. click Upload from CSV. The Upload aliases from CSV progress box appears. The Gateways window appears.0 Migration Guide 53 .Upgrade Procedure for the Kernel Reverse Proxy Configuration To upgrade from SecureSphere version earlier than 9.12. In the Advanced tab. Click Browse and locate the VRRP CSV file. i. The Upload Virtual Routers from CSV dialog box closes. f. 7. Connect to the Gateway using SSH and copy CSV files located in: /var/SecureSphere/upgrades/upgrade-<version>/backup/ReverseProxyData/ The CSV file contains the KRP configuration before upgrade. After the MX upgrade. The Upload Aliases from CSV dialog box closes. Click Save.0 Migration Guide Note: After uploading CSV files to the MX. h. 54 Version 10. Once the upload is successfully completed. In the Gateway window. 4. In the IP Address/Mask (CIDR) text box. The IP Addresses table appears. k. 2. Select the relevant gateway and click Virtual Routers from the Details pane. click Upload from CSV. Make sure to define a static IP Address in the same subnet. e. Note: Once the Gateway is upgraded. Click Close.0 with the KRP configuration: 1. 3. see Upgrading a SecureSphere Gateway (not relevant to Onebox Deployment) on page 34.0 and later to version 10. g. m. Select the relevant gateway and click IP Addresses from the Details pane. the KRP configuration is read from bootstrap. The Upload Virtual Routers from CSV dialog box appears. Review the Routes CSV file to make sure there are no illigal Routes. In case of VRRP configuration: a. Click Browse and locate the Alias CSV file. all KRP connections are terminated until the next steps are performed. type a static IP Adress for the external interface. l. Upgrade the MX. i. In the Advanced tab. 7. The IP Address window appears. Review the Aliases CSV file to make sure there are no Aliases with the same external interface and IP address. 5. f.terminated connections should become active again. select Use first line as header and click Upload. To upgrade from SecureSphere version 9. 9. b. The Aliases table appears. The Gateways window appears. Repeat steps a-k for another gateway that participates in the VRRP configuration. c.0 Migration Guide . In the IP Addresses table. After the MX upgrade. The Virtual Routers table appears. In the Aliases table. 6. The Upload aliases from CSV progress box appears. Connect to the Gateway using SSH and copy CSV files located in: /var/SecureSphere/upgrades/upgrade-<version>/backup/ReverseProxyData/ The CSV file contains the KRP configuration before upgrade. d. see Upgrading a SecureSphere Management Server or Onebox on page 26. select the external interface that you want to use for this gateway. To upload CSV files to the MX. Click Browse and locate the VRRP CSV file.xml and KRP in IMPCFG is disabled (Impossible to add new KRP aliases/routes/vrrp instances). select the relevant gateway and click Aliases in the Details pane. click New. The Upload Virtual Routers from CSV dialog box closes.SecureSphere Version 10. In the Virtual Routers table. j.ile to make sure there are no Aliases with the same external interface and IP address. click Setup > Gateways. The IP Address dialog box closes. click Close. new KRP xml configuration file will be downloaded to the GW and MX with GW will be in sync .Chapter 1 . click Upload from CSV. 10. From the Network Interface drop-down list. The IP Addresses table closes. Upgrade the Gateway. Close the Virtual Routers table. 8. 4. 15. 19.terminated connections should become active again. 8. new KRP xml configuration file will be downloaded to the GW and MX with GW will be in sync . 20. Close the Virtual Routers table. you must reconfigure them after the upgrade. repeat steps 7-18 for the second Gateway. Disconnect the management link from the backup Gateway. Click Browse and locate the Routes CSV file. In the Advanced tab. KRP connections are terminated only on the main Gateway (the backup Gateway is disconnected from the MX). click Close. 7. Note: Once the MX is upgraded. In the Advanced tab. Upgrade both Gateways. The Routes table appears. click Upload from CSV. Reconnect the management link after MX is upgraded and all the CSV files were uploaded to it. 6. The Upload routes from CSV progress box appears. 5. The Upload Virtual Routers from CSV dialog box closes. Upgrade the MX. select Use first line as header and click Upload. Close the Routes table. Once the upload is successfully completed. see Upgrading a SecureSphere Management Server or Onebox on page 26. 2. The Upload Aliases from CSV dialog box closes. select Use first line as header and click Upload. In the Routes table. In the Gateway window. The Upload Routes from CSV dialog box closes. Notes: • • After uploading CSV files to the MX. If static routes are configured outside of IMPCFG (Linux). When using VRRP configuration. 2. To minimize down time of High Availability Gateway: 1. select Use first line as header and click Upload. 17. Close the Aliases table. Disconnect the management link from the Gateway before the MX upgrade.0 Migration Guide 55 . 12. select the relevant gateway and click Routes in the Details pane. In the Virtual Routers table. In the Advanced tab. click Close.12. the traffic is directed to the backup Gateway. The Upload Virtual Routers from CSV dialog box appears.Upgrade Procedure for the Kernel Reverse Proxy Configuration 11. Once the upload is successfully completed. 3. Select the relevant gateway and click Virtual Routers from the Details pane. Version 10. To minimize Gateway down time: 1. The Virtual Routers table appears. click Close. 16. 18. 14. Appendix F . click Upload from CSV. That way the first configuration deletes the existing KRP entries from the bootstrap and restores them in the new KRP xml configuration file. Once the upload is successfully completed. 13. see Upgrading a SecureSphere Gateway (not relevant to Onebox Deployment) on page 34. 56 Version 10. 19. Close the Routes table. select the relevant gateway and click Aliases in the Details pane. In the Advanced tab. In the Advanced tab.SecureSphere Version 10. Close the Aliases table.0 Migration Guide 9. click Close. In the Aliases table. 10. click Upload from CSV. 14. Once the upload is successfully completed. 18. 16. The Aliases table appears. 13. 15. 12. click Close. The Routes table appears. Click Browse and locate the Routes CSV file. The Upload routes from CSV progress box appears. click Upload from CSV. The Upload Routes from CSV dialog box closes.Chapter 1 . In the Gateway window. Connect the management link on the backup Gateway. select the relevant gateway and click Routes in the Details pane. select Use first line as header and click Upload. 17. When using VRRP configuration. 21. The Upload aliases from CSV dialog box appears.0 Migration Guide . 20. repeat steps 7-18 for the second Gateway. The Upload Aliases from CSV dialog box closes. In the Routes table. In the Gateway window. 11. Once the upload is successfully completed. select Use first line as header and click Upload. the agent with an earlier version will work. there is no need to uninstall the existing agent prior to installing a new agent.0 and later.0. Appendix G .0 and later can work with agent versions 8. but without the new capabilities.0 Migration Guide 57 . Appendix G .1 Upgrading the SecureSphere Agents Starting with SecureSphere 10. 13. To upgrade a Unix Agent: 1. use the Supported kernel versions file. use -s • for SUSE: in addition to the instructions above. If you do not upgrade the agent. SecureSphere version 8.SecureSphere Agent Upgrade 13. To upgrade a Windows Agent: • Install the agent without uninstalling the existing agent. use -u • to start the agent after the upgrade. as explained in the Admin Guide. Version 10. Install the new Remote Agent using the following upgrade parameters: • to perform the upgrade.SecureSphere Agent Upgrade Agents are upgraded separately from SecureSphere.13.
Copyright © 2024 DOKUMEN.SITE Inc.