Sie sind auf Seite 1von 78

Upgrading

SecureSphere to
Version 11.0
February 2015

COPYRIGHT NOTICE
2015 Imperva, Inc. All Rights Reserved.
Follow this link to see the SecureSphere copyright notices and certain open source license terms:
https://www.imperva.com/sign_in.asp?retURL=/articles/Reference/SecureSphere-License-and-Copyright-Information
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.

PATENT INFORMATION
The software described by this document is covered by one or more of the following patents:
US Patent Nos. 7,640,235, 7,743,420, 7,752,662, 8,024,804, 8,051,484, 8,056,141, 8,135,948, 8,181,246, 8,392,963, 8,448,233, 8,453,255,
8,713,682, 8,752,208, 8,869,279 and 8,904,558.

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

Imperva-SecureSphere-11.0-Upgrade-Guide-v2.0

Email: info@imperva.com
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). IN THE EVENT THE INDIVIDUAL IS ENTERING INTO THIS
AGREEMENT ON BEHALF OF A CORPORATE OR OTHER PUBLIC OR PRIVATE ENTITY, END USER REFERS TO THAT
ENTITY, AND SUCH INDIVIDUAL CERTIFIES THAT HE/SHE IS AN AUTHORIZED REPRESENTATIVE OF THE END USER.
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.
1.

Definitions. The following capitalized terms shall have the meanings set forth below:
a.
b.

c.
d.
e.
f.

g.
h.
i.

j.
k.
l.
2.

Appliance means the Imperva branded computer hardware on which the Software operates.
Delivery shall mean, (i) in the case of Software, when the Software is made available by Imperva for End
User to electronically download or use on Amazon Web Services; (ii) in the case of Subscription Services,
when the Subscription 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.
Documentation means Impervas technical specifications that accompany and describe the installation,
use and operation of a Product.
End User means the party that has purchased the Products for its own use, either directly from Imperva or
through an authorized third party.
Licensed Volume means the volume or other measurement of permitted use for the Products as agreed to
by Imperva directly or through its resellers.
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.
Products mean Appliances, Software or Subscription Services, as the case may be.
Services mean Professional Services or Support, as the case may be.
Software means Impervas 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. The term Software does not include Open
Source Software.
Subscription Services mean the subscription services, including content, updates and upgrades thereto,
that may be made available to End User by Imperva directly or through its partners and suppliers.
Subscription Services include, without limitation, the ThreatRadar service and the Incapsula services.
Support means the technical support and maintenance services for the Product and periodic bug fixes and
updates to the Software that Imperva may make generally available at an annual subscription cost to end
users.
Professional Services mean the installation, configuration, and training services that Imperva may
provide to an End User.

Licenses and Restrictions.


a.

b.

c.

Software. Conditioned on the terms and conditions of this Agreement, Imperva grants End User a perpetual
(subject to Section 11 or any term license restrictions), nonexclusive, nontransferable, nonsublicensable
license to use the Software in accordance with its Documentation only for End Users internal business
purposes on the Appliances or in the Licensed Volume licensed by End User. If End User purchases Software
on a standalone basis, the license granted herein shall include the right to copy the Software up to the
Licensed Volume.
Subscription Services. Conditioned on the terms and conditions of this Agreement and any registration
form that Imperva may require, Imperva grants End User a nonexclusive, nontransferable, nonsublicensable,
revocable right to use and access the Subscription Services in accordance with its Documentation only for End
Users internal business purposes.
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

d.

e.

f.

prohibits reverse engineering restrictions), decompile, disassemble, otherwise attempt to derive source code
from or create derivative works based on the Products; (ii) make unauthorized copies of the Products; (iii)
disclose, distribute, transfer or market the Products to third parties; (iv) remove or modify any proprietary
notices, labels or marks on or in any copy of the Products; (v) distribute, sell, sublicense, rent, lease or use
the Products (or any portion thereof) for time sharing, hosting, service provider or other computer services to
third parties or otherwise make the functionality of the Software available to third parties; (vi) publicly
disseminate performance information or analysis (including, without limitation, benchmarks and performance
tests) from any source relating to the Products; (vii) access the database or any other third party product that
is embedded in the Software with applications other than the Software; or (viii) use the Products other than
as permitted herein.
Appliance. End User acknowledges that the Software included with the Appliance is licensed and not sold.
Such Software is licensed solely in conjunction with such Appliance (and not separately or apart from such
Appliance). If End User sells, leases, lends, rents, distributes or otherwise transfers any Appliance to any third
party or if Imperva terminates this Agreement under Section 11.b or for a breach of Section 2.c, then End
User will erase all Software from such Appliance.
Open Source Software. Open Source Software is copyrighted and licensed under the GPL/LGPL and other
licenses. Copies of or references to those licenses are included with Software in the Help section. If
delivery of source code is required by the applicable license, End User may obtain the corresponding Open
Source Software source code for a period of three years after Impervas last shipment of the Software, by
sending a request to: Legal Department Open Source Software Request, Imperva, Inc., 3400 Bridge
Parkway, Suite 200, Redwood Shores, CA 94065, United States.
US Government End User. For purposes of this Agreement, commercial computer software is defined at
FAR 2.101. If acquired by or on behalf of a civilian agency, the U.S. Government acquires this commercial
computer software and/or commercial computer software documentation and other technical data subject to
the terms of the Agreement as specified in 48 C.F.R. 12.212 (Computer Software) and 12.211 (Technical Data)
of the Federal Acquisition Regulation (FAR) and its successors. If acquired by or on behalf of any agency
within the Department of Defense (DOD), the U.S. Government acquires this commercial computer software
and/or commercial computer software documentation subject to the terms of the Agreement as specified in
48 C.F.R. 227.7202-3 of the DOD FAR Supplement (DFARS) and its successors. This U.S. Government End
User Section 2(f) is in lieu of, and supersedes, any other FAR, DFARS, or other clause or provision that
addresses government rights in computer software or technical data.

3.

Support and Subscription Services. Provided End User has an active and fully paid contract for Support and
has completed any required registration, Imperva will provide Support in accordance with its standard Support
terms then in effect. Provided End User has an active and fully paid contract for Subscription Services, Imperva
will provide such services in accordance with its standard Service Level Agreement (SLA) then in effect.

4.

Additional Terms for Subscription Services.


a.

b.

Accessing and Use of Subscription 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 Subscription Services, including without limitation paying all charges, taxes, and
other costs and fees related to internet access. End User may access the Subscription Services only through
the interfaces and protocols provided or authorized by Imperva and its partners, and agrees to set up,
maintain and use the Subscription Services in strict compliance with Impervas and its partners instructions.
End User is solely responsible for maintaining the confidentiality of any passwords and account information
required to access Subscription Services, for all acts that occur in connection with End Users account and to
immediately notify Imperva of any unauthorized use of End Users account. In the event of expiration or
termination of any Subscription 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 Users failure to
do so.
Authorization. Certain Subscription Services are offered to cache, monitor and optimize web pages and web
sites. In connection with such Subscription Services, End User hereby grants Imperva and its partners a
nonexclusive, worldwide, fully paid-up, royalty-free license to use, transfer, display, minimize and compress
the content and material on End User web sites (End User Content), in any media formats, solely as
necessary for the performance of the Subscription Services. Imperva and its partners do not provide backup
services for End User Content, and if End Users use of the Subscription 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 Impervas and its
partners sole determination, End User is using the Subscription Services in a manner that violates laws, rules
or regulations or creates an excessive burden or potential adverse impact on Impervas, its partners or its

suppliers systems, business or customers, Imperva, its partners or its suppliers may suspend or terminate
End Users access to the Subscription 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 statement of work (SOW) agreed to by Imperva and Impervas standard Professional Services terms
then in effect.

6.

Fees, Payment Terms, Shipment and Delivery.


a.

b.

7.

For orders accepted directly by Imperva, End User shall pay Imperva the applicable fees designated by
Imperva. Overage fees may apply if End User exceeds its allowance for any Subscription Services at
Impervas then-current overage rates. 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 based on Impervas income. Should End User be required under
any law or regulation of any governmental entity or authority outside of the United States, to withhold or
deduct any portion of the payments due to Imperva, then End User shall increase the sum payable to Imperva
by the amount necessary to yield to Imperva an amount equal to the sum it would have received had no
withholdings or deductions been made. Fees shall be invoiced as follows: (a) fees for all Subscription
Services, term Software licenses and Support shall be invoiced at the time of the initial order and in advance
of each renewal period; (b) fees for other Software licenses and Appliance purchases will be invoiced upon
Delivery. All payments from End User to Imperva are due net thirty (30) days after the date of invoice. If End
User's account for Subscription Services or Support is thirty (30) days or more overdue, in addition to any of
its other rights or remedies, Imperva reserves the right to suspend such services 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 Users facilities,
computers and records to confirm End Users use of Products is in compliance with this Agreement. End User
shall provide reasonable cooperation with any such audit.
Imperva will use commercially reasonable efforts to ship the Appliances and the Software license keys at the
times requested in Orders (in partial or full shipments); provided, however, that Imperva shall in no event be
liable for any delay in Delivery or for failure to give notice of delay. Without liability to any person and without
prejudice to any other remedy, Imperva may withhold or delay shipment of any Order if End User is late in
payment or is otherwise in default under this Agreement. 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. Appliances shall be
delivered Ex Works (Incoterms 2000) Impervas designated manufacturing facility. End User may specify
shipping instructions with the Order. In the absence of specific shipping instructions from End User, Imperva
will ship by the method it deems most advantageous. End User shall pay and be exclusively liable for all costs
associated with shipping and delivery including without limitation, freight, shipping, customs charges and
expenses, cost of special packaging or handling and insurance premiums incurred by Imperva in connection
with the shipment of Appliances to End User. In its discretion, Imperva may advance shipping charges on
behalf of End User on Appliances shipped to End User, and End User agrees to reimburse Imperva for any
such advanced charges and expenses.

Confidentiality.
a.

b.

As used herein, "Confidential Information" means all confidential and proprietary information of a party
("Disclosing Party") disclosed to the other party ("Receiving Party"), whether orally or in writing, that is
designated as confidential or that reasonably should be understood to be confidential given the nature of the
information and the circumstances of disclosure. Confidential Information includes, without limitation, the
Products, their performance (including any benchmarking information) and Impervas pricing for direct sales
of its Products and Services. Confidential Information shall not include any information that: (i) is or
becomes generally known to the public without breach of any obligation owed to the Disclosing Party; (ii) was
known to the Receiving Party prior to its disclosure by the Disclosing Party without breach of any obligation
owed to the Disclosing Party; (iii) was independently developed by the Receiving Party without breach of any
obligation owed to the Disclosing Party; or (iv) is received from a third party without breach of any obligation
owed to the Disclosing Party.
The Receiving Party agrees that it will (i) use Confidential Information for the sole purpose of exercising its
rights and performing its obligations under this Agreement, (ii) divulge Confidential Information only to those
of its employees, contractors, directors, independent consultants and agents who have a need to know such
Confidential Information and who are bound by professional duty or in writing (in advance) to confidentiality
and non-use obligations at least as protective of such information as this Agreement, and (iii) not disclose any
Confidential Information to any third party. The Receiving Party shall notify and cooperate with the Disclosing
Party immediately upon discovery of any unauthorized use or disclosure of Confidential Information of the

c.

d.

8.

Proprietary Rights; Indemnity.


a.

b.

9.

All title and intellectual property rights in and to the Products are 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. Any ideas, suggestions, modifications and the like made by End User with
respect to a Product will be the property of Imperva regardless of whether Imperva chooses to exercise its
rights to incorporate such ideas, suggestions or modifications into the Product.
Subject to the remainder of this Section 7.b, Imperva will indemnify End User from any Liability (as defined
below) to a third party resulting from infringement of a U.S. patent or any copyright, or misappropriation of
any third party trade secrets by the Product as delivered (Infringement Claim); provided that End User
(1) promptly notifies Imperva of any and all threats, claims and proceedings of such Infringement Claim, (2)
gives reasonable assistance in response to Impervas request for assistance, and (3) grants Imperva sole
control over defense and settlement thereof. For purposes of this section Liability means the resulting costs
(including reasonable attorneys fees) and damages awarded against End User to the third party making such
Infringement Claim, by a court of competent jurisdiction or agreed in settlement. The foregoing obligations
do not apply with respect to Products or portions or components thereof, (i) that are modified after delivery by
Imperva, (ii) combined with other products, processes or materials, where the alleged infringement relates to
such combination, (iii) where End User continues allegedly infringing activity after being notified thereof and
modifications that would have avoided the alleged infringement have been made available to End User, or (iv)
where End Users use of such Product is not strictly in accordance with this Agreement. In the event that
Products are held to or believed by Imperva to infringe, Imperva at its discretion, will have the option to (A)
modify the allegedly infringing Products to be non-infringing, (B) obtain for End User a license to continue
using the Products, or (C) request the return of the Product and upon receipt thereof terminate this
Agreement as to the infringing Product and refund to End User the unused portion of the fees paid under this
Agreement for such Subscription Services or a pro rata portion of fees paid for the infringing Software or
Appliance, depreciated on a straight-line basis over a three (3) year period. End User will defend, indemnify
and hold Imperva harmless against any claims, damages settlements and expenses (including attorneys fees)
excluded from Impervas indemnity obligations in (i) (iv) above. THIS SECTION SETS FORTH IMPERVAS
SOLE OBLIGATION AND END USERS SOLE AND EXCLUSIVE REMEDY IN THE EVENT OF VIOLATION OF
THIRD PARTY RIGHTS.

