FortiWeb Student Guide-Online

DO NOT REPRINT
© FORTINET
FortiWeb
Student Guide
for FortiWeb 5.3.4
DO NOT REPRINT
© FORTINET
FortiWeb Student Guide
for FortiWeb 5.3.4
Last Updated: 6 May 2015
We would like to acknowledge the following major contributors: Martijn Duijm, Idan Soen, Shiqiang Xu
Fortinet®, FortiGate®, and FortiGuard® are registered trademarks of Fortinet, Inc. in the U.S. and other
jurisdictions, and other Fortinet names herein may also be trademarks, registered or otherwise, of
Fortinet. All other product or company names may be trademarks of their respective owners. Copyright
© 2002 - 2015 Fortinet, Inc. All rights reserved. Contents and terms are subject to change by Fortinet
without prior notice. 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.
DO NOT REPRINT
© FORTINET
Table of Contents
VIRTUAL LAB BASICS ...................................................................................7
Topology..................................................................................................................................7
Logging In ...............................................................................................................................8
Disconnections/Timeouts .............................................................................................................................12
Transferring Files to the VM....................................................................................................12
Using HTML5 Instead of Java ................................................................................................12
Screen Resolution...................................................................................................................13
International Keyboards ..........................................................................................................13
Troubleshooting Tips ..............................................................................................................14
1 SETUP.......................................................................................................16
Objectives ...............................................................................................................................16
Time to Complete....................................................................................................................16
1 Configure Network Settings on your Fortinet Devices........................................................17
2 Access the GUI ...................................................................................................................20
3 Verify Connectivity to the Web Servers ..............................................................................21
4 Traffic Flow through FortiWeb to the Web Servers ............................................................22
2 INTEGRATING REMOTE LOGGING & REPORTS .............................................25
Objectives ...............................................................................................................................25
Time to Complete....................................................................................................................25
1 Configure Logging...............................................................................................................26
2 Configure FortiAnalyzer to Receive Logs ...........................................................................27
3 Configure FortiWeb to Send Logs to FortiAnalyzer............................................................29

DO NOT REPRINT
© FORTINET
4 Generate Customized FortiWeb Reports on FortiAnalyzer ................................................30
3 INTEGRATING FRONT-END FORTIGATE SOURCE NAT.................................32
Objectives ...............................................................................................................................32
Time to Complete....................................................................................................................32
1 Configure FortiGate Source NAT and Transmission of 'X-Forwarded-For:'.......................33
2 Configure FortiWeb to Use X-Headers...............................................................................36
4 MITIGATING DOS ATTACKS........................................................................38
Objectives ...............................................................................................................................38
Time to Complete....................................................................................................................38
1 Test for Slow Headers DoS Vulnerability ...........................................................................39
2 Configure FortiWeb to Protect Against TCP Floods...........................................................40
5 SIGNATURES & AUTO-LEARNING ...............................................................41
Objectives ...............................................................................................................................41
Time to Complete....................................................................................................................41
1 Enable Auto-Learning .........................................................................................................42
2 Simulate Attacks .................................................................................................................43
3 Generate a Protection Profile .............................................................................................44
6 SSL / TLS ................................................................................................46
Objectives ...............................................................................................................................46
Time to Complete....................................................................................................................46
1 Upload the Server's Certificate & Key to FortiWeb.............................................................47
2 Offload HTTPS to FortiWeb................................................................................................48

DO NOT REPRINT
© FORTINET
7 AUTHENTICATION & ACCESS CONTROL ......................................................49
Objectives ...............................................................................................................................49
Time to Complete....................................................................................................................49
1 Sophisticated Access Control .............................................................................................50
2 HTTP Authentication...........................................................................................................53
8 REWRITING & REDIRECTS ..........................................................................57
Objectives ...............................................................................................................................57
Time to Complete....................................................................................................................57
1 Redirect HTTP to HTTPS ...................................................................................................58
9 TROUBLESHOOTING...................................................................................59
Objectives ...............................................................................................................................59
Time to Complete....................................................................................................................59
1 Determine Baselines & Normal Resource Usage ..............................................................60
2 Fix the False Positives ........................................................................................................61
APPENDIX A: ADDITIONAL RESOURCES........................................................62
APPENDIX B: PRESENTATION SLIDES ...........................................................63
1 WAF Concepts ....................................................................................................................64
2 Basic Setup .........................................................................................................................104
3 Integrating External SIEM ...................................................................................................156
4 Integrating Front-End SNAT & Load Balancers .................................................................206
5 DoS & Defacement .............................................................................................................230
6 Signatures, Sanitization, & Auto-Learning..........................................................................262
7 SSL / TLS............................................................................................................................310
DO NOT REPRINT
© FORTINET
8 Authentication & Access Control ........................................................................................355
9 PCI DSS 3.0 Compliance....................................................................................................383
10 Caching & Compression ....................................................................................................432
11 HTTP Routing, Rewriting, & redirects................................................................................451
12 Troubleshooting .................................................................................................................477
DO NOT REPRINT  Virtual Lab Basics Topology
© FORTINET
Virtual Lab Basics
In this class, you will use a virtual lab for hands-on exercises. This section explains how to connect to
the lab and its virtual machines. It also shows the topology of the virtual machines in the lab.
Note: If your trainer asks you to use a different lab, such as devices physically located in
your classroom, please ignore this section. This applies only to the virtual lab accessed
through the Internet. If you do not know which lab to use, please ask your trainer.
Topology
LINUX1 FortiAnalyzer
eth0 port1
10.0.1.21 10.0.1.210
LINUX2
eth0 FortiGate
10.0.1.22 port3
10.0.1.254/24
vserver-to-fortiweb
10.0.1.253
FortiWeb
port1
WINDOWS1
10.0.1.7
10.0.1.10
vserver1
10.0.1.8
Initially, virtual server addresses are not used. You will configure them later, in the lab.
FortiWeb Student Guide 7

DO NOT REPRINT  Virtual Lab Basics Logging In
© FORTINET
Logging In
1. Run the System Checker. This will fully verify both:
 compatibility with the virtual lab environment's software, and
 that your computer can connect
It can also diagnose problems with your Java Virtual Machine, firewall, or web proxy.
Use the URL for your location.
North America/South America:
https://remotelabs.training.fortinet.com/training/syscheck/?location=NAM-West
Europe/Middle East/Africa:
https://remotelabs.training.fortinet.com/training/syscheck/?location=Europe
Asia/Pacific:
https://remotelabs.training.fortinet.com/training/syscheck/?location=APAC
If a security confirmation dialog appears, click Run.
If your computer successfully connects to the virtual lab, the result messages for the browser
and network checks will each display a check mark icon. Continue to the next step.

© FORTINET
If a browser test fails, this will affect your ability to access the virtual lab environment. If a network
test fails, this will affect the usability of the virtual lab environment. For solutions, either click the
Support Knowledge Base link or ask your trainer.
2. With the user name and password from your trainer, log into the URL for the virtual lab. Either:
https://remotelabs.training.fortinet.com/
https://virtual.mclabs.com/
3. If prompted, select the time zone for your location, then click Update.
This ensures that your class schedule is accurate.

© FORTINET
4. Click Enter Lab.
A list of virtual machines that exist in your virtual lab should appear.
From this page, you can access the console of any of your virtual devices by either:
 clicking on the device’s square, or
 selecting System > Open.

© FORTINET
5. Click K2-Win-Student to open a connection to that server.
A new window should open within a few seconds. (Depending on your account’s preferences, the
window may be a Java applet. If this fails, you may need change browser settings to allow Java to
run on this web site. You also may need to review and accept an SSL certificate.)
Depending on the virtual machine, the applet provides access to either the GUI or a text-based
CLI. Connections to Windows machines will use a Remote Desktop-like GUI. The applet
should automatically log in, then display the Windows desktop. For most lab exercises, you will
connect to this VM.

DO NOT REPRINT  Virtual Lab Basics Transferring Files to the VM
© FORTINET
Disconnections/Timeouts
If your computer’s connection with the virtual machine times out or if you are accidentally
disconnected, to regain access, return to the initial window/tab that contains your session’s list of VMs
and open the VM again.
If your session frequently times out or does not connect, ask your instructor.
Transferring Files to the VM

When using the Java applet to connect to a VM, you can drag-and-drop files from your computer to
the VM. For example, if you have a FortiGate configuration file that you want to upload to your lab VM,
you could create it on your computer, then drag it into the Java application window that is connected to
the Windows VM. Usually the destination folder is C:\Uploads.
Alternatively, if you store files in a cloud service such as Dropbox or SugarSync, you can use the web
browser to download them to your VM instead.
Using HTML5 Instead of Java

When you open a VM, your browser may download and use a Java application to connect to the
virtual lab’s VM. This means that Java must be installed, updated, and enabled in your browser.
Alternatively, you can use HTML5 instead. Click the Settings button, then select Use Java Client. Click
Save & Disconnect, then log in again. (To use this preference, your browser must allow cookies.)

DO NOT REPRINT  Virtual Lab Basics Screen Resolution
© FORTINET
When connecting to a VM, your browser should then open a display in a new window or tab.
Screen Resolution
Some Fortinet devices' user interfaces require a minimum screen size.
In the Java client, to configure the screen resolution, click the arrow at the top of the window.
In the HTML 5 client, to configure screen resolution, open the System menu.
International Keyboards
If characters in your language don’t display correctly, keyboard mappings may not be correct.

DO NOT REPRINT  Virtual Lab Basics Troubleshooting Tips
© FORTINET
To solve this in the HTML 5 client, open the Keyboard menu at the top of the window. Choose to either
display an on-screen keyboard, or send text from your computer to the VM's clipboard.
To solve this in the Java client, copy and paste between your computer and the Java applet. This
sends special characters or combinations using the keyboard icon at the top of the applet window.
Troubleshooting Tips
 If the HTML 5 client does not work, try the Java client instead. Remembering this preference
requires that your browser allow cookies.
 Do not connect to the virtual lab environment through a low-bandwidth or high-latency connection,
including VPN tunnels or wireless such as 3G or Wi-Fi. For best performance, use a stable
broadband connection such as a LAN.
 Do not disable or block Java applets. On Mac OS X since early 2014, to improve security, Java
has been disabled by default. In your browser, you must allow Java for this web site. On
Windows, if the Java applet is allowed and successfully downloads, but does not appear to
launch, you can open the Java console while troubleshooting. To do this, open the Control
Panel, click Java, and change the Java console setting to be Show console.
Network firewalls can also block Java executables.
Note: JavaScript is not the same as Java.

DO NOT REPRINT  Virtual Lab Basics Troubleshooting Tips
© FORTINET
 Prepare your computer's settings:

o Disable screen savers
o Change the power saving scheme so that your computer is always on, and does not go to
sleep or hibernate
 If disconnected unexpectedly from any of the virtual machines (or from the virtual lab portal),
please attempt to reconnect. If unable to reconnect, please notify the instructor.
 If during the labs, particularly when reloading configuration files, you see a message similar to the
one shown below, the VM is waiting for a response to the authentication server.
 To retry immediately, go to the console and enter the CLI command:
exec update-now

DO NOT REPRINT  1 Setup Objectives
© FORTINET
1 Setup
This lab will provide an initial orientation to FortiWeb's administrative GUI and CLI, and guide you
through configuring the network interfaces. It will also guide you through establishing traffic flow
through FortiWeb.
Objectives
 Configure FortiWeb network interfaces and a default route for administrative access via your lab
network, such as with web browser, Telnet or SSH client
 Access the GUI
 Verify connectivity to the web servers
 Configure FortiWeb in reverse proxy mode to allow basic HTTP traffic flow through it to the back-
end web servers
Time to Complete
Estimated: 20 minutes

DO NOT REPRINT  1 Setup Time to Complete
© FORTINET
1 Configure Network Settings on your Fortinet Devices
1. If you are using a local lab instead of the cloud-based virtual lab, start these virtual machines.
Otherwise, skip this step.
 FortiWeb
 FortiAnalyzer
 FortiGate (FORTIGATE1)
 LINUX1
 LINUX2
2. Open the console of the FortiWeb VM.
3. At the login prompt, enter the username admin (all lower case). Leave the password blank.
4. To be able to access the FortiWeb's GUI, you must first configure the port1 network interface.
Assign its IP address, and specifically allow HTTP connections to the GUI. You also must
configure its default gateway.
conf system interface
edit port1
set ip 10.0.1.7/24
set allowaccess http https ssh ping
end
config route static
edit 0
set device port1
set gateway 10.0.1.10
end
After you enter the "end" command, FortiWeb saves its running configuration in RAM, and also
saves it to the flash disk.
HTTPS or SSH are recommended for administrative access to FortiWeb because those
protocols provide authentication and encryption. Other available protocols include SSH, ICMP
(ping), SNMP, HTTP and telnet.
5. Verify that you've entered your configuration correctly by entering these commands:
show system interface
show route static

Alternatively, you can enter a shorter form (as long as it's not ambiguous with another
command):

© FORTINET
show sys int
6. Configure the network settings on the FortiGate VM:
edit port3
set ip 10.0.1.254/24
end
config route static
edit 0
set device port3
end
7. Configure the network settings on the FortiAnalyzer VM:
edit port1
set ip 10.0.1.210/24
end
config system route
edit 0
set device port1
end
8. Verify that FortiWeb can connect to your computer, FortiGate, and 2 web servers. Also verify
that your computer can connect to FortiWeb and FortiGate.
In FortiWeb's console, enter:
exec ping 10.0.1.10
exec ping 10.0.1.254
exec ping 10.0.1.210

© FORTINET
exec ping 10.0.1.21
exec ping 10.0.1.22

On your computer, use the Windows menu to open a command prompt (cmd.exe) and enter:
ping 10.0.1.7
ping 10.0.1.254
ping 10.0.1.210
ping 10.0.1.21
ping 10.0.1.22

© FORTINET
2 Access the GUI
Like with FortiGate, once you have configured its network interfaces, you can use your web browser to
connect to the GUI (or CLI) and configure many settings on FortiWeb.
Once you have access to FortiWeb through the network, you can alternatively upload configuration
files instead of configuring all settings through the GUI or CLI.
1. On the Windows computer, open a web browser.
Go to the URL for FortiWeb's GUI:
http://10.0.1.7/
2. Log in with the default account named admin (all lower case) with no password.
3. Go to System > Maintenance > System Time. From the Time Zone drop-down, select your time
zone, such as (GMT-5:00) Eastern Time.
4. Go to System > Network > DNS. Enter the IP address of at least one DNS server, such as 8.8.8.8.
In an offline lab, this will have no effect, but in a real network that is connected to the Internet, this
is required for FortiWeb to look up addresses of servers such as FortiGuard and NTP.
5. Go to System > Admin > Settings. Change the session timeout to 480 minutes.
Caution: This is not typical on a production network. During this class, a long timeout will
allow you to avoid repeated logins between labs. But in a production network, the timeout
should be 5 minutes or less. Failure to prevent access to an unattended administrative
sessions compromises the security of your network.
6. By default, FortiGate and FortiAnalyzer's GUI will redirect plain HTTP to secure HTTPS. To
disable this on FortiAnalyzer, for example, go to http://10.0.1.210/ and in System Settings >
Admin > Admin Settings, disable Redirect to HTTPS. (This is not recommended in production
networks, but in your virtual lab, this will allow you to avoid certificate warnings due to the built-in
default certificate.)

© FORTINET
3 Verify Connectivity to the Web Servers
The web servers that you will be configuring FortiWeb to protect are already configured.
From the Windows computer, open a browser and go to:
 http://10.0.1.21/
 http://10.0.1.22/
 https://10.0.1.21/ (because this certificate is self-signed, it is normal to see an HTTPS error)
 https://10.0.1.22/ (because this certificate is self-signed, it is normal to see an HTTPS error)
If the connections are successful, you should see a web page that says “LINUX1's Blog!” or “LINUX2’s
Blog!”.

© FORTINET
4 Traffic Flow through FortiWeb to the Web Servers
Before you begin to apply protection, first verify that HTTP traffic can pass through FortiWeb. To do
this, connect to the virtual server's IP. You should receive a web page that is actually hosted on one of
the back-end protected servers. This verifies your routing, virtual servers, and policy configuration.
Note: This lab requires Firefox with add-ons installed: Clear Cache & Live HTTP Headers.
1. On the Windows computer, open a web browser. Go to the URL for FortiWeb's GUI:
3. Define the IP where FortiWeb's reverse proxy will pick up HTTP requests.
Go to Server Objects > Server > Virtual Server. Add a virtual server named vserver1 with the IP
address 10.0.1.8/24, bound to the port1 interface. Click OK to save your changes.
4. Indicate that during an HTTP session, FortiWeb should consistently route requests from the same
client to the same back-end web server.
Go to Server Objects > Server > Persistence, select Insert Cookie, and enter the name session-
persistence-cookie1.
5. Monitor back-end servers for availability, forwarding requests to them only if they are up.
Go to Server Objects > Server > Health Check and add a health check.
Name: availability-check1
Protocol Type: HTTP
URL /bitnami/images/close.png
Matched Content .*
6. Define the web servers that FortiWeb will forward traffic to for load balancing.
Go to Server Objects > Server > Server Pool and add a server farm with entries for both web
servers.
Name: server-pool1
Type Reverse Proxy
Single
Server/Server Server Balance
Balance
Server Health
availability-check1
Check

© FORTINET
Session
session-persistence-cookie1
Persistence
IP 10.0.1.21
10.0.1.22
Note: In the lab, the servers and virtual devices are all on the same 10.0.1.0/24 subnet.
This is so that you can directly access each GUI from the Windows computer.
In a production network, however, hosts may be on separate subnets, separated by NAT.
Make sure you use the IP addresses as they appear from FortiWeb's perspective in the
network. Due to NAT, these may not be the IP address configured on each server's NIC.
Instead, you may need to enter each server's virtual server/VIP address.
7. Add a policy to combine and apply your previous proxy pickup and load balancing settings, and to
allow HTTP traffic flow unless it violates your security policy.
Go to Policy > Server Policy > Server Policy and add a new policy.
Name: policy1
Deployment Mode Single Server/Server Pool
Virtual Server vserver1
Server Pool server-pool1
HTTP Service HTTP
Web Protection
Inline Alert Only
Profile
Auto Learn Profile Default Auto Learn Profile
8. Go to System > Status > Policy Status. There should be two entries: one for each of the web
servers that you have configured policy1 to monitor.
If FortiWeb can successfully connect to those servers via HTTP, both circles in the Health Check
Status column should be green.

