securesphere test drive lab manual

7/18/2019 SecureSphere Test Drive Lab Manual

http://slidepdf.com/reader/full/securesphere-test-drive-lab-manual 1/37

SECURESPHERE TEST DRIVE

ON AMAZON WEB SERVICES

(AWS)

The purpose of this AWS Test Drive is to enable customers to rapidly

evaluate SecureSphere Web Application Firewall (WAF) features using AWS

cloud infrastructure services. This Test Drive is focused on demonstrating

how SecureSphere protects against advanced cyber threats such as SQL

Injection and Zero-Day Attacks.

Protecting

applications agains

SQL Injection and

Zero -Day At ta cks



SecureSphere on AWS Test Drive 1

ContentsPreface .......................................................................................................................................................... 2

Requirements ................................................................................................................................................ 2

Common Terms ............................................................................................................................................. 2

Introduction to SecureSphere Web Application Firewall ............................................................................. 3

Key Capabilities ......................................................................................................................................... 3

Lab Objectives ............................................................................................................................................... 6

SecureSphere Test Drive on AWS Sign-up and Launch ................................................................................. 7

Sign-Up for the Test Drive ......................................................................................................................... 7

Launch SecureSphere Test Drive .............................................................................................................. 8

Test Drive Environment .............................................................................................................................. 16

Lab 1: Protect Against SQL Injection ........................................................................................................... 19

Overview ............................................................................................................................................. 19

Test Drive Lab Procedure ........................................................................................................................ 20

Lab 1 Conclusion ..................................................................................................................................... 27

Lab 2: Protect against a Zero-Day attack using the Profile Overview ......................................................... 28

Create your Zero-Day attack ............................................................................................................... 28

Lab 2 Conclusion ..................................................................................................................................... 33

Imperva Test Drive FAQ .............................................................................................................................. 34

Copyright Notice ......................................................................................................................................... 35

Contacting Imperva ..................................................................................................................................... 36




PrefaceThis Test Drive allows you to quickly and easily explore the benefits of using Imperva SecureSphere Web

Application Firewall to protect your AWS applications. This lab was developed by Imperva and is

provided free of charge for educational and demonstration purposes.

Requirements

Internet Access

Remote Desktop Protocol (RDP) client on your local machine

Access to an email account to receive login credentials

RDP port is open to Amazon.com to connect to the “Attacker’s Workstation”

For a better browser experience, you can (optionally) access the SecureSphere manager over

TCP port 8083 (if open on your network)

Common TermsThe terms below are used throughout the document.

Term Definition

Attacker’s Workstation A Windows machine that was set up for the purpose of sending

attacks, as well as optionally accessing the SecureSphere GUI.

Web Application Firewall

(WAF)

A WAF stops attacks on HTTP servers, preventing a myriad of attacks

that NextGen Firewalls and IPD/IDS products cannot protect against.

SecureSphere Imperva’s comprehensive, integrated security platform that includes

SecureSphere Web, Database and File Security.

SecureSphere Manager

(MX)

A web based GUI that unifies the administration, logging, and

reporting of multiple SecureSphere gateways.

SecureSphere Gateway Inspects and passes traffic to the destination webservers.

SQL Injection A code injection technique, used to attack data-driven applications, in

which malicious SQL statements are inserted into an entry field for

execution (e.g. to dump the database contents to the attacker).




Introduction to SecureSphere Web Application FirewallYour website receives a continuous barrage of attacks. If hackers uncover a crack in your defenses, they

can steal your application data, defraud your users, and take down your website.

The SecureSphere Web Application Firewall stops web attacks and prevents costly data breaches and

downtime. Combining multiple defenses, SecureSphere accurately pinpoints and blocks attacks without

blocking your customers. It offers drop-in deployment and automated management. Certified by ICSA

Labs, SecureSphere satisfies PCI 6.6 compliance and provides ironclad protection against the OWASP

Top Ten.

Key Capabilities

Block Attacks with Laser Precision

Security accuracy is job number one at

Imperva. We know you’re just as

concerned about blocking legitimate

users as you are about stopping attacks.

With that in mind, we’ve developed

Dynamic Profiling technology to

automatically build a “white list” of

acceptable user behavior. And we use

Correlated Attack Validation to correlate

Dynamic Profiling violations with other

suspicious activity to correctly identify

attacks without blocking your customers.

Leverage World-Renowned Application Security Research

To get ahead and stay ahead in the

continuous fight against application