Warranty and Disclaimer.


a.

Disclosing Party. The Receiving Party may disclose Confidential Information to comply with an order from a
court of competent jurisdiction or with a mandatory requirement of a governing regulatory body, provided
such party, to the extent permitted by law and as soon as reasonably practicable under the circumstances,
informs the Disclosing Party and allows the Disclosing Party the opportunity to object to the disclosure order
or to take action to preserve the confidentiality of the information. The Receiving Party shall cooperate with
the Disclosing Party in such partys reasonable efforts to limit the disclosure of the information. End User
acknowledges, understands and agrees that Imperva may, as part of its provision of the Product and/or
Services to End User, collect, store and use information obtained from End User, including, but not limited to,
information about End Users users and customers (Information) for the purposes of the provision of the
Product, Services and other services to End User and may use such information for analysis and improvement
of Impervas products and services. End User represents and warrants that it has all rights and permissions
necessary to transfer such Information and to grant Imperva access to such Information as contemplated
herein.
Upon termination of this Agreement for any or no reason, the Receiving Party shall (i) immediately cease all
use of the Disclosing Party's Confidential Information, (ii) upon request from the Disclosing Party, either
promptly destroy all Confidential Information of the Disclosing Party or return all Confidential Information of
the Disclosing Party. Notwithstanding the foregoing, both parties agree that the Receiving Party may retain
copies of the Confidential Information that are necessary for (i) satisfying legal or regulatory requirements;
and (ii) archiving consistent with good business practices, provided that the Receiving Partys obligations of
confidentiality and restricted use under this Agreement shall continue with respect to such retained copies.
If the Receiving Party discloses or uses (or threatens to disclose or use) any Confidential Information of the
Disclosing Party in breach of this Section 7, the Disclosing Party shall have the right, in addition to any other
remedies available to it, to seek injunctive relief to enjoin such acts, it being specifically acknowledged by the
parties that any other available remedies are inadequate.

Imperva warrants that during the sixty (60) day period commencing on the date of first Delivery, the Software
and the Appliances will perform substantially in accordance with their Documentation. In the event of a

b.

breach of the foregoing warranty with respect to the Software, as End Users sole and exclusive remedy,
Imperva shall, at its sole expense, use reasonable efforts to modify the Software, so that it performs
substantially in accordance with its Documentation. In the event of a breach of the foregoing warranty with
respect to an Appliance, as End Users 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 errors or damage caused by misuse of the Products. The rights and remedies
granted End User under this Section state Impervas entire liability, and End Users exclusive remedy, with
respect to any breach of the warranty set forth in this Section 9(a).
EXCEPT AS EXPRESSLY SET FORTH IN SECTION 9(a), THE PRODUCTS OR 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
OR 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 END USERS OR IMPERVAS (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 END USER OR IMPERVA (OR ITS
PARTNERS OR SUPPLIERS) HAVE ANY LIABILITY TO THE OTHER FOR ANY LOST PROFITS OR REVENUES, LOSS
OF DATA OR 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. THE FOREGOING LIMITATIONS SHALL
NOT APPLY TO END USER WITH RESPECT TO ANY CLAIMS ARISING UNDER SECTION 2 (LICENSES AND
RESTRICTIONS), OR TO EITHER PARTY UNDER SECTION 7 (CONFIDENTIALITY).
11. Term and Termination.
a.

b.

c.

The term of this Agreement will commence upon Delivery of the Products to End User and will continue in
effect for such time as End User continues to have the right to access the Products. Support for Software
and/or Appliances will automatically renew at the end of the applicable Support 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.
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 Subscription Services) or Section 7 (Confidentiality).
Upon the earlier of expiration of End Users rights or termination of the Agreement, Imperva will cease
providing Subscription Services, Support and Professional Services, and each party shall promptly return or
destroy the other partys Confidential Information in accordance with Section 7 above. 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),
2(d), 2(f), 4, 6 -12, and 16.

12. Compliance with Laws; Export. End User acknowledges that the Software contains encryption technology that
is subject to export restrictions by the U.S. government and import restrictions by certain other governments. End
User will not and will not allow any third-party to remove or export from the U.S. or allow the export or re-export
of any part of the Software or any direct product thereof: (i) into (or to a national or resident of) Cuba, Iran, North
Korea, Sudan or Syria (to the extent the U.S. government or any agency thereof restricts export or re-export to
such countries); (ii) to anyone on the U.S. Commerce Departments Table of Denial Orders or U.S. Treasury
Departments list of Specially Designated Nationals; (iii) to any country to which such export or re-export is
restricted or prohibited, or as to which the U.S. government or any agency thereof requires an export license or
other governmental approval at the time of export or re-export without first obtaining such license or approval; or
(iv) otherwise in violation of any export or import restrictions, laws or regulations of any U.S. or foreign agency or
authority. End User agrees to the foregoing and warrants that it is not located in, under the control of, or a
national or resident of any such prohibited country or on any such prohibited party list. The Software is restricted
from being used for the design or development of nuclear, chemical, or biological weapons or missile technology
without the prior permission of the U.S. government. End User agrees to indemnify and hold Imperva, its partners
and suppliers harmless against any claims, losses or expenses arising out of End Users breach of this Section 12.

13. End User Mention. End User consents to Imperva using its name and logo to identify End User as a customer of
Imperva, such as use on Impervas web site. Any use shall be subject to Imperva complying with any guidelines
that End User may deliver to Imperva from time-to-time regarding the use of its name and logo. This consent
terminates upon termination of this Agreement.
14. Force Majeure. Neither party will be liable to the other for any delay or failure to perform any obligation under
this Agreement (except for a failure to pay fees) if the delay or failure is due to unforeseen events, which occur
after the signing of this Agreement and which are beyond the reasonable control of the parties, such as strikes,
blockade, war, terrorism, riots, natural disasters, government order, refusal of license by the government or other
governmental agencies, in so far as such an event prevents or delays the affected party from fulfilling its
obligations and such party is not able to prevent or remove the force majeure at reasonable cost.
15. Evaluation.
a.

b.

a.

Evaluation Product. If the order is for End User to evaluate Product and its related Documentation on a
temporary basis for non-commercial use (Evaluation Product) and Imperva agrees to such evaluation,
conditioned on End Users compliance with the terms and conditions of this Agreement, Imperva grants to End
User during the Evaluation Period (as defined below), a nonsublicensable, nontransferable, nonassignable and
nonexclusive, revocable license to use the Evaluation Product, solely at the location identified in writing by
End User and solely for End Users internal evaluation of the Evaluation Product. End User may only grant
access to the Evaluation Product to employees, contractors, agents or consultants who are bound to
confidentiality and non-use obligations no less protective of Impervas proprietary rights than this Agreement.
Notwithstanding anything to the contrary as stated in this Agreement, all worldwide right, title and interest to
the Evaluation Product, and all intellectual property rights in and to such product, are and will remain the
exclusive property of Imperva.
Evaluation Period. Unless otherwise agreed to by the parties in writing or terminated earlier in accordance
with this Agreement, an evaluation shall commence upon delivery of the Evaluation Product and continue for
thirty (30) days thereafter (Evaluation Period). Upon the expiration or termination of the Evaluation Period,
(i) all licenses granted under this Section 15 for such evaluation will cease, and (ii) End User will immediately
return the Evaluation Product to Imperva and destroy or erase any intangible copies of the Evaluation Product,
and certify in a writing signed by an officer of End User and delivered to Imperva that all such copies of have
been returned, destroyed or erased.
Additional Evaluation Terms. Notwithstanding anything to the contrary as contained in this Agreement,
End User acknowledges and agrees that the Evaluation Product is provided for evaluation AS-IS and Imperva
and its suppliers make no representations or warranties of any kind, express or implied, with respect to the
Evaluation Product, including, without limitation, any implied warranties of merchantability, title, fitness for a
particular purpose, informational content, system integration, enjoyment, non-infringement or any other
warranties arising out of course of dealing, usage or trade, and no obligation under Section 8.b (Indemnity)
shall arise with respect to an Evaluation Product.

16. Miscellaneous Provisions. The parties are independent contractors under this Agreement and nothing in this
Agreement authorizes a party to act as an agent of the other or bind the other to any transaction or agreement.
This Agreement will bind and inure to the benefit of each partys permitted successors and assigns. Neither party
may assign or transfer this Agreement in whole or in part by operation of law or otherwise, without the other
partys prior written consent. Any attempt to transfer or assign this Agreement without such written consent will be
null and void. Notwithstanding the foregoing, however, Imperva may assign this Agreement without consent to
the acquiring or surviving entity in a merger or acquisition in which Imperva is the acquired entity (whether by
merger, reorganization, acquisition or sale of stock) or to the purchaser of all or substantially all of Impervas
assets. Impervas licensors are intended third party beneficiaries of this Agreement. In the event any provision of
this Agreement shall be determined to be invalid or unenforceable under law, all other provisions of this
Agreement shall continue in full force and effect. Except as specifically provided in this Agreement, the exercise by
either party of any rights and remedies under this Agreement will be without prejudice to its other remedies under
this Agreement or otherwise. This Agreement contains the entire agreement of the parties with respect to the
subject matter of this Agreement and supersedes all previous communications, representations, understandings
and agreements, either oral or written between the parties with respect to said subject matter. This Agreement
may be modified or waived only in a written instrument signed by both parties. A waiver of any breach under this
Agreement shall not constitute a waiver or any other breach or future breaches. Notwithstanding the foregoing, if
a separate, written and mutually signed agreement for the acquisition of the Products and/or Services exists
between End User and Imperva, the terms of that written agreement (excluding any pre-printed terms of any
purchase order, confirmation or similar document, all of which will have no effect and will not be considered agreed
to by Imperva) shall take precedence over this Agreement. All notices, requests, demands and other
communications hereunder shall be in writing to the address set forth below for Imperva and on the applicable

order or registration form for End User and shall be deemed to have been duly given: (i) upon receipt if by
personal delivery; (ii) upon receipt if sent by certified or registered mail (return receipt requested); or (iii) two (2)
days after it is sent if by overnight delivery by a major commercial delivery service. This Agreement will be
interpreted and construed in accordance with the laws of the State of California and the United States of America,
without regard to conflict of law principles. The parties hereby consent to the exclusive jurisdiction and venue of
the state and federal courts located in Santa Clara County, California for resolution of any disputes arising out or
relating to this Agreement. The provisions of the United Nations Convention on Contracts for the International Sale
of Goods and the Uniform Computer Information Transactions Act will not apply to this Agreement in any manner
whatsoever.
Imperva, Inc.
3400 Bridge Parkway, Suite 200
Redwood Shores, CA 94065 USA
Revised October 2014

10

Table of Contents
About this Document.......................................................................................................... 14
Intended Audience ................................................................................................................ 14
Assumptions ......................................................................................................................... 14
Reference Documents ........................................................................................................... 14
Notes on Upgrading ........................................................................................................... 15
Estimated Upgrade Time ....................................................................................................... 15
The SecureSphere Operating System ...................................................................................... 15
Upgrade Path ....................................................................................................................... 15
New and Enhanced Features .......................................................................................... 15
Upgrading SOM ............................................................................................................. 15
Upgrading VMware Environments .................................................................................... 16
Upgrading Cluster Environments ..................................................................................... 16
Backup Directory .................................................................................................................. 16
Upgrade Sequence - What to Upgrade First ............................................................................ 17
Upgrading From Versions Prior to Version 9.0 .................................................................. 17
Upgrading From Version 9.0 and Later ............................................................................ 17
Mandatory Pre-Upgrade Checklist ..................................................................................... 18
Feature Specific Pre-Upgrade Checklist ............................................................................. 20
Upgrade Procedures ........................................................................................................... 21
Upgrading a SecureSphere Management Server or Onebox ...................................................... 21
Upgrading a SecureSphere Gateway (not relevant to Onebox Deployment) ............................... 28
Updating to the Latest Patch ............................................................................................. 31
Post Upgrade Procedures ................................................................................................... 32
Resetting User Passwords ...................................................................................................... 32
Enabling Activate Settings ..................................................................................................... 32
Reconnecting a SAN Device ................................................................................................... 33
Restore the Reverse Proxy Apache Configuration .................................................................... 34
Installing/Updating Mod-SSL ........................................................................................... 34
Enabling the Data Owner Portal ............................................................................................. 36
Verifying Maintenance License has not Expired ................................................................ 37
Updating to the Latest ADC Content ................................................................................ 37
Notifying Imperva Support .................................................................................................... 37
Installing the Latest Patch ..................................................................................................... 37
Applying and Disabling Activate Settings .......................................................................... 38
Applying Settings Which Have Yet to be Applied ............................................................... 38
Disabling Activate Settings .............................................................................................. 38
Backing Up the System ......................................................................................................... 38
Backup Audit Files .......................................................................................................... 39
Obtaining the SecureSphere Upgrade Packages ...................................................................... 39
Unmounting SAN Devices ...................................................................................................... 40
Running the Test Install Script ............................................................................................... 40
nCipher Card ........................................................................................................................ 41
nCipher NetHSM ................................................................................................................... 43
Verifying the Ethernet Driver in Use in a VM Deployment .................................................. 43
Pre-Installation Limitations ............................................................................................... 46
Action Sets ........................................................................................................................... 46
Archive Settings .................................................................................................................... 46
ARP (Apache Reverse Proxy) - Keys ....................................................................................... 46
Connectivity to Protected Servers ........................................................................................... 46
Execution History .................................................................................................................. 46
Gateway Groups ................................................................................................................... 47
Hard Disk Identifier ............................................................................................................... 47
Host Names .......................................................................................................................... 47
Jobs ..................................................................................................................................... 47
KRP - Onboard Interface ....................................................................................................... 47
KRP - Protected IP Addresses Not Linked to KRP Rules Deleted after Upgrade ........................... 47

