FAQ
Why don't my back-end servers receive the virtual server IP address as the source IP?
When the operation mode is Reverse Proxy, the server pool members receive the IP address of the FortiWeb interface the connection uses. If the back-end servers need to know the IP address of the client where the request originated, configure a X-Forwarded-For rule for the appropriate profile. For details, see "Defining your proxies, clients, & X-headers" in FortiWeb Administration Guide.
Does an FTP server policy handle FTP, FTPS and SFTP traffic?
Until you configure an FTP server policy, FortiWeb will deny all FTP traffic.
You can configure an FTP server policy to handle FTP and FTPS traffic, but SFTP is not supported.
FTPS (also named as FTP-over-SSL) is based on SSL/TLS and actually requires a backend FTP server for the communication. SFTP (SSH File Transfer Protocol) is just a part of SSH. It's more like a file transfer client instead of a server service.
Why does blocking by XFF not work when private IP in XFF?
By default, XFF parsing will ignore private IP. If you do not want to ignore it, please set as follows:
FortiWeb # config waf x-forwarded-for
FortiWeb (x-forwarded-for) # edit test
FortiWeb (test) # set skip-private-original-ip disable
FortiWeb (test) # end
Will all IP addresses listed in the XFF (X-Forwarded-For) header be handled by WAF modules?
The general format of the field is:
X-Forwarded-For: client, proxy1, proxy2
In 7.0.1 and previous builds, only the left-most or the right-most IP address can be scanned and processed by WAF modules including IP Protection features and other features. You can select the option “IP Location in X-Header” accordingly as below.
That means, a request including header "X-Forwarded-FOR: A.A.A.A, B.B.B.B, C.C.C.C" will NOT be blocked if only B.B.B.B is added into a IP block list.
From 7.0.2, an option Block Using Full Scan is added thus WAF modules can scan and process the IP addresses in the middle of the XFF header. Currently only IP Reputation is supported, while more features will be added and listed here in future release.
When this option is enabled, IP Reputation will scan all IP addresses listed in the X-Forwarded-For header to match with the IPs in the categories.
Both IP Reputation policy and X-Forwarded-For rule should be linked to the Protection Profile for a Server Policy. Also, Use X-Header to Identify Original Client's IP and Block Using Original Client's IP should be enabled in the X-Forwarded-For rule.
For troubleshooting purpose, the following diagnose commands can be used:
# diagnose debug flow filter module-detail x-forward-for 7
# diagnose debug enable
> GET / HTTP/1.1
> Host: 10.33.33.1:81
> User-Agent: curl/7.83.1
> Accept: */*
> X-Forwarded-For: 1.2.3.4, 192.168.0.2, 10.33.33.3
[x forward for][INFO](x_forward_for_process-949): inside x_forward_for process
[x forward for][INFO](http_parse_x_forwarded_for-850): inside x_forward_for http parse
[x forward for][INFO](http_parse_orig_ip-673): inside x_forward_for parse original ip
[x forward for][DEBUG](http_parse_orig_ip-693): Skip = 0, location = 1, Value = [1.2.3.4,192.168.0.2,10.33.33.3], Unparsed value[1.2.3.4, 192.168.0.2, 10.33.33.3]
[x forward for][INFO](http_parse_orig_ip-732): Original ip = 10.33.33.3
[x forward for][INFO](http_parse_fullscan_ip-755): inside http_parse_fullscan_ip
[x forward for][DEBUG](http_parse_fullscan_ip-792): Skip = 0, location = 1, Value = [1.2.3.4,192.168.0.2,10.33.33.3,]
[x forward for][DEBUG](http_parse_fullscan_ip-817): ips from value cur: 1.2.3.4
[x forward for][DEBUG](http_parse_fullscan_ip-819): parse original: this ip list has : 1.2.3.4
[x forward for][DEBUG](http_parse_fullscan_ip-817): ips from value cur: 192.168.0.2
[x forward for][DEBUG](http_parse_fullscan_ip-819): parse original: this ip list has : 192.168.0.2
[x forward for][DEBUG](http_parse_fullscan_ip-817): ips from value cur: 10.33.33.3
[x forward for][DEBUG](http_parse_fullscan_ip-819): parse original: this ip list has : 10.33.33.3
[x forward for][INFO](x_forward_for_process-990): xff: after parse ip str: 10.33.33.3
[x forward for][INFO](set_original_ip-428): xff: set original ip str: 10.33.33.3
[x forward for][INFO](set_original_ip-435): during set_original_ip: original IP address = 10.33.33.3
[x forward for][INFO](set_original_ip-452): set_original_ip: Full Scan IP address = 1.2.3.4
[x forward for][INFO](set_original_ip-452): set_original_ip: Full Scan IP address = 192.168.0.2
[x forward for][INFO](set_original_ip-452): set_original_ip: Full Scan IP address = 10.33.33.3
Why doesn’t Protected Hostnames work as expected?
Protected Hostnames are used in a server policy to restrict requests to specific hostnames. FortiWeb 7.0.1 and previous builds support setting the exact hostname or using wildcards such as *.example.com to match the field Host: in HTTP header. Please note that only one wildcard is supported. If you enter multiple wildcards, matching of hostname will be unexpected.
From 7.0.2, Protected Hostname supports Ignore Port and Include Sub-Domain, and wildcard is still supported. Sub-Domain will be ignored if the Host: field in a request is an IPv4 or IPv6 address.
Below are examples to show whether a request will match the configured hostname.
|
Protected Hostname |
Enable Ignore Port |
Enable Include Sub-Domain |
Request Host |
Result |
|---|---|---|---|---|
| abc.example.com | No | No | abc.example.com:8080 | Not match |
| abc.example.com | Yes | No | abc.example.com:8080 | Match |
| abc.example.com | Yes | Yes | xyz.abc.example.com:8080 | Match |
| *example.com | No | No | abc.example.com | Match |
| example.com* | No | No | example.com:8080 | Match |
| example.com* | Yes | No | example.com:8080 | Match |
| *example.com* | No | No | abc.example.com:8080 | Not match |
| example.com:8080 | No | No | example.com:8080 | Match |
|
example.com:8080 |
Yes |
No |
example.com:8080 |
Not match |
The reason of the Not match cases is either of the following:
-
Only one wildcard is supported;
-
When Ignore Port is enabled, the port in the
Host:field of the incoming request will be removed, so it does not match the protected hostname configured.
If you encounter other mismatching issues, you can either check the attack log or run diagnose logs as below:
diagnose debug flow filter module-detail allow-hosts 7
diagnose debug enable
[Protected Hostnames][INFO](allow_host_process-742): protected hostname validation begin
[Protected Hostnames][INFO](http_host_check-495): Enter Function : http_host_check
[Protected Hostnames][INFO](http_host_check-520): Request Host value : try.fwbtestgslb.com:8333
[Protected Hostnames][INFO](http_host_check-521): Request Host len : 24
[Protected Hostnames][INFO](host_parse_ignore_port-440): Inside host_parse_ignore_port
[Protected Hostnames][INFO](host_parse_ignore_port-441): Request Host value : try.fwbtestgslb.com:8333
[Protected Hostnames][INFO](host_parse_ignore_port-482): ipv4 or domain host removed port: try.fwbtestgslb.com
[Protected Hostnames][INFO](http_host_check-557): Ignore port enabled
[Protected Hostnames][INFO](http_host_check-560): hoststr after ignore port trim: try.fwbtestgslb.com
[Protected Hostnames][INFO](http_host_check-561): hoststr len after ignore port trim: 19
[Protected Hostnames][INFO](http_host_check-568): Include subdomains enabled
[Protected Hostnames][INFO](host_parse_include_subdomains-298): Inside host_parse_include_subdomains
[Protected Hostnames][INFO](host_parse_include_subdomains-299): hoststr recieved: try.fwbtestgslb.com
[Protected Hostnames][INFO](host_parse_include_subdomains-313): single request host subdom: try
[Protected Hostnames][INFO](host_parse_include_subdomains-313): single request host subdom: fwbtestgslb
[Protected Hostnames][INFO](host_parse_include_subdomains-313): single request host subdom: com
[Protected Hostnames][INFO](host_parse_include_subdomains-319): longest section is : 11
[Protected Hostnames][INFO](host_parse_include_subdomains-326): single fwb host subdom: *
[Protected Hostnames][INFO](host_parse_include_subdomains-326): single fwb host subdom: fwbtestgslb
[Protected Hostnames][INFO](host_parse_include_subdomains-326): single fwb host subdom: com*
[Protected Hostnames][INFO](host_parse_include_subdomains-331): section count of request host: 3, section count of fwb host: 3
[Protected Hostnames][INFO](http_host_check-570): hoststr after subdomains trim: try.fwbtestgslb.com
[Protected Hostnames][INFO](http_host_check-571): hoststr len after subdomains trim: 19
[Protected Hostnames][INFO](http_host_check-579): Protected Hostname host : *.fwbtestgslb.com*
[Protected Hostnames][INFO](http_host_check-584): url case disabled
[Protected Hostnames][INFO](http_host_check-586): found '*' at the begining of Protected Hostname host
[Protected Hostnames][INFO](http_host_check-588): Request host after manipulation: y.fwbtestgslb.com
[Protected Hostnames][INFO](http_host_check-703): Request host did not matched a Protected Hostname, perform default action
Which WAF modules will be skipped if the Allow List is matched?
When enabled, allow-listed items will skip the subsequent scans after the Global Object allow list. Please check the scan sequence of the Global Object Allow List in "Sequence of scans" in FortiWeb Administration Guide, or "What’s the sequence of WAF module scans in 7.0.0" in FAQ.
When the Allow List is matched, the following modules will be affected:
| Allow Name | Check Position | Affected Modules |
|---|---|---|
| Allow URL | Global white list | URL Access Rule will be checked; Modules after URL Access will be skipped |
| Allow Parameter |
|
When these four modules check parameters, parameters in Allow Parameter list will be skipped. |
| Allow Cookie |
|
When these three modules check or process cookies, cookies in Allow Cookie list will be skipped |
| Allow Header |
|
URL Access Rule will be checked; When Syntax based detection checks headers, headers in Allow Cookie list will be skipped |
The scan sequence of the modules mentioned above is:
Global White List -> URL Access -> Parameter Validation -> Signature -> Syntax Based Detection -> Cookie Security -> ML-based Anomaly Detection
The following parameters or cookies are by default included in Allow List if their corresponding modules are enabled. For example, the request with cookiesession1 will match the Allow list and be exempted from the subsequent scans only when Client Management is enabled.
|
Name |
Type |
Owner Module |
|---|---|---|
| cookiesession1 | cookie | Client management |
| cookiesession3 | cookie | Site Publish |
| cookiesession6 | cookie | Robot Check |
| cookiesession8341 | parameter | RBE(bot_reco_process is used by 5 modules) |
| redirect491 | parameter | Custom page |
| rewrite491 | parameter | Custom page/Url Rewrite |
| reason747sha | parameter | Custom page |
How do Global Allow List and Policy Based Allow List work?
On 7.0.1 and previous builds, only Global Allow List is supported, while on 7.0.2 and newer builds, FortiWeb also supports Policy Based Allow List.
Predefined Global or Predefined Policy Based Allow List have the same items updated from FortiGuard FortiWeb Security Service. The difference is that Predefined Global Allow List can be enabled or disabled, while Predefined Policy Based List cannot be disabled.
You can either enable or disable some Predefined Global Allow List that updated from FortiGuard FortiWeb Security Service, or create custom list to allow your own URLs, header field, cookies and parameters on the Custom Global Allow List tab in Server Objects > Global > Global Allow List. Global allow list applies to all server policies in all ADOMs.
As for Policy based Allow List, you can reference the predefined list or customized list (via Server Objects > Global > Global Allow List > Policy Based Allow List) in a server policy. When the traffic arrives at this server policy, it will be screened only according to the server policy based allow list instead of the global one.
By default, Global Allow List takes effect. When Allow List is set for a server-policy, the policy-based Allow List will take effect instead of the Global Allow List.
Why is the cookiesession1 generated by Client Management persistent cookie?
In inline deployment mode, when a client accesses a web application for the first time, FortiWeb inserts a cookie named “cookiesession1” into the client's browser. If the client carries the inserted cookie in subsequent access, FortiWeb tracks the client by this cookie; otherwise, FortiWeb tracks the client by the client's source IP.
To do user tracking more accurately, “cookiesession1” is set as a persistent cookie with one year validity by default. FortiWeb will identify it as the same user even if the client browser is closed and opened again.
On 7.0.2, FortiWeb provides an option to set “cookiesession1” as a session cookie. If you think that a persistent cookie introduces a threat to your application, they can enable this option, or disable this cookie altogether by disabling Client Management in the web protection profile.
config waf web-protection-profile inline-protection
edit <web-protection-profile name>
set http-session-cookie enable
next
end
you can enable diagnose debug flow filter module-detail client-management 7 to double check which type of cookie is applied in the web-protection-profile.
When http-session-cookie is disabled:
[client-manage][INFO](insert_wafsid:1419): [Note] it's persistent cookiesession1
When http-session-cookie is enabled:
[client-manage][INFO](insert_wafsid:1417): [Note] it's session level cookiesession1