attacks, you need your own security

research organization. SecureSphere WAF

customers get exactly that with regular

signature and policy updates from our

dedicated security research team, the

Application Defense Center (ADC). ADC

research yields the most up-to-date

threat intelligence, and the most

complete set of application signatures

and policies in the industry.




Shut Down Malicious Sources and Bots

Can you distinguish between real

customers, known attackers , or bots?

Can you tell if website visitors are using

anonymous proxies to cloak their

identity? ThreatRadar ReputationServices detects these users with IP

reputation feeds of malicious sources,

anonymizing services, phishing URLs, and

IP geolocation data. ThreatRadar delivers

an up-to-date and automated defense

against automated attacks and attack

sources to help you maximize uptime and

protect your sensitive data.

Stop Application DDoS and Business Logic Attacks

You can keep your customers happy and

your reputation intact in spite of the

growing threat of business logic attacks.

Business logic attacks exploit the normal

logic of your applications to post

comment spam in forums and message

boards, scrape web content, or disable

access to your website. All of this can

reduce your competitive edge, frustrate

customers, and damage your reputation.

SecureSphere mitigates these concernsby identifying bots, known attack sources,

and attack behavior.

Instantly Patch Website Vulnerabilities

Application vulnerabilities can leave your company exposed to attack for weeks or months.

SecureSphere integrates with application scanners for virtual patching, importing assessment results,

and creating custom policies to remediate vulnerabilities. Compared to manually fixing website

vulnerabilities, virtual patching reduces the window of exposure and costs.




Gain Forensics Insights with Customizable Reports

You can quickly analyze security threats

and meet compliance requirements with

graphical reports. SecureSphere provides

both pre-defined and fully-customizablereports. Reports can be viewed on

demand or emailed on a daily, weekly, or

monthly basis. A real-time dashboard

provides you with a high level view of

system status and security events.

Speed up Deployment without Risk

Now you can protect your applications

without impacting performance and

without requiring extensive network

changes. SecureSphere offers flexible

inline, non-inline, and proxy deployment

options that meet your organizations’

diverse requirements. SecureSphere’s

unique, transparent bridge mode saves

time and labor with drop-in deploymentthat requires no changes to existing

applications or network devices.

SecureSphere also delivers multi-Gigabit

throughput while maintaining sub-

millisecond latency.

Data Center Security Leader

We fill the gaps in traditional security by directly protecting high-valueapplications and data assets in physical and virtual data centers.




Lab Objectives

The objectives of these labs are to demonstrate the capability of SecureSphere to protect against SQL

Injection and Zero-Day Attacks. Participants will understand:

What type of damage a successful SQL Injection attack can cause

The challenges of protecting against a Zero-Day attack

How SecureSphere views the attacks

How SecureSphere can protect against the attacks

Additionally, Test Drivers are welcome to browse the GUI, generate different types of attacks against the

target server, or evaluate a feature.




SecureSphere Test Drive on AWS Sign-up and Launch

Sign-Up for the Test Drive

1. Go to Amazon’s Security Test Drive page:

http://aws.amazon.com/testdrive/security/

2. Click on the SecureSphere “Try it now free” button.

3. Complete the registration form

4. Click on Signup

5. Click on Continue

6. Click on Test Drives







7. Click on the Enter button

8. You have the opportunity to watch our video, download the PDF Guide, and launch the Test

Drive cloud. We recommend starting with the video, reviewing the Test Drive Lab Manual,

and then launching the Test Drive.

Launch SecureSphere Test Drive

9. Click on the Launch Test Drive button

10. Wait for the launch to complete. Once it’s completed, the progress bar will show ‘In

Progress’




Once you see ‘In Progress’ turn Green, you can proceed to the next step.

11. Check your email for the link to the Management Server (MX). Alternatively, you can copy &

paste the link from the bottom right-hand quadrant of the Test Drive GUI, in the

‘Environment’ window. For example:

Your Email will look similar to the one below:




Hello Edgard,

Your SecureSphere Test Drive has been created and is ready for you to use. Pleaseremember that after 3 hours the environment will no longer be available. The information youneed to login and use your TestDrive is available below.

From your location, you will need access to the Amazon Cloud. At a minimum, RDP protocoland (optionally) TCP Port 8083 must be allowed outbound to AWS.

You can use Remote Desktop client to RDP to the IP address of Windows AttackerMachine, and login using these credentials below