Table of Contents

Learning Statistics ................................................................................................................. 47


Log Collector ........................................................................................................................ 47
Non-Admin CLI Users ............................................................................................................ 47
Plugins ................................................................................................................................. 48
Read-Only User .................................................................................................................... 48
Revoking Permissions on SharePoint URM Scan ....................................................................... 48
Revoking Permissions on File URM Scan ................................................................................. 48
SharePoint ............................................................................................................................ 48
SNMP ................................................................................................................................... 48
SSL Keys .............................................................................................................................. 48
System Event Archiving ......................................................................................................... 49
Synchronizing with Active Directory Users before File/SharePoint URM Scan .............................. 49
Post Installation Limitations .............................................................................................. 50
Activate Settings ................................................................................................................... 50
Browser Default Page for SecureSphere .................................................................................. 50
Configuration Files ................................................................................................................ 50
Data Owner Portal - URM Scans ............................................................................................. 50
File Policies ........................................................................................................................... 50
File Audit Data ...................................................................................................................... 51
File URM Review Results ........................................................................................................ 51
IP Rules ............................................................................................................................... 51
MySQL ................................................................................................................................. 51
Routes ................................................................................................................................. 51
SCP Action Interface ............................................................................................................. 51
SSH Keys ............................................................................................................................. 52
Stream Dictionary Policies ...................................................................................................... 52
Uploading the Encryption Keys ............................................................................................... 57
nss.conf and http.conf files .................................................................................................... 60
Identifying the Physical IP address for use with VRRP ..................................................... 66
Resetting the Password for the 'admin' User in the GUI ................................................... 72
Resetting the Password for User 'admin' During Upgrade................................................. 73

12

SecureSphere Version 11.0 Migration Guide

Upgrading SecureSphere
Version 11.0
This upgrade guide is intended as a guide for administrators tasked with upgrading SecureSphere and
migrating installations of earlier versions of Imperva SecureSphere to version 11.0. It includes the following
information:

About this Document on page 14

Notes on Upgrading on page 15

Mandatory Pre-Upgrade Checklist on page 18

Feature Specific Pre-Upgrade Checklist on page 20

Upgrade Procedures on page 21

Updating to the Latest Patch on page 33

Post Upgrade Procedures on page 35

Version 11.0 Migration Guide

13

Chapter 1 - Upgrading SecureSphere Version 11.0

About this Document


This guide comprises full explanations of the upgrade process to SecureSphere version 11.0 from
SecureSphere version 9.0 and higher. It details specific tasks involved in the upgrade process.

Note: This guide describes how to upgrade from an appliance on which the First Time Login has
already been successfully completed.

Intended Audience
This document is intended for administrators setting up and provisioning SecureSphere.

Assumptions
The document assumes basic understanding of system administration and knowledge of how to operate
SecureSphere.

Reference Documents

SecureSphere User Guides


Provide information on how to configure and maintain SecureSphere.

SecureSphere Administration Guide


Provides information on how to administer and maintain SecureSphere.

Quick Start Guides


Separate Quick Start Guides are supplied with appliances and should be used for the installation process.

14

Version 11.0 Migration Guide

Notes on Upgrading

Notes on Upgrading
This section contains basic information regarding the upgrade.

Estimated Upgrade Time


Average upgrade takes about 3 hours, with upgrade of extremely large amounts of data or upgrades in highload environments sometimes taking as long as 5 hours.

The SecureSphere Operating System


This version of SecureSphere uses an OS based on CentOS 6.3. Whenever you upgrade to this version of
SecureSphere, CentOS 6.3 will be installed from scratch. Note that this is the first version of SecureSphere
that uses CentOS 6.3.

Upgrade Path
Note: In order to obtain assistance from Support when upgrading, you must be running a version
currently supported by Imperva. The oldest SecureSphere version supported is v9.0. If you are
running a version older than v9.0, you must upgrade independently to v9.0, then Imperva support can
assist upgrading to v11.0.

The following table describes the upgrade path, which depends on the SecureSphere version from which you
are upgrading.
Version from which you
are upgrading
9.0 and higher

Upgrade Path

Upgrade directly to this version, as described in Feature Specific PreUpgrade Checklist on page 20.

New and Enhanced Features


Before upgrading, you should read the latest version of the release notes for each new SecureSphere version
since your previous installation. So for example, if you are upgrading from v10.0 to 11.0. You should read the
release notes for v10.5 and v11.0. This is to become familiar with new features that have been added, and
changes that have been made in the design of existing features.

Upgrading SOM
When upgrading a SOM configuration, the correct upgrade sequence is as follows:
1.

Gateways

2.

SOM

3.

Management Servers

Note: SOM-MX backward compatibility requires SOM 10.0 and MX 9.5 p3.

Version 11.0 Migration Guide

15

Chapter 1 - Upgrading SecureSphere Version 11.0

Upgrading VMware Environments


Users running SecureSphere Server in a virtual environment with 80GB of disk space who want to upgrade to
v11.0 are recommended to increase disk size to 160GB. For instructions on how to add disk space to a
VMware environment, see Configuring Disk Space in the SecureSphere on Virtual Appliance Configuration
Guide.

Upgrading Cluster Environments


When upgrading from v10.5 to v11.0 (including when working with mixed versions), you must first install the
latest v10.5 patch on all cluster members (including the SecureSphere Management Server). You then need
to upgrade the cluster according to the instructions in the Database User Guide titled Upgrading Cluster
Software.

Backup Directory
If you have modified any system files (for example, hades.cfg), the modified file (the file from before the
upgrade) will be saved in the backup directory. It is your responsibility to edit the newly-installed system file
and modify it accordingly.
In the course of the upgrade to the new version, SecureSphere saves the configuration files from the previous
version in the following directory:
/var/SecureSphere/upgrades/upgrade-11.0.0.<PATCH_NUM>_0.<BUILD_NUM>/backup

16

Version 11.0 Migration Guide

Notes on Upgrading

Upgrade Sequence - What to Upgrade First


The following lists what should be upgraded first based on product and version.

Upgrading From Versions Prior to Version 9.0


When upgrading SecureSphere Server and SecureSphere Gateway separately from versions prior to version
9.0, first upgrade the SecureSphere Management Server. Once the upgrade of the SecureSphere Management
Server is completed, upgrade the Gateway.
The reason is that when the SecureSphere Gateway is installed, it must register with the Management Server,
so the Management Server must already be available and running. After the Management Server is running
with the newer version, the Gateways should be running with last known good configuration until they are
upgraded and receive the new configuration from the Management Server.
If you upgrade the Gateway first, then you may receive a warning message that the Gateway has reverted to
the last known configuration. In this case, upgrade the Management Server and restart the Gateway.

Upgrading From Version 9.0 and Later


When you are upgrading SecureSphere Server and SecureSphere Gateway separately from version 9.0 and
later, you should upgrade the Gateway first. This is because the 9.5 and later Gateway can work with 9.0 and
later Management Server. You can then upgrade the Management Server at your convenience.

Note: When upgrading an MX-HA environment, you must first remove the MX-HA configuration and
only then proceed with upgrade. For more information see Guidelines for MX-HA Upgrade on page 67.

Version 11.0 Migration Guide

17

Chapter 1 - Upgrading SecureSphere Version 11.0

Mandatory Pre-Upgrade Checklist


This section lists steps that you must conduct before starting the upgrade. Furthermore, depending on your
environment, there may be additional steps you need to take. Additional steps can be seen in the section
Feature Specific Pre-Upgrade Checklist on page 20.

Step

18

Action

Description

For more information, see

Install the latest patch for


the SecureSphere version
you are running.

Verifies that SecureSphere is up


to date with latest fixes before
upgrading.

Installing the Latest Patch on


page 38

Verify your maintenance


license has not expired.

If your maintenance license has


expired, contact your Imperva
sales representative.

Verifying Maintenance License


has not Expired on page 37

Update to the latest ADC


content.

Verify SecureSphere has the


latest ADC Content.

Updating to the Latest ADC


Content on page 37

Backup your SecureSphere


configuration.

Backup Audit Files.

Backup SecureSphere so it can be


restored if needed.

Backing Up the System on


page 39

If backing up a VMware based


SecureSphere, take a snapshot
before upgrade.

Backup Audit Files on page 39


Notify the Imperva Support Team
by opening an Upgrade Validation
case in the Customer Support
portal before upgrading your
system.

Notifying Imperva Support on


page 37

Notify Imperva support.

If you are working in


delayed activation mode
(Activate Settings), apply
settings and disable.

Download the latest


SecureSphere Upgrade
Package.

If your appliance has at least 4GB


of RAM, you must upgrade to the
64-bit version of SecureSphere.
Recommended saving to /var/tmp

Obtaining the SecureSphere


Upgrade Packages on page 39

Unmount any SAN Device.

If you use a SAN device, it needs


to be unmounted, configured and
unplugged.

Unmounting SAN Devices on


page 40

10

Make sure you know the


SecureSphere GUI admin
password (for the user
admin).

At a later point in the upgrade


process, you will need to login to
the SecureSphere GUI.

Resetting the Password for


User 'admin' During Upgrade
on page 73.

11

Remove or unplug all


removable media such as
USB drives, etc.

This step ensures that the


appliance will not attempt to boot
from the removable media.

N/A

12

If you are using MX-HA,


follow the instructions
uninstall MX-HA.

Upgrade should not be conducted


in MX-HA environments. Uninstall
MX-HA before proceeding with
upgrade.

Appendix G, Guidelines for


MX-HA Upgrade

Apply all settings which have


been made to SecureSphere.
Disable activate settings
feature

Applying and Disabling


Activate Settings on page 38

Version 11.0 Migration Guide

Mandatory Pre-Upgrade Checklist

Step

Action

Description

For more information, see

13

Review pre-upgrade
limitations.

A number of features have


aspects that are not carried over
through upgrade. It is important
to review these limitations so you
know what to expect once
upgrade is complete.

Pre-Installation Limitations on
page 46

14

On the Management
Server, verify that the /
var partition has at least
25GB of free space.

This partition is used to backup


the system configuration dump
file, reports, and more.

df h
If the /var partition has less
than 25GB of free disk space,
contact the Imperva Support
Team.

Version 11.0 Migration Guide

19

Chapter 1 - Upgrading SecureSphere Version 11.0

Feature Specific Pre-Upgrade Checklist


While the items listed in the Mandatory Pre-Upgrade Checklist on page 18 list steps that need to be taken by
all users. The below table reviews additional tasks you may need to conduct pre-upgrade, depending on the
features you use in your implementation of SecureSphere.
Step

20

Action

Description

For more information, see

If you are upgrading


SecureSphere on VMware
ESX, then verify you are
using the right driver.

SecureSphere supports the


VMXNET 3 Network Interface
driver. You should verify that this
is the driver being used by your
network interfaces in VMware.

Verifying the Ethernet Driver


in Use in a VM Deployment on
page 43

If you have modified the


/etc/rc.local file,
back it up.

If you are using the bash


shell, backup the

.bashrc file.

Backup CA and web server


keys.

Backup OS scripts used in


action interfaces of type
OS command.

This file contains information


about ARP settings, IP routes,
and IP rules.

IP Rules on page 51

This file is not migrated to the


new configuration, and you have
to manually restore it.
This file is not migrated to the
new configuration, and you will
have to manually restore it.
These files are not migrated to
the new configuration, and you
will have to manually restore
them.
It is recommended that you
export them from your web
server and have them ready for
upload once upgrade is complete.
These scripts are not migrated to
the new configuration, and you
will have to manually restore
them.

Version 11.0 Migration Guide

Upgrade Procedures

Upgrade Procedures
Note: For information on upgrading SecureSphere on Amazon AWS, see the SecureSphere on Amazon
AWS Configuration Guide.

This section provides step-by-step procedures on the following:

