Professional Documents
Culture Documents
Student Guide Fortiweb 581
Student Guide Fortiweb 581
Prerequisites
Load the ESX-Labs package into your Fusion or VMWare Player/Workstation
Start the SET-Linux server, then connect to it with user fortinet and password
fortinet.
TIP: if you have any problem with the ESX web GUI, right click over the SET-Linux
VM and select Console > Launch Remote Console.
sudo su
cd /root/scripts
./Deploy.sh ESX-IP fwb.conf
Example:
root@SET-Linux:# sudo su
root@SET-Linux:# [sudo] password for fortinet: fortinet
root@SET-Linux:# cd /root/scripts/
root@SET-Linux:# ./Deploy.sh 192.168.10.128 fwb.conf
root@SET-Linux:#
If this is the first installation, just select “y” for all options and wait for the
deployment of all VMs, which can take some minutes.
If for some reason you want to just reinstall one VM, delete that then run the same
script again, but this time choosing “n” except for the VM you want to reinstall.
In our lab either the SET-Linux has 2 interfaces, one getting IP from DHCP and
another locally defined.
FortiWeb has 3 interfaces, port1 is the one connected to DHCP network just to
allow administration access to the GUI.
In case of the coincidence of your local DHCP network is also 10.0.2.0/24, just
change the IPs indicated in the topology to another network from your choice, and
remember that IPs while doing this lab.
From the ESXi interface, open the WebServer1 VM console with user root and
password fortinet.
From the ESXi interface, open the WebServer2 VM console with user root and
password fortinet.
Turn on the FortiWeb01 if is not already on, At the CLI login prompt, log in with the
default username of admin with no password.
Enter the following command to display system status information for the FortiWeb
device:
The output displays the FortiWeb unit’s serial number, firmware build and
additional settings.
To configure a system hostname for the FortiWeb device enter the following
commands:
#config system global
(global)#set hostname FWB01
(global)#end
You should notice that port1 is currently configured with the factory default IP
setting of 192.168.1.99 .
Change the port1 to get IP from DHCP, and configure static IP address for port2
to 10.0.2.1 and port3 to 10.0.1.1 by entering the commands below:
Check the FortiWeb port1 IP received from DHCP. We’ll refer for it as FWB-IP in
this document:
To change the admin timeout default value (in minutes), execute the following CLI
commands:
The web UI on the FortiWeb unit can be accessed using a standard web browser.
For proper rendering and display of the graphical user interface, cookies and Java
script must be enabled.
Log in with the default username of admin (all lowercase) with no password.
Go to System -> Maintenance -> System Time and select the right time zone
according with your geographical location:
You have now completed the initial system configuration of your FortiWeb unit.
Explore the various menu items and screens available in the web UI to become
familiar with the overall layout and organization of system components.
Go to Server Objects > Server > Virtual Server to define the Virtual IP address
used by the FortiWeb unit to fulfill requests for the web application.
Name: WebServer_VS
IP Address: 10.0.2.105/24
Interface: port2
Next you will configure two real server entries and the server pool. Go to Server
Objects> Server Pool and click Create New. Configure the following settings:
Name: WebServer_Real
Type: Reverse Proxy
Single Server/Server Balance Server Balance
Server Health Check HLTHCK_ICMP
Load Balancing Alg. Round Robin
Click OK.
IP Address: 10.0.1.31
SSL Unchecked
Port: 80
Weight: 1
Click OK to save the configuration.
IP Address: 10.0.1.32
SSL Unchecked
Port: 80
Weight: 1
Click OK to save the configuration.
In this exercise, you will activate the Load Balancing configuration performed in
the previous exercise by selecting it within a Server Policy.
Go to Policy > Server Policy and click Create New. Configure the new Server policy
rule as follows:
http://10.0.2.105
To enable traffic logs, go to Log&Report > Log Config > Other Log Settings and
select Enable Traffic Log as shown below:
To verify the status of the real servers, go to System > Status > Policy Status and
check the Server Status widget.
If both real servers are active the following information should be displayed:
With the load balance configuration now in place, the next goal is to offload SSL
encryption/ decryption activities from the web servers to the FortiWeb unit.
On the FortiWeb unit go to System > Certificates> Local and click to GENERATE
certificate, then fill the information:
Download and give the file for the instructor to sign. Then click IMPORT and add
the signed certificate:
In order to apply SSL offloading, go to Policy > Server Policy > Server Policy and
make the following changes to the existing wg_LB policy:
The connection between the client and the FortiWeb unit is now secured. To
confirm this, connect to the Virtual IP address of the web server:
https://10.0.2.105
When the certificate warning message related to the certificate issuer (CA) is
displayed, click “I Understand the Risks then click Add Exception…” and view the
certificate provided. You should notice that it is issued to the Common Name (CN)
of FortiWeb interface.
Check that the connection to the real webserver is still using HTTP, since in Server
Objects > Server > Server Pool there are only HTTP real servers:
You can change the servers to enable SSL (just check this option, we won’t test it
in this laboratory):
Go to System > Status > Policy Status to see that WebServer2 is already
considered down.
Test access to http://10.0.2.105 and https:10.0.2.105 to check that the VIP still
works but forwarding traffic to the online webserver only.
Objectives
In this lab, you will execute a stored cross-site scripting (XSS) attack against the
vulnerable web application. Until this moment FortiWeb was configured to NOT
block attacks to the webserver. Afterwards, you will configure the FortiWeb device
to detect and block the attack.
http://10.0.2.105
To test the XSS Attack go to the “Guestbook” section, and under message field
type the following text:
Nome: Whatever
Mensagem: <script>alert('Not Secure')</script>
Click again to the Guestbook menu. You’ll have a prompt like this:
To test the SQL Injection, go to the “Acesso Cliente” Section and fill with the
following ID:
admin'or'x'='x
Perform the steps below to use the FortiWeb unit to detect and block cross-site
scripting attacks like the one you executed above.
Perform the steps below to create a server protection rule that will prevent cross-
site scripting. Go to Web Protection > Known Attacks > Signatures and click Create
New. Configure the following settings:
Name: xss
Cross Site Scripting: Checked
Action: Alert &Deny
Severity: High
Leave all other parameters at their default values and click OK.
Name: xss_profile
Known Attacks > Signatures: xss
Leave all other parameters at their default values then click OK.
Server Policy
Next go to Policy > Server Policy and edit the existing policy
(WebServer_LB_Policy). Configure the settings below to identify the traffic you
wish to protect against XSS:
XSS Prevention
http://10.0.2.105
Clear the WebServer database by going to Setup > Reset Database. This will
delete the previously entries inserted by the XSS attack.
Name: Whatever
Message: <script>alert('Not Secure')</script>
The FortiWeb unit will block your access to the web page.
Observe the entry for this attack in the Attack log, and check the details:
ID: admin'or'x'='x
Lab 4: DoS
Objectives
You will configure and test a DoS protection policy to block a DoS attack.
In this exercise, you will bring down one of the web servers by executing a DoS
attack against it.
Go to Policy > Server Policy, edit the WebServer_LB_Policy rule and remove the
Web Protection Profile configuration. We are doing this to see the results of the
attack when no protection is applied by FortiWeb
The Slow POST attack will start and you should see a new window showing
increasing counters for the number of connections attempted, active connections
and connections failed. A Slow-Post attack sends multiple posting of data while
keeping all the connections alive. The connections are kept alive by sending partial
posting data at regular times. This attack can eventually make a web service
unresponsive by consuming all the available resources in the server.
While the attack is running, try to connect several times to the web server using
the http://10.0.2.105. At one point, connection attempts from your browser will start
to fail because the attack has successfully brought down the web service.
In this exercise, you will configure a DoS Protection Policy. You will then perform
the DoS attack again and verify that the source IP address of the attacker has been
blocked by the FortiWeb.
Go to DoS Protection > Network > TCP Flood Prevention and click on Create New.
Configure the setting below:
Name: TCP_Flood
TCP Connection Number Limit 10
Action Period Block
Severity Medium
Block Period 60
Click OK.
Go to DoS Protection > DoS Protection Policy and click on Create New.
Name: DoS_Policy
HTTP Session Based Prevention: Unchecked
HTTP DoS Prevention: Checked
HTTP Access Limit: Please Select (not selected)
TCP Flood Prevention: TCP_Flood
Click OK.
Go to Policy > Web Protection Profile > Inline Protection Profile and click on the
existing profile with the name xss_profile.
Enable Session Management and select DoS_Policy for the DoS Protection
setting. Leave all other parameters at their default values, and then click OK.
You should see a new window showing increasing counters for the number of
connections attempted, active connections and connections failed.
Also, while the attack is running, check you can still access the webserver from
your laptop:
http://10.0.2.105
The tool attempted 4000 connections. Only the first 10 (the threshold defined in
the rule) were allowed by the FortiWeb. The other 3950 attempts were blocked.
Go to Log&Report > Monitor > Blocked IPs and check that the IP address has
indeed been blacklisted by the FortiWeb:
The IP address will be blacklisted for 60 seconds (the Block Period) after the
attack. During that time, any HTTP/S connection attempt from that IP address will
be rejected. We can manually remove an IP address from the Blocked IPs list by
clicking of the trash bin icon.
Go to Log&Report > Log Access > Attack and check the log generated after the
attack:
Objectives
In this lab, you will use the Auto Learn functionality to monitor HTTP sessions and
create ad hoc profiles to protect the back-end web server.
Go to Policy > Web Protection Profile > Inline Protection Profile and edit the
xss_profile. Verify that Session Management is enabled
Leave all other parameters at their actual values then click OK.
To optimize the learning process, it is recommended to fine tune the default Data
Type Group and Suspicious URL auto-learning settings. The steps included in the
sections below will guide you through this process.
Go to Auto Learn >Predefined Pattern > Data Type Group and select the check
box for predefine-data-type-group. Click Clone and configure the following
settings:
Name: autolearn_data_type_group
Click OK.
• US Zip Code.
• US State Name and Abbrev.
• Canadian Post Code.
Leave all other parameters at their default values then click OK.
Go to Auto Learn> Predefined Pattern > Suspicious URL and select the checkbox
for predefine-suspicious-url-rule. Click on Clone and configure the following
settings:
Name: autolearn_suspicious_url
Server Type: All (sets all selected)
Click OK.
Next, edit the autolearn_suspicious_url and watch the server type selected. Leave
all parameters at their default values and click OK.
Next you will create an auto learn profile to group the new auto-learning objects
created above. Go to Auto Learn > Auto Learn Profile and click Create New.
Configure the following settings:
Name: autolearn_profile
Data Type Group: autolearn_data_type_group
Suspicious URL: autolearn_suspicious_url_rule
Leave all other parameters at their default values and click OK.
Server Policy
Go to Policy >Server Policy >Server Policy and edit the policy called
WebServer_LB_Policy
From the SET-Linux, open a terminal. Run the installed nikto Perl script against
the virtual IP address as indicated below:
sudo su
nikto -h 10.0.2.105 –C all
The nikto script is an open source web server scanner, which performs network
security assessment.
Once the scan has completed, go to Auto Learn > Auto Learn Report. Select the
checkbox for the WebServer_LB_Policy report and click View to analyze the
report.
Pay attention to the attacks counted. In a later exercise, we will see how the
“learned” information can be used to configure protection settings against this type
of attack.
Change the Action to “Alert and Deny” to Generic Attacks, Known Exploits and
Bad Robot.
Customizing Reports
From the Auto Learn Report page the administrator can customize various fields
including:
• Protected Servers
• Attacks (Server Protection Rules)
• HTTP Methods
• URL Access Rules
• URL Start Page
Profile Generation
To generate an Auto Learn Inline Protection Profile, click Generate Config and
configure the following settings:
Go to Web Protection > Known Attacks > Signatures and edit the auto-attack…
entry. Change the Known Exploits, Generic Attacks and Bad Robot Actions to Alert
& Deny
To prevent those attacks, you will now modify the server policy to apply the web
protection profile generated from the Auto Learn report.
Go to Policy > Server Policy >Server Policy and edit the policy
WebServer_LB_Policy. From the Web Protection Profile drop down select the
automatically generated auto-attack… protection profile. Leave all other
parameters at their default values and click OK.
Next go to Auto Learn > Auto Learn Report> Auto Learn Report. Select the
checkbox for the existing report and click Clean Data to clear the auto learn report.
Run the nikto test again against the configured virtual IP.
Analyze the Attacks section of the auto learning report. You should observe that
there are no longer detected Known Exploits and Generic Attacks as indicated
below:
They have all been blocked by the configured auto-attack web protection profile.
PS: nikto tool can try different attacks every time you run it, which may cause new
attacks to be shown in the report. You might want to repeat executing it multiple
times to have better tests and consequently better reports.
Objectives
In this lab, you will perform a vulnerability assessment on the web server’s
application to comply with PCI DSS A6. All software should be up to date, including
all code libraries used by the application.
Go to Web Vulnerability Scan > Web Vulnerability Scan Profile. Click Create New
and configure the following parameters for your vulnerability assessment:
Name: web_scan
Hostname: http://10.0.1.31/dvwa
Scan: select all
Scan Mode: Enhanced Mode
Request Timeout 30
Delay Between Each Request 0
To define the Vulnerability Scan profile to use go to Web Vulnerability Scan > Web
Vulnerability Scan Policy and click Create new. Define the type of scan and the
format of the report as follows:
Name: wscan_policy
Type: Run Now
Profile: web_scan
Report Format: HTML, PDF
Click OK.
The scan should start automatically. However, if this is not the case, go to Web
Vulnerability Scan > Web Vulnerability Scan Policy then click on Start to start it
manually as indicated below:
Wait for the scan process to complete, then go to Web Vulnerability Scan > Scan
History to view the generated vulnerability scan report.
Click on the link to display the report in HTML format and analyze the results.
It takes some minutes to connect to the server and get all files. Check the
connection numbers of files copied.
Login to Webserver1 and delete one file from the path /var/www. Wait some
seconds and verify that FortiWeb detects the action and restores the file.
Open a terminal in the WebServer1 and verify that the file was restored.
For this Lab, you need to upload a XML file from a Third Party Vulnerability
scanner provided by the instructor.
You will see all the Rules and policies created based on the vulnerabilities
reported by Acunetix Vulnerability Scanner.
To erase all labs and shutdown the servers correctly, follow these steps: