FortiWeb 6.0 Study Guide-Online

DO NOT REPRINT
© FORTINET
FortiWeb Study Guide

for FortiWeb 6.0
DO NOT REPRINT
© FORTINET
Fortinet Training
http://www.fortinet.com/training
Fortinet Document Library
http://docs.fortinet.com
Fortinet Knowledge Base
http://kb.fortinet.com
Fortinet Forums
https://forum.fortinet.com
Fortinet Support
https://support.fortinet.com
FortiGuard Labs
http://www.fortiguard.com
Fortinet Network Security Expert Program (NSE)

https://www.fortinet.com/support-and-training/training/network-security-expert-program.html
Feedback
Email: courseware@fortinet.com
4/4/2019
DO NOT REPRINT
© FORTINET
TABLE OF CONTENTS
01 Introduction 4
02 Basic Setup 45
03 Integrating Front-End SNAT and Load Balancers 119
04 DoS and Defacement 146
05 Signatures, Sanitization, and Auto Learning 187
06 SSL and TLS 249
07 Authentication and Access Control 302
08 PCI DSS Compliance 344
09 Caching and Compression 388
10 HTTP Routing, Rewriting, and Redirects 411
11 Troubleshooting 445
 Introduction
DO NOT REPRINT
© FORTINET
In this lesson, you will learn the basics of FortiWeb. This includes how FortiWeb fits into your existing
network architecture.
While products such as FortiGate protect your client systems from threats, FortiWeb is specifically
designed to protect your web servers from threats.
FortiWeb 6.0 Study Guide 4

 Introduction
DO NOT REPRINT
© FORTINET
In this lesson, you will learn about the topics shown on this slide.

 Introduction
DO NOT REPRINT
© FORTINET
After completing this section, you should be able to achieve the objectives shown on this slide.
By demonstrating competence in understanding the value of FortiWeb, you will be able to effectively
apply FortiWeb in your network to protect web resources.

 Introduction
DO NOT REPRINT
© FORTINET
What is a WAF? Why would you need a WAF? Don’t FortiGate and FortiClient scan HTTP?
It’s true. Both FortiGate and FortiClient do scan HTTP, but who and what do they scan for? FortiGate’s
HTTP proxy and FortiClient are focused on protecting clients, not servers. For example, FortiGuard web
filtering URL ratings block requests based on the category of the server’s web pages. Antivirus protection
prevents clients from accidentally downloading spyware and worms. Neither feature protects servers
from threats such as malicious scripts or ransomware.
Protecting servers requires a different approach than protecting clients because servers are subject to
different types of attacks. Protecting web servers that handle popular web sites, and enterprise web
applications like IBM Lotus Notes or Microsoft SharePoint, also requires high performance. Also, unlike
web browsers, there is a database behind most modern web servers, which also requires protection.

 Introduction
DO NOT REPRINT
© FORTINET
Databases are jackpots for black hat hackers. Once your database has been compromised–stolen or
injected with code–it can be used for extortion, political manipulation, industrial espionage, seeding
clients as zombies for DDoS attacks on other servers, sending spam, fraudulent purchases, storing
criminal files, and more! The variations of threats seem endless.
So, if you need high-grade security for your web server, you also need it for the real target: the database
behind your server. Consider adding a FortiDB. FortiWeb can only scan web traffic. So, like FortiDB,
FortiWeb should be placed behind a firewall, such as FortiGate.

 Introduction
DO NOT REPRINT
© FORTINET
A layered security approach provides a better defense and better speed.
Security doesn’t need to be your bottleneck. With your FortiGate in front, you have the option of
distributing some scans–such as SSL offloading and lower-layer inspection–to whichever device has less
system load. Distributing scans optimizes performance. Just like FortiGate, FortiWeb has ASIC chips that
can accelerate encryption and decryption.

 Introduction
DO NOT REPRINT
© FORTINET
The FortiWeb product family comprises multiple models, designed to suit specific needs. The FortiWeb
models range from those suited to (SMB) applications all the way up to models suited to an enterprise
data center. The FortiWeb product family includes both dedicated hardware and VM appliances.

 Introduction
DO NOT REPRINT
© FORTINET

 Introduction
DO NOT REPRINT
© FORTINET
Good job! You now understand FortiWeb’s key features.
Now, you will learn about attack types and the ways that you can deploy FortiWeb to protect against
these threats.

 Introduction
DO NOT REPRINT
© FORTINET
By demonstrating competence in attack types and deployment options, you will be able to make more
informed decisions on how best to implement FortiWeb in your network.

 Introduction
DO NOT REPRINT
© FORTINET
FortiWeb can be deployed in a one-arm topology, but is more commonly positioned inline, to intercept all
incoming clients’ connections and redistribute them to your servers. FortiWeb has TCP-specific and
HTTP-specific firewalling capabilities. Because FortiWeb is not designed to provide security to non-HTTP
applications, it should be deployed behind a firewall, such as FortiGate, that focuses on security for other
protocols that may be forwarded to your backend servers, such as FTP and SSH. After you deploy the
FortiWeb device, you can configure it from a web browser and terminal on your management computer,
using its web GUI and CLI.

 Introduction
DO NOT REPRINT
© FORTINET
The order in which FortiWeb appliances apply protection rules and perform protection profile scans varies
according to whether or not you have applied a web protection profile.
Policies consolidate protection components; therefore, you should configure policies after you have
configured protection components.

 Introduction
DO NOT REPRINT
© FORTINET
FortiWeb solutions vary by the type of attack that they are meant to combat. A few FortiWeb solution and
attack combinations are summarized on this slide. Many of the FortiWeb solutions combat the (OWASP)
top 10 attacks.
You may remember seeing frequent Adobe Flash updates made to combat security issues. Less well-
publicized was Google’s temporary switch to using RC4 for its HTTPS services. This switch was made to
protect its servers from the BEAST attack in 2011. Since then, RC4 vulnerabilities have also been
discovered. CRIME attacks and BREACH attacks are based on related principles, and the same
researchers that published BEAST also published the compression-based Lucky 13 attack, so it’s
important to remember that simply using HTTPS is not guaranteed to be secure.

 Introduction
DO NOT REPRINT
© FORTINET
Cookies can be used to store attacks that are initiated by a different client. After a cookie is present on
the client, even if it is originally harmless, a malicious client can tamper with it easily. Many tools are
readily available to perform this type of attack–there are even browser plugins, as we show in our labs.
The next time you send a request to the server, these poisoned cookies become a dangerous input for an
HTTP parser to accept. Cookie poisoning detection is the FortiWeb feature that is used to combat this
type of attack.

 Introduction
DO NOT REPRINT
© FORTINET
Credit card theft is a major security issue. It doesn’t always originate with an attack. Poorly coded web
applications may return credit card data as hidden inputs, not realizing that anyone can view the HTML
source code of a web page–or alter it. FortiWeb can protect you from accidental disclosure. You will learn
about compliance issues in a separate lesson.

 Introduction
DO NOT REPRINT
© FORTINET
Uploading an executable isn’t even necessary for some attacks. If your web server doesn’t reject input
that contains commands to access the file system, your web server can be abused. This can be
especially bad if your web server is running as root or administrator. Imagine an unknown person with
super user access to your password or route –p add commands.
A DoS attack is a malicious attempt to bring down networks, web-based applications, or services by
overwhelming these resources with too much data or impairing them in some other way. According to
Verisign 2018 Q1 there has been a 53% increase in the number of DoS attacks over Q4 2017. A
dedicated hardware appliance like FortiDDoS is used to protect critical services from volumetric DoS
attacks.

 Introduction
DO NOT REPRINT
© FORTINET
Heartbleed was an SSL/TLS attack that was responsible for a Canada Revenue Agency website
shutdown, tax deadline extensions, and a full network security audit for Social Insurance Number
compromises in April 2014. FortiWeb SSL offloading is not vulnerable to this type of attack and,
therefore, could have prevented it.

 Introduction
DO NOT REPRINT
© FORTINET
Some of the default installations of IIS and Apache are notorious for publishing their installation version
information in the default 404 pages and HTTP headers, making it easy for attackers to find unpatched
servers. FortiWeb can erase these server information disclosures quickly, giving your system
administrators time to correct these misconfigurations.

 Introduction
DO NOT REPRINT
© FORTINET
The attack types that you examined in the previous slides were only some of the most common types of
attacks; there are many more that this lesson does not cover. Attacks can use many strategies in HTTP,
and attacks won’t always show in normal web server logs. How can you tell when you’re being attacked?
How can you block an attack?

 Introduction
DO NOT REPRINT
© FORTINET
How does FortiWeb stop some of the common attack types that you have learned about in this lesson?
In most deployments, you want to guarantee that zero bytes of an attack can reach your web servers.
This is especially important in the case of DoS attacks, because DoS attacks can start at the IP layer,
before a TCP connection is even fully formed.
To have access to the most features, including non-security features such as redirects and rewrites,
configure FortiWeb to operate in reverse proxy mode. If you can’t modify your IP address scheme, true
transparent proxy operating mode is a good option. When FortiWeb is used in an inline topology, and is
operating in either of these modes, it always blocks or sanitizes HTTP requests and can, therefore, block
an attack before it reaches your web servers.

 Introduction
DO NOT REPRINT
© FORTINET
Now you will learn about how attacks are blocked when FortiWeb is operating in reverse proxy mode.
Since FortiWeb is acting as a proxy for your servers, it is a termination point at the IP layer. It never
forwards the traffic to your protected servers if it detects an attack, so the connection is never formed.
Depending on the OSI layer of the client’s attack, FortiWeb replies with either a TCP reset or an HTTP
error code, whichever is appropriate.

 Introduction
DO NOT REPRINT
© FORTINET
If high performance and zero latency is more critical than absolute security, when streaming media, for
example, you can choose a different operating mode, such as offline mode, or transparent inspection
mode.

 Introduction
DO NOT REPRINT
© FORTINET
Let’s look at how FortiWeb interrupts attacks in offline mode. In offline mode, FortiWeb is located on an
arm, where it’s linked to a switch’s mirror port. So, FortiGate forwards a copy of the traffic to both the web
servers and FortiWeb. FortiWeb races to scan for attacks before the transmission and server-side
processing is complete. If FortiWeb detects an attack, it sends a TCP reset signal–the only thing it can do
in this mode–to try to force the server to discard the incomplete connection data.
When FortiWeb is operating in transparent inspection mode, it interrupts attacks in a similar manner. In
transparent inspection mode, FortiWeb is placed between servers and the client, instead of on an arm.
However, FortiWeb must still must race against the clock when it scans for attacks. It’s crucial that you
understand this: if the TCP reset packet loses the race, your incident response team must be ready
immediately. Just because FortiWeb attempts to interrupt an attack, does not mean that it will always
succeed. You should keep tripwires and other forensic tools ready.
In contrast, when FortiWeb is operating in reverse proxy mode, blocking is reliable.

 Introduction
DO NOT REPRINT
© FORTINET
The blocking method and attack protection used varies by operation mode, but so does traffic forwarding
and SSL offloading or inspection. This table provides a summary; but if you need a specific feature, check
the documentation to make sure that the required feature is supported.

 Introduction
DO NOT REPRINT
© FORTINET
Because blocking is not guaranteed to succeed in offline mode, this mode is best used during the
evaluation and planning phase, early in implementation.
Reverse proxy is the most popular operating mode. It can rewrite URLs, offload TLS, load balance, and
apply NAT.
For very large MSSP, true transparent mode has a significant advantage. You can drop it in without
changing any schemes of limited IPv4 space–in transparent mode, you don’t need to give IP addresses
to the network interfaces on FortiWeb.

 Introduction
DO NOT REPRINT
© FORTINET
HTTP 1.1 is stateless; that is, it has no inherent support for persistent sessions. However, many web
applications add sessions to become stateful.
Why? What is a session? What is statefulness? What effect do statefulness and sessions have on web
security?
Sessions occur when a set of correlated requests for individual web pages or data (hits) form the
impression of an overall client visit for a particular time span. Some memory of these requests is retained
between visits. Sessions typically consist of a session ID and data indicating current state. Classic
examples of a session include logins, shopping carts, and lists of previously viewed items.
When sessions are not protected to prevent misuse, software can be used in unexpected ways by
attackers. However, sessions alone are not enough to ensure that a client’s requested operations make
sense. The client’s next page request in the session could break the web application’s logic, unless
requests are restricted to valid ones.
If valid state transitions are not enforced, and session IDs and cookies aren’t guarded from fraud
(including sidejacking attacks made famous by Firesheep) or cookie poisoning, web applications become
vulnerable to state transition-based attacks—attacks where pages are requested out of the expected
order, by a different client, or inputs used for the next page are not as expected.

 Introduction
DO NOT REPRINT
© FORTINET
Many variations of HTTP attacks exist, but these are the principles behind most of them:
• Order of page requests in a web app’s session must make sense, if a page has prerequisites–but
HTTP has no built-in session logic
• Protocol (and application) design must degrade gracefully and successfully contain themselves within
finite resources
Don’t assume that increasing your web server’s maximum number of allowed simultaneous connections,
or enabling threading, will solve the problem. Slowloris attacks, for example, actually have more severe
effects on servers where threading is enabled, because they must then also attempt to limit the number of
threads.
Similarly, if your database server doesn’t allow enough connections, increasing them on your web server
will only change the type of error message.

 Introduction
DO NOT REPRINT
© FORTINET
FortiWeb can add its own sessions to enforce the logic of your web applications. This hardens the
security of your web applications, even without applying patches. For example, to reinforce authentication
logic, you might want to require that a client’s first HTTP request always be a login page. All other web
pages should be inaccessible until a client has authenticated, because out-of-order requests could be an
attempt to bypass the web application’s authentication mechanism.
How does FortiWeb know if a request is the client’s first HTTP request? If FortiWeb treats each request
independently, without knowledge of any previous requests, it will not be able to remember the
authentication request, and, therefore, cannot enforce page order. To fill this need for context, enable
session management on FortiWeb. When enabled session management is enabled, the following occurs:
• At the first HTTP/ HTTPS request from a client, FortiWeb embeds a cookie in the response’s Set-
Cookie field in the HTTP header named cookiesession1. (FortiWeb does not use source IP
addresses and timestamps alone for sessions. NAT can cloak multiple clients; clocks can be altered.)
• Later requests from the same client must include the embedded cookie in the Cookie field to be seen
as part of the same session. Once a request’s session is identified by the session ID in the cookie,
FortiWeb can perform any configured tracking or enforcement actions based on the requests
remembered for that session ID. Violating traffic may be dropped or blocked, depending on your
configuration
• After some time, if FortiWeb has not received any more requests, the session will time out. The next
request from that client, even if it contains the former session cookie, will restart the process at step 1

 Introduction
DO NOT REPRINT
© FORTINET

 Introduction
DO NOT REPRINT
© FORTINET
Good Job! You now understand the threat landscape and how to best deploy FortiWeb to protect your
web servers.
Now, you will learn about the available FortiWeb management interfaces.

 Introduction
DO NOT REPRINT
© FORTINET
After completing this section, you will be able to achieve the objective shown on this slide.
By demonstrating competence in understanding FortiWeb access methods, you will be able to access
and configure the FortiWeb features that you want to use in protecting your network.

 Introduction
DO NOT REPRINT
© FORTINET
If you’re familiar with how to access FortiGate, you’ll also be familiar with how to access FortiWeb.
First, you’ll need to use either a console connection or a peer network connection to configure FortiWeb
with an IP address and gateway. After that, you’ll be able to attach it to your network, and access the GUI
and CLI through the network. The operation mode can be set using either the dashboard or the CLI.
Tip: If you’ll be using one of the transparent modes, don’t configure FortiWeb network settings right away.
Changing the operation mode from reverse-proxy mode to a transparent mode, or the opposite, resets
FortiWeb’s network settings, and only port1 can be the management port. What does this mean? If you’re
connected through the network, you might lose GUI or CLI connectivity. So, during setup for transparent
mode, don’t place FortiWeb in your network immediately. Use a local console or peer network connection
to the GUI or CLI after you’ve switched the operation mode.

 Introduction
DO NOT REPRINT
© FORTINET
FortiWeb Manager centralizes the configuration of FortiWeb appliances. Its web GUI replaces the local
interfaces on FortiWeb devicesin your network, allowing you to create, deploy, and update configurations
remotely. Instead of creating a local configuration on a remote FortiWeb, FortiWeb Manager allows you to
create a configuration that you can install on one or more FortiWebs. To make changes to a
configuration, edit the FortiWeb Manager package (or create a new one), and deploy the updated
package to the remote device. The configuration you install using FortiWeb Manager replaces any default
or existing configuration on the remote device. However, you can revert to the previous configuration
using the installation logs.
In FortiWeb Manager, FortiWeb configuration is organized in two parts:
• Provisioning templates: System objects including DNS, SNMP, and security settings. In most cases,
you set these settings during an initial deployment, and do not update them often.
• Policy packages: Contain one or more policies you create using configuration objects such as virtual
servers, server pools, and web protection policies. You create these configuration objects separately,
and add them to the policies found in packages, as needed.
To update configurations you installed using policy packages, edit the configuration objects and policies
as needed, and then install the updated package.

 Introduction
DO NOT REPRINT
© FORTINET
You perform tasks that configure remote FortiWeb devices using the following two tabs: Device Manager
and Policy & Objects.
The Device Manager tab allows you to perform the following provisioning tasks:
• Create a list of FortiWeb appliances available for configuration. To help you organize your
devices, you can add a device to a group.
• Change an individual configuration setting on an appliance
• Create and assign reusable system templates that contain values for the settings that are most
commonly used when you provision an appliance, including DNS, SNMP, and security settings
• Upload firmware and data analytics definitions files and use the uploaded files to upgrade the
FortiWeb appliances in a group
The Policy & Objects tab allows you to perform the following policy creation and installation tasks:
• You create
• Configuration objects such as virtual servers, server pools, and web protection profiles
• Create or update policy packages. You create the package policies using the pre-built
configuration objects
• Install the policy packages on one or more FortiWeb appliances
The FortiWeb Manager web GUI also has a System Settings tab that allows you to monitor FortiWeb
Manager and to perform tasks, such as user management and high availability configuration.

 Introduction
DO NOT REPRINT
© FORTINET

 Introduction
DO NOT REPRINT
© FORTINET
Good job! You now know the various management interface options available for managing your
FortiWeb devices.
Now, you will learn about the available support resources.

 Introduction
DO NOT REPRINT
© FORTINET
In this section you will be able to achieve the objective shown on this slide.
By demonstrating competence in finding and using the available support resources, you will be able to
manage and maintain your FortiWeb services and device.

 Introduction
DO NOT REPRINT
© FORTINET
When you log in, many options appear. FortiWeb is full-featured and continues to evolve to meet the
challenges presented by the HTTP threat landscape. This slide shows the main sources of information
that can help you with your implementation.

 Introduction
DO NOT REPRINT
© FORTINET
As in other Fortinet products, clicking the help button in FortiWeb will go to the appropriate page in the
documentation. The help information gives how-to examples, feature overviews, and detailed references
of specific options.

 Introduction
DO NOT REPRINT
© FORTINET
Congratulations! You have completed this lesson.
Now, you will review the objectives that you covered in this lesson.

 Introduction
DO NOT REPRINT
© FORTINET
This slide shows the objectives that you covered in this lesson.
By mastering the objectives covered in this lesson, you learned how to use FortiWeb features to protect
your network from security threats.

 Basic Setup
DO NOT REPRINT
© FORTINET
In this lesson, you’ll learn how to physically deploy your FortiWeb and complete basic settings so that you can
begin to integrate FortiWeb into your network.

 Basic Setup
DO NOT REPRINT
© FORTINET

 Basic Setup
DO NOT REPRINT
© FORTINET
After completing this section, you should be able to achieve the objective shown on this slide.
By demonstrating competence in defining and discussing topologies and implementation scenarios, you will
be better able to understand how you can integrate FortiWeb into your network.

 Basic Setup
DO NOT REPRINT
© FORTINET
If you’re using FortiWeb VM in a cloud, much of the physical topology may be either hidden from you, or out of
your control. Instead, your main concern is the virtualized hardware. In the cloud, there is an important
difference between a logical topology and a typical hardware model deployment: your FortiWeb’s interface to
the Internet may be DHCP, not a static IP.

 Basic Setup
DO NOT REPRINT
© FORTINET
Regardless of whether you deploy real or virtual hardware, you need to know if source NAT (SNAT) is being
used. If you have a FortiGate operating in transparent mode and placed in front of your network, you can skip
this.
But if you are using NAT/route mode, or a load balancer such as FortiADC or Citrix NetScaler, you should
check its configuration. By default, FortiWeb blocks many attacks based upon a client’s source IP address.
So, if FortiGate hides the real source address from FortiWeb, FortiWeb may not behave as you intend.
Here, an upstream load balancer is applying SNAT, but FortiWeb hasn’t been configured to handle this. As a
result of the misconfiguration, whenever an attack occurs, FortiWeb blocks sessions from FortiADC, breaking
all connectivity.

 Basic Setup
DO NOT REPRINT
© FORTINET
There are two solutions you can use if you have upstream SNAT. This slide shows one solution:
Configure the upstream NAT device to put the original client’s IP address in an HTTP header such as X-
Forwarded-For. The name format can vary. Some CDNs, like Akamai use X-True-IP or X-Real-IP. If you’re
not sure what name format to use, run a packet capture or use browser developer tools to observe the HTTP
transactions.
Configure FortiWeb to find the IP in the HTTP header, not the IP header.
This solution works in many cases, including when FortiGate is used. But, not all NAT devices support the use
of this solution. Also, FortiWeb 5.3.4 ignores private IP addresses in X-headers, so this solution won’t work if
you’re an enterprise with users on your private network. What other solutions can you use?

 Basic Setup
DO NOT REPRINT
© FORTINET
The easier of the two solutions is to place FortiWeb in front of the load balancer. Some other positive side
effects of this topology are that the load balancer only receives legitimate traffic, so it’s protected, and the load
balancer resources are used efficiently.
Remember, though, that load balancers sometimes use the source IP address for session persistence or
client-based load balancing. If this is the case, configure FortiWeb to transmit the original client’s IP address in
X-Forwarded-For in the HTTP header, and configure your load balancer to use that address instead of the
source address in the IP header.

 Basic Setup
DO NOT REPRINT
© FORTINET
This diagram shows a network topology that you might see in an enterprise-sized business. It’s slightly
simplified, but probably it would involve an authentication server, full mesh topology, a management LAN on
FortiWeb’s port1, and, possibly, HA for redundancy. Because the FortiGate in this topology is operating in
NAT/route mode, and applying SNAT, the administrator has enabled load balancing and configured two virtual
servers. FortiGate applies X-headers: one for road warriors connecting from the Internet, and another for
employees on the headquarters office LAN.
Can you find the misconfiguration?
That’s right: it’s the FortiGate virtual server for the office LAN. Because FortiGate would be using private
network IP addresses, many LANs could have clients using those same private IP addresses; that is, the
addresses are not globally unique. So, a FortiWeb wouldn’t use the X-header for those private IP addresses.

 Basic Setup
DO NOT REPRINT
© FORTINET

 Basic Setup
DO NOT REPRINT
© FORTINET
You now have an understanding of the various network topologies possible with FortiWeb.
Now, you will learn about the nesting of configuration components and initial configuration, which is the logic
of configuring FortiWeb

 Basic Setup
DO NOT REPRINT
© FORTINET
By demonstrating competence in understanding which configuration objects are used by other configuration
objects and how objects link together, you will be able to start to configure FortiWeb.

 Basic Setup