Upgrading a SecureSphere Management Server or Onebox on page 21

Upgrading a SecureSphere Gateway (not relevant to Onebox Deployment) on page 28

Updating SecureSphere from 32 bit to v11.0 64 bit on page 32

Upgrading a SecureSphere Management Server or Onebox


Notes before starting:

If you are working with a version earlier than v9.0 please upgrade to at least version v9.0. Then run the
upgrade to version 11.0

If your upgrade fails, DO NOT RESTART SecureSphere. Contact support immediately

If your hostname is localhost, during upgrade you will be asked to provide another name for the
machine. If you do not provide another name, the hostname will be changed to secure

To upgrade a SecureSphere Management Server or Onebox:


1.

Complete the Mandatory Pre-Upgrade Checklist on page 18.

2.

Login as root.
Notes:

If you are using an SSH client (for example, putty), it is recommended to change the keep alive
time on the SSH client to 1, thus making sure to send NULL packets to keep session active.
This is done from the connection menu in the SSH tool configuration properties.

By default, you cannot connect to the appliance as root or secure over SSH. To login as
root, you must first connect as a CLI user and use the admin command. You can specify an IP
address from which the user root is allowed to login over SSH with the following command:

impctl hardening config --root-source-ip-exception=<IP


address>
3.

Navigate to the folder where you saved the upgrade package (recommended /var/tmp).

4.

Run following command:


rpm -ivh <UpgradePackageFilename>

Version 11.0 Migration Guide

21

Chapter 1 - Upgrading SecureSphere Version 11.0

The file is unzipped and installed. Est. time: 5 minutes. The following is
displayed.

Note: If you encounter a message stating something similar to internal.noarch needs


2321MB on the /var filesystem it means you dont have enough disk space and upgrade is
aborted. You then need to delete items under /var to free up disk space, then run upgrade again.
If you need assistance in determining what to delete, please contact Imperva Support.

5.

Navigate to the folder where the upgrade package was unzipped, as follows:
cd /var/SecureSphere/upgrades/[new-upgrade-folder]/bin

6.

Execute the following command:


./install
The Welcome Page is displayed, as follows:

7.

Press any key to continue. The End User License Agreement is displayed.

8.

Read the License Agreement, and press the spacebar to scroll through it. Once complete, type Accept,
then press Enter.

9.

Type a new root password. Note: you can use your current root password.
Note: Starting with version 10.0 the following special characters are supported in passwords:
* ( ) - + = @ $ & # % ^ : / ~ , _ .
This password policy is applied during the upgrade procedure and if an unsupported special
character is identified, then the procedure is stopped.

Pre installation tests are run. These tests run for about 30 minutes. They prepare the SecureSphere for
upgrade. While running, the upgrade log is displayed on the screen.

22

Version 11.0 Migration Guide

Upgrade Procedures

Warning: Do not reboot the machine or press any keys until instructed.

Once completed, you are told that the the system is going down for reboot now, while your computer
also displays a message stating the network connection was lost. This is because the server is rebooting.

Once the server reboots, installation continues. However, to see installation progress, you can connect via
VNC. For instruction on how to connect via VNC, see Monitoring Installation Status with VNC on page 53.

Note: On some platforms, you may need to connect via telnet or locally with a KVM, at which
time you should choose the management interface from the menu that appears.

10. Once OS installation is completed and VNC has closed, or after about 20 minutes, reconnect via SSH. If
the login doesnt display your localhost name or welcome information, try again after two minutes.
11. Once you're back in SSH, type the following command to watch the status of the upgrade:
UpgradeLogStatus, or

Version 11.0 Migration Guide

23

Chapter 1 - Upgrading SecureSphere Version 11.0

tail -f /var/SecureSphere/upgrades/upgrade-11.0.0.[PatchNumber]/bin/
upgrade.log
Once the installation is completed, you get the message Please Manually reboot the appliance. This
message indicates that the upgrade was successful.
If instead of the message indicating that the upgrade was successful, you receive message stating that
the upgrade failed, as seen at the end of the following message, do not continue with the upgrade
and contact Imperva Support for further instructions.

24

Version 11.0 Migration Guide

Upgrade Procedures

12. If installation was completed successfully, before rebooting do the following:

When mounts are used, re-mount all previously configured mounts. Follow the instructions in the
relevant configuration guide. You must change the var-dir and audit-base-path parameters
in the bootstrap.xml file to point to the mounted directory where your pre-upgrade audit data is
located.

If your appliance has a SAN device, reconnect it as described in Reconnecting a SAN Device on
page 31.

13. Type ctrl+c to get a prompt, then type Reboot and press Enter.

Note: Reboot and continue with the following steps only if the upgrade process completes
without any warnings of manual changes in the system.

14. Reconnect to the appliance via SSH. You are displayed the following message asking you to browse to the
SecureSphere Management Server:

15. When the SecureSphere Management Server is started and its status is running, browse to:
https://[Management Server IP address]:8083
16. Read the End User License Agreement and click Accept.

17. Enter the password for the user admin as shown in the following.

Note: You may have several GUI users with administrative privileges, but the user whose
password you should enter here is the one named admin.

Version 11.0 Migration Guide

25

Chapter 1 - Upgrading SecureSphere Version 11.0

18. Confirm that you would like to upgrade from the previous version by clicking Yes.

If you choose not to upgrade, all previous data is lost. Upgrade takes between one to four hours to
complete depending on the size of your deployment.
The following message appears once the upgrade is complete:

If the following message appears, do not continue but instead contact Imperva support for further
instructions.

19. If no errors occurred, open ssh, then type reboot to reboot the appliance.
20. Access the SecureSphere GUI.

26

Version 11.0 Migration Guide

Upgrade Procedures

21. Update the ADC content as follows:


21.1

Go to Admin > ADC.

21.2

Download the ADC content file from the Imperva web site.

21.3

Upload it to the system.

22. Conduct any post-upgrade procedures that may be relevant to your deployment as described in Post
Upgrade Procedures on page 29.

Version 11.0 Migration Guide

27

Chapter 1 - Upgrading SecureSphere Version 11.0

Upgrading a SecureSphere Gateway (not relevant to Onebox Deployment)


Notes before starting:

If you are working with a version earlier than v9.0 please upgrade to at least version v9.0. Then run the
upgrade to version 11.0

If your upgrade fails, DO NOT RESTART SecureSphere. Contact support immediately

If your hostname is localhost, during upgrade you will be asked to provide another name for the
machine. If you do not provide another name, the hostname will be changed to secure

To upgrade a Gateway:
1.

Complete the Mandatory Pre-Upgrade Checklist on page 18.

2.

Login as root.
Notes:

If you are using an SSH client (for example, putty), it is recommended to change the keep alive
time on the SSH client to 1, thus making sure to send NULL packets to keep session active.
This is done from the connection menu in the SSH tool configuration properties.

By default, you cannot connect to the appliance as root or secure over SSH. To login as
root, you must first connect as a CLI user and use the admin command. You can specify an IP
address from which the user root is allowed to login over SSH with the following command:

impctl hardening config --root-source-ip-exception=<IP


address>
3.

Navigate to the folder where you saved the upgrade package (recommended /var/tmp).

4.

Run following command:


rpm -ivh <UpgradePackageFilename>
The file is unzipped and installed. Est. time: 5 minutes. The following is
displayed.

Note: If you encounter a message stating something similar to internal.noarch needs


2321MB on the /var filesystem it means you dont have enough disk space and upgrade is
aborted. You then need to delete items under /var to free up disk space, then run upgrade again.
If you need assistance in determining what to delete, please contact Imperva Support.

5.

Navigate to the folder where the upgrade package was unzipped, as follows:
cd /var/SecureSphere/upgrades/[new-upgrade-folder]/bin

6.

Execute the following command:


./install

28

Version 11.0 Migration Guide

Upgrade Procedures

The Welcome Page is displayed, as follows:

7.

Press any key to continue. The End User License Agreement is displayed.

8.

Read the License Agreement, and press the spacebar to scroll through it. Once complete, type Accept,
then press Enter.

9.

Type a new root password. Note: you can use your current root password.
Note: Starting with version 10.0 the following special characters are supported in passwords:
* ( ) - + = @ $ & # % ^ : / ~ , _ .
This password policy is applied during the upgrade procedure and if an unsupported special
character is identified, then the procedure is stopped.

Pre installation tests are run. These tests run for about 30 minutes. They prepare SecureSphere for
upgrade. While running, the upgrade log is displayed on the screen.

Warning: Do not reboot the machine or press any keys until instructed.

Once completed, you are told that the the system is going down for reboot now, while your computer
also displays a message stating the network connection was lost. This is because the gateway is
rebooting.

Version 11.0 Migration Guide

29

Chapter 1 - Upgrading SecureSphere Version 11.0

Once the gateway reboots, installation continues. However, to see installation progress, you can connect
via VNC. For instruction on how to connect via VNC, see Monitoring Installation Status with VNC on
page 53.

Note: On some platforms, you may need to connect via telnet or locally with a KVM, at which
time you should choose the management interface from the menu that appears.

10. Once OS installation is completed and VNC has closed, or after about 20 minutes, reconnect via SSH.
11. Once you're back in SSH, type the following command to watch the status of the upgrade:
UpgradeLogStatus, or
tail -f /var/SecureSphere/upgrades/upgrade-11.0.0.[PatchNumber]/bin/
upgrade.log
Once the installation is completed, you get the message Please Manually reboot the appliance. This
message indicates that the upgrade was successful.
If instead of the message indicating that the upgrade was successful, you receive message stating that
the upgrade failed, as seen at the end of the following message, do not continue with the upgrade
and contact Imperva Support for further instructions.

30

Version 11.0 Migration Guide

Upgrade Procedures

12. If installation was completed successfully, before rebooting do the following:

When mounts are used, re-mount all previously configured mounts. Follow the instructions in the
relevant configuration guide. You must change the var-dir and audit-base-path parameters
in the bootstrap.xml file to point to the mounted directory where your pre-upgrade audit data is
located.

If your appliance has a SAN device, reconnect it as described in Reconnecting a SAN Device on
page 31.

13. If no errors occurred, type ctrl+c to get a prompt, then type Reboot and press Enter.

Note: If the gateway includes audit data, it is converted in the background.


The Gateways tab in the GUI reflects the progress of this procedure.

14. Conduct any post-upgrade procedures that may be relevant to your deployment as described in Post
Upgrade Procedures on page 29.

Version 11.0 Migration Guide

31

Chapter 1 - Upgrading SecureSphere Version 11.0

Updating SecureSphere from 32 bit to v11.0 64 bit


This section reviews how to upgrade from SecureSphere version v10.5 32 bit to SecureSphere v11.0 64 bit.

Upgrading SecureSphere
The upgrade process is identical for both MX and Gateway. It is a multi-step process:

Bring up a second server and install the new SecureSphere version on this server

Export the original server configuration

Bring down the old server

Import the old server configuration to the new server

Note: The second and third steps can be combined. See below.

Exporting the Server Configuration


Notes:

In order to export the server and conduct the upgrade, you must be using SecureSphere version
10.5 Patch 10 or newer.

For assistance at any stage type --help

To export the server configuration, connect to SecureSphere via SSH, then execute the following command:
impctl platform export
Table 1 Import and Export Commands
Command

Description

--zip-password=<password>

A password to protect the exported file. Valid password must contain 714 letters, digits or * ( ) - + = @ $ & # % ^ : / ~ , _ .

--protocol=<protocol>

<protocol> can be one of:

local

nfs

ftp

cifs
Important Notes: This argument is only used as part of the import
command. Only use this command when moving from a X1000 to a
X1010 machine.

--asset-tag

Asset tag of the target appliance.

The table below lists the arguments required for each of the possible protocols.

32

Protocol

Arguments

Explanation

local

--path

nfs

--path --server

server must be an IP address

ftp

--server --user --password --path

server must be an IP address. This argument is


optional.

Version 11.0 Migration Guide

Upgrade Procedures

Protocol

Arguments

Explanation

cifs

--server --user --password --path

server must be an IP address

Export Command Examples


impctl platform export -protocol=local --path=/tmp
--zip-password=<password>

impctl platform export --protocol=nfs --path=/tmp


--server=10.1.2.3 --zip-password=<password>

impctl platform export --protocol=ftp --server=10.5.6.7


--user=admin -password=123456 -path=/usr/tmp --zip-password=<password>

impctl platform export --protocol=cifs --server=10.1.2.3


--user=admin --password=123456 --path=/usr/tmp --zip-password=<password>

Bringing Up a Second Server with the New SecureSphere Version


This is done by installing the updated version which can be downloaded from the FTP. Dont run any
configuration such as first time login. Only configure an IP address so you can connect to the machine to
import the original file you exported.

Importing the Original Server Configuration to the New Server


Import the configuration file by executing the following command:
impctl platform import

The arguments used with this command are the same for the export step. The only differences being that you
use the command impctl platform import and additional use the asset tag argument if importing an X1000.
See examples in Export Command Examples on page 33.