You can access the SecureSphere Manager (MX) using a web browser on port8083(like HTTPS://ip_address:8083 )

If you dont have access to port 8083, the Windows Attacker Machine is able to loginto the MX

Login for Windows Machine:User: TestDrive

Password: Imperva1

Login for SecureSphere Manager:User: adminPassword: aws_is_cool1

Your IP address is below:

The Imperva Management Server IP and Username: admin and passwordaws_is_cool1.:https://ec2-54-183-14-120.us-west-1.compute.amazonaws.com:8083

You can RDP to the IP address of Windows Attacker Machine using Username:TestDrive and Password Imperva1 . The IP Address is :54.183.118.43

Use the Windows Attacker machine to attack this URL of the Web-Server :http://OrbiteraT-elbExter-15HHA3RDXNMCI-1823771081.us-west-1.elb.amazonaws.com

*Note: Please wait for ~5 - 8 minutes before accessing the URLs as some resources may take

a few extra minutes to become available, depending on AWS resource availability.

The login instructions are presented at the bottom of the email. There, you will find your

link to login to the MX, and the IP address of the Attacker’s Workstation.

Your URL to the MX will look similar to this:

https://ec2-54-183-14-120.us-west-1.compute.amazonaws.com:8083

https://ip_address:8083/



https://ec2-54-183-14-120.us-west-1.compute.amazonaws.com:8083/


http://orbiterat-elbexter-15hha3rdxnmci-1823771081.us-west-1.elb.amazonaws.com/













TIP : If you are unable to access the link provided in the email, proceed to Step 16

(accessing the Attacker’s Workstation using RDP), then return to this step after you’ve

accessed the desktop of the Attacker’s Workstation. The Attacker’s Workstation can

access the MX GUI, so accessing it directly is optional, but preferred.

Alternatively, once the Test Drive has finished launching you can obtain the necessary login

information from the ‘Environment’ window.




12. Accept the untrusted HTTPS connection using your browsers standard process. (We do not

generate trusted certificates for Test Drive since they are only live for a few hours):

13. Log into the GUI using the username and password provided in the email or in the

Environment window of the Test Drive signup portal.




14. You may have to wait a few minutes for the server to complete its initial load:

15. You are now in the SecureSphere GUI. If you are unable to connect, you might have a

blocked port. If you suspect your port is blocked, you can test it here:

http://portquiz.net:8083/

If you are unable to access a webpage at that address, ask your system administrator to

open outbound TCP port 8083. You will also want to check your local firewall to make sure

it’s not blocked on your workstation.

You can proceed to the next step, and access the Management Server (MX) from the

Attacker’s Workstation.

16. From your local workstation, access the Attacker’s Workstation using Remote Desktop

Protocol (RDP). In Windows, you can accomplish this by going to the command prompt,

typing mstsc, and pressing enter.







17. Enter the IP address of the Attacker’s Workstation that was provided in your email, or from

the OUTPUT window of the Test Drive signup portal.

18. Once prompted, enter your credentials to access the Attacker’s Workstation.




19. Click YES to accept the RDP session certificate.

20. You are now connected to the Attacker’s Workstation. From this workstation, you can

access the SecureSphere Management Server (MX) and generate attacks to the demo

webserver (SuperVeda).




Test Drive Environment

SuperVeda Webserver

SecureSphere

Admin

SecureSphere Gateways

Web GUI

Manage

2

1

3

5

4

Attacker

HTTP

HTTP

RDP

Web GUI (Alternate)

1 SecureSphere Admin This is your role, the person that uses a web browser to connect

to the MX, using HTTPS on port 8083. You will also use Remote

Desktop from your machine to the Windows machine we’ve

created for you in AWS to attack SuperVeda. The same machine

can act as both SecureSphere Admin and Attacker, in case your

browser cannot access port 8083 to the MX.

2 SecureSphere MX The MX controls the security policies, profiles, configurations,

alerts, and other functionality. The MX pushes the appropriate

configuration to the Gateways after each change.

3 SecureSphere

Gateways

The Gateways provide proxy functionality for the traffic. Only

traffic that’s load balanced (in this case HTTP/HTTPS) is passed on

to the webserver – all other traffic is dropped. After inspecting

the HTTP traffic against the policies and inspection engines, thetraffic is proxied to the SuperVeda webserver.

4 Attacker’s

Workstation

This is the Windows machine that you are RDP’d to, and can also

access the MX.

5 SuperVeda The vulnerable target that we will be attacking, then

subsequently protecting.




Within AWS, we’ve created all of the necessary components to provide enough infrastructure to

complete this Test Drive. This is not necessarily the way Imperva recommends deployment of

SecureSphere, this design is solely for the purpose of this Test Drive.

The AWS Architecture is represented below:

SuperVeda

For the purposes of this Test Drive, we will be using a website that’s been created specifically to

demonstrate vulnerabilities in web applications. The vulnerable website is for a phony online store

we’ve developed, called SuperVeda. We will be generating attacks againstthe SuperVeda website

within your own AWS private cloud. No attacks will leave AWS or affect any real company, as long as

these instructions are followed and all attacks are targeting the SuperVeda application. In this regard,

it’s very important to double check your work to ensure you’re not accidentally attacking the wrong

targets.

The testing site SuperVeda is open to many types of attacks, feel free to send a few if you know some off

the top of your head.




Lab 1: Protect Against SQL Injection

Overview

In this lab, we will send a SQL Injection attack against the target webserver, view stolen data, and then

enable protection against SQL Injection attacks. In order to demonstrate the damage that a SQL

Injection attack can do, we will turn off SecureSphere’s ‘Block Mode’ so the attack can pass to the

webserver. At a high level, we will follow this process:

1. Ensure the security is disabled

2. Generate SQL Injection attacks

3. View the alerts

4. Turn on Blocking Mode to stop the attacks

5. View the results

6. Summary




Test Drive Lab Procedure

Disable the security

1. First, make sure you’re logged into the Manager GUI and the Attacker’s Workstation, as described in

the previous section.2. Make sure that the security is disabled so you can experience the results of a successful attack. In

the GUI, we will set the system to ‘Simulation Mode’, as shown below:

1. Click on Main

2. Click on Setup3. Click on Web-Server Group within the left pane

4. Click on Simulation within the right pane

5. Click on Save

Generate SQL Injection Attacks

3. Open a web browser and navigate to the SuperVeda Website (the web server) from theAttacker’s

Workstation. As you can see below, we have an open RDP Session to the Attacker’s Workstation




with an open web-browser, using the URL that we received in the email.

4. At the end of the URL, paste this SQL Injection code and GO:

/showproducts.jsp?CatID=1 UNION SELECT 1,Username,1,1,'1','1','1' FROM users

So, your URL might look like this (with your IP instead of this sample):

http://OrbiteraT-elbExter-15KRX3MQUMOFB-2144608398.us-west-1.elb.amazonaws.com/showproducts.jsp?CatID=1 UNION SELECT

1,Username,1,1,'1','1','1' FROM users

The result is a webpage that shows the usernames of the people that have registered, as shown

below.

http://orbiterat-elbexter-15krx3mqumofb-2144608398.us-west-1.elb.amazonaws.com/









5. Since usernames have limited value, we can modify the string to steal passwords, as well as credit

card information. To do this, simply change the field you want to steal from the table, as shown

below:

To steal passwords:

http://<SERVER-IP>/showproducts.jsp?CatID=1 UNION SELECT 1,Password ,1,1,'1','1','1' FROM users

To steal Credit Cards:

http://<SERVER-IP>/showproducts.jsp?CatID=1 UNION SELECT 1,CCNumber ,1,1,'1','1','1' FROM users

Successfully attacking the server and stealing the credit cards results in a web-page with the credit

card numbers listed before the products:




View the Alerts

6. In the SecureSphere GUI, take a moment to view the Alerts generated by the attacks you’ve

generated.

1. Click on Monitor on the top menu

2. Click on Alerts on the sub-menu




3. Click on an Alert within the center pane that was generated during your session

4. Click on the + sign within the right pane to view the details of the Alerts

5. Return to step 3

7. Notice that there are several types of Alerts generated during your attack.

Protect Against SQL Injection

Now, it’s time to protect the SuperVeda webserver against attack. To do this, we will reverse what we

did in our 1st

step, which was to move to ‘Simulation Mode’. Now, we will move to ‘Active Mode’ where

attacks will be blocked instead of solely alerted upon.

8. To move SecureSphere into Blocking Mode, follow the steps below:

1. Click on Setup

2. Click on Web-Server Group within the left pane

3. Click on Active for the Mode selection within the right pane

4. Click on Save




9. Open the browser to SuperVeda web server and generate some attacks again, as you did in previous

steps. Try to steal usernames, passwords, and credit cards.

To steal usernames:

/showproducts.jsp?CatID=1 UNION SELECT 1,Username,1,1,'1','1','1' FROM users

To steal passwords:

http://<SERVER-IP>/showproducts.jsp?CatID=1 UNION SELECT 1,Password ,1,1,'1','1','1' FROM users

To steal credit cards:

http://<SERVER-IP>/showproducts.jsp?CatID=1 UNION SELECT 1,CCNumber ,1,1,'1','1','1' FROM users

You should receive a Block page which looks like this:




10. Check the Alert in the SecureSphere console, as previously described.



3. Click on an Alert within the center pane that was generated during your session, it will have the

Block symbol ( )in the 2nd

column.

4. Click on the + sign within the right pane to view the details of the Alerts.

5. Return to step 3 and view additional Alerts




Lab 1 Conclusion

In this lab, you were able to experience first-hand how a SQL injection attack can easily steal critical

information from unprotected web applications. Attackers exploit applications with the goal of stealing

sensitive data directly from the datacenter. By constructing a simple text string, we’re able to quickly

bypass common firewalls and steal usernames, passwords, and credit cards.

Next generation firewalls and intrusion prevention systems (IPS) are not equipped to stop application

attacks because they do not provide the accuracy, the granularity, or the breadth of protection to

thwart Web-based threats. While these solutions protect networks and users, they are ill-equipped to

stop attacks that target customers’ own websites. While next gen firewalls are “application aware”—

meaning that they can prevent users from visiting phishing sites or tunneling applications in HTTP—they

are not designed from the ground up to protect Web applications. As a result, they leave holes in their

application defenses—defenses that are only addressed by dedicated WAFs.

Once Block Mode was initiated in SecureSphere, we were able to stop the attacks across the entire

website. Because web application firewalls build a baseline of expected input, they can accurately stopattacks like SQL injection and cross-site scripting. By profiling Web application behavior, for instance, a

web application firewall can determine which users should not add brackets, braces, and semi-colons

into a zip code field on a registration page, but can enter these same characters into a comment field.

Validating input provides the context needed to differentiate between attacks and legitimate requests.




Lab 2: Protect against a Zero-Day attack using the Profile

Overview

In this lab, we will create our own Zero-Day attack, and attempt to send it to the SuperVeda webserver.

We will demonstrate how SecureSphere allows legitimate traffic through, while blocking attempts to

hack the application.

Create a Zero-Day attack

Send zero-Day attack to SuperVeda

View Alert

View Profile

Create your Zero-Day attack

Most attacks follow a structure of some sort. For the purpose of testing in the lab, we don’t actually

need the Zero-Day to work, we just need to create something that’s never been ‘in the wild’ before.

This technique ensures that it will bypass most signature based detection methods.

First, we will choose the structure we want to use, which includes the injection, the payload, and the

padding. Next, we will inject that attack into a page parameter.

For this exercise, use a text editor on your local machine or on the Attacker’s Workstation to craft the

attack.

Normal usage of an HTTP parameter is usually in the format of name=data. Take for example an online

store that sells books: it might use an HTTP parameter that looks like:

BookName=Security Handbook 2014

Or

Author = Dr. Seuss

SecureSphere studies and records good transactions, adding them to the application’s “Profile”. By

blocking on Profile Violations, the WAF will pass legitimate requests to the SuperVeda webserver, while

bad requests are blocked. SecureSphere doesn’t have to rely on signatures for attacks, as they are not a

reliable protection against zero-Day attacks.




We will follow this process to create our Zero-Day attack:

Choose your attack format

Choose your Injection

Create the Payload

Create the Padding Assemble the attack

The Injection is used to break the code and ‘open the door’ to our Payload. The Payload will contain the

destructive code we want to execute. The Padding is used to evade ISD/IPS, or push the code into the

correct position to execute properly. Then, we add the Zero-Day attack to a Parameter, so it might look

like:

BookName=Zero-Day Attack

Since Parameters could use a variety of characters, IDS/IPS and Next Gen Firewalls cannot protect

against this type of attack.

1. Choose which format you want to use for your Zero-Day attack:

1

2

3

4

2. Choose your Injection

Choose from one of the following example injections:

Choice Injection Potential Purpose

1 ‘) Breaks webserver code and starts a SQL statement

