— NEGATIVE SECURITY MODEL — ==> Allows all traffic and blocks as per security policies 

Initial Setup: First configure Management and then Gateway. 

1. Login with admin/admin 
2. When we are configuring Gateway, management IP is required. 

Upgrade: GW first and then MX 

• Download rpm file from imperva ftp 
• Verify with m5sum #md5sum <file> 
• Copy the file to /var/tmp 
• #rpm –ivh <rpm file> –> if any issue comes similar to internal.noarch, free up space in /var folder 
• If the above step is successful, WAF will share two steps to execute something like below 
• #cd /var/Securesphere/upgrades/upgrade****/bin 
• #./install 
• Press any key continue and enter ACCEPT 
• Once installation is completed, connect via SSH (admin:admin), type the below command to watch the status of the upgrade 
• #tail –F /root/upgrade.log 
• Once device comes up, login to MX and update ADC (Admin –> ADC –> update now) 

From v14: 

• • #md5sum <file> 
  • #chmod +x < .x file name> 
  • #./<file name> 

Post checks after upgrade:  

• • Telnet to MX on port 8083 from GW 
  • Telnet to GW on port 443 from MX 

#impctl status 

License: Log in to the user interface and follow these steps 

• In the Admin workspace, click ‘Licensing’. 
• Click Actions, then click ‘Upload License File’. 
• Navigate to the license file, then click ‘Upload’. 

Backup: 

• In the Admin workspace, click Maintenance > Export System. 
• OR 
• SSH into the MX as root 
• cd / tmp 
• type #full_expimp . sh  
• Select Export  
• Enter the password for user system  
• Select Full export to export the configuration with the alerts data, or Exclude alert data to export the configuration without it. 
• Choose whether you would like to export failed archive data (default is no). 
• Enter an encryption password when prompted with: Please enter the password for dump file encryption 
• If you are creating an export for an upgrade validation you must record this password and supply it a part of the validation process 
• Enter a file name for the export or let it default 
• If you allow it to default the file will be placed in the /var/tmp directory 

Import backup: 

• SSH to the management server 
• Move to the root user using the “admin” command 
• Move the export file to /tmp/ or /var/tmp/ (This would not work from other directories)  
• Start the utility with #full_expimp.sh 
• Follow the interactive wizard to import the file with your configuration.  

How to do Failover:  

• Add the gateways to same gateway group for automatic failover 
• Change the virtual router ID value from backup to master and Master to backup 

Patch installation: 

• #cat /opt/SecureSphere/etc/patch_level  –> to see the version 
• #uname –m –> to see the bit size 
• Recommended good practice 1: Before applying the patch, please take a full export for backup 
• Recommended good practice 2: Make sure you have at least 20% free space in the /var partition. Run #df –kh to view current space 
• Recommended good practice 3: Verify md5sum  
• #md5sum <.x file> 
• #chmod +x <.x file> 
• #./<.x file> 
• Reboot and update ADC content 

Patch installation fails due to / (root partition) reaching to 100% disk usage: Run the commands below to clear configuration repository files using the following commands on the gateway 

• #impctl gateway stop –teardown  
• #rm -rf /opt/SecureSphere/etc/archive/*  
• #rm -rf /opt/SecureSphere/etc/configuration/*  
• #rm -rf /opt/SecureSphere/etc/sg*  
• #rm -rf /opt/SecureSphere/etc/{gwconf.xml,config.xml}  
• #rm -rf /opt/SecureSphere/etc/global/*   
• #impctl gateway start –prepare 

WAF: It is the short form of a Web Application Firewall. It monitors web applications for security issues, which may arise due to errors in the code. 

Mutex: It is a mechanism of resource locking. For example, we don’t want to allow stop command while the server is starting, mutex prevents this from happening. While the server is starting or stopping, mutex of this resource is locked and prevents other operations of the same kind.  

Mutex should be unlocked as soon as the job is completed (i.e. when the server has successfully started or stopped). If the job is not completed for any reason the mutex lock will still be in place.  

#pkill -9 java –> Kill Java processes 

#ps aux | grep impctl | grep -E “start|stop”  –> Look for any running ‘impctl server start’ or ‘impctl server stop’ processes:  