DO NOT REPRINT
© FORTINET
You’ll usually start by configuring a leaf node object–use a fine-grained setting, not the server policy. Server
policies group objects together and apply settings to matching traffic. But, to use server policies, you must
configure the objects first.
In reverse proxy mode, start by configuring fine-grained objects, such as:

• A virtual server
• A certificate for HTTPS
• Persistence settings that will be used by the server pool
• Custom signatures
• TCP flood rate limits
• Authentication rules
• Rewrite rules
• Input rules
Then, select these objects in DoS policies, server pools, and other intermediate objects, before binding them
all together in a server policy.

 Basic Setup
DO NOT REPRINT
© FORTINET
Transparent inspection mode or true transparent proxy mode is similar to reverse proxy mode. The significant
exception is the virtual server. Virtual servers don’t exist in these operation modes, because they don’t
forward traffic at the IP layer. Instead, virtual servers use an OSI Layer 2 bridge, together with the IP-layer
port number. This is called a V-zone.
Also, due to differences in how the two modes work, some features that are supported in reverse proxy mode
aren’t supported in transparent mode. For example, when operating in transparent mode, FortiWeb forwards
traffic while inspection is being completed. Therefore, it can’t rewrite URLs in packets that have already
egressed; it can only interrupt connections once it detects that an attack is in progress.

 Basic Setup
DO NOT REPRINT
© FORTINET
In offline protection mode, most features are not supported. You would use offline protection mode primarily in
the preparation phase, with auto learning to discover applicable signatures and input constraints. When
operating in offline protection mode, FortiWeb doesn’t pick up traffic on the proxy or bridge. It accepts all
traffic on a data capture port, one of the network interfaces, and listens for attacks.

 Basic Setup
DO NOT REPRINT
© FORTINET
This slide shows simple setup steps. In reverse proxy, once you have completed these steps, traffic will flow
through FortiWeb and you will be ready to begin applying security.

 Basic Setup
DO NOT REPRINT
© FORTINET
First, you will learn about administrative domains (ADOMs). ADOMs can be useful to divide workloads among
administrators. Everything from certificates to policies can be separated by ADOMs; therefore, they can be
used for multi-tenant deployments. However, ADOMs do not have virtualized networking and, although they
may look and act mostly like FortiGate VDOMs, they are not true VDOMs.
ADOMs on FortiWeb subdivide the configuration. You can allocate separate access by web applications,
customers, or other logical divisions.

 Basic Setup
DO NOT REPRINT
© FORTINET
Enabling ADOMs is simple. You can do it from the dashboard in the System Information widget.

 Basic Setup
DO NOT REPRINT
© FORTINET
In most cases, you’ll start by creating one administrator account for each ADOM. The administrator will be
chiefly responsible for that ADOM, including that ADOM’s configuration backups. In larger organizations, you
may need to make more ADOM administrators. Multiple administrators can be assigned to each ADOM. You
can subdivide their permissions using access profiles, in order to follow best practices for the segregation of
duties. You can’t assign an administrator to more than one ADOM.

 Basic Setup
DO NOT REPRINT
© FORTINET
If you want to grant access to all ADOMs and global settings, select prof_admin as the access profile when
configuring the administrator account. Like the account named admin, an account that is assigned the
prof_admin profile will be able to configure all ADOMs and global settings.
Best practice dictates that you should avoid unnecessary security holes, so, if possible, try not to assign
prof_admin access. Instead, restrict the access of each administrator to their relevant domain. That way,
they can’t accidentally or maliciously impact other ADOMs, and any damage they cause or mistakes they
make will be limited in scope.

 Basic Setup
DO NOT REPRINT
© FORTINET
If administrators or users are centrally authenticated through an active directory or a RADIUS server, you
must define the queries first. If administrators or users are connecting through LDAPs or STARTTLs, make
sure to upload your LDAP server’s CA certificate to the list of trusted CAs; otherwise, FortiWeb won’t be able
to authenticate the server connection, and queries will fail!

 Basic Setup
DO NOT REPRINT
© FORTINET
Group queries so that you can use them when creating new accounts.

 Basic Setup
DO NOT REPRINT
© FORTINET
Define administrators’ scopes and permissions. This best practice, combined with access profiles and ADOMs
to define separate roles and scopes; strong passwords; and defining your trusted management hosts, helps to
keep your FortiWeb secure.
Administrator accounts are not all the same, even if you have assigned the same access profile permissions.
What’s the difference? The admin account is similar to root. Only the admin account can reset forgotten
passwords, for example. If you forget the password to the admin account, you’ll have to use the recovery
procedure with the maintainer account, which is only available if you have local console access, and even that
can be disabled.

 Basic Setup
DO NOT REPRINT
© FORTINET
Don’t allow multiple users to log in as admin. Make sure that administrator accounts are separate. Also,
specify the access profile and, if applicable, the query to your authentication server.
For security reasons, your routers shouldn’t allow login attempts from the Internet to FortiWeb. Scripts from
attackers are constantly scanning IPs on the Internet for open ports, especially for brute forcing. So, it’s a
good idea to provide insurance, in case your router is misconfigured. To do this, define all allowed IPv4
management IPs for every administrator account. FortiWeb’s GUI and CLI will respond to only trusted IPs. If
only one host or subnet is allowed, just paste it into all three fields.
If you leave any IPv4 Trusted Host field set to 0.0.0.0/0.0.0.0, FortiWeb will allow login attempts from
any address: anyone who wants to brute force your network security and take advantage of this!
IPv6 is different. FortiWeb will respond only if you define a trusted host or subnet, so you can leave those
fields empty.

 Basic Setup
DO NOT REPRINT
© FORTINET
When should you prohibit simultaneous administrator logins?
FortiWeb doesn’t lock the configuration when you view an object’s settings. So, if multiple administrators edit
that same object, the changes made last overwrite any configuration changes made previously. If you don’t
want to use access profiles to prevent this, you can configure FortiWeb to allow only one administrative
session at a time. Alternatively, you can enable ADOMs so that each administrator’s policies and other
settings can’t be seen or affected by others.

 Basic Setup
DO NOT REPRINT
© FORTINET
Reverse proxy operating mode, the most popular mode, is the default. If you are going to use an operating
mode other than the default, such as starting in offline mode for auto-learning, you would switch from the
default mode at this point.

 Basic Setup
DO NOT REPRINT
© FORTINET
If you switch to transparent mode through the CLI, don’t forget to set the gateway IP. FortiWeb will keep the
port1 management IP, but,since the routes are lost, you must specify the gateway when you switch operating
modes.

 Basic Setup
DO NOT REPRINT
© FORTINET
If you are going to use FortiWeb HA, you would configure it at this point. To configure HA, you must have
identical FortiWeb models with the same firmware. You can configure FortiWeb in Active-passive and active-
active HA. If FortiWeb is not operating in reverse proxy mode, HA usually implemented externally using a
FortiADC load balancer An example of this will follow.
You can configure a dedicated management interface to access each individual device. You may require
direct access to a member in order to view the log messages related to the standby device, or to configure
settings on the standby device, which settings do not synchronize. Those settings include configuring the host
name and HA priority. Once HA is formed, you can continue to configure settings on the master or active
device; the standby FortiWeb will automatically sync with the active FortiWeb. If you need to copy the
configuration to multiple FortiWebs, but don’t want failover, use configuration synchronization instead of HA.

 Basic Setup
DO NOT REPRINT
© FORTINET
HA on FortiWeb behaves similarly to HA on other Fortinet devices. If the heartbeat fails or a monitored port
does not respond, then the standby FortiWeb uses GARP to advertise to the network that the FortiWeb virtual
MAC address and, by extension, its IP addresses, can now be reached through the standby’s links.
This causes switches to start forwarding frames through the standby’s connected ports, as if the failed
FortiWeb had been unplugged and moved to different ports on the switch. The failover is almost
instantaneous.

 Basic Setup
DO NOT REPRINT
© FORTINET
A FortiWeb active-active cluster can consist of up to eight identical FortiWeb appliances. One of the cluster
members is selected as the master and other members act as slaves. The master receives all traffic from
clients and web servers and then distributes the traffic to cluster members, including itself.
Similar to the active-passive HA deployment, the operation of active-active HA cluster requires heartbeat
detection and configuration and session synchronization between the cluster members. If the master device
fails, one of the slaves will take it over. The heartbeat interfaces of all the HA devices must be connected
directly with crossover cables or through switches to carry the heartbeat and synchronization traffic between
the HA cluster members. The failover is almost instantaneous.

 Basic Setup
DO NOT REPRINT
© FORTINET
If you don’t configure FortiWeb to operate in reverse proxy mode, you would not usually configure an HA
network topology. Configuring an HA network topology in other operation modes could require changes to
your network scheme, which defeats one of the key benefits of other operating modes; they require no IP
changes.
Instead, you can use an existing external load balancer or HA solution in conjunction with FortiWeb
configuration synchronization, to preserve an existing active-active or active-passive topology.
Unlike FortiWeb HA, an external HA device detects when a FortiWeb has failed and then redirects the traffic
stream. FortiWeb has no way of actively notifying the external HA device. To monitor the live paths through
your FortiWeb configuration, you could configure your HA device to poll either a back-end web server or an IP
on each FortiWeb bridge (V-zone).

 Basic Setup
DO NOT REPRINT
© FORTINET
This slide covers a few VM-specific tips to consider if you’re using FortiWeb VM. The most important thing to
consider is that the HA heartbeat and failover (ARP) are latency sensitive. So, if your FortiWeb VMs share
hardware with other guest OSs, make sure that the FortiWeb VM has priority.

 Basic Setup
DO NOT REPRINT
© FORTINET
Link two ports that HA will use to communicate directly, then if possible, configure HA before configuring the
network interfaces. The network settings will sync, as well as other, subsequent settings. FortiGuard antivirus
packages now sync between the peers, so you no longer have the initial risk after the failover period. Some
data, such as logs and reports stored on the local hard drive, don’t sync. See the documentation for details.

 Basic Setup
DO NOT REPRINT
© FORTINET
If you don’t have two FortiWebs for HA, and you’re using transparent mode, you can still prevent hardware
failure from interrupting traffic. To do this, connect through port pairs and configure fail-open to bypass. Note
that your web sites will be totally unprotected until you replace the failed FortiWeb!

 Basic Setup
DO NOT REPRINT
© FORTINET
Fail-open is available only on FortiWeb models that have a specific type of ASIC chip between each port pair.
When you set fail-open options, FortiWeb programs the chip to behave as either a bypass or circuit interrupt,
when FortiWeb loses power or reboots.
• PowerOff-Bypass: Behaves as a wire when the FortiWeb device is powered off. This allows connections
to pass directly from one port to the other, bypassing all policy scans and modifications.
• PowerOff-Cutoff: Interrupts connectivity when the FortiWeb device is powered off. The bypass is
disabled. This is the default setting.
Alternatively, you can use FortiBridge.

 Basic Setup
DO NOT REPRINT
© FORTINET
The next step is to configure network interfaces and set which administrative protocols are enabled on the
interface. If you’re deploying in a cloud, such as Amazon Web Services, use DHCP instead of a static IP
address.

 Basic Setup
DO NOT REPRINT
© FORTINET
You should specify at least one route to the default gateway. This route is where FortiWeb sends traffic if an
IP isn’t directly connected. Usually, this is the upstream FortiGate or (if FortiGate is in transparent mode) the
Internet router. If you have a large internal network, and your protected web servers are not on the same
subnet, you must add a route for those destinations as well.

 Basic Setup
DO NOT REPRINT
© FORTINET
If your network interfaces use DHCP, especially if you have dual gateways, then static routes are not enough.
You may need to route traffic based upon the ingress port, the source, or both. To do this, you can now
configure policy-based routes.

 Basic Setup
DO NOT REPRINT
© FORTINET
Once FortiWeb connects to the Internet, if it has a FortiGuard subscription package, it downloads updates.
For FortiWeb, FortiGuard provides several updatable components—many more than just antivirus or intrusion
signatures. FortiGuard security also provides updates on known web app administrative URLs, information
leakage patterns, data types for input enforcement, IPs of current known attackers, and more.

 Basic Setup
DO NOT REPRINT
© FORTINET
The best practice is to enable FortiWeb to periodically check for FortiGuard update packages and
automatically install them. The antivirus databases are very similar to FortiGate and FortiMail, except that
there is no extreme database.
Notice the antivirus buffer size. This is one of FortiWeb’s many buffers. Is it big enough for most uploads? Is it
small enough that antivirus scans won’t use too much RAM? By default, FortiWeb passes uploads that are too
large to fit in the buffer. Virus uploads are usually small, so this is not a significant risk. But, if security is more
important than performance or accepting all uploads, then you should configure an HTTP constraint. This will
block POST requests where the body that is, the uploaded file is too large to fit the buffer. This is part of
security hardening.

 Basic Setup
DO NOT REPRINT
© FORTINET

 Basic Setup
DO NOT REPRINT
© FORTINET
Good job! You now understand the logic behind the FortiWeb configuration process and different deployment
options.
Now, you will learn how FortiWeb can address FTP and SSH, and how FortiWeb works in conjunction with
proxies.

 Basic Setup
DO NOT REPRINT
© FORTINET
By demonstrating competence in understanding how routing and forwarding works on FortiWeb, you will be
able to configure FortiWeb to act as a router, when appropriate for your network.

 Basic Setup
DO NOT REPRINT
© FORTINET
This slide shows the basics of how FTP (by default, on port 21) arrives at a virtual IP (VIP) on FortiGate.
Fortigate applies NAT then routes packets to FortiWeb. However, because it’s not HTTP, there is no proxy
pickup. Instead, FortiWeb simply routes the packet to its destination IP address. Unlike HTTP, with FTP or
SSH, the destination address must be the backend servers not FortiWeb’s virtual server.

 Basic Setup
DO NOT REPRINT
© FORTINET
If you’re using transparent mode, no configuration is required. FortiWeb allows other protocols to pass
through. However, if you’re using FortiWeb in reverse proxy mode, then you must enable IP-based forwarding
(routing) if you want it to transmit FTP or SSH. It’s very common for web servers to have secondary services
such as FTP or SSH. This allows web developers to update their applications and upload new files. Keep in
mind, however, that as a WAF, FortiWeb specializes in HTTP. FortiGate has session helpers for SIP with the
voice portion of Lync, for example, but FortiWeb doesn’t, so this may not work for all protocols. In that case,
you may need to adjust your topology so that FortiWeb is not a router hop for those protocols.

 Basic Setup
DO NOT REPRINT
© FORTINET
In transparent mode, FortiWeb forwards as a Layer 2 device. So, by default, web traffic passes through. If you
want web traffic to be inspected, you must define where FortiWeb should pick up traffic: which bridge and
TCP port number. This is a key difference from operating in reverse proxy mode.
In reverse proxy mode, FortiWeb forwards as a Layer 3 device. So, by default, traffic that is not destined for a
management IP or virtual server IP is dropped effectively—it is blocked. Web traffic won’t flow until you define
a virtual server IP and listening port number, as well as the destination server’s NAT IP or destination in the
back-end IP session. Non-web traffic isn’t picked up by a virtual server, nor is it destined for FortiWeb itself, so
traffic won’t flow unless IP-based forwarding (that is, routing) is enabled.

 Basic Setup
DO NOT REPRINT
© FORTINET
This table shows how traffic flow, proxy pickup, blocking styles, and SSL termination all vary by operating
mode.

 Basic Setup
DO NOT REPRINT
© FORTINET
To define transparent proxy or virtual server pickup, usually you can use the predefined port numbers port 80
for HTTP and port 443 for HTTPS. But, if your web servers allow API connections or requests to staging
websites, for example, you may need to define web services on other port numbers, such as port 8080.

 Basic Setup
DO NOT REPRINT
© FORTINET

 Basic Setup
DO NOT REPRINT
© FORTINET
Good job! You now know how to configure FortiWeb to deal with proxies.
Now, you will learn about dealing with load balancers in the network.

 Basic Setup
DO NOT REPRINT
© FORTINET
After completing this section, you will be able to achieve the objectives shown on this slide.
By demonstrating competence in describing and discussing server pools, load balancing, and session
persistence, you will be able to define where FortiWeb sends traffic in your network.

 Basic Setup
DO NOT REPRINT
© FORTINET
You define your destination backend web servers by specifying their IP addresses in server pools. Depending
on FortiWeb’s operation mode, it will either:
• Forward the frames, if it’s operating as a Layer 2, transparent device
• Rewrite the destination IP and distribute it according to your load balancing algorithm, if it’s operating in
reverse proxy mode
How do you define if subsequent requests are sent to the same server? How do you define how the load of
the first request in an IP or HTTP session should be distributed? Can you avoid servers that are down for
maintenance?
You must define some objects first.

 Basic Setup
DO NOT REPRINT
© FORTINET
Load balancing on FortiWeb is similar to load balancing on FortiGate, but with the addition of web-specific
methods. This is useful since HTTP has its own sessions at that layer, and because sometimes different web
servers are dedicated to hosting specific web apps.
You can specify that the load is distributed by HTTP session cookie instead of TCP/IP connection.
You can also choose, instead of load balancing, to use FortiWeb as a Layer 7 switch. When you use FortiWeb
as a Layer 7 switch, requests are sent to specific servers based on the hostname, or URL, or both. For
example, FortiWeb can send Microsoft SharePoint requests to a different server than Outlook Web App
requests.

 Basic Setup
DO NOT REPRINT
© FORTINET
After you make the initial load balancing decision, by default, each subsequent request could be sent to a
different web server, according to the algorithm. If you don’t want this to happen–for example, if your users log
in and only that server can associate the next request with that login–then you must configure session
persistence.

 Basic Setup
DO NOT REPRINT
© FORTINET
You can define session persistence in several ways, using either the IP or HTTP layer. This is similar to
FortiGate. If you want to use a session cookie-based method, the most efficient way is to use one of your
app’s own session cookies. If your session doesn’t have a cookie, FortiWeb can inject its own load balancing
session cookie, and use it to track the sessions.

 Basic Setup
DO NOT REPRINT
© FORTINET
If you aren’t sure whether your app has its own session cookies, it’s easy to find out. Look in your browser’s
cache, or download one of the many add-ons supported in Google Chrome or Mozilla Firefox.
In this example, you can configure FortiWeb to use the value in the cookie PHPSESSID to uniquely identify
sessions, and always route them to the same server.

 Basic Setup
DO NOT REPRINT
© FORTINET

 Basic Setup
DO NOT REPRINT
© FORTINET
Good job! You now understand load balancing, pass through, and how to define where FortiWeb sends traffic
in your network.
Now, you will learn about virtual hosts.

 Basic Setup
DO NOT REPRINT
© FORTINET
By demonstrating competence in understanding protected hostnames and configuring server policies, you will
be able to use hostnames to effectively deal with domains.

 Basic Setup
DO NOT REPRINT
© FORTINET
Protected host names can be domain names, but they can also be IP addresses. You should add all host
names that clients use, or that DNS could resolve to.
Protected host names can be used in the server policy to filter which traffic matches. They can also be used to
restrict matching in component objects such as URL rewrites, and for HTTP content routing.

 Basic Setup
DO NOT REPRINT
© FORTINET
Here’s an example of how you can use a protected hostnames definition to deny all requests that are not for
either www.example.co.uk or 10.0.1.253
When applied in a server policy, a reverse proxy FortiWeb would block a request to
http://example.co.uk because it is not an exact match. If you want to accept that variant and forward
it to your web servers, then you would add that hostname to the list, and select Accept in the Default Action
drop-down list. The request could still be blocked by a later scan–antivirus, for example–but it would not be
due to its host name.

 Basic Setup
DO NOT REPRINT
© FORTINET
When all objects are ready, create a server policy. In that policy, select your objects.
You must select a protection profile in order to save the policy. If you’re using reverse proxy mode, initially, to
test traffic flow, you can select the Alert Only profile or enable Monitor Mode. This will match traffic, and log
any attacks that the protection profile detects, but it will not block anything yet.
Then, after you’ve tested connectivity, you can clone and modify the protection profile to begin blocking
attacks. Be sure to disable Monitor Mode when you’re ready to begin blocking.
If you’re using transparent mode, remember that just because traffic is allowed, does not mean it was picked
up by the proxy. Transparent mode allows non-matching traffic by default. To be sure that traffic was matched
by a policy, enable and check your traffic logs.

 Basic Setup
DO NOT REPRINT
© FORTINET

 Basic Setup
DO NOT REPRINT
© FORTINET
Good job! You now understand virtual hosts.
Now, you will learn how to configure logging, including remote logging, on FortiWeb.

 Basic Setup
DO NOT REPRINT
© FORTINET
By demonstrating competence in configuring logging, you will be able to collect logging information from
FortiWeb.

 Basic Setup
DO NOT REPRINT
© FORTINET
FortiWeb can store logs locally on its hard disk or in RAM, however, logging externally has the following
benefits:
• Flexibility for reporting
• Better performance
• Better scalability
• Visibility for multi-device attack correlation

 Basic Setup
DO NOT REPRINT
© FORTINET
Now, you will learn how to set up FortiWeb to log externally.
First, define the IP address of FortiAnalyzer. This is where FortiWeb will send logs, if you’ve selected that
destination, and they match the type, severity, and other criteria.

 Basic Setup
DO NOT REPRINT
© FORTINET
Next, select your FortiAnalyzer definition in a trigger policy. If you also want to receive an alert email for
severe logs, such as hardware failure or DDoS attack, you can define multiple notification settings. Select
your FortiAnalyzer in each one, then also define an email server and select it in the trigger policy that you use
with severe events. Alternatively, you could configure your alert email in a central location, on FortiAnalyzer.

 Basic Setup
DO NOT REPRINT
© FORTINET
Now enable event and traffic log output to go to your FortiAnalyzer. Specify what severity of logs should be
sent. Remember: logging information-level events and greater can significantly increase bandwidth usage,
decrease performance, and require much more disk space on your FortiAnalyzer. After completing the
configuration, verify that your FortiAnalyzer model is powerful enough to handle the log volume without
dropping logs. Syslog is a UDP connectionless protocol that is lightweight but does not verify successful
message transmission and storage. Also verify that you’ve allocated enough disk space.
For example, if you need to store three months worth of logs, see how much disk space is consumed after a
normal week, then multiply it by 12 weeks. For a robust solution, also simulate logging volumes that could
happen if your network is under attack. This is when your logs are most crucial.

 Basic Setup
DO NOT REPRINT
© FORTINET
Choose which log types to record: attack logs, event logs, and, possibly, traffic logs. Remember that packet
payloads can only be stored on FortiWeb’s local hard disk. Like traffic logs, they can be disk intensive. If
possible, it’s best to enable that option only during troubleshooting.

 Basic Setup
DO NOT REPRINT
© FORTINET
For event logs that record critical system resource usage, you have even more granular control. You can
specify which levels will trigger a log message, and indicate a more specific trigger policy.

 Basic Setup
DO NOT REPRINT
© FORTINET
For the attack log, configuration is even more flexible. For each specific rule or attack signature, indicate
whether to log violations, and which notification servers (if any) to use. This is where you should select the
trigger policy that uses your FortiAnalyzer object.

 Basic Setup
DO NOT REPRINT
© FORTINET

 Basic Setup
DO NOT REPRINT
© FORTINET

 Basic Setup
DO NOT REPRINT
© FORTINET
By mastering the objectives covered in this lesson, you learned how to complete tasks involved in the basic
set up of FortiWeb.

 Integrating Front-End SNAT and Load Balancers