© FORTINET
You can also monitor the servers' status via the event log.
9. Go to the virtual server's IP (http://10.0.1.8/). You should receive a web page from one of the
servers on the back end. Because we are load balancing between two identical servers, the page
should look almost the same regardless of which server receives your page request.
The only difference might be the title: "LINUX1's Blog!" or "LINUX2's Blog!" should change if the
session cookie expires, or a new session is created for any other reason, and FortiWeb directs the
next request to a different back-end server.
10. Click Live HTTP Headers then refresh the page.
What is the value for cookiesession2? (This is your persistence session ID from FortiWeb.)
Alternatively, to observe session cookie behavior with multiple clients, you can open multiple
browsers such as Chrome, Firefox, and Internet Explorer. Since each have their own cache, each
will keep separate session cookies.
For example, to view cookies in Internet Explorer 11, go to Tools > Developer Tools, click Network
on the bottom left, then click the Play button. Refresh the page. Click the Details tab. The Cookies
row should show the names and values of all cookies for the page.
11. Click Clear Cache to delete cookies. Close the browser.
12. Open Firefox again. Go to http://10.0.1.8/ again.
Is the blog title the same? Compare the value of the session cookie with the previous steps.
Are any of the cookie values identical? Did FortiWeb forward the traffic to the same back-end web
server, or a different one?

DO NOT REPRINT  2 Integrating Remote Logging & Reports Objectives
© FORTINET
2 Integrating Remote Logging &
Reports
Objectives
 Enable event logging
 Enable traffic logging
 Enable attack logging
 Keep the packet payload that was a detected violation for troubleshooting false positives
 Collect logs on a centralized solution such as FortiAnalyzer
 Use FortiAnalyzer to generate reports based on traffic and attack logs from FortiWeb
Time to Complete

DO NOT REPRINT  2 Integrating Remote Logging & Reports Time to Complete
© FORTINET
1 Configure Logging
Before configuring FortiWeb to send logs to centralized storage, we will first enable local logging and
verify that expected events are being recorded.
3. Go to Log & Report > Log Config > Global Log Settings.
Verify that logging to disk and memory is enabled, with the "Information" level of detail selected.
Caution: This is not typical on a normal network, except for during troubleshooting.
Frequent logging consumes system resources, reduces performance, and can cause
premature hard disk failure.
4. Go to Log & Report > Log Config > Other Log Settings.
Enable both the traffic log and Traffic Packet Log.
Caution: This is not typical on a normal network, except for during troubleshooting.
Recording the scan buffer to disk consumes system resources, reducing performance.
Enable Custom Access Violation.

Click Apply to save the settings to FortiWeb’s flash disk.
5. Go to Log & Report > Log Access > Event. You should see many events for your logins, and for
when the web servers are unreachable by the server health monitors. When you simulate attacks,
you should also see entries in the attack log. When you attempt to connect through FortiWeb's
virtual server, you should see entries in the traffic log, regardless of whether it was blocked. (In
those cases, there will be a request, but no corresponding response from the server.)
6. Go to the virtual server's address:
7. Return to the traffic log in Log & Report > Log Access > Traffic.
You should now see both your request, and the server's reply. (If FortiWeb had blocked the
request, you would see the request only -- no reply. The blocked request would be recorded in the
attack log instead.)
8. Hide the Source Country column in the attack log.
Since our lab uses all private network IPs, there will be no public Internet IP that FortiWeb can
use to associate the clients with a particular geographic region. Hiding this column will help you
to focus on other, relevant columns.
9. Log out and log in again. Is the Source Country column still hidden? Or was the setting cleared
when you ended your administrative session?

© FORTINET
2 Configure FortiAnalyzer to Receive Logs
For performance reasons and report customization, remote logging is strongly recommended. This
reduces system resource overhead required to buffer and write logs to disk locally. You can configure
FortiAnalyzer or any third-party device that supports syslog to receive logs.
1. On FortiWeb's GUI, go to System > Status > Status and copy the VM's serial number.
2. Go to the URL for FortiAnalyzer's GUI:
https://10.0.1.210/
3. Enable ADOMs. In the System Settings tab, in the System Information widget, enable
Administrative Domains (ADOMs). FortiAnalyzer will automatically log you out. Log back in again.
4. Create a new database that uses the schema for storing logs from this version of FortiWeb.
In the Device Manager tab, from the ADOM menu, select Manage ADOMs. Create a new ADOM
named FortiWebADOM for FortiWeb devices and choose firmware version 5.2. (This is not your
FortiWeb's exact firmware version, but it uses a compatible log message schema, which is the
purpose of this selection.)
5. Add your FortiWeb to the new ADOM’s device list.
In the ADOM menu, select FortiWebADOM, then click the Add Device button.
Enter the FortiWeb's IP address (10.0.1.7), the user name admin, and no password, then click
Next.
(Unlike with FortiGate, for FortiWeb, FortiAnalyzer does not currently make an OFTP device
registration connection, so this account name and password is not actually used.)
Note: In the lab, FortiAnalyzer is on the same subnet as FortiWeb, with no firewall policies
blocking communication.
In a production network, you may need to add a firewall policy on your FortiGate to allow
UDP port 514 (syslog) from FortiWeb to FortiAnalyzer. If FortiAnalyzer is in a remote data
center, since logs contain sensitive security information and syslog is not encrypted or
authenticated, you should also create an IPsec VPN tunnel between networks to protect
that traffic.
From Device Type, select FortiWeb. (Other options that vary by this choice will appear.)
From Device Model, select FortiWeb-VM, and from License Type, select FVVM00. (Valid serial
numbers vary by these factors.)
In SN, paste your FortiWeb's serial number, then click Next.
You can find the serial number on the System Information widget of your dashboard when you
log in to FortiWeb.
FortiAnalyzer should initialize the database and tables required to store logs from the version
of FortiWeb that you indicated (different firmware versions may use different database
schemas), and successfully add FortiWeb to its list of devices that are allowed to send and
store logs. Click Next, then Finish.

© FORTINET
Note: If this fails, verify that you have created a new ADOM for FortiWeb
(FortiWebADOM). Also verify that you are adding the new device to that new ADOM --
not root. Initializing the database tables for FortiWeb will fail if you use the default root
ADOM that is designed for FortiGate.
When finished, FortiWeb's entry should appear in the device list, but its icon will be red instead of
green. This is normal. It's because unlike with FortiGate, FortiAnalyzer does not make an initial
OFTP connection to FortiWeb, and FortiWeb hasn't sent any logs to FortiAnalyzer yet. To do that,
you must configure FortiWeb to send the logs that you want to store to FortiAnalyzer's IP address.

© FORTINET
3 Configure FortiWeb to Send Logs to FortiAnalyzer
1. On the Windows computer, open a new window or browser tab. Go to the URL for FortiWeb's
GUI:
2. Define the FortiAnalyzer's IP address, which will be used as the destination in syslog packets from
FortiWeb.
Go to Log & Report > Log Policy > FortiAnalyzer Policy and create a new entry named
FortiAnalyzer1 with the IP address 10.0.1.210.
3. Group it with other servers that will be used to notify administrators when a matching log occurs.
(Currently this is none, but for serious indicators of persistent attacks, you could also choose for
FortiWeb to also send an email to the administrator.) Go to Log & Report > Log Policy > Trigger
Policy and create a new entry named notification-servers1, and select FortiAnalyzer1.
4. Choose the destination for logs about high CPU and RAM usage. Go to Log & Report >
Log Config > Other Settings. In the System Alert Thresholds area at the bottom of the page, from
Trigger Policy, select notification-servers1. Click Apply.
5. Choose the destination for other event and traffic logs. Go to Log & Report > Log Config > Global
Log Settings. Enable logging to FortiAnalyzer and select FortiAnalyzer1. Click Apply.
Note: This is enough to send traffic and event logs to FortiAnalyzer, but not attack logs.
You will individually configure the destination of attack logs in each rule/signature.
6. To verify that FortiWeb is transmitting event and traffic logs, log out and then log in again. This
should trigger FortiWeb to send a log about the login attempt to FortiAnalyzer. Also go to the
virtual server's address:
Then on FortiAnalyzer, go to:
 FortiView > Log View > Event (the Log View submenu is initially in the bottom left corner)
 FortiView > Log View > Traffic
You should now see both:
 your login and logout
 your request to the virtual server, and the back-end server's reply. (If FortiWeb had blocked
the request, or if the back-end server had not replied, you would see the request only -- no
reply. FortiWeb records policy violations in its attack log instead.)
Note: Attack logs are not specifically verified here. They will appear on FortiAnalyzer
under FortiView > Log View > Intrusion Prevention. These are configured in later labs.
However, like event and traffic logs, attack logs use the same UDP port 514 syslog
transport.
As a result, you would notice that FortiWeb sends the log, but not associated packet
payloads (if any). Packet payloads currently can only be stored on FortiWeb's own hard
disk.

© FORTINET
4 Generate Customized FortiWeb Reports on
FortiAnalyzer
1. On the Windows computer, open a browser. Go to the URL for FortiAnalyzer's GUI:
2. Verify that FortiAnalyzer has correctly parsed and stored logs in its database, and that queries
return non-empty datasets for reports.
Go to Reports > Advanced > Dataset. Open one of the predefined SQL queries that FortiAnalyzer
uses to define datasets for reports, such as fwb-event-Top-login-by-user. In the query testing pane
on the right, select your FortiWeb device, set Time Period to Today, then click Test.
Note: Notice that the default query does not filter out configuration changes, so despite its
name, the query actually produces a full audit trail.
If you want to include only login/logout events, copy the SQL query and create a custom
dataset, then add it to your report layout.
Complex queries where FortiAnalyzer must filter the results and join tables can take more time,
but with a simple query and only a few logs in the database, you should see results in a few
seconds.
3. Clone that dataset and name it FortiWeb-Administrator-Audit. Modify the SQL query to omit
entries where the log field was "user=daemon" or "user=ntp_daemon":
select ùseràs f_user, msg, count(*) as totalnum from $log where