#kill -9 PID –> Kill start/stop processes (replace PID with the actual PIDs you got in above step) 

Unlock mutex: 

• • For management-server mutex: #impctl mutex delete –mutex-name=services/management-server –force  
  • For gateway mutex: #impctl mutex delete –mutex-name=services/gateway –force  
  • For database-server mutex: #impctl mutex delete –mutex-name=services/database-server –force  
  • #impctl mutex show –> Verify that mutex is released  
  • If the output only shows ‘watchdog’ or is empty then the mutex is released. 

Interface link status: 

#ip link show 

#ifdown eth0 

#ifup eth0 

Imperva deployment modes: 

Transparent Bridge: SecureSphere is deployed inline in front of the protected application servers.  

In the event of a software, hardware, or power failure, SecureSphere’s specialized network interface card will detect the failure and physically complete the connection through the SecureSphere gateway. The NIC card will fail open in milliseconds, minimizing network downtime.  

However, application servers will not be monitored or protected from attacks until the SecureSphere gateway resumes operations.  

Sniffing: To deploy SecureSphere as a network monitor, connect it to an open SPAN port or a network TAP to observe traffic. A second connection to an active port on the switch allows SecureSphere to block malicious connections by sending TCP resets to both the server and the client involved in the session. In the event of a SecureSphere gateway failure, network traffic is unaffected. However, traffic will not be monitored or protected until the SecureSphere gateway becomes operational again.  

Transport Reverse Proxy: In Transparent Reverse Proxy mode, the client is unaware of the Reverse Proxy, and connects directly to the server. The On-Premises (SecureSphere) gateway is not visible to the client or to the server, which see each others’ real IP addresses. 