DO NOT REPRINT
© FORTINET
In this lesson, you will learn about special deployment considerations including:
• Where you should locate FortiWeb between your firewall and your servers
• Whether you should use built-in load balancing, or an external load balancer

DO NOT REPRINT
© FORTINET

DO NOT REPRINT
© FORTINET
By demonstrating competence in configuring FortiWeb to function behind an SNAT device, you will be better
able to understand how you can prevent innocent clients from being blocked.

DO NOT REPRINT
© FORTINET
FortiWeb has a built-in load balancer. Why and when should you use an external load balancer? There are
two primary reasons:
• Complexity: If you require very complex HTTP content routing rules, it might be worth a specialized
application delivery controller (ADC)
• Protocol support: FortiWeb specializes in HTTP. It can’t load balance other protocols. So, for example,
FortiWeb can’t load balance SIP for Microsoft Lync
If FortiGate is in NAT mode, you can set up a virtual server—a special type of VIP—to forward HTTP traffic to
FortiWeb. This can apply source NAT (SNAT) and load balancing. SNAT has unwanted side-effects with
FortiWeb because, by default, most of its features block based on the IP layer’s source address. So, you must
configure both FortiGate and FortiWeb correctly to avoid this. Note that this is specific to NAT. If your front-
end FortiGate routes but doesn’t apply NAT, or if it’s in transparent mode, then this doesn’t apply.
If you have FortiADC in front of FortiWeb, the same factor applies. It can be deployed either in front, or, more
commonly, behind FortiWeb. You'll learn about these two different deployments later in the lesson.

DO NOT REPRINT
© FORTINET
Before, or after? Location matters. If you have a transparent external load balancer that is positioned in front
of FortiWeb, you probably won’t need to do any specialized configuration. But if that load balancer applies
source NAT, you must configure both the load balancer and FortiWeb to read and apply an HTTP-layer X-
header (usually X-Real-IP: or X-Forwarded-For:) so that FortiWeb blocks clients based on the request’s
original source IP, not the current source IP (which is the load balancer).
FortiWeb X-headers now support IPv6, so this is no longer a factor in where you can deploy FortiWeb.
If your load balancer is positioned behind FortiWeb, the configuration of X-headers is simpler, but still
important. If the configuration is not correct, your load balancer could send all sessions to one server
because, at the IP layer, it looks like your load balancer has only one client: your reverse proxy FortiWeb. So,
source IP-based session persistence to the same back-end server won’t distribute load correctly. The load
balancer should forward based on an HTTP-layer session cookie, or by deriving the original client’s IP from
the X-header.

DO NOT REPRINT
© FORTINET
After you have configured your upstream or downstream NAT device to read or send X-headers, configure
your FortiWeb to use them. The settings you need to configure if your load balancer is positioned upstream
are highlighted on this slide. If your load balancer is positioned downstream, the settings you configure are
different. Enable Add X-Forwarded-For: or Add X-Real-IP: instead. Since HTTP headers aren’t
authenticated and are easy to spoof, be sure to define which IP addresses–for example, your upstream
FortiGate–are the trusted providers of this header.

DO NOT REPRINT
© FORTINET
Once you’ve configured how FortiWeb will use the X-Forwarded-For (XFF) header, you can apply the header
by selecting it in a protection profile that is used by a server policy.

DO NOT REPRINT
© FORTINET
If the client is on the Internet and has a public IP address, the attack logs show the original client’s IP, not the
IP address of your FortiGate. This helps when you need to identify the IP address of a repeat attacker so you
can blacklist their source IP.
If the client is on your private network and has an RFC 1918 address, many clients on other private networks
could have the same IP address. So the X-header will be ignored. In that case, the IP-layer source address
will still be in the attack log.

DO NOT REPRINT
© FORTINET
Since the IP layer’s source address hasn’t really been changed, and because the traffic log is often used to
troubleshoot IP-layer connectivity, this log still shows your front-end load balancer’s IP.

DO NOT REPRINT
© FORTINET

DO NOT REPRINT
© FORTINET
Good job! You now know how to configure FortiWeb to operate behind a load balancer.
Now, you will learn about the configuration needs of FortiGate within this scenario in order for FortiGate to
serve as the SNAT device.

DO NOT REPRINT
© FORTINET
By demonstrating competence in configuring FortiGate as an SNAT device, you will be better able to
understand how a front-end SNAT device works with FortiWeb.

DO NOT REPRINT
© FORTINET
You configured FortiWeb to block the original client’s IP, not FortiGate’s interface IP. To use FortiGate’s
interface IP, you must configure FortiGate’s HTTP proxy to add an X-Forwarded-For: header with the original
client’s IP; not remove or ignore the header. This is also a good time to configure the policies that FortiWeb
needs for both inbound and outbound traffic.

DO NOT REPRINT
© FORTINET
Where should you start?
IP addresses are referenced by each policy on FortiGate, so define those first. Add all potential source and
destination addresses:
• FortiGate’s virtual server as a destination will accept HTTP, apply NAT, and possibly add an X-Forwarded-
For: header. If your FortiGate is in transparent mode, the destination for HTTP traffic could be your
FortiWeb. If both devices are in transparent mode, then the destination IP could be your load balancer or
back-end web servers
• If you need to forward other protocols, such as RDP or SSH to your web servers, a FortiGate VIP may also
be an IP packet’s destination address
• FortiWeb itself can be a source of traffic outbound to the Internet for FortiGuard updates, DNS, email,
SNMP, or syslog
Note that FortiWeb’s virtual server replies, but never initiates an IP session–just like the back-end web
servers. So, it’s only used in policy destinations, not sources.

DO NOT REPRINT
© FORTINET
By default, load balancing, including virtual servers, are hidden on FortiGate’s GUI. To show them, turn on
that feature.

DO NOT REPRINT
© FORTINET
When FortiGate is running in NAT mode, it usually applies destination NAT. At the IP layer, this changes the
packet’s destination address to FortiWeb’s real, private network address. If FortiGate applies source NAT too,
then it also rewrites the source addresses of the packets. It might be to a pool, or to the egress interface’s
physical IP. If it does that, then from FortiWeb’s perspective, FortiGate is the client, not the browser. What’s
the result? When FortiWeb detects an attack, depending on the scan, it could block your FortiGate!
So, if your FortiGate applies source NAT, you’ll usually want to make sure that it also passes the packet’s
original SRC IP to FortiWeb. Otherwise, the following will happen:
• Many FortiWeb features, such as IP reputation, which uses public IPs, won’t work
• You will need to configure IP pools for the virtual server on FortiGate to prevent IP session or TCP
connection reuse (also called multiplexing) for unrelated HTTP requests. Otherwise, when the web app is
attacked, innocent requests in the same IP session or TCP connection may be dropped or reset. If you
block with period blocks, the effect is multiplied, and could effectively cause your web app to be down. So
configure and test this carefully!

DO NOT REPRINT
© FORTINET
Normally, FortiGate is used for SSL inspection. It decrypts a copy of a packet in order to scan it, but doesn’t
actually terminate the SSL session. Instead, it passes along the encrypted packet, if it doesn’t violate the
security policies. However, when using load balancing, FortiGate can terminate the SSL session, and pass
clear text HTTP to FortiWeb. This is called SSL offloading.
Should you use FortiWeb or FortiGate for SSL offloading? It depends on which device has less system load
and processing power. You could do it on either, or–if compliance requires the data to remain encrypted in
transit all the way to the web server–you aren’t required to do SSL offloading at all.
If both FortiWeb and FortiGate will inspect secure traffic to the servers, upload the server’s private key and
certificate to both devices.

DO NOT REPRINT
© FORTINET
After configuring the virtual server on FortiGate, configure the mapping for FortiGate’s load balancer: the
packets’ next destination IP, called the real server.
For a reverse proxy FortiWeb, instead of a back-end web server, the real server is the IP address of a virtual
server on FortiWeb. For transparent modes or offline mode, the real server is the IP address of a back-end
load balancer or actual web server.

DO NOT REPRINT
© FORTINET
If you’re doing SSL inspection–but not SSL offloading–FortiWeb’s virtual server should be listening for HTTPS
on port 443, not clear text HTTP on port 80.

DO NOT REPRINT
© FORTINET
If clients will use other protocols to access the web servers, remember to make VIPs to forward that traffic too.

DO NOT REPRINT
© FORTINET
Depending on your topology, you may be able to forward other protocols such as SFTP directly to back-end
servers. This prevents complications for protocols that need session helpers, and also improves round-trip
time, because FortiWeb isn’t a routing hop for non-HTTP protocols.

DO NOT REPRINT
© FORTINET
Finally, assemble the firewall addresses in the policy. Select HTTP or HTTPS as the service, and the DMZ
port and FortiGate’s virtual server as the destination.
If you enable source NAT, use the egress interface’s IP as the back-end IP session’s source IP, not a
dynamic pool. This will ensure that FortiGate uses the IP address expected by the FortiWeb’s X-header rule’s
list of trusted IPs. For non-HTTP protocols, also make policies for the VIPs of those services.

DO NOT REPRINT
© FORTINET
Don’t forget outgoing policies so that FortiWeb can connect to the Internet, and to remote logging or
authentication servers.

DO NOT REPRINT
© FORTINET
The example on this slide shows a load balancing profile that you might see on FortiADC VM or hyphenate D-
series models. This is where you configure the X-header for HTTP or HTTPS connections, if your FortiADC is
situated in front of your FortiWeb.
As a device that specializes in application-layer routing, you can see that FortiADC provides many more
features than FortiGate’s load balancer, in addition to dedicated system resources for high performance.

DO NOT REPRINT
© FORTINET

DO NOT REPRINT
© FORTINET

DO NOT REPRINT
© FORTINET
By mastering the objectives covered in this lesson, you learned why you might add an external load balancer,
when to locate it in front of FortiWeb, and if it’s applying source NAT. You also leaned how to configure it to
transmit the original client’s IP to FortiWeb, how FortiGate can use that HTTP header to block attacks
correctly instead of blocking all sessions from the FortiGate, and how the source address in attack logs
change when X-Forwarded-For: headers are used.

 DoS and Defacement
DO NOT REPRINT
© FORTINET
In this lesson, you will learn about why and how to mitigate denial of service (DoS) attempts, and how to
prevent (and rapidly, automatically reverse) vandalism.

DO NOT REPRINT
© FORTINET

DO NOT REPRINT
© FORTINET
By demonstrating competence in understanding the threats, you will be able to identify how FortiWeb can help
protect your network.

