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 Throughput widget on System > Status > Status. If there is no traffic, you have a problem. For details, see Connectivity issues.
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. Also revisit troubleshooting recommendations included with each feature’s instructions. For details, see Troubleshooting.
|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.|
You may need to refine the configuration. For details, see Expanding the initial configuration.
Once testing is complete, finish your basic setup with either Switching out of Offline Protection mode or Backups. Your FortiWeb appliance has many additional protection and maintenance features you can use. For details, see the other chapters in this guide.
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 websites’ 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. For details, see Specifying URLs allowed to initiate sessions.
- 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. For details, see Configuring HTTP protocol constraint exceptions.
- 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.
- 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. For details, see Enabling log types, packet payload retention, & resource shortage alerts and Viewing log messages.
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. For details, see Vulnerability scans.
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. For details, see Hardening security .
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 FortiWeb finds cookies, an icon is displayed on Policy > Server Policy > Server Policy for each affected server. If cookies are threats (for example, if they are used for state tracking or database input) consider adding a cookie security policy to the inline protection profiles for those servers. For details, see Protecting against cookie poisoning and other cookie-based attacks.
- Add any missing rules and policies to your protection profiles, such as:
- page access rules (see Enforcing page order that follows application logic)
- start page rules (see Specifying URLs allowed to initiate sessions)
- brute force login profiles (see Preventing brute force logins)
- rewriting policies (see Rewriting & redirecting)
- denial-of-service protection (see DoS prevention)
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.
- Examine the Attack Log widget under 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. For details, see Configuring logging.