Note: The imported file must be named UpgradeExport.tar.gz.zip, otherwise SecureSphere wont find
the file for import.

Version 11.0 Migration Guide

33

Chapter 1 - Upgrading SecureSphere Version 11.0

Import Command Examples


impctl platform import -protocol=local --path=/tmp
--zip-password=<password> --asset-tag=X1010

impctl platform import --protocol=nfs --path=/tmp


--server=10.1.2.3 --zip-password=<password>

impctl platform import --protocol=ftp --server=10.5.6.7


--user=admin -password=123456 -path=/usr/tmp --zip-password=<password>

impctl platform import --protocol=cifs --server=10.1.2.3


--user=admin --password=123456 --path=/usr/tmp --zip-password=<password>

Installing a Patch
Note: The SecureSphere upgrade package includes the latest patches. Subsequently, there is no need
to install a patch after the upgrade process.

34

Version 11.0 Migration Guide

Post Upgrade Procedures

Post Upgrade Procedures


This section reviews procedures that may need to be conducted based on your deployment. Conduct all the
procedures below that are used in your deployment of SecureSphere:

Reset user passwords: For more information, see Resetting User Passwords on page 35.

Enable activate settings: For more information, see Enabling Activate Settings on page 35.

Reconnect SAN devices: For more information, see Reconnecting a SAN Device on page 36.

Restore the Reverse Proxy Apache configuration. For more information, see Restore the Reverse
Proxy Apache Configuration on page 37.

Enable the Data Owner Portal: For more information, see Enabling the Data Owner Portal on page 39

Resetting User Passwords


Enhancements have been made to the way SecureSphere handles credentials locally. Therefore, if you
upgrade from v10.0 or earlier to v10.5 or later, and you use SecureSphere for authentication, it is
recommended you reset all user passwords and have users log in with the new password so the
enhancements can take effect.

Note: If you use an external system such as LDAP or a Radius server to authenticate users, then
these changes dont impact you and you do not need to conduct this procedure.

To reset user passwords:


1.

In the Admin workspace, select Users and Permissions.

2.

In the Users & Roles pane, expand the Users category, and then select the user whose password you
want to reset.

3.

In the Details pane, click the User Information tab and then click Reset Password. The Reset
Password window appears.

4.

In the Reset Password window:

In the Your Password text box, type your SecureSphere administrator password.

In the Users New Password text box, type a new password for the user. The password must:

Contain a minimum of seven characters

Include at least one numeral

Include at least one lower-case letter

5.

In the Confirm New Password text box, type the new user password again.

6.

Click Change to save the new user password.

7.

Repeat this procedure for each of your user. Users whose passwords are not reset or who do not log out
and then back in will not have the security enhancements enabled on their accounts.

Enabling Activate Settings


1.

Wait for the SecureSphere Management Server to load. Actions must execute after the Management
Server status is running.

2.

Login as root to the Management Server.

Version 11.0 Migration Guide

35

Chapter 1 - Upgrading SecureSphere Version 11.0

Note: By default, you cannot connect to the appliance as root or secure over SSH. To login as root,
you must first connect as a CLI user and use the admin command. You can specify an IP address from
which the user root is allowed to login over SSH with the following command:

impctl hardening config --root-source-ip-exception=<IP address>


3.

Use a text editor to edit the configuration file.


For example, enter the following command:

vi /opt/SecureSphere/server/SecureSphere/jakarta-tomcat-secsph/webapps/
SecureSphere/WEB-INF/bootstrap.properties
4.

Set the activate-settings.activation-mode attribute to OnActivateSettings

5.

Edit: activate-settings.activation-mode

6.

Pay attention to the spaces separating the attribute from its value.

7.

Restart the Management Server for changes to take effect.

OnActivateSettings

Reconnecting a SAN Device


Conduct this procedure immediately after your machine comes up from reboot during upgrade.
If you have just completed installation and have a SAN device, reconnect your appliance to the SAN device as
follows:
1.

Reconnect the cable you disconnected earlier.

2.

If the directory /mnt/<external-storage> does not exist, execute the following command:

mkdir -p /mnt/<external-storage>
where <external-storage> is your SAN mount name.
3.

Open the file /etc/fstab with a text editor (such as vi) and add the following line to the file where X
in SDX should be replaced with the actual letter of the drive:

/dev/sdX
4.

/mnt/external-storage

ext3

defaults

0 0

Confirm that the SAN device is mounted by executing the following commands:

mount -a
mount
5.

Open the bootstrap.xml using a text editor. It is located at /opt/SecureSphere/etc/bootstrap.xml.

6.

Verify the var-dir and audit-base-path parameters to point to the external partition, for example,
to /mnt/<external-storage>. If not, update the path parameters to match their location.

Warning: Do not format the SAN storage device. It contains data you want to keep.

36

Version 11.0 Migration Guide

Post Upgrade Procedures

Restore the Reverse Proxy Apache Configuration


If you are running reverse proxy with the Apache server, you need to restore its operation.

Note: If using SSL encryption, please prepare the key and certificate of the webserver before starting
the procedure.

To restore the Reverse Proxy Apache configuration:


1.

On the gateway, login as root after the SecureSphere Server is up.


Note: By default, you cannot connect to the appliance as root or secure over SSH. To login as
root, you must first connect as a CLI user and use the admin command. You can specify an IP
address from which the user root is allowed to login over SSH with the following command:

impctl hardening config --root-source-ip-exception=<IP address>


2.

Retrieve the previous configuration defined in httpd.conf from the backup directory (see Backup
Directory on page 16).

3.

If working with SSL, then install/update Mod-SSL as described in Installing/Updating Mod-SSL on page 37

4.

Recreate routes as follows:


4.1

Log in to the gateway as user root.

4.2

Execute the following command:

impcfg

5.

4.3

Navigate to Top > Gateway > Manage interfaces and routes > Manage reverse proxy
(apache) routes

4.1

Define the static routes.

4.1

If VRRP is defined, you must associate the route with the virtual instance.

After configuration is completed, run the following:


a.

Restart the httpd service:

service httpd restart


b.

Force httpd to start after reboot:

chkconfig -add httpd

Installing/Updating Mod-SSL
Mod-SSL comes with the latest Apache Reverse Proxy in SecureSphere 10.5 and supports all modes of https.
The following procedure details how Mod-SSL is installed/updated.
Note: The changes below can be added to the httpd.conf file only, or they can be added to the
ssl.conf as well. If you add them to the httpd.conf only, you must rename the ssl.conf so that the
Apache server will take the configuration from the httpd.conf file only.

Version 11.0 Migration Guide

37

Chapter 1 - Upgrading SecureSphere Version 11.0

To install/update mod-SSL:
1.

Configure the correct GUI definitions:


Note: In Apache Reverse Proxy, the GUI settings are similar to bridge-stp and not to Kernel
Reverse Proxy.

2.

If you choose one-side encryption (client <-> Gateway), add the following to ssl.conf
LoadModule ssl_module modules/mod_ssl.so
#Listen 443
Notes:In the following text, note the explanations of these terms

Inbound IP Address: as configured in the alias

Web server name: Web server real IP or name

Listen [Inbound IP address]:443


<VirtualHost [Inbound IP address]:443>
ServerName [Web server name]
# activate HTTPS on the reverse proxy
SSLEngine on
SSLCertificateFile

/[path to certificate]/<certificate file name>

SSLCertificateKeyFile

/[path to certificate]/<key file name>

SSLProxyEngine On
SSLProtocol -all +TLSv1 +SSLv3
SSLProxyProtocol -all +TLSv1 +SSLv3
SSLCipherSuite ALL:!ADH:!EDH:RC4+RSA:+HIGH:+MEDIUM:!LOW:!SSLv2:!EXPORT
SSLProxyCipherSuite HIGH:MEDIUM:!aNULL:+SHA1:+MD5:!ADH:!EDH:+HIGH:+MEDIUM
ProxyPreserveHost On
RewriteEngine On
RewriteRule ^/(.*) http://[Web server name]/$1 [P]
Header unset "WWW-Authenticate: NTLM"
Header add WWW-Authenticate "Basic realm=[Web server name]"
<Location />
ProxyPass http://[Web server name]:80/
ProxyPassReverse

http://[Web server name]:80/

</Location>
</VirtualHost>
3.

If you choose two-side encryption (client<->Gateway <-> Web server), make sure you have the
certificate and key of the web server before continuing, and change the above "Virtual Host" entry to:
Listen 443
<VirtualHost [Inbound IP address]:443>
ServerName [Web server name]
# activate HTTPS on the reverse proxy
SSLEngine on
SSLCertificateFile

/[path to certificate]/<certificate file name>

SSLCertificateKeyFile

/[path to certificate]/<key file name>

SSLProxyEngine On
SSLProtocol -all +TLSv1 +SSLv3
SSLProxyProtocol -all +TLSv1 +SSLv3

38

Version 11.0 Migration Guide

Post Upgrade Procedures

SSLCipherSuite ALL:!ADH:!EDH:RC4+RSA:+HIGH:+MEDIUM:!LOW:!SSLv2:!EXPORT
SSLProxyCipherSuite HIGH:MEDIUM:!aNULL:+SHA1:+MD5:!ADH:!EDH:+HIGH:+MEDIUM
<Location />
ProxyPass https://[Web server name]:443/
ProxyPassReverse

https://[Web server name]:443/

</Location>
</VirtualHost>
a.

Restart the httpd service:


service httpd restart

b.

Force httpd to start after reboot:


chkconfig --add httpd

Enabling the Data Owner Portal


If you are licensed to use SecureSphere File or SharePoint Security products and have upgraded from a
previous version of SecureSphere; before using the Data Owner Portal you must first enable the Open API
feature to make the Data Owner Portal available.
To enable the Open API and make the Data Owner Portal available:
1.

In the Admin workspace, click System Definitions > General Security Settings.

2.

Select the option Enable using Open API.

3.

Click Save. Settings are saved and the Data Owner Portal is now available.

Version 11.0 Migration Guide

39

Chapter 1 - Upgrading SecureSphere Version 11.0

40

Version 11.0 Migration Guide

A PPENDIX

Pre-Upgrade Procedure
Reference
The following section provide detailed information for items referenced in the Mandatory Pre-Upgrade Checklist on
page 18.

Verifying Maintenance License has not Expired


To verify your maintenance license has not expired, in SecureSphere go to Admin > Licensing. In the right-hand
pane under Cross System Modules, see Maintenance Start > Expired dates.

Updating to the Latest ADC Content


In SecureSphere go to Admin > ADC. Under Automatic ADC Update, click Update Now. For instructions on
manually updating ADC content (which is applicable for example if your SecureSphere doesnt have internet access),
see the SecureSphere Admin Guide.

Notifying Imperva Support


Before getting started, it is highly recommend that you notify Imperva Technical Support. This can be done by opening
a case on the SecureSphere customer portal of type Upgrade Validation as described in the following article: https:/
/www.imperva.com/sign_in.asp?retURL=/articles/Reference/Upgrade--Submitting-your-SecureSphere-Configurationfor-Upgrade-Testing.

Installing the Latest Patch


Before starting the upgrade process, you must install the latest patch to your current version.
Note: The upgrade package release date (the date that appears next to the upgrade package file on
the FTP) must be the same or later than the release date of the patch that you install.

The installation file includes the latest patches, so there is no need to install a patch after the upgrade process.
The SecureSphere version number is displayed in the status bar (on the right side) in the SecureSphere GUI.
To determine the patch you are using, execute the following CLI (command line interface) command on the appliance:
cat /opt/SecureSphere/etc/patch_level

The latest patch available for your version of SecureSphere, as well as instructions for installing the patch, are available
on the FTP under /downloads/SecureSphere_Patches/ for the relevant version.

Applying and Disabling Activate Settings


This section reviews the following:
Applying Settings Which Have Yet to be Applied on page 38
Disabling Activate Settings on page 38

Applying Settings Which Have Yet to be Applied


If you are operating in delayed activation mode, you need to manually apply all settings which have been configured
but not applied.
To apply settings which have been configured and saved but not yet applied:
1.

In any SecureSphere window, from the buttons on the right hand side of the window, click Activate. The
Activate Settings window appears, displaying detailed information about all changes that have not yet been
activated.

2.

In the Activate Settings window, click Activate. The Activate Settings window closes and the progress bar
appears, indicating the status of activation.

3.

Click OK. All changes are applied.

Disabling Activate Settings


To disable activate settings, you need to change the SecureSphere activation mode.
To disable activate settings:
1.

Login to the SecureSphere management server machine as root.

2.

Access the boostrap.properties file using the following command and path:
vi /opt/SecureSphere/server/SecureSphere/jakarta-tomcat-secsph/webapps/SecureSphere/
WEB-INF/bootstrap.properties

3.

Set the activate-settings.activation-mode attribute to Immediate as follows:


activate-settings.activation-mode = immediate
Note: The parameter immediate disables activate settings. If you want to enable activate
settings, youd alternatively use the parameter OnActivateSettings.

Note the spaces separating the attribute from its value.


4.

Run the following command to restart the server:


impctl server restart
The server is restart and activate settings has been disabled.

