Fortinet 5.0 Patch 6 Blacklisting & whitelisting clients

Fortinet 329 FortiWeb 5.0 Patch 6 Administration Guide

your exact value or matches your regular expression (depending on whether you have

selected Simple String or Regular Expression). Value matching is case sensitive.

7. Click OK to exit the sub-dialog and return to the rule configuration.

8. Repeat the previous steps for each individual criteria that you want to add to the access rule.

You could, for example, require both a matching request URL, HTTP header, and client

source IP in order to allow a request.

9. Click OK to save the rule.

10.Go to Web Protection > Advanced Protection > Custom Policy.

11.Click Create New. Group the advanced access rules into a policy.

For example, to create a policy that allows rate-limited access by 3 client IPs, you would

group the corresponding 3 advanced access rules for each of those IPs into the policy.

In Priority, enter the priority for each rule in relation to other defined rules. Rules with lower

numbers (higher priority) are applied first.

12.To apply the advanced access policy, select it as the Custom Access in a protection profile

(see “Configuring a protection profile for inline topologies” on page 468 or “Configuring a

protection profile for an out-of-band topology or asynchronous mode of operation” on

page 477).

Attack log messages contain Custom Access Violation when this feature detects an

unauthorized access attempt.

Blacklisting & whitelisting clients

You can block requests from clients based upon their source IP address directly, their current

reputation known to FortiGuard, or which country or region the IP address is associated with.

Conversely, you can also exempt clients from scans

typically included by the policy.

Manually identifying and blocking all known attackers

in the world would be an impossible task. To block:

• botnets

•spammers

•phishers

• malicious spiders/crawlers

• virus-infected clients

• clients using anonymizing proxies

• DDoS participants

To prevent accidental matches, specify as much of the header’s value as possible. Do not

use an ambiguous substring.

For example, entering the value 192.168.1.1 would also match the IPs 192.168.10-19 and

192.168.100-199. This result is probably unintended. The better solution would be to

configure either:

• a regular expression such as ^192.168.1.1$ or

• a source IP condition instead of an HTTP header condition