Testing your installation
When the configuration is complete, test it by forming connections between legitimate clients and servers at various points within your network topology.
In offline protection mode and transparent inspection mode, if your web server applies SSL and you need to support Google Chrome browsers, you must disable Diffie-Hellman key exchanges on the web server. These sessions cannot be inspected.
Examine the HTTP Traffic Monitor section of the Policy Summary widget on System > Status >
Status. If there is no traffic, you have a problem. See
“Connectivity issues” on page 674
.
Figure 32:HTTP Traffic Monitor section of the Policy Summary widget
Fortinet
If a connection fails, you can use tools included in the firmware to determine whether the problem is local to the appliance or elsewhere on the network. See
“Troubleshooting” on page 663 . Also revisit troubleshooting recommendations included with each feature’s
instructions.
If you have another FortiWeb appliance, you can use its web vulnerability scanner to verify that
your policies are blocking attacks as you expect. For details, see “Vulnerability scans” on page 533 .
You may need to refine the configuration (see “Expanding the initial configuration”
).
Once testing is complete, finish your basic setup with either
“Switching out of offline protection mode” on page 214 or
“Backups” on page 215
. Your FortiWeb appliance has many additional
210 FortiWeb 5.2 Patch 2 Administration Guide
protection and maintenance features you can use. For details, see the other chapters in this
Administration Guide.
Reducing false positives
If the dashboard indicates that you are getting dozens or hundreds of nearly identical attacks, they may actually be legitimate requests that were mistakenly identified as attacks (i.e. false positives). Many of the signatures, rules, and policies that make up protection profiles are based, at least in part, on regular expressions. If your web sites’ inputs and other values are hard for you to predict, the regular expression may match some values incorrectly. If the matches are not exact, many of your initial alerts may not be real attacks or violations. They will be false positives.
Fix false positives that appear in your attack logs so that you can focus on genuine attacks.
Here are some tips:
• Examine your web protection profile (go to Policy > Web Protection Profile and view the settings in the applicable offline or inline protection profile). Does it include a signature set that seems to be causing alerts for valid URLs. If so, disable the signature to reduce false positives.
• If your web protection profile includes a signature set where the Extended Signature Set option is set to Full, reduce it to Basic to see if that reduces false positives. See
“Specifying
URLs allowed to initiate sessions” on page 438 .
• If your web protection profile includes HTTP protocol constraints that seem to be causing alerts for legitimate HTTP requests, create and use exceptions to reduce false positives. See
“Configuring HTTP protocol constraint exceptions” on page 471 .
• Most dialog boxes that accept regular expressions include the >> (test) icon. This opens the
Regular Expression Validator window, where you can fine-tune the expression to eliminate false positives.
Figure 33:Regular Expression Validator dialog
Fortinet
• If you use features on the DoS Protection menu to guard against denial-of-service attacks, you could have false positives if you set the thresholds too low. Every client that accesses a web application generates many sessions as part of the normal process. Try adjusting some thresholds higher.
• To learn more about the behavior of regular expressions that generate alerts, enable the
Retain Packet Payload options in the logging configuration. Packet payloads provide the actual data that triggered the alert, which may help you to fine tune your regular expressions
to reduce false positives. See “Enabling log types, packet payload retention, & resource shortage alerts” on page 575
and “Viewing log messages” on page 587 .
211 FortiWeb 5.2 Patch 2 Administration Guide
Fortinet
Testing for vulnerabilities & exposure
Even if you are not a merchant, hospital, or other agency that is required by law to demonstrate compliance with basic security diligence to a regulatory body, you still may want to verify your security.
• Denial of service attacks can tarnish your reputation and jeopardize service income.
• Hacked servers can behave erratically, decreasing uptime.
• Malicious traffic can decrease performance.
• Compromised web servers can be used as a stepping stone for attacks on sensitive database servers.
To verify your configuration, start by running a vulnerability scan. See
“Vulnerability scans” on page 533 . You may also want to schedule a penetration test on a lab environment. Based upon
results, you may decide to expand or harden your FortiWeb’s initial configuration (see
“Hardening security” on page 641
).
Expanding the initial configuration
After your FortiWeb appliance has operated for several days without significant problems, it is a good time to adjust profiles and policies to provide additional protection and to improve performance.
• Begin monitoring the third-party cookies FortiWeb observes in traffic to your web servers.
When cookies are found, an icon appears on Policy > Server Policy > Server Policy for each affected server. If cookies are threats, such as if they are used for state tracking or database input, consider enabling the
Cookie Poisoning Detection
option on the inline protection profiles for those servers.
• Add any missing rules and policies to your protection profiles, such as:
• page access rules (see
“Enforcing page order that follows application logic” on page 433
)
• start page rules (see
“Specifying URLs allowed to initiate sessions” on page 438 )
•
brute force login profiles (see “Preventing brute force logins” on page 375
)
• rewriting policies (see
“Rewriting & redirecting” on page 379 )
•
denial-of-service protection (see “DoS prevention” on page 356 )
Especially if you began in offline protection mode and later transitioned to another operation mode such as reverse proxy, new features may be available that were not supported in the previous operation mode.
• Examine the Attack Event History in the Policy Summary widget on System > Status >
Status. If you have zero attacks, but you have reasonable levels of traffic, it may mean the protection profile used by your server policy is incomplete and not detecting some attack attempts.
212 FortiWeb 5.2 Patch 2 Administration Guide
Figure 34:Attack Event History section of the Policy Summary widget
Fortinet
• Examine the Attack Log widget on System > Status > Status. If the list includes many identical entries, it likely indicates false positives. If there are many entries of a different nature, it likely indicates real attacks. If there are no attack log entries but the Attack Event
History shows attacks, it likely means you have not correctly configured logging. See
“Configuring logging” on page 575 .
Figure 35:Attack Log Widget
You can create reports to track trends that may deserve further attention. See
“Data analytics” on page 631 ,
“Vulnerability scans” on page 533
, and
“Reports” on page 618 .
213 FortiWeb 5.2 Patch 2 Administration Guide