2 && Makes an AND list

3 > `/. Output Redirection

4 <script> Starts a script

5 || Makes an OR list

Injection Payload Padding

Padding Injection Payload

Injection Padding Payload

Injection Payload




3. Create the Payload

To create your payload, choose 2-3 random words and put them together. This will simulate some

unforeseen, unknown attack. Some examples are below, but feel free to create your own Payload.

Example Payload Potential Purpose

1 quickbrownfox Disables keyboard

2 boomboom Shuts down server

3 Gimme data Steals the database

4 Execute command Runs the command to get a list of processes

5 Ping Imperva.com Tries to ping Imperva.com

4. Create the Padding To create Padding, choose any character, and repeat it several times. Three example Paddings could

be:

000

WWWWWWWW

%%%%%%

5. Assemble the Attack

Assemble the attack by referring to the attack format you chose in step 1.

For example, if I chose Format 1, Injection 2, quickbrownfox, and ‘WWWWW’ as Padding, my Zero-

Day attack would like this:

The result would look like this: &&quickbrownfox%%%%%%

Injection&&

Payloadquickbrownfox

Padding%%%%%%




6. Click on ‘Create an Account’ within the SuperVeda website. Then, copy & paste the attack into the

‘First Name’ field.

7. You should receive a Block Page, such as this, which shows that the WAF blocked your Zero-Day

attack:




8. In the SecureSphere GUI, take a look at the Alerts that were generated from your attack, even

though no signature could have detected it.



3. View the most recent Alert, located at the top of the center pane. They will have Block symbol

( ) in the 2nd

column.

4. Click on the + sign within the right pane to view the details of the Alerts.

5. Return to step 3 and view additional Alerts




Lab 2 Conclusion

Despite the best efforts of application developers and IT security teams, most applications have

vulnerabilities. In this lab, you were able to create an attack that had never been performed, send it to a

web server, and observe the WAF protecting the application from attack. Next-generation firewalls and

IDS/IPS solutions lack the capability to enforce good behavior because they rely on signatures of known

attacks to protect servers. Zero-day attacks, APTs, and targeted malware easily bypass those solutions,

leaving applications open to attack.

Through defenses such as patented Dynamic Profiling technology, SQL injection and XSS correlation

engines, and detection of HTTP protocol violations, SecureSphere identifies zero-day attempts to exploit

web application vulnerabilities. In addition, once a new vulnerability is published, the Imperva

Application Defense Center (ADC) quickly develops a signature or a set of policies to virtually patch the

vulnerability. Through automatic security updates, all SecureSphere appliances receive the latest

security content and are protected against newly published vulnerabilities. Using SecureSphere, an

organization can ensure their web servers are protected against attacks, even before the attack is

conceived, developed, and executed.




Imperva Test Drive FAQ

Q: If I don’t have RDP access from my network, how can I try a Test Drive?

A: You can launch a free Windows workstation with your own AWS account. Alternatively, you

can try the Test Drive from a different internet connection if you aren’t able to access RDP. Also,

check your local firewall to make sure you’re allowed to use RDP Protocol.

Q: If I didn’t finish the Test Drive, can I try it again?

A: Yes, you can try a Test Drive up to 3 times.

Q: If I don’t port 8083 from my network, can I access the Manager (MX)?

A: Yes, you can use the Attacker’s Workstation to access the MX.

Q: Where can I learn more?

A: For the latest research and thought leadership, visit the White Papers & eBooks page on

Imperva.com.

http://www.imperva.com/Resources/WhitePapersAndEbooks







Copyright Notice

© 2014 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,752,662, 7,743,420, 7,640,235, 8,024,804, 8,051,484, 8,056,141, 8,135,498 and8,181,246.

Imperva Inc.

3400 Bridge Parkway, Suite 200

Redwood Shores, CA 94065

United States

Tel: +1 (650) 345-9000 Fax: +1 (650) 345-9004

Website: http://www.imperva.com

General Information: [email protected]

Sales: [email protected]

Professional Services: [email protected]

Technical Support: [email protected]



Contacting Imperva

Headquarters

3400 Bridge Parkway, Suite 200Redwood Shores, CA 94065

United States

Tel: +1 (650) 345-9000

Fax: +1 (650) 345-9004

General Information: [email protected]

Sales: [email protected]

Professional Services: [email protected]

Technical Support: [email protected]

Partners: [email protected]

Media Relations: [email protected]

Investor Relations: [email protected]

Imperva Sales:

(866) 926-4678 (US Only)

Technical Support:

(877) 467-3780

(650) 345-9000, option 2.

For questions relating to the Test Drive, please email [email protected]

mailto:[email protected]
















securesphere test drive lab manual

Documents