1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
It is recommended to begin the implemementation in QA/staging environment. You can deployment in production
but be cautions about traffic volume, and Auto Policy Generation profiles you use (Production Profile only.)
Gather required information for deployment:
Obtain Network Topology diagram
If a penetration test was conducted and information can be gathered before the implemementation, it will be ve
Do you have a public Admin path that requires special attention?
Are there any File Upload folders? (if positive what extensions are valid)
Are there any Streaming Media files?
Where are the Login pages? We will need valid username and password for the testing.
Please define what is the Code Page for every site we need to protect (UTF-8, 8859-2 etc.)
Sensitive Cookies in the application?
Are Credit Card Numbers processed by the Application? Are the numbers in a database?
Any other confidential information (such as national ID numbers) that should not appear in the response?
Any know Web Application vulnerabilities you are aware of?
You would need a contact person who is knowledgeable on all web application areas and can perform all kind
activates (surfing, purchasing and such) and can also confirm that everything is working.
Is there a Security Page for the website?
For example: http://www.radware.com/securityblock/securityblock1.asp?_event_transid=2181105781
See our template here: http://kb.radware.com/questions/2695/
PHASE 2
PHASE 2.1
Details
if the web application is externally accessible, you can View traffic, identify potential challenges, activate Auto Discovery
before arriving on site
Reverse Proxy: suitable for ADC deployment when original client IP address is not required in web app. If Client IP
address required for logging purposes only, you can add client ip address in XFF header and still use the Reverse Proxy.
The preferable deployment mode. For Additional information please refer to KB2559.
Transparent Proxy: suitable for ADC deployment when original client IP address required in web app. Please refer to
line 20 for limitations of this deployment mode.
Bridge: suitable for standalone AppWall deployments, usually in a non-ADC environment.
It is highly recommended to deploy AppWall in a Test/QA/Staging environment first, especially as part of implementation.
If the prefered deployment is in the production environment, and the SSL traffic is terminated before the Web servers
you may consider using AppWall Monitor for span port traffic.
Deployment in production in-inline mode Gateway is not recommended but might be requested.
PHASE 2.2
Test the cache policy with Alteon / AppDirector on the target web site for afew
days prior to moving traffic through AppWall.
After redirecting the traffic through AppWall, set the cache only on AppWall farm (there is a common mistake to set
cache also on the web server farm).
Set on Alteon/AppDirector the Close on session end and check the peak value.
There is a limitation with activating Acceleration and SSL offloading features in AppDirector along with AppWall in
Transparent Proxy mode:
- AppDirector versions 1.x support Transparent servers but not SSL offloading.
- AppDirector versions 2.x support SSL Offloading but no transparent servers.
Caching
SSL Termination
preferably enable SSL Termination at the ADC. If AppWall must process SSL traffic you have the option to set the tunnel
to either SSL-Clear or SSL-SSL mode. If using SSL-SSL consider smaller encryption key in the backend web servers
Multiplexing
Multiplexing might be an issue, as termination of one server tcp connection by AppWall upon security violation, might
impact multiple client connections. Recommended not to use.
Layer 7 Policy
In the scenario of many web servers which might result in many tunnels, use Host header based policy in the ADC.
Host header Policy enables defining single tunnel to different applications and different servers. The need for more than
a single tunnel will be when both SSL and HTTP traffic is used, and when multiple encoding types are utilized
(applications in different languages). For additional details about host based security policy please refer to KB2869
Redirect Policy
Disable Multiplexing on AppWall's Farm (in AppDirector)
AppWall Deployment
place AppWall in a server rack
Connect AppWall to the network. Make sure there are at least 2 available
network ports in the switch
At least one port used for web application traffic and one port for management. Additional NICS can be added. In Bridge
mode 2 NICs required for Bridge and one for management.
Define unique hostname for AppWall server, set management IP for remote
management
Upgrade to AppWall latest version
Install the latest Java on your PC in order to run AppWall MNG Application
https://MNG_IP/Console/
PHASE 3
Time zone
DNS
Default Gateways for Management and Services
Routing Rules
Management IP
Services IP
Management Default Gateway for separated routing of Management traffic
In the
scenario of Bridge mode deployment, configure a bridge IP, from the relevant network segment
Bridge IP - for Bridge mode deployment; the bridge ip address must not be from the MNG subnet
MNG IP and Bridge IP must be with
a different networks
If management application shows "Ended with Errors" message at the bottom, follow the next instructions:
check > Forensics > initialization logs - look for red items:
usually License issue or Is
Open Ports - change rule for port 80/443 to allow access to AppWall instead of directly to Servers
Open TCP ports in the network Firewall for management interface (for encrypted mgmt traffic):
8200 (Gateway management)
8270 (Cluster management)
443 for Web Interface
22 for CLI (SSH)
2214 and 9216 (Vision) - for more details please refer to KB2710
Verify (in the user guide) that the required code-pages are supported.
If not contact Support to add support for required Code-page
Build a Company Security page to which users will be redirected upon security violation (e.g. "Please contact customer
support."). An advance security page which can process query parameters, can accept and show event transaction ID
for easier search in Forensics (by default the parameter name is "_event_transid").
For more details please refer to KB2695
Ask the Admin to provide all SSL server certificates and the passwords
Install certificates on Alteon / AppDirector.
Define SSL policy.
If end-to-end SSL required, import certificates to AppWall as well.
In ADC deployment it will usually be an internal VIP that will balance the traffic to the web servers.
In non-ADC environment, Web server interface will be the protected web server.
in Bridge mode deployment, you can also set a Web Farm
Create a new tunnel(s) in AppWall. If creating an SSL tunnel select the Server
certificates imported in phase 2
If at this phase protecting multiple servers is required, you should plan how to distribute traffic to your applications: The
total number of tunnels which can be defined in AppWall is limited to 50. Even without reaching this limit, if you are
required to add more than 15 tunnels, you should consider revising your tunnel planning:
Please refer to Layer 7 Policy section (C 24).
PHASE 4
PHASE 4.1:
Security
Level 1
In the Security Policy view, create a new Web Application using the web
application wizard, with:
- "/" Application Path
- Rapid Auto Policy Generation mode
- Select the relevant Profile: If staging environment select Manual Browsing or
Manual Crawling; if Production, select Production Rapid.
At the host level (under web application) configure the Security Page
Browse through AppWall
Auto Discovery will show access information (parameters status codes, 404, etc.) and application structure
define who will access the application through AppWall in the first phase (QA, test group, admin). Warning: do not use
staging profiles in production environment.
Testing
QA team or admin, either manually or also using a crawler browse through the entire Web application (make sure all
dark corners are accessed as well) - to generate logs for later fine tuning.
Verify that Vulnerabilities, Database and HTTP Methods security filters are
enabled. Review the Path Blocking filter findings, disable Safe Reply\Path
Blocking in case there is no need.
Let the system generate policy automatically
Fine tuning through Refining the security policy from the Security events, using
"Refine!" button
Violations of HTTP RFC should be fixed in application or can be set to be ignored by AppWall either for specific URL or
for "Any URL".
Review all Security events in the Forensics view.
At this point all traffic should be legitimate and should not be blocked. Refine the events that generate false positives.
At this point 404 status code can be identified as well (broken links)
consider using Discard all rules or Apply to all other pages
OR
PHASE 4.2:
Security
Level 4.2.1:
2
PHASE
Verify that Vulnerabilities, Database and HTTP Methods security filters are
enabled in all Application Paths
Initially the admin should access the application through AppWall to validate traffic is processed properly and basic
legitimate requests are not blocked. Specifically check message size logs that nothing is blocked
Auto Discovery will show access information (parameters status codes, 404, etc.) and application structure
define who will access the application through AppWall in the first phase (QA, test group, admin). Warning: do not use
staging profiles in production environment.
Testing
QA team or admin, either manually or also using a crawler browse through the entire Web application (make sure all
dark corners are accessed as well) - to generate logs for later fine tuning.
Fine tuning through Refining the security policy from the Security events, using
"Refine!" button
Message Size and RFC properties are part of the Auto Policy Generation. Nevertheless review the events for details and
refine:
Message size and parsing properties events should be reviewed first
Violations of HTTP RFC should be fixed in application or can be set to be ignored by AppWall either for specific URL or
for (Any URL)
Review all Security events in the Forensics view.
Parameters Security Bypass list can be updated to bypass cookies that do not require protection. Add the Alteon /
AppDirector persistency cookie to the list of bypassed parameters
At this point all traffic should be legitimate and should not be blocked. Refine the events that generate false positives.
At this point 404 status code can be identified as well (broken links)
consider using Discard all rules or Apply to all other pages
PHASE 4.2.2
e.g. if during penetration test a specific folder was identified as exposing sensitive info and should not be accessed, can
be added to Path Blocking
Is there any /admin/ application path (for configuration of the web site, creating Add Path Blocking filter to all Application paths, and add sensitive folders to Path Blocking filter on all application
web users, etc). if so, consider using path blocking for that path.
Paths.
If limited access is needed, define web role(s) based on source IP address or based on Successful Login Detection. You
can then allow access to these path only relevant role.
Is there any file upload folder? if so, use "File Upload"
If exists create Application Path for Upload application and define File Upload filter on it with specific allowed file types
If limited access is needed, define web
role(s) based on source IP address or based on Successful Login Detection. You can then allow access to these path only
relevant role.
Are there any streaming files (swf, avi, mpeg, radio). if so use "bypass
if exists - define to bypass in tunnel level "Security Bypass" tab. Also allows ignoring problematic applications cookies
extensions"
(ASP, Google, etc.)
use Brute Force security filter to secure login pages
Create Application Path for Login page and Authenticated pages, and enable Brute Force Filter on them. For additional
information, refer to KB2952.
Securing cookies (the default is signing, but you can also encrypt) impacts performance
Preferably secure only the sensitive cookies identified rather than securing all
Session security filter events should be reviewed to define whether there are cookies that should not be processed as
the client side need to read or manipulate them.
OR
PHASE 4.3:
Security
Level 4.3.1:
3
PHASE
In the Security Policy view, create a new Web Application using the web
application wizard, with:
- "/" Application Path
- Extended Auto Policy Generation mode
- Select the relevant Profile: If staging environment select Manual Browsing or
Manual Crawling; if Production, select Production Automatic
if possible import and process sitemap.xml for shorter time for initial policy
Initially the admin should access the application through AppWall to validate traffic is processed properly and basic
legitimate requests are not blocked. Specifically check message size logs that nothing is blocked
Auto Discovery will show access information (parameters status codes, 404, etc.) and application structure
repeat this periodically at the during the initial auto policy process.
For Regular Expression Application Path please refer to KB2506
define who will access the application through AppWall in the first phase (QA, test group, admin). Warning: do not use
staging profiles in production environment.
Testing
QA team or admin, either manually or also using a crawler browse through the entire Web application (make sure all
dark corners are accessed as well) - to generate logs for later fine tuning.
Fine tuning through Refining the security policy from the Security events, using
"Refine!" button
Message Size and RFC properties are part of the Auto Policy Generation. Nevertheless review the events for details and
refine:
Message size and parsing properties events should be reviewed first
Violations of HTTP RFC should be fixed in application or can be set to be ignored by AppWall either for specific URL or
for (Any URL)
Review all Security events in the Forensics view.
Parameters Security Bypass list can be updated to bypass cookies that do not require protection. Add the Alteon /
AppDirector persistency cookie to the list of bypassed parameters
At this point all traffic should be legitimate and should not be blocked. Refine the events that generate false positives.
At this point 404 status code can be identified as well (broken links)
consider using Discard all rules or Apply to all other pages
PHASE 4.3.2
In case the application processes XML client input and / or web services import
WSDL file and activate WebServices or XMLSecurity where needed.
Create Application Paths (if required) with Extended Auto Policy Generation
Mode. Activate relevant Security filters in these Application Paths based on the
next
inputs:
Double
check that SafeReply filter activated where required, by Auto Policy
Generation. If not create Application Paths and activate Safe Reply Filter on
relevant sections
Payment section and shopping cart web app pages must be secured by SafeReply
Any page that might leak sensitive info
Indentify what is considered as sensitive information, in the organization. Define Some organization regard different data as sensitive. If possible use custom pattern in Safe Replay to mitigate
custom sensitive patterns for Safe Reply
sensitive data leakage.
integration with external DLP solution available through ICAP protocol
Is there any /admin/ application path (for configuration of the web site, creating Add Path Blocking filter to all Application paths, and add sensitive folders to Path Blocking filter on all application
web users, etc). if so, consider using path blocking for that path.
Paths.
If limited access is needed, define web role(s) based on source IP address or based on Successful Login Detection. You
can then allow access to these path only relevant role.
Is there any file upload folder? if so, use "File Upload"
If exists create Application Path for Upload application and define File Upload filter on it with specific allowed file types
If limited access is needed, define web
role(s) based on source IP address or based on Successful Login Detection. You can then allow access to these path only
relevant role.
Are there any streaming files (swf, avi, mpeg, radio). if so use "bypass
extensions"
if exists - define to bypass in tunnel level "Security Bypass" tab. Also allows ignoring problematic applications cookies
(ASP, Google, etc.)
Create Application Path for Login page and Authenticated pages, and enable Brute Force Filter on them. For additional
information, refer to KB2952.
Securing cookies (the default is signing, but you can also encrypt) impacts performance
Preferably secure only the sensitive cookies identified rather than securing all
Session security filter events should be reviewed to define whether there are cookies that should not be processed as
the client side need to read or manipulate them.
When required configure the Authentication and User Tracking settings under
the host
Enables:
- Authentication
- single-sign-on to multiple application
- successful login detection to cross and sub domain application
- role-based policy for authenticated users and for guests
- role-based policy by mapping AppWall roles to LDAP groups
Logging filter - highly effects performance; use it only selectively and for
specific application paths for short periods of time.
PHASE 5
Advanced Tuning
Avoid from Product fingerprint
PHASE 6
CSRF protection is set to Passive by default. Review the logs change the mode to Active if required
In "Hosts" section under "Security Policy" tab you have the CSRF protection settings. Please manually REFINE by either allowing domain name (e.g.
*.domain.com) or specific file under the new "Hosts" section.
View Dashboard - view active connection per tunnel to learn normal behavior
(baseline).
update max active connections in tunnel configuration if needed (a good Active Connections :TPS ration should be ~
1:2-3)
You should also trace the ration between Active connections to the Transactions Rate (TPS) - High Active connections
to Transactions Rate ratio might indicate wrong settings of idle connections in the web server and in the AppWall tunnel
Vision Reporter
Configuring AppWall for events distribution
Security Reports
Application Intelligence
PCI Compliance
Correlating Reports
Alerts
PHASE 7
PHASE 9
under Configuration View > Services you can configure the Vision Reporter settings. For more details please refer to KB
2826
Configuring Multi-Tenancy
You may consider configuring user Authentication and Role based policy with
Active Directory, LDAP, and Radius.
a. Administrator
b. Web Application Owner
c. Web Application Viewer
PHASE 8
Change the K_V_D__ cookies prefixes \ "_event_transid" parameter name of security page\ make sure the security page
neither contain the expressions such as "Web Application Firewall" \ "AppWall" or similar
can be shown when logging in as Web Application owner and viewing the reports only of your owned applications
after all events are handled and refined, change tunnel mode to Active
when no event from internal testing generated and you ready to move to active
change Automatic Configuration profile to Production pro"Production Rapid" or "Production Automatic" Traffic analysis profiles !!!
PHASE 10
disable the "Suppress Events when Auto Configuration Learns" check box in the
Security Policies > Auto Policy Generation
You now have 2 possible approaches as to how to switch the system to Active
mode in production
select the active Implementation Strategy: one of the options 10.1 or 10.2
OR
PHASE 10.2: The Rapid Approach
Active Tunnel
Create custom views in Forensics Security Log to filter the security events by
Security Filters.
For each such filter review the events and make sure there are no false positives
consider disabling Automatic Policy Generation per filter\tunnel\device
depending on how frequently the web application is being updated and modified.
Create custom views in Forensics Security Log to filter the security events by
Refine\review Tunnel event
"tunnel" event
switch tunnel to active while all the filters are Passive
consider to disable Automatic Policy Generation per filter\tunnel\device
depending on how frequently the web application is being updated and modified.