DO NOT REPRINT
© FORTINET
 Error! No text of specified style in document.
FortiWeb 5.6.0
Study Guide
for FortiWeb 5.6.0
DO NOT REPRINT
© FORTINET
FortiWeb Study Guide
for FortiWeb 5.6.0
Last Updated: 28 June 2017
We would like to acknowledge the following major contributors: Martijn Duijm, Idan Soen, Rafael
Lehmani, Shiqiang Xu
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 © 2017 Fortinet, Inc. All rights reserved. Fortinet®, FortiGate®, FortiCare®, and
FortiGuard®, and certain other marks are registered trademarks of Fortinet, Inc., 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. 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.
DO NOT REPRINT
© FORTINET
Table of Contents
1 Introduction .........................................................................................................................4
2 Basic Setup .........................................................................................................................42
3 Integrating External SIEM ...................................................................................................101
4 Integrating Front-End SNAT and Load Balancing ..............................................................156
5 Denial of Service (DoS) and Defacement ...........................................................................184
6 Signatures, Sanitization, and Auto-Learning ......................................................................220
7 SSL / TLS ............................................................................................................................281
8 Authentication and Access Control .....................................................................................329
9 PCI DSS 3.0 Compliance....................................................................................................368
10 Caching and Compression.................................................................................................422
11 HTTP Routing, Rewriting, and Redirects ..........................................................................443
12 Troubleshooting ................................................................................................................473
DO NOT REPRINT
© FORTINET
 Introduction
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 Study Guide
4
DO NOT REPRINT
© FORTINET
 Introduction
In this lesson, we will explore the following topics:
• FortiWeb Overview
• Attack types and Deployment options
• Management Interfaces
• Support Resources
• Let’s begin by looking at the key features.
FortiWeb Study Guide
5
DO NOT REPRINT
© FORTINET
 Introduction
After completing this section, you should be able to:
• Define a Web Application Firewall (WAF)
• Learn the value of FortiWeb
• Describe the FortiWeb product family
• By understanding FortiWeb’s function, you will be better able to apply the FortiWeb in your network in
order to protect your critical Web Server resources.
FortiWeb Study Guide
6
DO NOT REPRINT
© FORTINET
 Introduction
