Fortinet 655 FortiWeb 5.0 Patch 6 Administration Guide
In the FortiWeb appliance's web UI, you can view traffic load two ways:
• Monitor current HTTP traffic on the dashboard. Go to System > Status > Status and examine
the graphs in the Policy Summary widget.
• Examine traffic history in the traffic log. Go to Logs&Report > Log Access > Traffic.

Preparing for attacks

A prolonged denial of service (DoS) or brute-force login attack (to name just a few) can bring
your web servers to a standstill, if your FortiWeb appliance is not configured for it.
To fight DoS attacks, see “DoS prevention” on page 338.
In the FortiWeb appliance's web UI, you can watch for attacks in two ways:
• Monitor current HTTP traffic on the dashboard. Go to System > Status > Status and examine
the attack event history graph in the Policy Summary widget.
• Examine attack history in the traffic log. Go to Logs&Report > Log Access > Attack.
Before attacks occur, use the FortiWeb appliance's rich feature set to configure attack
defenses.
Login issues
If the person cannot access the login page at all, it is usually actually a connectivity issue (see
“Ping & traceroute” on page 630 and “Configuring the network settings” on page 111) unless all
accounts are configured to accept logins only from specific IP addresses (see “Trusted Host #1”
on page 215).
If an administrator can connect, but cannot log in, even though providing the correct account
name and password, and is receiving this error message:
Too many bad login attemptsor reached max number of logins. Please try
again in a few minutes. Login aborted.
single administrator mode may have been enabled. See “Enable Single Admin User login” on
page 54.
If the person has lost or forgotten his or her password, the admin account can reset other
accounts’ passwords (see “Changing an administrator’s password” on page 219).

Checking user authentication policies

In FortiWeb, users and organized into groups. Groups are part of authentication policies. If
several users have authentication problems, it is possible someone changed authentication
policy or user group memberships. If a user is legitimately having an authentication policy, you
need to find out where the problem lies.
To troubleshoot user access
1. In the web UI, go to User > User Group > User Group and examine each group to locate the
name of the problem user.
2. Note the user group to which the affected users belong, especially if multiple affected users
are part of one group. If the user is not a group member, there is no access.
3. Go to Application Delivery > Authentication Policy > Authentication Rule and determine
which rule contains the problem user group. If the user group is not part of a rule, there is no
access.