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 against
SQL Injection and
Zero-Day Attacks

Contents
Preface .......................................................................................................................................................... 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

SecureSphere on AWS Test Drive

Preface
This 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 Attackers Workstation
For a better browser experience, you can (optionally) access the SecureSphere manager over
TCP port 8083 (if open on your network)

Common Terms
The terms below are used throughout the document.

Term
Attackers Workstation
Web Application Firewall
(WAF)
SecureSphere
SecureSphere Manager
(MX)
SecureSphere Gateway
SQL Injection

Definition
A Windows machine that was set up for the purpose of sending
attacks, as well as optionally accessing the SecureSphere GUI.
A WAF stops attacks on HTTP servers, preventing a myriad of attacks
that NextGen Firewalls and IPD/IDS products cannot protect against.
Impervas comprehensive, integrated security platform that includes
SecureSphere Web, Database and File Security.
A web based GUI that unifies the administration, logging, and
reporting of multiple SecureSphere gateways.
Inspects and passes traffic to the destination webservers.
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).

SecureSphere on AWS Test Drive

Introduction to SecureSphere Web Application Firewall

Your 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 youre just as
concerned about blocking legitimate
users as you are about stopping attacks.
With that in mind, weve 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.

SecureSphere on AWS Test Drive

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 Reputation
Services 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 concerns
by 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.

SecureSphere on AWS Test Drive

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-customizable
reports. 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. SecureSpheres
unique, transparent bridge mode saves
time and labor with drop-in deployment
that requires no changes to existing
applications or network devices.
SecureSphere also delivers multi-Gigabit
throughput while maintaining submillisecond latency.

Data Center Security Leader

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

SecureSphere on AWS Test Drive

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 on AWS Test Drive

SecureSphere Test Drive on AWS Sign-up and Launch

Sign-Up for the Test Drive
1. Go to Amazons 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

SecureSphere on AWS Test Drive

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 its completed, the progress bar will show In
Progress

SecureSphere on AWS Test Drive

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:

SecureSphere on AWS Test Drive

Hello Edgard,
Your SecureSphere Test Drive has been created and is ready for you to use. Please
remember that after 3 hours the environment will no longer be available. The information you
need to login and use your TestDrive is available below.
From your location, you will need access to the Amazon Cloud. At a minimum, RDP protocol
and (optionally) TCP Port 8083 must be allowed outbound to AWS.