38

Version 11.0 Migration Guide

Backing Up the System


Before running the upgrade process, backup the SecureSphere system. The backup process guarantees that the
system can be restored, if needed. Save the backup file on another machine.
Note: If backing up a VMware based SecureSphere, take a snapshot before upgrade.

To backup your system:


1.

Login to the Management Server as user root.

2.

To start the full export/import utility, execute the following commands:


full_expimp.sh

3.

To fully export the SecureSphere server for backup purposes, set the following parameters:
3.1

Operation: option - 1

3.2

Password: the password you chose for the system user in the first-time login.

3.3

Export Type: option - 1

4.

Enter a response (y or n) to the question: Would you like to export failed archives data [y/n] (default is n)?.

5.

Enter a name for the backup file or use the default name. Make sure to type a full path when not using the default,
which is /var/tmp/SecureSphere_<current date>.tgz

6.

Enter Y to confirm the export action.

7.

Wait for the process to end. This may take some time when there is a large number of events to export. You can
follow the log file created in the same directory as the backup file by using the tail command in a different shell.
If the export was successful, you will see the following message at the end of the file:
full_expimp completed successfully on <date>

8.

Save the backup file to an external location.

9.

Copy all the reports from the below path to a different machine for backup purposes:
/opt/SecureSphere/server/SecureSphere/jakarta-tomcat-secsph/webapps/SecureSphere/
WEB-INF/reptemp

Backup Audit Files


Backup audit files by archiving them to an external location. See SecureSphere User Guide for details on the exact
operation steps.
It is possible to back up the audit directory to an external location. If the gateway continues to audit, information
collected after the directory was copied or information was archived is not backed up.

Obtaining the SecureSphere Upgrade Packages


The SecureSphere upgrade software packages are on the FTP server at:
/Downloads/SecureSphere_Upgrades/V11.0/
It is recommended to save the file down to \var\tmp and run the installation from there.
File Name

Version

64Bit/upgrade-11.0.0.<patch_number>_0.<build_number>-x86_64noarch.rpm

SecureSphere 11.0 64-bit version

Version 11.0 Migration Guide

39

Unmounting SAN Devices


SAN device is a dedicated network that provides access to consolidated, block level data storage, and is primarily used
to make storage devices, such as disk arrays accessible to servers so that the devices appear to the OS as locally
attached devices.
If your appliance has a SAN device attached, it must be unmounted and physically disconnected from SecureSphere.
To unmount a SAN device:
1.

Execute the following commands:


impctl teardown
umount /mnt/<external storage>
where <external-storage> is your SAN mount name.

2.

Open the bootstrap.xml file using a text editor.

3.

Change the var-dir and audit-base-path parameters to point to /var/SecureSphere.

4.

Save bootstrap.xml.

5.

Disconnect the cable of the SAN device.


Warning: If you do not disconnect the cable, the reboot process will detect the SAN device and ask
you whether to ignore the device or to format it.
Do not format the SAN storage, because it contains data you want to keep.

Running the Test Install Script


You can choose to first test the installation script by first running the ./install script. This means that all tests
performed by the pre-install script will run whether or not there are warnings, and the script aborts before making any
changes to the system. This helps determine if there are any major issues before conducting the actual upgrade.
To run the ./install script:
1.

Execute the following commands:


cd /var/SecureSphere/upgrades/upgrade-11.0.0.<patch_number>_0.<build_number>/bin
./install --test-only
If the script identifies any modified files, a message is displayed on the screen. Additional information is displayed
with the file name in which changes were detected. Differences are saved to [filename].diff in the backup
directory (see Backup Directory on page 16).

40

Version 11.0 Migration Guide

If the tests are successful, the following message is displayed.

nCipher Card
Note: This section is relevant to SecureSphere Gateways only.

The nCipher card configuration is not completely carried over to the upgraded configuration. You will have to partially
reconfigure the nCipher card configuration.
See the nCipher Card Installation section in the Add Ons appendix of the SecureSphere Administration Guide
for more information. You do not have to do everything described in that appendix, because only the SecureSphere
Gateway has to be reconfigured. You only need to perform the procedure below.
To reconfigure the nCipher card after the upgrade:
1.

Confirm that you have backed up the nCipher cards configuration (the directory
/opt/nfast/kmdata/local to an external storage device).

Note: The section Mandatory Pre-Upgrade Checklist on page 18 instructed you to do this.

2.

Referring to the procedure nCipher Card in the Add-On Appendix in the SecureSphere Administration
Guide, perform the steps in the Installing the nCipher Card Driver section.

3.

Next, perform the steps in the Verifying the Installation section.

4.

Next, perform steps 1-3 in the Security World Initialization section.

Version 11.0 Migration Guide

41

5.

Next, instead of steps 4-6 in the Security World Initialization section, do the following:
5.1

Copy the contents of the directory


/opt/nfast/kmdata/local (which you backed up before beginning this upgrade) from the backup
location back to the /opt/nfast/kmdata/local directory

5.2

Execute the following command:

/opt/nfast/bin/new-world --program -m1


5.3

When you are asked to do so, insert the SmartCard into the nCipher reader.
The output should resemble the following:

Checking modules and reading cards ...


10:38:15 WARNING: Module #1: preemptively erasing module to see its slots!
Indoctrinating Module:
Module 1: 0 cards of 1 read
Checking modules and reading cards ...
Card reading complete.
6.

Continue the Security World Initialization from steps 7 - 11.

7.

Run the command impctl teardown.

8.

Run the command impctl boot.

42

Version 11.0 Migration Guide

nCipher NetHSM
Starting with upgrade to SecureSphere v11.0, SecureSphere now migrates all configuration. There is no need for any
manual configuration after upgrading.

Verifying the Ethernet Driver in Use in a VM Deployment


When upgrading SecureSphere on VMware, you need to verify the Network Interfaces are using the driver VMXNET 3
driver.
Then, if you are not using the supported driver (VMXNET 3), you need to change the driver you use on your Network
Interface.
To verify you are using the VMXNET 3 driver:
1.

Right click on the SecureSphere VM and click Edit Settings. The Machine Properties window opens.

2.

In the Machine Properties window, select a network adapter, then look at the name of the current adapter. It
should read VMXNET 3, as follows:

If the driver installed is not VMXNET 3, you need to change. For instructions on how to change ethernet drivers in
VMware, see the Imperva Customer Portal article Changing Ethernet Drivers in a VM Deployment.

Version 11.0 Migration Guide

43

44

Version 11.0 Migration Guide

A PPENDIX

Feature Limitations as Part


of SecureSphere Upgrade
There are a number of limitations which should be taken into account as part of the SecureSphere upgrade. Some of
these limitations should be considered before the upgrade for they may impact how information is carried over. While
other limitations simply affect SecureSphere behavior. Limitations are broken down as follows:

Limitations that should be noted before upgrade as they may impact how information is migrated into the
upgraded version of SecureSphere. For more information, see Pre-Installation Limitations on page 46.

Limitations which can be addressed after upgrade. For more information, see Post Installation Limitations on
page 50

Pre-Installation Limitations
This section lists limitations that should be carefully reviewed and addressed before conducting the upgrade as they
may impact the way data is migrated or supported once upgraded.
How to use this section: Review the following items relevant to your implementation of SecureSphere. For example, if
you dont use SecureSphere for SharePoint Security, you can ignore that section. Then determine if and how the
limitation may impact you, and what steps you can take.

Action Sets
1.

2.

When migrating an action set with an action interface of type Assignment Task and/or of type Review Task,
the data under the following fields will sometimes not be migrated.

Followed action on status change

Followed action on assignee change

Followed action on overdue

OS scripts used in action interfaces of type OS command do not survive the upgrade. You must backup these
scripts before performing the upgrade and restore them after the upgrade is complete.

Archive Settings
The default and user-defined archive name templates are set to the a format. This means that only the file name
format will be changed. This is defined under Main > Setup >Settings > Archive Settings. Other settings remain
intact.
The new name format is:
SecureSphere_Audit_${policyName}_${startDate}_${endDate}_${gatewayName}_${splitIndex}.mprv

ARP (Apache Reverse Proxy) - Keys


The nss.conf file and CA and server keys are not carried over to the upgraded configuration. For more information,
see Appendix E, Configuring Apache Reverse Proxy.

Connectivity to Protected Servers


During the upgrade process, connectivity to the protected servers may be lost, depending on the gateways mode:

Transparent Reverse Proxy/Kernel Reverse Proxy/Apache Reverse Proxy: Connectivity is lost during the
upgrade process.

STP/IMPVHA Bridge: Connectivity depends on fail mode configuration. If fail mode configuration is set to fail
open, the network card creates a bypass and connectivity remains. If the fail mode configuration is set to fail
close, the connectivity is lost.

Sniffing: Connectivity to the protected servers is not affected when running the SecureSphere Gateway in Sniffing
mode.

Execution History
In Admin > Jobs Status > Execution History: The Execution History tab contains information about all the
previous executions of the specific job.
After an upgrade, only the last weeks execution history is kept. The rest is deleted.

46

Version 11.0 Migration Guide

Pre-Installation Limitations

Gateway Groups
If STP mode with HA enabled, a gateway group contains more than one gateway, and Block on Overload is checked
under Overload Policy (under Topology Configuration in the Gateway Group Details pane), the gateway may
be moved out of the group during the upgrade process. The user must manually return the gateway to the gateway
group after the upgrade is complete.

Hard Disk Identifier


Hard disks previously identified as HDE and HDA are identified as SDA after the upgrade.

Host Names
In a Web profile, a learned host with a space in its name is not migrated.

Jobs
All jobs with the status executing will not be resumed after the upgrade. You need to rerun them once upgrade is
complete. Additionally, jobs that are scheduled to run while the upgrade is being conducted also wont run.
Please make a list of all critical jobs that need to run and run them manually after the upgrade.

KRP - Onboard Interface


With G series appliances, the onboard interface cannot be used in a KRP (Kernel Reverse Proxy) configuration.

KRP - Protected IP Addresses Not Linked to KRP Rules Deleted


after Upgrade
Protected IP Addresses that are part of the server group that are not linked to a KRP rule are deleted during the
upgrade. This does not impact functionality as KRP rules are migrated, while IP Addresses not linked to a rule have no
relevance to SecureSphere operation.

Learning Statistics
Learning statistics in the profile overview are reset to zero after the upgrade.

Log Collector
The Log Collector password does not survive the upgrade and must be reconfigured.

Non-Admin CLI Users


When a non-admin CLI user logs into the appliance using SSH after the upgrade to version 11.0, he will be asked for
his password and then will immediately be asked to change his password.

Version 11.0 Migration Guide

47

Plugins
The order of plugin execution can be explicitly specified in version 9.5., while in earlier versions, the order was implicit.
If there is more than one plugin defined for the same service, the implicit order of earlier versions is not always
maintained in the upgrade to version 9.5, so after the upgrade, review the list of plugins for each service to confirm
that they are being executed in the order you want them to execute.

Read-Only User
In versions 8.5 and earlier it was possible to set a user as a read-only (in Admin > Users and Permissions > Users
& Roles). This option was removed in versions 9.0 and 9.5 and was re-created in version 10.0.
The limitation is that when upgrading from version 8.5 or earlier to version 11.0 the Read-Only User setting is not
migrated.

Revoking Permissions on SharePoint URM Scan


When upgrading from 9.0 or 9.5: You will need to rerun the SharePoint URM scan in order to revoke permissions
based on it.

Revoking Permissions on File URM Scan


When upgrading from version 9.5 or older: After the upgrade you can revoke permissions on file URM scans. You
cannot revoke permissions on the pre-upgrade data.

SharePoint
The SharePoint service and the applications defined under it do not survive the upgrade from version 9.0 to version
9.5.
The service and the applications remain in the site tree after the upgrade, but they cannot be used. You must manually
delete them.
However, you do not have to manually re-define them. To automatically re-define them, right-click the SharePoint
service in the site tree and select Auto-Discover Applications. Afterwards, you can use the File Explorer.
You must then re-apply scans to the newly-defined services and applications.

SNMP
The default SNMP setting for SecureSphere is off, so if you had SNMP enabled, you will have to re-enable it after
upgrading.

SSL Keys
Existing SSL keys are migrated, but their expiration date and other fields not displayed in earlier versions of
SecureSphere are not displayed in this version either, even though these fields are displayed for SSL keys created in
this version. These older SSL keys will not be automatically deleted based on their expiration dates (as defined in
Admin > System Definitions > SSL Certificate Expiration Monitoring).

48

Version 11.0 Migration Guide

Pre-Installation Limitations

System Event Archiving


Only the 100,000 most recent system events survive the upgrade. Older system events are deleted without being
purged.
By default, version 11.0 stores the last 100,000 system events. Any system event beyond 100,000 is purged nightly.
You can configure archiving for the system events or even change the number of events kept, however if no archive
location is defined any event beyond the last 100,000 is purged and not archived. To control the settings after
upgrading, go to Admin > Maintenance > System Event Archiving.

Synchronizing with Active Directory Users before File/SharePoint