The On-Premises (SecureSphere) gateway is in bridge mode, but additionally functions as a Reverse Proxy for the servers specified in the SecureSphere GUI (in the Transparent Reverse Proxy section of the Definitions tab of the server group ( Main > Setup > Sites ). All other traffic, including non-Web traffic, is still bridged.  

In this way, the same On-Premises (SecureSphere) gateway protecting many Web and database server groups can act as a Reverse Proxy for some or all of the Web server groups it protects, and as a bridge for the other server groups.  
This allows the usage of DHE/ECDHE ciphers for server which are configured to work in Reverse Proxy 

The client begins the session by sending packets to the server’s IP address (12.1.1.10). The On-Premises (SecureSphere) gateway intercepts connections destined for the server, inspects them and forwards them on to the server. 

The server sees the connections as coming from the client’s IP address (70.1.1.50) and replies to that address. The return connection passes through the On-Premises (SecureSphere) gateway, which inspects them and forwards them on to the client. 

Kernel Reverse Proxy: In a Kernel Reverse Proxy deployment, the client begins the session by sending packets to the SecureSphere Gateway’s inbound IP address. The SecureSphere Gateway inspects the packets and, based on the rules, opens a second connection to the server, changing the packet’s source IP address to the SecureSphere Gateway’s outbound IP address and the destination IP address to the real IP address of the server. 

The server sends the return packets to the SecureSphere Gateway, which inspects the packets, changing the source IP address to the SecureSphere Gateway’s inbound IP addresses and the destination IP address to that of the client, and sends the modified packets to the client. 

Packets that do not match any of the decision rules are ignored. You may wish to define a default rule that sends these packets to a server that generates a customized error message for the client. Packets that do not match the ssl protocol will also be blocked.

TRP vs KRP: 

The SecureSphere Web Application Firewall supports both reverse proxy and transparent proxy configurations. Both proxy configurations offer content modification, including cookie signing and URL rewriting. Transparent proxy mode enables transparent deployment without network or DNS changes.  

How Imperva Reverse proxy works: This is possible through Gateway Aliases setting 

1. Connection initiates from Internet to WAF 
2. WAF holds the connection and Initiates new connection to end server 

Security policies Exception: Monitor –> Alerts 

1. Filter as per the requirement 
2. Select the Alert and Violations will show up in the right pane 
3. Expand any violation (if multiple), click on Exception symbol (+e) to create an exception. 
4. Select the policy (Policies –> Security) and click Advanced to see the exceptions (click on any Exception summary and edit as per requirement) 
5. If there is no exception symbol in the violations page, copy the policy and go to the security policy section and search for the same policy and create an exception based on match criteria 

Gateway Aliases: Setup –> Gateways 

Select the Gateway: 

• • Virtual routers –> Click New to add Network Interface, VR ID (any number), Primary IP address (Gateway IP address which sends the traffic to end server), Default state (Master or backup) 
  • IP Addresses –> Click New to add Network Interface, Ip address (Application IP address from WAF interface subnet, unique for each application, traffic comes from Internet to this IP address), select virtual ID 
  • Aliases –> Click new to add Name, External Address (Application IP address from WAF interface subnet, unique for each application, traffic comes from Internet to this IP address), Internal Address (WAF IP address which sends the traffic to end server) 

Application setup: Setup –> Sites:  

• Create Site –> it’s just a location name 
• Select Site and Create Server group –> Here operation mode and basic security policies will be enabled
  • To add a protected Application IP address (Bridge mode): Definitions –> Protected IP addresses 
• Select Server group and Create Service –> 
  • Add a Certificate: Definitions –> Encryption support –> Add (+) 
  • Error page: Definitions –> Error page:  to add a custom error page 
  • To add a Protected Application IP address (Kernel Reverse Proxy Mode): Reverse Proxy –> Reverse Proxy –> Add (+)
    • Add Gateway IP Alias, Gateway port, Server Certificate 
    • Priority: Click Add (+) – To add Internal IP/Hostname (end server IP) and server port, Enable Encrypt if traffic should be encrypted from WAF to end server 
• Edit the Application name with in the service where we can restrict monitoring to URLs or ignore URLs/Directories 

Http Request and Headers: A request header is an HTTP header that can be used in an HTTP request to provide information about the request context, so that the server can tailor the response 

Request headers contain more information about the resource to be fetched, or about the client requesting the resource. Response headers hold additional information about the response, like its location or about the server providing it 

• • GET /tutorials/other/top-20-mysql-best-practices/ HTTP/1.1 
  • Host: code.tutsplus.com 
  • User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.1; en-US; rv:1.9.1.5) Gecko/20091102 Firefox/3.5.5 (.NET CLR 3.5.30729) 
  • Accept: text/html,application/xhtml+xml,application/xml;q=0.9,*/*;q=0.8 
  • Accept-Language: en-us,en;q=0.5 
  • Accept-Encoding: gzip,deflate 
  • Accept-Charset: ISO-8859-1,utf-8;q=0.7,*;q=0.7 
  • Keep-Alive: 300 
  • Connection: keep-alive 
  • Cookie: PHPSESSID=r2t5uvjq435r4q7ib3vtdjq120 
  • Pragma: no-cache
  • Cache-Control: no-cache 

HTTP response codes: 

• 1xx informational response – the request was received, continuing process 
• 2xx successful – the request was successfully received, understood, and accepted 
• 3xx redirection – further action needs to be taken in order to complete the request 
• 4xx client error – the request contains bad syntax or cannot be fulfilled 
• 5xx server error – the server failed to fulfil an apparently valid request 

HTTP Response Codes (Important):

200 OK: Standard response for successful HTTP requests. The actual response will depend on the request method used. In a GET request, the response will contain an entity corresponding to the requested resource. In a POST request, the response will contain an entity describing or containing the result of the action. 

301 Moved Permanently: This and all future requests should be directed to the given URI 

302 Found (Previously “Moved temporarily”): Tells the client to look at (browse to) another URL. The HTTP/1.0 specification (RFC 1945) required the client to perform a temporary redirect with the same method (the original describing phrase was “Moved Temporarily”), but popular browsers implemented 302 redirects by changing the method to GET. Therefore, HTTP/1.1 added status codes 303 and 307 to distinguish between the two behaviours 

400 Bad Request: The server cannot or will not process the request due to an apparent client error (e.g., malformed request syntax, size too large, invalid request message framing, or deceptive request routing). 

401 Unauthorized (RFC 7235): Similar to 403 Forbidden, but specifically for use when authentication is required and has failed or has not yet been provided. The response must include a WWW-Authenticate header field containing a challenge applicable to the requested resource. See Basic access authentication and Digest access authentication. 401 semantically means “unauthorised”, the user does not have valid authentication credentials for the target resource. 

403 Forbidden: The request contained valid data and was understood by the server, but the server is refusing action. This may be due to the user not having the necessary permissions for a resource or needing an account of some sort, or attempting a prohibited action (e.g. creating a duplicate record where only one is allowed). This code is also typically used if the request provided authentication by answering the WWW-Authenticate header field challenge, but the server did not accept that authentication. The request should not be repeated. 

404 Not Found: The requested resource could not be found but may be available in the future. Subsequent requests by the client are permissible. 

500 Internal Server Error: A generic error message, given when an unexpected condition was encountered and no more specific message is suitable. 

501 Not Implemented: The server either does not recognize the request method, or it lacks the ability to fulfil the request. Usually this implies future availability (e.g., a new feature of a web-service API). 

502 Bad Gateway: The server was acting as a gateway or proxy and received an invalid response from the upstream server. 

503 Service Unavailable: The server cannot handle the request (because it is overloaded or down for maintenance). Generally, this is a temporary state. 

504 Gateway Timeout: The server was acting as a gateway or proxy and did not receive a timely response from the upstream server. 

Imperva models: X2010, M160 

Broken URLs and References:  

A broken link is a link from one of the application’s learned hosts which points to a non-existing URL. 

A broken reference is like a broken link, except that the link is from an external source. 

WAF password recovery: 

• Prepare a Live USB and boot the applance from it 
• Mount the root partition and edit grub.conf to remove the bootloader password 
• Save the changes and reboot 
• Stop at the grub screen and bring the system up in single user mode 
• Change the root password 
• Reboot 

Prepare the Live USB: 

1. 1. Create a Fedora 17 i686 Desktop liveusb: 
   2. Copy the “Fedora-17-i686-Live-Desktop.iso” file from our FTP to your computer (/Downloads/Tools/Fedora/Fedora-17-i686-Live-Desktop.iso) 
   3. Insert a USB disk 
   4. Run the Live USB Creator ( run as Administrator) – “Live USB Creator” can be found on the FTP ( /Downloads/Tools/FEDORA/liveusb-creator-3.12.0-setup.exe )  
   5. Make sure Target device point to your USB drive. 
   6. Click on “Browse” Button to choose the “Fedora” file. 
   7. Click on “Create Live USB” 
   8. Once this is complete, you must edit the \syslinux\syslinux.cfg file located in the usb drive: 

IMPORTANT – For the editing task you MUST use a third-party text-editor, such as Notepad++, to ensure proper formatting.  
Edit \syslinux\syslinux.cfg, on the USB device, Erase its contents and copy and paste the below: 

SERIAL 0 38400 CONSOLE 0 default vmlinuz0 initrd=initrd0.img root=live:CDLABEL=LIVE rootfstype=vfat ro liveimg quiet rhgb rd.luks=0 rd.md=0 rd.dm=0 serial text console=ttyS0,38400n8 

Note: On some devices, you may need to use SERIAL 1 38400 and CONSOLE 1 and ttyS1 instead of 0. There is no way to tell beforehand.  
Additional: On M110, M160, and X-xx10 devices, you may need to use 9600 instead of 38400.  

Boot the appliance from USB and remove the bootloader password: 

1. 1. Connect the USB to your appliance and boot from the USB stick (following reboot it should boot from USB by default).
   2. Login as root when login is presented.
   3. Mount the root volume to /mnt-mount /dev/sysvg/root.vol /mnt . Verify it is mounted using df -h | grep /mnt  
   4. Edit /mnt/etc/shadow.Replacethe string near the root until the first“:” with the following string (which is a hash of the string ‘123456’) – $1$A6HcN8Ee$s6qjS6Nzu/JhWdq4CP10D.  
   5. Press ESC to exit edit mode. Type ” wq” to save and quit 
   6. Run the following commands to save your changes and reboot safely   

• • • sync; sync  
    • cd /  
    • umount /mnt  
    • reboot  

Remove the USB stick and let the appliance boot off the hard drive.   

Change root password:  

1. 1. The system will boot up normally and will ask you to login. Enter user root and use password ‘123456‘
   2. Now , you can change back the root password using the ‘impcfg’ tool.  
      • Type impcfg  
      • Go to Manage platform > Manage Users > Change user ‘root’ password and Save & Apply the changes 
      • Old password is ‘123456’ 
      • Enter the new password 
   3. This completes the password recovery process. 

Confidentiality, Authentication, Integrity (CIA): 

• Confidentiality is roughly equivalent to privacy. Confidentiality measures are designed to prevent sensitive information from unauthorized access attempts. It is common for data to be categorized according to the amount and type of damage that could be done if it fell into the wrong hands. More or less stringent measures can then be implemented according to those categories. 
• Integrity involves maintaining the consistency, accuracy and trustworthiness of data over its entire lifecycle. Data must not be changed in transit, and steps must be taken to ensure data cannot be altered by unauthorized people (for example, in a breach of confidentiality). 
• Availability means information should be consistently and readily accessible for authorized parties. This involves properly maintaining hardware and technical infrastructure and systems that hold and display the information. 

OWASP TOP 10: 

1. Broken Access Control 
2. Cryptographic Failures 
3. Injections 
4. Insecure Design 
5. Security Misconfigurations 
6. Vulnerable and outdated components 
7. Identification and Authentication Failures 
8. Software and Data integrity failures 
9. Secure logging and monitoring failures 
10. Server-side request forgery (SSRF)  

Cookie injection: When a client sends the application a cookie it did not originally receive from the application. 

Cookie tampering: When a client alters a cookies that the application expects will not be altered. 

Cookie signing: SecureSphere adds a cryptographic signature to prevent tampering. 

Cookie encryption: SecureSphere encrypts cookies to prevent injection 

URL Rewriting: It is the process of modifying Uniform Resource Locators (URLs) for various purposes. The URL as a “web address” is a string that, when entered into the browser bar field, directs the browser to move to a given site and page. Changing the URL can help with user access and site visibility; it can also be used by hackers to redirect users without their knowledge or “trap” them in a certain site. 

URL rewriting is also known as URL manipulation. 

URL rewriting can be done through coding with various tools, or with a “rewrite engine” that automates the process. Webmasters may want to rewrite a URL for readability, to make it easier for users to type into the URL bar, or for various other types of advertising or visibility benefits. 

In hacking, URL rewriting can automatically redirect user traffic, or spoof legitimate sites. The results of this kind of malicious URL rewriting can be frustrating as users find themselves shunted around to pages or sites that they do not intend to visit. In general, URL rewriting is a part of the conventional protocol for the internet that works and directs traffic on the basis of URLs. 

SSL Handshake: 

Symmetric encryption: one key for encryption and decryption. 

Asymmetric encryption: uses two different keys, the Public Key, is used for encryption and the other, the Private Key, is for decryption. 

PFS: Perfect Forward Secrecy (PFS), also known as Forward Secrecy, is an encryption style known for producing temporary private key exchanges between clients and servers. For every individual session initiated by a user, a unique session key is generated. This ongoing process ensures that even if the most recent key is hacked, a minimal amount of sensitive data is exposed. 

Hard shutdown: 

• To perform graceful shutdown: Insert pin into item H at the front of appliance 
• To perform hard/ungraceful shutdown: 

Insert a pin into item H for 10 seconds at the front of appliance will perform immediate power off  OR 

Press the power switch item U at the back of appliance 

• To power up:  

Once appliance is fully powered down, insert pin into item H again OR press the power switch item U to power up 

What should you do if impcfg is “locked” with message “another impcfg session is currently active on this machine”: 

#killall -9 impcfg  

#impctl mutex delete –mutex-name=impcfg –force  

The first command will kill any existing impcfg sessions, the second commands unlocks it so it can be relaunched.  

SNMP configuration: 

#service snmpd stop  
#chkconfig –level 2345 snmpd off  

* Since version 14.2 impctl commands are available to disable snmp:  

To disable SNMPv1 #impctl platform snmp config –disable-snmp-v1 

To disable SNMPv2 #impctl platform snmp config –disable-snmp-v2 

SNMP Service Start/Stop/Restart/Status: #impctl platform snmp start/stop/restart/status 

The security features provided in SNMPv3 are as follows: 

• • Message integrity—Ensures that a packet has not been tampered with during transit. 
  • Authentication—Determines that the message is from a valid source. 
  • Encryption—Scrambles the content of a packet to prevent it from being learned by an unauthorized source. 

To configure snmp v2 or v3: 

#impctl platform snmp config –version=2 

#impctl platform snmp config –version=3 –authentication-password=Imperva12# –encryption-password=Imperva12# –user-name=imperva 

#cd /etc/snmp 

#cp snmpd.conf snmpd.conf.backup 

#vi snmpd.conf 

Com2sec <community name> 

View systemview included .1 

Banner configuration: 

#vi /etc/ssh/banner.txt  

What logs should be provided while opening a new case: 

• SN (Serial Number) of your management server. 
• Version and patch number you are using. 
• License challenge string from the license page in the GUI. 
• For DB agent related cases, please supply the agent version. 
• For possible HW issue, please supply the SN of the suspected faulty appliance. 
• Screenshot of the relevant issue. 
• MX tech info 
• Gateway Tech info 

#impctl support get-tech-info [–last-server-archives=5] [–case-number=<case#>] 

How do I resolve the error “Gateway reverted to last known good configuration”:

Clear the configuration cache on the MX,  

• SSH to the MX #impctl server stop 
• Delete the files under the following directories:  

#rm -rf /opt/SecureSphere/server/SecureSphere/jakarta-tomcat-secsph/webapps/SecureSphere/gwconfig/*  

#rm -rf /var/ServerLogs/SecureSphereWork/conf_classes/* 

• Start the MX: #impctl server start 

• Then, force the Gateway to get a configuration update: SSH to the GW 
• Stop the GW #impctl gateway stop 
• Run commands below: 

#rm -fr /opt/SecureSphere/etc/configuration/**  

#rm -rf /opt/SecureSphere/etc/sg*  

#rm -rf /opt/SecureSphere/etc/{gwconf.xml,config.xml}  

#rm -rf /opt/SecureSphere/etc/global/*   

#impctl gateway start  

Verify that the Gateway have received the configuration successfully. SSH to the Gateway and Run the command:  

#gwlog –> Search for the following notification (this is an example only):  

<div id=”NOTIFICATION”>06/10/2013 14:56:57<b>[NOTIFICATION]ConfigManager.cpp:4709</b> Full configuration update finished successfully (in 65 seconds)</div> 

If the Full configuration update isn’t finished successfully, contact Imperva Support, and provide the Tech info taken from your Gateway and MX. 

Fail Open: In the event the Gateway fails (For example powered off), it will continue to pass traffic without monitoring it. 

Fail Close: In the event the Gateway fails, it will block all traffic. 

High Availability: The gateway group is a High Availability cluster 

TLS version support and configuration: 

#vi /opt/SecureSphere/etc/bootstrap.xml –> look for <tls-supported-versions>, Changing the flag from true to false will disable a TLS version.  

Make sure to restart gateway after saving the changes for them to take effect by command below:  

#impctl gateway restart  

Enable ping (icmp) to On-Premises (SecureSphere) appliances: 

• Edit the file /etc/sysctl.conf  
• Scroll down to the line beginning with net.ipv4.icmp_echo_ignore_all  
• Change the value of the line from 1 to 0 
• Before: 

net.ipv4.icmp_echo_ignore_all = 1  

• After: 

net.ipv4.icmp_echo_ignore_all = 0  

• Save the changes to the file and exit 
• Ping will be enabled after reboot of the appliance. 

To enable ping immediately without rebooting type the no following command as root (note this will not survive reboot): 

#echo 0 > /proc/sys/net/ipv4/icmp_echo_ignore_all  

IP Tables: 

To list the current iptables rules type: #iptables -L –n 

Add rules to iptables in the following order 

The first rule accept icmp from a specific host or network (in the example below the network s 10.1.1.0/24). 

#iptables -A INPUT -s 10.1.1.0/24 -p icmp -j ACCEPT  

The second rule blocks icmp from anywhere 

#iptables -A INPUT -s 0/0 -p icmp -j DROP

Run command “/sbin/service iptables save ” to save the iptable changes.   

To DELETE an IP from the IP tables:  

#iptables -D INPUT -s 10.1.1.0/24 -p icmp -j ACCEPT  

Important Note: Do NOT use this solution for MX-HA Servers.   

Planning: 

• Know your application – is it all SSL or a mix of non-SSL and standard port 80 traffic  
• Does the HTTP/S traffic use DHE based ciphers – if they do you will need to plan on deploying Reverse proxy  
• WAF in bridge mode cannot decrypt/monitor DHE encrypted connections due to the algorithm used  
• What is the average and max HTTP hits/sec – this may be hard to obtain but proper sizing requires such information 
• look at the network and  implement routing/switching so the WAF primarily sees only traffic that needs to be inspected  

Policies:  

• Imperva provides a number of security policies out-of-the-box, and a few are applied by default  
• Look through these policies so you have a base understanding of what protection is already in place by default 
• Understand your industry security requirements. For example banking sites may need to look at policies that mitigate credential stuffing  
• review the match criteria which is provided – by using the proper criteria you can create a policy that bets fit your needs 

Profiling:  

• Profiling is a key feature that allows the WAF to learn what is normal behavior for the application  
• you should always review what the profile has learned in case there was something that should not be allowed was learned  
• It uses this information to detect anomalies that may indicate malicious  activity  

Factory reset: It can be via USB installation 

• Download usb file from imperva ftp portal 
• Download image writer and write the file to usb 
• Plug the usb to the device and reboot 
• After the appliance boots, select installer as 9600 baudrate one 
• Once installation completes, login with admin:admin 

How to see the throughput of the device: 

#cat /proc/hades/status —> v13 

#cat /opt/SecureSphere/etc/proc/hades/status —> v14  

#Impcfg 

#Impctl platform dmi show | grep Serial 

#dmidecode -s chassis-serial-number 

#impctl –version 

#impctl gateway show 

#impctl gateway register –> To register gateway with Management 

#impctl platform console show –> To see the current baud rate 

#impctl platform console config –baudrate=<value> –->To modify the baud rate value with  38400 or 115200 or 9600.. This action requires reboot 

#impctl platform network bypass show –> Gateway showing Running (In Bypass) Status in the WebUI 

#brctl show (If the gateway is running in Bridge STP Mode).  

#impctl platform snmp status 

#impctl gateway sniffing show –> To verify which interfaces are used for sniffing / blocking 

#impctl gateway start  

#impctl gateway start –prepare  –> prepares the resources (such as bridges and sniffing interfaces) while the former only starts the gateway process.  
 
#impctl gateway stop  

#impctl gateway stop –teardown –> removes all of the resources as well. In order for the gateway to properly run it has to have the resources “prepared”.  

#password_decode $(grep “name=\”db\”” /opt/SecureSphere/etc/bootstrap.xml|cut -d\” -f4) –> To retrieve system password 

#password_decode $(grep “name=\”secure\”” /opt/SecureSphere/etc/bootstrap.xml|cut -d\” -f4) –> To retrieve secure password 

#watch -d -n 1 cat /proc/hades/cpuload  –> to display the current average CPU load 

#watch -d -n 1 cat /opt/SecureSphere/etc/proc/hades/cpuload –> On v.14 Gateway RP mode the command looks like 

#poweroff 

#impctl platform reboot 

#reboot 

#gpg –cipher-algo=3DES –no-mdc-warning -q -o <decrypted-file-name> <full-export-config-file>.tgz –> Give the passphrase which is used to encrypt the file 

#ethtool eth0 –> determining the speed and duplex setting of network interface 

#find / -printf ‘%s %p\n’ | sort -nr | head -100  —> Finding the 100 biggest files on GW\MX 

#wget https://<GW-IP>/requestfullconfig –no-check-certificate –> Forcing GW to get new configuration, issue this command on the MX: 

#nc -z www.imperva.com 443 

#cd /var/crash/imperva 

#chmod 777 <gz filename> –> to transfer