You can use Remote Desktop client to RDP to the IP address of Windows Attacker
Machine, and login using these credentials below
You can access the SecureSphere Manager (MX) using a web browser on port
8083(like HTTPS://ip_address:8083 )
If you dont have access to port 8083, the Windows Attacker Machine is able to login
to the MX

Login for Windows Machine:

User: TestDrive
Password: Imperva1
Login for SecureSphere Manager:
User: admin
Password: aws_is_cool1
Your IP address is below:

The Imperva Management Server IP and Username: admin and password

aws_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-west1.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 Attackers Workstation.
Your URL to the MX will look similar to this:
https://ec2-54-183-14-120.us-west-1.compute.amazonaws.com:8083

SecureSphere on AWS Test Drive

10

TIP: If you are unable to access the link provided in the email, proceed to Step 16
(accessing the Attackers Workstation using RDP), then return to this step after youve
accessed the desktop of the Attackers Workstation. The Attackers 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.

SecureSphere on AWS Test Drive

11

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.

SecureSphere on AWS Test Drive

12

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
its not blocked on your workstation.
You can proceed to the next step, and access the Management Server (MX) from the
Attackers Workstation.
16. From your local workstation, access the Attackers Workstation using Remote Desktop
Protocol (RDP). In Windows, you can accomplish this by going to the command prompt,
typing mstsc, and pressing enter.

SecureSphere on AWS Test Drive

13

17. Enter the IP address of the Attackers 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 Attackers Workstation.

SecureSphere on AWS Test Drive

14

19. Click YES to accept the RDP session certificate.

20. You are now connected to the Attackers Workstation. From this workstation, you can
access the SecureSphere Management Server (MX) and generate attacks to the demo
webserver (SuperVeda).

SecureSphere on AWS Test Drive

15

Test Drive Environment

4
RDP

Web GUI (Alternate)

Attacker
HTTP

1
Web GUI
Manage

3
SecureSphere Gateways

SecureSphere
Admin

HTTP

SuperVeda Webserver

SecureSphere Admin

SecureSphere MX

SecureSphere
Gateways

Attackers
Workstation
SuperVeda

SecureSphere on AWS Test Drive

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 weve
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.
The MX controls the security policies, profiles, configurations,
alerts, and other functionality. The MX pushes the appropriate
configuration to the Gateways after each change.
The Gateways provide proxy functionality for the traffic. Only
traffic thats 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, the
traffic is proxied to the SuperVeda webserver.
This is the Windows machine that you are RDPd to, and can also
access the MX.
The vulnerable target that we will be attacking, then
subsequently protecting.

16

Within AWS, weve 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 thats been created specifically to
demonstrate vulnerabilities in web applications. The vulnerable website is for a phony online store
weve developed, called SuperVeda. We will be generating attacks against the 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,
its very important to double check your work to ensure youre 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.

SecureSphere on AWS Test Drive

17

SecureSphere on AWS Test Drive

18

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 SecureSpheres Block Mode so the attack can pass to the
webserver. At a high level, we will follow this process:
1.
2.
3.
4.
5.
6.

Ensure the security is disabled

Generate SQL Injection attacks
View the alerts
Turn on Blocking Mode to stop the attacks
View the results
Summary

SecureSphere on AWS Test Drive

19

Test Drive Lab Procedure

Disable the security
1. First, make sure youre logged into the Manager GUI and the Attackers 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 Setup
3. 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 the Attackers
Workstation. As you can see below, we have an open RDP Session to the Attackers Workstation

SecureSphere on AWS Test Drive

20

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.

SecureSphere on AWS Test Drive

21

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:

SecureSphere on AWS Test Drive

22

View the Alerts

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

1. Click on Monitor on the top menu

2. Click on Alerts on the sub-menu
SecureSphere on AWS Test Drive

23

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, its 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

SecureSphere on AWS Test Drive

24

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:

SecureSphere on AWS Test Drive

25

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

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, 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

SecureSphere on AWS Test Drive

26

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, were 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 HTTPthey
are not designed from the ground up to protect Web applications. As a result, they leave holes in their
application defensesdefenses 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 stop
attacks 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.

SecureSphere on AWS Test Drive

27

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 dont actually
need the Zero-Day to work, we just need to create something thats 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 Attackers 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 applications Profile. By
blocking on Profile Violations, the WAF will pass legitimate requests to the SuperVeda webserver, while
bad requests are blocked. SecureSphere doesnt have to rely on signatures for attacks, as they are not a
reliable protection against zero-Day attacks.

SecureSphere on AWS Test Drive

28

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

Injection

Payload

Padding

Padding

Injection

Payload

Injection

Padding

Payload

Injection

Payload

2. Choose your Injection

Choose from one of the following example injections:
Choice
1
2
3
4
5

Injection
)
&&
> `/.
<script>
||

SecureSphere on AWS Test Drive

Potential Purpose
Breaks webserver code and starts a SQL statement
Makes an AND list
Output Redirection
Starts a script
Makes an OR list

29

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
1
2
3
4
5

Payload
quickbrownfox
boomboom
Gimme data
Execute command
Ping Imperva.com

Potential Purpose
Disables keyboard
Shuts down server
Steals the database
Runs the command to get a list of processes
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 ZeroDay attack would like this:
Injection
&&

Payload
quickbrownfox

Padding
%%%%%%

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

SecureSphere on AWS Test Drive

30

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:

SecureSphere on AWS Test Drive

31

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.

1. Click on Monitor on the top menu

2. Click on Alerts on the sub-menu
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

SecureSphere on AWS Test Drive

32

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.

SecureSphere on AWS Test Drive

33

Imperva Test Drive FAQ

Q:
A:

If I dont have RDP access from my network, how can I try a Test Drive?
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 arent able to access RDP. Also,
check your local firewall to make sure youre allowed to use RDP Protocol.

Q:
A:
Q:
A:

If I didnt finish the Test Drive, can I try it again?

Yes, you can try a Test Drive up to 3 times.
If I dont port 8083 from my network, can I access the Manager (MX)?
Yes, you can use the Attackers 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.

SecureSphere on AWS Test Drive

34

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-CopyrightInformation. 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 and
8,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]

SecureSphere on AWS Test Drive

35

Contacting Imperva
Headquarters
3400 Bridge Parkway, Suite 200
Redwood Shores, CA 94065
United States
Tel: +1 (650) 345-9000
Fax: +1 (650) 345-9004

General Information:
[email protected]

Imperva Sales:
(866) 926-4678 (US Only)

Sales:
[email protected]

Technical Support:
(877) 467-3780
(650) 345-9000, option 2.

Professional Services:
[email protected]
Technical Support:
[email protected]
Partners:
[email protected]
Media Relations:
[email protected]
Investor Relations:
[email protected]

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

SecureSphere on AWS Test Drive

36