URM Scan
When upgrading from version 9.5 or older: After the upgrade you need to make sure Active Directory data is
contained in the Windows Domains global object. To synchronize the Active Directory data, follow the instructions in
the Configuring Active Directory Integration for Data Enrichment section in the File/ SharePoint Security User
Guide.

Version 11.0 Migration Guide

49

Post Installation Limitations


While the items in Pre-Installation Limitations on page 46 list limitations which need to be noted before upgrade for
they may impact how features are migrated. The items listed here address how information was migrated and further
action that may need to be taken after upgrade depending on what features you use in SecureSphere.

Activate Settings
After the upgrade process, the Activate Settings feature is disabled. In order to use Activate Settings, you must enable
it first. For information on how to do this, see Enabling Activate Settings on page 30.

Browser Default Page for SecureSphere


The page which loads immediately after logging into SecureSphere has changed in v11.0 from ui/main.html to
index.html. If you have bookmarked this page please delete this bookmark and create a new one. Additionally, the old
URL may be present in the browser cache so when auto-filling a URL may lead you to the old page. If you do navigate
to the old default page it will appear as if SecureSphere is loading indefinitely.

Configuration Files
Before the upgrade process, the upgrade script verifies that no changes have been made to
/opt/SecureSphere/etc/hades.cfg. If the file has been changed, a message is displayed and the modified file
(the file from before the upgrade) is saved in the backup directory. It is your responsibility to edit the newly-installed
system file and modify it accordingly.
For your reference, after the upgrade process completes, the modified system files (the files from before the upgrade)
can be found in the below directory:
/var/SecureSphere/upgrades/upgrade-11.0.0.<PATCH_NUM>_0.<BUILD_NUM>/backup
The files are:
/etc/httpd/conf/httpd.conf
/etc/rc.d/rc.local
/opt/SecureSphere/etc/impctl/lib/keepalived.sh
/opt/SecureSphere/etc/hades.cfg

Data Owner Portal - URM Scans


Scans that were last run before v10.5 cannot participate in a review. Users need to rerun the scan before they will
appear in the Start Review window.

File Policies
In versions earlier than v10.5, the criteria Operation had a possible value Create Folder. Starting with v10.5, this
value is replaced with Object Type.
Subsequently, if before upgrading you have a policy that includes the Create Folder value, after the upgrade it is split
to 2 criteria: Operation (Create) and Object Type (Folder).
Additional, the Delete folder operation will be changed to delete (without an Object Type).

50

Version 11.0 Migration Guide

Post Installation Limitations

File Audit Data


In earlier versions, SecureSphere File Audit Data included operations such as Create Folder and Delete Folder which
would appear in the Operations column. In v11.0 there is a new column named Object Type and the data is split
between these two columns.
So for example, if in the past when a Create Folder operation was conducted under Operation, Create Folder
would be displayed; in versions v11.0 and newer under Operation, the word Create is displayed and in the new
Object Type column Folder is displayed.

File URM Review Results


Some items that were marked for review, approved, or revoked may be lost and will be missing in the Manage File
Permissions window in SecureSphere.

IP Rules
Manual changes to /etc/rc.local to configure ARP settings, IP routes, and IP rules, are not migrated. Manual
configuration is required after completing of the upgrade process. The files can be viewed after the upgrade process
completion at:
/var/SecureSphere/upgrades/upgrade-11.0.0.<PATCH_NUM>_0.<BUILD_NUM>/backup

MySQL
If you are using one of the following SecureSphere features with a MySQL database:

DB Data Classification

Assessment

Credentials Verification

Test Connection

After upgrading, you must download and install an MySQL driver on the SecureSphere management server, even if you
already downloaded the driver when using the previous version of SecureSphere. Instructions for doing this are in the
Basic Configuration chapter of the SecureSphere User Guide.

Routes
During the upgrade process, all the manually defined routes are identified. When the upgrade process completes, the
routes are restored. However, files containing static routes changes are not migrated. Instead, the SecureSphere
system maintains all routes defined internally. The new static routes should be configured from impcfg.

SCP Action Interface


Existing action interfaces sending data to SCP will not work after upgrading. This is because new SSH keys are
generated. Therefore, a warning is displayed to the client that the servers host key does not match the one cached in
the registry. And example of this message when working with putty is as follows.

Version 11.0 Migration Guide

51

Click Yes to trust the new key. Data can now be sent to SCP.

SSH Keys
After upgrading SecureSphere, new SSH keys are generated. Therefore, a warning is displayed to the client that the
signature has changed. The message is displayed only once after the upgrade, when the user tries to SSH to the
appliance for the first time.

Stream Dictionary Policies


Stream signatures are no longer automatically applied to new server groups when created. Server groups that were
created before upgrade that had stream signature policies applied to them will retain these policies.

52

Version 11.0 Migration Guide

A PPENDIX

Monitoring Installation
Status with VNC
In release 11.0, the SecureSphere operating system was upgraded to CentOS 6.3.
Installing a new operating system may take some time. If the upgrade is done through a remote connection you do not
have visibility into the process and cannot watch the installation screens. To obtain visibility to the operating system
installation process you can to connect to the appliance being upgraded using VNC viewer software. The appliance and
the VNC client must be on the same subnet. In order to connect to the machine with VNC you need to have VNC viewer
installed on your PC. Open it, then in the Server field, type <appliance management IP>:1 . The password is
install.

Figure 1 VNC Viewer

1.

Once connected, you can monitor the installation of the CentOS Operating System.

Figure 2 CentOS

2.

Once the OS installation is complete, the VNC connection is terminated.

3.

After the reboot, reconnect to SecureSphere via SSH as user root.


Note: By default, you cannot connect to the appliance as root or secure over SSH. To login as
root, you must first connect as a CLI user and use the admin command. You can specify an IP
address from which the user root is allowed to login over SSH with the following command:
Note: impctl hardening config --root-source-ip-exception=<IP

address>
4.

54

Continue the upgrade according as detailed in Feature Specific Pre-Upgrade Checklist on page 20.

Version 11.0 Migration Guide

A PPENDIX

Mounting a USB Key


When not having network access to your SecureSphere management Server or Gateway you may need to copy the
upgrade installation via a USB key. You may additionally need to mount the USB key to copy over the upgrade
installation file.
To mount a USB key:
1.

cd /mnt

2.

mkdir usbmnt

3.

Find out the name of the usb device to be mounted using the commands:

fdisk -l

ls -ltr /dev | grep sd

4.

Then type: mount /dev/sdb1 /mnt/usbmnt

5.

Now you can access the directory which is the USB key - cd /mnt/usbmnt

6.

To safely unmount and eject - umount /mnt/usbmnt

56

Version 11.0 Migration Guide

A PPENDIX

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.
This procedure should be conducted after upgrade has been completed.
Imperva SecureSphere includes and supports operation modes that run under FIPS 140-2 Level 1 encryption
algorithms. SecureSphere Apache reverse Proxy mode is included in the above support.
With FIPS 140 support, the encryption module for httpd mod_nss replaces the mod_ssl that was used previously.

Uploading the Encryption Keys


Note: If you are not using SSL, start with step 2.

To upload encryption keys:


1.

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

Parameter

Description

-in

The name of the file that contains certificates

-inkey

The name of the file that contains the private key

out

The name of the file that will contain the PKCS#12 key

-name

The key name that must be the same as the name specified in the nss.conf file
under the NSSNickname parameter.

-passout

The output key password

For example if source key file name is inputkey.pem and certificate file is input.cert the command is as
follows:
openssl pkcs12 -export -in /tmp/input.cert -inkey /tmp/inputkey.pem -out /tmp/
outputkey.p12 -name mykey -passout pass:1234
2.

Create an NSS database. You must specify the database directory.


certutil -N -d /etc/httpd/alias
Where:
Parameter

Description

-N

Creates a new certificate database

-d

Cert database directory path that must be the same as the name specified in the
nss.conf file under the NSSCertificateDatabase parameter.

3.

Enter a password or leave the text box empty. If you are adding a password, the password must contain at least 8
characters one of which should be a non-alphabetic character.

4.

Load the PKCS #12 file into your NSS database by executing the following command:
pk12util pk12util -i /tmp/<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.conf file under the NSSCertificateDatabase parameter.

Based on the above example it should be similar to:


pk12util pk12util -i /tmp/outputkey.p12 -d /etc/httpd/alias W 1234
You are asked to enter the certificate NSS DB password see Uploading the Encryption Keys on page 57 - step 2.

58

Version 11.0 Migration Guide

5.

Import the certificate of the CA server which issued the server certificate. This is used as the local certificate
authority. You do not need the key of the CA, just the certificate. Assuming you have its ASCII representation (e.g.,
a PEM file), you can load it as follows:
certutil -A -d /etc/httpd/alias/ -n "My Local CA" -t CT -i /tmp/<CA certificate>
Where:
Parameter

Description

-A

Adds a certificate to the database

-d

Cert database directory path that must be the same as the name specified in the
nss.conf file under the NSSCertificateDatabase parameter.

-n

The nickname of the certificate to add

-t

Sets the certificate trust attributes

-i

The BINARY certificate request file

For example, if your CA server certificate name is CAserver.cer the command should look like:
certutil -A -d /etc/httpd/alias/ -n "My Local CA" -t CT -i /tmp/CAserver.cer
6.

When using FIPS, run the following additional steps:


a.

Edit the file /etc/httpd/alias/phrases file.


It should contain a single line:
NSS FIPS 140-2 Certificate DB:<< NSS certificate database password >
The password is the one you set in Uploading the Encryption Keys on page 57 - step 2.

b.

Turn on the FIPS mode in the certificate database by executing the following command:
modutil dbdir /etc/httpd/alias fips true

Note: FIPS mode should be false if you change the NSS certificate DB settings.

This completes the first step of creating the certificate DB and uploading the keys to it. With the new mod_nss
module you can work either in FIPS mode enabled or disabled.
Note: The parameter NSSProxyProtocol may need to contain TLSv1. For example:
NSSProxyProtocol SSLv3,TLSv1.

Version 11.0 Migration Guide

59

nss.conf and http.conf files


The nss.conf and http.conf files are not carried over to their proper locations during the upgrade process, and
you will have to manually copy them from the backup directory (see Backing Up the System on page 38) after the
upgrade has successfully completed.
1.

Copy the original httpd.conf file from the upgrade backup folder to /etc/httpd/conf

2.

Copy the original nss.conf file from the upgrade backup folder to /etc/httpd/conf.d

3.

Restart the httpd service by executing the following command:


service httpd restart

4.

To enable the HTTP service start after reboot, execute the following command:
chkconfig httpd on

60

Version 11.0 Migration Guide

A PPENDIX

Upgrade Procedure for the


Kernel Reverse Proxy
Configuration
To upgrade from SecureSphere version earlier than 9.0 to version 11.0 with the KRP configuration:
1.

Upgrade the management server, see Upgrading a SecureSphere Management Server or Onebox on page 21.
After the MX upgrade, all KRP connections are terminated until the next steps are performed.

2.

Upgrade the gateway, see Upgrading a SecureSphere Gateway (not relevant to Onebox Deployment) on page 28.

3.

Connect to the Gateway using SSH and copy CSV files located in:
/var/SecureSphere/upgrades/upgrade-<version>/backup/gateway/ReverseProxyData/
The CSV file contains the KRP configuration from before the upgrade.

4.

Review the Aliases CSV file to make sure there are no aliases with the same external interface and IP address.

5.

Review the Routes CSV file to make sure there are no illegal routes.

6.

To upload CSV files to the management server, click Setup > Gateways. The Gateways window appears.

7.

Select the relevant gateway and click IP Addresses from the Details pane. The IP Addresses table appears.

8.

In the IP Addresses table, click New. The IP Address window appears.

9.

From the Network Interface drop-down list, select the external interface that you want to use for this gateway.
c.

In the IP Address/Mask (CIDR) text box, type a static IP Address for the external interface. For
instructions on how to identify this interface, see Identifying the Physical IP address for use with VRRP on
page 66.

10.
11. Click Save. The IP Address dialog box closes.

12. Click Close. The IP Addresses table closes.


13. If using VRRP, conduct the following
a.
b.
c.
d.
e.
f.
g.
h.
i.

Select the relevant gateway and click Virtual Routers from the details pane. The Virtual Routers table appears.
In the Virtual Routers table, click Upload from CSV. The Upload Virtual Routers from CSV dialog box
appears.
Click Browse and locate the VRRP CSV file.
In the Advanced tab, select Use first line as header and click Upload.
Once the upload is successfully completed, click Close. The Upload Virtual Routers from CSV dialog box
closes.
Select the virtual router created after uploading the .csv file, then click edit.
From the Primary IP Address dropdown menu, select the static IP Address you want to use for VRRP, then
click Save.
Close the Virtual Routers table.
Repeat steps a-g for another gateway that participates in the VRRP configuration. Make sure to define a static
IP Address in the same subnet.