$filter and ùser` is not null and ùser` != 'daemon' and ùser` !=
'ntp_daemon' and msg is not null group by f_user, msg order by
totalnum desc
4. Go to Reports > Reports > Chart Library and clone the chart named Top Event Login by User.
Modify it so that it uses your modified SQL query.
5. Clone and modify the default report template so that it will use your new chart to create a simple
audit of administrator activities.
Go to Reports > Reports > Default Templates. Click Clone and enter the name FortiWeb
Administrator Audit. In the Configuration tab, set Time Period to Today and select your FortiWeb
device. Then go to the Layout tab and click the X on each chart to remove all queries except
for:
 Top Event Categories
 Top Login Events by User
Click the Save icon in the top left corner. (Due to time constraints, we won't assemble custom
charts here, but this is where you would reference them.)
6. Generate the report.
In the View Report tab, click Run Report Now. After a few seconds, FortiAnalyzer should
display the new entry. Click either the HTML or PDF link to view the report.

© FORTINET
If your report appears empty, logs may not match the time period of filter criteria. Try adjusting
Time Period to Last 7 Days, for example, or including all devices in the ADOM.
7. Download the report. Compare it to a report from FortiWeb's built-in report engine. When would it
be an advantage to use the built-in report engine, instead of FortiAnalyzer? When would it be
useful to use FortiAnalyzer's report engine instead of FortiWeb's?

DO NOT REPRINT  3 Integrating Front-End FortiGate Source NAT Objectives
© FORTINET
3 Integrating Front-End FortiGate
Source NAT
Objectives
 Configure FortiGate to forward HTTP traffic to FortiWeb's virtual server, preserving the original
client's IP address by embedding it in the HTTP header "X-Forwarded-For:"
 Configure FortiWeb to read X headers to derive the original client's IP address
Time to Complete

DO NOT REPRINT  3 Integrating Front-End FortiGate Source NAT Time to Complete
© FORTINET
1 Configure FortiGate Source NAT and Transmission of
'X-Forwarded-For:'
1. On the Windows computer, open a web browser. Go to the URL for FortiGate's GUI:
3. Go to System > Config > Features. Verify that Load Balancing is turned on, then click Apply. (It is
required so that the virtual server features will appear in FortiGate's GUI. Otherwise, virtual
servers will be hidden.)
If your FortiGate VM does not accept this change, it may be in conserve mode. Disable all unused
features such as IPS and antivirus, and/or ask your instructor to increase the vRAM allocated to
FortiGate VM. (The minimum default is not enough for all features to be enabled simultaneously.)
4. Go to Policy & Objects > Load Balancing > Virtual Servers. Use these settings
Name vserver-to-FortiWeb
Type HTTP
Interface port3
Virtual Server IP 10.0.1.253
Virtual Server Port 80
HTTP Multiplexing Preserve Client IP
Do not enable multiplexing of multiple HTTP requests over the same TCP connection; its
purpose is to improve performance with back-end servers by eliminating repetitive TCP
handshakes for small HTTP requests, but in this case, it can sometimes conflict with FortiWeb's
blocking, which can reset the TCP connection. This can result in blocking innocent requests.
Preserve Client IP is crucial. This is what transmits the original client's IP in an X-header at the
HTTP layer, so that FortiWeb can block based upon that, and not the FortiGate's egress interface
IP.
5. Define where the "real" server on FortiGate forwards packets: not to the back-end web servers,
but to FortiWeb's virtual server (10.0.1.8). Go to Policy & Objects > Load Balancing >
Real Servers and add these settings:
Virtual Server vserver-to-FortiWeb
IP Address 10.0.1.8
Port 80
Mode Active

© FORTINET
Note: Normally, you should set this higher, to a number appropriate for your FortiWeb
model's specifications. For this lab, however, 100 is enough.
6. Go to Policy & Objects > Monitor > Load Balance Monitor. You should see your mapping between
FortiGate's virtual server and your real server definition (which points to the virtual server on
FortiWeb).
7. To apply the load balancer, add a policy that accepts all connections to the virtual server on port1,
then applies source NAT. Packets egress towards FortiWeb's virtual server. Go to Policy &
Objects > Policy > IPv4 and add these settings:
Incoming Interface port3
Source Address all
Outgoing Interface port3
Destination
vserver-to-FortiWeb
Address
Service HTTP
HTTPS
Action ACCEPT
NAT off
Log Allowed
On
Traffic
Enable this policy On
Note: In the lab, however, all VMs are on the same subnet. That way you can access all
of them directly.
In a production network, however, NAT is often enabled as an additional security measure
that protects all servers behind FortiGate.
8. Go to http://10.0.1.253/. Through this virtual server on FortiGate, which links through the virtual
server on FortiWeb, you should be able to see the web pages of one of the back-end servers.
Traffic is passing from your browser to FortiGate, on to FortiWeb, and finally to the web
servers.
9. View FortiWeb's traffic and attack log. What is the recorded source IP address of the attacker?
Now, FortiWeb will log server information disclosure and attack attempts with the source as
10.0.1.254: the FortiGate's port3 physical interface IP, not your browser. Packets egress
through port3 when forwarded to FortiWeb. While correct from the IP layer perspective, the

© FORTINET
attack log currently does not reveal the IP address of the original client: your web browser. Also, in
a real network, FortiWeb would block connections from your FortiGate's IP whenever FortiWeb
detects an attack, affecting innocent clients.
To fix this, you must configure both devices to use X-headers to communicate about the original
client's IP.

© FORTINET
2 Configure FortiWeb to Use X-Headers
This assumes that you have already enabled FortiWeb's traffic logs and attack logs.
3. Indicate which HTTP X-header that FortiWeb will use when blocking a traffic source. To prevent
abuse, trust that header only when it comes from FortiGate.
Go to Server Objects > X-Forwarded-For > X-Forwarded-For and configure these settings:
Name x-headers1
Use X-Header to
Identify Original enabled
Client's IP
Block Using
enabled
Original Client's IP
Trusted IP 10.0.1.254
4. Define a group of some predefined signatures so that you can test the effect of X-headers by
simulating an attack.
Go to Web Protection > Known Attacks > Signatures and add a signature set.
Name signatures1
SQL Injection Action is Period Block for 60 seconds

Label as High severity
Trigger Action is notification-servers1
Generic Attacks Action is Period Block for 60 seconds

Disable RFI Injection
5. Apply the X-header rules by selecting it in a protection profile that is used by the policy. Also
select the new group of signatures.
Go to Policy > Web Protection Profile > Inline Protection Profile and create a profile named
protection1.
Name protection1
Session enabled

© FORTINET
Management
X-Forwarded-For x-headers1
Cookie Poison Action is Period Block for 60 seconds

Signatures signatures1
Go to Policy > Server Policy > Server Policy. Edit policy1 and set Web Protection Profile to
protection1.
For most features, FortiWeb now should block the attacker's specific IP address, not FortiGate's
physical interface IP.
6. Simulate an attack by going to these URLs, each in a separate tab:
http://10.0.1.253/../../../cmd.exe
http://10.0.1.253/index?q=select%20*%20from%20USERS;
Then quickly open the normal URL http://10.0.1.253/ .
 The innocent request should be blocked. Why?
 If you used another computer to access http://10.0.1.253/, would it work? Why or why not?
7. Go to Log & Report > Monitor > Blocked IPs. Also view the attack logs on either FortiWeb's GUI or
on FortiAnalyzer. Compare the source IP address in the logs.
 Which log contains the IP address of the attack's origin (your web browser)?
 Which log would you use to troubleshoot connectivity between devices in your data center?

DO NOT REPRINT  4 Mitigating DoS Attacks Objectives
© FORTINET
4 Mitigating DoS Attacks
Objectives
 Test a web site for vulnerability to a non-volumetric type of DoS
 Configure FortiWeb to detect a non-volumetric denial of service (DoS) attack
 Remove an IP address from the temporary blacklist
Time to Complete

DO NOT REPRINT  4 Mitigating DoS Attacks Time to Complete
© FORTINET
1 Test for Slow Headers DoS Vulnerability
1. On your Windows computer, open SwitchBlade. (Its executable is named gui.exe.)

2. Select Slow Headers as the attack type, the URL http://10.0.1.21/ , and 1,005 connections. Keep
the default connection rate and timeout, so that the attack does not generate an obvious traffic
spike. Click Run Attack.
After about 500 connections, you should notice that errors are occurring. This means that the DoS
is succeeding: connections are being rejected.
A few seconds after the simulation is complete, SwitchBlade will display the maximum number of
simultaneous connections that the web site sustained. How many simultaneous connections were
supported?
3. Run the attack again, but this time target the virtual server on FortiWeb, http://10.0.1.8/ .
Does the attack succeed?
Notice that FortiWeb is not rejecting or period blocking the attack source IP, however. Ideally, to
save resources, FortiWeb should be configured to efficiently block this kind of malicious behavior:
the same client IP is opening an abnormally high number of TCP connections, even though the
rate of HTTP requests per second is not necessarily suspicious.

DO NOT REPRINT  4 Mitigating DoS Attacks Time to Complete
© FORTINET
2 Configure FortiWeb to Protect Against TCP Floods
3. Enable FortiWeb to distinguish clients behind the same public IP, such as an office or café. Go to
System > Config > Advanced and enable Shared IP.
4. Define a sensor that detects an excessive number of TCP connections per IP (which we tried
before with SwitchBlade). Go to DoS Protection > Network > TCP Flood Prevention and add these
settings:
Name excessive-connections1
TCP Connection
10
Number Limit
Action Period Block
5. Group the sensor in a DoS policy named dos-sensors1.

Go to DoS Protection > DoS Protection Policy > DoS Protection Policy and add a group named
dos-sensors1.
6. Edit protection1 to include your new DoS sensor.
7. Go to http://10.0.1.8/ and verify that the web page still loads completely, and no images or other
page components have been blocked.
8. Open SwitchBlade and run an attack with 1,000 connections on http://10.0.1.8.
You should see that FortiWeb accepts connections at first, but once SwitchBlade exceeds 10
concurrent TCP connections, FortiWeb blocks all after that for the next 60 seconds, and eventually
terminates remaining open connections.

DO NOT REPRINT  5 Signatures & Auto-Learning Objectives
© FORTINET
5 Signatures & Auto-Learning
Objectives
 Configure auto-learning to observe your web applications' traffic and anticipate security needs
 Configure a signature set to protect against an observed vulnerability
 Test your protection
Time to Complete

DO NOT REPRINT  5 Signatures & Auto-Learning Time to Complete
© FORTINET
1 Enable Auto-Learning
3. Although you enabled auto-learning when initially configuring the policy, since you selected the
protection1 profile, FortiWeb has been blocking attacks.
Go to Policy > Server Policy > Server Policy and enable Monitor Mode. This ensures that
FortiWeb does not block traffic, so that it can learn about the entire transaction. (Otherwise, for
example, it wouldn't see the server's response, and would not be able to know if it should suggest
blocking server information disclosure or an input that is vulnerable to XSS, for example.)
4. Edit signatures1 so that Information Disclosure is disabled.
(You can skip this step. Auto-learning will still function. However, since the web pages have
information leaks, most "attacks" will be of the information disclosure type, so it will be more
difficult to see the other attack types in the graphs. Also, in production networks, instead of
configuring FortiWeb to block information disclosure, for optimal performance, you should correct
the configuration of the web servers instead.)

© FORTINET
2 Simulate Attacks
1. Log in to DVWA (http://10.0.1.8/dvwa/login.php) with the name "admin" and password "password".
Go to DVWA Security, and change the security level to low.
2. Visit some URLs to simulate both normal web site usage and attacks:
http://10.0.1.8/wp-login.php?q=ping%2010.0.1.1
http://10.0.1.8/cmd.exe
http://10.0.1.8/../../cmd.exe
FortiWeb does not block these simulated attacks. Why?
3. In DVWA, go to the Command Execution page. Enter:
10.0.1.10;cd ../../;ls
If a file listing appears, then attackers could browse your file system and even edit files, according
to the permissions of the account that the web server is using.
4. Go to the SQL Injection page. Enter this SQL statement, which if the web application does not
reject, could be passed to the database and used to show its contents:
SELECT * FROM mysql.user;

5. Click the User Agent Switcher button. Configure Firefox to self-report as the Google search index
bot, then click several links on the web site.
6. After a few minutes, go to Auto Learn > Auto Learn Report.
You should be able to view the report and generate a protection profile based upon the
recommendations, which we will do in the next .

© FORTINET
3 Generate a Protection Profile
1. Go to Auto Learn > Auto Learn Report.

2. Select a report, and click View.
In this very short period, how many of the page requests did FortiWeb perceive as normal, and
how many were estimated to be attacks? How accurate is auto-learning so far? How many
samples do you think it would require for FortiWeb to make an accurate guess at correct input
constraints?
Normally, you would wait at least a week or so during normal traffic so that auto-learning could
observe normal traffic behavior: both weekday traffic and weekend/holiday traffic. After that, you
would generate the profile, adjusting settings as necessary.
After upgrading a web application, you might run another auto-learning period to adjust your
configuration. In this way, FortiWeb will not continue to use signatures to protect vulnerabilities
that are now patched. It will also detect new inputs that may require protection.
3. On the Attacks tab, for the types of attack attempts that auto-learning detected, change Action to
Period Block, set Type to Custom, and set Custom to On. Disable all other scans, including
Information Disclosure (if you left it enabled).
(For Information Disclosure, if your servers are emitting this type of information, once you have
detected it, initially set the Action to Erase, no Alert. Meanwhile, notify the web server's
administrator to disable this in their configuration. This conserves CPU and (if logging to RAM)
RAM on all future requests.)
Notice that in addition to observing attacks, FortiWeb has also learned about HTML forms,
cookies, and hidden inputs that the web application uses. With more sample data, FortiWeb
would be able to make an estimate about normal, expected numbers and text, and enforce correct
limits. Usually, however, an auto-learning period may take at least a week of observation, so for
now, disable the recommended protocol and input rules.
4. Also change the Action to Alert & Deny for the Cross-Site Scripting attack type.
5. Click Generate Config and enter the name prefix protection2.
6. Inspect the contents of the new protection profile.
Which settings did you specify manually?
Which settings did auto-learning generate automatically?
If FortiWeb had many policies, and was learning about the possible attacks and typical valid inputs
of each web app in each policy, how much RAM would it need to keep auto-learning data? What
strategies could you use to reduce the RAM usage during an auto-learning phase?
7. Change policy1 to use the new protection profile. Deselect the auto-learning profile.
Disable Monitor Mode.
8. Go to the XSS Reflected page in DVWA and submit a JavaScript as an input, such as this
harmless proof of concept:
<script>alert('You\'ve been hacked');</script>

(If you can't log in, make sure that RFI Injection is disabled in the signature set generated by
auto-learning for protection2.)

© FORTINET
If a JavaScript alert appears, the attack succeeded. Verify your FortiWeb's included signatures so
that cross-site scripting is blocked. Also verify that the signature action is Alert & Deny or Block
Period, and that the policy is no longer in monitor mode.
When your attack is successfully blocked, your browser should display a block message. Also
FortiWeb should have a corresponding attack log.

DO NOT REPRINT  6 SSL / TLS Objectives
© FORTINET
6 SSL / TLS
Objectives
 Upload a signed certificate and private key to FortiWeb
 Configure clients to trust the web site's certificate
 Configure FortiWeb to provide HTTPS service, instead of your back-end servers
 Disable weak cryptography
Time to Complete

DO NOT REPRINT  6 SSL / TLS Time to Complete
© FORTINET
1 Upload the Server's Certificate & Key to FortiWeb
1. On the Windows computer, open FileZilla and connect to 10.0.1.21 by SFTP/SSH on port 22.
Enter the name "bitnami" and the password "bitnami". Download the server's HTTPS certificate
and private key:
/opt/bitnami/apache2/conf/server.crt
/opt/bitnami/apache2/conf/server.key
/opt/bitnami/apache2/conf/privkey.pem
2. Open each file in Notepad. What is the difference between their contents? Which ones contain the
private key?
3. Go to the URL for FortiWeb's GUI:
4. Upload the server's certificate and private key to FortiWeb, which will offer HTTPS (performing the
certificate and cryptographic operations) to clients for all back-end web servers.
Go to System > Certificates > Local and click Import, then set Type to Certificate. Upload the .crt
and .key files.
5. View the certificate details. Look at the Issuer field. Is it a self-signed certificate, or CA-signed
certificate? Do you think it will generate browser warnings?
6. Look for your private key in FortiWeb backups.
You can download a backup via the GUI in System > Maintenance > Backup & Restore. Try it
both with Encrypted disabled and enabled. Open it in a plain text editor such as Notepad++.
Is the private key in the backup? (Hint: How big is the size of the key and certificate, and how
much bigger is the current backup file from the solution for the previous lab? Is there any part of
the configuration that is now binary instead of CLI commands in ASCII text?)
Go to System > Maintenance > Backup & Restore and try the SFTP backup. Upload the backup
file to your home directory on 10.0.1.21, then use FileZilla to download the backups to your
computer. Examine the differences between backup files using Notepad++.
Which backups, if any, must be password-encrypted, and stored securely to properly safeguard
your private keys?

DO NOT REPRINT  6 SSL / TLS Time to Complete
© FORTINET
2 Offload HTTPS to FortiWeb
1. Edit policy1 to provide HTTPS service.

Specify that FortiWeb should present the certificate named "server" whenever a client requests an
HTTPS connection.
Open the advanced SSL settings. Disable SSL 3.0, which is a violation of PCI DSS. Also set
SSL/TLS Encryption Level to High.
2. Go to the HTTPS URL for the virtual server:
A certificate warning should appear. What does it indicate?
Hint: View the certificate.
How should you solve the problem?
When generating a CSR from FortiWeb's GUI, it uses SHA-1. What authentication algorithms
does this server certificate's fingerprint use?
3. Go to the HTTPS URL for the domain:
https://www.example.com/
Why is the page only partially encrypted? Which 2 FortiWeb features could you use to solve this
problem?
4. Temporarily accept the certificate -- do not permanently store the exception.
5. In the search field, try a SQL injection attack again, such as:
SELECT * FROM mysql.user;

Does FortiWeb successfully scan the HTTPS request and block the SQL injection, even though
the connection is encrypted? How can you verify this? (Verify that your policy is using protection2,
and that the Monitor Mode option is disabled.)
6. Go to https://10.0.1.7/ (HTTPS access to FortiWeb's GUI). Compare the icon in the URL bar with
https://10.0.1.8/ . Can you find which version of SSL/TLS your browser is using to view the web
pages?
Hint: Both your browser and FortiWeb's logs may have this information.

DO NOT REPRINT  7 Authentication & Access Control Objectives
© FORTINET
7 Authentication & Access Control
Before you provide a login form to users, it's a good best practice to:
 Limit access to plausible source IPs, URLs, rates, etc.
 Apply SSL/TLS to encrypt the channel when user names and passwords are transmitted
In this lab, we will begin by limiting access to the web site, and blocking excessive requests. On
Internet web sites, excessive request rates could indicate brute force attempts on the passwords, or
content scrapers. We will also apply HTTP authentication for al web apps on the domain.
Objectives
 Apply per-IP access control with a rate limit to URLs on the back-end web servers
Time to Complete

DO NOT REPRINT  7 Authentication & Access Control Time to Complete
© FORTINET
1 Sophisticated Access Control
3. Go to Web Protection > Advanced Protection > Custom Rule and create a new rule.
Name combo-access-control-rule1
Action Alert & Deny
Click OK, then click Create New to add a match condition for the rule. Add these two conditions.
Filter Type Access Rate Limit
HTTP Request
2
Limit/sec
Filter Type Source IPv4/IPv6
Source IPv4/IPv6 10.0.1.10
Notice that in the filter types, you can create very complex requirements in order to restrict access
to very specific clients and conditions. If your web application (such as Microsoft OWA or
SharePoint) already provides its own authentication, for example, access controls can help to
protect that HTML form from a brute force attack and from unauthorized IP addresses.
4. Go to Web Protection > Advanced Protection > Custom Policy and group the rule into a policy that
you can use to apply multiple rules at the same time.
Name combo-access-policy1
Rule combo-access-control-rule1
5. Go to Policy > Web Protection Profile > Inline Protection Profile. Edit the profile named
protection1. Disable the DoS protection policy and select the new rule:
Name protection1
Session
enabled
Management
X-Forwarded-For x-headers1
Cookie Poison enabled; Period Block; 60 seconds; High severity; Trigger policy is
notification-servers1

© FORTINET
Signatures signatures1
Custom Rule combo-access-policy1
Notice that we've applied the x-headers1 rule here. Due to this, the rate limit would be applied
to the client's IP address, not FortiGate's.
6. Go to Policy > Server Policy > Server Policy. In policy1, change the protection profile to be
protection1.
7. Go to http://10.0.1.8/. The page does not appear the same. Why?
This time, because FortiWeb is limiting each client to 2 requests per second, and the web page
has more than 2 components (images, scripts, etc. are all separate from the web page and are
separate requests themselves), you should notice that FortiWeb blocked those requests.
On a real network, you would set the rate limit to a small multiple of the number of requests
required per page. This normally is much higher, such as 50, but depends on the web page.
8. In Firefox, in the corner on the upper right side, click the button with 3 horizontal bars (the
preferences menu). Go to Developer > Network. A tools panel will appear below the web page. On
it, click the Reload button. Look in the lower right corner of the window.
How many requests are required for the web browser to download all parts of the page?
9. Return to combo-access-control-rule1. Increase the allowed request rate to the normal number
of requests per page, so that it will not interfere with later labs.

© FORTINET
10. To verify that your increased rate limit settings work, refresh the page.
The web page should appear normal again, due to loading the external style sheet (CSS) file and
images.

© FORTINET
2 HTTP Authentication
3. Define which domain names will match the authentication rule.
Go to Server Objects > Protected Hostnames > Protected Hostnames and create a new set of
host names. (If this server hosted web sites for many domains, including subdomains such as
store.example.com, we could add all domain names here.)
Name hostnames1
Default Action Deny
Host www.example.com
Action Allow
Host 10.0.1.8
Action Allow
4. Define which user accounts can log in to the web site.

Go to User > Local User > Local User and create a new account. (For larger audiences, you would
usually define an LDAP or RADIUS query to a remote authentication server instead.)
Name user1
User Name juser
Password test
Group the account in a user group. Go to User > User Group > User Group and define queries.
Name user-query1
Auth Type Basic
User Type Local
Name user1
5. Define which user accounts are authorized to access a specific URL, and which authorization
“realm" the URL belongs to.
Go to Application Delivery > Authentication Policy > Authentication Rule and create a new rule.

© FORTINET
Name HTTP-auth-realm1
Host Status enabled
Host www.example.com
Auth Type Basic
User Group user-query1
User Realm Employees Only
Auth Path /
Group the new rule into an HTTP authentication policy (it can include many web sites with
common connection timeouts, session caches, and other identical settings). During the testing
phase, we want to see all authentication attempts -- not just failures -- so we'll also log successful
attempts, too. Go to Application Delivery > Authentication Policy > Authentication Policy.
Name HTTP-auth-settings1
Cache Timeout 15
Alert Type All
Auth Rule HTTP-auth-realm1
Note that this cache timeout is unrealistically small. This is so that you don't have to wait long
for the authentication session to expire, so that you can try it again with a slightly different URL or
user account. But in a real production network, you should set it as 300 seconds or higher. This
will allow users to read the web page and click the next link without FortiWeb prompting them to
re-authenticate.
6. Apply the new authentication and authorization settings.
Go to Policy > Web Protection Profile > Inline Protection Profile. Modify protection1 to set HTTP
Authentication to use HTTP-auth-settings1.
7. Test the new configuration.
Remember, due to the Cache Timeout setting and that, by default, browsers keep cookies until
you restart them, you need to wait 15 seconds and then restart your browser between each test.
 If you enter http://www.example.com/dvwa/, or http://www.example.com/feed/, does this
require authentication?
 If you enter the exact URL in the authentication rule (http://www.example.com/) next, does
FortiWeb ask you to authenticate?
 What about the secure URL, https://www.example.com/ ?
 What about the virtual server's IP address, http://10.0.1.8/ ?
 Which user name do you need to enter: user1 or juser?
 Where do failed user authentications appear: in the attack log, or the event log?

© FORTINET
How are logs about user logins different from those about administrator logins?
 If you have some individual sub-URLs which should not trigger authentication, how could you
adjust the authentication rules to do that?
 What 2 other authentication features can you use on FortiWeb to authenticate requests for
specific URLs?
8. Define a rule that indicates where FortiWeb will allow to begin browsing sessions, forcing them to
begin on the page where FortiWeb shows the authentication prompt.
Go to Web Protection > Access > Start Pages.
Name session-initiation-page1
Action Redirect
Severity Low
Trigger Policy notification-servers1
In the rule, define the valid session initiation pages for the domain name (www.example.com):
Host Status enabled
Host Name www.example.com
Type Simple
URL Pattern /
Default Yes
Host Status enabled
Type Simple
URL Pattern /dvwa/
Default No
Host Status enabled
Type Simple
URL Pattern /feed/

© FORTINET
Default No
9. Modify protection1 to select your new object named session-initiation-page1.

10. To force the browser to clear its authentication cache, either restart Firefox, or open another one
with its own cache, such as Google Chrome. FortiWeb should show an HTTP authentication
dialog in all URLs above. If it doesn't, check your event and attack logs for clues about what part
of the authentication configuration you need to correct.
11. Test the effects of the session initiation rules.
 If you enter http://www.example.com/category/uncategorized/, does FortiWeb redirect you to
another URL? If so, which one?
 What about a secure URL, https://www.example.com/ ?
 What about the virtual server's IP address, http://10.0.1.8/ ?
 Are you required to authenticate?
 After FortiWeb redirects you to the authentication page and you authenticate, can you visit
http://www.example.com/category/uncategorized/ now?

DO NOT REPRINT  8 Rewriting & Redirects Objectives
© FORTINET
8 Rewriting & Redirects
Objectives
 Redirect HTTP requests to secure HTTPS, and configure clients to use HTTPS-only access for
subsequent requests
 Know where to find rewriting examples in the documentation
Time to Complete

DO NOT REPRINT  8 Rewriting & Redirects Time to Complete
© FORTINET
1 Redirect HTTP to HTTPS
1. On the Windows computer, go to the URL for FortiWeb's GUI:

2. Create a rewriting rule that matches all host names and request URLS if the protocol is HTTP,
then rewrites the protocol part of the request location with "https://". Go to Application Delivery >
URL Rewriting Policy > URL Rewriting Rule.
Hint: If you are not familiar with back-references, capture groups, or how to use regular
expressions for traffic, click the "?" button while on that page. An example is in the online help /
Administration Guide. Look for "Example: HTTP-to-HTTPS Redirect."
3. Group the rewriting rule into a rewriting policy (you can use multiple rules to rewrite different parts
of the same request), then select it in profile1.
When you go to the web site:
FortiWeb should now redirect your browser to the secure channel:
https://www.example.com/
4. To configure the browser to always use HTTPS when connecting to this site in the future, edit
policy1 to enable Add HSTS Header. (It's in the advanced SSL features section.)
5. Go to https://www.example.com/ to receive a reply with the HSTS header.
6. Visit http://www.example.com/ again. Your browser should automatically change your request to
HTTPS, without using the redirect. (If it doesn't, verify that policy1 uses profile1, which uses your
rewriting rules.)
In some cases, a client may still not use HTTPS, and therefore you must keep the redirect. Why?
Can HSTS completely prevent man-in-the-middle attacks? Why or why not?

DO NOT REPRINT  9 Troubleshooting Objectives
© FORTINET
9 Troubleshooting
Objectives
 Determine normal network and hard disk usage
 Locate a signature that is causing false positives, blocking normal traffic
Time to Complete

DO NOT REPRINT  9 Troubleshooting Time to Complete
© FORTINET
1 Determine Baselines & Normal Resource Usage
1. On the Windows computer, go to the URL for FortiWeb's GUI:

2. Go to System > Status > Status. What is the maximum number of hits in the last 5 hours? What is
the average?
3. Enter the CLI commands:
get system performance
diag sys top delay 5

How much of the CPU and RAM is used by buffers and cache, and how much is free, while
FortiWeb is idle?
What are typically the topmost intensive processes?
4. Open SwitchBlade and run a slow POST attack with 5,000 connections.
Now how is the resource usage? Which are the top most intensive processes?
When SwitchBlade finishes, how many were the highest number of concurrent connections that
your FortiWeb handled? What strategies could you use to reduce unnecessary RAM and CPU
usage?
Press Ctrl + C to stop the "top" command.
5. Enter the CLI command:
diag hardware logdisk info

6. How many disks does FortiWeb have? Are they in a RAID array? How big is the capacity?
7. Enter the CLI commands:
diag hardware harddisk list
diag sys mount list

How many disks are listed? Which disk does FortiWeb use to store uploaded certificates and
private keys? How can you determine this?

DO NOT REPRINT  9 Troubleshooting Time to Complete
© FORTINET
2 Fix the False Positives
1. Upload the configuration file that is the basis for this lab:
fortiweb-troubleshooting.conf
2. Go to the blog and click a few links:
3. Look at the attack log. What is the most common "attack" detected? How would you solve it on the
web server itself?
____________________________________________________
4. Disable that signature category in the protection profile.
5. Go to the virtual server's URL:
6. In the search box, type "wombats" and press Return.
FortiWeb should reset the page. Log in to the GUI and go to the attack log to find which signature
triggered the block action. Click the entry, then in the panel on the right side, click Add Exception.
7. Try your search again. Does FortiWeb block the web page?
8. Scroll to the bottom of the page. Log in with the name "user" and password "bitnami".
Again, log in to FortiWeb and add an exception for the mistaken attack detection.
9. Try to log in again. Change the color scheme of the blog, then log out again.
Return to the attack log and refresh it. Are there any more false positives?

DO NOT REPRINT  Appendix A: Additional Resources
© FORTINET
Appendix A: Additional Resources
Training Services http://training.fortinet.com
Technical Documentation http://help.fortinet.com
Knowledge Base http://kb.fortinet.com
Forums https://forum.fortinet.com/
Customer Service & Support https://support.fortinet.com
FortiGuard Threat Research & Response http://www.fortiguard.com

DO NOT REPRINT  Appendix B: Presentation Slides
© FORTINET
Appendix B: Presentation Slides

DO NOT REPRINT  WAF Concepts
© FORTINET
In this lesson, we will show you the role FortiWeb plays in your network defense strategy.
HTTP is an application layer protocol with its own inherent risks, but the XHTML web applications
that it contains – your “Layer 8” – bring their own challenges also. HTTP-specific security appliances
that protect servers, called web application firewalls (WAF), bring in-depth security for the most
popular protocol on the Internet.

© FORTINET
After completing this lesson, you should have these practical skills that you can use. You’ll be able to
connect to a FortiWeb that’s fresh out of the box, choose the best operation mode for your needs,
and find detailed help if you need it.
We’ll talk about FortiWeb’s role in your network stack, show examples of HTTP attacks, and how
each role blocks attacks differently. Because FortiWeb is web-specific, you’ll want to embed it in your
network security “sandwich” at the right location. It’s crucial to understand its role: what it can do, and
what it doesn’t. This, too, varies by operation mode.
We’ll finish by connecting to FortiWeb for the first time, and setting the operation mode. Lab
exercises can help you to test and reinforce your skills.

© FORTINET
What is a web application firewall? Why do I need it? Doesn’t FortiGate and FortiClient scan HTTP?
It’s true. They do. But who and what do they scan for? FortiGate’s HTTP proxy and FortiClient are
more focused on protecting clients, not servers. For example, FortiGuard Web Filtering URL ratings
block requests based on the category of the server’s web pages. Antivirus prevents clients from
accidentally downloading spyware and worms. Neither protect an innocent server (which doesn’t
send requests – it receives them) from script kiddies or ransomware.
Protecting servers requires a different approach. They are subject to other kinds of attacks, as we’ll
see in a minute. For web servers that handle popular web sites, and for enterprise web applications
like IBM Lotus Notes or Microsoft SharePoint, it also requires high performance. Also… Unlike web
browsers, behind most modern web servers is a database…

© FORTINET
Databases are jackpots for black hat hackers. Once your database has been compromised – stolen
or injected with code – it can be used for extortion, political manipulation, industrial espionage,
seeding clients as zombies for DDoS attacks on other servers, sending spam, fraudulent purchases,
storing criminal files… The variations seem endless.
So it may sound obvious, but if you need high-grade security for your web servers, don’t forget the
real target. Consider a FortiDB, too. FortiWeb can only scan web traffic. So like FortiDB, FortiWeb
too should be behind a firewall such as FortiGate.

© FORTINET
As always, you can get better results from layered security. Not just in terms of defense coverage,
but speed.
Security doesn’t need to be your bottleneck. Together 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. This optimizes performance. Just like FortiGate, FortiWeb has ASIC
chips that can accelerate encryption and decryption.

© FORTINET
So which OSI layers of networking does FortiWeb inspect?
HTTP is obviously Layer 7 of the OSI model. But before a request arrives:
1. A cable is plugged in.
2. A link established.
3. An IP session started.
4. A TCP connection opened.
5. Possibly an SSL or TLS session negotiated.
6. Inside that HTTP body may be anything – a Flash binary, form data, or XML.
IP addresses and sessions exist at multiple layers. Sessions aren’t all the same: cookies from the
web app and proxies, SSL/TLS encryption tickets, and IP sessions are all different. Their persistence
matters – and all can still be exploited if not secured. Every time that a web server does not gracefully
handle the maximum sessions for each layer – by allowing a client to make many half-negotiated TLS
sessions, for example – a denial of service attack is possible.
So while FortiWeb mostly specializes in HTTP security, it obviously does some work in other
layers. Keep this in mind: it will be important again for the operation mode and DoS protection.

© FORTINET

© FORTINET
They are as complex as other areas of your network.
HTTP isn’t a new protocol. Sir Tim Berners-Lee invented it between 1989 and 1991. Since then, its
popularity has skyrocketed. There are now 3 HTTP protocol versions. Variants like ALPN and SPDY
also exist. Especially as multimedia pages and dynamically-generated pages with database back-
ends became commonplace, the attack surface both client-side and server-side has increased.
Financial, government, and purchasing systems are now linked. Complexity, pervasiveness, and
financial incentive for attack have increased. Between the ease of attacks, the scale of their effects,
and rewarding money, hacking web servers has become common worldwide. New vulnerabilities are
now disclosed daily.
That’s a lot of pressure.
What do these attacks look like?
Some, like the TCP SYN flood, exploit how HTTP always uses TCP underneath, as a transport
protocol. These aren’t specifically an HTTP attack, but they use HTTP’s underpinnings.
Others use principles similar to other software and protocols. For example, TCP stateful inspection
requires that connections follow the correct protocol logic, and will not permit data transmission
before the connection has been acknowledged. Similarly, for example, shopping cart and web app
authentication – inside an HTTP cookie header or the body, its “Layer 8” – require that customers
submit a payment card or password before submitting the web page that completes the purchase or
changes a profile.

© FORTINET
But other attacks are unique to HTTP. Here, we mention Slowloris – an HTTP variant of the socket
exhaustion attack, which uses HTTP methods such as “GET” or “POST.” We also mention the “Range:”
header. Unlike most HTTP headers, and unlike lower-level protocols, one request can have multiple
headers. There is no standard-specified limit. So if the HTTP server accepts too many “Range:”
headers, the HTTP parser could exhaust its memory. Also, while it’s not a good idea for the server to
accept out-of-order ranges that require the server to search the same file back and forth for a specific
byte range – it could consume system resources due to random disk access – again, it’s not a protocol
violation. And “POST” requests compliant with the RFC don’t necessarily have a maximum size,
meaning that the attack could last almost indefinitely.
Securely coded servers would gracefully handle their limit by replying with a 500 error code, but not all
servers or applications do. Like programmers of other software, web programmers often aren’t trained
in security. So if you have mission-critical web apps, you should add FortiWeb.

© FORTINET
Let’s show a specific example.
Assume that the client is a web browser. They’re watching a video. They skip forward, and the
browser uses GET and requests a byte range in the middle of the video file. Here is the web server’s
reply. The reply uses HTTP 1.1. It’s the most common version, and supports the “Range:” header.
According to the HTTP 1.1 specification, if the client does not use the GET method with a “Range:”
header, then the server should reply with an error code in the 400 or 500s. Here, the reply code to a
GET is 206. All is normal.
But what if it was not a person watching a video? What if the client was a script?
• Attacks could request non-sequential byte ranges. As the system jumps repeatedly from place to
place on the disk, this could cause premature hard disk failure.
• Attacks could use POST to overwrite ranges of the video, defacing the site.
• Since this is video, it’s transmitted using MIME encoding. MIME encoding allows binary to be
embedded by encoding the data as alphanumeric characters. Each data chunk is delimited by a
special string called a “MIME boundary,” so that when a computer is loading the data, it knows
where the data stops. The server’s HTTP parser is what takes the incoming data, and breaks it
apart, loading pieces into memory according to these MIME boundaries. So if the parser doesn’t
handle all MIME boundaries correctly, attacks could use different quotes around the MIME
boundary string. This is legal, but in an error, the parser would continue to load the rest of the
request as if the MIME boundary string hadn’t happened yet, until it runs out of memory. This
could waste system resources. But the worst scenario? The parser overwrites areas in the RAM to
give the attacker root privileges. That, is, a parser error could cause a buffer overflow.

© FORTINET
Buffers may be new to you if you’ve never programmed, so let’s give a quick idea of how this works.
What is a buffer? Just a piece of RAM containing data. Programs use buffers to temporarily load data
until the CPU’s work on the data is finished. Both web servers and your FortiWeb itself have buffers.
Two HTTP-specific examples are shown here:
1. A buffer that contains the HTTP “Host:” header, usually important for virtual hosts, and
2. A buffer that contains the HTTP body of a “POST” request, often a file upload or web app
parameters.
Once that part of the program finishes – sends the packet, for example, or writes the file to disk – the
buffer vanishes.
Note that “cache” usually does not mean the same thing. Cache is used multiple times. A cache may
be temporarily flushed to disk, then reloaded for use again. Cache keeps data that is used
repeatedly, and could be used for processing thousands of packets, until the data expires. It’s a
performance shortcut so that the system can save CPU and/or bandwidth: instead of repeatedly
processing or querying for the same thing, it just reuses the data kept in cache.

© FORTINET
Then, what is a “buffer overflow”? A buffer overflow is just what it sounds like: when too much
data is loaded into the RAM, and it overflows the space that the OS has allocated for it. Buffer
overflows have been common since the beginning of the C programming language in 1969. Many
string-related functions in the standard C library don’t check two critical things: that data being loaded
into a buffer will fit, and that it terminates with a null byte (which C requires strings to do).
The result? A bug. Every time a programmer makes a mistake, an overflow is possible.
This is FortiWeb’s purpose: to safeguard and harden your web apps.

© FORTINET
And most operating systems and web servers today, from Linux and Android to iPhones and Apache,
were built using C or C++.
Here’s a short clip from a C program. Look at the names of the functions. Do you see how they are
slightly different? The difference is very small: one letter!
Not all functions are “safe”. What happens if the programmer accidentally didn’t type the right name?
Use the “safe” one…?
Someone – it may be today, or it may be next week – will be selling that zero-day exploit on the black
market.

© FORTINET
Because the attacker can load as much of whatever he or she wants into your RAM. The parser – the
part of the program that loads input from a client – isn’t stopping the RAM from being overloaded, or
loaded with bad commands, like it should.

© FORTINET
A crash is your best case scenario. Here, the attacker attempts to access a location in RAM. It
could be to overwrite the privileges, getting root access. Luckily, the OS forbids it, and terminates the
thread. You may need to restart a service, or if it’s a core process, restart the server.
But if the overflow happens in the wrong place, and isn’t stopped… It could result in privilege
escalation, and in the ability to execute whatever code the attacker wants.
FortiWeb helps here. It scans requests from clients, and enforces correct types and limits –
before the attack reaches your web servers. This is after-market buffer hardening, protection from
many zero-day attacks. An on-the-fly patch.

© FORTINET
Since buffers are RAM, buffer overflows don’t survive if you shut down or reboot the server – unless
they are able to write code to a disk, somewhere where it will be executed again when the computer
reboots. If code is reloaded each time the server restarts, this is a classic virus.
How else can an attack persist? Not on the web server or attacker’s computer, but on a third
system: your clients’ session cookies, or when your web server opens a connection to your database
server. Then, every time a web browser requests that page, the attack is loaded again.

© FORTINET
In modern web applications, data is often stored in a database. When the server receives an HTTP
request from the client, it queries the database, then loads the results into a web page template, and
eventually delivers HTML to the client.
So if your web site is very popular, your database is a tempting target for virus writers. If they want to
infect or hijack as many of your clients as possible, your database is irresistible.
Unfortunately for the DBA, corrupted databases are very hard to clean up… and losing a day’s worth
of transactions isn’t an attractive option.

© FORTINET
Since mishandled C strings are well understood, maybe you could ask your vendor to do a code audit
for those unsafe C functions. But would that be enough?
• Apps often don’t enforce prerequisites, yet depend on them to work.

• Apps sometimes can’t handle very much data, but don’t enforce a limit.
• Apps sometimes don’t understand other data types, however don’t check for the required type,
either.
Unhandled errors can take many, many forms.

© FORTINET
Buffer overflows are just one – possibly the best-known – type of attack. It’s not even specific to
HTTP – non-networked software such as Microsoft Word is a popular target, too. RAM and socket
exhaustion aren’t web-specific either.
But some other attacks that FortiWeb blocks are.

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

© FORTINET
Here is a variant of Slowloris that uses the HTTP “POST” method.
Unfortunately, here, strict RFC compliance actually undermines the web server, because the RFC
defines no limits on the maximum size of data that a client can submit.
Many web servers will not create a log message until the HTTP transaction is complete, long after the
attack has begun… And unlike a TCP SYN flood, this attack forms a complete TCP connection, then
slowly sends protocol-correct data, nothing that is technically illegal. Additionally, it could create
seemingly valid “200 OK” logs, hiding the attack, as long as the URL and parameters are valid. If the
client is accessing from multiple public IPs, this attack is therefore very difficult to detect. Unless you
inspect the data that is actually submitted for suspicious behavior like duplicate posts, slowness, or
corrupt files, it seems like a rush of genuine traffic.
Would you be able to distinguish this from a rush of Reddit traffic or an Apple WWDC day?

© FORTINET
Now we’ve shown why the problem of web security is complex. Let’s look at some of FortiWeb’s
solutions.

© FORTINET
FortiWeb solutions vary by the type of attack. We’ll summarize a few here. Many combat the OWASP
top 10.
You may remember frequent Flash updates due to security issues. Less well publicized was Google’s
temporary switch to preferring RC4 for its HTTPS services, and this was specifically to protect its
servers from the BEAST attack popularized in 2011. Since then, RC4 vulnerabilities have also been
discovered, which makes this choice a complex one. CRIME 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.

© FORTINET
Remember the previous slide where cookies were used to store attacks that were initiated by a
different client? Once a cookie is on the client, even if it is originally harmless, a malicious client can
tamper with them. It’s trivial to do. Tools are readily available – there are even browser plugins, as we
show in our labs.
When next sending a request to the server, these cookies become a dangerous input for an HTTP
parser to accept. Cookie poisoning protection is FortiWeb’s feature against this.

© FORTINET
Credit card theft is a major security issue. It doesn’t always originate with an attack. Poorly coded
web applications may return credit card data as “hidden” inputs, not realizing that anyone can view
the HTML source code of a web page – or alter it.
FortiWeb can protect you from accidental disclosure. We’ll cover compliance issues like this in a
separate lesson.

© FORTINET
Uploading an executable isn’t even necessary for some attacks. As you can see here, if your web
server doesn’t reject input that contains commands to access the file system, its own normal system
software can be abused. This can be especially bad if your web server is running as “root” or
“Administrator”, instead of its own limited account. Imagine an unknown person with superuser
access to your “passwd” or “route –p add” commands.

© FORTINET
Here’s another SSL/TLS attack, in case you believed your bank’s HTTPS web site was automatically
very secure. Heartbleed was responsible for the Canadian Revenue Agency web site shutdown, tax
deadline extensions, and the full network security audit for Social Insurance Number compromises in
April 2014.
FortiWeb SSL offloading was not vulnerable to this attack, and could have prevented it.

© FORTINET
Some default installs of IIS and Apache are notorious for publishing their installation version
information in the default 404 pages and HTTP headers, making it trivial for attackers to find
unpatched servers.
FortiWeb can erase these server information disclosures on-the-fly, giving your system
administrators time to correct these misconfigurations.

© FORTINET
So now we’ve seen that attacks can use many strategies in HTTP. Those were only some of the
most common attacks. They won’t always show in normal web server logs, either. How can you tell
when you’re being attacked? And how can you block it?

© FORTINET
Now that you know several common attacks, how does FortiWeb stop them?
In most deployments, you’ll want to guarantee that zero bytes of the attack can reach your web
servers. In DoS attacks, this is especially important, since denial of services can start at the IP layer,
before a TCP connection is even fully formed.
Only inline topologies, which support reverse proxy or true transparent proxy mode, can block like
this.
To have the most features available, including non-security features such as redirects and
rewrites, choose reverse proxy mode. If you can’t modify your IP address scheme, true
transparent proxy mode is a good second best choice.

© FORTINET
Let’s see how attacks are blocked 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.

© FORTINET
That’s not your only option for blocking attacks, however.
If high performance and zero latency is more critical than absolute security, such as for streaming
media, you can choose to use a different operation mode, such as offline mode, or transparent
inspection mode.

© FORTINET
Let’s see how attacks are interrupted in offline mode.
FortiWeb is located on an arm, where its link is 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
an attack is detected, it sends a TCP reset signal – the only thing it can do in this mode – in order to
try to force the server to discard the incomplete connection data.
This is similar, by the way, to transparent inspection. In that mode, FortiWeb is placed in between
servers and the client, instead of on an arm, but it still must race against the clock. It’s crucial to
understand that if that TCP reset packet loses that race, your incident response team must be ready
immediately. Simply because FortiWeb attempted to interrupt the attack does not mean that it will
always succeed. Keep tripwires and other forensic tools ready.
In contrast, with reverse proxy mode, blocking is reliable.

© FORTINET
The blocking method and attack protection varies by operation mode, but so does traffic forwarding
and SSL offloading or inspection. This table summarizes, but if you need a specific feature, always
check the documentation to make sure your required feature is supported.

© FORTINET
Because offline blocking is not guaranteed to succeed, it’s best used during the evaluation and
planning phase, early in implementation.
Reverse proxy is the most popular mode. It can rewrite URLs, offload TLS, load balance, and apply
NAT.
An important exception is for very large MSSP cases, where 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.

© FORTINET
If you’re familiar with 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 shown previously, or the CLI.
A tip if you’ll be using one of the transparent modes: Don’t configure FortiWeb network
settings yet. Changing the operation mode from reverse proxy to a transparent one, or vice versa,
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 modes, don’t place FortiWeb in your network immediately. Wait. Use a local
console or peer network connection to the GUI or CLI until after you’ve switched the operation mode.

© FORTINET
You may be wondering what tools to use with FortiWeb. FortiWeb has some tools on the appliance
itself, of course. Some tools such as packet capture, flow traces, and traffic logs are familiar from
FortiGate. But for now, let’s talk about external tools.
If you’re a hosting provider or data center, you will usually be load testing your servers and
applications to be able to plan and guarantee service levels. You can use some of these tools,
including Avalanche, to verify that you’ve got a FortiWeb model that is powerful enough for your
needs, plan for traffic growth, and also to simulate some types of denial-of-service attacks.
Vulnerability scanners can be useful to locate obvious, easy patches. But for real security and
penetration testing, simulate attacks. Use scripts and browser extensions that allow you to change
cookies, hidden inputs, and other HTTP data to mimic hacking attempts.
Be careful: when using these tools, NEVER use them over your ISP’s network, on a live production
server. Always use them in an isolated lab, with a copy of the database – NOT your live
database server. If you test an injection attack, and it succeeds, for example, you don’t want to
destroy live customer, student, or patients data!

© FORTINET
When you log in, many options appear. FortiWeb is full-featured and yet continues to evolve to meet
the pace of the HTTP threat landscape. Here are the main places you can get details to help you with
your implementation.

© FORTINET
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.

© FORTINET
To review, these are the topics that we just talked about.
We showed why and where to use FortiWeb – its key benefits and purpose. Because it’s not an FTP,
SSH, or SQL scanner, if your back-end web servers require that, you know which other security
measures to blend with FortiWeb.
We also discussed how several types of HTTP attacks work. Keep those in mind for other parts of
FortiWeb training, when we show you how to configure attack protection. Finally, because supported
features vary by operation mode, you also now know which operation mode to choose.
If you want expertise during implementation, both online help and professional services are just a
click away.

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

© FORTINET
After completing this lesson, you should have these practical skills that you can use to complete
basic FortiWeb setup, up to the point where traffic is flowing and you can begin to apply security
settings.
Lab exercises can help you to test and reinforce your skills.

© FORTINET
First, let’s look at physical and logical topology.

© FORTINET
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 a cloud, the logical topology has an important difference from a typical hardware model
deployment: your FortiWeb’s interface to the Internet may be DHCP, not a static IP.

© FORTINET
Regardless of whether you deploy real or virtual hardware, you need to know if source NAT is used.
If you have a transparent mode FortiGate in front, 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.

© FORTINET
There are 2 solutions you can use if you have upstream source NAT.
This is one solution:

1. Configure the upstream NAT device to put the original client’s IP in an HTTP header such as “X-
Forwarded-For:”. (The name can vary – some CDNs like Akamai use “X-True-IP:” or “X-
Real-IP:” – so if you’re not sure, run a packet capture, or use browser developer tools to
observe the HTTP transactions.)
2. Then, configure FortiWeb to find the IP in that HTTP header, not the IP header.
This works in many cases, including FortiGate. But not all NAT devices support it. And in FortiWeb
5.3.4, FortiWeb will ignore private IP addresses in X-headers, so this won’t work if you’re an
enterprise with users on your private network. What other solutions can you use?

© FORTINET
The easier solution is to put FortiWeb first, in front of the load balancer.
This has a good side effect, too: the load balancer only receives legitimate traffic, so it’s protected.
Also, its resources are used efficiently.
Remember, though, that load balancers also use the source IP sometimes: for session
persistence or client-based load balancing. If so, configure FortiWeb to transmit the original client’s IP
in “X-Forwarded-For:” in the HTTP header, and configure your load balancer to use that instead,
not the source address in the IP header.

© FORTINET
Here’s a diagram 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 is in NAT/route mode, and applying source NAT, the administrator enabled
load balancing and configured 2 virtual servers. They apply an X-header: 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 those would be using private
network IPs, many LANs could have clients using those same addresses – the addresses are not
globally unique. So a FortiWeb running 5.3.4 wouldn’t use the X-header for those.

© FORTINET
Once you’ve decided on a physical and logical topology, you’ll log in and begin to configure FortiWeb.
Where should you start?
It can help to understand which configuration objects are used by another.

© FORTINET
You’ll usually start with a “leaf node” object – a fine-grained setting, not the server policy.
Server policies bring other objects together, and apply those settings to matching traffic. But to do
that, 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
And other detailed settings. Then select them in DoS policies, server pools, and other intermediate
objects, before binding it all together in a server policy.

© FORTINET
In transparent inspection or true transparent proxy modes, most is similar. The biggest exception is
the virtual server: it doesn’t exist in those modes, because they don’t forward traffic by the IP layer.
Instead, they use an OSI Layer 2 bridge together with the IP-layer port number. This is called a V-
zone.
Some features aren’t supported, either.
This is due to inherent differences in how the operation modes work. For example, since transparent
inspection forwards traffic while inspection is being completed, it obviously can’t rewrite URLs in
packets that have already egressed. It can only interrupt connections once it detects that an attack is
in progress.

© FORTINET
In offline protection, most features are not supported. Its primary purpose is usage in the
preparation phase, with auto-learning to discover applicable signatures and input constraints. Its
other main difference is that it doesn’t pick up traffic to proxy or bridge – it accepts all traffic on a
“data capture port”, one of the network interfaces, and listens for attacks.

© FORTINET
Now that we’ve shown the basic idea of how objects link together, let’s start to configure FortiWeb.

© FORTINET
We’ve shown each of the objects and their functions. These are the simple setup steps.
In reverse proxy, once these steps are done, you’ll have traffic now flowing through FortiWeb, and be
ready to begin applying security.

© FORTINET
If administrators or users are centrally authenticated through an Active Directory or RADIUS server,
define the queries first.
If 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!

© FORTINET
Don’t forget to group the queries so that you can use them when creating new accounts.

© FORTINET
Also define administrators’ scopes and their 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.
All administrator accounts are not the same, even if you have assigned the same access
profile permissions.
What’s the difference? The ‘admin’ account is like ‘root’. Only ‘admin’ can reset others’ forgotten
passwords, for example. If you forget the password to that 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.

© FORTINET
Don’t allow multiple people to log in as ‘admin’. Separate administrator accounts. 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 3 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.

© FORTINET
When should you prohibit simultaneous administrator logins?
FortiWeb doesn’t lock the configuration when you view an object’s settings. So if multiple
administrators decide to edit that same object, their changes would be in a race: the last
person to save their changes would overwrite the other person’s configuration. 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. We’ll see more about ADOMs with external logging.

© FORTINET
Like usual, be sure to set your time zone.
For more accurate times, allow your FortiWeb to connect to an NTP server so that it can keep its
clock in sync.

© FORTINET
Most people can skip this step. Reverse proxy, the most popular mode, is the default.
But if you’re using another mode – such as starting in offline mode for auto-learning, before switching
to reverse proxy – do that in this step.

© FORTINET
If you switch to either transparent mode, FortiWeb’s network settings will be reset. So it’s best
to do this either from the command line, or before you configure your network settings and HA!

© FORTINET
If you switch to transparent mode via 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
operation modes.

© FORTINET
If you’ll use FortiWeb HA, configure it at this point. Like usual, you must have 2 exactly identical
FortiWeb models with the same firmware. Only active-passive HA is supported; active-active is
usually implemented externally, such as with a FortiADC load balancer.
Since the standby has no management IP, configure any device-specific settings first. This
includes the host name and HA priority. Then enable HA. That way, as you continue to configure
settings, the standby 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.

© FORTINET
HA on FortiWeb behaves similarly to 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) are now reachable via the standby’s links.
This causes switches to begin 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.

© FORTINET
If you’re using FortiWeb VM, there are a few VM-specific tips.
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 OSes, make sure that FortiWeb
VM has priority.

© FORTINET
Link two ports that HA will use to communicate – directly if possible – then configure HA before the
network interfaces: network settings will sync. So will other, subsequent settings.
FortiGuard Antivirus packages now sync between the peers, so you don’t have initial risk after the
failover period anymore.
Some data, such as logs and reports stored on the local hard drive, doesn’t sync. See the
documentation for details.

© FORTINET
If you don’t have 2 FortiWebs for HA, and you’re using transparent modes, you can still prevent
hardware failure from interrupting traffic. To do this, connect through port pairs and configure fail-
open to bypass.
However, your web sites will be totally unprotected until you replace the failed FortiWeb!

© FORTINET
Fail-open is available only in some hardware models. Those FortiWeb models have a type of ASIC
chip between each port pair. When you set these options, FortiWeb’s OS programs the chip to
behave as either a bypass or circuit interrupt when it loses power or reboots.
Alternatively, you can use FortiBridge.

© FORTINET
The next step is to configure network interfaces, and which administrative protocols are enabled on
each.
If you’re deploying in a cloud such as Amazon Web Services, use DHCP instead of the usual:
a static IP address.

© FORTINET
Like usual, you should specify at least one route, to the default gateway – where FortiWeb will send
traffic for routing 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 larger internal network, and your protected web servers are not on the same subnet,
you must add a route for those destinations, too.

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

© FORTINET
Once FortiWeb can reach the Internet, if it has a FortiGuard subscription package, it can download
updates.
For FortiWeb, FortiGuard provides an extensive amount of updatable components – much 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.

© FORTINET
The best practice is to enable FortiWeb to periodically check for FortiGuard update packages, and
automatically install them.
The antivirus databases are very similar to FortiGate and FortiMail, except that there is no “extreme”
database.
Notice the antivirus buffer size: this is one of FortiWeb’s many buffers. Is it big enough for
most uploads? Is it small enough so that antivirus scans won’t use too much RAM? By
default, FortiWeb will pass uploads that are too large to fit in the buffer. Usually, virus uploads are
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.

© FORTINET
Next, let’s establish connectivity through FortiWeb.
As mentioned previously, FortiWeb only scans HTTP. But FortiWeb can act as a router or
bridge for other protocols. Then, it will forward packets that are destined for your web servers’ IPs.
If you do this, use caution. An upstream firewall such as FortiGate should scan any FTP or SSH
connections to your web servers.

© FORTINET
This shows the basics of how FTP (by default, on port 21) would arrive at a virtual IP (VIP) on
FortiGate, which applies NAT, then routes packets towards FortiWeb.
Because it’s not HTTP, however, there is no proxy pickup. Instead, FortiWeb simply routes the
packet to its destination IP address.
So unlike HTTP, with FTP or SSH, the destination address must be the back-end servers – not
FortiWeb’s virtual server.

© FORTINET
If you’re using transparent mode, no configuration is required. FortiWeb will allow other protocols to
pass through.
But if you’re using FortiWeb in reverse proxy mode, then you must enable IP-based
forwarding (that is, 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.

© FORTINET
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?

© FORTINET
In transparent mode, shown here, FortiWeb forwards as a Layer 2 device. So by default, web
traffic passes through. If web traffic should be inspected, though, you must define where FortiWeb
should pick up traffic: which bridge and TCP port number.
This is a key difference with reverse proxy.
In comparison, reverse proxy 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 first 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. And as we showed, 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.

© FORTINET
This table shows some basics of how traffic flow, proxy pickup, blocking styles, and SSL termination
all vary by operation mode.

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

© FORTINET
After FortiWeb has picked up traffic, how do you define where it should send it?

© FORTINET
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:
• Simply 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 should be sent to the same previous 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.

© FORTINET
Load balancing on FortiWeb is like FortiGate, but adds 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 load is distributed by HTTP session cookie instead of the 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 upon the “Host:” name and/or URL. For example, FortiWeb can
send Microsoft SharePoint requests to a different server than Outlook Web App requests.

© FORTINET
After the initial load balancing decision, by default, each next 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.

© FORTINET
Like on FortiADC, you can define session persistence in several ways, using either the IP or
HTTP layer.
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 it doesn’t have one, however, FortiWeb can inject its own load balancing session cookie, and use it
to track the sessions.

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

© FORTINET
Finally, 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 also use host name definitions on
FortiWeb to route HTTP traffic.
Like other objects, configure host names before you configure the server policy.

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

© FORTINET
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.

© FORTINET
When all objects are ready, create a server policy. In it, select your objects.
You must select a protection profile in order to save the policy. But if you’re using reverse proxy
mode, initially, to test traffic flow, you can select an “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.

© FORTINET
We showed 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. If we’re
forwarding FTP, RDP, or SSH, we also talked about how FortiGate can use a virtual IP to forward it
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.

DO NOT REPRINT  Integrating External SIEM
© FORTINET
In this lesson, we’ll talk about special deployment considerations:

• When should you log to an external server or device?
• How can you support multi-tenant deployments?

© FORTINET
After completing this lesson, you should have these practical skills that you can use in deployments
that require intensive logging.
With large web sites and hosted environments, ADOMs, external logging, and reports are crucial. In
this lesson, we’ll show you how to configure a FortiAnalyzer solution.

© FORTINET
First, let’s talk about administrative domains. They can be useful to divide up workloads among
administrators.
Because everything from certificates to policies can be separated by ADOMs, they can be used for
multi-tenant deployments. Keep in mind, though, that ADOMs do not have virtualized
networking, and so although they may look and act mostly like FortiGate VDOMs, they are not
true virtual domains.

© FORTINET
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 also subdivide
access to logs and be used to filter 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’s device list.

© FORTINET
Enabling ADOMs is simple. You can do it from the dashboard in the System Information widget.

© FORTINET
When you enable ADOMs, there is a global scope for some settings that apply to the entire FortiWeb
– regardless of ADOM – such as the “admin” account and firmware updates.
But most settings will be specific to each ADOM, so you must create at least one ADOM that will
contain policies, certificates, and so forth.

© FORTINET
In most cases, you’ll start by creating one administrator account per ADOM. He or she 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
segregation of duties.
You can’t, however, assign an administrator to more than one ADOM.

© FORTINET
If you want to grant access to all ADOMs and global settings, select “prof_admin” as the access
profile when configuring the administrator account. Similar to the account named “admin,” this
account will be able to configure all ADOMs and global settings.
Best practice dictates that you usually should avoid unnecessary security holes, however. Do not
provide “prof_admin” access if possible. Instead, restrict each administrator to their relevant
domain. That way, they cannot accidentally or maliciously impact other ADOMs, and any damage or
mistakes will be limited in scope.

© FORTINET
If you have enabled ADOMs, this changes how you should query logs in order to build custom reports
on FortiAnalyzer or other SIEMs. Let’s take a look.

© FORTINET
Logging externally is a FortiWeb best practice. Why? FortiWeb can store logs locally on its hard disk,
or in RAM.
The reason is that logging externally has several benefits:

• Flexibility for reporting
• Better performance
• Better scalability
• Visibility for multi-device attack correlation

© FORTINET
Since you may already have a FortiAnalyzer, we’ll show you how to configure logging and custom
reports with it. But many of these concepts would apply to any other 3rd-party event logging and
reporting system.

© FORTINET
These are the basic steps to configure both devices to interoperate.
1. On FortiAnalyzer, enable administrative domains. To support FortiWeb ADOMs, also enable the
“Advanced ADOM” option.
2. 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.
3. Add FortiWeb to FortiAnalyzer’s device list so that it is allowed to store logs, and has an assigned
disk quota.
4. Optionally, configure centralized alert email and custom report queries.
5. 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.

© FORTINET
Let’s see the setup in action.
Here, we are enabling ADOMs on FortiAnalyzer.

© FORTINET
Next, we create a new ADOM. On FortiAnalyzer, these do more than just separate administrators
from each other’s data. Under the hood, choosing the ADOM also specifies the schema of a
new database, and indicates which schema its tables will use. Log schemas vary by Fortinet
device.

© FORTINET
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 logs’
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.
Here, we want the schema for FortiWeb 5.2 and later, so we select “5.2”, even though
FortiWeb is running 5.3.4.

© FORTINET
Next, we add our FortiWeb’s IP to the new database.

© FORTINET
Notice that 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 front-end FortiGate to the remote network’s FortiGate. Syslog is a clear-text protocol, and
FortiWeb logs contain sensitive network security information.

© FORTINET
Next indicate your FortiWeb model, version, and serial number. Device list control occurs by serial
number and IP.
Ignore settings such as DLP archive, quarantine, and IPS packet log. These require an OFTP
connection, which is not currently supported.

© FORTINET
Now FortiAnalyzer should initialize the database for this specific FortiWeb, preparing it to store log
data.

© FORTINET
When done, a success message should appear. Click “Finish”.

© FORTINET
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.

© FORTINET
Next, let’s look at how to configure logging – especially remote logging – on FortiWeb.

© FORTINET
First, define the IP address of a FortiAnalyzer. This is the destination where FortiWeb will send logs if
you’ve selected that destination, and they match the type, severity, and other criteria.

© FORTINET
Next, select your FortiAnalyzer definition in a “trigger policy”.
Notice that 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 will use with severe events.
Alternatively, you could configure your alert email in a central location, on FortiAnalyzer.

© FORTINET
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 3 months 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.

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

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

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

© FORTINET
Now we’re ready to test logging.

© FORTINET
These are 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 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 purpose-built to handle massive
numbers of transactions and analyze traffic anomalies with speed.

© FORTINET
When you log in to FortiAnalyzer again, you should notice a green icon in the “Logs” column when
viewing the device list. This indicates that FortiAnalyzer has recently received a log message from
FortiWeb, so connectivity was successful.

© FORTINET
If you configured event handling, you can use it to view logs. But you can also use the “Log View”
menu on the “FortiView” tab. To drill down and view the details of a log, just double-click its row.

© FORTINET
If you have many network devices, it’s often more convenient to configure alerts from one central
location – not on each device individually. You can do this on FortiAnalyzer.

© FORTINET
FortiAnalyzer also offers more granular ways than FortiWeb to define what will trigger an alert email.

© FORTINET
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.)

© FORTINET
You don’t have to receive one email for every incident. In continuous scripted attacks or distributed
denial of service attacks, this could result in a deluge of email. To avoid that, specify the alert interval.

© FORTINET
Unlike on FortiWeb, selecting the event’s “Severity” does not filter the logs.
Instead, use the “Generic Text Filter” field to specify a SQL filter.

© FORTINET
Indicating how severe the messages are on FortiAnalyzer simply allows you to color-code their
entries in the “Event Management” tab.

© FORTINET
If you double-click an alert event, you can view the log message’s fields, such as which host and URL
was attacked.

© FORTINET
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 “FortiView” tab instead.

© FORTINET
Once FortiAnalyzer is receiving and storing your FortiWeb’s logs, you can begin to generate reports.
Custom reports is a challenge for many FortiAnalyzer beginners, and FortiWeb’s queries are different
from FortiGate’s. We’ll show you the basics of how to make a report specifically for FortiWeb, and
how to customize the SQL query to show precisely what you want.

© FORTINET
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 them, you’ll eventually want to search logs, or make a report.
To do this, FortiAnalyzer runs SQL queries. 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.

© FORTINET
Let’s see 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.

© FORTINET
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 7 days’ worth of logs yet.

© FORTINET
On the report’s “Advanced Settings” tab, you can filter by all of the other log fields. Since we specified
the FortiWeb 5.2 and greater 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 exact, entire string in that log field. 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.

© FORTINET
Once you’ve defined the dataset, you need to define how the report will display it. You can do that on
the “Layout” tab.

© FORTINET
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, and
• Which row or column should be bound to each X- or Y-axis, for example.
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 them 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.

© FORTINET
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.

© FORTINET
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 FortiWeb’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 FortiWeb, and
verify that your FortiWeb 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.

© FORTINET
We showed how to enable FortiWeb ADOMs for multi-tenant deployments, or to implement

segregation of duties for multiple administrators.
We also showed how and why to log externally for better performance, network visibility, and
reporting flexibility. Integrating FortiWeb 5.3.4 with FortiAnalyzer 5.2.1 will allow you to generate
custom reports. Custom reports can be made by customizing the default datasets and charts, or by
using the database schema and a SQL language reference to write your own queries.

DO NOT REPRINT  Integrating Front-End SNAT & Load Balancers
© FORTINET
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?

© FORTINET
After completing this lesson, you should have these practical skills that you can use in larger
FortiWeb deployments.
With large web sites and hosted environments, load balancing is crucial. In this lesson, we’ll show
you how to configure a few solutions.
In large data centers, an application delivery controller (ADC) will specifically handle local load
balancing. Either BGP multi-homing or a global load balancer such as FortiDirector will handle
redundant data centers located around the world.
Also, a FortiGate should be in front of FortiWeb. Either FortiGate or FortiADC can balance load
instead of using FortiWeb’s built-in load balancer. Both must consider the effects of source NAT.

© FORTINET
FortiWeb has a built-in load balancer. Why and when should you use an external load balancer?
There are 2 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 front-end FortiGate routes but doesn’t apply NAT, or if it’s in
transparent mode, then this doesn’t apply.
If you have FortiADC in front of FortiWeb, the same factor applies. It can be deployed either in front,
or, more commonly, behind FortiWeb. We’ll show those 2 different deployments in a minute.

© FORTINET
Before, or after? Location matters. If you have a transparent external load balancer that is before
FortiWeb, you probably won’t need to configure anything special.
But if it applies source NAT, you must configure both load balancer and FortiWeb to read and apply
an HTTP-layer X-header (usually ‘X-Real-IP:’ or ‘X-Forwarded-For:’) so that FortiWeb blocks
clients based upon the request’s original source IP, not the current source IP (which is going to be
your load balancer).
FortiWeb X-headers now support IPv6, so if you require IPv6, this no longer a factor in where you
decide to deploy FortiWeb.
If your load balancer is after FortiWeb (not before), configuration of X-headers may be simpler, but
still important. Otherwise, your load balancer could send all sessions to 1 server – because at the IP
layer, it looks like your load balancer has only 1 client: your reverse proxy FortiWeb. So source IP-
based session persistence to the same back-end server therefore won’t distribute load correctly. The
load balancer should either forward based upon an HTTP-layer session cookie, or by deriving the
original client’s IP from the X-header.

© FORTINET

© FORTINET
Once your upstream or downstream NAT device is configured to read or send X-headers, configure
your FortiWeb to use them, too.
The red highlights show settings that you need if your load balancer is upstream.
If it’s downstream, the settings 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 trusted providers of this header.

© FORTINET
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.

© FORTINET
If the client is on the Internet and has a public IP address, notice that the attack logs will now show
the original client’s IP, not your FortiGate. This helps if you need to blacklist a repeat attacker’s
source IP, and need to know what their address is.
Note that in FortiWeb 5.3.4, if the client is on your private network and has an RFC 1918
address, then 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.

© FORTINET
But, 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 will still show your front-end load balancer’s
IP.

© FORTINET

© FORTINET
We configured FortiWeb to block the original client’s IP, not FortiGate’s interface IP.
To use this, first we must configure FortiGate’s HTTP proxy to add an “X-Forwarded-For:”
header with the original client’s IP. (Not to remove/ignore the header.)
Because FortiWeb needs policies for both inbound and outbound traffic, now is also a good time to
configure those.

© FORTINET
Where should we start?
IP addresses are referenced by each policy on FortiGate. So let’s 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-
Forwarded-For:” header. (If your FortiGate is in transparent mode, the destination for HTTP traffic
could be your FortiWeb instead. 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
• And 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.

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

© FORTINET
If your FortiGate is in NAT mode, it usually will be applying 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 is also rewriting 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:
• Many FortiWeb features such as IP reputation, which uses public IPs, won’t work.
• IP pools for the virtual server on FortiGate must be configured 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!

© FORTINET
Normally, FortiGate is used for SSL inspection. It decrypts a copy of a packet in order to scan it, but
doesn’t actually terminate the SSL session. Instead, it passes along the encrypted packet (if it doesn’t
violate the security policies).
With load balancing, however, 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.

© FORTINET
After configuring the virtual server on FortiGate, make the other half of 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.

© FORTINET
Don’t forget that if you’re doing SSL inspection – but not SSL offloading – then FortiWeb’s virtual
server should be listening for HTTPS on port 443, not clear text HTTP on port 80.

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

© FORTINET
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.

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

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

© FORTINET
Load balancers are usually 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. So let’s see that for
comparison with FortiGate.

© FORTINET
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 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.

© FORTINET
We explained 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.

DO NOT REPRINT  DoS & Defacement
© FORTINET
In this lesson, we’ll talk about why and how to mitigate denial of service attempts, and how to prevent
(and rapidly, automatically reverse) vandalism.

© FORTINET
After this lesson, you should have these practical skills that you can use to improve your network’s
resilience to denial of service attacks.
If an intrusion succeeds and you need to quickly reverse the attacker’s web site defacement, you will
be able to use FortiWeb to do that, too.

© FORTINET
Denial of service 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.

© FORTINET
So clearly DoS attacks are not harmless and cheap. And everyone from businesses to governments
are targets.
How can you stop them?
Denial of service 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.

© FORTINET
FortiWeb is not designed to defend DNS servers. But it is critical: don’t forget DNS when hardening
your defenses.
Without DNS, the Web effectively doesn’t work.
To illustrate the point, 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.

© FORTINET
To fight DoS attacks, first you need to know if it is really a DoS attack, or just a traffic spike.
What is your network’s normal behavior – including during periods such as holiday shopping
seasons? Do you normally have traffic from Brazil or Antarctica?

© FORTINET
Some types of DoS attempt 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.

© FORTINET
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.

© FORTINET
At the IP network layer, FortiWeb can protect you in multiple ways.
When you apply a “Period Block” action to a signature, that client’s source IP is ignored until the
penalty times out. But that’s not the only way that FortiWeb uses the client’s source IP.
One of the best protections 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.

© FORTINET
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 are 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.

© FORTINET
If you’re not completely blocking an IP, then the next logical protection is to protect your network from
rate anomalies.
Usually, it doesn’t work well to apply the same rate limit to everybody. 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 2 ways to distinguish shared Internet connections, and apply different rate
limits for them. This is one way: “Shared IP”.

© FORTINET
The “Shared IP” setting uses a small amount of RAM for each client to remember the sequence ID
number in the previous packet’s IP header. (If your web apps’ requests don’t have a session cookie,
this may be the only way that you can distinguish when multiple clients share the same Internet
connection.)
If the numbers are sequential, then that IP usually has only 1 client behind the public IP. FortiWeb
calls this a “standalone” IP.
But if the numbers are non-sequential, then it usually means 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.

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

© FORTINET
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.

© FORTINET
What would happen if you weren’t on the first page of results for Google, Yahoo! or Baidu? Just as
it’s important to block bad IPs, it’s equally important to not block good IPs!
If you host a public 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.

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

© FORTINET
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.

© FORTINET
Search engines are well-known bots. But what about scripted access from bots that you don’t know?
These can sometimes be legitimate power users using tools such as wget. But more often, they are
DoS tools.
If FortiWeb only analyzed the TCP/IP layers, these 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,
full-featured web browser like Firefox or Chrome would. So when a client exceeds a rate limit, you
can configure FortiWeb to inject a test script into the page, and validate whether it’s a browser or not.
If it’s a bot, you can block that source IP.

© FORTINET
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.

© FORTINET

© FORTINET
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.”

© FORTINET
As its name indicates, “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.

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

© FORTINET
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, in general, 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, too, which are
discussed 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.

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

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

© FORTINET
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?
We’ll discuss FortiWeb’s IPS features in another lesson. But if you are already breached and need a
solution to fight it right now, while you’re analyzing a more permanent solution, what can you do?

© FORTINET
Some targets like the FBI and MIT have reasons why some groups persistently attack them.
But you don’t have to be rich, powerful, or politically controversial to have your web site defaced,
either.
About 1.5 million web sites were defaced in 2014. This 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 like this are abandoned after, with the attacker moving on to look for new
targets.

© FORTINET
Not all security breaches are for extortion or secretly 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 and/or automatically revert the files to a clean copy.
Especially in “drive-by” mass defacements at hosting providers, this can minimize impact while you
discover and analyze the security hole.

© FORTINET
When you configure anti-defacement, FortiWeb will periodically use 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, it 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 fast.

© FORTINET
Since most modern web sites are not static HTML files, but instead 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, also apply controls. Database security devices such as FortiDB can help.

© FORTINET
We showed several different types of denial of service attacks that can affect web servers – ones that
affect every OSI layer of the web server stack, as well as DNS. We showed how to study your normal
traffic patterns, and to recognize anomalies.
Some of FortiWeb’s DoS sensors analyze multiple OSI layers. If the HTTP layer is included, we
showed how FortiWeb can test whether clients are web browsers, and apply separate traffic policing
or period blocks to browsers and search engine crawlers.
Finally, we also showed how to use anti-defacement to rapidly undo vandalism, since defacements
often accompany denial of service attacks.

DO NOT REPRINT  Signatures, Sanitization & Auto-learning
© FORTINET
In this lesson, we will show how you can use signatures from FortiGuard subscription services,
create your own custom signatures, and use auto-learning to train FortiWeb about your web apps’
security needs.

© FORTINET
After completing this lesson, you should have these practical skills in how to begin integrating
FortiWeb’s security features that fit best with your specific web applications.

© FORTINET
FortiWeb can send TCP reset signals and, depending on the violation and your FortiWeb’s operation
mode, it 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?

© FORTINET
FortiWeb has many, 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. And whenever an administrator updates a web server or web
application, its needs can change.
How can you configure FortiWeb most quickly?

© FORTINET
There are a few quick start strategies you can use.

© FORTINET
Here is an overview of methods that you can use to configure FortiWeb quickly. Let’s take a look at
each of them.

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

© FORTINET
If you want to do a “dry run” to see if a feature will accidentally block 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 1 week and it doesn’t generate any
accidental attack logs, it’s usually safe to enable the feature – it won’t interfere with normal traffic.

© FORTINET
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 completely 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. Especially if your FortiWeb is inline, it’s important
to use auto-learning wisely.
There are several ways that you can reduce or negate the impact of auto-learning. This keeps
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.

© FORTINET
Here, we see 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.

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

© FORTINET
While auto-learning, one of the things that FortiWeb usually studies is the web apps’ inputs:
• 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 trying to insert
inappropriate data into 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.

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

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

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

© FORTINET
In an HTTP request that uses the GET method, the URL and parameters are all together, on the
same line, with no spaces between them. So how does auto-learning find the URL, and differentiate it
from each input and its values?
By default, it uses standard cues to find them. Usually, for example, a question mark (?) 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.

© FORTINET
The object named “URL Replacer” is what shows auto-learning how to interpret the URL line to find
the actual 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. Cookbook examples are in the
documentation. When you’ve defined a chain of URL replacers to interpret every non-standard part of
the URL into the standard format, group them together – in order – in an application policy, then
select it in the auto-learning profile.
Remember to clear the cache of auto-learning data first if you need to restart the auto-learning period
with your new “URL Replacer.”

© FORTINET
Auto-learning will monitor for many attack types, and give you a head start in 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.

© FORTINET
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. But the tab for inputs, for example, will only
appear when you select a specific URL. You may need to adjust their estimated data types, too.

© FORTINET
If you click the “Attacks” tab, for example, you will see how many requests matched attack
signatures. It is in the “Count” and “Percentage” column.

© FORTINET
When you verify the recommendations, if you want to choose a different setting:
1. Change “Type” to “Custom”.
2. Change “Custom” to “On” if you want to enable the protection, or “Off” if you want to disable it.
3. If you are enabling that type of protection, change the “Action” to your preferred setting when
FortiWeb detects a violation.
4. After you’ve verified or adjusted all settings, click “Generate Config”. Auto-learning will generate
all required components, too.
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.

© FORTINET
A protection profile is what you select in a server policy to indicate which scans FortiWeb should
perform. As you can see, it 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, it can analyze whether cookies are returned intact, and whether sessions are initiated
from a correct URL, and then 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.

© FORTINET
Let’s look at each component that auto-learning generates, and how it protects your web servers.
First, let’s study how it protects session cookies.

© FORTINET
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. But as 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 previously, 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.

© FORTINET
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 will
allow 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.

© FORTINET
Because the server is effectively storing some of its application data on an untrusted client, session
cookies are a risk.
A malicious client could change its value. They could replace the session ID with a SQL query, for
example. In the next request that the client sends, the poisoned cookie would go with it 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.

© FORTINET
FortiWeb’s cookie poisoning detection blocks this kind of abuse.
When it is enabled, FortiWeb uses a little bit of RAM to remember 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 do that.

© FORTINET
Here we see the session cookie again, but this time with 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 bind the authentication status to the session ID.
Before the client receives the server’s reply each time, 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.

© FORTINET
The “Cookie:” header is one type of HTTP input that users don’t usually see, but it’s not the only
one.

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

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

© FORTINET
Input from HTML forms is equally important to validate.

© FORTINET
FortiWeb can apply reasonable limits to inputs from HTML forms, such as requiring that user names
contain email addresses.
Technically, you can use parameter validation rules regardless of the HTML input type: both
visible, user-completed HTML forms, and “hidden” inputs. In the HTTP, they are transmitted the
same way.
But 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.

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

© FORTINET
When restricting uploads, you can also engage FortiGuard Antivirus.

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

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

© FORTINET
When configuring which signatures to use, choosing “Period Block” instead of “Alert & Deny” where
you suspect repeat attacks from a client is an important performance tweak. Select it for DoS or
persistent attacks to reduce FortiWeb’s CPU usage and buy time for forensic analysis.

© FORTINET
Signatures detect many types of attacks. Many correspond to the OWASP top 10, which PCI
specifically requires that you block.
Here is one type, called “cross-site scripting.” Its root cause 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 that is now 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.

© FORTINET
Another very common attack is SQL injection. Again, 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. It can, for example, 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.

© FORTINET
Some signatures apply to most web apps – they are not app-specific. Cross-site scripting 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 specific 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 an individual 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.

© FORTINET
The advanced mode for editing the signature policy offers full flexibility. You can disable a signature
in only this policy, or in all policies. You can also disable it for only a specific domain name and/or
URL (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 directly there,
while viewing the log.
1. Click a log entry to view its details.
2. In the log entry, click the link to either make an exception or disable that specific signature.

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

© FORTINET
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.

© FORTINET
Not all attacks can be detected by regular expressions matching an input string. 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 and/or browser, not another.
• 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.

© FORTINET
Unless you’ve used auto-learning, this can be harder to configure correctly. You must understand the
web app well.
So instead of a period block, 403 Forbidden, or “Alert & Deny” action, it is usually best to just redirect
the client to a 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.

© FORTINET
Many other mechanistic attacks exploit page flow after the session is initiated.
“Page Access” rules enforce valid page order. You shouldn’t, for example, be able to place an
order for a TV unless you’ve submitted payment!
“Page Access” rules can’t completely prevent all permutations of CSRF attacks. Some would require
too much RAM to prevent. A solution would become a potential performance bottleneck or
opportunity for denial of service attacks. So this is why vulnerability scans, IP reputation, and other
features are still important. But page order rules can prevent many.

© FORTINET
This shows how you would configure a page order rule for the scenario we just showed. Notice that
we don’t have to input all pages – only ones where the order between 2 specific pages must be
enforced.
Like usual, we 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.

© FORTINET
We showed 3 strategies for quickly deploying protection settings. We showed how the “Action”
setting that you select can affect performance. When FortiWeb is scanning for attacks, we showed
how it can scan for both input sanitization errors and mechanistic attacks. Finally, we also showed 2
strategies for avoiding blocking legitimate requests when they accidentally match a rule or an attack
signature.

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

© FORTINET
After completing this lesson, you should have these practical skills that you can use to provide
HTTPS access to your web applications.

© FORTINET
Before, HTTPS was mostly used for online banking, e-commerce, and government web sites. Users
needed privacy and confidence about the site’s authenticity.
Since the leaks in 2013 and later by Edward Snowden, however, 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 a person’s seemingly harmless location check-ins and vacation photos can be
exploited. If you’re in vacation in Bali, obviously you’re not home to prevent theft. And privacy laws
that govern email have not modernized 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, too. As a result of the more computationally expensive handshake
and encryption, HTTPS sites are also harder to brute force the login page.

© FORTINET
While many of the top 200 web sites according to Alexa have now changed to HTTPS, they’re only a
few sites relative to the massive total Internet. What about the other web sites?
This shows statistics for the top 200,000 sites as of February 7, 2015. In that sample, 474 were still
vulnerable to Heartbleed, an SSL vulnerability almost 1 year old. 21% 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.

© FORTINET
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 back-end servers, or
• 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 back-end 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.

© FORTINET
To show the difference, here’s an illustration:

• 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 2nd SSL session to the protected servers. This is not
fully transparent. FortiWeb may need its own certificate, too, so that it can authenticate itself to
servers. But it doesn’t save system resources on the protected servers, so it’s not technically SSL
offloading, either.

© FORTINET
To summarize, here are the main differences.
Remember, despite the name, both do enable FortiWeb to inspect HTTPS traffic.

© FORTINET
(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 2nd HTTPS session to the
back-end servers so that data in transit is always secure. These are the configuration steps.
1. First, 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 own personal certificate instead of typing a password, also upload those
CA certificates and CRL or the address of an OCSP server, so that 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.

© FORTINET
Let’s show 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!

© FORTINET
If you’re doing SSL inspection in the other operation modes, then for each server in your server pool,
you must also enable the “SSL” option and define its HTTPS listening port.

© FORTINET
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.

© FORTINET
If you want best performance, you should set up FortiWeb for SSL offloading.
But 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 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 will be acting as a client to your web servers in this 2nd 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.

© FORTINET
Just because you have enabled HTTPS does not automatically make your web site fully secure.
Obviously the attack signatures and mechanism protections in another lesson deal with security once
the packet is received.
But even in transit, HTTPS is not automatically fully secure. SSL and TLS do have their own
vulnerabilities. So it’s important that you configure HTTPS on FortiWeb as securely as you can.

© FORTINET
This is a vulnerability from late 2014 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.

© FORTINET
(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.

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

© FORTINET
After you choose which SSL or TLS versions that FortiWeb will offer to clients, the next factor you
should consider is which cipher suites.
Key sizes 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
re-keying, 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.

© FORTINET
Weak encryption and checksums, including so-called “export grade” encryption, are now disabled by
default on many browsers. So reasons to use old, weak encryption are decreasing.

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

© FORTINET
In Google Chrome, you also click the padlock to see which protocol and ciphers were negotiated.

© FORTINET
Unfortunately, there is no easy way to do this for Internet Explorer. But there are still ways that you
can test for robust client support.
This is one way to test. It’s a Python script called “sslyze.”
You can see that it checks for several vulnerabilities, such as Heartbleed and insecure
renegotiation…

© FORTINET
… as well as certificate validation errors, and which protocols and cipher suites that the server (or
FortiWeb) supports.
Here, we see 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.

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

© FORTINET
Aside from protocol versions and cipher suites, the other major component of HTTPS is X.509
certificates.

© FORTINET
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.
It may also need its own certificate if you want FortiWeb to use PKI authentication as a client to your
back-end severs.

© FORTINET
But 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 few authorized individuals, and backups
should be password-encrypted.

© FORTINET
What other certificates do you need to upload to FortiWeb?
CA certificates are important for certificate validation. FortiWeb must validate certificates in 2 cases:
• When a client sends a personal certificate for PKI authentication, and
• When FortiWeb connects to an OCSP, LDAPS, back-end HTTPS, or secure email server.

© FORTINET
Like web browsers, when FortiWeb evaluates a certificate, it will examine the same factors:
1. Does the IP address or host name in the certificate match exactly?
2. Is it currently valid, not expired or pending a future time or date?
3. Is it signed by a CA that I trust?
4. 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?

© FORTINET
For CA signatures to be truly trustworthy, it’s important that an attacker can’t use collision attacks.
These allow them 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 show what this allows
you to do.

© FORTINET
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.

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

© FORTINET
Server certificates are only one type of certificate. FortiWeb can also accept – and present – a client
certificate.

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

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

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

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

© FORTINET
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?

© FORTINET
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.

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

© FORTINET
Here we see a reply from a web server where FortiWeb has injected the “Strict-Transport-
Security:” header.

© FORTINET
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!

© FORTINET
We discussed the differences between SSL and TLS, and how some HTTPS protocol versions and
ciphers are not recommended. We explained SSL offloading and SSL inspection, how to test them,
and their implications for server-side configuration. Finally, we also showed how to enforce use of
HTTPS instead of clear text HTTP.

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

© FORTINET
After completing this lesson, you should have these practical skills that you can use to provide
authentication for your web applications.

© FORTINET
When you authenticate users, the first thing you should always do is make sure that user names and
passwords are encrypted in transit. Otherwise, man-in-the-middle (MiTM) attacks and even attackers
in the same Wi-Fi range can easily see their logins.
You may think, “Do I really 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.

© FORTINET
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, effectively, their action is
“Continue to Other Scans.”
If you have a web app that should only be accessible by a few people such as top management
levels logging in from a secure, private network location, this may be enough.

© FORTINET
Obviously it’s often impractical to manually maintain the 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.

© FORTINET
If you need to control access based upon the request’s HTTP layer – its URL and host name – then
FortiWeb can do that, too. In previous FortiWeb versions, URL access rules could only match by the
domain name and URL, but now, they can match based upon the client’s source IP, too.
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.

© FORTINET
If you need more sophisticated HTTP-layer control of URL access rules, FortiWeb can do that, too. 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.

© FORTINET
Here, you can see a rule that not only restricts URL access to 1 source IP, but also checks the rate
limit and self-reported “User-Agent:” string, allowing access only by that specific client software.

© FORTINET
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.

© FORTINET
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.
By the way, 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.

© FORTINET
When you add an authentication or site publishing rule, this is what the HTTP transaction looks like.
Notice that the first reply is actually a 401 error code, with a header that indicates which
authentication the client should submit. This triggers the browser’s HTTP authentication dialog box.
When the person submits their user name and password, the browser re-sends the initial request,
this time with their authentication details in an HTTP header. Now 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!

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

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

© FORTINET
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 via 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.

© FORTINET
Once your queries and/or locally-defined user accounts exist, group them into a user group.

© FORTINET
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.

© FORTINET
Next, group your authentication rules in an authentication policy.
This creates a set of authentication rules, but it also specifies whether FortiWeb will log login failures,
what the connection timeout is, and also how long it will keep idle, authenticated HTTP sessions in
cache.
Fast cache timeouts help to prevent unattended computers from being a possible attack vector, and
reduce RAM usage on FortiWeb. So it 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.

© FORTINET
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?

© FORTINET
Site publishing is the newer, more sophisticated authentication gateway method. For Microsoft TMG
replacements, this is the method of choice.
Notice that it supports client certificates and HTML form-based authentication, not just HTTP
authentication. It also supports delegation, agentless 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, and
• Where in the certificate FortiWeb should look for the field that contains the user name

© FORTINET
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.

© FORTINET
When configuration is complete, the dialog that site publishing will trigger 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

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

© FORTINET
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.

© FORTINET
Now that authentication is implemented, you’ll want to add a few protections for attacks that are
specific to it.

© FORTINET
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.

© FORTINET
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.

© FORTINET
Remember, if there are multiple clients sharing a single Internet connection behind NAT, then you’ll
usually want to allow multiple times as many 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!

© FORTINET
Padding oracle attacks are another attack on authentication and session IDs. The name just means
that the attacker analyzes the padding in order to find a predictable pattern. Once they find this
pattern, they use it to understand the encryption and thereby undo it.
In essence, it’s the same idea as the SSL/TLS attacks named CRIME & Lucky 13. CRIME “requires
only 6 requests to decrypt 1 cookie byte” due to compression. “TLS MAC calculation [always]
includes 13 bytes of header information … in part, [that’s] what makes the [Lucky 13] attacks
possible”… Its predictable length.
http://www.isg.rhul.ac.uk/tls/Lucky13.html

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

© FORTINET
Padding can be found an 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.

© FORTINET
We showed 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.
We showed 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 sign-on across multiple web applications without any installation of a Fortinet SSO agent.
Finally, we showed 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.

DO NOT REPRINT  PCI DSS 3.0 Compliance
© FORTINET
In this lesson, we’ll show how to apply FortiWeb features to help you meet requirements of PCI DSS
3.0. This includes applying industry best practices from the OWASP Top 10.

© FORTINET
After completing this lesson, you should have these practical skills that you can use to find
vulnerabilities and patch them (or apply FortiWeb on-the-fly patching), secure your transactions, and
detect data leaks.

© FORTINET
Objectives of professional attackers are 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
includes bank debit and credit card numbers.
This 2014 study from Verizon highlights how common the problem is.

© FORTINET
Because retailers and payment service providers often do not directly bear the cost of fraud,
unfortunately 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 re-issue compromised cards. And this was for only one
breach.

© FORTINET
The payment card network – including banks – absorbs most of the losses due to fraud. As a result, it
has a clear financial interest in security. It 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.

© FORTINET
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.

© FORTINET
PCI has released its next security standard, version 3.0. This came into force on January 1, 2014, but
for existing PCI DSS 2.0 compliant vendors, they extended the deadline to January 1, 2015. Many
specifications were still best practice only, though, before beginning enforcement in June 1, 2015.
What’s important to know?
The core areas of security remain the same. But the standards development will now be 3 years long,
and there are new sub-requirements to deal with the most current threats – specifically mentioning
web application firewalls.
We’ll discuss each of these sub-requirements, and how to meet them.

© FORTINET
FortiWeb helps to meet all PCI requirements, but PCI now specifically recommends a web
application firewall, and developing remediations against the top 10 vulnerabilities according to
OWASP.

8
© FORTINET
If you’re not familiar with OWASP, it’s a global non-profit. Its goal is to promote secure application
coding and hardening.
OWASP has been growing steadily since 2004, and has been a contributor to projects such as the
WebGoat security education application. Now you can find OWASP presenters everywhere from
OWASP’s official AppSec conferences in California and Rio de la Plata, to German OWASP Day,
Financial Services Cyber Security Summit in Dubai, and Black Hat Asia.

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

© FORTINET
OWASP’s last update to the Top 10, available in many languages from Arabic and Chinese to
Spanish and Ukrainian, is from 2013.
Let’s show how FortiWeb can help you to find these vulnerabilities in your web applications, and to
defend against them.

© FORTINET
Injection and cross-site scripting: these 2 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 it 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 do not 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.

© FORTINET
The good news is that FortiWeb can easily prevent these. 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.

© FORTINET
For performance reasons, FortiWeb shouldn’t scan for attacks that your web apps aren’t vulnerable
to. It’s a waste of resources.
Manual penetration tests are slow and costly. How can you speed up some of your PCI compliance
audits? How can you quickly discover the correct FortiWeb settings for your web apps?

© FORTINET
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 can give 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, 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

© FORTINET
To make 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.

© FORTINET
Let’s quickly show 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,
choose the “One Time” type of schedule.

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

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

© FORTINET
If you’re not sure what authentication data to send to the login URL, as usual, the developer tools in
your web browser can help you.
In this example, the Network panel was opened before clicking the “Log In” button 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.

© FORTINET
Once the scan is configured, you can immediately run it by clicking the “Play” button, or wait for the
appropriately scheduled time. While the scan is running, the page will periodically update 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.

© FORTINET
To view the report while you’re logged into FortiWeb’s GUI, click its link in the “Scan History”
submenu.

© FORTINET
When you open the report, it will remind you which settings you chose, then show a summary of the
number and types of vulnerabilities that FortiWeb found.
If you click on each vulnerability type on the left, you can view details about where FortiWeb found
each vulnerability.
Here we see an actual scan result 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.

© FORTINET
The details contain information that will help you to decide on signatures to protect your servers, such
as:
• What was tested, and
• How severe are the potential effects of the vulnerability
That way, you can prioritize work based upon risk levels.
If you view the page and its response, and determine that the vulnerability cannot actually be
exploited, you can also mark any false positives that the scan finds until the number of detected
vulnerabilities is accurate for your “To Do” list.

© FORTINET
Now we’ve shown a couple of OWASP top 10 vulnerabilities, and how to detect them. What are the
other vulnerabilities?

© FORTINET
OWASP’s second most serious threat is more complex to protect against.
Because authentication and sessions can be attacked in many ways, you want to make sure that
every step is secure:
• 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 to make sure that a client is not trying to masquerade
as another client, effectively hijacking another’s 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 & passwords
• Subsequent page accesses use the bound session correctly, and don’t allow nonsense page
transitions
• Log messages shouldn’t contain passwords or credit card numbers

© FORTINET
In this example, you can see that when a normal user begins at the login page, they receive a
session ID in a cookie.
But if the app does not require a session for access to all of the other pages, then page order within
the session cannot be enforced, either: 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.

© FORTINET
Most A2 mitigations are selected in the protection profile, but some are enabled directly in the policy.

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

© FORTINET
Insecure references to objects can occur wherever the web app does not validate authorization to
those specific objects. Remember, just because a client has submitted a user name and
password does not mean they should be necessarily universally trusted. For example, 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 we will see soon. The difference is that A4 deals
specifically with parameters instead of pages, and application inputs instead of redirect URLs.

© FORTINET
Most people realize that to enforce valid input lengths and types, they should use parameter
validation rules. But other object references are less obvious. For example, even 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 indicates to the web server that it should use its
PHP preprocessor in order to render the HTML page before replying to clients. So 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
would help to control which PHP objects they can access.

© FORTINET
Most web servers have default pages. When you are configuring the web server for the first time, this
helps to quickly confirm that the software is running.
These files, however, should never be exposed on live production servers. This is what A5 essentially
says. They provide information that is useful to attackers. If their permissions are incorrect, these files
can also be an exploit vector.

© FORTINET
For example, phpinfo.php usually has a simple function that displays all PHP settings. Each
application could have its own php.ini and .htaccess file. And 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 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.

© FORTINET
Creative penetration testing by human specialists should always be a part of your security audits, but
automated testing should be part of your arsenal, too. It’s impractically slow to find common
vulnerabilities with only manual testing. For this, you can use FortiWeb’s built-in web vulnerability
scanner. It will use HTTP (like your users) and attempt to find unpatched modules, source code
disclosure, plus vulnerabilities to 3 of the OWASP top 10 threats.
A5 vulnerabilities will be listed under “Information” and sometimes “Source Disclosure” vulnerabilities.
You can also use the “Information Disclosure” category of signatures to find A5 vulnerabilities.

© FORTINET
A6 is 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. And if attacks are logged, you can easily mask passwords and credit card
numbers so that they don’t appear in your unencrypted logs.

© FORTINET
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.

© FORTINET
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.

© FORTINET
“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 if the client is authorized for that “realm” – as FortiWeb does
– and in that step in the session. The app should also check whether that URL should be accessible
from that IP address. Configuration files shouldn’t be accessible via the Internet. Access should be
restricted to a private management network.
There could be other URLs, too, used internally by the web application, whose permissions should be
set so that they can’t be accessed directly, via the Internet.

© FORTINET
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.)

© FORTINET
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 that they don’t intend.
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 would require large numbers of both positive and negative security rules.
For example, let’s say that Jane has received an email that seems 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, when she clicks the button (or even automatically), 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.
And 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.
Then you can also enable FortiWeb signatures to guard against injections of CSRF code.

© FORTINET
This CSRF example shows how a person’s actions on a bank web site can be hijacked by an
attacker.
In this case, 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 – are becoming more common.

© FORTINET
It may surprise you to know that unpatched software is not considered by OWASP to be the most
serious threat. It only ranks 9th on the list of its 10 most serious security threats, even though it is one
of the most common.
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.

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

© FORTINET
Like A4, A10 deals with inputs where the web application hasn’t validated the input. In this case, it’s
specifically inputs for redirects. Apps should check both:
• Valid destination (if offsite redirects are allowed), and
• Authorization of the person to go to those web pages

© FORTINET
Access control rules and parameter validation rules are both applied by selecting them in the
protection profile.
When you’re configuring the parameter validation rule, however, 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?

© FORTINET
There may be cases where you want to adjust the predefined data types, or add your own.

© FORTINET
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.

© FORTINET
To do this quickly, copy and modify the 2nd 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.) They 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:
\?

© FORTINET
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. But 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.

© FORTINET
We explained the risks that PCI tries to mitigate, and its new recommendation specifically for web
application firewalls such as FortiWeb. We discussed how mitigating the OWASP Top 10 most
serious threats can help to protect financial data. We showed 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/configuration file access control
• Parameter sanity checks, including hidden inputs and redirects
Finally, because FortiWeb enforces data types by using regular expressions, we showed how you
can customize it to enforce your app’s specific data types. We also showed how to avoid recording
passwords and payment card numbers in logs.

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

© FORTINET
After completing this lesson, you should have these practical skills that you can use to improve the
user’s experience of your web apps. You’ll also be able to configure FortiWeb to decompress a
buffered copy of traffic in order to scan or rewrite that traffic.

© FORTINET
First, let’s talk about how FortiWeb can cache responses from your protected web servers. Did you
know that FortiWeb does more than secure your web apps? It can make them faster, too.

© FORTINET
Web pages don’t usually change every second or even every hour. Many web pages – even
ones generated on-the-fly by a Tomcat servlet or PHP preprocessor for your content management
system – are effectively static. Usually an author writes the web page or uploads a file, and then that
file never changes again. Yet every time that a client requests the page, the server will usually
use CPU and precious time to re-generate the HTML, again and again. 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. This 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.

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

© FORTINET
Cache on FortiWeb will use 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, for example, 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.

© FORTINET
It may make sense that search result pages shouldn’t be cached. Here are some others that you may
not guess, however.
For example, if the server sets a session cookie, then 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. And 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.

© FORTINET
Let’s show 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 here? 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, just specify the maximum size that you want
to allocate to the cache, and click OK. FortiWeb will automatically try 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!

© FORTINET
FortiWeb can also compress responses. This is another performance feature – something FortiWeb
can do to improve your users’ 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 – then this savings can be significant.

© FORTINET
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 themselves, but you may be able
to improve performance by having FortiWeb do it instead. This allows your servers to focus and use
the CPU more efficiently, on things such as the 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, naturally. If a file is too big to fit in
FortiWeb’s compression buffer, then of course 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.

© FORTINET
Let’s see 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 usually 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 opposite from 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.

© FORTINET
Plain text notes may not compress well either. This is because 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.
Some file types have native compression, too. ZIP archives are of course 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.

© FORTINET
When does compression help? When you have long files, with repetitive bytes: GZIP’s
Huffman coding is good at representing these efficiently. With a Fortinet .conf file, the GZIP
could be 13% of the original – a good compression ratio.
But these examples use natural, human languages. Written Chinese is already very compact, with
almost no repetition. So compression only reduces the file size of this UTF-8 plain text file by 1.5%.
Compression is not worth the CPU time.
An English translation of the same poem is less compact. But compression still doesn’t offer much
advantage: it reduces the file size by only 31%. Length improves the probability of repetition, though.
Look at the second, longer poem. It has a complex vocabulary, but it’s about 3 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.

© FORTINET
Here’s a real web page. For the HTML page alone, compression makes the transmitted file 4 times
smaller – a very big speed improvement.
When compressing HTML, it’s typical to see a 75% to 80% file size reduction like this.

© FORTINET
Let’s see 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 that 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 for “text/plain”.
When done, select the compression policy in the protection profile. That’s it!

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

© FORTINET
Depending on how much load your FortiWeb has, it may be better for your servers to do it instead.
In that case, FortiWeb receives a pre-compressed file. So 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 just 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.
You don’t want to forward an uncompressed file, though. So FortiWeb’s uncompression is only
temporary. After a rewrite or a scan where the “Erase” action is required, it automatically applies the
compression again. Alternatively, if no patterns match and no change is required, then FortiWeb
doesn’t need to re-compress; it can just re-use the compressed original. Either way, FortiWeb
forwards a compressed response.

© FORTINET
Just like we configured a compression policy before, uncompression policies are based upon file
type. And if you want to exclude any responses from uncompression, you can do that, too.

© FORTINET
We showed 2 methods to improve the speed at which you deliver your web apps to clients: cache
and compression.
We also showed how, if your server has already compressed its response, FortiWeb can buffer and
uncompress a copy of the traffic in order to scan and/or modify it before forwarding the packet.

DO NOT REPRINT  HTTP Routing, Rewriting, & Redirects
© FORTINET
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.

© FORTINET
After completing this lesson, you should have these practical skills that you can use to rewrite
requests and responses, and to redirect clients to HTTPS or new URLs if a web application has
moved. We will also show you how to use FortiWeb as a Layer 7 switch, delivering each request to a
specific web server depending on the URL that the client requests.

© FORTINET
Let’s begin with redirects. This is usually the simplest thing you can do with FortiWeb’s rewriting
rules.
Redirects also will help you to learn how to match traffic for rewriting, which we will show later.

© FORTINET
When are redirects useful? Mostly to establish HTTP traffic flow.
When a page moves, or if the person made a typo, you can tell the client to go to the new URL. This
avoids 404 errors. It’s the most common use. 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, different host name on the private network.
These uses are simply infrastructure: they are required for the web app to work. But redirects can
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, though, you’ll
often combine a redirect with a rewrite, which we’ll show later.

© FORTINET
How do redirects work?
FortiWeb replies to a client’s request with a 301 or 302 code and a “Location:” header. This
tells the browser to look for that resource in another location instead. (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 first. So 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 1st time and the
2nd time – have been modified by FortiWeb.
Keep this in mind. We’ll use the same concept later for rewriting traffic.

© FORTINET
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 via 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, remember?
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.

© FORTINET
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.” And since usually we don’t want to redirect every request to the same place,
we’re also going to specify a few more match conditions: the “Host:” and URL line in the HTTP
header.
Once you’ve specified the match, the “Request Action” will be that 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. And to avoid making 1 rewriting rule per URL
– which could be 10,000 – we use capture group variables to define the location.

© FORTINET
What is a capture group? And, relatedly, how can we refer back to text that was stored by a capture
group?
For URL rewriting rules, FortiWeb uses regular expressions. You may have noticed by now that
FortiWeb uses regex for many features. Because HTTP and its usual payload HTML are text-based,
and because regex is designed for text-based patterns, it’s the perfect match.

© FORTINET
In case you’ve never used regular expressions before, or haven’t used them with output, let’s quickly
explain what a capture group is.
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 (that is, “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

© FORTINET
In programming, the purpose of variables is to re-use 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, by the way, this isn’t the only way you can refer back to data from capture
groups. If you want to re-use 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 re-use 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.

© FORTINET
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 – then we 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.

© FORTINET
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 our universal redirect to
HTTPS.

© FORTINET
If you only want to redirect for www.example.com, then you could just enter:
www\.example\.com
Alternatively, you could match the IPv4 address. The documentation has example 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?

© FORTINET
The answer is rewrites. When FortiWeb is inline, remember: 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.

© FORTINET
There are many more reasons why you might want to rewrite traffic. We can’t fit them all here.
Rewriting sometimes is 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 our example, we need absolute links in our 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.

© FORTINET
Again, 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 in the FortiWeb Administration Guide.

© FORTINET
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.
But 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 – remember – 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.

© FORTINET
Here’s an example. 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:
• People won’t need to fix their browser’s bookmarks, and
• We won’t have to configure any redirects to avoid 404 errors.
To make this work, we need 2 rules:

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

© FORTINET
On the left side, we see the second rule. It scans the reply body – which could be HTML or
JavaScript for example – 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.

© FORTINET
Rewriting clients’ 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.

© FORTINET
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.
Notice that HTTP content routing can match based upon 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.

© FORTINET
This shows an example of HTTP content routing based upon the “Cookie:” header.
When the person 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.
In this way, we could 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.
And because each server can host different web apps, FortiWeb will allow 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.

© FORTINET
Let’s show 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.

© FORTINET
To apply your routes, in your server policy, select the “Deployment Mode” named “HTTP Content
Routing”, 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.

© FORTINET
If a multiplexing device is in front of FortiWeb, and if it is intelligent enough to pipeline requests from
the same client, for the same web app, together in the same TCP connection, then you can enable
the “Match Once” setting.
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.
Don’t enable the setting otherwise, however. If the connection multiplexes unrelated requests
from multiple clients, many requests could be routed to the wrong server pool.

© FORTINET
To begin, we showed how you can redirect users to a secure site, and rewrite URLs in the headers
and in links in web pages. We explained 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, we explained how to use capture groups.
Finally, we also showed 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.

DO NOT REPRINT  Troubleshooting
© FORTINET
In this lesson, we’ll show how to avoid common misconfigurations, diagnose false positives, solve
connectivity and storage issues, and optimize your FortiWeb’s performance.

© FORTINET
After completing this lesson, you should have these practical skills that you can use to resolve issues
and avoid problems.
Lab exercises can help to test and reinforce your skills.

© FORTINET
Especially if you are installing a new, custom web app with FortiWeb, initially you may need to fine-
tune rules and signatures to avoid some false positives. “False positives” are requests that look
similar to an attack, but are actually normal traffic.

© FORTINET
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, 2 scans occur. So if a client begins a TCP flood, or is already being period
blocked, the white list will not immediately restore connectivity.

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

© FORTINET
If there are only a couple of false positives, then you can fix them yourself easily.
1. Enable local storage of attack logs. Enable packet payloads – part of the packet that matched the
rule or signature.
2. Then in the attack log, find an entry for an “attack” that is actually normal traffic.
3. Click the row. The log message’s details should appear in a panel on the right side. If you scroll
down to the “Packet Header” section, FortiWeb will highlight the part of the request or reply that
matched the signature.
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” part 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 re-enable them.

© FORTINET
If you’re adjusting behavior to create a custom signature, it can be helpful to know the ID and
behavior of the signature that triggered a false positive.
The ID indicates the category of attack that it was intended to block. And 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 3 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

© FORTINET
If FortiWeb is applying a period block, usually their entry on the temporary blacklist will expire before
they contact you. However, if they try the same thing again, they will immediately be blacklisted
again. Even if you white list their IP, this will not cancel the period block.
So remember to also 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.

© FORTINET
A white list entry should not be a permanent solution, however. Imagine if the person’s laptop
becomes infected with a virus, or if their phone is stolen. Then, that client is not in that person’s
control anymore. You don’t want FortiWeb’s security to be nullified.
So if you’re not immediately sure how to write a custom signature, you could instead change the rule
or signature’s “Action” to be “Alert Only”. 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 more 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, though, not for search engine crawlers.

© FORTINET
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.

© FORTINET
Search engine crawlers aren’t the only bots that may be trying to access your web apps.
Some are blog comment spam bots. Others are content scrapers – scripts that steal web pages,
images, and videos from other sites. Often they’re used to populate sites so that their owners can get
advertising revenue without paying authors.

© FORTINET
Sometimes, power users will occasionally use command-line tools such as “curl” and “wget” to
download web pages for offline viewing. But these are the minority. And (unless you block them),
they will, by default, honestly report their “User-Agent:” string.
But some bots, such as ContentSmartz, are designed specifically for malicious use. And 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, look at the “Bot Analysis” page. You may
want to enable “Real Browser Enforcement” to protect your pages from theft.

© FORTINET
If your FortiWeb is scanning HTTPS, you can troubleshoot encryption–related issues, too.

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

© FORTINET
There are some misconfiguration issues that are possible with HTTPS. Here is an example of 2
common ones.

© FORTINET
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 will cause
an “unknown protocol” message in the attack logs.
Notice that this may be normal, expected behavior in some cases. For example, if you’re
required to be PCI DSS compliant, you could see this error when some very old clients are trying 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. It is very unlikely, however. 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.

© FORTINET
This case is more rare, but you could also see some messages that indicate FortiWeb can’t inspect
the HTTPS traffic. This is caused by a combination of factors: a specific type of cipher suite and when
FortiWeb is 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.

© FORTINET
Once scans are functioning correctly, next verify performance. Security should not be your
bottleneck.

© FORTINET
Is performance normal? How do you know?
Begin by observing your system resources and bandwidth usage while FortiWeb is idle, and during
low traffic periods, such as night time and weekends. Then also 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?

© FORTINET
If you have an SNMP manager such as FortiManager or Cactus, this is a good way to track traffic
and system resource changes over time. You can use this data to help you plan in advance 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 trap “Attack detected by signatures”, then you may need to
optimize a custom signature’s regular expression. If possible, reduce the number of characters
“consumed” or forward-looking required in order to determine a match.

© FORTINET
High RAM or CPU usage can also be tracked in the logs.
Especially 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.

© FORTINET
You wouldn’t transmit your security logs over the Internet without encryption, right? The same
principle applies to alert email.
Since your mail servers may not be located in the same data center as FortiWeb, FortiWeb now
supports secure mail protocols to protect the messages while they are in transit.
To preserve performance while you are under a denial of service attack, FortiWeb will only record
one log and send one alert email for multiple instances. This also helps to prevent 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.

© FORTINET
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 re-spawned, so this is not a permanent
solution, but it can provide temporary relief while you enable debug logging.
In the example here, 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, for example, a
memory leak. This would require a firmware upgrade to fix. But in other cases, high RAM usage can
be caused by misconfiguration.
Debug logs can help you and Fortinet Technical Support to locate the real cause.

© FORTINET
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, for example, 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 only
tries an attack only once, then its entry in cache is now consuming some RAM, yet doesn’t provide
any benefit. “Period Block” only improves performance when the same client attacks your web
apps many times – not just once.

© FORTINET
You can test for persistent, disk-stored cache by rebooting FortiWeb. But 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.

© FORTINET
Beside 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 here, 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.

© FORTINET
Here, we 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. Occasionally there are exceptions. When
FortiWeb added the data analytics feature, it required more storage for the data analytics file, so
before loading the firmware update, it was required to upload a special image to repartition the disk.
As always, read your Release Notes to see if there are any special instructions like this before
upgrading.

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

© FORTINET
If you ever need to restart FortiWeb, obviously it will terminate all current administrator sessions. So if
multiple people configure FortiWeb, notify them to save their changes before you enter the “exec
reboot” command.
This command can be used to show which accounts are currently logged in.

© FORTINET
In order to study your normal traffic flows, FortiWeb has some tools for this, also.

© FORTINET
You can download the data analytics database from Fortinet Technical Support. When you upload it
to FortiWeb, the “Data Analytics” option then becomes usable in policies.
Data analytics queries your attack and traffic statistics and HTTP return codes in server replies. It
then correlates them with, for example, specific regions of the world and attack categories.

© FORTINET
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.

© FORTINET
If you need to analyze your network on 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. And the virtual
MAC will usually by dynamically generated, at load time – not static. Unless you use a distributed
virtual switch, you shouldn’t notice any transmission errors either, and separate vSwitches should
mean there are no transmission errors, either. And some will be emulated. There is no actual twisted
pair cable in a host-only virtualized network…

© FORTINET
You can also 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, where both devices believe that they are the primary, and
therefore both believe 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 clearly that the ports on both
devices have the same virtual MAC.

© FORTINET
As always, to test your routing paths, FortiWeb has ping and traceroute commands.

© FORTINET
Also like FortiGate, you can use the command line to capture packets that arrive on or leave one of
FortiWeb’s network interfaces. And 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

© FORTINET
Let’s show 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, but 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 3 packets, we don’t have to press Ctrl + C to stop the
capture.

© FORTINET
This is the packet capture that Fortinet Technical Support is more likely to request. It contains much
more detailed information as indicated by verbosity level “6”, including 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 too much distracting, irrelevant information, we’ve used the packet filter
‘tcp port 443’ to focus on HTTPS traffic.
Stopping after 3 packets is usually not enough. So in this case, the command runs until the
administrator pressed Ctrl+C, as indicated by “^C”.
By default, terminal emulators such as PuTTY or TeraTerm have a 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, you can see how in
the FortiWeb CLI Reference.

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

© FORTINET
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.

© FORTINET
If you have an HA cluster, and especially if you use FortiWeb VM, here are a few specific tips.

© FORTINET
Like FortiGate, FortiGuard services are licensed for each device, not per 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.

© FORTINET
When signatures or rules accidentally block innocent traffic, we showed how you can either fix the
rules or signatures, create exceptions for specific URLs, or disable the signature. Content scrapers
and search engine crawlers often should have different settings than human web browsers, so we
showed how to handle those specifically.
We also showed how to monitor CPU, RAM, bandwidth, and disk space for abnormal usage. “Period
Block” often improves performance, but we explained one case when that is not true. Finally, we
showed how to fix connectivity issues, including ones with FortiGuard and HA clusters.

FortiWeb Student Guide-Online

Uploaded by

Copyright:

Available Formats

FortiWeb Student Guide-Online

Uploaded by

Document Information

Copyright

Available Formats

Share this document

Share or Embed Document

Sharing Options

Did you find this document useful?

Is this content inappropriate?

Copyright:

Available Formats

FortiWeb Student Guide-Online

Uploaded by

Copyright:

Available Formats

DO NOT REPRINT

VIRTUAL LAB BASICS ...................................................................................7

Transferring Files to the VM....................................................................................................12

Using HTML5 Instead of Java ................................................................................................12

International Keyboards ..........................................................................................................13

Troubleshooting Tips ..............................................................................................................14

1 Configure Network Settings on your Fortinet Devices........................................................17

2 Access the GUI ...................................................................................................................20

3 Verify Connectivity to the Web Servers ..............................................................................21

4 Traffic Flow through FortiWeb to the Web Servers ............................................................22

2 INTEGRATING REMOTE LOGGING & REPORTS .............................................25

2 Configure FortiAnalyzer to Receive Logs ...........................................................................27

3 Configure FortiWeb to Send Logs to FortiAnalyzer............................................................29

3 INTEGRATING FRONT-END FORTIGATE SOURCE NAT.................................32

1 Configure FortiGate Source NAT and Transmission of 'X-Forwarded-For:'.......................33

2 Configure FortiWeb to Use X-Headers...............................................................................36

4 MITIGATING DOS ATTACKS........................................................................38

1 Test for Slow Headers DoS Vulnerability ...........................................................................39

2 Configure FortiWeb to Protect Against TCP Floods...........................................................40

5 SIGNATURES & AUTO-LEARNING ...............................................................41

1 Enable Auto-Learning .........................................................................................................42

2 Simulate Attacks .................................................................................................................43

3 Generate a Protection Profile .............................................................................................44

6 SSL / TLS ................................................................................................46

1 Upload the Server's Certificate & Key to FortiWeb.............................................................47

2 Offload HTTPS to FortiWeb................................................................................................48

1 Sophisticated Access Control .............................................................................................50

8 REWRITING & REDIRECTS ..........................................................................57

1 Redirect HTTP to HTTPS ...................................................................................................58

1 Determine Baselines & Normal Resource Usage ..............................................................60

2 Fix the False Positives ........................................................................................................61

APPENDIX A: ADDITIONAL RESOURCES........................................................62

APPENDIX B: PRESENTATION SLIDES ...........................................................63

1 WAF Concepts ....................................................................................................................64

2 Basic Setup .........................................................................................................................104

3 Integrating External SIEM ...................................................................................................156

4 Integrating Front-End SNAT & Load Balancers .................................................................206

5 DoS & Defacement .............................................................................................................230

6 Signatures, Sanitization, & Auto-Learning..........................................................................262

9 PCI DSS 3.0 Compliance....................................................................................................383

10 Caching & Compression ....................................................................................................432

11 HTTP Routing, Rewriting, & redirects................................................................................451

FortiWeb Student Guide 7

FortiWeb Student Guide 8

FortiWeb Student Guide 9

FortiWeb Student Guide 10

FortiWeb Student Guide 11

Transferring Files to the VM

Using HTML5 Instead of Java

FortiWeb Student Guide 12

FortiWeb Student Guide 13

FortiWeb Student Guide 14

 Prepare your computer's settings:

 To retry immediately, go to the console and enter the CLI command:

FortiWeb Student Guide 15

FortiWeb Student Guide 16

conf system interface

set allowaccess http https ssh ping

config route static

set device port1