What is a web application firewall (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, and 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.
FortiWeb Study Guide
7
DO NOT REPRINT
© FORTINET
 Introduction
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.
FortiWeb Study Guide
8
DO NOT REPRINT
© FORTINET
 Introduction
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.
FortiWeb Study Guide
9
DO NOT REPRINT
© FORTINET
 Introduction
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.
FortiWeb Study Guide
10
DO NOT REPRINT
© FORTINET
 Introduction
Great! You now understand FortiWeb’s key features.
Now, let’s explore Web Server attack types and ways in which we can deploy FortiWeb to protect against
these threats.
FortiWeb Study Guide
11
DO NOT REPRINT
© FORTINET
 Introduction
After completing this section, you should be able to:
• Understand when and where to add FortiWeb to your defense portfolio
• Choose the right operation mode
FortiWeb Study Guide
12
DO NOT REPRINT
© FORTINET
 Introduction
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- 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 back-end servers, such as FTP and SSH. Once you have deployed the FortiWeb device,
you can configure it from a web browser and terminal on your management computer, using its web UI and
CLI.
FortiWeb Study Guide
13
DO NOT REPRINT
© FORTINET
 Introduction
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.
FortiWeb Study Guide
14
DO NOT REPRINT
© FORTINET
 Introduction
FortiWeb solutions vary by the type of attack that they are meant to combat. A few of the FortiWeb solution
and attack combinations are summarized in 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.
FortiWeb Study Guide
15
DO NOT REPRINT
© FORTINET
 Introduction
In the previous slide, we discussed how cookies can be used to store attacks that are initiated by a different
client. Once a cookie is 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.
FortiWeb Study Guide
16
DO NOT REPRINT
© FORTINET
 Introduction
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. We’ll cover compliance
issues in a separate lesson.
FortiWeb Study Guide
17
DO NOT REPRINT
© FORTINET
 Introduction
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, its system software can be abused. This can be especially bad
if your web server is running as root or Administrator. Imagine an unknown person with superuser access to
your passwd or route –p add commands.
FortiWeb Study Guide
18
DO NOT REPRINT
© FORTINET
 Introduction
Heartbleed was an SSL/TLS attack that was responsible for a Canadian Revenue Agency web site 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.
FortiWeb Study Guide
19
DO NOT REPRINT
© FORTINET
 Introduction
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.
FortiWeb Study Guide
20
DO NOT REPRINT
© FORTINET
 Introduction
The attack types that we discussed in the previous slides were only some of the most common types of
attacks; there are many more that we did 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?
FortiWeb Study Guide
21
DO NOT REPRINT
© FORTINET
 Introduction
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 denial of service (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.
FortiWeb Study Guide
22
DO NOT REPRINT
© FORTINET
 Introduction
Let’s look at 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 back-end 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.
FortiWeb Study Guide
23
DO NOT REPRINT
© FORTINET
 Introduction
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.
FortiWeb Study Guide
24
DO NOT REPRINT
© FORTINET
 Introduction
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, that 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.
FortiWeb Study Guide
25
DO NOT REPRINT
© FORTINET
 Introduction
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.
FortiWeb Study Guide
26
DO NOT REPRINT
© FORTINET
 Introduction
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.
FortiWeb Study Guide
27
DO NOT REPRINT
© FORTINET
 Introduction
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 to 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.
FortiWeb Study Guide
28
DO NOT REPRINT
© FORTINET
 Introduction
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.
FortiWeb Study Guide
29
DO NOT REPRINT
© FORTINET
 Introduction
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 is 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 the 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.
FortiWeb Study Guide
30
DO NOT REPRINT
© FORTINET
 Introduction
Great! You now understand the threat landscape and how to best deploy FortiWeb to protect your Web
Servers.
Now, let’s take a look at the management interfaces FortiWeb has available to us.
FortiWeb Study Guide
31
DO NOT REPRINT
© FORTINET
 Introduction
In this section, you will:
• Describe the various management access methods
FortiWeb Study Guide
32
DO NOT REPRINT
© FORTINET
 Introduction
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.
FortiWeb Study Guide
33
DO NOT REPRINT
© FORTINET
 Introduction
FortiWeb Manager centralizes the configuration of FortiWeb appliances. Its web UI replaces the local
interfaces on FortiWeb appliances in 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
appliance. The configuration you install using FortiWeb Manager replaces any default or existing configuration
on the remote appliance. 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 package,s as needed.
To update configurations you installed using policy packages, edit the configuration objects and policies as
needed, and then install the updated package.
FortiWeb Study Guide
34
DO NOT REPRINT
© FORTINET
 Introduction
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 when you add it.
• 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:
• 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 UI 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.
FortiWeb Study Guide
35
DO NOT REPRINT
© FORTINET
 Introduction
Fantastic! You now know the various Management Interface options available for managing your FortiWeb
devices.
Now let’s take a look at the available support resources.
FortiWeb Study Guide
36
DO NOT REPRINT
© FORTINET
 Introduction
In this section you will learn how to:
• Find and Use Support Resources
FortiWeb Study Guide
37
DO NOT REPRINT
© FORTINET
 Introduction
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 source of information that can
help you with your implementation.
FortiWeb Study Guide
38
DO NOT REPRINT
© FORTINET
 Introduction
Like in other Fortinet products, clicking the help button in FortiWeb will jump to the right page in the
documentation. It gives how-to examples, feature overviews, and detailed references of specific options.
FortiWeb Study Guide
39
DO NOT REPRINT
© FORTINET
 Introduction
Congratulations! You have now completed this lesson.
FortiWeb Study Guide
40
DO NOT REPRINT
© FORTINET
 Introduction
Now that we have completed this lesson, you should be able to:
• Define what a Web Application Firewall is
• Describe the value of FortiWeb
• Describe the FortiWeb product family
• Understand when and where you can add FortiWeb to your defense portfolio
• Choose the right FortiWeb operation mode
• Understand the various management access methods
• Find and use support resources
FortiWeb Study Guide
41
DO NOT REPRINT
© FORTINET
 Basic Setup
In this lesson, you’ll learn how to physically deploy your FortiWeb and complete basic settings so that you
can begin to integrate it into your network.
FortiWeb Study Guide
42
DO NOT REPRINT
© FORTINET
 Basic Setup
In this lesson, we will explore the following topics:
• Topology
• Nesting of Configuration Components
• Initial Configuration
• Routing FTP/SSH to the Back-End
• Proxy Pickup and Connection Termination
• Load Balancing and Pass Through
• Virtual Hosts
By the end of this lesson you will be able to perform a basic deployment of FortiWeb in a variety of network
topologies.
FortiWeb Study Guide
43
DO NOT REPRINT
© FORTINET
 Basic Setup
First, we’ll take a look at physical and logical topology. In this section we will:
• Define and discuss possible topologies and implementation scenarios
FortiWeb Study Guide
44
DO NOT REPRINT
© FORTINET
 Basic Setup
If you’re using FortiWeb VM in a cloud, much of the physical topology may either be 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.
FortiWeb Study Guide
45
DO NOT REPRINT
© FORTINET
 Basic Setup
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 source NAT, but FortiWeb hasn’t been configured to handle this.
As a result of the misconfiguration, whenever an attack occurs, FortiWeb blocks sessions from the FortiADC,
breaking all connectivity.
FortiWeb Study Guide
46
DO NOT REPRINT
© FORTINET
 Basic Setup
There are two solutions you can use if you have upstream source NAT. The following is one solution:
Configure the upstream NAT device to put the original client’s IP address in an HTTP header such as XForwarded-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?
FortiWeb Study Guide
47
DO NOT REPRINT
© FORTINET
 Basic Setup
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.
FortiWeb Study Guide
48
DO NOT REPRINT
© FORTINET
 Basic Setup
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 source NAT, the administrator has enabled load balancing and configured two
virtual servers. The 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. Since the 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 running 5.3.4 wouldn’t use the X-header for those private
IP addresses.
FortiWeb Study Guide
49
DO NOT REPRINT
© FORTINET
 Basic Setup
Great! Now you have an understanding of the various network topologies possible with FortiWeb.
In the next section we will discuss the nesting of configuration components, which is the logic of configuring a
FortiWeb
FortiWeb Study Guide
50
DO NOT REPRINT
© FORTINET
 Basic Setup
Once you’ve decided on a physical and logical topology, you’ll log in and begin to configure FortiWeb. Where
should you start? Understanding which configuration objects are used by other configuration object will help
you determine where to start. After this lesson you will:
• Understand configuration objects and basic configuration logic
FortiWeb Study Guide
51
DO NOT REPRINT
© FORTINET
 Basic Setup
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.
FortiWeb Study Guide
52
DO NOT REPRINT
© FORTINET
 Basic Setup
In transparent inspection mode or true transparent proxy mode, most is similar. The most 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.
FortiWeb Study Guide
53
DO NOT REPRINT
© FORTINET
 Basic Setup
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.
FortiWeb Study Guide
54
DO NOT REPRINT
© FORTINET
 Basic Setup
Good Job! You should now have an understanding of the logic behind the FortiWeb configuration process.
Next, we will look at creating an Initial configuration
FortiWeb Study Guide
55
DO NOT REPRINT
© FORTINET
 Basic Setup
Now that learned the basics about how objects link together, you can start to configure FortiWeb. In this
section you will learn to:
• Describe and perform initial configuration tasks and procedures
• Configure Administrative Groups, profiles and accounts
• Configure Operating mode
• Configure Network Interfaces and Routing
• Describe and Configure High Availability
• Discuss FortiGuard Services
FortiWeb Study Guide
56
DO NOT REPRINT
© FORTINET
 Basic Setup
This slide shows simple setup steps. In reverse proxy, once you have completed these steps, traffic will flow
through FortiWeb, you will be ready to begin applying security.
FortiWeb Study Guide
57
DO NOT REPRINT
© FORTINET
 Basic Setup
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!
FortiWeb Study Guide
58
DO NOT REPRINT
© FORTINET
 Basic Setup
Group queries so that you can use them when creating new accounts.
FortiWeb Study Guide
59
DO NOT REPRINT
© FORTINET
 Basic Setup
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 admin 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.
FortiWeb Study Guide
60
DO NOT REPRINT
© FORTINET
 Basic Setup
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 only respond to 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 – useful for anyone that wants to brute force your network security!
IPv6 is different. FortiWeb will only respond if you define a trusted host or subnet, so you can leave them
empty.
FortiWeb Study Guide
61
DO NOT REPRINT
© FORTINET
 Basic Setup
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 would overwrite any configuration changes made before. 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. You’ll learn more about ADOMs when we cover external logging.
FortiWeb Study Guide
62
DO NOT REPRINT
© FORTINET
 Basic Setup
Be sure to set your time zone. To ensure that time setting remains accurate, allow your FortiWeb to connect
to an NTP server so that it can keep its clock in sync.
FortiWeb Study Guide
63
DO NOT REPRINT
© FORTINET
 Basic Setup
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.
FortiWeb Study Guide
64
DO NOT REPRINT
© FORTINET
 Basic Setup
If you switch to transparent mode, FortiWeb’s network settings are reset. So it’s best to make this switch from
the CLI or before you configure your network settings and HA.
FortiWeb Study Guide
65
DO NOT REPRINT
© FORTINET
 Basic Setup
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.
FortiWeb Study Guide
66
DO NOT REPRINT
© FORTINET
 Basic Setup
If are going to use FortiWeb HA, you would configure it at this point. To configure HA, you must have two
identical FortiWeb models with the same firmware. Only active-passive HA is supported; active-active is
usually implemented externally, using a FortiADC load balancer, for example.
Since the standby FortiWeb has no management IP, you need to configure any device-specific settings first,
before you enable HA. This includes configuring the host name and HA priority. Then, you enable HA. That
way, as you continue to configure settings, 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.
FortiWeb Study Guide
67
DO NOT REPRINT
© FORTINET
 Basic Setup
HA on FortiWeb behaves similarly to how it does on other Fortinet devices. If the heartbeat fails or a
monitored port does not respond, then the standby FortiWeb uses ARP to advertise to the network that the
FortiWeb virtual MAC 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.
FortiWeb Study Guide
68
DO NOT REPRINT
© FORTINET
 Basic Setup
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 FortiWeb VM has priority.
FortiWeb Study Guide
69
DO NOT REPRINT
© FORTINET
 Basic Setup
Link two ports that HA will use to communicate – directly, if possible – then 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 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.
FortiWeb Study Guide
70
DO NOT REPRINT
© FORTINET
 Basic Setup
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!
FortiWeb Study Guide
71
DO NOT REPRINT
© FORTINET
 Basic Setup
Fail-open is available only 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 — Behave as a wire when the FortiWeb appliance is powered off. This allows
connections to pass directly from one port to the other, bypassing all policy scans and modifications.
PowerOff-Cutoff — Interrupt connectivity when the FortiWeb appliance is powered off. The bypass is
disabled. This is the default setting.
Alternatively, you can use FortiBridge.
FortiWeb Study Guide
72
DO NOT REPRINT
© FORTINET
 Basic Setup
The next step is to configure network interfaces, and set which administrative protocols are enabled on
interface. If you’re deploying in a cloud, such as Amazon Web Services, use DHCP instead of the usual: a
static IP address.
FortiWeb Study Guide
73
DO NOT REPRINT
© FORTINET
 Basic Setup
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.
FortiWeb Study Guide
74
DO NOT REPRINT
© FORTINET
 Basic Setup
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.
FortiWeb Study Guide
75
DO NOT REPRINT
© FORTINET
 Basic Setup
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.
FortiWeb Study Guide
76
DO NOT REPRINT
© FORTINET
 Basic Setup
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.
FortiWeb Study Guide
77
DO NOT REPRINT
© FORTINET
 Basic Setup
Excellent! You now know how to perform an Initial configuration of a FortiWeb.
In the next section we will look at how FortiWeb can address FTP and SSH.
FortiWeb Study Guide
78
DO NOT REPRINT
© FORTINET
 Basic Setup
Next, you’ll establish connectivity through FortiWeb. As mentioned previously, FortiWeb only scans HTTP.
However, FortiWeb can act as a router or bridge for other protocols. When functioning as a router, FortiWeb
forwards packets that are destined for your web servers’ IPs. If you do use FortiWeb as a router, use caution.
An upstream firewall such as FortiGate should scan FTP or SSH connections to your web servers.
In this section we will learn how to:
• Route FTP and other non-HTTP protocols through FortiWeb
FortiWeb Study Guide
79
DO NOT REPRINT
© FORTINET
 Basic Setup
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 back-end servers – not FortiWeb’s virtual server.
FortiWeb Study Guide
80
DO NOT REPRINT
© FORTINET
 Basic Setup
If you’re using transparent mode, no configuration is required. FortiWeb will allow 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.
FortiWeb Study Guide
81
DO NOT REPRINT
© FORTINET
 Basic Setup
Good job! You now know how to allow FortiWeb to deal with FTP and SSH
Next, let’s look at FortiWeb in conjunction with Proxies.
FortiWeb Study Guide
82
DO NOT REPRINT
© FORTINET
 Basic Setup
We’ve just shown that FortiWeb only proxies HTTP. It doesn’t pick up other protocols, and in reverse proxy
mode, which forwards as a Layer 3 router, it will only forward non-HTTP packets if you enable IP-based
forwarding.
What is required for HTTP traffic flow? In this section we will:
• Describe and Discuss forwarding HTTP through FortiWeb
FortiWeb Study Guide
83
DO NOT REPRINT
© FORTINET
 Basic Setup
In transparent mode, FortiWeb forwards as a Layer 2 device. So, by default, web traffic passes through. If
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 servers – a NATted 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.
FortiWeb Study Guide
84
DO NOT REPRINT
© FORTINET
 Basic Setup
This table shows some basics of how traffic flow, proxy pickup, blocking styles, and SSL termination all vary
by operating mode.
FortiWeb Study Guide
85
DO NOT REPRINT
© FORTINET
 Basic Setup
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
web sites, for example, you may need to define web services on other port numbers, such as port 8080.
FortiWeb Study Guide
86
DO NOT REPRINT
© FORTINET
 Basic Setup
Great! You now know how FortiWeb can be configured to deal with Proxies.
Now let’s take a look at dealing with Load Balancers in the network.
FortiWeb Study Guide
87
DO NOT REPRINT
© FORTINET
 Basic Setup
After FortiWeb has picked up traffic, how do you define where it should send the traffic? In this section we will:
• Describe and Discuss Server Polls
• Describe and Discuss Load Balancing
• Describe and Discuss Session Persistence
FortiWeb Study Guide
88
DO NOT REPRINT
© FORTINET
 Basic Setup
You define your destination back-end 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, or
• 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.
FortiWeb Study Guide
89
DO NOT REPRINT
© FORTINET
 Basic Setup
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 balancing load, to use FortiWeb as a Layer 7 switch. This sends requests 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.
FortiWeb Study Guide
90
DO NOT REPRINT
© FORTINET
 Basic Setup
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.
FortiWeb Study Guide
91
DO NOT REPRINT
© FORTINET
 Basic Setup
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 you session doesn’t have a cookie, FortiWeb can inject its own load balancing
session cookie, and use it to track the sessions.
FortiWeb Study Guide
92
DO NOT REPRINT
© FORTINET
 Basic Setup
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.
FortiWeb Study Guide
93
DO NOT REPRINT
© FORTINET
 Basic Setup
Excellent! You now know how to implement FortiWeb in the network when Load Balancers are in use.
In the final section we will look at Virtual Hosts.
FortiWeb Study Guide
94
DO NOT REPRINT
© FORTINET
 Basic Setup
You can also restrict proxy pickup by the domain name in the Host header in the HTTP layer.
Some web servers have web sites for several domains. In Apache, for example, you might configure a few
virtual hosts for low-volume web sites on the same hardware, and the same IP address, if you are a hosting
provider. For a larger-scale solution, you can use host name definitions on FortiWeb to route HTTP traffic.
Like other objects, configure host names before you configure the server policy.
In this section you will:
• Describe and Discuss Protected Hostnames
• Configure Server Policies
FortiWeb Study Guide
95
DO NOT REPRINT
© FORTINET
 Basic Setup
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.
FortiWeb Study Guide
96
DO NOT REPRINT
© FORTINET
 Basic Setup
Here’s an example of how you can use a protected host names 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, for example, block a request to
http://example.co.uk since 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 host name to the list and set its Action setting to Accept. The request
could still be blocked by a later scan – antivirus, for example – but it would not be due to its host name.
FortiWeb Study Guide
97
DO NOT REPRINT
© FORTINET
 Basic Setup
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 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.
FortiWeb Study Guide
98
DO NOT REPRINT
© FORTINET
 Basic Setup
Congratulations! You have successfully completed this lesson.
FortiWeb Study Guide
99
DO NOT REPRINT
© FORTINET
 Basic Setup
In this lesson, we covered how to integrate FortiWeb in networks where an upstream device applies source
NAT. On FortiGate, this can be done with a virtual server, which is a special type of virtual IP. We also talked
about how FortiGate can use a virtual IP to forward FTP, RDP, or SSH to FortiWeb, and FortiWeb can route it
to the web servers. Last, we showed how to configure FortiWeb for basic traffic flow and load balancing.
Specifically, we discussed:
•
•
•
•
Physical cabling
Source NAT effects
Configuring FortiGate to forward traffic
Initial Setup, including:
• Administrator accounts
• Operation mode
• Network settings and time
• HA
• Bypass and fail-open
• Virtual server, services, v-zones
• Load distribution and session persistence using Client IP or session cookie
• Routing non-HTTP protocols
• Protected hostnames
FortiWeb Study Guide
100
DO NOT REPRINT
© FORTINET
 Integrating External SIEM
In this lesson, you’ll learn about special deployment considerations, such as the following:
• When you should log to an external server or device
• How to support multi-tenant deployments
FortiWeb Study Guide
101
DO NOT REPRINT
© FORTINET
 Integrating External SIEM
In this lesson we will explore the following topics:
• Administrative Domains
• Integrating external logging and reporting
• Setup on FortiAnalyzer
• Setup on FortiWeb
• Testing log connectivity
• Centralized alerts
• Custom reports
FortiWeb Study Guide
102
DO NOT REPRINT
© FORTINET
 Integrating External SIEM
In this section we will:
• Describe and Discuss Administrative Domains
• Compare and Contrast ADOMs and VDOMs
FortiWeb Study Guide
103
DO NOT REPRINT
© FORTINET
 Integrating External SIEM
First, let’s talk about administrative domains (ADOMs). ADOMs can be useful to divide up 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 so although
they may look and act mostly like FortiGate VDOMs, they are not true virtual domains.
ADOMs on FortiWeb subdivide the configuration. You can allocate separate access by web applications,
customers, or other logical divisions.
When you’re logging to an external device, such as a FortiAnalyzer, ADOMs can subdivide access to logs and
filter the data used in reports. If you enable ADOMs on FortiWeb, be sure to enable the Advanced ADOM
mode on FortiAnalyzer too, so that your FortiWeb ADOMs appear in the FortiAnalyzer device list.
FortiWeb Study Guide
104
DO NOT REPRINT
© FORTINET
 Integrating External SIEM
Enabling ADOMs is simple. You can do it from the dashboard in the System Information widget.
FortiWeb Study Guide
105
DO NOT REPRINT
© FORTINET
 Integrating External SIEM
When you enable ADOMs, some settings apply to the entire FortiWeb – regardless of ADOM – such as the
admin account and firmware updates. But, most settings are specific to each ADOM, so you must create at
least one ADOM that will contain policies, certificates, and so on.
FortiWeb Study Guide
106
DO NOT REPRINT
© FORTINET
 Integrating External SIEM
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.
FortiWeb Study Guide
107
DO NOT REPRINT
© FORTINET
 Integrating External SIEM
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 each the access of 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.
FortiWeb Study Guide
108
DO NOT REPRINT
© FORTINET
 Integrating External SIEM
Excellent! You now know the understand the purpose and characteristics of Administrative Domains.
In the next section we will discuss integrating external logging and reporting.
FortiWeb Study Guide
109
DO NOT REPRINT
© FORTINET
 Integrating External SIEM
If you enable ADOMs, the way that you query logs in order to build custom reports on FortiAnalyzer or other
SIEMs changes. Let’s take a look.
In this section we will:
• Describe and Discuss the benefits of and reasons for external logging
FortiWeb Study Guide
110
DO NOT REPRINT
© FORTINET
 Integrating External SIEM
Logging externally is a FortiWeb best practice. Why? FortiWeb can store logs locally on its hard disk, or in
RAM, but logging externally the following benefits:
• Flexibility for reporting
• Better performance
• Better scalability
• Visibility for multi-device attack correlation
FortiWeb Study Guide
111
DO NOT REPRINT
© FORTINET
 Integrating External SIEM
Great! You now know why we would want to integrate external logging and reporting.
In the next section we will look at configuring the FortiAnalyzer as an external SIEM.
FortiWeb Study Guide
112
DO NOT REPRINT
© FORTINET
 Integrating External SIEM
Now you will learn how to configure logging and custom reports with FortiAnalyzer; however, you could apply
many of the concepts you will learn in this lesson to any third-party event logging and reporting system.
FortiWeb Study Guide
113
DO NOT REPRINT
© FORTINET
 Integrating External SIEM
These are the basic steps to you need to perform to configure both devices to interoperate.
•
•
•
•
•
On FortiAnalyzer, enable administrative domains. To support FortiWeb ADOMs, also enable the
Advanced ADOM option.
Create a new ADOM specifically for FortiWeb 5.2 or later devices. This will initialize a new database
according to the schema that is required to store FortiWeb logs, which are different than FortiGate logs.
FortiWeb logs, for example, can include HTTP session IDs.
Add FortiWeb to FortiAnalyzer’s device list so that it is allowed to store logs, and has an assigned disk
quota.
Optionally, configure centralized alert email and custom report queries.
On FortiWeb, enter your FortiAnalyzer’s device IP, add it to a notification settings object, and configure
which events and severities should be sent to FortiAnalyzer.
FortiWeb Study Guide
114
DO NOT REPRINT
© FORTINET
 Integrating External SIEM
Let’s see the setup in action. This slide shows how to enable ADOMs on FortiAnalyzer.
FortiWeb Study Guide
115
DO NOT REPRINT
© FORTINET
 Integrating External SIEM
Next, you create a new ADOM. On FortiAnalyzer, ADOMs do more than just separate administrators for each
user’s data. Choosing an ADOM also specifies the schema of a new database, and indicates which schema
its tables will use. Log schemas vary by Fortinet device.
FortiWeb Study Guide
116
DO NOT REPRINT
© FORTINET
 Integrating External SIEM
Next, you add your FortiWeb IP, Serial Number, Device Name, and Device Model to the new database. The
device list control occurs by serial number and IP.
FortiWeb Study Guide
117
DO NOT REPRINT
© FORTINET
 Integrating External SIEM
Log schemas also vary by device version. Just like its other features, FortiWeb logs have evolved over time,
so older firmware doesn’t produce the same logs. This determines whether incoming log fields each have a
column in the tables. Logs must fit the tables correctly in order for reports to function. For example, if you
choose the wrong schema, or indicate the wrong firmware version, and there is no column to store HTTP
session IDs and attack subtypes, FortiAnalyzer will not be able to store that part of FortiWeb traffic and attack
logs. Report datasets that require it will fail. I the example shown in this slide, you need to select the schema
for FortiWeb 5.6 log formats.
FortiWeb Study Guide
118
DO NOT REPRINT
© FORTINET
 Integrating External SIEM
When you register FortiWeb, FortiAnalyzer does not use the admin account credentials, and it does not create
an OFTP registration connection back to FortiWeb. FortiGate does, but most other Fortinet devices don’t. This
simplifies connectivity – your firewall policies only need to allow one-way UDP syslog traffic from FortiWeb to
FortiAnalyzer.
If your FortiAnalyzer is located on a remote network, remember to make an IPsec VPN tunnel from the frontend FortiGate to the remote network’s FortiGate. Syslog is a clear-text protocol, and FortiWeb logs contain
sensitive network security information.
FortiWeb Study Guide
119
DO NOT REPRINT
© FORTINET
 Integrating External SIEM
Now FortiAnalyzer should initialize the database for this specific FortiWeb, preparing it to store log data.
When done, a success message should appear. Click Finish.
FortiWeb Study Guide
120
DO NOT REPRINT
© FORTINET
 Integrating External SIEM
As a quick review, here’s what matters when configuring FortiWeb and FortiAnalyzer to work together.
•
•
•
•
The FortiAnalyzer firmware must be compatible with FortiWeb. An old FortiAnalyzer won’t support the logs
of new FortiWeb firmware if the log format has changed.
Remember to enable ADOMs, and create one specifically for FortiWeb.
Add FortiWeb to the allowed device list.
Test connectivity. If there are firewalls in between, policies must allow UDP syslog traffic from FortiWeb to
FortiAnalyzer.
FortiWeb Study Guide
121
DO NOT REPRINT
© FORTINET
 Integrating External SIEM
Good Job! In this section you performed a basic configuration of FortiAnalyzer to work with ForitWeb.
Next we will look at configuring the FortiWeb itself
FortiWeb Study Guide
122
DO NOT REPRINT
© FORTINET
 Integrating External SIEM
Next, you will learn how to configure logging – especially remote logging – on FortiWeb.
FortiWeb Study Guide
123
DO NOT REPRINT
© FORTINET
 Integrating External SIEM
First, define the IP address of a FortiAnalyzer. This is where FortiWeb will send logs, if you’ve selected that
destination, and they match the type, severity, and other criteria.
FortiWeb Study Guide
124
DO NOT REPRINT
© FORTINET
 Integrating External SIEM
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.
FortiWeb Study Guide
125
DO NOT REPRINT
© FORTINET
 Integrating External SIEM
Now enable event and traffic log output 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 configuring, 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 to 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.
FortiWeb Study Guide
126
DO NOT REPRINT
© FORTINET
 Integrating External SIEM
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.
FortiWeb Study Guide
127
DO NOT REPRINT
© FORTINET
 Integrating External SIEM
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.
FortiWeb Study Guide
128
DO NOT REPRINT
© FORTINET
 Integrating External SIEM
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.
FortiWeb Study Guide
129
DO NOT REPRINT
© FORTINET
 Integrating External SIEM
Excellent! You have now configured logging on FortiWeb.
In the next section we will confirm the connectivity between FortiWeb and FortiAnalyzer.
FortiWeb Study Guide
130
DO NOT REPRINT
© FORTINET
 Integrating External SIEM
Now you're ready to test logging.
FortiWeb Study Guide
131
DO NOT REPRINT
© FORTINET
 Integrating External SIEM
This slide lists the easiest ways to test connectivity for each log type that FortiWeb can generate.
Ideally, you want to load test logging to make sure that the network is not dropping logs at crucial times such
as during traffic spikes or distributed denial of service attacks. If this is the case, analyze the available
bandwidth, but also the processing capacity of your FortiAnalyzer, FortiWeb, and all routers and switches
between. For even stronger robustness in DDoS attacks, you can also insert a FortiDDoS in front of your
FortiWeb. Its specialized hardware is built to handle massive numbers of transactions, and analyze traffic
anomalies with speed.
FortiWeb Study Guide
132
DO NOT REPRINT
© FORTINET
 Integrating External SIEM
When you log in to FortiAnalyzer again, you should notice a green icon in the Logs column when viewing the
device list. The green icon indicates that FortiAnalyzer recently received a log message from FortiWeb, so
connectivity was successful.
FortiWeb Study Guide
133
DO NOT REPRINT
© FORTINET
 Integrating External SIEM
If you configured event handling, you can use it to view logs. But, you can also use the Log View menu. To
drill down and view the details of a log, double-click the row that log is in.
FortiWeb Study Guide
134
DO NOT REPRINT
© FORTINET
 Integrating External SIEM
Great! We have now confirmed that FortiWeb is sending log data to the FortiAnalyzer.
In the next section we will look at using that data to generate centralized alerts
FortiWeb Study Guide
135
DO NOT REPRINT
© FORTINET
 Integrating External SIEM
If you have many network devices, it’s often more convenient to configure alerts from one central location,
rather than on each device individually. You can do this on FortiAnalyzer.
In this section you will learn to configure centralized alerts.
FortiWeb Study Guide
136
DO NOT REPRINT
© FORTINET
 Integrating External SIEM
FortiAnalyzer offers more granular ways than FortiWeb to define what will trigger an alert email.
FortiWeb Study Guide
137
DO NOT REPRINT
© FORTINET
 Integrating External SIEM
To configure event handlers, go to the Event Management tab and select your FortiWeb ADOM. Just like log
storage, event options vary by the log schema.
FortiWeb Study Guide
138
DO NOT REPRINT
© FORTINET
 Integrating External SIEM
You don’t have to receive one email for every incident. In continuous scripted attacks, or DDOS attacks, this
could result in a deluge of email. To avoid that, specify the alert interval.
FortiWeb Study Guide
139
DO NOT REPRINT
© FORTINET
 Integrating External SIEM
Unlike on FortiWeb, selecting the event’s Severity on FortiAnalyzer does not filter the logs. On FortiAnalyzer,
use the Generic Text Filter field to specify a SQL filter.
FortiWeb Study Guide
140
DO NOT REPRINT
© FORTINET
 Integrating External SIEM
Indicating how severe the messages are on FortiAnalyzer simply allows you to color-code their entries in the
Event Management tab.
FortiWeb Study Guide
141
DO NOT REPRINT
© FORTINET
 Integrating External SIEM
If you double-click an alert event, you can view the log message’s fields, such as which host and URL was
attacked.
FortiWeb Study Guide
142
DO NOT REPRINT
© FORTINET
 Integrating External SIEM
If you simply want to view all chronological logs of the attack or event log type, instead of filtering them and
using them to generate alert email, go to the “LogView” tool instead.
FortiWeb Study Guide
143
DO NOT REPRINT
© FORTINET
 Integrating External SIEM
Good job! You now know how to have FortiAnalyzer generate centralized alerts for your FortiWeb
In the final section we will learn to generate customized reports.
FortiWeb Study Guide
144
DO NOT REPRINT
© FORTINET
 Integrating External SIEM
Once FortiAnalyzer is receiving and storing your FortiWeb logs, you can start to generate reports. Custom
reports are a challenge for many FortiAnalyzer beginners, and FortiWeb’s queries are different from
FortiGate’s. In this lesson, you’ll learn the basics of how to make a report specifically for FortiWeb, and how to
customize the SQL query to show precisely what you want.
FortiWeb Study Guide
145
DO NOT REPRINT
© FORTINET
 Integrating External SIEM
We’ve already explained a little of how FortiWeb sends log messages, and how FortiAnalyzer stores log
messages in its database: it splits each log message, and stores each log field in a corresponding table
column.
After storing logs, you’ll eventually want to search them, or make a report.
To do this, you run SQL queries using FortiAnalyzer. These queries select specific columns – mostly these
match the name of log fields, but not always – and sometimes recasts them as a different datatype, if
required. Each query returns a dataset: the logs matching the query criteria, in the format and order specified.
In the case of a search, FortiAnalyzer shows the dataset in the GUI. But for reports, it compiles and sorts
data, cross-references it if applicable, and then renders graphs and tables in a document.
FortiWeb Study Guide
146
DO NOT REPRINT
© FORTINET
 Integrating External SIEM
Now, let’s look at an example of how to configure a custom report on FortiAnalyzer. We’ll begin by creating a
new report, or cloning one of the defaults.
FortiWeb Study Guide
147
DO NOT REPRINT
© FORTINET
 Integrating External SIEM
In the Configuration tab for the report, you can filter by time period, FortiWeb serial number, and FortiWeb
ADOM. These correspond to the timestamp, device ID, and ADOM fields in logs sent by FortiWeb.
If you’ve just begun to send logs to FortiAnalyzer, you may need to restrict the report’s time period to Today
since there haven’t been seven days’ worth of logs yet.
FortiWeb Study Guide
148
DO NOT REPRINT
© FORTINET
 Integrating External SIEM
On the report’s Settings tab, you can filter by all of the other log fields. Since we specified the FortiWeb 5.6 log
schema when we created the device list entry, the filter list includes many FortiWeb-specific log fields, such
as the HTTP status code that the web server replied with, or the URL that was requested.
To filter correctly, the value must match the entire string in that log field exactly. If you’re not sure what the
value would be, search for a sample log, and then copy and paste its value.
Here, we’ve included only log messages for server replies that were not 200 – that is, we’re including only
error messages in the report.
FortiWeb Study Guide
149
DO NOT REPRINT
© FORTINET
 Integrating External SIEM
Once you’ve defined the dataset, you need to define how the report will display it. You can do that on the
Layout tab.
FortiWeb Study Guide
150
DO NOT REPRINT
© FORTINET
 Integrating External SIEM
If you click the options for a chart that you’re including in the report, you can specify:
• Which dataset should be used to make the chart
• Which row or column should be bound to each X-axis or Y-axis
You can even add additional dataset filters. Report contents can be filtered at multiple levels, so if you don’t
see what you expect, check all filters.
If you’ve made a custom dataset – that is, a custom report query – this is where you select it. Custom queries
should be tested after each FortiAnalyzer or FortiWeb upgrade. Due to their individual nature, upgrade scripts
cannot be guaranteed to upgrade the custom queries correctly. To customize a dataset, you can start by
cloning and modifying its SQL query. Be sure to test the query so that reports will contain the data that you
expect, and omit data that should not be included. To write a completely new dataset, it’s helpful to download
the FortiAnalyzer database schema. If you don’t know SQL, many references are available. For example,
depending on the device and version, you may need to query for destination IP addresses by the column
name dstip instead of its log field name, dst. You may also need to cast it as an IP address type, instead of a
simple string. Schema and SQL references will help you to do both.
FortiWeb Study Guide
151
DO NOT REPRINT
© FORTINET
 Integrating External SIEM
Finally, run the report. You can either do this manually, by clicking the Run Report Now button, or scheduling
when FortiAnalyzer will automatically compile the dataset and generate the report.
FortiWeb Study Guide
152
DO NOT REPRINT
© FORTINET
 Integrating External SIEM
When the report is complete, whether it was triggered manually or automatically (that is, by schedule), it
appears here.
If you chose email as an output, it should also arrive at your inbox. If it doesn’t, first make sure that your spam
filters haven’t caught it – adding FortiAnalyzer’s sender email address to your address book often helps. If
that’s not the problem, verify that your firewall isn’t blocking SMTP from FortiAnalyzer, and verify that your
FortiAnalyzer’s settings for authentication and encryption match those of your email server. Attachment size is
rarely an issue, but could be something to check too. Email servers can reject send attempts for many
reasons.
FortiWeb Study Guide
153
DO NOT REPRINT
© FORTINET
 Integrating External SIEM
Congratulations! You have successfully complete this lesson.
FortiWeb Study Guide
154
DO NOT REPRINT
© FORTINET
 Integrating External SIEM
In this lesson, you learned:
•
•
•
•
•
ADOMs – Segregation of Duties or Customers
Why External Logging?
Configuring FortiAnalyzer to receive logs from FortiWeb
• Database schema specific to logs for FortiWeb
Configuring FortiWeb to send logs to FortiAnalyzer
Configuring event handlers & reports on FortiAnalyzer
• Custom SQL queries
FortiWeb Study Guide
155
DO NOT REPRINT
© FORTINET
 Integrating Front-End SNAT and Load Balancers
In this lesson, we’ll talk about special deployment considerations:
• Where should you put FortiWeb between your firewall and your servers?
• Should you use built-in load balancing, or an external load balancer?
FortiWeb Study Guide
156
DO NOT REPRINT
© FORTINET
 Integrating Front-End SNAT and Load Balancers
In this lesson we will discuss:
• External load balancers
• Setup on FortiWeb
• Setup on the front-end FortiGate
• Setup on FortiADC
FortiWeb Study Guide
157
DO NOT REPRINT
© FORTINET
 Integrating Front-End SNAT and Load Balancers
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, since by default, most of its features block based upon the IP layer’s source address. So you must
configure both FortiGate and FortiWeb correctly to avoid this. Notice that this is specific to NAT. If your frontend 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. We’ll show those 2 different deployments in a minute.
FortiWeb Study Guide
158
DO NOT REPRINT
© FORTINET
 Integrating Front-End SNAT and Load Balancers
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 Xheader (usually X-Real-IP: or X-Forwarded-For:) so that FortiWeb blocks clients based upon the request’s
original source IP, not the current source IP (which is the load balancer).
FortiWeb X-headers now support IPv6, so this 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 upon an HTTP-layer session cookie, or by deriving the original client’s IP from
the X-header.
FortiWeb Study Guide
159
DO NOT REPRINT
© FORTINET
 Integrating Front-End SNAT and Load Balancers
Great! You now know the reasons for using an external load balancer and how they impact FortiWeb
deployment.
In the next section we will look at how to configure the FortiWeb to work with a load balancer.
FortiWeb Study Guide
160
DO NOT REPRINT
© FORTINET
 Integrating Front-End SNAT and Load Balancers
In this section you will:
• Configure FortiWeb to function behind an SNAT device
FortiWeb Study Guide
161
DO NOT REPRINT
© FORTINET
 Integrating Front-End SNAT and Load Balancers
Once you have configured your upstream or downstream NAT device to read or send X-headers, configure
your FortiWeb to use them. The red outlines on the slide highlight the settings that you need to configure, if
your load balancer is positioned upstream. If it’s 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.
FortiWeb Study Guide
162
DO NOT REPRINT
© FORTINET
 Integrating Front-End SNAT and Load Balancers
Once you’ve configured how FortiWeb will use the XFF header, to apply it, select it in a protection profile that
is used by a server policy.
FortiWeb Study Guide
163
DO NOT REPRINT
© FORTINET
 Integrating Front-End SNAT and Load Balancers
If the client is on the Internet and has a public IP address, the attack logs show the original client’s IP, not your
FortiGate. This helps when you need to determine the IP address of a repeat attacker so that you can blacklist
their source IP.
In FortiWeb 5.3.4, 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.
FortiWeb Study Guide
164
DO NOT REPRINT
© FORTINET
 Integrating Front-End SNAT and Load Balancers
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.
FortiWeb Study Guide
165
DO NOT REPRINT
© FORTINET
 Integrating Front-End SNAT and Load Balancers
Good job! You now know how to configure FortiWeb to operate behind a load balancer.
In the next section we will look at the configuration needs of the FortiGate within this scenario for the
FortiGate to serve as the SNAT device.
FortiWeb Study Guide
166
DO NOT REPRINT
© FORTINET
 Integrating Front-End SNAT and Load Balancers
In this section you will learn how to:
• Configure FortiGate as a SNAT device
FortiWeb Study Guide
167
DO NOT REPRINT
© FORTINET
 Integrating Front-End SNAT and Load Balancers
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.
FortiWeb Study Guide
168
DO NOT REPRINT
© FORTINET
 Integrating Front-End SNAT and Load Balancers
Where should you start?
IP addresses are referenced by each policy on FortiGate. So define those first. Add all potential source and
destination addresses:
• FortiAnalyzer as a destination will allow FortiWeb to log to it
• FortiGate’s virtual server as a destination will accept HTTP, apply NAT, and possibly add an X-ForwardedFor: 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.
FortiWeb Study Guide
169
DO NOT REPRINT
© FORTINET
 Integrating Front-End SNAT and Load Balancers
By default, load balancing, including virtual servers, are hidden in FortiGate’s GUI. To show them, turn on that
feature.
FortiWeb Study Guide
170
DO NOT REPRINT
© FORTINET
 Integrating Front-End SNAT and Load Balancers
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 packets’ source address. 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!
FortiWeb Study Guide
171
DO NOT REPRINT
© FORTINET
 Integrating Front-End SNAT and Load Balancers
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.
FortiWeb Study Guide
172
DO NOT REPRINT
© FORTINET
 Integrating Front-End SNAT and Load Balancers
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.
FortiWeb Study Guide
173
DO NOT REPRINT
© FORTINET
 Integrating Front-End SNAT and Load Balancers
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.
FortiWeb Study Guide
174
DO NOT REPRINT
© FORTINET
 Integrating Front-End SNAT and Load Balancers
If clients will use other protocols to access the web servers, remember to make VIPs to forward that traffic too.
FortiWeb Study Guide
175
DO NOT REPRINT
© FORTINET
 Integrating Front-End SNAT and Load Balancers
Depending on your topology, you may be able to forward other protocols such as SFTP directly to back-end
servers. This avoids complications for protocols that need session helpers, and also improves round-trip time,
since FortiWeb isn’t a routing hop for non-HTTP protocols.
FortiWeb Study Guide
176
DO NOT REPRINT
© FORTINET
 Integrating Front-End SNAT and Load Balancers
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.
FortiWeb Study Guide
177
DO NOT REPRINT
© FORTINET
 Integrating Front-End SNAT and Load Balancers
Don’t forget outgoing policies so that FortiWeb can connect to the Internet, and to remote logging or
authentication servers.
FortiWeb Study Guide
178
DO NOT REPRINT
© FORTINET
 Integrating Front-End SNAT and Load Balancers
Excellent! You have now configured your front-end FortiGate.
In the next session we will look at configuring a FortiADC load balancer for this scenario.
FortiWeb Study Guide
179
DO NOT REPRINT
© FORTINET
 Integrating Front-End SNAT and Load Balancers
Load balancers are usually located on the back end, but if you’re using one to provide external active-active
HA among multiple FortiWeb devices, you could have one on the front end. Let’s compare that with FortiGate.
FortiWeb Study Guide
180
DO NOT REPRINT
© FORTINET
 Integrating Front-End SNAT and Load Balancers
Here’s a load balancing profile that you might see on FortiADC VM or D series models. This is where you
configure the X-header for HTTP or HTTPS connections, if your FortiADC is in situated 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.
FortiWeb Study Guide
181
DO NOT REPRINT
© FORTINET
 Integrating Front-End SNAT and Load Balancers
Congratulations! You have successfully completed this lesson.
FortiWeb Study Guide
182
DO NOT REPRINT
© FORTINET
 Integrating Front-End SNAT and Load Balancers
In this lesson, you learned about why you might add an external load balancer. When it’s in front of FortiWeb,
and if it’s applying source NAT, we also showed how to configure it to transmit the original client’s IP to
FortiWeb. We showed 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.
Conversely, we also showed how FortiWeb can transmit that IP to a back-end load balancer or web site.
Content management systems with anti-spam plugins, for example, log the client’s IP address, so sometimes
even web servers need to know the browser’s IP.
FortiWeb Study Guide
183
DO NOT REPRINT
© FORTINET
 DoS and Defacement
In this lesson, we’ll talk about why and how to mitigate denial of service (DoS) attempts, and how to prevent
(and rapidly, automatically reverse) vandalism.
FortiWeb Study Guide
184
DO NOT REPRINT
© FORTINET
 DoS and Defacement
In this lesson we will explore the following topics:
• Threat Overview
• Network or Transport layer analysis
• Application layer analysis
• Blended analysis – L3/L4 + L7
• Breaches
FortiWeb Study Guide
185
DO NOT REPRINT
© FORTINET
 DoS and Defacement
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 is clear in studies by Amazon, Google, and the University of Waterloo
(https://cs.uwaterloo.ca/~bernard/edgecloud). Any latency greater than about 80ms is noticeable by users.
According to Greg Linden, Amazon found every 100ms 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 denial of service 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 it doesn’t count identity theft
or credit card fraud.
Sony’s DDoS itself was massive, but it was ultimately a diversion tactic – it distracted from worse
compromises. Worse, by 2014, Sony hadn’t learned.
FortiWeb Study Guide
186
DO NOT REPRINT
© FORTINET
 DoS and Defacement
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.
FortiWeb Study Guide
187
DO NOT REPRINT
© FORTINET
 DoS and Defacement
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.
FortiWeb Study Guide
188
DO NOT REPRINT
© FORTINET
 DoS and Defacement
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 per 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 per 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.
FortiWeb Study Guide
189
DO NOT REPRINT
© FORTINET
 DoS and Defacement
Good! You now have a better understanding of the various threats.
In the next section we will look at mitigating threats at the Network and Transport layers.
FortiWeb Study Guide
190
DO NOT REPRINT
© FORTINET
 DoS and Defacement
For DoS attacks that use web stack protocols, FortiWeb has multiple solutions. Each mitigates attacks that
function at different layers, in different ways.
Let’s take a look.
FortiWeb Study Guide
191
DO NOT REPRINT
© FORTINET
 DoS and Defacement
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. It’s efficient – it
blocks quickly, at a low layer, before FortiWeb has wasted CPU time on more intensive HTTP scans.
FortiWeb Study Guide
192
DO NOT REPRINT
© FORTINET
 DoS and Defacement
An IP can have a bad reputation for different reasons. Which ones 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, for
example. But 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.
FortiWeb Study Guide
193
DO NOT REPRINT
© FORTINET
 DoS and Defacement
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. And
you don’t want to set a low 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.
FortiWeb Study Guide
194
DO NOT REPRINT
© FORTINET
 DoS and Defacement
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.
FortiWeb Study Guide
195
DO NOT REPRINT
© FORTINET
 DoS and Defacement
Not all DoS sensors use the Shared IP setting. TCP flood prevention, for example, simply specifies one
connection rate limit.
FortiWeb Study Guide
196
DO NOT REPRINT
© FORTINET
 DoS and Defacement
TCP SYN cookie flood prevention doesn’t use shared IP either. But it doesn’t need to.
That’s because legitimate clients almost always follow a TCP SYN signal quickly with SYN ACK and the rest
of the connection setup. Only attackers don’t. So, FortiWeb can be certain that this anomaly is malicious, and
should be automatically blocked.
FortiWeb Study Guide
197
DO NOT REPRINT
© FORTINET
 DoS and Defacement
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 web site, 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 web site. This
can be devastating for e-commerce, government service, and content sites. To prevent this, if your web apps
are publicly accessible, white list known search engines on FortiWeb.
FortiWeb Study Guide
198
DO NOT REPRINT
© FORTINET
 DoS and Defacement
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.
FortiWeb Study Guide
199
DO NOT REPRINT
© FORTINET
 DoS and Defacement
Great! You now know how to detect and prevent threats at the Network and Transport layers
In the next section we will look at threats in the Application layer.
FortiWeb Study Guide
200
DO NOT REPRINT
© FORTINET
 DoS and Defacement
As we continue up the OSI stack, FortiWeb has some DoS protection that works by analyzing the application
alone. Others combine analysis of the application layer with the transport or network layer.
Let’s take a look.
FortiWeb Study Guide
201
DO NOT REPRINT
© FORTINET
 DoS and Defacement
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 could be difficult to detect. But FortiWeb can analyze and
work with the HTTP layer, too.
These types of tools are often command-line, lightweight, and don’t support many of things a normal, fullfeatured 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 it’s a browser or not. If it’s a bot, you can
block that source IP.
FortiWeb Study Guide
202
DO NOT REPRINT
© FORTINET
 DoS and Defacement
This DoS sensor also does traffic policing on HTTP requests, but it operates differently. Do you see a
separate Shared IP rate?
No.
For this feature, 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. So
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. Otherwise, or if a bot is detected, FortiWeb applies the
block action that you’ve selected.
FortiWeb Study Guide
203
DO NOT REPRINT
© FORTINET
 DoS and Defacement
Good job! You now know how to detect and prevent Application layer threats.
Next, let’s look at a blended analysis where all three layers are involved.
FortiWeb Study Guide
204
DO NOT REPRINT
© FORTINET
 DoS and Defacement
In this section we will:
• Describe and Discuss Multi-layer DDoS mitigation solutions
FortiWeb Study Guide
205
DO NOT REPRINT
© FORTINET
 DoS and Defacement
In this sensor, real browser enforcement can even be combined with shared IP, which we see here in the
HTTP request limit.
Although it works on both the IP and HTTP layers, this FortiWeb feature doesn’t require the client to support
cookies – only JavaScript.
Again, to cause connection timeouts on this type of malicious client and discourage them from returning, you
can set the Action to Period Block.
FortiWeb Study Guide
206
DO NOT REPRINT
© FORTINET
 DoS and Defacement
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 this is a good candidate for a period block action.
FortiWeb Study Guide
207
DO NOT REPRINT
© FORTINET
 DoS and Defacement
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 them in the protection profile used by a server policy.
FortiWeb Study Guide
208
DO NOT REPRINT
© FORTINET
 DoS and Defacement
Apart from the TCP/IP stack, web protocols have some DoS vulnerabilities inherent in the design. 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 these, 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, then it’s possible to use that to create an app-specific DoS attack.
FortiWeb Study Guide
209
DO NOT REPRINT
© FORTINET
 DoS and Defacement
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 so-called sizing factors. You should also
consider your settings for various scan buffers, response cache, and how FortiWeb is configured to handle
them.
FortiWeb Study Guide
210
DO NOT REPRINT
© FORTINET
 DoS and Defacement
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 purposebuilt 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.
FortiWeb Study Guide
211
DO NOT REPRINT
© FORTINET
 DoS and Defacement
Great! You now know how to detect and prevent multi-layer threats.
Next, let’s discuss breaches in the network.
FortiWeb Study Guide
212
DO NOT REPRINT
© FORTINET
 DoS and Defacement
Once you’ve strengthened your architecture and configuration against DoS attacks, remember what DoS
attacks are usually designed to achieve: distraction.
Has a security breach happened while you’ve been fighting the DoS attack?
You’ll learn about FortiWeb’s IPS features in another lesson. But, if you are already breached and need a
solution to fight it now, while you’re analyzing a more permanent solution, what can you do?
FortiWeb Study Guide
213
DO NOT REPRINT
© FORTINET
 DoS and Defacement
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 web site defaced. About 1.5 million web sites 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, such as
these, are abandoned after the attack is done, with the attacker moving on to look for new targets.
FortiWeb Study Guide
214
DO NOT REPRINT
© FORTINET
 DoS and Defacement
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 web site
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.
FortiWeb Study Guide
215
DO NOT REPRINT
© FORTINET
 DoS and Defacement
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 web sites.
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.
FortiWeb Study Guide
216
DO NOT REPRINT
© FORTINET
 DoS and Defacement
Since most modern web sites 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 for banks or PeopleSoft installations, you should
also apply controls. Database security devices such as FortiDB can help.
FortiWeb Study Guide
217
DO NOT REPRINT
© FORTINET
 DoS and Defacement
Congratulations! You have successfully completed this lesson.
FortiWeb Study Guide
218
DO NOT REPRINT
© FORTINET
 DoS and Defacement
In this lesson, we discussed several different types of DoS attacks that can affect web servers. You learned
about a range of attack types, including ones that affect every OSI layer of the web server stack, as well as
DNS. You learned how to study your normal traffic patterns, and how to recognize anomalies.
Some of FortiWeb’s DoS sensors analyze multiple OSI layers. You learned about how FortiWeb can test
whether clients are web browsers, and apply separate traffic policing or period blocks to browsers and search
engine crawlers, when the HTTP layer is included.
Finally, you also learned how to use anti-defacement to rapidly undo vandalism, since defacements often
accompany DoS attacks.
FortiWeb Study Guide
219
DO NOT REPRINT
© FORTINET
 Signature Sanitization and Auto Learning
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.
FortiWeb Study Guide
220
DO NOT REPRINT
© FORTINET
 Signature Sanitization and Auto Learning
In this lesson we will explore:
• Quick Start
• Generating signatures and rules
• Input Validation: Session Cookies
• Input Validation: Headers and Body
• Input Validation: Forms
• State Based attacks
• Threat Scoring
FortiWeb Study Guide
221
DO NOT REPRINT
© FORTINET
 Signature Sanitization and Auto Learning
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, its needs can change.
How can you configure FortiWeb most quickly?
FortiWeb Study Guide
222
DO NOT REPRINT
© FORTINET
 Signature Sanitization and Auto Learning
There are a few quick start strategies you can use. In this section we will:
• Discuss and Describe the Quick Start method of enabling signatures
• Configure Monitor Only mode
• Configure Auto Learning
FortiWeb Study Guide
223
DO NOT REPRINT
© FORTINET
 Signature Sanitization and Auto Learning
Here is an overview of methods that you can use to configure FortiWeb quickly. Let’s take a look at each of
them.
FortiWeb Study Guide
224
DO NOT REPRINT
© FORTINET
 Signature Sanitization and Auto Learning
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.
FortiWeb Study Guide
225
DO NOT REPRINT
© FORTINET
 Signature Sanitization and Auto Learning
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.
FortiWeb Study Guide
226
DO NOT REPRINT
© FORTINET
 Signature Sanitization and Auto Learning
The most powerful, but also the most resource-intensive method, 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 apps’ normal traffic. As you can imagine, this takes considerable CPU power and RAM.
So if you enable it 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.
FortiWeb Study Guide
227
DO NOT REPRINT
© FORTINET
 Signature Sanitization and Auto Learning
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.
FortiWeb Study Guide
228
DO NOT REPRINT
© FORTINET
 Signature Sanitization and Auto Learning
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.
FortiWeb Study Guide
229
DO NOT REPRINT
© FORTINET
 Signature Sanitization and Auto Learning
While auto learning, one of the things that FortiWeb usually studies is the web apps’ inputs, such as:
• How many are there?
• What are their names?
• What data type should they accept? Are some formats illegal?
• How big of a number, or how long of a string?
One of the most common ways that attackers find zero-day exploits are 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.
FortiWeb Study Guide
230
DO NOT REPRINT
© FORTINET
 Signature Sanitization and Auto Learning
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!
FortiWeb Study Guide
231
DO NOT REPRINT
© FORTINET
 Signature Sanitization and Auto Learning
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.
FortiWeb Study Guide
232
DO NOT REPRINT
© FORTINET
 Signature Sanitization and Auto Learning
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.
FortiWeb Study Guide
233
DO NOT REPRINT
© FORTINET
 Signature Sanitization and Auto Learning
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.
FortiWeb Study Guide
234
DO NOT REPRINT
© FORTINET
 Signature Sanitization and Auto Learning
The object named URL Replacer is what shows auto learning how to interpret the URL line to find the URL
and separate each input.
Since 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 autolearning 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.
FortiWeb Study Guide
235
DO NOT REPRINT
© FORTINET
 Signature Sanitization and Auto Learning
Good job! You now know how to deploy and configure FortiWeb very quickly.
In the next section we will begin to look at ways to fine tune FortiWeb to your specific environment by
generating signatures and rules based on learned data.
FortiWeb Study Guide
236
DO NOT REPRINT
© FORTINET
 Signature Sanitization and Auto Learning
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 Study Guide
237
DO NOT REPRINT
© FORTINET
 Signature Sanitization and Auto Learning
Once 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 upon its data. 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 – not just the host name or the auto learning
profile’s 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 their estimated data types, too.
FortiWeb Study Guide
238
DO NOT REPRINT
© FORTINET
 Signature Sanitization and Auto Learning
If you click the Attacks tab, for example, you will see how many requests matched attack signatures. It is in
the Count and Percentage columns.
FortiWeb Study Guide
239
DO NOT REPRINT
© FORTINET
 Signature Sanitization and Auto Learning
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.
FortiWeb Study Guide
240
DO NOT REPRINT
© FORTINET
 Signature Sanitization and Auto Learning
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.
FortiWeb Study Guide
241
DO NOT REPRINT
© FORTINET
 Signature Sanitization and Auto Learning
Well done! You now know how to generate auto-learning reports and modify protection profiles.
In the next section we will look at using Input Validation based on Session cookies.
FortiWeb Study Guide
242
DO NOT REPRINT
© FORTINET
 Signature Sanitization and Auto Learning
Now you will learn more about each component that auto learning generates, and how it protects your web
servers.
First, let’s study how it protects session cookies. We will:
• Describe and Discuss HTTP Header validation
• Describe and Discuss HTTP Protocol Constraints
FortiWeb Study Guide
243
DO NOT REPRINT
© FORTINET
 Signature Sanitization and Auto Learning
As it was initially defined in the RFC, HTTP is stateless. This means that each request is not necessarily
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, it 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 do this with sever-side sessions, session cookies that are stored client-side, or both.
FortiWeb Study Guide
244
DO NOT REPRINT
© FORTINET
 Signature Sanitization and Auto Learning
Here is 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: and 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. In the client’s second request, it returns the unchanged cookie.
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.
FortiWeb Study Guide
245
DO NOT REPRINT
© FORTINET
 Signature Sanitization and Auto Learning
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.
FortiWeb Study Guide
246
DO NOT REPRINT
© FORTINET
 Signature Sanitization and Auto Learning
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.
FortiWeb Study Guide
247
DO NOT REPRINT
© FORTINET
 Signature Sanitization and Auto Learning
In 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.
FortiWeb Study Guide
248
DO NOT REPRINT
© FORTINET
 Signature Sanitization and Auto Learning
Good job! You have just learned how to implement Input validation based on session cookies.
In the next section we will discuss Input Validation based on Headers and Body.
FortiWeb Study Guide
249
DO NOT REPRINT
© FORTINET
 Signature Sanitization and Auto Learning
The Cookie: header is one type of HTTP input that users don’t usually see, but it’s not the only one. In this
section we will:
• Describe and Discuss HTTP Header validation
• Describe and Discuss HTTP Protocol Constraints
FortiWeb Study Guide
250
DO NOT REPRINT
© FORTINET
 Signature Sanitization and Auto Learning
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.
FortiWeb Study Guide
251
DO NOT REPRINT
© FORTINET
 Signature Sanitization and Auto Learning
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.
FortiWeb Study Guide
252
DO NOT REPRINT
© FORTINET
 Signature Sanitization and Auto Learning
Excellent! You now know how to implement Input Validation based on Headers and Body.
In the next section we will look at Input Validation based on Forms.
FortiWeb Study Guide
253
DO NOT REPRINT
© FORTINET
 Signature Sanitization and Auto Learning
Input from HTML forms is equally important to validate. In this section we will:
• Configure Parameter Validation Rules
• Configure Upload Restriction Rules
• Configure Upload Restriction Policy
• Configure Signature Policy
• Define Cross Site Scripting
• Define SQL Injection
FortiWeb Study Guide
254
DO NOT REPRINT
© FORTINET
 Signature Sanitization and Auto Learning
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, usercompleted 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.
FortiWeb Study Guide
255
DO NOT REPRINT
© FORTINET
 Signature Sanitization and Auto Learning
With FortiWeb, you can also specify that excessively large files of the wrong type can’t be uploaded.
FortiWeb Study Guide
256
DO NOT REPRINT
© FORTINET
 Signature Sanitization and Auto Learning
When restricting uploads, you can also engage FortiGuard Antivirus.
FortiWeb Study Guide
257
DO NOT REPRINT
© FORTINET
 Signature Sanitization and Auto Learning
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.
FortiWeb Study Guide
258
DO NOT REPRINT
© FORTINET
 Signature Sanitization and Auto Learning
Because they are regular expressions, you can also customize or write your own attack signatures. If you do
this, use PCRE syntax.
FortiWeb Study Guide
259
DO NOT REPRINT
© FORTINET
 Signature Sanitization and Auto Learning
When configuring which signatures to use, choosing the Period Block setting instead of Aert & Deny is an
important performance tweak. Select it for DoS or persistent attacks to reduce FortiWeb’s CPU usage and
buy time for forensic analysis.
FortiWeb Study Guide
260
DO NOT REPRINT
© FORTINET
 Signature Sanitization and Auto Learning
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 re-uses 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.
FortiWeb Study Guide
261
DO NOT REPRINT
© FORTINET
 Signature Sanitization and Auto Learning
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 into your CMS.
FortiWeb Study Guide
262
DO NOT REPRINT
© FORTINET
 Signature Sanitization and Auto Learning
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 the Advanced Mode button
that appears, and create exceptions or disable those individual signatures. You don’t need to disable the
entire category.
FortiWeb Study Guide
263
DO NOT REPRINT
© FORTINET
 Signature Sanitization and Auto Learning
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.
This 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.
FortiWeb Study Guide
264
DO NOT REPRINT
© FORTINET
 Signature Sanitization and Auto Learning
Regardless of the reason why a request is detected as an attack, you can usually customize FortiWeb’s error
message.
FortiWeb Study Guide
265
DO NOT REPRINT
© FORTINET
 Signature Sanitization and Auto Learning
Great! You now know how to implement Input Validation based on Forms
In the next section we will look at how to detect and prevent State-Based attacks.
FortiWeb Study Guide
266
DO NOT REPRINT
© FORTINET
 Signature Sanitization and Auto Learning
Lack of input sanitization is only the beginning. If your FortiWeb’s vulnerability scan detects those types of
vulnerabilities, it’s the easiest for developers to find and correct.
What’s harder to find and correct? Mechanism exploits.
In this section we will:
• Define a Start Page
• Configure Session Initiation page
• Define Page Access rules
• Configure Allowed Page Order
FortiWeb Study Guide
267
DO NOT REPRINT
© FORTINET
 Signature Sanitization and Auto Learning
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 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.
FortiWeb Study Guide
268
DO NOT REPRINT
© FORTINET
 Signature Sanitization and Auto Learning
Unless you’ve used auto learning, this can be difficult to configure correctly. To do so, you must understand
the web app well. Instead of a period block, 403 Forbidden, or Alert & Deny action, it is usually best 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.
FortiWeb Study Guide
269
DO NOT REPRINT
© FORTINET
 Signature Sanitization and Auto Learning
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.
FortiWeb Study Guide
270
DO NOT REPRINT
© FORTINET
 Signature Sanitization and Auto Learning
This slide shows you how to configure a page order rule for the scenario we just talked about. Notice that we
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.
FortiWeb Study Guide
271
DO NOT REPRINT
© FORTINET
 Signature Sanitization and Auto Learning
Well done! You now know how to detect and prevent State-Based attacks.
Next, let’s take a look at Threat Scoring.
FortiWeb Study Guide
272
DO NOT REPRINT
© FORTINET
 Signature Sanitization and Auto Learning
The threat scoring feature allows you to configure your signature policy to take action based on multiple
signature violations by a client , instead of a single signature violation. When a client violates a signature in a
threat scoring category, it contributes to a combined threat score. When the combined threat score exceeds a
maximum value you specify, FortiWeb takes action. In this section we will:
• Configure Threat Scoring
• Review Threat Scoring in Attack Logs
FortiWeb Study Guide
273
DO NOT REPRINT
© FORTINET
 Signature Sanitization and Auto Learning
When threat scoring for a signature category is turned on, FortiWeb ignores the action set for the category.
Instead, when traffic violates a signature in the category, FortiWeb adds the threat score for the signature to
the combined threat score for the signature policy. When the combined score exceeds the maximum specified
by the Threat Scoring Threshold setting, FortiWeb takes the specified action.
Some high-priority signatures are configured to override the threat management settings for their category.
You cannot enable threat scoring for the following categories:
• Credit card detection
• Information disclosure, if it is configured to erase information
FortiWeb Study Guide
274
DO NOT REPRINT
© FORTINET
 Signature Sanitization and Auto Learning
Threat scoring match scope specifies how FortiWeb calculates the combined threat score before it compares
it to the threat scoring threshold.
• HTTP transaction – FortiWeb compares the score for each transaction to the threshold
• TCP session – FortiWeb compares the score for each session to the threshold. The score can include
multiple transactions.
• HTTP session – FortiWeb compares the score for sessions associated with a specific client to the
threshold. This option requires you to enable session management in the appropriate protection profile.
Example combined threat score calculations are shown in this slide.
Threat scoring threshold is low (7 points).
A TCP session contains two HTTP transactions:
•
Transaction A violates two signatures. Each signature has a threat score of 3.
•
Transaction B also violates two signatures. Each signature has a threat score of 5.
• If the threat scoring match scope is HTTP transaction:
• The score for transaction A is 6, which does not exceed the threshold and FortiWeb takes no
action.
• The score for transaction B is 10, which exceeds the threshold, and FortiWeb takes the specified
action.
• If threat scoring match scope is TCP session, the score for the session is 16, which exceeds the threshold
and triggers the action.
FortiWeb Study Guide
275
DO NOT REPRINT
© FORTINET
 Signature Sanitization and Auto Learning
The signature details settings allow you to adjust the threat score for each signature.
FortiWeb Study Guide
276
DO NOT REPRINT
© FORTINET
 Signature Sanitization and Auto Learning
Some high priority signatures are configured, by default, to ignore the threat score settings. When traffic
violates these signatures, FortiWeb takes the action specified for that signature immediately. If you disable the
override setting for these signatures, they behave like other signatures when you add their category to the
threat scoring group.
FortiWeb Study Guide
277
DO NOT REPRINT
© FORTINET
 Signature Sanitization and Auto Learning
A column and icon in the attack log indicate messages that FortiWeb generated when a combined threat
score for a signature policy exceeded its threshold. The message details include more information about the
score and the signatures that contributed to it. FortiWeb aggregates threat score messages in the Aggregated
Attacks page.
FortiWeb Study Guide
278
DO NOT REPRINT
© FORTINET
 Signature Sanitization and Auto Learning
Congratulations! You have successfully completed this lesson.
FortiWeb Study Guide
279
DO NOT REPRINT
© FORTINET
 Signature Sanitization and Auto Learning
In this lesson, you learned three strategies for quickly deploying protection settings. You learned how the
action setting that you select can affect performance. You learned that when FortiWeb scans for attacks, it
can scan for both input sanitization errors and mechanistic attacks. Finally, you learned two strategies for
avoiding blocking legitimate requests when they accidentally match a rule or an attack signature.
FortiWeb Study Guide
280
DO NOT REPRINT
© FORTINET
 SSL/TLS
In this lesson, you’ll learn how to use encrypted HTTP transactions. With HTTPS, login credentials and other
sensitive data aren’t compromised while they’re in transit.
FortiWeb Study Guide
281
DO NOT REPRINT
© FORTINET
 SSL/TLS
In this lesson we will explore the following topics:
• HTTPS Basics
• SSL/TLS Protocols and ciphers
• X.509 Certificates
• Client PKI Certificates
• What if clients type HTTP?
FortiWeb Study Guide
282
DO NOT REPRINT
© FORTINET
 SSL/TLS
In this section we will discuss:
• Why HTTPS?
• SSL Inspection vs SSL Offloading
• Configure SSL Offloading
• Configure SSL Inspection
FortiWeb Study Guide
283
DO NOT REPRINT
© FORTINET
 SSL/TLS
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.
FortiWeb Study Guide
284
DO NOT REPRINT
© FORTINET
 SSL/TLS
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 shows statistics for the top ~140,000 sites as of October 3rd, 2016. In that sample, 175 were still
vulnerable to Heartbleed, an SSL vulnerability over one year old. 9.1% used weak cipher strengths less than
128 bits.
The good news is that FortiWeb has tools to not only easily offer HTTPS, but to help you implement it
securely for all protected web sites.
FortiWeb Study Guide
285
DO NOT REPRINT
© FORTINET
 SSL/TLS
When we configure HTTPS on FortiWeb, mostly we’re 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.
FortiWeb Study Guide
286
DO NOT REPRINT
© FORTINET
 SSL/TLS
The differences between SSL inspection and SSL offloading are explained in this slide.
•
•
SSL inspection puts the certificate and private key on both FortiWeb and the web servers. However,
FortiWeb is not an end point 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.
FortiWeb Study Guide
287
DO NOT REPRINT
© FORTINET
 SSL/TLS
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.
FortiWeb Study Guide
288
DO NOT REPRINT
© FORTINET
 SSL/TLS
(slide contains animations)
Since reverse proxy is the most popular operation mode, usually you will be configuring an SSL proxy. It
either may be SSL offloading, or after inspection, may make a second HTTPS session to the back-end
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. (click)
2. If an intermediate CA signs it, be sure that browsers can link it to a trusted root. (click) Otherwise, include
the signing chain in the bottom of the certificate, (click) or as intermediate certificates on FortiWeb. (click)
3. Upload both the signed certificate and its associated private key in the local certificates menu on
FortiWeb. (click)
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.
(click)
5. Finally, select your certificate and, if applicable, certificate revocation and validation rules, in the policy.
FortiWeb Study Guide
289
DO NOT REPRINT
© FORTINET
 SSL/TLS
Let’s look at how to configure SSL / TLS offloading on FortiWeb.
In the simplest case, you only 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!
FortiWeb Study Guide
290
DO NOT REPRINT
© FORTINET
 SSL/TLS
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.
FortiWeb Study Guide
291
DO NOT REPRINT
© FORTINET
 SSL/TLS
If you’re using transparent mode, your back-end web servers must be configured to offer HTTPS. This may be
different from reverse proxy – SSL offloading means that the back-end server only needs to offer plain HTTP.
So while transparent mode doesn’t require any server-side changes, reverse proxy might.
For better security, though, 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 can’t therefore inspect.
FortiWeb Study Guide
292
DO NOT REPRINT
© FORTINET
 SSL/TLS
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. Like with SSL inspection, 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.
FortiWeb Study Guide
293
DO NOT REPRINT
© FORTINET
 SSL/TLS
Great! You are now familiar with HTTPS basics
In the next section we will look at SSL/TLS protocols and ciphers
FortiWeb Study Guide
294
DO NOT REPRINT
© FORTINET
 SSL/TLS
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.
In this section you will learn:
• HTTPS Limitations
• TLS versions and vulnerablities
• Verifying Client Connections
FortiWeb Study Guide
295
DO NOT REPRINT
© FORTINET
 SSL/TLS
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.
FortiWeb Study Guide
296
DO NOT REPRINT
© FORTINET
 SSL/TLS
(slide contains animations)
What should these servers have done?
(click)
First, don’t use old SSL protocol versions.
(click)
Use TLS 1.1 or 1.2, if possible.
FortiWeb Study Guide
297
DO NOT REPRINT
© FORTINET
 SSL/TLS
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.
FortiWeb Study Guide
298
DO NOT REPRINT
© FORTINET
 SSL/TLS
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.
FortiWeb Study Guide
299
DO NOT REPRINT
© FORTINET
 SSL/TLS
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.
FortiWeb Study Guide
300
DO NOT REPRINT
© FORTINET
 SSL/TLS
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.
FortiWeb Study Guide
301
DO NOT REPRINT
© FORTINET
 SSL/TLS
In Google Chrome, you also click the padlock to see which protocol and ciphers were negotiated.
FortiWeb Study Guide
302
DO NOT REPRINT
© FORTINET
 SSL/TLS
Unfortunately, there is no easy way to verify client connections 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.
FortiWeb Study Guide
303
DO NOT REPRINT
© FORTINET
 SSL/TLS
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.
FortiWeb Study Guide
304
DO NOT REPRINT
© FORTINET
 SSL/TLS
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.
FortiWeb Study Guide
305
DO NOT REPRINT
© FORTINET
 SSL/TLS
Excellent! You now have an understanding of SSL/TLS protocols and ciphers.
In the next section you will look at X.509 certificates
FortiWeb Study Guide
306
DO NOT REPRINT
© FORTINET
 SSL/TLS
Aside from protocol versions and cipher suites, the other major component of HTTPS is X.509 certificates.
FortiWeb Study Guide
307
DO NOT REPRINT
© FORTINET
 SSL/TLS
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 back-end severs.
FortiWeb Study Guide
308
DO NOT REPRINT
© FORTINET
 SSL/TLS
In most cases, since FortiWeb is a proxy, it will be acting as an agent for your web sites. So it will present
their 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.
FortiWeb Study Guide
309
DO NOT REPRINT
© FORTINET
 SSL/TLS
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, back-end HTTPS, or secure email server
FortiWeb Study Guide
310
DO NOT REPRINT
© FORTINET
 SSL/TLS
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?
FortiWeb Study Guide
311
DO NOT REPRINT
© FORTINET
 SSL/TLS
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.
FortiWeb Study Guide
312
DO NOT REPRINT
© FORTINET
 SSL/TLS
Multi-domain 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 OWASP to be less
secure. Instead, you can use a SAN certificate extension field to list specific host names that are under your
control.
FortiWeb Study Guide
313
DO NOT REPRINT
© FORTINET
 SSL/TLS
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.
FortiWeb Study Guide
314
DO NOT REPRINT
© FORTINET
 SSL/TLS
Good job! You now know more about X.509 certificates
In the next section you will learn about Client PKI certificates
FortiWeb Study Guide
315
DO NOT REPRINT
© FORTINET
 SSL/TLS
Server certificates are only one type of certificate. FortiWeb can also accept – and present – a client
certificate.
In this section you will learn to:
• Describe and Discuss Client PKI Certificates
• Configure Client PKI Certificates
FortiWeb Study Guide
316
DO NOT REPRINT
© FORTINET
 SSL/TLS
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 bi-lateral authentication.
FortiWeb can also authenticate as a client. If it uses HTTPS to connect to the back-end web servers, it can
present its own certificate to authenticate as a client.
FortiWeb Study Guide
317
DO NOT REPRINT
© FORTINET
 SSL/TLS
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.
FortiWeb Study Guide
318
DO NOT REPRINT
© FORTINET
 SSL/TLS
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.
FortiWeb Study Guide
319
DO NOT REPRINT
© FORTINET
 SSL/TLS
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.
FortiWeb Study Guide
320
DO NOT REPRINT
© FORTINET
 SSL/TLS
Great! You now know how to implement and use Client PKI certificates on FortiWeb.
Next you will look at what to do if the user types HTTP instead of HTTPS.
FortiWeb Study Guide
321
DO NOT REPRINT
© FORTINET
 SSL/TLS
Regardless of whether your servers or FortiWeb offer HTTPS, there is no way that you can prevent a client
from typing http:// into 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? I this section you will learn how to implement HTTP to HTTPS redirection.
FortiWeb Study Guide
322
DO NOT REPRINT
© FORTINET
 SSL/TLS
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.
FortiWeb Study Guide
323
DO NOT REPRINT
© FORTINET
 SSL/TLS
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 dialogs that allow users to ignore certificate warnings, a common source of socalled click-through insecurity.
FortiWeb Study Guide
324
DO NOT REPRINT
© FORTINET
 SSL/TLS
Here we see a reply from a web server where FortiWeb has injected the Strict-Transport-Security: header.
FortiWeb Study Guide
325
DO NOT REPRINT
© FORTINET
 SSL/TLS
Once 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!
FortiWeb Study Guide
326
DO NOT REPRINT
© FORTINET
 SSL/TLS
Congratulations! You have successfully completed this lesson
FortiWeb Study Guide
327
DO NOT REPRINT
© FORTINET
 SSL/TLS
In this lesson, you learned about the differences between SSL and TLS, and how some HTTPS protocol
versions and ciphers are not recommended. You learned about SSL offloading and SSL inspection, how to
test them, and their implications for server-side configuration. Finally, you learned how to enforce use of
HTTPS instead of clear text HTTP.
FortiWeb Study Guide
328
DO NOT REPRINT
© FORTINET
 Authentication and Access Control
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.
FortiWeb Study Guide
329
DO NOT REPRINT
© FORTINET
 Authentication and Access Control
In this lesson we will explore the following topics:
• After encrypting, Control access and Authenticate
• Authentication
• User Tracking
• Attacks on Authentication
FortiWeb Study Guide
330
DO NOT REPRINT
© FORTINET
 Authentication and Access Control
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 their logins.
Why do you need HTTPS?
For some web apps, adding HTTPS is not as critical. 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.
FortiWeb Study Guide
331
DO NOT REPRINT
© FORTINET
 Authentication and Access Control
At the most basic level, you can manually blacklist specific IP addresses and white list 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, their action is Continue to Other
Scans.
If you have a web app that should only be accessible by a specified group of people, such as top
management levels logging in from a secure, private network location, this may be enough.
FortiWeb Study Guide
332
DO NOT REPRINT
© FORTINET
 Authentication and Access Control
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.
FortiWeb Study Guide
333
DO NOT REPRINT
© FORTINET
 Authentication and Access Control
If you need to control access based upon the request’s HTTP layer – its URL and host name – then FortiWeb
can do that. In previous FortiWeb versions, URL access rules could only match by the domain name and
URL, but now FortiWeb can also match based upon 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.
FortiWeb Study Guide
334
DO NOT REPRINT
© FORTINET
 Authentication and Access Control
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 very fine-grained access control.
FortiWeb Study Guide
335
DO NOT REPRINT
© FORTINET
 Authentication and Access Control
In this slide, you can see a rule that restricts URL access to one source IP and checks the rate limit and selfreported User-Agent: string. This rule allows access only by that specific client software.
FortiWeb Study Guide
336
DO NOT REPRINT
© FORTINET
 Authentication and Access Control
Great! You now have an understanding of Control Access and Authentication basics.
In the next section we will look at the details of Authentication.
FortiWeb Study Guide
337
DO NOT REPRINT
© FORTINET
 Authentication and Access Control
Once you’ve determined which clients should be allowed to try to log in, handle 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.
FortiWeb Study Guide
338
DO NOT REPRINT
© FORTINET
 Authentication and Access Control
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: it can delegate the
credentials to the back-end web app, yet still cache authenticated sessions locally so that you can apply
single sign-on. We’ll show that later.
FortiWeb Study Guide
339
DO NOT REPRINT
© FORTINET
 Authentication and Access Control
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 box. 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:
which OS and Apache version it has. 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!
FortiWeb Study Guide
340
DO NOT REPRINT
© FORTINET
 Authentication and Access Control
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.
FortiWeb Study Guide
341
DO NOT REPRINT
© FORTINET
 Authentication and Access Control
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, this isn’t the most practical way to
define accounts.
FortiWeb Study Guide
342
DO NOT REPRINT
© FORTINET
 Authentication and Access Control
Instead, 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 LDAPS protocol. Directory
tree structures vary by the schema, so if it was IBM Lotus Notes or another application, the CNID,
distinguished names, and query strings would be different.
FortiWeb Study Guide
343
DO NOT REPRINT
© FORTINET
 Authentication and Access Control
Once your queries and/or locally-defined user accounts exist, group them into a user group.
FortiWeb Study Guide
344
DO NOT REPRINT
© FORTINET
 Authentication and Access Control
Reference the user group when you define an authentication rule. This defines who has access to each URL.
Note that some HTTP authentication styles like NTLM are not supported by all query types.
FortiWeb Study Guide
345
DO NOT REPRINT
© FORTINET
 Authentication and Access Control
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 cache.
Fast cache timeouts help to prevent unattended computers from being a possible attack vector, 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, for example, the protected web app won’t be user-friendly: their
authentication session will timeout between each page submission.
FortiWeb Study Guide
346
DO NOT REPRINT
© FORTINET
 Authentication and Access Control
When configuration is complete, this is the authentication dialog that FortiWeb will trigger in users’ browsers.
Since it’s based only on an HTTP header, there’s no way to control style, such as to put company logos or
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?
FortiWeb Study Guide
347
DO NOT REPRINT
© FORTINET
 Authentication and Access Control
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 single sign-on (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, just 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
FortiWeb Study Guide
348
DO NOT REPRINT
© FORTINET
 Authentication and Access Control
One important advantage of site publishing over simple authentication rules is FortiWeb’s ability for 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 single sign-on (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, however, Instead, they
will be tokens encrypted with a private key that you load onto FortiWeb.
FortiWeb Study Guide
349
DO NOT REPRINT
© FORTINET
 Authentication and Access Control
When configuration is complete, the dialog that site publishing triggers in users’ browsers can be either the
HTTP browser pane that we saw previously, an HTML web page with a form, like this, or it 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, or
• User name and password, then 2-factor authentication token such as RSA SecurID
FortiWeb Study Guide
350
DO NOT REPRINT
© FORTINET
 Authentication and Access Control
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.
FortiWeb Study Guide
351
DO NOT REPRINT
© FORTINET
 Authentication and Access Control
This is how it works: 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.
FortiWeb Study Guide
352
DO NOT REPRINT
© FORTINET
 Authentication and Access Control
Good job! You now know how to implement authentication features on FortiWeb
In the next section you will learn about the User Tracking feature.
FortiWeb Study Guide
353
DO NOT REPRINT
© FORTINET
 Authentication and Access Control
The new user tracking feature allows you to track sessions by user and capture a username to reference in
traffic and attack log messages. You can also use this feature to prevent a session fixation attack and set a
period of time during which FortiWeb blocks requests with a session ID from a timed-out session.
FortiWeb Study Guide
354
DO NOT REPRINT
© FORTINET
 Authentication and Access Control
Tracked users are identified in both the Attack logs and in the Traffic logs
FortiWeb Study Guide
355
DO NOT REPRINT
© FORTINET
 Authentication and Access Control
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.
FortiWeb Study Guide
356
DO NOT REPRINT
© FORTINET
 Authentication and Access Control
Here we see the screen for creating a User Tracking policy.
You will need to define an Authentication URL, a Log Off URL, and define Authentication Result Conditions
FortiWeb Study Guide
357
DO NOT REPRINT
© FORTINET
 Authentication and Access Control
Excellent! You are now able to utilize the User Tracking feature on FortiWeb.
Next, we will discuss examples of attacks on authentication.
FortiWeb Study Guide
358
DO NOT REPRINT
© FORTINET
 Authentication and Access Control
Now that authentication is implemented, you’ll want to add a few protections for attacks that are specific to it.
FortiWeb Study Guide
359
DO NOT REPRINT
© FORTINET
 Authentication and Access Control
The most obvious protection may be brute force protection. Especially when a client’s smart phone, tablet or
laptop has become infected and is now 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.
Once they guess successfully, they will be able to log in as that user. If the user 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.
FortiWeb Study Guide
360
DO NOT REPRINT
© FORTINET
 Authentication and Access Control
Hands up! How many of you will admit to using these passwords?
This is one of many reasons why PKI and 2-factor authentication are an important step if you need stronger
authentication.
It’s also a perfect example of why you should limit each account to the minimum required permissions for that
person’s job, and why you should enable brute force protection.
FortiWeb Study Guide
361
DO NOT REPRINT
© FORTINET
 Authentication and Access Control
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!
FortiWeb Study Guide
362
DO NOT REPRINT
© FORTINET
 Authentication and Access Control
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 is, in part, is what makes Lucky 13 attacks possible.
http://www.isg.rhul.ac.uk/tls/Lucky13.html
FortiWeb Study Guide
363
DO NOT REPRINT
© FORTINET
 Authentication and Access Control
How much faster can an attacker break cryptography with a padding oracle?
This quote from Juliano Rizzo illustrates how serious the problem is.
FortiWeb Study Guide
364
DO NOT REPRINT
© FORTINET
 Authentication and Access Control
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.
FortiWeb Study Guide
365
DO NOT REPRINT
© FORTINET
 Authentication and Access Control
Congratulations! You have successfully completed this lesson
FortiWeb Study Guide
366
DO NOT REPRINT
© FORTINET
 Authentication and Access Control
In this lesson, you learned multiple ways to control access at the IP and HTTP layers, before a client can even
attempt to log in. This includes access control rules, Geo IP, and FortiGuard IP reputation.
You learned how FortiWeb can add authentication if the application doesn’t already have it. But if the web app
does have its own authentication, FortiWeb can forward credentials to it. FortiWeb also can apply single signon across multiple web applications without any installation of a Fortinet SSO agent.
Finally, you learned how to defeat some specific authentication attacks. They focus on breaking authentication
by brute forcing either the password itself, or the padding in a password input.
FortiWeb Study Guide
367
DO NOT REPRINT
© FORTINET
 PCI DSS 3.0 Compliance
In this lesson, you’ll learn how to apply FortiWeb features to help you meet the requirements of PCI DSS 3.0.
This includes applying industry best practices from the OWASP Top 10.
FortiWeb Study Guide
368
DO NOT REPRINT
© FORTINET
 PCI DSS 3.0 Compliance
In this lesson we will explore the following topics:
• PCDISS Overview
• How Do I know If My Web App is Vulnerable?
• More Top 10 Threats
• Defining Custom Data Types
FortiWeb Study Guide
369
DO NOT REPRINT
© FORTINET
 PCI DSS 3.0 Compliance
In this section you will learn to:
• Define and Discuss PCI DSS
• Describe and Discuss the OWASP Top 10
FortiWeb Study Guide
370
DO NOT REPRINT
© FORTINET
 PCI DSS 3.0 Compliance
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
bank debit and credit card numbers.
This 2014 study from Verizon highlights how common the problem is.
FortiWeb Study Guide
371
DO NOT REPRINT
© FORTINET
 PCI DSS 3.0 Compliance
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.
FortiWeb Study Guide
372
DO NOT REPRINT
© FORTINET
 PCI DSS 3.0 Compliance
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 their profitability. 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.
FortiWeb Study Guide
373
DO NOT REPRINT
© FORTINET
 PCI DSS 3.0 Compliance
If you’re new to PCI compliance, here is a brief overview. As you can see, it enforces many of security’s best
practices for more than a decade. So, you may already be mostly compliant.
FortiWeb Study Guide
374
DO NOT REPRINT
© FORTINET
 PCI DSS 3.0 Compliance
PCI has released its next security standard, version 3.2. This came into force on April 1, 2016.
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.
We’ll discuss each of these sub-requirements, and how to meet them.
FortiWeb Study Guide
375
DO NOT REPRINT
© FORTINET
 PCI DSS 3.0 Compliance
FortiWeb helps you meet all PCI requirements, but PCI now specifically recommends a web application
firewall (WAF), and developing remediations against the top 10 vulnerabilities, according to OWASP.
FortiWeb Study Guide
376
9
DO NOT REPRINT
© FORTINET
 PCI DSS 3.0 Compliance
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.
FortiWeb Study Guide
377
DO NOT REPRINT
© FORTINET
 PCI DSS 3.0 Compliance
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 upon its available attack data.
Many large organizations, including PCI, recommend that you scan for these vulnerabilities and fix or defend
against them.
FortiWeb Study Guide
378
DO NOT REPRINT
© FORTINET
 PCI DSS 3.0 Compliance
OWASP’s last update to the top 10 is from 2013. 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.
FortiWeb Study Guide
379
DO NOT REPRINT
© FORTINET
 PCI DSS 3.0 Compliance
Injection and cross-site scripting: these two vulnerabilities remain the most common threat every year. This
could be because they are the easiest to exploit, even for inexperienced attackers. All you need is to 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.
FortiWeb Study Guide
380
DO NOT REPRINT
© FORTINET
 PCI DSS 3.0 Compliance
The good news is that FortiWeb can easily prevent injection and cross-site scripting. 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.
FortiWeb Study Guide
381
DO NOT REPRINT
© FORTINET
 PCI DSS 3.0 Compliance
Great! You are now familiar with PCIDSS and the OWASP Top 10 list.
In the next section we will look at how you can identify if your web app is vulnerable.
FortiWeb Study Guide
382
DO NOT REPRINT
© FORTINET
 PCI DSS 3.0 Compliance
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 Study Guide
383
DO NOT REPRINT
© FORTINET
 PCI DSS 3.0 Compliance
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:
• SQL injection
• Cross-site scripting (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
FortiWeb Study Guide
384
DO NOT REPRINT
© FORTINET
 PCI DSS 3.0 Compliance
To prepare for a vulnerability scan, always begin by copying the web app and its database to a test
environment. DO NOT SCAN LIVE WEB SITES, 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.
FortiWeb Study Guide
385
DO NOT REPRINT
© FORTINET
 PCI DSS 3.0 Compliance
Let take a look at 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 only scan when you manually initiate it, select the One
Time option in the Type field.
FortiWeb Study Guide
386
DO NOT REPRINT
© FORTINET
 PCI DSS 3.0 Compliance
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 formbased 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.
FortiWeb Study Guide
387
DO NOT REPRINT
© FORTINET
 PCI DSS 3.0 Compliance
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 this example, the Network panel was opened before clicking the Log In in the web app. Since the form used
the POST method, parameters were in the HTTP body, not the headers, so we scrolled down to the Form
Data section at the bottom to copy the input that FortiWeb will use for authentication. As you can see, it has a
few more unexpected inputs – not only the user name and password.
FortiWeb Study Guide
388
DO NOT REPRINT
© FORTINET
 PCI DSS 3.0 Compliance
Once you’ve configured the scan, you can immediately run it by clicking Play, or wait for the appropriately
scheduled time. While the scan is running, the page periodically updates its progress. 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.
FortiWeb Study Guide
389
DO NOT REPRINT
© FORTINET
 PCI DSS 3.0 Compliance
To view the report while you’re logged into FortiWeb’s GUI, click its link in the Scan History page.
FortiWeb Study Guide
390
DO NOT REPRINT
© FORTINET
 PCI DSS 3.0 Compliance
The report lists the settings you chose and shows a summary of the number and types of vulnerabilities that
FortiWeb found. If you click a vulnerability type on the left, you can view details about where FortiWeb found
each vulnerability.
This slide shows the scan results from scanning WebGoat. OWASP is one of the organizations that
contributes to maintaining this security education web app. For security training purposes, it is designed to be
insecure. So, as you’d expect, FortiWeb detects many severe vulnerabilities.
FortiWeb Study Guide
391
DO NOT REPRINT
© FORTINET
 PCI DSS 3.0 Compliance
The details contained in a vulnerability report can help you to decide on which signatures you should use to
protect your servers, and prioritize work based on risk levels. Those details include:
• What was tested
• The severity of the potential effects of the vulnerability
If you determine that the vulnerability cannot be exploited, you can mark it as a false positive. Finding and
marking the false positives in scans ensures that you have an accurate list of vulnerabilities that you need to
address.
FortiWeb Study Guide
392
DO NOT REPRINT
© FORTINET
 PCI DSS 3.0 Compliance
Excellent! You now know how to perform a Vulnerability scan on FortiWeb.
In the next section we will look at more Top 10 threats.
FortiWeb Study Guide
393
DO NOT REPRINT
© FORTINET
 PCI DSS 3.0 Compliance
Now we’ve shown a couple of OWASP top 10 vulnerabilities, and how to detect them. What are the other
vulnerabilities?
FortiWeb Study Guide
394
DO NOT REPRINT
© FORTINET
 PCI DSS 3.0 Compliance
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, 2-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
FortiWeb Study Guide
395
DO NOT REPRINT
© FORTINET
 PCI DSS 3.0 Compliance
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.
FortiWeb Study Guide
396
DO NOT REPRINT
© FORTINET
 PCI DSS 3.0 Compliance
You select most A2 mitigations in the protection profile, but some you enable in the policy.
FortiWeb Study Guide
397
DO NOT REPRINT
© FORTINET
 PCI DSS 3.0 Compliance
Remember, if you have logging enabled (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.
FortiWeb Study Guide
398
DO NOT REPRINT
© FORTINET
 PCI DSS 3.0 Compliance
Insecure references to objects can occur wherever the web app does not validate authorization to those
objects. Just because a client has submitted a user name and password does not mean they should be
universally trusted. Each request must be validated to determine whether that person is authorized to change
others’ passwords, or to view other users’ secret boards.
This concept is similar to A7 and A10, which you will look at later. The difference is that A4 deals specifically
with parameters instead of pages, and application inputs instead of redirect URLs.
FortiWeb Study Guide
399
DO NOT REPRINT
© FORTINET
 PCI DSS 3.0 Compliance
To enforce valid input lengths and types, you should use parameter validation rules. However, other object
references are less obvious: a bookmark cookie that names a specific page, or a hidden preference to
remember your login token. From the web app’s perspective, these are inputs. Any data that affects how a
web server processes other data is, effectively, an input.
A .php file extension, for example, is an input that tells the web server that it should use its PHP preprocessor
to render the HTML page before replying to clients. If you allow a client to upload an arbitrary PHP file, and
then to go to that URL, they can access any data that the PHP module has access to. Cloaking the file
extension and preventing clients from uploading PHP files helps control which PHP objects they can access.
FortiWeb Study Guide
400
DO NOT REPRINT
© FORTINET
 PCI DSS 3.0 Compliance
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 A5. These files provide information that can be useful to attackers.
If their permissions are incorrect, these files can also be an exploit vector.
FortiWeb Study Guide
401
DO NOT REPRINT
© FORTINET
 PCI DSS 3.0 Compliance
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.
FortiWeb Study Guide
402
DO NOT REPRINT
© FORTINET
 PCI DSS 3.0 Compliance
Creative penetration testing by human specialists should always be a part of your security audits, but
automated testing should be part of your arsenal as well. It’s impractically slow to find common vulnerabilities
using only manual testing. For this, you can use FortiWeb’s built-in web vulnerability scanner. It uses HTTP
(like your users) and attempt to find unpatched modules, source code disclosure, plus vulnerabilities to three
of the OWASP top 10 threats.
A5 vulnerabilities will be listed under the Information and, sometimes, Source Disclosure vulnerabilities
categories. You can also use the Information Disclosure category of signatures to find A5 vulnerabilities.
FortiWeb Study Guide
403
DO NOT REPRINT
© FORTINET
 PCI DSS 3.0 Compliance
A6 covers sensitive data exposure.
This objective is at the heart of PCI DSS compliance. The other OWASP top 10 threats can impact 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.
FortiWeb Study Guide
404
DO NOT REPRINT
© FORTINET
 PCI DSS 3.0 Compliance
To enable DLP, edit a signature policy. You can configure FortiWeb to detect a violation based upon a specific
number of payment card numbers in the web page, if required.
FortiWeb Study Guide
405
DO NOT REPRINT
© FORTINET
 PCI DSS 3.0 Compliance
Remember: both A6 and PCI DSS require security while payment is in transit. To secure payment card data
while in transit, authentication and encryption are critical. Note that older SSL 2.0 and SSL 3.0 versions have
many known vulnerabilities, and should be avoided, if possible.
If you’re required to be PCI DSS compliant, SSL 2.0, weak key strength, and MD5 hashes are all considered
to be PCI DSS violations. Soon, SSL 3.0, TLS 1.0 and SHA-1 may be violations too. This is becoming
increasingly likely, because their specified renegotiation styles and cipher suites have exploits in the wild now.
FortiWeb Study Guide
406
DO NOT REPRINT
© FORTINET
 PCI DSS 3.0 Compliance
“Security through obscurity”. We’ve all heard this, right? Threat A7 is exactly that.
Simply because there are no public hyperlinks to an administrative web page does not mean that it won’t be
found and exploited. If your web server’s access rules don’t forbid it, an attacker could even access files
outside of your web app’s directory. And even within the web app itself, you can’t assume that clients will
always access web pages in authorized ways. Some of the most famous hacks have been executed simply by
editing the URL that was in the browser’s URL bar, trying to access URLs where the app didn’t check for
authorization. This is called forced browsing.
Remember: even if a user is authenticated, they are not necessarily authorized for every URL. For each
request, the app should verify that the client is authorized for that realm – as FortiWeb does – and in that step
in the session. The app should also check that URL should be accessible from that IP address. Configuration
files shouldn’t be accessible through the Internet. Access should be restricted to a private management
network.
There could be other URLs, used internally by the web application, whose permissions should be set so that
they can’t be accessed directly, from the Internet.
FortiWeb Study Guide
407
DO NOT REPRINT
© FORTINET
 PCI DSS 3.0 Compliance
Access control rules, including so-called custom rules, which allow you to combine multiple factors such as
User-Agent: and rate limiting, can be selected in the protection profile. So can the start pages, page order
rules, and signatures. In the signatures, verify that the directory traversal category is enabled.
FortiWeb Study Guide
408
DO NOT REPRINT
© FORTINET
 PCI DSS 3.0 Compliance
In A8, the client is correctly authenticated and correctly authorized, but an attacker either injects malicious
code, crafts a phishing email, or uses social engineering to trick the user into executing an action.
As you might expect, FortiWeb can detect and sanitize some forms of CSRF, like clickjacking. But other
forms of this attack are currently too CPU- and memory-intensive for prevention to be practical in real time.
They often require large numbers of both positive and negative security rules.
For example, let’s say that Jane has received an email that appears to be from her bank. It’s injected with
code so that when Jane visits the real bank web site and tries to transfer funds, they aren’t sent to the
intended recipient. Instead, funds are transferred to the attacker. In order to detect this kind of attack, a WAF
would need to remember all authorized transfer recipients, and block unauthorized ones, for every user, on
every web application. Also, this is only one input, on one web page. The WAF would need to understand
every input, on every page, of every protected web app. So, if possible, your app should try to safeguard
critical state machine transitions like this. Code security auditors can help you to find them, and CSRF
libraries exist to help eliminate this. These will help to safeguard against social engineering or chat vectors.
You can also enable FortiWeb signatures to guard against injections of CSRF code.
FortiWeb Study Guide
409
DO NOT REPRINT
© FORTINET
 PCI DSS 3.0 Compliance
This CSRF example shows how a person’s actions on a bank web site can be hijacked by an attacker. In this
example, the attacker sends a text message with a link. It is a simple page with an <iframe> and a script
that changes the Pay Bill button to send money to the attacker instead!
This is only one variant. The attacker could log keystrokes, activate the web cam, wiretap, or even send
requests without the user pressing any buttons at all. The attacker could deliver their script in many ways, too.
For example, malvertising – fake banner ads that point to a real web site such as a lottery or credit card
application form, but contain attack scripts – is becoming more common.
FortiWeb Study Guide
410
DO NOT REPRINT
© FORTINET
 PCI DSS 3.0 Compliance
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.
FortiWeb Study Guide
411
DO NOT REPRINT
© FORTINET
 PCI DSS 3.0 Compliance
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.
FortiWeb Study Guide
412
DO NOT REPRINT
© FORTINET
 PCI DSS 3.0 Compliance
Like A4, A10 deals with inputs that the web application hasn’t validated. In this case, it’s specifically inputs for
redirects. Apps should check both:
• Valid destination (if offsite redirects are allowed)
• Authorization of the person to go to those web pages
FortiWeb Study Guide
413
DO NOT REPRINT
© FORTINET
 PCI DSS 3.0 Compliance
You apply both access control rules and parameter validation rules by selecting them in the protection profile.
When you’re configuring the parameter validation rule, be careful. Can you find the misconfiguration for the
constraints on the redirect_to parameter? Look at its data type. Do you know what matches this data
type?
FortiWeb Study Guide
414
DO NOT REPRINT
© FORTINET
 PCI DSS 3.0 Compliance
Great! You now have a greater understanding of the OWASP to 10 threat list.
In the next section we will discuss defining custom data types.
FortiWeb Study Guide
415
DO NOT REPRINT
© FORTINET
 PCI DSS 3.0 Compliance
There may be cases where you want to adjust the predefined data types, or add your own.
FortiWeb Study Guide
416
DO NOT REPRINT
© FORTINET
 PCI DSS 3.0 Compliance
Look at the regular expressions that are in the predefined URI data type.
The predefined URI data type matches any valid URI – not just redirects to the same site. So it would still
allow redirects to another site, potentially a malicious one. Also, this data type also could block legitimate,
same-site redirects.
Finally, this regular expression matches URLs as you would type them into a browser – not ones that have
been URL encoded. (URL encoding translates some characters that are not allowed in a URL, such as
spaces, into entity encodings, such as ‘%20’. By default, FortiWeb only decodes 1 layer of URL encoding.)
To block redirects to another potentially malicious site or to match URL encoded inputs that have not been
fully decoded, we would customize the data type and set an advanced setting.
FortiWeb Study Guide
417
DO NOT REPRINT
© FORTINET
 PCI DSS 3.0 Compliance
To do this quickly, copy and modify the second regular expression. (By the way, you can find more regular
expression tips and cookbook examples in the FortiWeb Administration Guide.)
In this example, we’ve started to modify the expression to match only acceptable data type for the redirect
input. By opening the regular expression validator, we can check the expression to avoid mismatches while
we write.
We’re matching and allowing only redirects to example.com, www.example.com, or ftp.example.com. To
indicate alternatives, we put the set in parentheses, and put a vertical bar between each possible alternative.
Redirects must use either HTTP, HTTPS, or FTP. Characters can use their URL-encoded forms:
%3A
:
%2F
/
%3F
?
%3D
=
%26
&
Some of these characters have special meanings in the PCRE regular expression syntax, so we precede
them with a backslash character to escape the regex interpreter, and treat them as literal characters to match.
For example, to match a literal question mark, you would type the expression:
\?
FortiWeb Study Guide
418
DO NOT REPRINT
© FORTINET
 PCI DSS 3.0 Compliance
To prevent attackers from evading detection by encoding the URL twice or more, alternatively, you can enable
the option to undo it in the System > Config > Advanced menu. This is a global setting, so it can impact
performance of scanning every input, in every policy. Use it with caution and test your FortiWeb’s
performance. If necessary, adjust your data type instead.
FortiWeb Study Guide
419
DO NOT REPRINT
© FORTINET
 PCI DSS 3.0 Compliance
Congratulations! You have successfully completed this lesson.
FortiWeb Study Guide
420
DO NOT REPRINT
© FORTINET
 PCI DSS 3.0 Compliance
In this lesson, you learned the risks that PCI tries to mitigate, and its new recommendation specifically for web
application firewalls such as FortiWeb. You also learned about how mitigating the OWASP Top 10 most
serious threats can help to protect financial data. You learned FortiWeb features that protect against those
threats, including:
• Credit card leaks
• Signatures for injection, XSS, and known vulnerability exploits
• Session management, cookie poisoning detection, and secure authentication
• Start page and page order enforcement
• Administrative and configuration file access control
• Parameter sanity checks, including hidden inputs and redirects
Because FortiWeb enforces data types by using regular expressions, you learned how you can customize it to
enforce your app’s specific data types. Finally, you learned how to avoid recording passwords and payment
card numbers in logs.
FortiWeb Study Guide
421
DO NOT REPRINT
© FORTINET
 Caching and Compression
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.
FortiWeb Study Guide
422
DO NOT REPRINT
© FORTINET
 Caching and Compression
In this lesson we will explore the following topics:
• Response cache
• Response compression
FortiWeb Study Guide
423
DO NOT REPRINT
© FORTINET
 Caching and Compression
First, let’s take a look at how FortiWeb can cache responses from your protected web servers. Did you know
that FortiWeb can do more than just secure your web apps? It can make them faster, too.
FortiWeb Study Guide
424
DO NOT REPRINT
© FORTINET
 Caching and Compression
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 that 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 or on your FortiWeb.
FortiWeb Study Guide
425
DO NOT REPRINT
© FORTINET
 Caching and Compression
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.
FortiWeb Study Guide
426
DO NOT REPRINT
© FORTINET
 Caching and Compression
Cache on FortiWeb uses some of its RAM. So, before you enable cache, make sure that 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 content delivery network (CDN) such as Akamai, then there may be no net
benefit to enabling FortiWeb’s cache.
FortiWeb Study Guide
427
DO NOT REPRINT
© FORTINET
 Caching and Compression
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, right? 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 for 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 determine the size. Also, by
definition, live streams have dynamic content, not static.
FortiWeb Study Guide
428
DO NOT REPRINT
© FORTINET
 Caching and Compression
Let’s 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 this example? Remember: there are some things that FortiWeb
automatically doesn’t 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 that 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!
FortiWeb Study Guide
429
DO NOT REPRINT
© FORTINET
 Caching and Compression
Good job! You now know the purpose behind caching and how to implement it on FortiWeb.
In the next section we will discuss response compression.
FortiWeb Study Guide
430
DO NOT REPRINT
© FORTINET
 Caching and Compression
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.
FortiWeb Study Guide
431
DO NOT REPRINT
© FORTINET
 Caching and Compression
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, 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.
FortiWeb Study Guide
432
DO NOT REPRINT
© FORTINET
 Caching and Compression
Let’s 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.
FortiWeb Study Guide
433
DO NOT REPRINT
© FORTINET
 Caching and Compression
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.
FortiWeb Study Guide
434
DO NOT REPRINT
© FORTINET
 Caching and Compression
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 only
reduces the file size by 10%. But HTML gives us a better than 2:1 ratio.
FortiWeb Study Guide
435
DO NOT REPRINT
© FORTINET
 Caching and Compression
Here’s 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.
FortiWeb Study Guide
436
DO NOT REPRINT
© FORTINET
 Caching and Compression
Let’s 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!
FortiWeb Study Guide
437
DO NOT REPRINT
© FORTINET
 Caching and Compression
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.
FortiWeb Study Guide
438
DO NOT REPRINT
© FORTINET
 Caching and Compression
Depending on how much load your FortiWeb has, it may be better for your servers to do 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.
FortiWeb Study Guide
439
DO NOT REPRINT
© FORTINET
 Caching and Compression
Like a compression policies, uncompression policies are also based on file type. If you want to exclude any
responses from uncompression, you can do that, too.
FortiWeb Study Guide
440
DO NOT REPRINT
© FORTINET
 Caching and Compression
Congratulations! You have successfully completed this lesson.
FortiWeb Study Guide
441
DO NOT REPRINT
© FORTINET
 Caching and Compression
In this lesson, you learned two methods that you can use to improve the speed at which you deliver your web
apps to clients: cache and compression. You also learned how FortiWeb can buffer and uncompress a copy
of a precompressed packet in order to scan it, or modify it, or both, before forwarding it.
FortiWeb Study Guide
442
DO NOT REPRINT
© FORTINET
 HTTP Rewriting and Redirects
In this lesson, we’ll show you 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”.)
We’ll also explain how to redirect or rewrite pieces of the request or response for better usability and security.
FortiWeb Study Guide
443
DO NOT REPRINT
© FORTINET
 HTTP Rewriting and Redirects
In this lesson we will explore the following topics:
• Redirects
• What is a capture group and what is a back reference?
• Rewrites
• HTTP Content Routing
FortiWeb Study Guide
444
DO NOT REPRINT
© FORTINET
 HTTP Rewriting and Redirects
Let’s begin with redirects. This is usually the simplest thing you can do with FortiWeb’s rewriting rules.
Redirects also help you learn how to match traffic for rewriting, which we will talk about later.
FortiWeb Study Guide
445
DO NOT REPRINT
© FORTINET
 HTTP Rewriting and Redirects
When are redirects useful? Mostly to establish HTTP traffic flow.
When a page moves, or the makes a typo, you can tell the client to go to the new URL. This avoids 404
errors. It’s the most common use for redirects. On a larger scale, you can redirect people if the web app has
moved 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 we’ll talk about later.
FortiWeb Study Guide
446
DO NOT REPRINT
© FORTINET
 HTTP Rewriting and Redirects
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: 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 we don’t want to tell potential attackers which web server we’re using. To cloak the
server type, we 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 in mind. We’ll use the same concept later for rewriting traffic.
FortiWeb Study Guide
447
DO NOT REPRINT
© FORTINET
 HTTP Rewriting and Redirects
Here’s another example of a redirect. We’ll start 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.
FortiWeb Study Guide
448
DO NOT REPRINT
© FORTINET
 HTTP Rewriting and Redirects
To configure the HTTP-to-HTTPS redirect that we 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, the 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 we define in the
Location field. To avoid making one rewriting rule for each URL – which could be 10,000 – we use capture
group variables to define the location.
FortiWeb Study Guide
449
DO NOT REPRINT
© FORTINET
 HTTP Rewriting and Redirects
Great! You now know how to configure redirection on FortiWeb.
In the next section we will look at capture groups and back references.
FortiWeb Study Guide
450
DO NOT REPRINT
© FORTINET
 HTTP Rewriting and Redirects
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.
FortiWeb Study Guide
451
DO NOT REPRINT
© FORTINET
 HTTP Rewriting and Redirects
In case you’ve never used regular expressions before, or haven’t used them with output, let’s take a look at
capture groups.
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
FortiWeb Study Guide
452
DO NOT REPRINT
© FORTINET
 HTTP Rewriting and Redirects
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.
FortiWeb Study Guide
453
DO NOT REPRINT
© FORTINET
 HTTP Rewriting and Redirects
Now that we know what a capture group is, let’s look again at the match conditions for our 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:
.*
It’s also sometimes called a greedy match because it makes the biggest match that it can. Since the host
name is relatively short, that’s OK. But if we were matching HTML in the body, (.*) could be a performance
problem. Why? Because if the HTML page is large, we don’t want to store the entire page in a capture group
in RAM every time the page is requested! “.*” can be tempting to use everywhere because it’s easy to
remember. But this is a perfect example of why you should think carefully. Match accurately. Usually, you
should use the fewest number of character comparisons that you can, not the most.
Because we’ve wrapped the greedy match in parentheses, and because this is the first match condition in the
table, this causes FortiWeb to store the packet’s whole host name in capture group 0.
FortiWeb Study Guide
454
DO NOT REPRINT
© FORTINET
 HTTP Rewriting and Redirects
Next, we test to see if the URL line in the HTTP header matches. The URL line always begins with a forward
slash, and we want to capture the text after that, so the regular expression begins with:
^/
Then the capture group matches all text from that point 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.
FortiWeb Study Guide
455
DO NOT REPRINT
© FORTINET
 HTTP Rewriting and Redirects
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 we were redirecting possibly 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 we improve that?
FortiWeb Study Guide
456
DO NOT REPRINT
© FORTINET
 HTTP Rewriting and Redirects
Good job! You now know the about Capture Groups, Back References, and how to use them on FortiWeb
In the next section we will look at Rewrites.
FortiWeb Study Guide
457
DO NOT REPRINT
© FORTINET
 HTTP Rewriting and Redirects
The answer is rewrites. 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.
FortiWeb Study Guide
458
DO NOT REPRINT
© FORTINET
 HTTP Rewriting and Redirects
There are many more reasons why you might want to rewrite traffic. We can’t fit them all here. 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, we 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 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.
FortiWeb Study Guide
459
DO NOT REPRINT
© FORTINET
 HTTP Rewriting and Redirects
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.
FortiWeb Study Guide
460
DO NOT REPRINT
© FORTINET
 HTTP Rewriting and Redirects
When you configure a rewrite, you first indicate the direction of the traffic:
• Is it an incoming request?
• Is it an outgoing reply?
That’s because requests and replies have different HTTP headers and content, so the options will be 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.
FortiWeb Study Guide
461
DO NOT REPRINT
© FORTINET
 HTTP Rewriting and Redirects
Look at the example in this slide. Look at the match conditions. Can you guess which URLs will match? What
are the capture groups? Now, what is the output?
We want to hide the .php file extension and WordPress-specific login URL from clients. This helps to prevent
attackers from fingerprinting our server’s software stack, but it also means that if we change our app later to
movable type or Drupal, the following will be true:
• People won’t need to fix their browser’s bookmarks
• We won’t have to configure any redirects to avoid 404 errors
To make this work, we 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
FortiWeb Study Guide
462
DO NOT REPRINT
© FORTINET
 HTTP Rewriting and Redirects
On the left side, we 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 our rules, we group them in a URL rewriting policy, then select them in the protection profile.
FortiWeb Study Guide
463
DO NOT REPRINT
© FORTINET
 HTTP Rewriting and Redirects
Great! You now know how to configure rewrites on FortiWeb.
In the next section we will look at HTTP Content routing.
FortiWeb Study Guide
464
DO NOT REPRINT
© FORTINET
 HTTP Rewriting and Redirects
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 upon the IP
layer’s source and destination. But FortiWeb can also route based upon the HTTP layer.
Let’s take a look.
FortiWeb Study Guide
465
DO NOT REPRINT
© FORTINET
 HTTP Rewriting and Redirects
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 n 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.
FortiWeb Study Guide
466
DO NOT REPRINT
© FORTINET
 HTTP Rewriting and Redirects
This shows an example of HTTP content routing based upon the Cookie: header.
When a user goes to the web site, at first, they don’t have any session ID. We’ve configured a rule on
FortiWeb that directs the first page request to a login server, which assigns a session ID.
By doing this, we 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 Server 2, or Web Server 3, and so on. On FortiWeb, we 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 so 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.
FortiWeb Study Guide
467
DO NOT REPRINT
© FORTINET
 HTTP Rewriting and Redirects
Let’s take a look at 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.
FortiWeb Study Guide
468
DO NOT REPRINT
© FORTINET
 HTTP Rewriting and Redirects
To apply your routes, in your server policy, select HTTP Content Routing from the 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.
FortiWeb Study Guide
469
DO NOT REPRINT
© FORTINET
 HTTP Rewriting and Redirects
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.
This 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.
FortiWeb Study Guide
470
DO NOT REPRINT
© FORTINET
 HTTP Rewriting and Redirects
Congratulations! You have successfully completed this section
FortiWeb Study Guide
471
DO NOT REPRINT
© FORTINET
 HTTP Rewriting and Redirects
In this lesson, you learned about how you can redirect users to a secure site, and rewrite URLs in the headers
and in links in web pages. You also learned how rewriting can be both a convenience to users and a security
feature. To show how you can use parts of a match when constructing the new host name, URL or header,
this lesson explained how to use capture groups.
Finally, you also learned a different way that FortiWeb can use those same match criteria: FortiWeb can act
as an OSI Layer 7 switch to forward requests for specific web applications to specific servers.
FortiWeb Study Guide
472
DO NOT REPRINT
© FORTINET
 Troubleshooting
In this lesson, you’ll learn how to avoid common misconfigurations, diagnose false positives, solve
connectivity and storage issues, and optimize your FortiWeb’s performance.
FortiWeb Study Guide
473
DO NOT REPRINT
© FORTINET
 Troubleshooting
In this lesson we will explore the following topics:
• False positives
• SSL/TLS issues
• Performance
• Traffic flow and site statistics
• HA and FortiGuard
FortiWeb Study Guide
474
DO NOT REPRINT
© FORTINET
 Troubleshooting
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.
FortiWeb Study Guide
475
DO NOT REPRINT
© FORTINET
 Troubleshooting
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 the 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 white list will not immediately restore connectivity.
FortiWeb Study Guide
476
DO NOT REPRINT
© FORTINET
 Troubleshooting
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 falsepositives to fix, especially for HTTP constraints or input rules, auto learning can be a useful tool to help you
update your FortiWeb settings.
Remember: full 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.
FortiWeb Study Guide
477
DO NOT REPRINT
© FORTINET
 Troubleshooting
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.
FortiWeb Study Guide
478
DO NOT REPRINT
© FORTINET
 Troubleshooting
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
FortiWeb Study Guide
479
DO NOT REPRINT
© FORTINET
 Troubleshooting
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
white list 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 white list entry.
FortiWeb Study Guide
480
DO NOT REPRINT
© FORTINET
 Troubleshooting
A white list 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.
White lists are best for individual browsers, not for search engine crawlers.
FortiWeb Study Guide
481
DO NOT REPRINT
© FORTINET
 Troubleshooting
If the client isn’t a person – 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, not specific to each policy. So if you need that feature, or if you need to add
another search engine such as Duck Duck Go!, please contact us for a feature enhancement request.
FortiWeb Study Guide
482
DO NOT REPRINT
© FORTINET
 Troubleshooting
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.
FortiWeb Study Guide
483
DO NOT REPRINT
© FORTINET
 Troubleshooting
Good job! You now know how to identify and resolve false positive situations on FortiWeb.
In the next section we will look at SSL/TLS related issues.
FortiWeb Study Guide
484
DO NOT REPRINT
© FORTINET
 Troubleshooting
If your FortiWeb is scanning HTTPS, you can troubleshoot encryption–related issues.
FortiWeb Study Guide
485
DO NOT REPRINT
© FORTINET
 Troubleshooting
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 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 white listing 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?
FortiWeb Study Guide
486
DO NOT REPRINT
© FORTINET
 Troubleshooting
There are some misconfiguration issues that are possible with HTTPS. Here is an example of two common
ones.
FortiWeb Study Guide
487
DO NOT REPRINT
© FORTINET
 Troubleshooting
If the client and SSL terminator (this 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 is possible, especially if your web application or clients only supports 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.
FortiWeb Study Guide
488
DO NOT REPRINT
© FORTINET
 Troubleshooting
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 perfect forward secrecy (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 (due to the nature of transparent inspection) FortiWeb
is out-of-sync with the current keys, then packet inspection will fail. It’s normal for PFS with that operation
mode.
To fix this, on your web servers, you must disable those types of cipher suites. Here’s an example of how to
do this in an Apache 2 configuration file.
FortiWeb Study Guide
489
DO NOT REPRINT
© FORTINET
 Troubleshooting
Great! You are now able to resolve SSL/TLS related issues.
In the next section we will look at performance related topics.
FortiWeb Study Guide
490
DO NOT REPRINT
© FORTINET
 Troubleshooting
Once scans are functioning correctly, verify performance. Security should not be your bottleneck.
FortiWeb Study Guide
491
DO NOT REPRINT
© FORTINET
 Troubleshooting
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 night time 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?
FortiWeb Study Guide
492
DO NOT REPRINT
© FORTINET
 Troubleshooting
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 signatures trap, then you may need to optimize a
custom signature’s regular expression. If possible, reduce the number of characters consumed or forwardlooking required in order to determine a match.
FortiWeb Study Guide
493
DO NOT REPRINT
© FORTINET
 Troubleshooting
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, that you don’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.
FortiWeb Study Guide
494
DO NOT REPRINT
© FORTINET
 Troubleshooting
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.
FortiWeb Study Guide
495
DO NOT REPRINT
© FORTINET
 Troubleshooting
Like 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 you and Fortinet Technical Support locate the true cause.
FortiWeb Study Guide
496
DO NOT REPRINT
© FORTINET
 Troubleshooting
Just like your web applications, your 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 your response cache and antivirus buffer, 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 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.
FortiWeb Study Guide
497
DO NOT REPRINT
© FORTINET
 Troubleshooting
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.
FortiWeb Study Guide
498
DO NOT REPRINT
© FORTINET
 Troubleshooting
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 30 GB large.
Currently, it contains very little data relative to its total capacity. But the 97 MB /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.
FortiWeb Study Guide
499
DO NOT REPRINT
© FORTINET
 Troubleshooting
In this slide, you can see that the 97 MB /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.
FortiWeb Study Guide
500
DO NOT REPRINT
© FORTINET
 Troubleshooting
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.
FortiWeb Study Guide
501
DO NOT REPRINT
© FORTINET
 Troubleshooting
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 exec reboot command. You can
use this command to show which accounts are currently logged in.
FortiWeb Study Guide
502
DO NOT REPRINT
© FORTINET
 Troubleshooting
Excellent! You are now able to identify and resolve Performance related issues.
In the next section we will discuss traffic flow and site statistics.
FortiWeb Study Guide
503
DO NOT REPRINT
© FORTINET
 Troubleshooting
FortiWeb has tools that you can use to study your normal traffic flows.
FortiWeb Study Guide
504
DO NOT REPRINT
© FORTINET
 Troubleshooting
You can download the data analytics database from Fortinet Technical Support. When you upload it to
FortiWeb, the Data Analytics option becomes usable in policies.
Data analytics queries your attack and traffic statistics, and HTTP return codes in server replies. It then
correlates them with specific regions of the world and attack categories.
FortiWeb Study Guide
505
DO NOT REPRINT
© FORTINET
 Troubleshooting
Data analytics is useful for more than just a security perspective.
If you need to measure the success of online sales campaigns in a new region, data analytics can help you to
measure this.
FortiWeb Study Guide
506
DO NOT REPRINT
© FORTINET
 Troubleshooting
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, FortiWeb VM will show slightly different output.
For example, the driver will be for the virtual hardware, provided by Xen or VMware. The virtual MAC isusually
be 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.
FortiWeb Study Guide
507
DO NOT REPRINT
© FORTINET
 Troubleshooting
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.
FortiWeb Study Guide
508
DO NOT REPRINT
© FORTINET
 Troubleshooting
To test your routing paths, FortiWeb has ping and traceroute commands.
FortiWeb Study Guide
509
DO NOT REPRINT
© FORTINET
 Troubleshooting
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&externalId=11186
FortiWeb Study Guide
510
DO NOT REPRINT
© FORTINET
 Troubleshooting
Let’s 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.
FortiWeb Study Guide
511
DO NOT REPRINT
© FORTINET
 Troubleshooting
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 this example, the command runs
until the administrator presses Ctrl+C, as indicated by ^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.
FortiWeb Study Guide
512
DO NOT REPRINT
© FORTINET
 Troubleshooting
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.
FortiWeb Study Guide
513
DO NOT REPRINT
© FORTINET
 Troubleshooting
If FortiGuard updates fail, these debug commands 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.
FortiWeb Study Guide
514
DO NOT REPRINT
© FORTINET
 Troubleshooting
Good job! You are now able to view and interpret basic traffic flow and site statistics information.
In the next section we will look at high availability and FortiGuard related issues.
FortiWeb Study Guide
515
DO NOT REPRINT
© FORTINET
 Troubleshooting
If you have an HA cluster, and especially if you use FortiWeb VM, here are a few specific tips.
FortiWeb Study Guide
516
DO NOT REPRINT
© FORTINET
 Troubleshooting
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.
FortiWeb Study Guide
517
DO NOT REPRINT
© FORTINET
 Troubleshooting
Congratulations! You have successfully completed this section.
FortiWeb Study Guide
518
DO NOT REPRINT
© FORTINET
 Troubleshooting
In this lesson you learn how you can 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.
FortiWeb Study Guide
519