DO NOT REPRINT
© FORTINET
DoS attacks have made news headlines for years, but many network engineers see them as a nuisance, not a
real threat. This is a mistake.
The high cost of DoS attacks is clear in studies by Amazon, Google, and the University of Waterloo
(https://cs.uwaterloo.ca/~bernard/edgecloud). Any latency greater than 80 milliseconds is noticeable to users.
According to Greg Linden, Amazon found every 100 milliseconds of latency cost them 1% in sales. According
to VP Marissa Mayer, Google found an extra .5 seconds in search page generation time dropped traffic by
20%. Meanwhile, Goldman Sachs is making record profits off a 500 millisecond trading advantage. A broker
could lose $4 million in revenues per millisecond if their electronic trading platform is 5 milliseconds behind
the competition. When a DoS attack occurs, latency or unresponsiveness increases until the service is totally
unusable. Some DoS attacks, such as the one that Sony faced in 2011, last for weeks, and are coupled with
breaches and data theft. That estimated cost was $250 million; and that doesn’t include identity theft or credit
card fraud.
Sony’s distributed DoS (DDoS) attack was massive, but it was ultimately a diversion tactic that distracted from
worse compromises.

DO NOT REPRINT
© FORTINET
Clearly DoS attacks are not harmless, or cheap. Everyone from businesses to governments are targets.
How can you stop them?
DoS is a broad category of attacks. Protocols from NTP monlist, to HTTP, and SSL have been used. It’s any
attack that makes a service unresponsive without a rootkit or other breach. Once a server’s bandwidth, CPU,
memory, or service-specific sockets or memory buffers are consumed, then it can’t respond to legitimate
users. To stop a DoS attack, you must prevent those resources from being consumed. Since this lesson is
about FortiWeb, we’ll talk about how to mitigate DoS attacks on the main protocols that affect the web: IP,
DNS, TCP, HTTP, and SSL or TLS.

DO NOT REPRINT
© FORTINET
FortiWeb is not designed to defend DNS servers. But it is critical that you don’t forget DNS when hardening
your defenses.
Without DNS, the web doesn’t work.
Consider the case of Lenovo. After Lenovo’s Superfish vulnerability was disclosed, the hacker group Lizard
Squad used a DNS hijack to redirect lenovo.com to their own web server. The files on Lenovo’s web
servers weren’t actually modified at all. Only the DNS servers were compromised.
There are secure, load-tested DNS solutions. Since web apps are often hosted in redundant data centers
though–some in San Francisco, others in New York, Sao Paulo, Shanghai, Oslo, Frankfurt, or Dubai–it’s also
worth it to consider a DNS solution such as FortiDirector. It can send clients to the closest data center that is
still available.
That way, if an individual data center is under a 300 Gbps attack, for example, legitimate clients could still use
other sites that aren’t affected. In a severe DDoS, the latency caused by a server being in another country still
might be better than a server under heavy attack.

DO NOT REPRINT
© FORTINET
To fight DoS attacks, first you need to know if it is really a DoS attack, or just a traffic spike. What’s your
network’s normal behavior including during periods such as holiday shopping seasons? Do you normally have
traffic from Brazil or Antarctica?
Some types of DoS attempts are easy to determine with certainty. TCP SYN flood and TCP floods for a single
HTTP session cookie are almost never caused by normal clients.
But in other cases, a traffic anomaly is relative to your normal traffic patterns. How many images, scripts, and
videos are loaded for each web page? How many people usually visit your site on Sunday, compared to
Monday? If you know your normal ranges, it is easier to recognize a traffic spike, and to avoid misconfiguring
your DoS sensors on FortiWeb.

DO NOT REPRINT
© FORTINET

DO NOT REPRINT
© FORTINET
Good job! You now have a better understanding of various threats.
Now you will learn how to mitigate threats at the network and transport layers.

DO NOT REPRINT
© FORTINET
By demonstrating competence in using FortiWeb against DoS attacks that use web stack protocols using
multiple solutions, you will be able to mitigate attacks that function at different layers, in different ways.

DO NOT REPRINT
© FORTINET
At the IP network layer, FortiWeb can protect you in multiple ways.
When you apply a period block action to a signature, that client’s source IP is ignored until the penalty times
out. But that’s not the only way that FortiWeb uses the client’s source IP.
One of the best methods of protection is FortiGuard IP reputation. It requires no maintenance, and it’s efficient
– it blocks quickly, at a low layer, before FortiWeb has wasted CPU time on more intensive HTTP scans.

DO NOT REPRINT
© FORTINET
An IP can have a bad reputation for different reasons. Which of those reasons matter?
Zombie PCs can send both attacks and innocent traffic – sometimes, the person is using their computer
without knowing that they are infected. Other types of attacks indicate source IP addresses that always should
be blocked.
Unless you’re protecting webmail servers, you may not need to block IPs that are known spammers; however,
you may want to apply a period block action to known botnet participants, since they are often associated with
DoS attacks. Period block can improve performance. Like all caching strategies, it uses a little bit of RAM to
save CPU and bandwidth resources that are scarce during a DoS attack. FortiWeb will not remove the client’s
IP from its temporary blacklist cache until the period expires, and it won’t waste CPU or bandwidth replying
with a 403 error at the HTTP layer.

DO NOT REPRINT
© FORTINET
If you’re not completely blocking an IP, then the next logical action is to protect your network from rate
anomalies. Usually, it doesn’t work well to apply the same rate limit to all user types. Request rates that are
normal from an airport Wi-Fi network or large office would be very abnormal for a single person at home. You
don’t want to set too low a limit, effectively blocking all large buildings. But due to IPv4 NAT, it can be hard to
tell how many private network clients are behind the public IP.
On FortiWeb, there are two ways to distinguish shared Internet connections and apply different rate limits for
them. One way is shared IP.

DO NOT REPRINT
© FORTINET
The Shared IP setting uses a small amount of RAM for each client to remember the sequence ID number in
the previous packet’s IP header. If your web apps’ requests don’t have a session cookie, this may be the only
way that you can distinguish when multiple clients share the same Internet connection.
If the numbers are sequential, then that IP usually has only one client behind the public IP. FortiWeb calls this
a standalone IP. If the numbers are non-sequential, it usually means that there are multiple clients behind that
public IP. FortiWeb calls this a shared IP, and you’ll usually configure higher rate limits for shared IPs in DoS
sensors that use the Shared IP setting.

DO NOT REPRINT
© FORTINET
Not all DoS sensors use the Shared IP setting. TCP flood prevention, for example, simply specifies one
connection rate limit.

DO NOT REPRINT
© FORTINET
What would happen if you weren’t on the first page of results for Google, Yahoo!, or Baidu? Just as it’s
important to block bad IPs, it’s equally important to not block good IPs!
If you host a public website, search engine crawlers will periodically access your web site for search rankings
and sometimes page cache. Their scripts are much faster than humans. But search engines are not a DoS.
So clearly you shouldn’t give them a low rate limit. You probably shouldn’t block them at all.
If you block a search engine, your rankings can suffer, and people may not be able to find your website. This
can be devastating for e-commerce, government service, and content sites. To prevent this, if your web apps
are publicly accessible, whitelist known search engines on FortiWeb.

DO NOT REPRINT
© FORTINET
Known search engines are one of the many objects that FortiWeb keeps updated by FortiGuard services.
While search engines often identify themselves by their User-Agent: HTTP header, those headers can be
easily forged, so it’s important to allow them based upon their public source IP address instead. You should
periodically check the list for updates. If a new search engine becomes popular, you may have a new option
on FortiWeb.

DO NOT REPRINT
© FORTINET

DO NOT REPRINT
© FORTINET
Great job! You now know how to detect and prevent threats at the network and transport layers.
Now, you will learn about threats at the application layer.

DO NOT REPRINT
© FORTINET
By demonstrating competence in understanding how FortiWeb can use its DoS protection features analyze
the application and transport layers together, you can use those features to mitigate threats.

DO NOT REPRINT
© FORTINET
Search engines are well-known bots. But what about scripted access from bots that you don’t know? These
can sometimes be legitimate power users using tools such as wget. But more often, they are DoS tools. If
FortiWeb only analyzed the TCP/IP layers, these DoS tools could be difficult to detect. But, FortiWeb can
analyze and work with the HTTP layer, too.
DoS tools are often command line, lightweight, and don’t support many of the functions that a normal, full-
featured web browser like Firefox or Chrome would. So, when a client exceeds a rate limit, you can configure
FortiWeb to inject a test script into the page, and validate whether the requests are coming from a browser or
not. If the requests are coming from a bot, you can block that source IP.

DO NOT REPRINT
© FORTINET
HTTP Flood Prevention also does traffic policing on HTTP requests, but it operates differently from HTTP
Access Limits. Do you see a separate Shared IP rate?
No.
When enforcing HTTP Flood Prevention, FortiWeb injects a session cookie in the server’s HTTP response.
Since clients keep separate session cookie caches, as long as the client accepts cookies, it uniquely identifies
the client. FortiWeb counts the rate of requests from that session cookie value. If the rate is too high, and
you’ve enabled Real Browser Enforcement, then FortiWeb uses the real browser enforcement JavaScript to
fingerprint the client and determine if it is a person’s browser or a bot. If a bot is detected, FortiWeb applies
the block action that you’ve selected.

DO NOT REPRINT
© FORTINET

DO NOT REPRINT
© FORTINET
Good job! You now know how to detect and prevent application layer threats.
Next, you will learn about blended analysis, where all three layers are involved.

DO NOT REPRINT
© FORTINET
By demonstrating a thorough understanding of blended analysis, you will be able to use blended analysis
techniques as part of a multilayer DDoS mitigation solution for your network.

DO NOT REPRINT
© FORTINET
When FortiWeb is enforcing the HTTP access limits, it can combine real browser enforcement with shared IP,
which you can see in the HTTP request limit shown on the slide.
Although it works on both the IP and HTTP layers, this FortiWeb feature doesn’t require the client to support
cookies–only JavaScript.
To cause connection timeouts on resource clogging malicious clients and discourage them from returning, you
can set the Action to Period Block.

DO NOT REPRINT
© FORTINET
Malicious IPs is another DoS mitigator that you can use with high confidence. Although some download
accelerators do use multiple connections, it’s very rare that legitimate clients will open many TCP connections
simultaneously. Normal browser tabs on Firefox and Chrome are not going to be the source of 1,024
simultaneous TCP connections. So, the TCP Connection Number Limit is a good candidate for a period
block action.

DO NOT REPRINT
© FORTINET
Once you have configured DoS sensors, group them together into an anti-DoS policy that specifies which
ones to use. You may want to configure multiple DoS policies, depending on the types of web apps you host.
Then, select the sensors in the protection profile used by a server policy.

DO NOT REPRINT
© FORTINET
DoS vulnerabilities can be inherent in the design of some web protocols. We’ve shown DoS sensors that
involve HTTP session cookies. But your other HTTP headers, individual servlets, and web apps can have
their own DoS vulnerabilities too. To prevent attackers from taking advantage of these vulnerabilites, you can
use HTTP constraints to limit the HTTP protocol and app-specific input buffers to reasonable amounts.
Sometimes, web app DoS vulnerabilities can be detected with FortiWeb input rules. You will learn about
FortiWeb input rules in another lesson. For example, a login page should usually accept only one password
input. If the application accepts many passwords, then it’s possible to use that feature to create an app-
specific DoS attack.

DO NOT REPRINT
© FORTINET
You shouldn’t forget your FortiWeb itself when engineering your network to be resilient to attacks. How you
configure FortiWeb also affects how successful you will be.
Similar to your web apps, you should consider RAM and other sizing factors. You should also consider your
settings for various scan buffers, response cache, and how FortiWeb is configured to handle them.

DO NOT REPRINT
© FORTINET
Most DoS mitigation that FortiWeb does is in software. In other words, it does increase CPU, or RAM load, or
both. So, if you have large or high-profile attack targets, it’s best practice to combine FortiWeb with a purpose-
built hardware device like FortiDDoS. FortiDDoS is a specialist. Sophisticated anomaly analysis over time,
with data aging, ensures that you can intelligently cope with massive throughput. Its specialized chips can
help to keep your network working near line speed. Performance like this is simply not possible in software on
a general-purpose CPU.

DO NOT REPRINT
© FORTINET

DO NOT REPRINT
© FORTINET
Good job! You now understand how to detect and prevent multilayer threats.
Now, you will learn about breaches in the network.

DO NOT REPRINT
© FORTINET
By demonstrating knowledge of well-known security breaches and FortiWeb's anti-defacement solutions, you
will be able to protect your network.

DO NOT REPRINT
© FORTINET
There are reasons why some targets, like the FBI and MIT, are persistently attacked. But you don’t have to be
rich, powerful, or politically controversial to have your website defaced. About 1.5 million websites were
defaced in 2014, and this number is growing rapidly. Targets included a local rugby team, a Montessori school
in Abu Dhabi, Baseball Canada, and UK charity groups for cancer research. Many bulk defacements are
abandoned after the attack is done, with the attacker moving on to look for new targets.

DO NOT REPRINT
© FORTINET
Not all security breaches are for extortion or stealing data. Some, like those done by LulzSec and ISIS, are
just vandalism. They may spread propaganda or discredit and humiliate the target.
FortiWeb has an anti-defacement feature. It keeps hashes of files in your Apache, IIS, or other website
directory. Periodically, FortiWeb connects to the server to see if the files have changed. If it detects a change,
and you did not explicitly tell FortiWeb that an authorized change would occur, then FortiWeb can email you or
automatically revert the files to a clean copy. This can help minimize the impact of drive-by mass defacements
at hosting providers, while you work to discover and analyze the security hole.

DO NOT REPRINT
© FORTINET
When you configure anti-defacement, FortiWeb periodically uses FTP, SSH, or the SMB/CIFS protocol to
connect to your back-end web servers to look for changes to the files.
The first time it connects, FortiWeb will download copies to its own hard disk. These are the clean copies that
it will restore if it detects defacement, and if you have enabled automatic restoration of your websites.
Subsequently, FortiWeb will only check to see if the files on the server have changed; it won’t download new
files each time. So, after the first sync, anti-defacement connections are made quickly.

DO NOT REPRINT
© FORTINET
Since most modern websites are not static HTML files, but are templates where content is injected from a
database, be aware that anti-defacement does not make a backup copy of your back-end databases.
Use FortiWeb to block SQL injection attacks, and follow best practices. Make sure you back up your database
regularly. If your database changes frequently, it can help to log transactions so that you can revert them if
necessary. If your web app data is very sensitive, such as, that used for banks or PeopleSoft installations, you
should also apply controls. Database security devices such as FortiDB can help.

DO NOT REPRINT
© FORTINET

DO NOT REPRINT
© FORTINET
Congratulations! You have successfully completed this lesson.

DO NOT REPRINT
© FORTINET
By mastering the objectives covered in this lesson, you learned how you can use FortiWeb features to
mitigate DoS attacks and prevent vandalism.

 Signature, Sanitization, and Auto Learning
DO NOT REPRINT
© FORTINET
In this lesson, you will learn how to use signatures from FortiGuard subscription services, create your own
custom signatures, and use auto learning to train FortiWeb on your web apps’ security needs.

DO NOT REPRINT
© FORTINET

DO NOT REPRINT
© FORTINET
By demonstrating competence in knowing and using quick start methods, you will be able to quickly configure
FortiWeb and get it set up in your network.

DO NOT REPRINT
© FORTINET
FortiWeb can send TCP reset signals and, depending on the violation and your FortiWeb’s operation mode,
may also be able to send HTTP return codes and error pages.
What methods does it use to determine whether a client’s request is an attack?
FortiWeb has many strategies to detect attacks. In some cases, you can use default settings, and adjust as
necessary. But in other cases, you need to tailor settings to each web app. Whenever an administrator
updates a web server or web application, the needs of that web server or application can change.
How can you configure FortiWeb most quickly?

DO NOT REPRINT
© FORTINET
This slide shows an overview of methods that you can use to configure FortiWeb quickly. Let’s take a look at
each of them.

DO NOT REPRINT
© FORTINET
Default settings and predefined settings are the easiest to use. If they’re not quite right, you can copy the
profile, adjust it, then change your policy to select your new profile.

DO NOT REPRINT
© FORTINET
If you want to do a dry run to see if a feature accidentally blocks normal traffic, you can either enable the
Monitor Mode option for a policy-wide effect, or you can select the Alert action for a specific feature that you
want to test.
If you test your FortiWeb configuration with typical traffic for one week and it doesn’t generate any accidental
attack logs, it’s usually safe to enable the feature without worrying that it will interfere with normal traffic.

DO NOT REPRINT
© FORTINET
One of the powerful but resource-intensive methods of traffic monitoring is to let FortiWeb study your traffic
and suggest appropriate settings. This is called auto learning.
To teach itself about your traffic, FortiWeb must scan every HTTP header, every input, and every cookie in
every page of each app’s normal traffic. As you can imagine, this takes considerable CPU power and RAM.
So, if you enable auto learning fully, on every policy, for every network interface, this can significantly impact
performance. It’s important to use auto learning wisely, especially if your FortiWeb is inline.
There are several ways that you can reduce or negate the impact of auto learning and keep performance at
an acceptable level. For example, you can run auto learning on only one policy at a time, or you can use it
while FortiWeb is in a one-arm, out-of-band topology and in offline mode, in an initial phase before you switch
to an inline, reverse proxy deployment.

DO NOT REPRINT
© FORTINET
This slide shows auto learning with the smallest possible performance impact: none.
Before deploying FortiWeb inline, FortiWeb is in offline mode, and attached to a switch’s traffic mirroring port.
Through its data capture port, FortiWeb listens and studies typical inputs, their sizes and data types, and the
server’s typical responses. After collecting data for at least a week–recommended time varies by your
application, usage patterns, and traffic volumes–FortiWeb can recommend safe constraints and attack
signatures. Then, you can generate initial protection profiles, switch the operation mode, and deploy FortiWeb
inline.

DO NOT REPRINT
© FORTINET
FortiWeb is studying what your HTTP traffic usually looks like: how long the headers are, which URLs there
are, and what the inputs’ data types are.

DO NOT REPRINT
© FORTINET
While auto learning, one of the things that FortiWeb usually studies is the web app’s inputs, such as:
• How many are there?
• What are their names?
• What data type should they accept? Are some formats illegal?
• How big a number, or how long a string?
One of the most common ways that attackers find zero-day exploits is by inserting inappropriate data in an
input–forms, hidden inputs, or cookies–to see if it breaks the application in a way that can be exploited. So
auto learning will compare normal users’ inputs to the data types that it knows. If it usually matches a specific
type, such as a postal code or IP address, then FortiWeb will recommend that you apply an input rule to reject
other, invalid types of inputs.

DO NOT REPRINT
© FORTINET
Obviously, if you’re under attack, it’s not a good time to begin auto learning.
Why?
Think about the data type learning that we just showed. FortiWeb is learning about what is normal input for
your web app. So you want to feed it lots of normal traffic.
If most traffic contains XSS attacks, for example, then FortiWeb could accidentally learn that those inputs
normally allow JavaScript. Then it will recommend disabling XSS signatures. That would be the opposite of
the configuration you want!

DO NOT REPRINT
© FORTINET
Another thing that auto learning studies is which web servers are being protected.
Each web server has specific configuration and administrative files, such as .conf files, that should not be
accessible from an Internet URL. FortiWeb auto learning will recommend access control to block public
network access to the URLs that apply to your specific web servers.

DO NOT REPRINT
© FORTINET
If you have an application or web server with unusual configuration files or administrative URLs, you can
always look to see whether it will match a predefined pattern. If it doesn’t, make a custom definition for your
suspicious URLs.
You can use the predefined regular expressions as an example.

DO NOT REPRINT
© FORTINET
In an HTTP request that uses the GET method, the URL and parameters are all together, on the same line,
with no spaces between them. So, how does auto learning find the URL, and differentiate it from each input
and its values?
By default, it uses standard cues to find them. A question mark (?) usually separates the URL from the inputs,
an equal sign (=) separates the input’s name from its value, and an ampersand (&) separates the input’s value
from the name of the next input.
What happens if the URL is dynamically generated, or if the separator characters are different? In that case,
you must specify where to find each piece. Otherwise, auto learning won’t function correctly.

DO NOT REPRINT
© FORTINET
The object named URL Replacer is what shows auto learning how to interpret the URL line to find the URL
and separate each input.
Because Java server pages and Outlook Web App 2003 often don’t use the standard URL format, there are
predefined objects for them. But you can configure your own, too. You can see examples in the
documentation. When you’ve defined a chain of URL replacers to interpret every non-standard part of the
URL into the standard format, group them together, in order, in an application policy, then select it in the auto-
learning profile.
Remember to clear the cache of auto-learning data first, if you need to restart the auto-learning period with
your new URL replacer.

DO NOT REPRINT
© FORTINET

DO NOT REPRINT
© FORTINET
Good job! You now know how to deploy and configure FortiWeb using quick start methods.
Now you will learn ways to fine-tune FortiWeb to your specific environment by generating signatures and rules
based on learned data.

DO NOT REPRINT
© FORTINET
By demonstrating competence in understanding auto learning, you will be able to use learned data to create a
configuration that is tailored to your web applications.

DO NOT REPRINT
© FORTINET
Auto learning will monitor for many attack types, and give you a head start in creating a configuration that is
tailored to your specific web applications. What is the result? When you’ve decided that it has analyzed
enough of your traffic, you use auto learning’s data to generate a protection profile. This also generates its
components for the relevant rules and attack signatures.
FortiWeb also offers a machine-learning function that enables it to automatically detect malicious web traffic.
After your FortiWeb has been monitoring normal usage for a while, look at the auto-learning report. Does it
look accurate, or did it incorrectly detect too many attacks? Did it miss any URLs that you know of? Did it
detect your web server type correctly?
When you click Generate Config, the profile that auto learning generates will be based on the data that it has
collected. So, if any estimated settings are incorrect, you can correct them here.
Remember to click on each URL in the tree on the left side of the window–not just the host name or the auto-
learning profile name–because each web page can have unique cookies and other inputs. The Overview,
Attacks, and Visits tabs are always visible. However, the tab for inputs only appears when you select a
specific URL. You may need to adjust the estimated data types for URLs, too.

DO NOT REPRINT
© FORTINET
If you click the Attacks tab, you will see how many requests matched attack signatures. It is in the Count and
Percentage columns.

DO NOT REPRINT
© FORTINET
When you verify the recommendations, if you want to choose a different setting, you will need to complete the
following steps:
• Change the setting in the Type column to Custom
• Change the setting in the Custom column:
• If you want to enable protection, select On
• If you want to disable protection, select Off
If you are enabling custom protection, in the Action column, select the action that you want FortiWeb to
perform when it detects a violation.
After you’ve verified or adjusted all settings, click Generate Config. Auto learning will generate all required
components.
There are some settings that are not studied by auto learning. For example, whitelisted objects is a global
setting, not policy specific. You should manually configure those after.

DO NOT REPRINT
© FORTINET
A protection profile is what you select in a server policy to indicate which scans FortiWeb performs. The
protection profile ties together many component scans. Signatures detect many types of known attacks–
similar to IPS on FortiGate–but FortiWeb analyzes many more things than simply malformed data. For
example, FortiWeb can analyze whether cookies are returned intact, and whether sessions are initiated from
the correct URL and pages accessed in a logical order. This means that FortiWeb can detect known attacks
with signatures, but it can also prevent many zero-day attacks.

DO NOT REPRINT
© FORTINET
In version 6.0, FortiWeb introduced machine learning that enables it to automatically detect malicious web
traffic. Machine learning can detect potential unknown zero-day attacks to provide real-time protection.
Machine learning is intended to replace auto learning; therefore, in FortiWeb version 6.0, by default, auto
learning is disabled. To enable auto learning, click System > Config > Feature Visibility > Auto Learn from
GUI.
Machine learning builds a mathematical model to detect abnormal traffic based on observations around URLs,
parameters, and HTTP methods of HTTP/HTTPS session passing to the web server.
FortiWeb employs two layers of machine learning to detect malicious attacks. The first layer uses the Hidden
Markov Model (HMM), monitors access to the application, and collects data to build a mathematical model
behind every parameter and HTTP method. After it finishes building the mathematical models, FortiWeb
verifies a request against the model to determine whether the request is an anomaly or not.
After the first layer of machine learning triggers a request as an anomaly, FortiWeb uses the second layer of
machine learning to verify whether it's a real attack or just an anomaly that should be ignored. To do so,
FortiWeb includes prebuilt trained threat models.

DO NOT REPRINT
© FORTINET
Pretrained models represent specific attack categories, such as SQL injection, cross-site scripting, and so on.
Each threat model is already trained, based on analysis of thousands of attack samples.
Threat models are continuously updated using the FortiWeb Security Service. When new attack types are
released, the FortiGuard team analyzes the new threats and retrains the relevant threat model. The new
threat model is then pushed to all customer installations, using a method that is similar to how signatures are
updated.

DO NOT REPRINT
© FORTINET

DO NOT REPRINT
© FORTINET
Good job! You now understand machine learning and how to generate auto-learning reports and modify
protection profiles.
Now, you will learn how to use input validation based on session cookies.

DO NOT REPRINT
© FORTINET
By demonstrating competence in input validation with reference to session cookies, you will be able to
describe and discuss HTTP header validation and HTTP protocol constraints.

DO NOT REPRINT
© FORTINET
HTTP is stateless. This means that each request is not correlated to any request before or after.
For simple web page views, this was enough. However, as web pages became dynamic and eventually
became software in their own right–that is, web applications–programmers needed some way for servers to
remember variables between each request.
For example, in a page that gradually loads more items as you scroll down, the web application must know
what items you have already viewed. If you like a Facebook post, Facebook must know what account you
used to log in, so that the like status is applied only when your account is accessing the page–not for
everyone. Web apps usually remember variables using sever-side sessions, session cookies that are stored
client-side, or both.

DO NOT REPRINT
© FORTINET
This slide shows an example HTTP transaction, showing how cookies are used in a JSP application.
1. First, the client initiates a session by requesting a page:

/login
2. The server replies. In the reply, the header contains Set-Cookie:, the name of a session cookie,
JSESSIONID, and its value. The value is a unique ID for this client’s session, and allows the server to
identify the client and correlate the next request with the first.
3. The client returns the unchanged cookie in its second request.
4. The server uses this ID to remember the settings that it may need to generate the next page in this client’s
session. Then, it replies.

DO NOT REPRINT
© FORTINET
Because the server is effectively storing some of its application data on an untrusted client, session cookies
are a risk. A malicious client could change the value of the session cookie; for example, they could replace the
session ID with a SQL query. In the next request that the client sends, the poisoned cookie would go with the
request to the server. If the web app does not check the cookie’s value for SQL commands before passing the
cookie’s value into a database query, then the attacker could run any database commands that they want.

DO NOT REPRINT
© FORTINET
FortiWeb’s cookie poisoning detection blocks this kind of abuse. When cookie poisoning detection is enabled,
FortiWeb remembers each cookie, and associates it with FortiWeb’s session management cookie. If the next
request’s cookies don’t match the original cookie sent by the server, then FortiWeb knows that the client has
changed the cookie. Normally, innocent clients don’t change their cookies.

DO NOT REPRINT
© FORTINET
On this slide, you can see an example of a session cookie being present and FortiWeb, inline, scanning for
cookie poisoning. After the client logs in with HTTP authentication, the web app creates a session ID. Then,
as the client continues to use the web app, the web app sets a new cookie, to remember that the client has
previously authenticated, and binds the authentication status to the session ID. Before the client receives the
server’s reply, FortiWeb reads and remembers the values of all cookies. If the server changes the cookie’s
value, FortiWeb updates its cache. After the first request, every time, FortiWeb validates that the client hasn’t
changed the cookies.

DO NOT REPRINT
© FORTINET

DO NOT REPRINT
© FORTINET
Good job! You now know how to implement input validation based on session cookies.
Now, you will learn how to implement input validation based on headers and body.

DO NOT REPRINT
© FORTINET
Now, you will learn input validation in reference to HTTP header and body.

DO NOT REPRINT
© FORTINET
HTTP constraints allow you to control the number, type, and length of many HTTP headers, which are also
inputs. This prevents unexpected inputs that a malicious client could craft to try to compromise your server.
The limits can vary according to your server’s software, and its hardware. For example, if a server has limited
RAM, then it’s potentially easier to overload or crash with an excessive number of headers, since parsing the
headers and storing them in buffers requires RAM.

DO NOT REPRINT
© FORTINET
Since requests that use the POST method can have very large bodies, if your web app does not accept movie
or music uploads, for example, then it can be useful to reduce the maximum length of the HTTP body.

DO NOT REPRINT
© FORTINET

DO NOT REPRINT
© FORTINET
Excellent! You now know how to implement input validation based on headers and body.
In the next section you will look at input validation based on forms.

DO NOT REPRINT
© FORTINET
By demonstrating competence in configuring and defining HTML forms, you will be able to use input from
these forms to validate your network traffic.

DO NOT REPRINT
© FORTINET
FortiWeb can apply reasonable limits to inputs from HTML forms, such as requiring that user names contain
email addresses.
Technically, you can use parameter validation rules regardless of the HTML input type: both visible, user-
completed HTML forms, and hidden inputs. In the HTTP, they are transmitted the same way. Since hidden
inputs are not rendered by the browser as buttons or fields, you may not realize they exist. It often takes more
time to find all of them. That’s why FortiWeb has hidden input rules. Its GUI helps you to quickly configure this
specific type of parameter by scanning the URL’s HTML page for hidden inputs.

DO NOT REPRINT
© FORTINET
With FortiWeb, you can also specify that excessively large files of the wrong type can’t be uploaded.

DO NOT REPRINT
© FORTINET
When restricting uploads, you can also engage FortiGuard antivirus.

DO NOT REPRINT
© FORTINET
FortiGate-style FortiGuard Antivirus signatures are not the only type of signatures that FortiWeb uses.
FortiGuard antivirus is an engine for analyzing binary file uploads; it’s enabled by the Trojans option in
Signatures. For non-binary web app exploits, FortiGuard security provides an extensive set of regular
expressions that match attack string patterns.

DO NOT REPRINT
© FORTINET
Because they are regular expressions, you can also customize or write your own attack signatures. If you do
this, use PCRE syntax.

DO NOT REPRINT
© FORTINET
When configuring which signatures to use, choosing the Period Block setting instead of the Alert & Deny
setting is an important performance tweak. Select it for DoS or persistent attacks to reduce FortiWeb’s CPU
usage and to buy time for forensic analysis.

DO NOT REPRINT
© FORTINET
Signatures detect many types of attacks. Many correspond to the OWASP top 10, which PCI specifically
requires that you block.
One type of attack is called cross-site scripting (XSS). The root cause of an XSS attack is that the web
application does not sanitize its inputs, rejecting JavaScript. As a result, it stores the XSS attack in its
database and, whenever other clients request the page that reuses that data, the JavaScript is embedded in
the page.
JavaScript can do many things with a page, including rewriting the whole page and making its own requests.
This is the basic mechanism of AJAX apps. In this case, XSS causes innocent clients to transmit to a different
server that is controlled by the attacker. This could, for example, transmit credit card information or passwords
from a form to the attacker.

DO NOT REPRINT
© FORTINET
Another very common type of attack is SQL injection. Similar to an XSS attack, its root cause is that the web
app does not sanitize input. If the attacker enters a SQL query into an input such as an HTML form, the web
app simply accepts it, and passes it along to the database engine, which accidentally runs the query.
The SQL language can do anything to the data. For example, it can download the table of users so that the
attacker can run a password cracker. A query could add new entries for new administrator logins, or modify
logins, blocking administrators from logging in to your CMS.

DO NOT REPRINT
© FORTINET
Some signatures apply to most web apps–they are not app-specific. XSS and SQL injection signatures belong
to this category.
Popular web apps such as Drupal and WordPress are well known. So, FortiWeb has predefined signatures for
their known vulnerabilities, and FortiGuard Service updates can provide ongoing updates, as new
vulnerabilities are discovered. But, if you need to protect an in-house, custom web app, you can also write
your own app-specific custom signatures.
If a predefined signature causes a false positive, edit the signature policy. Click Signature Details, and create
exceptions or disable those individual signatures. You don’t need to disable the entire category.

DO NOT REPRINT
© FORTINET
The advanced mode for editing the signature policy offers full flexibility. You can disable a signature in the
current policy only, or in all policies. You can also disable it for only a specific domain name, or URL, or both
(that is, make an exception to the rule). The exceptions also support PCRE regular expressions so you can
match an entire group of URLs if you need to.
Enabling or disabling individual signatures is your primary tool for eliminating false positives.
Alternatively, if you’re viewing the attack log and it looks like an innocent request accidentally matched the
attack signature, you can also create exceptions or disable signatures while viewing the log.
1. Click a log entry to view its details.
2. In the log entry, click the link to make an exception or disable the signature.

DO NOT REPRINT
© FORTINET
Regardless of the reason why a request is detected as an attack, you can usually customize FortiWeb’s error
message.

DO NOT REPRINT
© FORTINET

DO NOT REPRINT
© FORTINET
Good job! You now know how to implement input validation based on forms.
Now you will learn how to mitigate state-based attacks by configuring the start page, session initiation page,
page access rules, and allowed page order.

DO NOT REPRINT
© FORTINET
By demonstrating competence in configuring the start page, session initiation page, page access rules, and
allowed page order, you will be able to mitigate state-based attacks in your network.

DO NOT REPRINT
© FORTINET
Not all attacks can be detected by regular expressions matching an input string. The exploits that are hardest
to find and protect against are mechanistic. They exploit how the web app allows transitions from one page to
the next, that are not logically valid.
One major category of mechanistic attacks involves how sessions are initiated. If a shopping cart must be
associated with an existing session, a file upload must be associated with a previous login, or if there’s any
other correlation of this page with previous pages, then the web app must validate that:
• The session is not null
• The session was created by that client IP or browser
• The session was created by visiting a URL where sessions normally begin, such as a login page or
advertising campaign URL
Otherwise, the attacker can exploit the app in many ways. Session hijacking is one way.

DO NOT REPRINT
© FORTINET
Unless you’ve used auto learning, the session initiation page can be difficult to configure correctly. To do so,
you must understand the web app well. Instead of selecting Period Block, Send 403 Forbidden, or Alert &
Deny from the Action drop-down list, it is usually best to select Redirect, to redirect the client to the correct
page for session initiation. Since a web app can have multiple valid session initiation pages, the default setting
indicates the target for the Redirect action.

DO NOT REPRINT
© FORTINET
Many other mechanistic attacks exploit page flow after the session is initiated. Page access rules enforce
valid page order. You shouldn’t, for example, be able to place an order for a TV unless you’ve submitted
payment!
Page access rules can’t completely prevent all permutations of CSRF attacks. Some require too much RAM
to prevent. A solution could become a potential performance bottleneck or opportunity for DoS attacks. This is
why vulnerability scans, IP reputation, and other features are still important; however, page order rules can
prevent many of these attacks.

DO NOT REPRINT
© FORTINET
This slide shows you how to configure a page order rule for the scenario that you considered previously.
Notice that you don’t have to input all pages–only ones where the order between two pages must be enforced.
You can specify that the rule applies only to specific virtual hosts and specific URLs. This avoids false
positives and wasted resources, improving performance, since FortiWeb only needs to remember session
page order for those specific combinations.

DO NOT REPRINT
© FORTINET

DO NOT REPRINT
© FORTINET

DO NOT REPRINT
© FORTINET
By mastering the objectives covered in this lesson, you learned how to use strategies to quickly deploy
FortiWeb and use inputs from various sources to mitigate attacks on your network.

 SSL/TLS
DO NOT REPRINT
© FORTINET
In this lesson, you will learn how to use encrypted HTTP transactions. With HTTPS, login credentials and
other sensitive data aren’t compromised while they’re in transit.

 SSL/TLS
DO NOT REPRINT
© FORTINET

 SSL/TLS
DO NOT REPRINT
© FORTINET
By demonstrating competence in knowing when to use HTTPS and configuring SSL offloading and inspection,
you will be able to use them in your network.

 SSL/TLS
DO NOT REPRINT
© FORTINET
Before, HTTPS was mostly used for online banking, e-commerce, and government web sites. Users needed
privacy and confidence in the site’s authenticity.
Since the leaks in 2013 and later by Edward Snowden, many of the most popular content web sites from
Twitter and Facebook, Tumblr and 500px.com, to Gmail, Google’s search engine, and YouTube have all
switched to HTTPS. Why?
Even seemingly harmless location check-ins and vacation photos can be exploited. If you’re on vacation in
Bali, obviously you’re not home to prevent theft. And privacy laws that govern email have not evolved to cover
social media, leaving people vulnerable to unscrupulous employers and free Wi-Fi. People that prefer privacy
are shifting to HTTPS. This trustworthiness factor is now reflected in Google search rankings. HTTPS sites
have a slightly higher ranking.
There’s a surprising side-effect. As a result of the more computationally expensive handshake and encryption,
it is also more difficult to brute force HTTPS site login page.

 SSL/TLS
DO NOT REPRINT
© FORTINET
Many of the top 200 web sites, according to Alexa, have now changed to HTTPS, but what about the millions
of other web sites on the Internet?
This slide shows statistics for the top ~140,000 sites as of March 2nd, 2019. In this sample, 52 sites were still
vulnerable to Heartbleed, an SSL vulnerability over one year old. 2.8% used weak cipher strengths less than
128 bits.
The good news is that FortiWeb has tools that offer HTTPS, and help you implement it securely for all
protected web sites.

 SSL/TLS
DO NOT REPRINT
© FORTINET
When you configure HTTPS on FortiWeb, you are usually configuring policies, not the HTTPS administrative
GUI. Policies govern traffic travelling through FortiWeb, not to it.
In policies, FortiWeb supports HTTPS. It can be either:

• An SSL reverse proxy, which terminates the SSL session and then (usually) forwards plain HTTP to
backend servers.
• An SSL inspector, which does not terminate the SSL session. Instead, it decrypts a copy of the traffic to
scan it for viruses and other security violations. It forwards the original, still-encrypted packet to the
backend web servers.
For both, you must upload the web site’s certificate and private key, and then specify it in the policy. This
allows FortiWeb to decrypt the HTTPS traffic and, in the case of SSL offloading, to offer HTTPS service to
clients.

 SSL/TLS
DO NOT REPRINT
© FORTINET
The differences between SSL inspection and SSL offloading are explained on this slide.
• SSL inspection puts the certificate and private key on both FortiWeb and the web servers. However,
FortiWeb is not an endpoint for the SSL session; it’s one continuous session, from the client to the servers.
Clients negotiate with the server, not with FortiWeb. As long as the traffic is not an attack, FortiWeb allows
the packets to continue to their final destination.
• SSL offloading only puts the certificate and private key on FortiWeb; clients negotiate the SSL session with
FortiWeb, not the web servers. This reduces system load on the web servers. Since the traffic is decrypted
before FortiWeb forwards it, FortiWeb can also scan traffic in this mode.
There is one more style, not shown here. Technically, you can inspect SSL or TLS if FortiWeb does terminate
the SSL session. But, it must make a second SSL session to the protected servers. This is not fully
transparent. FortiWeb may need its own certificate so that it can authenticate itself to servers. However,
FortiWeb doesn’t save system resources on the protected servers, so it’s not technically SSL offloading either.

 SSL/TLS
DO NOT REPRINT
© FORTINET
This slide lists some of the main differences between SSL inspection and SSL offloading.
Remember, despite the name, both do enable FortiWeb to inspect HTTPS traffic.

 SSL/TLS
DO NOT REPRINT
© FORTINET
Since reverse proxy is the most popular operation mode, usually you will be configuring an SSL proxy. It may
be SSL offloading, or, after inspection, may make a second HTTPS session to the backend servers, so that
data in transit is always secure. These are the configuration steps:
1. Get a signed certificate. If you’re an enterprise whose computers all trust your active directory or other CA
server, this could be your own private CA. Otherwise, it should be a commercial root CA, so that all
browsers will trust your CA-signed certificate.
2. If an intermediate CA signs it, be sure that browsers can link it to a trusted root. Otherwise, include the
signing chain in the bottom of the certificate, or as intermediate certificates on FortiWeb.
3. Upload both the signed certificate and its associated private key in the local certificates menu on
FortiWeb.
4. PKI authentication is optional. If you want FortiWeb to offer it so that clients, such as iPhones, can log in
by showing their personal certificate instead of typing a password, upload those CA certificates and CRL
or the address of an OCSP server. This way FortiWeb will know if any certificates have been revoked.
5. Finally, select your certificate and, if applicable, certificate revocation and validation rules, in the policy.

 SSL/TLS
DO NOT REPRINT
© FORTINET
Let’s look at how to configure SSL/TLS offloading on FortiWeb.
In the simplest case, you need to import the PEM file or .cert and .key file. Then, in the policy, select the
predefined HTTPS service, and your certificate. That’s it!

 SSL/TLS
DO NOT REPRINT
© FORTINET
If you’re doing SSL inspection in the other operating modes, then, for each server in your server pool, you
must also enable the SSL option and define its HTTPS listening port.

 SSL/TLS
DO NOT REPRINT
© FORTINET
If you’re using transparent mode, your backend web servers must be configured to offer HTTPS. This may be
different from reverse proxy–SSL offloading means that the backend server only needs to offer plain HTTP.
So while transparent mode doesn’t require any server-side changes, reverse proxy might.
For better security, you might still want to audit your servers’ HTTPS support. Make sure that patches are
applied, and that TLS-level compression is disabled. Also disable any ciphers that FortiWeb doesn’t support,
and, therefore can’t inspect.

 SSL/TLS
DO NOT REPRINT
© FORTINET
If you want best performance, you should set up FortiWeb for SSL offloading. However, in some cases, such
as compliance, where sensitive data must always be encrypted while in transit, you may need a reverse proxy
FortiWeb to re-encrypt before forwarding data to your web servers. To do this, you’ll enable the SSL option for
each entry in the server pool.
However, because FortiWeb is acting as a client to your web servers in this second session, you should also
upload the certificate of the CA that signed their server certificates. That way, FortiWeb can validate your
servers’ certificates.
If your web servers require that FortiWeb use PKI authentication to authenticate itself as a client, this is also
where you specify which certificate FortiWeb will present. Again, you’ll upload this certificate in the local
menu, but this time, its purpose will be different. FortiWeb will present it when it is a client, not a server.

 SSL/TLS
DO NOT REPRINT
© FORTINET

 SSL/TLS
DO NOT REPRINT
© FORTINET
Good job! You are now familiar with HTTPS basics.
Now, you will learn about SSL/TLS protocols and ciphers.

 SSL/TLS
DO NOT REPRINT
© FORTINET
By demonstrating competence in understanding SSL/TLS protocols and ciphers, you will be able to use them
in your network.

 SSL/TLS
DO NOT REPRINT
© FORTINET
Enabling HTTPS does not automatically make your web site fully secure. Attack signatures and mechanism
protections that deal with security once the packet is received are covered in another lesson.
Even in transit, HTTPS is not automatically fully secure. SSL and TLS do have vulnerabilities, so it’s important
that you configure HTTPS on FortiWeb as securely as you can.
This is a vulnerability, seen in late 2014, was named POODLE because it exploited padding as an oracle that
caused patterns in encrypted packets. These patterns made a crypto-analysis attack possible. Due to this
being a vulnerability in an implementation of options for older protocols, all servers that supported SSL 2.0
and some that supported SSL 3.0, were vulnerable.

 SSL/TLS
DO NOT REPRINT
© FORTINET
What should these servers have done? First, don’t use old SSL protocol versions. Use TLS 1.1 or 1.2, if
possible.

 SSL/TLS
DO NOT REPRINT
© FORTINET
TLS 1.2 was initially slow to be adopted, but is now a reasonable choice. The Heartbleed SSL vulnerability
helped to spur its adoption. Since then, other vulnerabilities in old SSL versions have increased the incentive
to upgrade.

 SSL/TLS
DO NOT REPRINT
© FORTINET
After you choose which SSL or TLS versions that FortiWeb will offer to clients, the next factor you should
consider is which cipher suites.
Key sizes that are 128 bits or lower are considered weak. Hardware is now fast enough to decrypt them with
speed. But, you should also look at the encryption and checksum mechanisms, plus renegotiation and
rekeying, if applicable.
Here’s one reason. RC4 was initially championed as a solution to the BEAST attack. It allowed servers to
continue supporting old clients that needed SSL 3.0 or TLS 1.0. But in the end, RC4 is a mitigation at best. It
is still stronger than the ciphers that are vulnerable to BEAST. But it does have its own weaknesses. So it’s
not as good as disabling old SSL and TLS protocols.
FortiWeb gives you full control over this, so you can support older clients, if you need to, without becoming
vulnerable to the BEAST attack.

 SSL/TLS
DO NOT REPRINT
© FORTINET
Weak encryption and checksums, including so-called export-grade encryption, are now disabled by default on
many browsers. So reasons to use old, weak encryption are decreasing.

 SSL/TLS
DO NOT REPRINT
© FORTINET
Now that you’re aware of some ways to make HTTPS stronger, how can you see what is being used? Client
and server (or, for offloading, FortiWeb) will negotiate the protocol and cipher suites that they both support.
On the client side, in Firefox and Chrome browsers, you can see the negotiation results. Look for the padlock
icon in Firefox’s URL bar, and click it.

 SSL/TLS
DO NOT REPRINT
© FORTINET
In Google Chrome, you also click the padlock to see which protocol and ciphers were negotiated.

 SSL/TLS
DO NOT REPRINT
© FORTINET
Unfortunately, there is no easy way to verify client connections to Internet Explorer. However, there are still
ways that you can test for robust client support. This is one way to test: a Python script called sslyze. As you
can see from the slide, the script checks for several vulnerabilities, such as Heartbleed and insecure
renegotiation.

 SSL/TLS
DO NOT REPRINT
© FORTINET
The sslyze script also checks for certificate validation errors, and which protocols and cipher suites that the
server (or FortiWeb) supports. The example in this slides shows that FortiWeb has been configured for
somewhat higher security–it is offering TLS 1.2 with 256-bit AES, RSA keys, and SHA-384 checksums. But its
certificate for www.example.com is self-signed, so browsers will show error messages. This
misconfiguration should be corrected before being used on a production network.

 SSL/TLS
DO NOT REPRINT
© FORTINET
SSL scans like this can be very useful to prepare for security audits, as well as when you need to analyze
client compatibility, because it can quickly check all of your configurations.

 SSL/TLS
DO NOT REPRINT
© FORTINET

 SSL/TLS
DO NOT REPRINT
© FORTINET
Good job! You now have an understanding of SSL/TLS protocols and ciphers.
Now, you will learn about X.509 certificates.

 SSL/TLS
DO NOT REPRINT
© FORTINET
By demonstrating competence in understanding certificates, you will be able use them effectively in your
network.

 SSL/TLS
DO NOT REPRINT
© FORTINET
Aside from protocol versions and cipher suites, the other major component of HTTPS is X.509 certificates.
FortiWeb uses several kinds of X.509 certificates. It uses its own, built-in, default, self-signed server certificate
when you open your browser and connect to the GUI. FortiWeb may also need its own certificate, if you want
it to use PKI authentication as a client to your backend severs.

 SSL/TLS
DO NOT REPRINT
© FORTINET
In most cases, since FortiWeb is a proxy, it will be acting as an agent for your websites. So, it will present the
websites’ certificates when a client connects. Since FortiWeb needs the private key to be able to encrypt and
decrypt traffic, be sure to store your FortiWeb backups in a secure location. Like all backups of your private
key, physical access to your private key should be tightly restricted to a few authorized individuals, and
backups should be password encrypted.

 SSL/TLS
DO NOT REPRINT
© FORTINET
What other certificates do you need to upload to FortiWeb?
CA certificates are important for certificate validation. FortiWeb must validate certificates in two cases:
• When a client sends a personal certificate for PKI authentication
• When FortiWeb connects to an OCSP, LDAPS, backend HTTPS, or secure email server

 SSL/TLS
DO NOT REPRINT
© FORTINET
Like web browsers, when FortiWeb evaluates a certificate, it will examine the same factors:
• Does the IP address or host name in the certificate match exactly?
• Is it currently valid, not expired, or pending a future time or date?
• Is it signed by a CA that I trust?
• If X.509 extensions exist, such as restricting certificate usage to signing other certificates or as server
authentication, is the certificate being used in a valid context?

 SSL/TLS
DO NOT REPRINT
© FORTINET
For CA signatures to be truly trustworthy, it’s important that an attacker can’t use collision attacks. Collision
attacks allow the attackers to mimic the CA’s fingerprint, so it’s better to use certificates with SHA-256 or
greater.
FortiWeb now supports many new certificate-related features, including multi-domain certificates, SNI, and
URL-specific contexts for requiring client PKI authentication. Let’s take a look at what this enhanced support
allows you to do.

 SSL/TLS
DO NOT REPRINT
© FORTINET
Multidomain certificates mean you don’t have to use a wildcard certificate when multiple host names are being
protected by the same FortiWeb policy. Wildcard certificates are considered by Open Web Application
Security Project (OWASP) to be less secure. Instead, you can use a SAN certificate extension field to list
specific host names that are under your control.

 SSL/TLS
DO NOT REPRINT
© FORTINET
SNI enables a FortiWeb virtual server to offer different certificates, depending on the host name requested by
the client. Like many other objects on FortiWeb, you must configure an SNI list, then select it in the server
policy.

 SSL/TLS
DO NOT REPRINT
© FORTINET

 SSL/TLS
DO NOT REPRINT
© FORTINET
Good job! You now know more about X.509 certificates.
Now, you will learn about client PKI certificates.

 SSL/TLS
DO NOT REPRINT
© FORTINET
By demonstrating competence in understanding and configuring PKI certificates, you will be able use them
effectively in your network.

 SSL/TLS
DO NOT REPRINT
© FORTINET
Passwords have many problems. They are hard to remember, and usually easy to crack. But they are also
hard to reliably type on touch-screen devices.
If most of your web site’s users (or a critical segment of them) use touch screens, and if they are managed by
your organization, then it may be both more user-friendly and more secure to authenticate them using
personal certificates instead. For example, the administrator could use Apple’s iPhone profile manager to
install both your enterprise’s CA certificate and the personal certificate on the phone. Then, every time that
person accessed the web site, they would be securely and effortlessly authenticated.
During an HTTPS handshake, the server (or in the case of SSL offloading, FortiWeb) first presents its
certificate. The client validates it. However, the client can, optionally, present their own certificate for the
server to validate. This is why it’s also called mutual authentication or bilateral authentication.
FortiWeb can also authenticate as a client. If it uses HTTPS to connect to the backend web servers, it can
present its own certificate to authenticate as a client.

 SSL/TLS
DO NOT REPRINT
© FORTINET
In order for client PKI authentication to work, you must upload the certificate of the CA that signed the
personal certificates. By default, FortiWeb doesn’t trust any CAs. So if you don’t upload any, FortiWeb won’t
validate any clients’ certificates. You’ll also need to configure a certificate validation rule on FortiWeb.

 SSL/TLS
DO NOT REPRINT
© FORTINET
If you’re configuring mutual authentication for the SSL session on the front end, you must do it on both the
client browser and FortiWeb.

 SSL/TLS
DO NOT REPRINT
© FORTINET
If you’re configuring mutual authentication with the protected web servers behind FortiWeb, they may already
be installed with a store of trusted CA certificates. In that case, you’ll only need to configure FortiWeb.

 SSL/TLS
DO NOT REPRINT
© FORTINET

 SSL/TLS
DO NOT REPRINT
© FORTINET
Good job! You now know how to implement and use client PKI certificates on FortiWeb.
Now, you will learn what to do if a user types HTTP instead of HTTPS.

 SSL/TLS
DO NOT REPRINT
© FORTINET
By demonstrating competence in configuring HTTP to HTTPS redirection, you will be able to direct users who
make incorrect entries in their browsers.

 SSL/TLS
DO NOT REPRINT
© FORTINET
Regardless of whether your servers or FortiWeb offer HTTPS, there is no way that you can prevent a client
from typing http:// in to their browser. And it’s a common habit for most people. Unless they’re technical,
they may not know the difference.
How can you protect these clients?
The most common method is to simply use HTTP’s redirect mechanisms to send clients to the secure site.
But it’s not ideal. SSL stripping attacks are possible.

 SSL/TLS
DO NOT REPRINT
© FORTINET
It’s better to enforce strict transport security. If you enable it, FortiWeb can add an HSTS header so that in the
future, the browser will automatically convert HTTP addresses to their HTTPS equivalent, before making the
request. It will also suppress dialog boxes that allow users to ignore certificate warnings, a common source of
so-called click-through insecurity.

 SSL/TLS
DO NOT REPRINT
© FORTINET
Here we see a reply from a web server where FortiWeb has injected the Strict-Transport-Security:
header.

 SSL/TLS
DO NOT REPRINT
© FORTINET
After you’ve configured your HTTPS service, don’t forget to add authentication and access control. After all,
HTTPS is only about security in transport. Once a request reaches servers, you need to enforce security
there, too!

 SSL/TLS
DO NOT REPRINT
© FORTINET

 SSL/TLS
DO NOT REPRINT
© FORTINET

 SSL/TLS
DO NOT REPRINT
© FORTINET
By mastering the objectives covered in this lesson, you have learned how to use encrypted HTTP transaction
to protect login credentials and other sensitive data that travels through your network.

 Authentication and Access Control
DO NOT REPRINT
© FORTINET
In this lesson, you will learn how to add authentication for web applications that don’t have it—or where you
want to unify the login across multiple applications. You’ll also learn how to secure the HTTP transactions so
that your users’ login credentials aren’t compromised.

DO NOT REPRINT
© FORTINET

DO NOT REPRINT
© FORTINET
By demonstrating competence in understanding access control methods, you will be able to ensure that user
information is protected during authentication.

DO NOT REPRINT
© FORTINET
When you authenticate users, the first thing you should always do is make sure that user names and
passwords are encrypted in transit. Otherwise, man-in-the-middle (MiTM) attacks and even attackers in the
same Wi-Fi range can easily see user login information.
Why do you need HTTPS?
For some web apps, adding HTTPS is not as critical. Windows New Technology LAN Manager (NTLM)
authentication for HTTP does apply some encryption, and some applications use HTML forms that encrypt
and checksum inputs at an individual level. But, usually, as a best practice, you should use HTTPS. It not only
encrypts and tamper-proofs logins in transit, but also binds sessions to the client IP. This better secures the
session. The protection is stronger.
So if your web app doesn’t use HTTPS already, use a reverse proxy FortiWeb to apply it. Once you have a
secure channel, FortiWeb can help you control which IPs have access to each URL, before they even attempt
to authenticate.
At the most basic level, you can manually blacklist specific IP addresses and whitelist others.
Unlisted IPs are in a grey zone: they will neither be allowed or denied by this feature. Instead, they’ll be
subject to all of the other scans that you have configured. In other words, the action assigned to these IPs is
Continue to Other Scans.
If you have a web app that should be accessible by only a specified group of people, such as top
management levels logging in from a secure, private network location, using the Continue to Other Scans
action may be enough.

DO NOT REPRINT
© FORTINET
It is often impractical to manually maintain source IPs in blacklists if you have a publicly available site on the
Internet. So, what other features does FortiWeb have to automatically restrict client IPs?
A much more powerful way of blacklisting is the Geo IP feature. With it, you can blacklist IPs in all regions that
shouldn’t be accessing your web site. For example, if you sell e-books where the copyright agreement allows
publishing only in France, you can ignore traffic from everywhere else.
FortiGuard IP reputation can help you to effortlessly deny access to IPs of unknown reputation due to
anonymous proxies, and to block the IP addresses of known botnets and hackers.

DO NOT REPRINT
© FORTINET
If you need to control access based on the request’s HTTP layer–its URL and host name–then FortiWeb can
do that. In previous FortiWeb versions, URL access rules could match by only the domain name and URL, but
now FortiWeb can also match by the client’s source IP.
For example, you might want to restrict your phpMyAdmin management GUI so that only web site
administrators on the private network can access it. To do this, you could create a URL access rule that
blocks access to all phpMyAdmin URLs, unless they are accessed from a management subnet.

DO NOT REPRINT
© FORTINET
If you need more sophisticated HTTP-layer control of URL access rules, FortiWeb can do that. In the GUI,
they’re called Custom Access Rules. These rules have extensive additional HTTP-layer criteria that you can
use to create fine-grained access control.

DO NOT REPRINT
© FORTINET
In this slide, you can see a rule that restricts URL access to one source IP and checks the rate limit and self-
reported User-Agent: string. This rule allows access by only that specific client software.

DO NOT REPRINT
© FORTINET

DO NOT REPRINT
© FORTINET
Good job! You now understand access control method basics.
Now, you will learn about the details of authentication.

DO NOT REPRINT
© FORTINET
By demonstrating competence in understanding and configuring authentication, you will be able to handle the
details of logins in your network.

DO NOT REPRINT
© FORTINET
After you’ve determined which clients should be allowed to attempt to log in, you need to handle the details of
the login itself. If your web application doesn’t offer authentication natively, FortiWeb can add it.
Here’s a tip: FortiWeb can also strengthen your app’s existing authentication. Configure FortiWeb input rules
on password strength for URLs that change passwords, and you can prevent clients from setting weak
passwords that hackers can easily guess or brute force.
If your web app doesn’t have its own authentication, FortiWeb authentication rules are a simple way to add it.
Usually, deployments have an existing database of user accounts, such as a Microsoft Active Directory tree. If
so, instead of defining all user accounts locally, you can configure FortiWeb to query the authentication server
instead.
Even if your web app does have authentication, you may still want to use FortiWeb. FortiWeb can delegate
the credentials to the back-end web app, yet still cache authenticated sessions locally so that you can apply
single sign-on.

DO NOT REPRINT
© FORTINET
When you add an authentication or site publishing rule, this is what the HTTP transaction looks like.
Notice that the first reply is actually a 401 error code, with a header that indicates which authentication the
client should submit. This triggers the browser’s HTTP authentication dialog. When the user submits their user
name and password, the browser resends the initial request, this time with their authentication details in an
HTTP header. Next, FortiWeb forwards the request (with the HTTP authentication header removed) to the
back-end web server. Since the web server is misconfigured, its reply includes an information disclosure: the
associated OS and Apache version. So, before it forwards the reply to the client, FortiWeb’s information
disclosure signature removes that header, too.
The Authorization: header may look encrypted, but it’s not. It’s only encoded in base64. So use caution:
only use basic or digest authentication if the passwords are protected by SSL/TLS!

DO NOT REPRINT
© FORTINET
Authentication rules are very simple. If you need more complex features, such as support for single sign-on,
logoff URLs, 2-factor authentication, and Kerberos delegation, use site publishing rules instead.

DO NOT REPRINT
© FORTINET
When configuring any kind of authentication, what’s the first thing you need to do? Configure user accounts.
With FortiWeb, you can configure them locally. But, if you have many users, local configuration isn’t the most
practical way to define accounts.

DO NOT REPRINT
© FORTINET
If you have many users, you’ll want to configure a query. Whenever someone tries to log in, FortiWeb will
contact the query server, and ask if the credentials are valid.
In this example, FortiWeb is querying a Microsoft Active Directory server using the Lightweight Directory
Access Protocol over SSL (LDAPS) protocol. Directory tree structures vary by the schema, so if it was IBM
Lotus Notes or another application, the common name identifier, distinguished names, and query strings
would be different.

DO NOT REPRINT
© FORTINET
Once your queries, locally-defined user accounts, or both exist, group them in to a user group.

DO NOT REPRINT
© FORTINET
Reference the user group when you define an authentication rule. Authentication rules define who has access
to each URL. Note that some HTTP authentication styles like NTLM are not supported by all query types.

DO NOT REPRINT
© FORTINET
Next, group your authentication rules in an authentication policy. This creates a set of authentication rules, but
it also specifies whether FortiWeb will log login failures, what the connection timeout is, and also how long it
will keep idle, authenticated HTTP sessions in the cache.
Fast cache timeouts help to prevent unattended computers from becoming possible attack vectors, and
reduce RAM usage on FortiWeb. Using fast cache timeouts can improve both performance and security. Be
careful not to make them too small, however. If there are some web applications where people must fill out
long forms, such as contact information or tax data, the protected web app won’t be user-friendly; their
authentication session will time out between each page submission.

DO NOT REPRINT
© FORTINET
When configuration is complete, this is the authentication dialog that FortiWeb will open in users’ browsers.
Since it’s based on only an HTTP header, there’s no way to control style, such as including company logos or
using custom colors. It uses the default style of the browser windows.
Basic HTTP authentication isn’t enough for some applications. What if you use Kerberos, or have multiple
web applications and want single sign-on (SSO) between them?

DO NOT REPRINT
© FORTINET
Site publishing is the newer, more sophisticated authentication gateway method. For Microsoft TMG
replacements, this is the method of choice.
Notice that it supports client certificates and HTML form-based authentication, not just HTTP authentication. It
also supports delegation, agentless SSO, and 2-factor authentication.
If you’re using a RADIUS authentication query, site publishing also supports RSA SecurID in addition to, or
instead of, a password.
Both LDAP and RADIUS queries support plain HTTP and Kerberos delegation. Kerberos delegation can be
integrated with PKI client certificates. The certificate delivers a user name and public key, but also is a
selector for the key tab. To use it, select Client Certificate Authentication and Kerberos Constrained
Delegation, then specify:
• Which previously uploaded key tab file to use to create and validate service tickets
• Where in the certificate FortiWeb should look for the field that contains the user name

DO NOT REPRINT
© FORTINET
One important advantage of site publishing over simple authentication rules is FortiWeb’s ability to forward
credentials to the web app after it verifies the login. Many modern web applications have their own
authentication dialogs, so if you want to use FortiWeb’s agentless SSO, then FortiWeb needs the credentials,
but so do the protected web apps.
If you’re using Kerberos, these won’t be the same credentials that the user submitted. Instead, they will be
tokens encrypted with a private key that you load onto FortiWeb.

DO NOT REPRINT
© FORTINET
When configuration is complete, the dialog that site publishing opens in users’ browsers can be either the
HTTP browser pane that you saw previously, or an HTML web page with a form, like the one shown on this
slide. Alternatively, FortiWeb will invisibly authenticate the user by validating their personal certificate.
If FortiWeb presents a dialog, its appearance varies by the type of authentication tokens that users must
enter:
• Normal user name and password
• User name and RSA SecurID passcode
• User name and password then 2-factor authentication token, such as RSA SecurID

DO NOT REPRINT
© FORTINET
For universities, enterprises, and other large organizations, you may have multiple web apps that you are
protecting, and want to reduce the number of logins that a student or staff must make. However, you may not
have administrative privileges on the web servers, so Fortinet SSO would not be an option. In this case, you
can enable the agentless SSO feature on FortiWeb.

DO NOT REPRINT
© FORTINET
When the client authenticates with any web site in the SSO domain, FortiWeb caches the credentials in an
authentication session. As long as the user continues to use web apps in that domain, FortiWeb will silently
allow the user to continue accessing them, forwarding (that is, delegating) credentials to each next web app, if
necessary.

DO NOT REPRINT
© FORTINET

DO NOT REPRINT
© FORTINET
Good job! You now know how to implement authentication features on FortiWeb.
Now, you will learn about the user tracking feature.

DO NOT REPRINT
© FORTINET
By demonstrating competence in using the user session tracking and username capture features, you will be
able to prevent session fixation attacks and instruct FortiWeb to block requests from timed out session IDs.

DO NOT REPRINT
© FORTINET
FortiWeb only tracks users that have logged in to a resource successfully, and stops tracking the user either
when the user logs off normally, or when the user’s session times out due to inactivity.

DO NOT REPRINT
© FORTINET
The User Tracking Rule tab is shown on this slide.
When you create a user tracking policy, you need to define an Authentication URL, a Log Off URL, and
Authentication Result Conditions.

DO NOT REPRINT
© FORTINET

DO NOT REPRINT
© FORTINET
Good job! You now know how to use the user tracking feature on FortiWeb.
Now, you will learn about attacks on authentication.

DO NOT REPRINT
© FORTINET
By demonstrating competence in understanding how authentication attacks occur, you will be able to take
measures to protect your network from attacks that are specific to authentication.

DO NOT REPRINT
© FORTINET
The most obvious protection may be brute force protection. When a client’s smart phone, tablet, or laptop
becomes infected and, subsequently becomes part of a botnet, web apps may receive many requests from
what appear to be legitimate sources. However, your attack logs may be full of log messages about
authentication failures. This is because the malware (or, in the case of attackers that aren’t cautious, a script
on their own computer) is trying to guess the password.
After the attacker successfully guesses the password, they will be able to log in as that user. If the user
associated with the guessed password has administrator privileges on your network, this can be a serious
breach for more than just that account.
Brute force detection monitors login URLs for suspicious request rates from each client IP.

DO NOT REPRINT
© FORTINET
Hands up! How many of you will admit to using these passwords?
The widespread use of weak passwords is one of many reasons why using PKI and 2-factor authentication is
important: they provide stronger authentication.
The use of weak passwords is also a good reason to limit each account to the minimum required permissions
for that person’s job, and why you should enable brute force protection.

DO NOT REPRINT
© FORTINET
Remember, if there are multiple clients sharing a single Internet connection behind NAT, then you’ll usually
want to allow multiple requests. Otherwise, if 25 people begin their work day at 9 AM and try to log in at about
the same time, they’ll be locked out!

DO NOT REPRINT
© FORTINET
Padding oracle attacks are another attack type aimed at authentication and session IDs. In this type of attack,
the attacker analyzes the padding in order to find a predictable pattern. Once they find a pattern, they use it to
understand the encryption and undo it.
It’s the same idea as the SSL/TLS attacks named CRIME & Lucky 13. CRIME requires only six requests to
decrypt one cookie byte, due to compression. A TLS MAC calculation always includes 13 bytes of header
information. The predictable length, in part, is what makes Lucky 13 attacks possible.
http://www.isg.rhul.ac.uk/tls/Lucky13.html

DO NOT REPRINT
© FORTINET
How much faster can an attacker break cryptography with a padding oracle?
This quote from Juliano Rizzo illustrates how serious the problem is.

DO NOT REPRINT
© FORTINET
Padding can be found in any individually encrypted HTTP input: the URL line, including parameters at the end
of it; a cookie header; or (in the case of POST method requests) parameters in the body.
So when you configure FortiWeb, indicate which inputs have padding that you want to protect.

DO NOT REPRINT
© FORTINET

DO NOT REPRINT
© FORTINET

DO NOT REPRINT
© FORTINET
By mastering the objectives covered in this lesson, you learned how to use FortiWeb to control access at the
IP and HTTP layer authentication, credential and SSO capabilities to web apps; and defeat some specific
authentication attacks.

 PCI DSS Compliance
DO NOT REPRINT
© FORTINET
In this lesson, you’ll learn how to apply FortiWeb features to help you meet the requirements of the payment
card industry data security standard (PCI DSS). This includes applying industry best practices from the
OWASP top 10.

DO NOT REPRINT
© FORTINET

DO NOT REPRINT
© FORTINET
By demonstrating competence in understanding PCIDSS and the OWASP Top 10, you will be able to better
identify and protect your network from Web application security threats.

DO NOT REPRINT
© FORTINET
The objective of professional attackers is to acquire information that they can sell on the black market. For
online retail companies, this can include addresses, personal ID numbers, and passwords, but most often, it is
bank debit and credit card numbers.
This 2014 study from Verizon highlights how common the problem is.

DO NOT REPRINT
© FORTINET
Because retailers and payment service providers often do not directly bear the cost of fraud, many assume
that it will not hurt their business. Sometimes, executives assume that security will cost more than the risk
itself.
This is false.
This article highlights one breach in 2014: Target. Because their point-of-sale systems were not correctly
secured, 40,000,000 debit cards were compromised. Target had a huge 46% drop in 4th quarter 2013 profits.
Customers became nervous of using their cards to pay for purchases at Target–in the USA. Currently there is
no legislation that requires vendors like this to pay for identity theft monitoring after a compromise, so for each
individual customer, the risk is huge. Target was forced to immediately spend $100,000,000 to improve
security. Banks that did business with Target were affected, too: they spent $200,000,000 to reissue
compromised cards. And this was for only one breach.

DO NOT REPRINT
© FORTINET
The payment card network–including banks–absorbs most of the losses due to fraud. As a result, it has a
clear financial interest in security. Security directly affects the profitability of payment card companies. But,
obviously, they pass these costs on to businesses and, ultimately, customers. This is the hidden cost of crime.
So now most payment service providers and retailers must demonstrate basic responsibility when transmitting
or storing payment card data. These standards are known as PCI DSS.

DO NOT REPRINT
© FORTINET
If you’re new to PCI compliance, here is a brief overview. As you can see, it has been enforcing many of
security’s best practices for more than a decade. So, you may already be mostly compliant.

DO NOT REPRINT
© FORTINET
PCI has released its next security standard, version 3.2.1 This came into force on May 2018.
What’s important to know?
The core areas of security remain the same. But the standards development will now be three years long, and
there are new sub requirements to deal with the most current threats–specifically, web application firewalls.
You will learn about each of these sub requirements, and how to meet them.

DO NOT REPRINT
© FORTINET
FortiWeb helps you meet all PCI requirements, but PCI now specifically recommends using a WAF, and
developing remediations against the top 10 vulnerabilities, according to OWASP.
9
DO NOT REPRINT
© FORTINET
If you’re not familiar with OWASP, it’s a global non-profit. Its goal is to promote secure application coding and
hardening.
OWASP has been growing steadily since 2004, and has been a contributor to projects such as the WebGoat
security education application. Now you can find OWASP presenters everywhere from OWASP’s official
AppSec conferences in California and Rio de la Plata, to German OWASP Day, Financial Services Cyber
Security Summit in Dubai, and Black Hat Asia.

DO NOT REPRINT
© FORTINET
OWASP’s top 10 is a list of vulnerabilities that are considered by security experts to be the most serious web
security threats. OWASP periodically updates them, based on its available attack data.
Many large organizations, including PCI, recommend that you scan for these vulnerabilities and fix or defend
against them.

DO NOT REPRINT
© FORTINET
OWASP’s last update to the top 10 is from 2018. It is available in many languages, including Arabic, Chinese,
Spanish, and Ukrainian. Let’s take a look at how FortiWeb can help you to find these vulnerabilities in your
web applications, and defend against them.

DO NOT REPRINT
© FORTINET
Injection and cross-site scripting remain the most common threat every year. This could be because they are
the easiest to exploit, even for inexperienced attackers. All you need to do is insert a line of code into any
input. If the input doesn’t reject it, you might be able to exploit it.
If a web application does not sanitize its inputs to make sure that they don’t contain scripts, queries, or shell
commands, and if the web app passes that input to an unsuspecting database engine, command line, or
browser, it could accidentally run the attack.
Numerous public XXE issues have been discovered, including attacking embedded devices. XXE occurs in a
lot of unexpected places, including deeply nested dependencies. The easiest way is to upload a malicious
XML file, if accepted

DO NOT REPRINT
© FORTINET
The good news is that FortiWeb can easily prevent injection and XSS. In signature policies, simply enable
their signature categories, then select that signature policy in the protection profile that you’re using.
Plain ASCII inputs aren’t the only type that HTTP can transport. If your web application uses Flash or AJAX,
also be sure that, in the protection profile, you enable FortiWeb to scan binary AMF and XML inputs.

DO NOT REPRINT
© FORTINET

DO NOT REPRINT
© FORTINET
Good job! You are now familiar with PCIDSS and the OWASP Top 10 list.
Next, you will learn how to identify if your web app is vulnerable.

DO NOT REPRINT
© FORTINET
By demonstrating competence in configuring and reviewing vulnerability scans, you will be able to use them to
protect your network.

DO NOT REPRINT
© FORTINET
For performance reasons, FortiWeb shouldn’t scan for attacks that your web apps aren’t vulnerable to. It’s a
waste of resources. Manual penetration tests are slow and costly. How can you speed up some of your PCI
compliance audits? How can you quickly discover the correct FortiWeb settings for your web apps?
FortiWeb has a vulnerability scan engine that is tailored to web applications. Quarterly vulnerability scans by
an approved vendor are part of the requirements for PCI DSS compliance. FortiWeb’s vulnerability scan gives
you a quick start so that you will be better prepared, with fewer required remediations.
The web vulnerability scanner doesn’t test for every possible vulnerability–some things are better investigated
by creative human penetration testers–but it does scan for these top OWASP vulnerabilities:
• SQLi
• XSS, which is a type of JavaScript injection
• Operating system command line injection
• Source code disclosure, which tricks the preprocessor into echoing back the PHP, ASP, Ruby, or other
page source code

DO NOT REPRINT
© FORTINET
To prepare for a vulnerability scan, always begin by copying the web app and its database to a test
environment. Do not scan live websites, especially through the Internet. If your public IP is a known source of
potential attacks, your ISP could ban you, but reputation-based services could also blacklist you. Additionally,
depending on the web app, the scan could inject data into the database, requiring you to restore from backup,
potentially causing some data loss. Also, if your FortiWeb is directly attached to the test servers, no other
network devices will rate limit or interfere with the accuracy of the scan, so the scan will be faster and more
accurate. For all of these reasons and more, you should scan a test copy of the web app–not the live
production network.
To configure a vulnerability scan, define the schedule, then the profile. Optionally, if you want FortiWeb to
email the finished report to you, also configure a connection to an email server. Finally, bind them together in
a scan policy.

DO NOT REPRINT
© FORTINET
Now you will learn how to configure a web vulnerability scan on FortiWeb.
First, determine the schedule. When a web app is updated, or different plugins installed, its vulnerabilities can
change. So while a recurring vulnerability scan may be part of your PCI compliance routine, it’s a best
practice to run the scan manually, whenever new software is introduced.
Any recurring scan can also be started on demand, whenever you need it, so it doesn’t prevent you from
manually forcing a scan. But if you want FortiWeb to scan only when you manually initiate it, in the Edit Web
Vulnerability Scan Schedule window, to the right of Type, select One Time.

DO NOT REPRINT
© FORTINET
FortiWeb may be able to scan faster if you decrease the request timeout. For the most complete scan, you
should also select an Enhanced Mode scan, which will try the POST HTTP method, too.
If your web application has a login page, remember to provide FortiWeb with a user name and password. That
way, FortiWeb can test all of the pages in your web app. Otherwise, the report will be incomplete. Depending
on your application, logins could be HTML form-based, HTTP dialog only, or both. Remember, with a form-
based login, when you click Log In, your browser could be sending credentials to a different URL than the one
that you’re currently viewing. To find the URL, view the page’s source code. Search for the <form> tag. Its
action attribute shows the URL where your app receives login attempts–the scan’s authentication URL.
<form name="loginform" id="loginform" action="http://10.0.1.21/wp-login.php"

method="post">
FortiWeb will log in. Then, it will crawl the links in the app, trying injection and echo vulnerability probes in
each input that FortiWeb finds on each page.

DO NOT REPRINT
© FORTINET
If you’re not sure what authentication data to send to the login URL, as usual, the developer tools in your web
browser can help you.
In the example shown on the slide, the Network menu was clicked before Log In in the web app. Since the
form used the POST method, parameters were in the HTTP body, not the headers. At the bottom of the slide,
you can see the Form Data section. In that section, you can copy the input that FortiWeb will use for
authentication. As you can see, the input has some unexpected inputs – not only the user name and
password.

DO NOT REPRINT
© FORTINET
Once you’ve configured the scan, you can immediately run it by clicking Play, or wait for the appropriately
scheduled time. For extended scans, you can either periodically return to the page to see the scan’s status, or
configure the scan to email you the results. However, you can also view and download it through the web UI.

DO NOT REPRINT
© FORTINET
You can also use XML-format reports from third-party web vulnerability scanners to automatically generate
FortiWeb protection profiles that contain rules and policies that are appropriate for your environment.

DO NOT REPRINT
© FORTINET

DO NOT REPRINT
© FORTINET
Good job! You now know how to perform a vulnerability scan on FortiWeb.
Now, you will learn more about additional top 10 threats.

DO NOT REPRINT
© FORTINET
By demonstrating competence in understanding the additional top ten threats, you will be able to better protect
your network through effective threat mitigation.

DO NOT REPRINT
© FORTINET
OWASP’s second most serious threat is more complex to protect against.
Because authentication and sessions can be attacked in many ways, you want to make sure that every step is
secure by ensuring the following:
• Sessions are cryptographically hard to predict.
• Sessions are bound to the client IP (if possible, to the individual browser).
• Session cookies, if used, are checksummed. This ensures that a client is not trying to masquerade as
another client and hijack a session.
• HTTPS protects both user names and passwords (and, if applicable, two-factor authentication passcodes)
during transit.
• Authentication doesn’t allow brute force attempts to guess valid user names and passwords.
• Subsequent page accesses use the bound session correctly, and don’t allow nonsense page transitions.
• Log messages don’t contain passwords or credit card numbers.

DO NOT REPRINT
© FORTINET
In this example, a normal user begins at the login page and receives a session ID in a cookie. However, if the
app does not require a session for access to all of the other pages, then the page order within the session
can’t be enforced, because the web app has no other way to remember the client’s previous page request and
associate it with a session. This kind of broken session management can be exploited.

DO NOT REPRINT
© FORTINET
You select most A2 mitigations in the protection profile, but some you enable in the policy.

DO NOT REPRINT
© FORTINET
Remember, if you have enabled logging (especially with the packet payload), credit cards and passwords
could be in the log messages–not just the HTTP traffic. To prevent this, and ensure PCI DSS compliance,
enable masking of sensitive data in the logs.

DO NOT REPRINT
© FORTINET
The file phpinfo.php usually has a simple function that displays all PHP settings. Each application could
have its own php.ini and .htaccess file. IIS, Apache, or whatever your web server is, may insert an X-
Powered-By: or Server: header that indicates which server and patch versions are installed. Software
stack fingerprints are useful for crafting attacks or even buying prebuilt ones on the black market.
If any configuration files can be read, written, or executed by users on the Internet, then attackers can gain
information on how to exploit unpatched servers, rewrite the configuration, and more.

DO NOT REPRINT
© FORTINET
A3 covers sensitive data exposure.
This objective is at the heart of PCI DSS compliance. The other OWASP top 10 threats can impact the safety
of stored payment card data–yet another reason to remove such a feature from your web application if
possible–but this threat is specifically about the data while it’s in transit, on the wires.
Like FortiGate, FortiWeb has data leak protection to detect credit card leaks on server replies. Ideally, servers
should accept card numbers, but never increase risk by repeating them back to the client. FortiWeb goes
further, though. As an SSL or TLS terminator, FortiWeb can offer only the most secure protocol versions and
cipher suites to your clients. This helps to keep your servers–and clients–more secure. If attacks are logged,
you can easily mask passwords and credit card numbers so that they don’t appear in your unencrypted logs.

DO NOT REPRINT
© FORTINET
To enable DLP, edit a signature policy. You can configure FortiWeb to detect a violation based on a specific
number of payment card numbers in the web page, if required.

DO NOT REPRINT
© FORTINET
Remember: both A3 and PCI DSS require security while payment is in transit. To secure payment card data
while in transit, authentication and encryption are critical.

DO NOT REPRINT
© FORTINET
Most web servers have default pages. When you’re configuring the web server for the first time, this helps to
quickly confirm that the software is running. However, these files should never be exposed on live production
servers. This is essentially the message of A6. These files provide information that can be useful to attackers.
If their permissions are incorrect, these files can also be an exploit vector.

DO NOT REPRINT
© FORTINET
Deserialization exploit is somewhat difficult. Some tools can discover deserialization flaws, but human
intervention is normally required for problem validation. Therefore, this is included in the top 10 based on
industry survey and not on quantifiable data.

DO NOT REPRINT
© FORTINET
It may surprise you to know that unpatched software is not considered by OWASP to be the most serious
threat. It only ranks ninth on the list of its 10 most serious security threats, even though it is one of the most
common. This ranking is partly this is because it’s the easiest to defend against. If FortiWeb is scanning for
known exploits and Trojans, and blocking Heartbleed HTTPS leaks, then this allows you some time to patch
your servers. Automatic updates on many server software components also make this threat easy to fight.

DO NOT REPRINT
© FORTINET
HTTPS offloading is configured directly in the server policy. The option to block known exploits and Trojan
uploads is configured in two places: the signature set and in the file upload restrictions.

DO NOT REPRINT
© FORTINET
Exploitation of insufficient logging and monitoring is core to nearly every major incident. Attackers rely on the
lack of monitoring and timely response to achieve their goals without being detected.

DO NOT REPRINT
© FORTINET
Most successful attacks start with vulnerability probing. Allowing such probes to continue can raise the
likelihood of successful exploit.
One strategy for determining if you have sufficient monitoring is to examine the logs following penetration
testing. The testers' actions should be recorded sufficiently to understand what damages they may have
inflicted.
You should consider following while configuring logging and monitoring:

• Ensure all login, access control failures, and server-side input validation failures can be logged with
sufficient user context to identify suspicious or malicious accounts, and held for sufficient time to allow
delayed forensic analysis.
• Ensure that logs are generated in a format that can be easily consumed by a centralized log management
solutions.
• Ensure high-value transactions have an audit trail with integrity controls to prevent tampering or deletion,
such as append-only database tables or similar.
• Establish effective monitoring and alerting so that suspicious activities are detected and responded to in a
timely fashion

DO NOT REPRINT
© FORTINET

DO NOT REPRINT
© FORTINET

DO NOT REPRINT
© FORTINET
By mastering the objectives covered in this lesson, you learned how to identify and avoid web application
security threats.

 Caching and Compression
DO NOT REPRINT
© FORTINET
In this lesson, you’ll learn how to cache common responses from the server for improved responsiveness in
your web apps, and how to handle response compression.

DO NOT REPRINT
© FORTINET

DO NOT REPRINT
© FORTINET
By demonstrating competence in FortiWeb response caching, you will be able to secure your web apps, and
make them faster.

DO NOT REPRINT
© FORTINET
Web pages don’t usually change every second, or even every hour. Many web pages–even ones generated
on-the-fly by a Tomcat servlet or PHP preprocessor for your content management system–are effectively
static. Usually an author writes the web page or uploads a file, and then that file never changes again. Yet
every time a client requests the page, the server usually uses CPU and precious time to regenerate the
HTML. This increases load and round-trip time and reduces performance, but does not benefit the user. When
many clients visit your site, this also means that load on your servers and LAN traffic increases
proportionately. Many clients can quickly overwhelm your server, and adding many more servers is
expensive. In other words, the solution doesn’t scale well.
To solve this, a web app could cache responses that haven’t changed. However, there is a tradeoff: by
sacrificing some RAM to store the response, the server could conserve CPU cycles. If the web app doesn’t
have a cache of its own, sometimes cache plugins are available.
But not all web apps support cache. Plus, if you have a server farm, keeping the same cache on every server
wastes RAM. So, it’s usually better to place the cache on a single server in front of, or on, your FortiWeb.

DO NOT REPRINT
© FORTINET
Like the web cache on FortiGate, if the content doesn’t appear to be dynamic, FortiWeb can keep a copy of
the response. That way, instead of repeatedly forwarding requests for the same content to the server,
FortiWeb can reply directly and quickly to the client.
This saves transmission and processing time on the back end. And the user is happier with a faster web
application.

DO NOT REPRINT
© FORTINET
Cache on FortiWeb uses some of its RAM. So, before you enable cache, make sure it can benefit your web
apps.
Cache will only improve the speed if you have many static files that are hosted locally. So, if most of your files
are, dynamically generated pages based on search results, or personalized pages after a user logs in, or if
most files are hosted in a remote CDN such as Akamai, then there may be no net benefit to enabling
FortiWeb’s cache.

DO NOT REPRINT
© FORTINET
It makes sense that search result pages can’t be cached. But you may not be able to guess some of the other
things that also can’t be cached.
When the server sets a session cookie, even if the page itself is identical to other requests, the Cookie:
HTTP header isn’t identical. A session cookie is a unique session ID–different from all other replies on
purpose, to identify the client. Remember, if any part of the HTTP request–including that header–is unique,
then the page shouldn’t be cached.
FortiWeb also won’t cache if the response has an unknown content length. (This often occurs with streaming
video, such as live news reports.) Cache has a fixed maximum size, and FortiWeb must be able to tell where
the content starts and ends, so it can’t cache a response if it can’t identify the size. Also, by definition, live
streams have dynamic content, not static.

DO NOT REPRINT
© FORTINET
Now, take a look at how to enable caching on FortiWeb. It’s very easy.
First, if there are any static URLs that you don’t want FortiWeb to cache, configure exceptions.
Can you find the misconfiguration in the example shown on this slide? Remember, there are some things that
FortiWeb doesn’t automatically cache because they are dynamic. So, you don’t need to configure those as
exceptions. These include responses with session cookies, because session cookies are supposed to be
unique IDs.
Next, configure the cache policy. In the simplest case, you just need to specify the maximum size you want to
allocate to the cache. FortiWeb automatically tries to cache all static URLs until its cache is full. Alternatively,
if you want more fine-grained control, you can manually specify which URLs to cache. Then, in your protection
profile, select the cache policy. That’s it!

 Introduction and System Settings
DO NOT REPRINT
© FORTINET

DO NOT REPRINT
© FORTINET
Good job! You now know the purpose of caching and how to implement it on FortiWeb.
Now, you will learn about response compression.

DO NOT REPRINT
© FORTINET
By demonstrating competence in FortiWeb response compression, you can improve the user experience, and
save money.

DO NOT REPRINT
© FORTINET
FortiWeb can also compress responses. This is another performance feature–something FortiWeb can do to
improve your user experience.
Compression can save you money, too. Mobile phone and 4G tablet data plans often have a bandwidth cap,
with penalty fees if you download too much. So, if your web applications are used frequently–like webmail at a
large company–the savings can be significant.
Compression essentially makes a .zip file of each request before replying to the client. Clients automatically
decompress the received file.
Compression is another feature that web servers sometimes offer, but you may be able to improve
performance by having FortiWeb do it instead. This allows your servers use CPU more efficiently, and focus
on things such as page preprocessors and queries to the database. It also reduces the total bandwidth you
need to deliver each response to the client. This reduces bandwidth usage for Android and iPhone users, but
it also uses your WAN or Internet link more efficiently.
There are a few cases where you won’t want to use compression. If a file is too big to fit in FortiWeb’s
compression buffer, then FortiWeb won’t be able to compress it. Some file types don’t compress well, either.
For example, remote procedure call (RPC) clients are essentially using HTTP as a transport for binary. Binary
is already somewhat efficient without compression. So, compression rarely improves the file size of a binary
enough to be worth the CPU time.

DO NOT REPRINT
© FORTINET
Now, take a look at response compression in action.
Notice that the client’s request indicates that it supports GZIP compression. FortiWeb will remember this.
Since the client is using the GET method, the request is short and, therefore, uncompressed. But the server
replies with a web page, image file, movie, or whatever file was requested, and it’s often at least several
kilobytes. That’s why it’s important to compress the response.
Is that always true?
No. GET is the opposite of other HTTP methods. With POST or PUT, the client may be sending a large file–
not the server. Uncompressed requests have already been transmitted along most of the network path by the
time they reach FortiWeb, so, at that point, compression can’t provide much benefit. And the server’s reply is
a short acknowledgement, so compressing that won’t improve performance. But, FortiWeb will try response
compression regardless of the HTTP method.

DO NOT REPRINT
© FORTINET
The best compression ratios are achieved when there is repetition in the data, such as HTML tags, JavaScript
functions, or CSS attributes that appear many times in the same file. As a result, plain text notes may not
compress well.
Some file types have native compression. ZIP archives are compressed, but so are MP4 movies, MP3 music,
and JPG photos. You might be surprised, but modern Microsoft Office files are compressed, too. In fact, if you
temporarily change their file extension from .docx to .zip, you can open the archive and see the XML files
inside.
Because it wouldn’t be logical to compress file types that are already compressed, FortiWeb won’t offer to
compress them.

DO NOT REPRINT
© FORTINET
When does compression help? When you have long files, with repetitive bytes: GZIP’s Huffman coding is
good at representing these efficiently. With a Fortinet .conf file, the GZIP could be 13% of the original–a
good compression ratio.
But, these examples use natural, human languages. Written Chinese is already very compact, with almost no
repetition. So, compression only reduces the file size of this UTF-8 plain text file by 1.5%. Compression is not
worth the CPU time.
An English translation of the same poem is less compact, but compression still doesn’t offer much advantage.
It reduces the file size by only 31%. Length improves the probability of repetition, though. Look at the second,
longer poem. It has a complex vocabulary, but it’s about three times as long. Its file size is reduced by 47%.
We’re finally reaching a 2:1 compression ratio. This still isn’t great, but now compression might improve
performance.
What about file formats that aren’t plain TXT files?
PDF file format is worse: it is a binary format with its own native compression; GZIP compression reduces the
file size by only 10%. But HTML gives us a better than 2:1 ratio.

DO NOT REPRINT
© FORTINET
The example shown on this slide is of a real web page. For the HTML page alone, compression makes the
transmitted file four times smaller–a very big speed improvement. When compressing HTML, it’s typical to
see a 75% to 80% file size reduction.

DO NOT REPRINT
© FORTINET
Now take a look at how to configure compression. Like cache, it’s simple.
First, configure any URLs that you want to exclude. Next, configure the compression policy. This specifies
which Internet file types you want FortiWeb to compress before forwarding the response to the client. (Internet
file types are the HTTP equivalent of email’s MIME types.) In most cases, you should configure FortiWeb to
compress all file types except text/plain.
When done, select the compression policy in the protection profile. That’s it!

DO NOT REPRINT
© FORTINET
If you decide not to offload compression, then you must configure your FortiWeb to handle it when
compressed responses arrive from the web servers.
Compression is, effectively, low-grade encryption. It changes the traffic so that it won’t match signatures or
rewrite conditions. FortiWeb must undo the compression so that your signature policies and rewrite conditions
work.

DO NOT REPRINT
© FORTINET
Depending on how much load your FortiWeb has, it may be better for your servers to compress files instead.
In that case, FortiWeb receives a precompressed file. Some patterns–such as information leak signatures and
HTML body rewrites–won’t match unless you undo the compression.
Think of uncompress rules as compression inspection–like SSL inspection. It prevents compression from
causing an accidental security bypass. For specific URLs and Content-Type:, you’ll configure FortiWeb to
temporarily undo the compression so that it can scan.
However, you don’t want to forward an uncompressed file. So, FortiWeb’s uncompression is only temporary.
After a rewrite or a scan where the erase action is required, FortiWeb automatically applies the compression
again. Alternatively, if no patterns match and no change is required, then FortiWeb doesn’t need to
recompress; it can just reuse the compressed original. Either way, FortiWeb forwards a compressed
response.

DO NOT REPRINT
© FORTINET
Like compression policies, uncompression policies are also based on file type. If you want to exclude any
responses from uncompression, you can do that, too.

DO NOT REPRINT
© FORTINET

DO NOT REPRINT
© FORTINET
Now, you will review the objectives you covered in this lesson.

DO NOT REPRINT
© FORTINET
By mastering the objectives covered in this lesson, you can improve the speed at which you deliver your web
apps to clients: cache and compression. You can also configure FortiWeb to buffer and uncompress a copy of
a precompressed packet in order to scan it, or modify it, or both, before forwarding it.

 HTTP Routing, Rewriting, and Redirects
DO NOT REPRINT
© FORTINET
In this lesson, you will learn how to control application delivery; that is, the flow of HTTP traffic through
FortiWeb based on the HTTP layer, instead of lower-layer IP-based routing. (This is also called HTTP content
routing.)
You will also learn how to redirect or rewrite pieces of the request or response for better usability and security.

DO NOT REPRINT
© FORTINET

DO NOT REPRINT
© FORTINET
By demonstrating competence in understanding redirects and how to configure them, you will able to use
redirects when required.

DO NOT REPRINT
© FORTINET
When are redirects useful? Mostly to establish HTTP traffic flow.
When a page moves, or when the user makes a typo, FortiWeb can tell the client to go to the new URL. Using
redirects helps you to avoid getting 404 errors. It’s the most common use for redirects. On a larger scale, you
can redirect users when web apps move to a new domain name (for example, from
webmail.example.com/mail to mail.example.com). You can also translate the host name if each
back-end web server has its own unique host name on the private network.
These uses are simply infrastructure: they are required for the web app to work. But redirects can also be a
security feature: you can send users to your site’s secure HTTPS channel. Since redirecting clients won’t
change the URLs of hyperlinks in the web pages on the server, you’ll often combine a redirect with a rewrite,
which you will learn about later.

DO NOT REPRINT
© FORTINET
How do redirects work?
FortiWeb replies to a client’s request with a 301 or 302 code and a Location: header. This tells the browser
to look for that resource in another location. The location can include a full path, such as
http://www.example.com/feed, or a relative URL, such as /feed.
Next, the client requests again, this time with the updated URL.
Note that because FortiWeb is inline, it’s in the right place to intercept the request and reply with the redirect.
FortiWeb can also modify traffic. In this example, the back-end web server’s response includes a Server:
Apache header. But you don’t want to tell potential attackers which web server you are using. To cloak the
server type, you also configure a signature set and enable Alert & Erase for information disclosure. So the
replies that the client receives–both the first time and the second time–have been modified by FortiWeb.
Keep this concept in mind. You will use it again later for rewriting traffic.

DO NOT REPRINT
© FORTINET
Here’s another example of a redirect. Start looking at this example from the beginning: when the client
discovers which subnet contains the virtual server, and what its MAC address is.
As you can see, the client asks for the IP of FortiWeb’s virtual server–not the back-end servers, which are
hidden to the client. Next, the client completes the TCP handshake with the reverse proxy FortiWeb, and
requests a page through HTTP.
At about the same time, FortiWeb establishes a second TCP connection to one of the protected web servers
behind it. Meanwhile, it replies to the client that the site should be accessed through HTTPS, not HTTP.
FortiWeb can do this because the Location: header can contain an entire path, including the protocol
prefix.
So the client attempts again. This time, it sets up a TLS 1.2 session with FortiWeb before making the page
request. When the server replies, FortiWeb forwards it through the secure TLS session to the client.

DO NOT REPRINT
© FORTINET
To configure the HTTP-to-HTTPS redirect that you just traced, in the Application Delivery menu, make a
URL rewriting rule. (Don’t be confused by the name–it can do more than just rewrite the URL line.)
Define the match criteria first. Since redirects act on incoming requests, indicate the traffic’s direction in the
Action Type field. Since you don’t want to redirect every request to the same place, you’ll also specify these
match conditions: the host and URL line in the HTTP header.
Once you’ve specified the match, FortiWeb will return a 301 or 302 code, which causes clients to modify the
URL and try the request again. Where will the new, modified URL be? That’s what you define in the Location
field. To avoid making one rewriting rule for each URL–which could be 10,000–use capture group variables to
define the location.

DO NOT REPRINT
© FORTINET

DO NOT REPRINT
© FORTINET
Good job! You now know how to configure redirection on FortiWeb.
Now, you will learn about capture groups and back references.

DO NOT REPRINT
© FORTINET
By demonstrating competence in understanding capture groups and back references, you will be able to use
them, when needed, on FortiWeb.

DO NOT REPRINT
© FORTINET
What is a capture group? And, relatedly, how can we refer back to text that was stored by a capture group?
For URL rewriting rules, FortiWeb uses regular expressions. You may have noticed by now that FortiWeb
uses regex for many features. Because HTTP and its usual payload HTML are text based, and because regex
is designed for text-based patterns, it’s the perfect match.
A capture group is a regular expression inside a pair of parentheses. When the text that you’re evaluating
matches the pattern inside the parentheses, the regex engine stores, or captures, the match temporarily by
putting it in RAM. It stores each piece of text in the same order, which the engine evaluates the match:
1. Left-to-right
2. Outside-to-inside

DO NOT REPRINT
© FORTINET
In programming, the purpose of variables is to reuse the piece of data that you’ve stored. The same is true
here. When building the output, FortiWeb can use the data from your capture group variables.
Technically, this isn’t the only way you can refer back to data from capture groups. If you want to reuse parts
of the previous evaluations in the subroutine (which is the case with our HTTP-to-HTTPS rewrite), then you
would use $0 and so on. But to reuse parts of the current evaluation, use /0 and so on. That can be useful for
URLs with repeating text.
You can find many more useful examples of regular expressions in the FortiWeb Administration Guide and in
PCRE reference books.

DO NOT REPRINT
© FORTINET
Now that you know what a capture group is, look again at the match conditions for your HTTP-to-HTTPS
redirect.
First–and only if it’s an HTTP request, not HTTPS–you evaluate the Host: field in the HTTP header. In this
case, we match all of any text in that field, so any domain name will match. The regular expression to do this
is: .*
A match found using the expression is sometimes called a greedy match because using the expression
makes the biggest match that it can. Since the host name is relatively short, that’s okay. However, if you were
matching HTML in the body of a message, using the expression (.*) could cause a performance problem.
Why? If the HTML page is large, you don’t want to store the entire page in a capture group in RAM every time
the page is requested! The expression .* is easy to use because it is easy to remember. But before you use
it, you should think carefully, and match accurately. Usually when matching, you should use the fewest
number of character comparisons that you can, not the most.
When you wrap the greedy match in parentheses, and when it is the first match condition in the table,
FortiWeb stores the packet’s whole host name in capture group 0.

DO NOT REPRINT
© FORTINET
Next, you will test to see if the URL line in the HTTP header matches. The URL line always begins with a
forward slash, and you want to capture the text after that, so the regular expression begins with: ^/
The capture group matches all text from the point that you indicated until the end of the line, indicated by the
dollar sign ($). It’s stored in capture group 1.
Now FortiWeb is ready to construct the entire Location: header for the universal redirect to HTTPS.

DO NOT REPRINT
© FORTINET
If you only want to redirect for www.example.com, then you could enter: www\.example\.com
Alternatively, you could match the IPv4 address. The documentation has examples of regular expressions that
you can use for both.
A web site’s domain name usually exists in more than just the HTTP header, though. What about links in the
web pages?
If you were redirecting all links for every page, it could make the web app slower. Clients would have to
request every page twice. Plus, every HTTP request is an opportunity for a man-in-the-middle to make an
HTTPS stripping attack, avoiding the HTTPS redirect. How can you improve that?

DO NOT REPRINT
© FORTINET

DO NOT REPRINT
© FORTINET
Good job! You now understand how to use capture groups and back references on FortiWeb.
Now, you will learn about rewrites.

DO NOT REPRINT
© FORTINET
By demonstrating competence in configuring rewrites, you will be able to use rewrites to redirect clients to
HTTPS addresses.

DO NOT REPRINT
© FORTINET
When FortiWeb is inline, it can do more than intercept. It can modify the traffic, too. If FortiWeb rewrites
absolute links to use the HTTPS address, then the client will only be redirected the first time, when they begin
a browsing session.
Rewrites exist on Apache, IIS, and other web servers, so rewrites may be familiar to you. But if the regular
expressions are complex, they can require significant processing time. So, if your server is spending most of
its processing time on rewrites, instead of querying the database and building the web page, you may be able
to improve performance by offloading the rewrites to FortiWeb.
There are many more reasons why you might want to rewrite traffic. Rewriting is sometimes required for the
web app to work. For example, your Internet DNS records might refer to public host names that don’t match
the web servers’ host names on your private network, such as www1, www2, and so on. But, rewriting can
improve security, too.
In this example, you need the absolute links in the web pages to be changed from HTTP to HTTPS.
For example, FortiWeb can return 403 error codes to URLs that should not be publicly available, instead of
forwarding the web page from the server. It can also cloak server information disclosure in headers and in the
body. If your web servers have already been compromised, FortiWeb can sanitize responses to safeguard
your users while your incident response team makes an ex post facto intrusion analysis. But even better,
FortiWeb can patch your applications on-the-fly, replacing vulnerable functions with safe ones.

DO NOT REPRINT
© FORTINET
If you need to rewrite HTML tags or UTF-8 encoded domain names, there are specific regular expression
examples that you can copy or modify from the FortiWeb Administration Guide.

DO NOT REPRINT
© FORTINET
When you configure a rewrite, you first indicate the direction of the traffic:
• Is it an incoming request?
• Is it an outgoing reply?
Requests and replies have different HTTP headers and content, so the options are different, too.
When evaluating traffic for a match with your rewrite policy, FortiWeb doesn’t necessarily test for incoming or
outgoing, relative to the packet’s source IP and your defined server pools. Unlike FortiMail, FortiWeb doesn’t
need to. That’s because the headers and content of requests and replies are different.
So, regardless of direction, FortiWeb’s HTTP parser dissects the traffic. It splits it into its header fields and
body. It stores each part in a buffer. Then, depending on your rules, FortiWeb’s rewrite engine looks for the
corresponding buffer, and evaluates it for a match. If the traffic meets all match conditions, then FortiWeb
rewrites the specified parts of the HTTP layer.

DO NOT REPRINT
© FORTINET
Look at the example in this slide. Look at the match conditions. Can you guess which URLs will match? What
are the capture groups? What is the output?
You want to hide the .php file extension and WordPress-specific login URL from clients. This helps to prevent
attackers from fingerprinting your server’s software stack, but it also means that if you change your app later
to movable type or Drupal, the following will be true:
• People won’t need to fix their browser’s bookmarks.
• You won’t have to configure any redirects to avoid 404 errors.
To make this work, you need two rules:

• One to translate the incoming request’s URL to its real, server-side URL (which is shown here)
• One to translate hyperlinks in the reply to platform-agnostic URLs

DO NOT REPRINT
© FORTINET
On the left side, you can see the second rule. It scans the reply body–which could be HTML or JavaScript–
and removes all instances of .php before FortiWeb forwards it to the client.
To apply your rules, you group them in a URL rewriting policy, then select them in the protection profile.

DO NOT REPRINT
© FORTINET

DO NOT REPRINT
© FORTINET
Good job! You now know how to configure rewrites on FortiWeb.
Now, you will learn about HTTP content routing.

DO NOT REPRINT
© FORTINET
By demonstrating competence in configuring Layer 7 HTTP content routing, you will be able to use this
feature on FortiWeb.

DO NOT REPRINT
© FORTINET
Rewriting client requests has an interesting effect: it can change how you configure routing, or vice versa.
Why? Because FortiWeb has static and policy-based routes, like usual. They match traffic based on the IP
layer’s source and destination. But FortiWeb can also route based on the HTTP layer.
Like other load balancing methods, HTTP content routing can avoid servers that are down for maintenance. It
can also distribute TCP connections among servers in the pool. But unlike the other load balancing methods,
with HTTP content routing, you may have multiple server pools. Each one has a logical function.
For example, some servers might host only SharePoint, and others might host only Outlook Web App, while a
third server pool hosts both your e-commerce storefront and CRM portal. Depending on which web app the
client asks for, FortiWeb would route the request to the appropriate server pool.
HTTP content routing can match based on criteria that are also rewritable: Host:, URL, and Referer:. So if
you apply both, verify your match conditions. Do your match criteria look for the initial URL, or the rewritten
one, for example? If the interactions are complex, it can help to look at the sequence of scans section of the
FortiWeb Administration Guide.

DO NOT REPRINT
© FORTINET
This slide shows an example of HTTP content routing based on the Cookie: header.
When a user goes to the web site, at first, they don’t have any session ID. You have configured a rule on
FortiWeb that directs the first page request to a login server, which assigns a session ID.
By doing this, you can use the login server as a logical controller. The login server inserts a session ID with a
number in a range that always belongs to Web Server2, or Web Server3, and so on. On FortiWeb, you would
configure an HTTP content routing rule that routes requests with each range of session IDs to their assigned
servers. FortiWeb would forward the next request and all subsequent ones to the same back-end server. This
provides HTTP session persistence, and it can do the same for a logical group–a server pool–not just to a
single server.
Because each server can host different web apps, FortiWeb allows you to select a separate protection profile
for each one. So, in the case of HTTP content routing, a policy may use multiple protection profiles.

DO NOT REPRINT
© FORTINET
Now you will learn how to configure content routing. Begin by configuring your server pools. Each server pool
will be the target of traffic that matches the HTTP content route. Next, configure the content routes
themselves.

DO NOT REPRINT
© FORTINET
To apply your routes, in your server policy, select HTTP Content Routing in the Deployment Mode drop-
down menu. Then, add each route to the table that appears. Just like you can configure a default gateway at
the IP layer, you can also configure a default route at the HTTP layer.

DO NOT REPRINT
© FORTINET
If a multiplexing device is in front of FortiWeb, and if it is intelligent enough to pipeline requests from the same
client, for the same web app, together in the same TCP connection, then you can enable the Match Once
setting.
Enabling Match Once improves performance. For routing, FortiWeb will only evaluate the first request in the
connection. It won’t repeatedly evaluate content routes for the related requests. However, don’t enable the
setting otherwise. If the connection multiplexes unrelated requests from multiple clients, many requests could
be routed to the wrong server pool.

DO NOT REPRINT
© FORTINET

DO NOT REPRINT
© FORTINET

DO NOT REPRINT
© FORTINET
By mastering the objectives covered in this lesson, you learned to how to redirect users to secure sites. and
how to rewrite URLS in headers and links in web pages for convenience and security.

 Troubleshooting
DO NOT REPRINT
© FORTINET
In this lesson, you will learn how to avoid common misconfigurations, diagnose false positives, solve
connectivity and storage issues, and optimize the performance of your FortiWeb.

 Troubleshooting
DO NOT REPRINT
© FORTINET
In this lesson, you will learn about the topics shown on the slide.

 Troubleshooting
DO NOT REPRINT
© FORTINET
By demonstrating competence in fine-tuning rules and signatures, you will be able to identify, and prevent or
reduce false positives, especially if you are installing a new, custom web application with FortiWeb.

 Troubleshooting
DO NOT REPRINT
© FORTINET
Especially if you are installing a new, custom web app with FortiWeb, initially you may need to fine-tune rules
and signatures to avoid some false positives. False positives are requests that look similar to an attack, but
are actually normal traffic.
When deploying FortiWeb for the first time, or when beginning to protect new web applications, the most
common diagnostic task can be to find an individual signature or rule that is accidentally blocking normal
traffic.
Because FortiWeb can block based upon multiple factors–the source IP address, the request rate, the data
type of inputs, the size of a file upload, and so on–you may need to adjust more than one setting. For a list of
scans and processing that FortiWeb applies to traffic, see the sequence of scans in the FortiWeb
Administration Guide or online help. In this list, you’ll notice one effect you may not expect: whitelisting does
not bypass all scans, just most.
Before the whitelist check, two scans occur. So, if a client begins a TCP flood, or is already being period
blocked, the whitelist will not immediately restore connectivity.

 Troubleshooting
DO NOT REPRINT
© FORTINET
Essentially, there are three steps to correcting most false positives.
Web app upgrades and patches can change your security requirements, causing false positives. URL
structure in Microsoft Outlook Web Application, for example, has changed significantly between 2003 and
later versions. WordPress vulnerabilities often vary by the installed plugins, too. So, if you have many false-
positives to fix, especially for HTTP constraints or input rules, auto learning can be a useful tool to help you
update your FortiWeb settings.
Remember: fully enabled auto learning on all policies and ports can add significant latency. So, if possible,
use some of the documented strategies for eliminating or reducing auto learning-related processing load while
protecting live traffic.

 Troubleshooting
DO NOT REPRINT
© FORTINET
If there are only a couple of false positives, then you can fix them easily.
1. Enable local storage of attack logs. Enable packet payloads–part of the packet that matched the rule or
signature.
2. In the attack log, find an entry for an attack that is actually normal traffic.
3. Click the row. The log message details should appear in a panel on the right side. If you scroll down to the
Packet Header section, the part of the request or reply that matched the signature is highlighted.
4. If you want to customize the signature or rule so that it will still block attacks, but not match your innocent
traffic, then do so. Otherwise, scroll up to the message portion of the attack log’s panel. Click the link to
either add an exception, or disable the signature entirely.
If you change your mind later, you can use the advanced mode when editing a signature policy to find
disabled signatures, and reenable them.

 Troubleshooting
DO NOT REPRINT
© FORTINET
If you’re adjusting behavior to create a custom signature, it can be helpful to know the ID and behavior of the
signature that triggered a false positive.
The ID indicates the category of attack that it was intended to block. The Found In and Match Sample fields
show what part of the request was being analyzed. When you create your custom signature, you should do
three things:
• Defend against that same attack, if possible
• Scan the same part of the request or reply
• Match the same dangerous traffic, but avoid matching normal traffic that was recorded in the packet
payload

 Troubleshooting
DO NOT REPRINT
© FORTINET
If FortiWeb is applying a period block, usually their entry on the temporary blacklist will expire before they
contact you. However, if they try the same thing again, they will immediately be blacklisted again. Even if you
whitelist their IP, this will not cancel the period block. You need to remove their entry in Blocked IPs.
Otherwise, you will have to wait for the entry to expire before you can test the new whitelist entry.

 Troubleshooting
DO NOT REPRINT
© FORTINET
A whitelist entry should not be a permanent solution. If a user’s laptop gets infected with a virus, or if their
phone is stolen, then that client is no longer in that person’s control. You don’t want FortiWeb’s security to be
nullified.
If you’re not sure how to write a custom signature, you could change the rule or signature’s action to Alert
Only instead. That way, the client will be able to use the application, but you will still be notified of potential
attacks. You can also continue to gather data about what normal traffic is accidentally matching the signature,
until you understand how to correct the rule or signature.
Whitelists are best for individual browsers, not for search engine crawlers.

 Troubleshooting
DO NOT REPRINT
© FORTINET
If the client isn’t a person–if it’s a bot–then you should use different tactics. If all your sites should be easily
found on Google or Bing, for example, then you should whitelist them by their public IP on the Internet, in
FortiWeb’s list of known search engines.
Currently this is a global setting, and not specific to each policy.

 Troubleshooting
DO NOT REPRINT
© FORTINET
Search engine crawlers aren’t the only type of bots that may be trying to access your web apps. Blog
comment spam bots and content scrapers–scripts that steal web pages, images, and videos from other sites–
might also being trying to access. Often they’re used to populate sites so that their owners can get advertising
revenue without paying authors.
Sometimes, power users use command-line tools such as curl and wget to download web pages for offline
viewing, and–unless you block them–they will, by default, report their User-Agent: string.
Some bots, such as ContentSmartz, are designed specifically for malicious use. Because User-Agent: strings
are not authenticated or encrypted, it’s easy to fraudulently claim to be something more innocent such as
wget. This is why FortiWeb’s feature for known search engines doesn’t rely on that HTTP header.
If you think that a content scraper is abusing your sites, review the Bot Analysis page. You may want to
enable Real Browser Enforcement to protect your pages from theft.

 Troubleshooting
DO NOT REPRINT
© FORTINET

 Troubleshooting
DO NOT REPRINT
© FORTINET
Good job! You now know how to identify and resolve false positive situations on FortiWeb.
Now, you will learn about SSL/TLS-related issues.

 Troubleshooting
DO NOT REPRINT
© FORTINET
By demonstrating competence in SSL/TLS issues, you will be able to identify and resolve encryption-related
issues if your FortiWeb is scanning HTTPS.

 Troubleshooting
DO NOT REPRINT
© FORTINET
If HTTP works, but HTTPS is sometimes failing, it might not be a false positive. It might be a real attack.
Some versions of SSL and TLS have their own DoS vulnerabilities. Insecure session renegotiation is one. If
the following conditions are true, this is a good indicator that these are real attacks, not normal traffic:
• Your DoS sensors are detecting other attacks from the same clients
• They are failing the Real Browser Enforcement test
• You are whitelisting search engine crawlers
If possible, you should disable insecure renegotiation to make SSL-related DoS attacks impossible.
So, what are some examples of genuine misconfiguration issues?

 Troubleshooting
DO NOT REPRINT
© FORTINET
There are some misconfiguration issues that are possible with HTTPS. This slide shows examples of two
common ones.

 Troubleshooting
DO NOT REPRINT
© FORTINET
If the client and SSL terminator (which is FortiWeb or your web servers, depending on your operation mode)
don’t speak the same SSL or TLS protocol, then their proposals won’t match. This causes an unknown
protocol message in the attack logs.
In some cases, this may be normal, expected behavior. For example, if you’re required to be PCI DSS
compliant, you could see this error when some very old clients try to use your web app.
If the protocol is known, but the client and SSL terminator don’t support any of the same cipher suites, then
they won’t be able to negotiate a secure channel. This error is more rare, since there are currently more than
160 combinations. But it is possible, especially if your web application or clients only support a few specific,
rarely used cipher suites, such as SEED, or very weak or very strong key strengths. You may want to use
Geo IP or another feature to block clients that are probing your network to see if weak ciphers are supported.

 Troubleshooting
DO NOT REPRINT
© FORTINET
This case is more rare, but you could also see some messages that indicate FortiWeb can’t inspect the
HTTPS traffic. This is caused by a combination of factors: a specific type of cipher suite and FortiWeb
operating in transparent inspection mode.
The PFS mechanism is similar to how IPsec Phase I keys are temporary and used to negotiate the real, more
secure Phase II keys. The idea is that by periodically changing the keys inside a secure tunnel, even if one
key is decrypted, only part of the conversation has been compromised–not the entire thing.
Obviously, in order to scan traffic, FortiWeb always must have the right keys to be able to decrypt the packet.
Otherwise, it can only scan lower-layer headers. So, if (because of the nature of transparent inspection)
FortiWeb is out-of-sync with the current keys, then packet inspection will fail. This is normal for PFS with that
operation mode.
To fix this, on your web servers, you must disable those types of cipher suites. This slide shows an example
of how to do this in an Apache 2 configuration file.

 Troubleshooting
DO NOT REPRINT
© FORTINET

 Troubleshooting
DO NOT REPRINT
© FORTINET
Good job! You now understand how to resolve SSL/TLS-related issues.
Now, you will learn about performance-related issues.

 Troubleshooting
DO NOT REPRINT
© FORTINET
By demonstrating competence in identifying and resolving performance-related issues, you will be able to
prevent security bottlenecks from occurring.

 Troubleshooting
DO NOT REPRINT
© FORTINET
Is performance normal? How do you know?
Begin by observing your system resources and bandwidth usage while FortiWeb is idle and during low traffic
periods, such as nighttime and weekends. Then, observe system resource usage on weekdays and holidays,
including expected traffic spikes such as marketing campaigns or quarterly financial reports to stockholders.
What is the normal range? What is the expected rate of growth?

 Troubleshooting
DO NOT REPRINT
© FORTINET
If you have an SNMP manager, such as FortiManager or Cactus, SNMP traps and queries are a good way to
track traffic and system resource changes over time. You can use the collected data to help you plan for
network upgrades as your organization grows.
If SNMP shows sustained high resource usage, there are related traps to help you find the cause.
For example, if it correlates with the attack detected by a signatures trap, then you may need to optimize a
custom signature’s regular expression. If possible, reduce the number of characters consumed or forward-
looking required in order to determine a match.

 Troubleshooting
DO NOT REPRINT
© FORTINET
High RAM or CPU usage can also be tracked in the logs. If you have a FortiWeb model with less RAM, you
may need to adjust your system alert thresholds. That way, you won’t receive alert email or many log
messages and traps during normal load. You can specify the thresholds in Log&Report > Log Config >
Other Settings.

 Troubleshooting
DO NOT REPRINT
© FORTINET
You wouldn’t transmit your security logs over the Internet without encryption, right? The same principle
applies to alert email.
Since your mail servers may not be located in the same data center as FortiWeb, FortiWeb now supports
secure mail protocols to protect the messages while they are in transit.
To preserve performance while you are under a DoS attack, FortiWeb only records one log and sends one
alert email for multiple instances. This also prevents your inbox from being flooded. While the attack
continues, FortiWeb will continue to periodically record the event. The interval varies slightly, depending on
the type of attack.

 Troubleshooting
DO NOT REPRINT
© FORTINET
As on FortiGate and other Fortinet products, if a process is consuming an abnormal amount of RAM, you can
immediately terminate the process. It may be respawned, so this is not a permanent solution, but it can
provide temporary relief while you enable debug logging.
In the example shown in this slide, a specific policy is consuming an abnormally high amount of RAM. If you
kill the process, and notice that it initially starts with much lower RAM usage, it could indicate a memory leak.
This would require a firmware upgrade to fix. In other cases, high RAM usage can be caused by
misconfiguration.
Debug logs can help both you and Fortinet Technical Support locate the true cause.

 Troubleshooting
DO NOT REPRINT
© FORTINET
Just like your web applications, FortiWeb has its own memory buffers. It uses them to temporarily store
information until it is done processing. Many of these buffers are configurable, so if you aren’t careful, your
configuration can decrease performance.
Avoid increasing the body cache and DLP cache sizes, unless necessary. To harden your security, configure
FortiWeb with HTTP constraints that block any part that is too large to fit its HTTP or HTML parser buffers.
Also be aware that the period block action does not always improve performance. Like any cache, it is a
shortcut to avoid repetitive CPU processing that has the same results. So, if a client tries an attack only once,
then its entry in the cache is still consuming RAM, but not providing any benefit. Using period block only
improves performance when the same client attacks your web apps many times.

 Troubleshooting
DO NOT REPRINT
© FORTINET
You can test for persistent, disk-stored cache by rebooting FortiWeb. Usually, cache is ephemeral, stored in
RAM.
So, keep HTTP session timeouts, response cache, authentication session caches, and others as low as
possible without affecting normal traffic. This helps to keep RAM usage lower.

 Troubleshooting
DO NOT REPRINT
© FORTINET
Besides the OS and configuration, there are some files that FortiWeb stores on a flash disk or hard disk.
All files and databases are kept in persistent storage that won’t be lost when you power off FortiWeb. Each
physical disk can be subdivided into logical partitions, which are then mounted on a file system pointer in
RAM.
In the example shown in this slide, you can see that logs are stored on a partition that is about 30GB large.
Currently, it contains very little data relative to its total capacity. But the 97MB /data partition is almost half full.
Is this normal?
To answer that question, we need to know if /data indicates the hard disk or flash disk.

 Troubleshooting
DO NOT REPRINT
© FORTINET
The example on this slide shows that the 97MB/data device corresponds to the size of the first firmware
partition on the internal flash disk. Since firmware doesn’t increase in size unless you upload an update, this
disk usage is probably normal.
Normally, you don’t need to repartition the disks; however, there can be exceptions. When FortiWeb added
the data analytics feature, it required more storage for the data analytics file. So, before loading the firmware
update, you were required to upload a special image to repartition the disk. As always, read your release
notes to see if there are any special instructions for upgrading.

 Troubleshooting
DO NOT REPRINT
© FORTINET
Logs and data analytics statistics are both stored in a database. So, if your FortiWeb experiences an
unexpected power failure, you may need to check the hard disk for errors, and then also may need to reindex
the database. Otherwise, features that depend on them may fail.

 Troubleshooting
DO NOT REPRINT
© FORTINET
If you ever need to restart FortiWeb, it will terminate all current administrator sessions. If multiple people
configure FortiWeb, notify them to save their changes before you enter the execute reboot command. You
can use this command to show which accounts are currently logged in.

 Troubleshooting
DO NOT REPRINT
© FORTINET

 Troubleshooting
DO NOT REPRINT
© FORTINET
Good Job! You now understand how to identify and resolve performance-related issues.
Now, you will learn about traffic flow and site statistics.

 Troubleshooting
DO NOT REPRINT
© FORTINET
By demonstrating competence in traffic flow and site statistics, you will be able to resolve HA and FortiGuard-
related issues.

 Troubleshooting
DO NOT REPRINT
© FORTINET
If you need to analyze your network at a lower level, FortiWeb has many of the same network diagnostic tools
as FortiGate.
When viewing the NIC statistics, the FortiWeb VM will show a slightly different output.
For example, the driver will be for the virtual hardware, provided by Xen or VMware. The virtual MAC is
usually dynamically generated at load time–it is not static. Unless you use a distributed virtual switch, you
shouldn’t notice any transmission errors. Separate vSwitches should also mean there are no transmission
errors. Some will be emulated. There is no actual twisted pair cable in a host-only virtualized network.

 Troubleshooting
DO NOT REPRINT
© FORTINET
You can view the ARP table. This can be useful if you need to find an IP address conflict, but also can be
used in HA. If you suspect a split-brain scenario–that is, both devices believe that they are the primary, and
that they should assign the IP addresses and virtual MAC to their physical ports, then log in to the local
console on each device. The ARP list will show that the ports on both devices have the same virtual MAC.

 Troubleshooting
DO NOT REPRINT
© FORTINET
To test your routing paths, FortiWeb has ping and traceroute commands.

 Troubleshooting
DO NOT REPRINT
© FORTINET
Also like FortiGate, you can use the command line to capture packets that arrive on or leave one of
FortiWeb’s network interfaces. If you save the output to a file, you can use the fgt2eth.pl Perl script to
convert it to a format that Wireshark can load.
You can download the converter here:

http://kb.fortinet.com/kb/microsites/search.do?cmd=displayKC&docType=kc&external
Id=11186

 Troubleshooting
DO NOT REPRINT
© FORTINET
Now you will look at a couple of examples.
If all you need to know is whether packets from a client using a specific protocol are arriving at FortiWeb on a
specific interface, this basic packet capture may be enough. It doesn’t filter out any packets. It only shows a
few main parts of the IP header, as indicated by the verbosity level number 1.
Since the command indicates to stop after three packets, we don’t have to press Ctrl+C to stop the capture.

 Troubleshooting
DO NOT REPRINT
© FORTINET
This is the packet capture that Fortinet Technical Support is more likely to request. It contains much more
detailed information, as indicated by verbosity level 6. This capture includes higher-level payloads that you
can load into a packet analyzer, such as Wireshark, to troubleshoot HTTP and other application-layer issues.
To avoid capturing distracting, irrelevant information, we’ve used the packet filter tcp port 443 to focus on
HTTPS traffic.
Stopping after three packets usually doesn’t gather enough information. In the example shown on the slide,
the command runs until the administrator presses Ctrl+C.
By default, terminal emulators such as PuTTY or TeraTerm have limited buffer in RAM. To use the Perl script
to convert this output to Wireshark format, you must configure the terminal client to save the buffer to a plain
text file on your computer. If you’ve never done this before, see the FortiWeb CLI Reference.

 Troubleshooting
DO NOT REPRINT
© FORTINET
FortiWeb now also features a GUI-based packet capture tool, as well as the traditional CLI commands. Before
using this tool, you should have a good understanding of tcpdump and filter expressions. You must have
read-write permission for system settings.
Capture results are collected in a PCAP format file, which you can download and open in any tool supporting
PCAP format, such as Wireshark
Go to http://www.tcpdump.org/manpages/pcap-filter.7.html for more information on the

tcpdump utility.

 Troubleshooting
DO NOT REPRINT
© FORTINET
In most cases, FortiWeb can connect easily to FortiGuard. If your firewall blocks outgoing traffic however, this
information can help you to configure policies to allow it.
FortiWeb needs DNS, NTP, and HTTPS connectivity to the Internet. Depending on your configuration, it may
need other protocols too, such as SMTPS for alert email. For a complete list of protocols and default port
numbers used by FortiWeb’s various features, see the FortiWeb Administration Guide.

 Troubleshooting
DO NOT REPRINT
© FORTINET
If FortiGuard updates fail, the debug commands shown on this slide can help you to discover the cause.
The execute update-now command can also be useful if you have a FortiWeb VM model and you want to
force it to immediately authenticate its license, instead of waiting for the next retry interval.

 Troubleshooting
DO NOT REPRINT
© FORTINET
Like FortiGate, FortiGuard services are licensed for each device, not for each cluster.
FortiWeb VM must be able to authenticate its license, just like FortiGuard services. This means that FortiWeb
VM must have a reliable connection to the Internet. It also means that you should not apply dynamic source
NAT to outbound connections from FortiWeb to FortiGuard, because this can make it look like the VM license
has been moved to a different location–or stolen. This can cause unexpectedly related symptoms, such as
slow ARP retraining during HA failover.

 Troubleshooting
DO NOT REPRINT
© FORTINET

 Troubleshooting
DO NOT REPRINT
© FORTINET

 Troubleshooting
DO NOT REPRINT
© FORTINET
By mastering the objectives covered in this lesson, you learned how to either fix the rules or signatures, create
exceptions for specific URLs, or disable the signature, when signatures or rules accidentally block innocent
traffic. You also learned how to handle content scrapers and search engine crawlers, which often have
different settings than human web browsers.
You learned how to monitor CPU, RAM, bandwidth, and disk space for abnormal usage. You learned that
while period block often improves performance, there is one case when that is not true. Finally, you learned
how to fix connectivity issues, including ones with FortiGuard and HA clusters.

DO NOT REPRINT
© FORTINET
No part of this publication may be reproduced in any form or by any means or used to make any
derivative such as translation, transformation, or adaptation without permission from Fortinet Inc.,
as stipulated by the United States Copyright Act of 1976.
Copyright© 2019 Fortinet, Inc. All rights reserved. Fortinet®, FortiGate®, FortiCare® and FortiGuard®, and certain other marks are registered trademarks of Fortinet,
Inc., in the U.S. and other jurisdictions, and other Fortinet names herein may also be registered and/or common law trademarks of Fortinet. All other product or company
names may be trademarks of their respective owners. Performance and other metrics contained herein were attained in internal lab tests under ideal conditions, and
actual performance and other results may vary. Network variables, different network environments and other conditions may affect performance results. Nothing herein
represents any binding commitment by Fortinet, and Fortinet disclaims all warranties, whether express or implied, except to the extent Fortinet enters a binding written
contract, signed by Fortinet’s General Counsel, with a purchaser that expressly warrants that the identified product will perform according to certain expressly-identified
performance metrics and, in such event, only the specific performance metrics expressly identified in such binding written contract shall be binding on Fortinet. For
absolute clarity, any such warranty will be limited to performance in the same ideal conditions as in Fortinet’s internal lab tests. In no event does Fortinet make any
commitment related to future deliverables, features, or development, and circumstances may change such that any forward-looking statements herein are not accurate.
Fortinet disclaims in full any covenants, representations,and guarantees pursuant hereto, whether express or implied. Fortinet reserves the right to change, modify,
transfer, or otherwise revise this publication without notice, and the most current version of the publication shall be applicable.

FortiWeb 6.0 Study Guide-Online

Uploaded by

Document Information

Copyright

Available Formats

Share this document

Share or Embed Document

Sharing Options

Did you find this document useful?

Is this content inappropriate?

Copyright:

Available Formats

FortiWeb 6.0 Study Guide-Online

Uploaded by

Copyright:

Available Formats

DO NOT REPRINT

FortiWeb Study Guide

Fortinet Network Security Expert Program (NSE)

FortiWeb 6.0 Study Guide 4

FortiWeb 6.0 Study Guide 5

FortiWeb 6.0 Study Guide 6

FortiWeb 6.0 Study Guide 7

FortiWeb 6.0 Study Guide 8

A layered security approach provides a better defense and better speed.

FortiWeb 6.0 Study Guide 9

FortiWeb 6.0 Study Guide 10

FortiWeb 6.0 Study Guide 11

Good job! You now understand FortiWeb’s key features.

FortiWeb 6.0 Study Guide 12

FortiWeb 6.0 Study Guide 13

FortiWeb 6.0 Study Guide 14

FortiWeb 6.0 Study Guide 15

FortiWeb 6.0 Study Guide 16

FortiWeb 6.0 Study Guide 17

FortiWeb 6.0 Study Guide 18

FortiWeb 6.0 Study Guide 19

FortiWeb 6.0 Study Guide 20

FortiWeb 6.0 Study Guide 21

FortiWeb 6.0 Study Guide 22

FortiWeb 6.0 Study Guide 23

FortiWeb 6.0 Study Guide 24

FortiWeb 6.0 Study Guide 25

In contrast, when FortiWeb is operating in reverse proxy mode, blocking is reliable.

FortiWeb 6.0 Study Guide 26

FortiWeb 6.0 Study Guide 27

FortiWeb 6.0 Study Guide 28

FortiWeb 6.0 Study Guide 29

FortiWeb 6.0 Study Guide 30

FortiWeb 6.0 Study Guide 31

FortiWeb 6.0 Study Guide 32

FortiWeb 6.0 Study Guide 33

FortiWeb 6.0 Study Guide 34

FortiWeb 6.0 Study Guide 35

In FortiWeb Manager, FortiWeb configuration is organized in two parts:

FortiWeb 6.0 Study Guide 36

FortiWeb 6.0 Study Guide 37

FortiWeb 6.0 Study Guide 38

Now, you will learn about the available support resources.

FortiWeb 6.0 Study Guide 39

FortiWeb 6.0 Study Guide 40

FortiWeb 6.0 Study Guide 41

FortiWeb 6.0 Study Guide 42

Congratulations! You have completed this lesson.

FortiWeb 6.0 Study Guide 43

FortiWeb 6.0 Study Guide 44

FortiWeb 6.0 Study Guide 45

FortiWeb 6.0 Study Guide 46

FortiWeb 6.0 Study Guide 47

FortiWeb 6.0 Study Guide 48

FortiWeb 6.0 Study Guide 49

FortiWeb 6.0 Study Guide 50

FortiWeb 6.0 Study Guide 51

Can you find the misconfiguration?

FortiWeb 6.0 Study Guide 52

FortiWeb 6.0 Study Guide 53

FortiWeb 6.0 Study Guide 54

FortiWeb 6.0 Study Guide 55

In reverse proxy mode, start by configuring fine-grained objects, such as:

FortiWeb 6.0 Study Guide 56