14. In the Gateways window, select the relevant gateway and click Aliases in the Details pane. The Aliases table
appears.
15. In the Aliases table, click Upload from CSV. The Upload aliases from CSV progress box appears.
16. Click Browse and locate the Alias CSV file.
17. In the Advanced tab, select Use first line as header and click Upload.
18. Once the upload is successfully completed, click Close. The Upload Aliases from CSV dialog box closes.
19. Close the Aliases table.
20. In the Gateways window, select the relevant gateway and click Routes in the Details pane. The Routes table
appears.
21. In the Routes table, click Upload from CSV. The Upload routes from CSV progress box appears.
22. Click Browse and locate the Routes CSV file.
23. In the Advanced tab, select Use first line as header and click Upload.
24. Once the upload is successfully completed, click Close. The Upload Routes from CSV dialog box closes.
25. Close the Routes table.
26. When using VRRP configuration, repeat step 13 for the second Gateway.
Note: After uploading CSV files to the MX, new KRP xml configuration file will be downloaded to
the GW and MX with GW will be in sync - terminated connections should become active again.

To upgrade from SecureSphere version 9.0 and later to version 11.0 with the KRP configuration:
1.

Upgrade the Gateway, see Upgrading a SecureSphere Gateway (not relevant to Onebox Deployment) on page 28.

2.

Upgrade the management server, see Upgrading a SecureSphere Management Server or Onebox on page 21.
After the management server upgrade, all KRP connections are terminated until the next steps are performed.
Note: Once the Gateway is upgraded, the KRP configuration is read from bootstrap.xml and KRP
in IMPCFG is disabled (impossible to add new KRP aliases/routes/vrrp instances).

3.

Connect to the Gateway using SSH and copy CSV files located in the following:
/var/SecureSphere/upgrades/upgrade-<version>/backup/gateway/ReverseProxyData/
The CSV file contains the KRP configuration from before the upgrade.

62

Version 11.0 Migration Guide

4.

Review the Aliases CSV file to make sure there are no aliases with the same external interface and IP address.

5.

Review the Routes CSV file to make sure there are no illegal routes.

6.

To upload CSV files to the MX, click Setup > Gateways. The Gateways window appears.

7.

Select the relevant gateway and click IP Addresses from the Details pane. The IP Addresses table appears.

8.

In the IP Addresses table, click New. The IP Address window appears.

9.

From the Network Interface drop-down list, select the external interface that you want to use for this gateway.

10. In the IP Address/Mask (CIDR) text box, type a static IP Address for the external interface. For instructions on
how to identify this interface, see Identifying the Physical IP address for use with VRRP on page 66.
11. Click Save. The IP Address dialog box closes.
12. Click Close. The IP Addresses table closes.
13. If using VRRP, conduct the following
a.
b.
c.
d.
e.
f.
g.
h.
i.

Select the relevant gateway and click Virtual Routers from the details pane. The Virtual Routers table appears.
In the Virtual Routers table, click Upload from CSV. The Upload Virtual Routers from CSV dialog box
appears.
Click Browse and locate the VRRP CSV file.
In the Advanced tab, select Use first line as header and click Upload.
Once the upload is successfully completed, click Close. The Upload Virtual Routers from CSV dialog box
closes.
Select the virtual router created after uploading the .csv file, then click edit.
From the Primary IP Address dropdown menu, select the static IP Address you want to use for VRRP, then
click Save.
Close the Virtual Routers table.
Repeat steps a-g for another gateway that participates in the VRRP configuration. Make sure to define a static
IP Address in the same subnet.

14. In the Gateways window, select the relevant gateway and click Aliases in the Details pane. The Aliases table
appears.
15. In the Aliases table, click Upload from CSV. The Upload aliases from CSV progress box appears.
16. Click Browse and locate the Alias CSV file.
17. In the Advanced tab, select Use first line as header and click Upload.
18. Once the upload is successfully completed, click Close. The Upload Aliases from CSV dialog box closes.
19. Close the Aliases table.
20. In the Gateways window, select the relevant gateway and click Routes in the Details pane. The Routes table
appears.
21. In the Routes table, click Upload from CSV. The Upload routes from CSV progress box appears.
22. Click Browse and locate the Routes CSV file.
23. In the Advanced tab, select Use first line as header and click Upload.
24. Once the upload is successfully completed, click Close. The Upload Routes from CSV dialog box closes.
25. Close the Routes table.
26. When using VRRP configuration, repeat steps 13 for the second Gateway.
Notes:

After uploading CSV files to the MX, new KRP xml configuration file will be downloaded to the
GW and MX with GW will be in sync - terminated connections should become active again.

If static routes are configured outside of IMPCFG (Linux), you must reconfigure them after the
upgrade.

Version 11.0 Migration Guide

63

To minimize Gateway down time:


1.

Disconnect the management link from the gateway before the management server upgrade.

2.

Reconnect the management link after management server is upgraded and all the CSV files were uploaded to it.
That way the first configuration deletes the existing KRP entries from the bootstrap and restores them in the new
KRP xml configuration file.

To minimize down time of High Availability Gateway:


1.

Upgrade both Gateways, see Upgrading a SecureSphere Gateway (not relevant to Onebox Deployment) on
page 28.

2.

Disconnect the management link from the backup Gateway.

3.

Upgrade the MX, see Upgrading a SecureSphere Management Server or Onebox on page 21.
Note: Once the MX is upgraded, KRP connections are terminated only on the main Gateway (the
backup Gateway is disconnected from the MX), the traffic is directed to the backup Gateway.

4.

Configure a static IP Address in the IP Address Table which will later be used as the primary IP address of the
virtual router, as follows:
a.
b.
c.
d.
e.
f.

Select the Master gateway and click IP Addresses from the Details pane. The IP Addresses table appears.
In the IP Addresses table, click New. The IP Address window appears.
From the Network Interface drop-down list, select the external interface that you want to use for this
gateway.
In the IP Address/Mask (CIDR) text box, type a static IP Address for the external interface. For
instructions on how to identify this interface, see Identifying the Physical IP address for use with VRRP on
page 66.
Click Save. The IP Address dialog box closes.
Click Close. The IP Addresses table closes.

5.

Select the Master gateway and click Virtual Routers from the Details pane. The Virtual Routers table appears.

6.

In the Virtual Routers table, click Upload from CSV. The Upload Virtual Routers from CSV dialog box
appears.

7.

In the Advanced tab, select Use first line as header and click Upload.

8.

Once the upload is successfully completed, click Close. The Upload Virtual Routers from CSV dialog box
closes.

9.

Select the virtual router created after uploading the .csv file, then click edit.

10. From the Primary IP Address dropdown menu, select the static IP Address you want to use for VRRP, then click
Save.
11. Close the Virtual Routers table.
12. In the Gateways window, select the Master gateway and click Aliases in the Details pane. The Aliases table
appears.
13. In the Aliases table, click Upload from CSV. The Upload aliases from CSV dialog box appears.
14. In the Advanced tab, select Use first line as header and click Upload.
15. Once the upload is successfully completed, click Close. The Upload Aliases from CSV dialog box closes.
16. Close the Aliases table.
17. In the Gateways window, select the Master gateway and click Routes in the Details pane. The Routes table
appears.
18. In the Routes table, click Upload from CSV. The Upload routes from CSV progress box appears.
19. Click Browse and locate the Routes CSV file.

64

Version 11.0 Migration Guide

20. In the Advanced tab, select Use first line as header and click Upload.
21. Once the upload is successfully completed, click Close. The Upload Routes from CSV dialog box closes.
22. Close the Routes table.
23. Connect the management link on the backup Gateway.
24. When using VRRP configuration, repeat steps 4-22 for the second Gateway.

Version 11.0 Migration Guide

65

Identifying the Physical IP address for use


with VRRP
If using VRRP, you need to determine the physical IP address to be used for the KRP interface. This IP address is taken
from the SecureSphere bootstrap file of the original SecureSphere you are upgrading from
To identify an IP address for use with VRRP:
1.

On the source SecureSphere, navigate to the boostrap file, located under /opt/SecureSphere/etc/bootstrap.xml.

2.

Open the file with a text editor.

3.

Search for the VRRP Alias. You can do this by searching for the text VRRP alias. The address that should be used
for the physical interface is the address that appears as in-address. Or in the example below,
10.100.13.24/24.
Example: <interface name="a5" in-device="eth2" in-address="10.100.13.24/24" out-device="eth3" outaddress="10.100.13.44/24"> <vrrp address="10.100.13.34/24"/> </interface>

4.

66

Use this address for the IP address for the external interface for VRRP configuration.

Version 11.0 Migration Guide

A PPENDIX

Guidelines for MX-HA


Upgrade
This section describes the procedure for upgrading MX-HA configurations.
1.

On the primary server, uninstall MX-HA by executing the following command:


impctl server ha uninstall

2.

After the previous step successfully completes (and not before!), perform the following actions on the secondary
server:
2.1

Create a new DB by executing the following command:


impctl db create

2.2

Start the DB by executing the following command:


impctl db start

2.3

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.

On the Primary Server


4.

Upgrade to the new SecureSphere version by running the relevant RPM according to the instructions given earlier
in this document.

On the Secondary Server


5.

Upgrade as follows:
From Version 9.0 and higher either:

Upgrade to the new SecureSphere version by running the relevant RPM, or

Install the new SecureSphere version from scratch.

Install the latest SecureSphere Patch. Both management servers should have the same patch installed.
Because this is the secondary server, it does not matter that the data is not migrated, as all the data will be
restored from the primary server.

6.

Download new Oracle RPMs and prepare the servers by performing the following steps on both servers:
6.1

Create a new mxha directory by executing the following command:


mkdir /var/tmp/mxha

6.2

From the Imperva FTP server, download the Oracle RPMs to the /var/tmp/mxha directory.
There are two directories, one for 32 bit and the other for 64 bit. If your appliance has at least 4GB of
RAM, download the 64-bit version of SecureSphere. Otherwise, download the 32-bit version.

6.3

File Name

Version

/Downloads/SecureSphere_Setup/v11.0/32Bit/MX-HA/

32-bit version

/Downloads/SecureSphere_Setup/v11.0/64Bit/MX-HA/

64-bit version

Execute the following command:


impctl server ha preparerpm

7.

On both Management Servers, 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 which is the IP address shared by both Management Servers.

<other_MX private interconnect> is the IP address of the interconnect on the other Management
Server; for example when you are running this command on the primary Management Server, specify the IP
address of the interconnect on the secondary Management Server.

<other_MX physical> is the public IP address of the other Management Server; for example, when you
are running this command on the primary Management Server, specify the public IP address of the secondary
Management Server.

8.

Re-establish SSH trust for the root user and the oracle user.

9.

On the primary server, install MX-HA by executing the following command:


impctl server ha install

68

Version 11.0 Migration Guide

10. After the previous step successfully completes (and not before!), upgrade the gateway.

Version 11.0 Migration Guide

69

70

Version 11.0 Migration Guide

A PPENDIX

Retrieving and Resetting


Passwords
This section how to retrieve and reset passwords as might be required during upgrade. It reviews the following:

Resetting the Password for the 'admin' User in the GUI on page 72

Resetting the Password for User 'admin' During Upgrade on page 73

Resetting the Password for the 'admin' User in


the GUI
This procedure describes the steps to reset the password for the admin user on the GUI. If you need to change the
password during the upgrade, see Resetting the Password for User 'admin' During Upgrade on page 73.
To reset the admin password to admin12:
1.
2.
3.

Login to the MX via SSH as user root (or through another user and elevate)
Run the command "su - oracle"
Login to the local database by running the command "sqlplus secure/<password of secure user>". For example:
sqlplus secure/webco123

4.

Enter the following query on the SQL> prompt:


UPDATE SECURE.CONF_SECURE_MEMBERS SET password = '1844156d4166d94387f1a4ad031ca5fa'
WHERE dn = 'admin';
commit;

5.

Type Exit to exit the sqlplus prompt then Exit again to return to the root unix prompt
Now you can go to the Web interface and enter admin as the user, and admin12 as the password.
_________________
If you'd like to change the password to "webco123", replace the above query with:
UPDATE SECURE.CONF_SECURE_MEMBERS SET password = 'c803ac767fddcdfc230a31c98ed27745'
WHERE dn = 'admin';
commit;

72

Version 11.0 Migration Guide

Resetting the Password for User 'admin' During Upgrade

Resetting the Password for User 'admin'


During Upgrade
This procedure describes the steps to reset the password for the admin user on the GUI during the upgrade.
To reset the admin password during upgrade:
1.

Login to the MX via SSH as user root

2.

Run the command "su - oracle"

3.

Login to the local database by running the command "sqlplus system/<password of system user>". For example
"sqlplus system /system12"

4.

Enter the following query on the SQL> prompt:


UPDATE SECURE_OLD.CONF_SECURE_MEMBERS SET password =
'1844156d4166d94387f1a4ad031ca5fa' WHERE dn = 'admin';
commit;

5.

Type "exit" to exit the sqlplus prompt then "exit" again to return to the root unix prompt
No need to perform server restart. Login to the GUI as 'admin/admin12'.

Version 11.0 Migration Guide

73

74

Version 11.0 Migration Guide