So

Module 5 – Webserver Protection

Supportability guide

Version 20.0 Ÿ July 2024

Module 5 – Webserver Protection

Course Agenda
• Module 1: Architecture and Troubleshooting basics
• Module 2: Network Protection
• Module 3: Web Protection
• Module 4: Email Protection
• Module 5: Webserver Protection
• Module 6: Authentication
• Module 7: Synchronized Security and Central Management
• Module 8: Site-to-Site and Remote connections
• Module 9: Wireless Protection
• Module 10: High Availability
• Module 11: XGS Hardware and Troubleshooting

Module 1: Architecture and Troubleshooting basics

Module 2: Network Protection
Module 3: Web Protection
Module 4: Email Protection
Module 5: Webserver Protection
Module 6: Authentication
Module 7: Synchronized Security and Central Management
Module 8: Site-to-Site and Remote connections
Module 9: Wireless Protection
Module 10: High Availability
Module 11: XGS Hardware and Troubleshooting

Page 2 of 69
Module 5 – Webserver Protection

Module Objectives
Once you complete this module you will be able to:
ü Identify the function of web server protection features
ü Identify the relevant information for troubleshooting issues with Webserver
Protection
ü Troubleshoot and resolve problems related to:
ü URL hardening
ü Form hardening
ü Common Threat Filter
ü Reverse authentication
ü Webserver outage
ü WAF certificate
ü SlowHTTP Protection

Once you complete this module you will be able to:

• Identify the function of web server protection features
• Identify the relevant information for troubleshooting issues with Webserver Protection
• Troubleshoot and resolve problems related to:
o URL hardening
o Form hardening
o Common Threat Filter
o Reverse authentication
o Webserver outage
o WAF certificate
o SlowHTTP Protection

Page 3 of 69
Module 5 – Webserver Protection

Reverse proxy and Protection features

Page 4 of 69
Module 5 – Webserver Protection

Reverse proxy scenario

External interface: Real Webserver
31.222.175.174 IP address: 172.16.1.10
Hostname: lab- Hostname: lab-server.lab.internal
Legitimate request gw1.lab.external
Running IIS website with authentication
Running a separate webmail service

SQL Injection, XSS …

Sophos Firewall
configure as reverse
proxy

Remote File Inclusion

WAN LAN
Malware upload
Virtual Web Server Real Web Server
Ping Sweep Sophos Firewall

Reverse proxy scenario

This is a typical WAF environment and our troubleshooting in this module is based on that.
In this scenario, Sophos Firewall protects a real webserver that has an IP address of 31.222.175.174, and
hostname lab-server.lab.internal.
The Sophos Firewall has an external IP address of 192.168.1.100 and public hostname lab-gw1.lab.external.
The real webserver is running IIS website with authentication, and a separate webmail service.
[Click]
The Reverse Proxy blocks attacks

SQL Injection
A type of injection attack that execute malicious SQL statements. It is the vulnerability that results when
you give an attacker the ability to influence the Structured Query Language (SQL) queries that an
application passes to a back-end database. By being able to influence what is passed to the database, the
attacker can leverage the syntax and capabilities of SQL itself, as well as the power and flexibility of
supporting database functionality and operating system functionality available to the database. SQL
injection is not a vulnerability that exclusively affects Web applications; any code that accepts input from
an untrusted source and then uses that input to form dynamic SQL statements could be vulnerable (e.g.
“fat client” applications in a client/server architecture aka customize application like those created using
either Java or Visual Studio).”

Page 5 of 69
Module 5 – Webserver Protection

XSS or Cross-Site Scripting

Cross Site Scripting (XSS). Occurs when unfiltered data is accepted by the Web application and then
returned as HTML/JavaScript to the target’s browser, which then parses the content as if it was a valid part
of the request’s results. Common abuses are session hijacking and site defacement.

Remote File Inclusion

A crafted attack which targets web application vulnerabilities by referencing external scripts. The results is
to upload or download malware to the target web server. An improperly programmed Web server can be
tricked into including code or data from remote servers. This gives an attacker the ability to execute his
own code on the Web server, which can grant him access to the file system and more.

Malware
Malicious software like virus, worm, ransomware, worm and spyware

Ping Sweep
A technique use to identify the hosts id and IP address to determine if they are active

Page 6 of 69
Module 5 – Webserver Protection

OWASP ModSecurity Core Rule Set

OWASP ModSecurity Core Rule Set 2.2.7 (up to v17.5) OWASP ModSecurity Core Rule Set 3.1 (from v18)

Rigid filtering Filter strength with four levels of filtering.

Rigid filtering setting migrates to Level 1 (Most permissive)
setting and can be set up to Level 4 (Most restrictive)
Protocol violations Protocol enforcement
Protocol anomalies
Request limits
HTTP policy
Generic attacks Application attacks
Tight security
Bad robots Scanner detection

Outbound Data leakages

OWASP ModSecurity Core Rule Set

• SFOS XG has implemented OWASP ModSecurity Core Rule Set 3.1( XG v18) ( Earlier version was 2.2.7 (XG
v17) ) in the categories and settings of web server rules and protection policies.
• Sophos Firewall has merged some protection categories into a single category, mapped filter rules to
new rule IDs, and introduced filtering strength levels.
• OWASP 3.1 brings completely new rules and a new rule engine so with this new version we decided to
remove the old up2date WAF code and provide any future OWASP updates that there may be in MR's or
major releases, so we have removed WAF Pattern update as well.

Note: If a category was turned on earlier, the new category into which it's merged is turned on during
migration. For example, if a pre-migration policy has Protocol violations turned on and Protocol anomalies
turned off, the post-migration category Protocol enforcement, which contains both categories, is turned on.

Page 7 of 69
Module 5 – Webserver Protection

Webserver Protection Firewall rule

Configuration

Webserver Protection Firewall rule

Configuration

WAF can be configured with action Protect with Webserver Protection from firewall rule.

Additionally, we are now supporting Wildcard domain for the domain configuration

You can use the wildcard *. at the start of a domain name only. Example: *.example.com. A single WAF
policy supports multiple wildcard domains. Virtual web servers with wildcard domains are only matched
when there are no virtual web servers with specific domains configured. Example: A client request to the
domain, test.example.com, will match with test.example.com before it matches with *.example.com before
matching with *.com.

Page 8 of 69
Module 5 – Webserver Protection

Protection Features
Antivirus Antivirus

Threat Filters

Cookie Signing

URL Hardening

Form Hardening

Reputation Filtering

Web Server Authentication

Protection Features
Antivirus

Sophos’ Web Server Protection uses antivirus to scan both uploads and downloads with both scan engines.
This protects the servers from malicious code uploaded, and ensure users are protected as well should the
server are compromised or infected.

Antivirus scanning is configured using Sophos, Avira or both scan engines. In the event of a scanning issue
such as generating false positive or sluggish performance, scanning is switch from dual to single engine.
(either Avira or Sophos).

Sophos Firewall scan files as they are uploaded to the web server, downloaded from the web server or
both. This not only protect the web server, but prevents the spread of malware.

Block unscannable content such as encypted or corrupt files.

You can limit the file size of the Sophos Firewall will scan. You may choose to do this if the web service
handles large non-executable data files.

Page 9 of 69
Module 5 – Webserver Protection

Protection Features
Antivirus Threat Filters

Threat Filters

Cookie Signing

URL Hardening

Form Hardening

Reputation Filtering

Web Server Authentication

Protection Features
Threat filter

Web Server Protection uses scan engine and attack pattern to filter against common threats and attacks.
The patterns are kept current as part of the Sophos Firewall automatic pattern update. Unlike many
products which require extensive knowledge, Sophos’ protection is kept simple allowing administrator to
select which protection methods they want enable without dealing with pages of complex patterns and
configuration screens.
Categories of rules are enabled and disabled, depending on the type of web server being protected.

Filter strength
Level 1 (Most permissive): Use this for deployments related to many websites and applications, and for
standard security requirements. It generates minimal false positives. It's the default setting.
Level 2: Provides additional protection, such as from regexp-based SQL and XSS injection, and checks extra
keywords for code injections. Use this for better security coverage and for deployments with higher
security requirements. It generates additional false positives that you need to handle.
Level 3: Turns on additional rules and keyword lists. It also sets additional limits on the use of special
characters. Use this for higher security requirements and based on your experience in handling false
positives.

Page 10 of 69
Module 5 – Webserver Protection

Level 4 (Most restrictive): Places additional restrictions on special characters. Use this for deployments
with very high security requirements. It generates a high level of false positives. We recommend that you
troubleshoot these before you make the site live.
Level 1 isn't logged. Levels 2 and higher are logged to /log/reverseproxy.log.
To check the reverse proxy log, sign in with the command line interface.

Application attacks
Performs tight security checks on requests, such as attempts to traverse prohibited paths.
Sophos Firewall also searches for attempted command executions common to most attacks. After
breaching a web server, an attacker usually tries to execute commands on the server like expanding
privileges or manipulating data stores. Checking for these post-breach execution attempts allows Sophos
Firewall to detect attacks that may go unnoticed, for example, attackers targeting a vulnerable service after
gaining legitimate access.

SQL injection attacks

Checks for embedded SQL commands and escape characters in request arguments. Most attacks on web
servers target input fields that can be used to direct embedded SQL commands to the database.

XSS attacks
Checks for embedded script tags and code in request arguments.Typical cross-site scripting attacks aim at
injecting script code into input fields on a target web server.

Protocol enforcement
Enforces adherence to RFC standards for HTTP and HTTPS protocols. Violating these standards usually
indicates malicious intent.
Searches for common usage patterns. The absence of such patterns often indicates malicious requests.
These patterns include HTTP headers, such as Host and User-Agent.
Enforces reasonable limits on the number and range of request arguments. Overloading request arguments
is a typical attack vector.
Narrows the allowed usage of HTTP protocol. Web browsers typically use only a limited subset of the
possible HTTP options. Disallowing the rarely used options prevents attacks that use these options.

Scanner detection
Checks for usage patterns characteristic of bots and crawlers. When you deny them access, possible
vulnerabilities on your web servers are less likely to be discovered.

Data leakages

Page 11 of 69
Module 5 – Webserver Protection

Prevents web servers from leaking information to the client. This includes error messages sent by servers,
which attackers can use to gather sensitive information or detect specific vulnerabilities.

Protection Features
Antivirus Cookie Signing

Threat Filters Sign cookie

Cookie Signing Cookie Cookie

URL Hardening
Check cookie
Form Hardening Cookie
REJECTED
Reputation Filtering

Web Server Authentication

Protection Features
Cookie signing

Cookie signing is a feature that prevent cookies from maliciously manipulated. This is by using a pair of
cookies or called: Cookie Pair. This works when the Web Server sets a cookie, a 2nd cookie is paired which
resulted in having a Hash built from the Primary Cookie name, its value and secret. The secret is only
known by the Sophos Firewall. If the request cannot provide the correct cookie pair, its construed as a
possible manipulation and the cookie is dropped.

Page 12 of 69
Module 5 – Webserver Protection

Protection Features
Antivirus URL Hardening

Threat Filters

Cookie Signing

URL Hardening

Form Hardening http://www.sophos.com/products Allowed

http://www.sophos.com/products/xg-firewall Blocked

Reputation Filtering http://www.sophos.com/file.php?id=1234 Unsigned

http://www.sophos.com/file.php?ah-i=shjo73v39)3y Signed
Web Server Authentication

Protection Features
URL Hardening

Static URL Hardening protects against URL rewriting by signing all the URLs in the page that served. If a URL
requested that is NOT signed, access is denied.

This only works with static URLs. URLs that are dynamically generated in the client-side (for example by
JavaScript), will not be signed. In this case, exclusions are created.
Note: Exclusions are covered later in this module.

Static URL hardening affects all files with a HTTP content type of text/* or *xml*, where * is a wildcard.
Ensure other file types, e.g. binary files, have the correct HTTP content type, otherwise they may get
corrupted by the URL hardening feature.

Entry URLs are the unsigned URLs that can be requested.

Page 13 of 69
Module 5 – Webserver Protection

Protection Features
Antivirus Form Hardening

Threat Filters

Cookie Signing

URL Hardening

Form Hardening
• Stops form attacks via manipulation
• Enforces valid answers
Reputation Filtering
• Tamper proof
Web Server Authentication

Protection Features
Form Hardening

Form hardening protects against web from rewrirting. It saves the web form original structure and signs
it. If the form structure changed and submitted to Sophos Firewall, the request will be rejected. The
Sophos Firewall also inspects and validates the information submitted by visitors using the forms on your
websites. This stops malicious users from passing invalid data which damage or manipulate your server.

Page 14 of 69
Module 5 – Webserver Protection

Protection Features
Antivirus Reputation Filtering

Threat Filters

Cookie Signing

URL Hardening
• RBL - Reputation Based List classification with:
Form Hardening Sophos labs, and
MaxMind’s GeoIP classification services.
Reputation Filtering
• SXL – Sophos Extensible Lists from
SORBS (V18-V19-V20), and Cyren (v17).
Web Server Authentication

Protection Features
Reputation Filtering

Blocking clients with bad reputation is done using remote lookups. This can be skipped and instead, use
GEOIP-baesd classification which is faster.
For RBLs, Sophos Firewall uses Sophos Extensible List (SXL) and SORBS in v18 which was Cyren earlier till
v17.
For GeoIP, it uses Maxmind. Sophos Firewall blocks clients that belong to the A1 (anonymous proxies or
VPN services) and A2 (satellite ISP) classifications.

Page 15 of 69
Module 5 – Webserver Protection

Protection Features
Antivirus Web Server Authentication

Threat Filters
Attacker has to successfully authenticate
Cookie Signing before getting any access to the protected
web server
URL Hardening

Form Hardening Protected

Reputation Filtering Internet Web Server

Sophos Firewall
Attacker
Web Server Authentication

Protection Features
Web Server Authentication

Sophos Firewall can act as an authentication proxy, which adds another protection layer between potential
attackers and web services.

Uses are presented with either a login form or basic authentication. Sophos Firewall authenticate the user,
and if credentials are correct, pass their requests through the web server.

As an option, Sophos Firewall can pass the users credentials through the web server to log them to the web
service. This is only done where the web service supports basic authentication.

Page 16 of 69
Module 5 – Webserver Protection

Configuration process
Best Practice

Update the Test the

configuration configuration

Review the log file

Place the Protection Policy in
monitor mode while refining the
configuration

Configuration process
Best Practice

Configure the firewall profile for highest security

Before we look at how to troubleshoot issues, it is important to understand the configuration process for
the web application firewall.

When initially creating a firewall profile for a web service you should start by configuring it to the highest
level of security suitable for the environment.
[Click]
You will then need to test the configuration,
[Click]
review the log file,
[Click]
and update the configuration.
[Click]

Page 17 of 69
Module 5 – Webserver Protection

Repeat these steps until the web service works without triggering rules in the firewall profile. By using
monitor mode, it allows Sophos Firewall to NOT reject or block traffic which potentially can affect access to
the web server located in the production environment.

As part of this module we will look at what happens when rules are triggered, what you will see in the log,
and where the configuration needs to be updated to resolve the issue.

Page 18 of 69
Module 5 – Webserver Protection

v20
WAF Enhancements

WAF Enhancements

Page 19 of 69
Module 5 – Webserver Protection

WAF Improvements Highlights

• Custom Cipher configuration
• GeoIP support
• HSTS and X-Content-Type-Options header enforcement
• Interface enable/disable Behaviour

Page 20 of 69
Module 5 – Webserver Protection

TLS Version Settings

V19.5

V20

TLS version settings and customer cipher suites can be configured through the General settings page. If
custom is selected, the customer must follow OpenSSL syntax and help can be found in the “Syntax” link:

Customers can freely use the predefined options available as previously but now provides even more
control for business compliance.

Validated in the new table: tblwaftlssetting

For a full list of the table breakdown, please refer to the handouts

• id: int4 (PRIMARY KEY)

• label: varchar(50) (NOT NULL UNIQUE)
• protocol: varchar(50)
• ciphersuite: varchar(1000)
•the table will be preloaded with the following records:
id
label
protocol
ciphersuite

Page 21 of 69
Module 5 – Webserver Protection

0
Language.Custom
NULL
NULL
1
Language.tls_v1_or_higher
all -SSLv3
HIGH:!aNULL:!eNULL:!EXPORT:!DES:!RC4:!3DES:!MD5:!PSK:!EXP:!NULL:!ADH
2
Language.tls_v1_1_or_higher
all -SSLv3 -TLSv1
HIGH:!aNULL:!eNULL:!EXPORT:!DES:!RC4:!3DES:!MD5:!PSK:!EXP:!NULL:!ADH
3
Language.tls_v1_2_or_higher
-all +TLSv1.2
ECDH+AESGCM:DH+AESGCM:ECDH+AES256:DH+AES256:ECDH+AES128:DH+AES:RSA+AESG
CM:RSA+AES:!aNULL:!MD5:!DSS
4
Language.tls_v1_2_secure
-all +TLSv1.2
ECDHE-ECDSA-AES128-GCM-SHA256:ECDHE-RSA-AES128-GCM-SHA256:ECDHE-ECDSA-
AES256-GCM-SHA384:ECDHE-RSA-AES256-GCM-SHA384:ECDHE-ECDSA-CHACHA20-
POLY1305:ECDHE-RSA-CHACHA20-POLY1305:DHE-RSA-AES128-GCM-SHA256:DHE-RSA-
AES256-GCM-SHA384

Page 22 of 69
Module 5 – Webserver Protection

TLS 1.2 options

Let's reevaluate both TLS 1.2 cipher suite options considering each cipher:
•TLS 1.2 wide compatibility:
• ECDH+AESGCM: This cipher suite specifies the use of Elliptic Curve Diffie-Hellman for key
exchange and AES in Galois/Counter Mode for encryption.
• ECDH+AES256: ECDH key exchange with AES-256 encryption.
• ECDH+AES128: ECDH key exchange with AES-128 encryption.
• RSA+AESGCM: RSA key exchange with AES in Galois/Counter Mode.
• RSA+AES: RSA key exchange with AES encryption.
• !aNULL: Excludes anonymous (aNULL) ciphers.
• !MD5: Excludes ciphers using the MD5 hash algorithm.
• !DSS: Excludes Digital Signature Standard (DSS) ciphers.
• !DHE: Excludes ephemeral Diffie-Hellman (DHE) ciphers.
•TLS 1.2 strict:
• ECDHE-ECDSA-AES128-GCM-SHA256: Ephemeral Elliptic Curve Diffie-Hellman key
exchange with ECDSA authentication and AES-128 GCM encryption.
• ECDHE-RSA-AES128-GCM-SHA256: Ephemeral Elliptic Curve Diffie-Hellman key exchange
with RSA authentication and AES-128 GCM encryption.
• ECDHE-ECDSA-AES256-GCM-SHA384: Ephemeral Elliptic Curve Diffie-Hellman key
exchange with ECDSA authentication and AES-256 GCM encryption.
• ECDHE-RSA-AES256-GCM-SHA384: Ephemeral Elliptic Curve Diffie-Hellman key exchange
with RSA authentication and AES-256 GCM encryption.
• ECDHE-ECDSA-CHACHA20-POLY1305: Ephemeral Elliptic Curve Diffie-Hellman key
exchange with ECDSA authentication and ChaCha20-Poly1305 encryption.
• ECDHE-RSA-CHACHA20-POLY1305: Ephemeral Elliptic Curve Diffie-Hellman key
exchange with RSA authentication and ChaCha20-Poly1305 encryption.

Page 23 of 69
Module 5 – Webserver Protection

The key difference between these two options is that the "wide compatibility" option includes RSA key
exchange ciphers and excludes some weak or less secure options like MD5, DSS, and DHE. The "strict"
option focuses on modern and strong ephemeral ECDHE key exchange ciphers.
In summary, the "wide compatibility" option is more inclusive of various cipher suites, including those with
RSA and ECDH key exchanges, making it better suited for environments where compatibility with older
systems is a concern.

Page 24 of 69
Module 5 – Webserver Protection

TLS 1.3 and Custom Cipher Suites

TLS 1.3 introduced several improvements over TLS 1.2, including the ciphersuites used for encryption and
authentication. The ciphersuites you mentioned (TLS_AES_128_GCM_SHA256,
TLS_AES_256_GCM_SHA384, and TLS_CHACHA20_POLY1305_SHA256) are considered more secure
and efficient than their TLS 1.2 counterparts. Here's why they are better:

•Stronger Encryption Algorithms:

• TLS_AES_128_GCM_SHA256: This ciphersuite uses the Advanced Encryption Standard
(AES) with a 128-bit key in Galois/Counter Mode (GCM) for encryption. AES-128 is a strong
symmetric encryption algorithm, and GCM provides both encryption and authentication,
making it a popular and secure choice.
• TLS_AES_256_GCM_SHA384: This ciphersuite uses AES with a 256-bit key in GCM mode.
AES-256 provides a higher level of security due to the longer key length, making it resistant to
various attacks.
• TLS_CHACHA20_POLY1305_SHA256: ChaCha20 is a stream cipher, and Poly1305 is a
message authentication code. This combination provides a high level of security, and it is often
considered more secure and efficient than older ciphers, especially in resource-constrained
environments. The use of ChaCha20-Poly1305 is considered a significant security improvement
over TLS 1.2.

•Removal of Weaker Ciphers: TLS 1.3 has removed several older and weaker ciphersuites that were
available in TLS 1.2. This means that there are fewer options for attackers to try to exploit vulnerabilities in
weaker ciphers.

Page 25 of 69
Module 5 – Webserver Protection

•Perfect Forward Secrecy (PFS): All ciphersuites in TLS 1.3 provide PFS by default, ensuring that even if
an attacker records encrypted traffic and obtains the server's private key in the future, they cannot decrypt
past communications.

•Reduced Handshake Complexity: TLS 1.3 streamlines the handshake process, reducing the attack surface
and making it more difficult for attackers to intercept and manipulate the handshake.

•Improved Security Against Known Attacks: TLS 1.3 has incorporated lessons learned from previous
TLS versions and known attacks, making it more resilient to attacks such as BEAST, POODLE, and
CRIME, which could affect TLS 1.2.

•Increased Use of AEAD Ciphers: TLS 1.3 predominantly uses Authenticated Encryption with Associated
Data (AEAD) ciphers, which combine encryption and authentication in a more secure manner, reducing the
risk of ciphertext manipulation.
In summary, the ciphersuites in TLS 1.3 are considered more secure than those in TLS 1.2 due to stronger
encryption algorithms, the removal of weaker ciphers, improved handshake security, and other
enhancements that have been made based on security research and lessons learned from past TLS versions.
Upgrading to TLS 1.3 is generally recommended to benefit from these security improvements.

Lastly, and most importantly, with v20, customers have now the option to select 'Custom' settings for TLS,
allowing them to tailor their choice of ciphers to match their specific requirements and their organization's
security policies. The custom TLS option provides significant flexibility; however, customers should be
mindful that they are required to adhere to a specific syntax when configuring these parameters. Detailed
documentation for this syntax can be found here

Page 26 of 69
Module 5 – Webserver Protection

HSTS and MIME-type Sniffing

• HSTS – Strict Transport Security,
Ensures the WAF is only accessible using HTTPS
by adding this header:
o Strict-Transport-Security: max-age=31536000;
include SubDomains; preload-type detection code

• MIME-type sniffing protection,

instructs the browser to use MIME type by adding the
header:
o X-Content-Type-Options: nosniff

• Ensures the browser doesn’t run a

MIME-type detection code

HSTS ensures that all connections being made, without needing the need to add http:// or https:// URLs. If
the browser knows HSTS is enabled, it will always use https:// for the connection, even if http:// is specified
in a link or manually typed out. This setting includes all subdomains.

With the MIME-type no sniff header, this helps avoid having your website being compromised by an
attacker by protecting against MIME type sniffing attacks. This ensures the browser always uses the MIME
type declared rather than trying to determine the type which potentially could have been manipulated.

The "X-Content-Type-Options: nosniff" header indeed prevents browsers from running MIME-type
detection code. This is a security feature that's beneficial for the following reasons:
•Reducing Security Risks: By disabling MIME-type sniffing, the header ensures that browsers won't
attempt to interpret content in a way that might be manipulated by malicious actors. For example, it helps
prevent potential vulnerabilities where an attacker tricks a browser into executing a script or rendering
content as a different type than intended.
•Content Integrity: It helps maintain the integrity and security of the content served by a web server. By
strictly following the declared content type, browsers are less likely to misinterpret or mishandle data.
•Consistency: The header enforces consistency and predictability in how browsers handle content types,
making it less likely that a browser will try to "guess" the type of content.
In essence, "X-Content-Type-Options: nosniff" is a security measure that promotes safer and more
predictable handling of content types, reducing the risk of certain web-based attacks and vulnerabilities.

Page 27 of 69
Module 5 – Webserver Protection

These can be validated in the browser’s network developer tools and analyzing the headers from a client
request.

Page 28 of 69
Module 5 – Webserver Protection

Geo IP

The new GeoIP feature allows customers to block WAF requests based on the country of origin, the pre-
existing country groups can be utilized under the “Blocked countries” section.

Page 29 of 69
Module 5 – Webserver Protection

GeoIP - Troubleshooting
• Uses same maxmind DB as all other country services
show country-host ip2country ipaddress

• 403 returned with no reason

• reverseproxy.log
Example log of rejection due to IP,
[authz_core:error]
[Thu Oct 12 19:16:26.336457 2023] [authz_core:error] [pid 15909:tid 139658461681408] [client
108.180.32.247:51642] AH01630: client denied by server configuration:
proxy:balancer://dc051c7d4ca9767ab61e86fa186fa151/
[Thu Oct 12 19:16:26.336298 2023] timestamp="1697138186" srcip="108.180.32.247" localip="10.1.1.4" user="-"
method="GET" statuscode="403" reason="-" extra="-" exceptions="-" duration="269" url="/"
server="ryxgv18.eastus.cloudapp.azure.com" referer="-" cookie="-" set-cookie="-" recvbytes="474"
sentbytes="401" protocol="HTTP/1.1" ctype="text/html" uagent="Mozilla/5.0 (Windows NT 10.0; Win64; x64)
AppleWebKit/537.36 (KHTML, like Gecko) Chrome/117.0.0.0 Safari/537.36" querystring="" websocket_scheme="-"
websocket_protocol="-" websocket_key="-" websocket_version="-" ruleid="30"
[Thu Oct 12 19:16:26.446394 2023] [authz_core:error] [pid 15909:tid 139658461681408] [client
108.180.32.247:51642] AH01630: client denied by server configuration:
proxy:balancer://dc051c7d4ca9767ab61e86fa186fa151/favicon.ico, referer:
http://ryxgv18.eastus.cloudapp.azure.com/

The maxmind DB for country definitions which is already used for other firewall rules and features is also
utilized. Client IPs can be validated with the “Show country-host ip2country ipaddres” command from the
device console.

The same logging is used for all access permission settings (pre v20) and will display as a “authz_core:error”
in the reverseproxy.log. It then specifies the IP origin, as there is no differentiation between country
blocking and the standard “Allowed client networks” section this setting will need to be verified manually.

Page 30 of 69
Module 5 – Webserver Protection

GeoIP
# cat /cfs/waf/reverseproxy.conf
KeepAlive On
ServerName "localhost"
Listen 10.1.1.4:80 http
<VirtualHost 10.1.1.4:80>
ServerName "ryxgv18.eastus.cloudapp.azure.com"
SSLProxyEngine On
RequestHeader set X-Forwarded-Proto http
DocumentRoot "/sdisk/waffiles/c2028878b4bd360a21a0101b4bc4ca21"
SetEnv proxy-initial-not-pooled
SetEnvIfExpr true RuleID=30
ProxyQosIpsPolicyId 1
ProxyQosFirewallRuleId 30
<Proxy balancer://dc051c7d4ca9767ab61e86fa186fa151>
BalancerMember http://1.2.3.4 status=-SE timeout=300
</Proxy>
<Location "/">
SetEnv proxy-aside-c
ProxyPass "balancer://dc051c7d4ca9767ab61e86fa186fa151/" lbmetho
d=bybusyness
ProxyPassReverse "http://1.2.3.4:80/"
ProxyPassReverse "http://1.2.3.4/"
SetOutputFilter DEFLATE
SetEnvIfExpr "reqenv('MM_COUNTRY_CODE') == 'CA'" BlockCountry_1
<RequireAll>
Require all granted
Require not env BlockCountry_1
</RequireAll>
</Location>
</VirtualHost>
# Start: 1697139193.44145
# Stop: 1697139199.38022
# Time: 5.9387788772583

In this example we can see that Canada was selected as a blocked country through the reverseproxy.conf
file which is a new line added whenever at least one country block exists.

The following tables will be used for this new feature:

tblwafblockcountries
tblwaflocation (new column: block_unknown_country)

Page 31 of 69
Module 5 – Webserver Protection

WAF – Interface Enable/Disable behaviour

• When an interface is disabled where WAF was bound to,
the apache service will stop logging.
• Validate the interface it is bound to as “enabled”
• Polled every 60 seconds (some delay after disabling interface)

/log/reverseproxy.log
AH00526: Syntax error on line 3 of /cfs/waf/reverseproxy.conf:
Invalid address or port
# cat /cfs/waf/reverseproxy.conf
KeepAlive On
ServerName "localhost"
Listen :80 http
# Start: 1697140051.9251
# Stop: 1697140056.22354
# Time: 4.29843688011169

In the event a WAF rule is created and bound to an interface, but that interface is disabled. The firewall will
not run the apache service as seen in the reverseproxy.conf file for the specific waf instance. As that change
is made the reverseproxy.log will also display the interface is no longer found. As polling occurs every 60
seconds this message may repeat until the next polling occurs

Page 32 of 69
Module 5 – Webserver Protection

Reverse proxy troubleshooting

Page 33 of 69
Module 5 – Webserver Protection

Troubleshooting WAF
Service and Log file
#service waf:start/stop/restart/status -ds nosync

# service -S | grep WAF

WAF RUNNING

# tail –f /log/reverseproxy.log
[Sun Jan 26 22:09:29.001072 2020] [security2:notice] [pid 30434:tid 140128167969216]
ModSecurity: APR compiled version="1.5.2"; loaded version="1.5.2"
[Sun Jan 26 22:09:29.001079 2020] [security2:notice] [pid 30434:tid 140128167969216]
ModSecurity: PCRE compiled version="8.43 "; loaded version="8.43 2019-02-23”

[Sun Jan 26 22:09:29.045931 2020] [slotmem_shm:debug] [pid 30537:tid 140128167969216]

mod_slotmem_shm.c(364): AH02602: create didn't find /tmp/slotmem-shm-pb8f4a755.shm in
global list
[Sun Jan 26 22:09:29.045934 2020] [slotmem_shm:debug] [pid 30537:tid 140128167969216]
mod_slotmem_shm.c(374): AH02300: create /tmp/slotmem-shm-pb8f4a755.shm: 608/6

Troubleshooting WAF
Service and Log files

These command and logs are useful while troubleshooting WAF related issues. Live logs are available on
both GUI and advance shell access.
To verify advanced logs, login to advance shell access and verify below log file:
/log/reverseproxy.log

By default, log level is set as notice [security2:notice] and if we enable debug then we will get debug logs
for the waf [slotmem_shm:debug].
You can use various Linux utilities to view the log file e.g. tail.

WAF configuration database entries

#psql -U nobody -d corporate -c "select * from tblwafadvanceconfig"

cookiesignkey | urlhardeningsignkey | formhardening_secret | status | reverse_proxy | mpm_mode |
max_processes | max_threads_per_process | min_spare_threads | max_spare_threads |
min_spare_processes | max_spare_processes | port | manualmode | patternversion |

Page 34 of 69
Module 5 – Webserver Protection

aua_refresh_enabled | aua_refresh_interval | trace_enabled | max_prefork_processes |

mod_whatkilledus | sxl | max_connections_per_child
----------------------+----------------------+----------------------+--------+---------------+----------+----
YWQ4MzQwMmIzYjk3Mjlj | MjFjMDcyMTZiNDZlMmUy | YWVmMTAxNzcyZjYzOGRk | 0| 0|
worker | 16 | 50 |
25 | 75 | 5| 10 | 4080 | 0 | UNKNOWN | 0|
30 | 1| 128 | 0| 1| 9000

# psql -U nobody -d corporate -c "select * from tblwafsecurityprofile"

id | name | comment | wafmode | threats_filter | av | outlookanywhere |
cookiesign | urlhardening | urlhardening_entrypages_source | urlhardening_sitemap_url |
urlhardening_sitemap_update | formhardening | av_engines | av_size_limit_status | av_directions |
av_block_unscannable | av_size_limit | bad_clients | bad_clients_no_dnslookup | waf | wafparanoia |
sec_request_body_no_files_limit | filter_mode | cook
iesign_drop_unsigned | av_timeout | isdefault | paranoia_level | sec_request_body_limit |
sec_response_body_limit | sec_response_body_limit_action
----------------------+----------------------+----------------------+--------+---------------+----------+----
7 | WAF-Demo | | detect | 1| 1| 0| 1| 0|
| | 0| 0 | avira | 0 | uploads |
0| 0| 1| 0| 0| 0| 1048576 | black |
1| 90 | 0| 1| 1073741824 | 524288 | ProcessPartial

Page 35 of 69
Module 5 – Webserver Protection

Troubleshooting WAF
Enabling debug mode
1. Make the system partition editable
2. Edit WAF configuration file /usr/apache/conf/httpd.conf and
change "LogLevel notice" to "LogLevel debug”
3. Verify the changes in the httpd.conf
4. Restart WAF to apply changes
# mount -o remount,rw /

# vi /usr/apache/conf/httpd.conf

# cat /usr/apache/conf/httpd.conf | grep -i loglevel LogLevel debug

# service waf:restart -ds nosync

Troubleshooting WAF
Enabling debug mode

STEP 1: Make the system partition editable.

mount -o remount,rw /

STEP 2: Edit the WAF configuration file in /usr/apache/conf/httpd.conf and change "LogLevel
notice" to "LogLevel debug"
vi /usr/apache/conf/httpd.conf

STEP 3: Restart WAF for the changes to take effect.

service -ds nosync waf:restart

Disable Debug Logs

STEP 1: Make the system partition editable.
mount -o remount,rw /

STEP 2: Edit the WAF configuration file in /usr/apache/conf/httpd.conf and change "LogLevel
debug" to "LogLevel notice"

Page 36 of 69
Module 5 – Webserver Protection

vi /usr/apache/conf/httpd.conf

STEP 3: Restart WAF for the changes to take effect.

service -ds nosync waf:restart

Page 37 of 69
Module 5 – Webserver Protection

Troubleshooting WAF
Log viewer standard view

Troubleshooting WAF
Log viewer Standard View

Live logs are available on GUI.

Navigate to Monitor & Analyze > Reports > Log Viewer and select ‘Web Application Filter’ from ‘View logs
for’ drop-down list

Page 38 of 69
Module 5 – Webserver Protection

Troubleshooting WAF
Configuration files
Modules Description

/usr/apache/conf/httpd.conf Static Configuration file

/cfs/waf/reverseproxy.conf Dynamic Configuration file

/usr/apache/conf/waf/modsecurity.conf Modsecurity module Configuration file

/usr/apache/modules/ List of WAF modules

/usr/apache/conf/waf/rules/ Modsecurity rules

/usr/apache/conf/modules.conf List of modules that are loaded when WAF is started

/usr/apache/bin/httpd -v Apache version used by WAF

Troubleshooting WAF
Configuration files

• Static config file

cat /usr/apache/conf/httpd.conf

• Dynamic Configuration file

cat /cfs/waf/reverseproxy.conf

• Modsecurity configuration file

cat /usr/apache/conf/waf/modsecurity.conf

• A list of WAF modules

ls /usr/apache/modules/

• A list of mod_security rules

ls /usr/apache/conf/waf/rules

• A list of modules that are loaded when WAF is started

less /usr/apache/conf/modules.conf
cat /usr/apache/conf/modules.conf

Page 39 of 69
Module 5 – Webserver Protection

• Apache version used by WAF

/usr/apache/bin/httpd -v

Page 40 of 69
Module 5 – Webserver Protection

Troubleshooting WAF
Determine ID and its function
# grep 920460 /usr/apache/conf/waf/rules/*conf
/usr/apache/conf/waf/rules/REQUEST-920-PROTOCOL-ENFORCEMENT.conf:
"id:920460,
# less /usr/apache/conf/waf/rules/REQUEST-920-PROTOCOL-ENFORCEMENT.conf
SecRule REQUEST_URI|REQUEST_HEADERS|ARGS|ARGS_NAMES "@rx
(?:^|[^\\\\])\\\\[cdeghijklmpqwxyz123456789]" \
"id:920460,\
phase:2,\
block,\
capture,\
t:none,t:urlDecodeUni,t:htmlEntityDecode,t:lowercase,\
log,\
msg:'Abnormal character escapes in request',\
logdata:'Matched Data: %{TX.0} found within %{MATCHED_VAR_NAME}:
%{MATCHED_VAR}',\
tag:'application-multi',\
ver:'OWASP_CRS/3.2.0',\
severity:'CRITICAL',\
setvar:'tx.http_violation_score=+%{tx.critical_anomaly_score}',\
setvar:'tx.anomaly_score_pl4=+%{tx.critical_anomaly_score}'"

Troubleshooting WAF
Determine ID and its function

We can determine the general function of an ID which is generated in reverseproxy.log file for Common
Threat Filter (CTF) using the WAF Configuration file.

The Mod Security Confs are located at /usr/apache/conf/waf/rules/*conf

As in example, let’s say if we want to determine ID 920460 then first, it would have to be found out to
which pattern the ID belongs and thus in which file to search:
# grep 920460 /usr/apache/conf/waf/rules/*conf
/usr/apache/conf/waf/rules/REQUEST-920-PROTOCOL-ENFORCEMENT.conf: "id:920460,

Next, open the file with less and search for the ID
#less /usr/apache/conf/waf/rules/REQUEST-920-PROTOCOL-ENFORCEMENT.conf
SecRule REQUEST_URI|REQUEST_HEADERS|ARGS|ARGS_NAMES "@rx
(?:^|[^\\\\])\\\\[cdeghijklmpqwxyz123456789]" \
"id:920460,\
phase:2,\
block,\
Page 41 of 69
Module 5 – Webserver Protection

capture,\
t:none,t:urlDecodeUni,t:htmlEntityDecode,t:lowercase,\
log,\
msg:'Abnormal character escapes in request',\
logdata:'Matched Data: %{TX.0} found within %{MATCHED_VAR_NAME}: %{MATCHED_VAR}',\
tag:'application-multi',\
tag:'language-multi',\
tag:'platform-multi',\
tag:'attack-protocol',\
tag:'paranoia-level/4',\
ctl:auditLogParts=+E,\
ver:'OWASP_CRS/3.2.0',\
severity:'CRITICAL',\
setvar:'tx.http_violation_score=+%{tx.critical_anomaly_score}',\
setvar:'tx.anomaly_score_pl4=+%{tx.critical_anomaly_score}'"

Page 42 of 69
Module 5 – Webserver Protection

Infrastructure rules
Infrastructure rules
• Certain rules we call "infrastructure rules" are core to the operation of
the WAF ModSecurity. 901100
• You should not turn off these rules without possibly affecting other rules 901110
that are built upon these rules.
• Adding an infrastructure rule to the Skip filter rules list makes 949190
you vulnerable to attacks.
• To block a false positive, search reverseproxy.log for non-infrastructure 949110
rules triggered before the infrastructure rule, add them to the Skip filter
rules list instead. 959100

980100

980110

980120
Note: The infrastructure rules are always the last ones to be triggered by an HTTP request.
980130

Certain rules we call "infrastructure rules" are core to the operation of the WAF ModSecurity. You should
not turn off these rules without possibly affecting other rules that are built upon these rules. Adding an
infrastructure rule to the Skip filter rules list makes you vulnerable to attacks.

To block a false positive, search reverseproxy.log for non-infrastructure rules triggered before the
infrastructure rule, add them to the Skip filter rules list instead. Remember that the infrastructure rules are
always the last ones to be triggered by an HTTP request.

Reference: https://support.sophos.com/support/s/article/KB-000035562?language=en_US

Page 43 of 69
Module 5 – Webserver Protection

Troubleshooting WAF
Packet capture with unencrypted traffic
# mount -o remount,rw /

# vi /usr/apache/conf/httpd.conf

Uncomment the following lines

(delete the "#" in front of every line):
#LoadModule pcap_module /usr/apache/modules/mod_pcap.so
#PcapFileName /var/WAF.pcap
#PcapNetworkProtocol ip

# service waf:restart -ds nosync

# cd /var; ls WAF.pcap
WAF.pcap

Troubleshooting WAF
Packet capture with unencrypted traffic

If you take packet capture for WAF traffic, then it will be encrypted for HTTPS so if you want to
check unencrypted traffic for analysis then it can be done by below steps :-
1) Login to the XG via SSH.
2) Open /usr/apache/conf/httpd.conf using vi
3) Uncomment the following lines (delete the "#" in front of every line):
#LoadModule pcap_module /usr/apache/modules/mod_pcap.so
#PcapFileName /var/WAF.pcap
#PcapNetworkProtocol ip
4) Restart the WAF after saving the httpd.conf:
#service waf:restart -ds nosync
5) Reproduce the issue and then check. You will find the resulting file here: /var/WAF.pcap for a
file called WAF.pcap.
6) Download WAF.pcap. This unencrypted file is helpful for troubleshooting WAF issues.

Note: Please use this for your troubleshooting reference and do not share directly with customer.
Also, make sure to revert those lines by comment(#) it again.

Page 44 of 69
Module 5 – Webserver Protection

Troubleshooting WAF
Website not reachable
• Check the WAF service and if required, restart the service manually
• Check for error messages in the /log/reverseproxy.log
• Check the WAF network socket is listening on port 80 or port 443:
o If the external and internal protocol/ports are different, you need HTML Rewriting
• Enable Pass Host Header
• Test the connection with DNAT rules only
# service WAF:status -ds nosync

# service WAF:restart -ds nosync

# tail -f /log/reverseproxy.log

# netstat -naltp | grep -E ':80|:443’

Common issues
Website is not reachable

• Ensure the DNS of the site hostname is pointing to the correct hosted address
• Check using the console or tcpdump if the requests are arriving at the correct interface
• If external and internal protocol/ports are different, you need HTML Rewriting (Virtual Webserver)
i.e. Select to rewrite the links of returned web pages to retain link validity.
• Enable Pass Host Header (Virtual Webserver) i.e. Select to forward the host header requested by the
client to the web server.
• Check that the WAF network socket is listening on port 80 or port 443: netstat -naltp | grep -E
':80|:443'
• Test the connection with DNAT rules only. If this does not work, there is a problem with your backend
server.

Note:
What is Pass Host Header?
The Host request header specifies the host and port number of the server to which the request is being
sent.
If no port is included, the default port for the service requested (e.g., 443 for an HTTPS URL, and 80 for an
HTTP URL) is implied.

Page 45 of 69
Module 5 – Webserver Protection

A Host header field must be sent in all HTTP/1.1 request messages. A 400 (Bad Request) status code may be
sent to any HTTP/1.1 request message that lacks a Host header field or that contains more than one.

Page 46 of 69
Module 5 – Webserver Protection

Troubleshooting WAF
Webserver unreachable Error 503
• Getting error code 503
• This indicated that the webserver/webservice was unreachable

Common issues
Webserver unreachable error code as 503

Getting error code 503

This indicated that the webserver/webservice was unreachable

Code 503 is a HTTP server error response code indicating the web server is either offline or not ready to
handle any request. It can also occur when the web server is overloaded. One entry to look for is Retry-
After response HTTP header which implies how long the user agent should wait before making a follow-up
request. Normally, the code should be 429 (Too Many Request) or 301 (Moved Permanently). Should it
generate a 503, then its no doubt web service or web server is either interrupted or not available.

Troubleshooting Steps:
If the error code is 503 and getting logs as below than server may be unreachable.
Check the OSI layer 3 connectivity to web server. (Router, Web Server interface, network
connectivity or even web server application).

Page 47 of 69
Module 5 – Webserver Protection

Troubleshooting WAF
Static URL Hardening – No signature found
• Getting error on browser with message • Possible cause: Static URL hardening
‘No signature found’. o A required paths is not allowed
o The requested paths are not matching the
allowed paths

Common issues
Static URL Hardening – No signature found

Here you can see a webpage blocked because Sophos Firewall is unable to find a signature for the entry
URL. To proceed, we need to take a look at the configured entry URLs in the firewall profile.

[Click]
It is important to remember that entry URLs configured in the firewall profile are case sensitive. In this
example we can see that "/DVWA-1.9/" is listed as an entry URL in capital letters; this means that if you try
to access the page using lowercase letters in the URL it will not match and access will be denied.

[Click]
The solution is to ensure that entry URLs are added in the case that will be used when the page is being
accessed. This may require the entry URL to be added in different cases as shown here.

Page 48 of 69
Module 5 – Webserver Protection

Troubleshooting WAF
Static URL Hardening - /log/ reverseproxy.log
• Verify that all required paths are added to the URL hardening configuration.
• E.g.,
/dvwa-1.9/ was denied because the path configuration is case sensitive
Only /DVWA-1.9/ was configured when the log was taken
[Fri Aug 12 16:58:08.129415 2016] [url_hardening:error] [pid
6672:tid 4077886272] [client 192.168.1.7:52782] No signature found,
URI: http://www.dvwa.com/dvwa-1.9/
[Fri Aug 12 16:58:08.128535 2016] timestamp="1471017488"
srcip="192.168.1.7" localip="192.168.1.254" user="-"
host="192.168.1.7" method="GET" statuscode="403" reason="Static URL
Hardening" extra="No signature found" exceptions="-" duration="4730"
url="/dvwa-1.9/" server="www.dvwa.com" referer="-"

Common issues
Static URL Hardening – No signature found in the logs

Verify that all required paths are allowed properly with URL hardening configuration.

As per the highlighted logs, requested path /dvwa-1.9/ is denied because path is case sensitive and actual
allowed path is /DVWA-1.9/.

Page 49 of 69
Module 5 – Webserver Protection

Troubleshooting WAF
Form hardening changed the initial web request

Troubleshooting WAF
Form hardening changed the initial web request

Form hardening prevents tampering with forms. The Sophos Firewall saves the original structure of a web
form and signs it. If the structure has changed when the form is submitted, the Sophos Firewall rejects the
request.

We will now take a look at one of the effects of form hardening and how to resolve any problems it can
cause.
[Click]
The HTML-parser that the UTM uses for form hardening will change the data in the initial web request.
Some scripts depend on the information in the initial web request and so can fail because it has been
modified.

Page 50 of 69
Module 5 – Webserver Protection

Troubleshooting WAF
Form hardening in the logs - /log/ reverseproxy.log
Wed Aug 12 05:26:39.011279 2020] [form_hardening:error] [pid 26499:tid
140122100037376] [client ###.###.###.###:50516] Form validation failed: Token is not
valid for URL /DVWA/vulnerabilities/upload/ (expected:
/DVWA/vulnerabilities/upload/#), referer: https://xgfirewall-
training.westeurope.cloudapp.azure.com/DVWA/vulnerabilities/upload/
[Wed Aug 12 05:26:39.011316 2020] [form_hardening:error] [pid 26499:tid
140122100037376] [client ###.###.###.###:50516] Failed to validate form: Form
Hardening Token is invalid (2), referer: https://xgfirewall-
training.westeurope.cloudapp.azure.com/DVWA/vulnerabilities/upload/
[Wed Aug 12 05:26:38.908803 2020] timestamp="1597227998" srcip="###.###.###.###"
localip="10.1.1.88" user="-" method="POST" statuscode="400" reason="Form Hardening"
extra="Form Hardening Token is invalid" exceptions="-" duration="102675"
url="/DVWA/vulnerabilities/upload/" server="xgfirewall-
training.westeurope.cloudapp.azure.com" referer="https://xgfirewall-
training.westeurope.cloudapp.azure.com/DVWA/vulnerabilities/upload/"
cookie="security=impossible; PHPSESSID=grlcdbl44fafmgo1jr85ngu2n6" set-cookie="-"
recvbytes="112778" sentbytes="5624" protocol="HTTP/1.1" ctype="text/html"
uagent="Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:79.0) Gecko/20100101
Firefox/79.0" querystring="" websocket_scheme="-" websocket_protocol="-"
websocket_key="-" websocket_version="-" ruleid="17"

Troubleshooting WAF
Form hardening in the logs

When the form hardening detects a problem you will see errors like these in the reverseproxy.log. The
important information here is the fact that it is triggering form hardening and the URL involved.

Page 51 of 69
Module 5 – Webserver Protection

Troubleshooting WAF
Form hardening solution
Check the option "Never change HTML during
Enable a WAF Firewall rule URL Hardening or Form Hardening“

Troubleshooting WAF
Form hardening solution

To resolve issues caused by the form hardening HTML-parser changing the initial web request you need to
use the "Never change HTML during Static URL Hardening or Form Hardening" option, which can be
enabled in the exceptions.

To be able to use this option you will need to create a new exception for form hardening that applies to the
URL identified in the reverseproxy.log.

If you are using the web application firewall with Outlook Web Access you will need to enable this option,
as without this setting any functions which use the Exchange Control Panel (ECP) will not work correctly.
With Outlook Web Access, you would see a statuscode=“412” in the reverseproxy.log.

Never change HTML during static URL hardening or form hardening

When this option is selected, no data matching the defined exception settings will be modified by Sophos
Firewall. For example, binary data wrongly supplied with a text/HTML content type by the web server will
not be corrupted. On the other hand, web requests may be blocked due to activated URL hardening, HTML
rewriting, or form hardening. Those three features use an HTML parser and therefore to some extent
depend on the modification of webpage content. To prevent undesired blocking, skip URL hardening and/or

Page 52 of 69
Module 5 – Webserver Protection

form hardening for requests affected by blocking; you might need to do this in another/new exception to
reflect dependencies between web servers and/or webpages.

Accept unhardened form data

Form Hardening exceptions rely on the FH (Form Hardening) token, and if this is missing it will always block
the data, even if the Form Hardening check is disabled. This token is added to forms that are presented to
the client through the web application firewall. If the form is presented to the user through an external
source, but submitted through Sophos Firewall, the FH token will not be present, causing the data to be
blocked. With this option, forms submitted without the FH token will be accepted.

Page 53 of 69
Module 5 – Webserver Protection

Troubleshooting WAF
Links are not working/content or images are not displayed properly /log/ reverseproxy.log
[Wed Aug 12 06:11:27.424679 2020] [security2:error] [pid 44999:tid 140326027122432]
[client ###.###.###.###:62626] [client ###.###.###.###] ModSecurity: Warning. Found 1
byte(s) in REQUEST_BODY outside range: 38,44-46,48-58,61,65-90,95,97-122. [file
"/usr/apache/conf/waf/rules/REQUEST-920-PROTOCOL-ENFORCEMENT.conf"] [line "1391"]
[id "920273"] [msg "Invalid character in request (outside of very strict set)"] [data
"REQUEST_BODY=txtName=test2&mtxMessage=test&btnSign=Sign Guestbook"] [severity "CRITICAL"]
[ver "OWASP_CRS/3.2.0"] [tag "application-multi"] [tag "language-multi"] [tag "platform-
multi"] [tag
This is the "attack-protocol"] [tag "OWASP_CRS"] [tag
threat
"OWASP_CRS/PROTOCOL_VIOLATION/EVASION"] [tag "paranoia-level/4"] [hostname "xgfirewall-
filter rule ID
training.westeurope.cloudapp.azure.com"] [uri "/DVWA/vulnerabilities/xss_s/"] [unique_id
"XzPOX38AAAEAAK-Hfj4AAAAC"], referer: https://xgfirewall-
training.westeurope.cloudapp.azure.com/DVWA/vulnerabilities/xss_s/ [Wed Aug 12
06:11:27.428393 2020] [security2:error] [pid 44999:tid 140326027122432] [client
###.###.###.###:62626] [client ###.###.###.###] ModSecurity: Access denied with code 403
(phase 2). Operator GE matched 5 at TX:anomaly_score. [file
"/usr/apache/conf/waf/rules/REQUEST-949-BLOCKING-EVALUATION.conf"] [line "91"]
[id "949110"] [msg "Inbound Anomaly Score Exceeded (Total Score: 10)"] [severity
"CRITICAL"] [tag "application-multi"] [tag "language-multi"] [tag "platform-multi"] [tag
"attack-generic"] [hostname "xgfirewall-training.westeurope.cloudapp.azure.com"] [uri
This is NOT the
"/DVWA/vulnerabilities/xss_s/"] [unique_id "XzPOX38AAAEAAK-Hfj4AAAAC"], referer:
https://xgfirewall-training.westeurope.cloudapp.azure.com/DVWA/vulnerabilities/xss_s/
threat filter rule ID

Troubleshooting WAF
Links are not working/content or images are not displayed properly

In the reverseproxy.log there are several log entries related to this event.

In the first log entry we can see that rule ID 920273 has been triggered, and the message ‘Invalid character
in request’. This is the threat filter rule that has been triggered.

The next log entry looks very similar, but it is a rule that causes the traffic to be blocked based on the threat
filter rules that have been triggered. Skipping this rule will bypass a wide range of protection. You can
identify these rules as they refer to anomaly scores being exceeded.

There are certain rules we call infrastructure rules; they are core to the operation of the WAF ModSecurity.
You should not disable these rules without possibly affecting other rules that are built upon these rules. If
an infrastructure rule is added to the Skip Filter Rules list, then you make yourself vulnerable to other
possible attacks. The infrastructure rule ID are different for v18 and v17 and below list is for v18 :-

901100
901100
949100

Page 54 of 69
Module 5 – Webserver Protection

949190
949110
959100
980100
980110
980120
980130
980140

To block a false positive search the reverseproxy.log for non-infrastructure rules that were triggered before
the infrastructure rule and add those to the Skip Filter Rules list instead. Keep in mind that the
infrastructure rules are always the last rules to be triggered by an HTTP request.

Page 55 of 69
Module 5 – Webserver Protection

Troubleshooting WAF
Common Threat Filter solution Add “Skip Filter Rules” in Common Threat
Filter if the detections are false positives
Identify the Modsecurity rules blocked

Troubleshooting WAF
Common Threat Filter solution

User may get distorted page if few of the URLs are getting denied or may get ‘Forbidden’ error if primary
URL is getting denied due to Common Threat filter false positives.
Confirm the threat filter rules detected the traffic to be malicious and add them to skip filter if they are
actually false positives. Once added to skip filter, those rules would be ignored for pattern match.

Page 56 of 69
Module 5 – Webserver Protection

Troubleshooting WAF
Missing certificates for WAF HTTPS
• Confirm the certificate was uploaded in PKCS#12 format
o The Certificate and Private Key are required
o Navigate to SYSTEM > Certificates to upload

Troubleshooting WAF
Missing certificates for WAF HTTPS

Information needed by GES:

Access to the Firewall (shell and WebAdmin)
Certificate in PKCS#12 format customer used

Page 57 of 69
Module 5 – Webserver Protection

Troubleshooting WAF
Reverse authentication method: Basic Authentication > NTLM
1. The client connects to the virtual webserver on the Sophos Firewall
2. The virtual webserver prompts the user to login using basic authentication
3. The real webserver requests NTLM so the authentication fails

Virtual
webserver

NTLM authentication on the real webserver

Basic authentication on the virtual webserver

Troubleshooting WAF
Reverse authentication method: Basic Authentication > NTLM

When the Sophos Firewall is configured for reverse authentication, the user will be prompted to
authenticate with the Sophos Firewall. If this is successful, the Sophos Firewall can be configured to pass
the same credentials through to the real webserver using basic authentication. If the real webserver is not
configured to accept basic authentication this will fail. In this diagram the real webserver will only accept
NTLM authentication.

Page 58 of 69
Module 5 – Webserver Protection

Troubleshooting WAF
Verify authentication method
• Problem:
Users cannot authenticate with reverse authentication enabled
• Possible cause:
Misconfiguration of authentication method
• Check the reverseproxy.log
[Fri Aug 12 03:11:53.705490 2016] [authnz_aua:error] [pid 29277:tid
3977173824] [client 192.168.1.6:64992] [test] frontend and backend
credentials differ, authentication impossible

Troubleshooting Reverse Authentication

Verify authentication method

The final issue we will look at in this module is where users cannot authenticate when reverse
authentication is enabled.
Problems with authentication can be caused by the misconfiguration of the authentication methods on the
real webserver.
In the reverserpoxy.log you would see an error like this: "frontend and backend credentials differ,
authentication impossible".

Scenario - 1
Backend server authentication: Disabled, WAF authentication: Enabled

This is where we do not have authentication enabled on backend web server. Rather, we have enabled
authentication on backend servers behalf.
Highlighted logs states that user authentication failed and either user is not added to the authentication
policy or credentials are invalid.
Check the ‘Authentication Policy’ to verify the user is added into the policy and credentials are still valid.

Page 59 of 69
Module 5 – Webserver Protection

[Fri Aug 12 03:35:04.075505 2016] [authnz_aua:error] [pid 1808:tid 4068444992] [client

192.168.1.6:65328] [test] user authentication failed with 'AUTH_DENIED’
[Fri Aug 12 03:35:04.067000 2016] timestamp="1470969304" srcip="192.168.1.6" localip="192.168.1.254"
user="test" host="192.168.1.6" method="GET" statuscode="401" reason="-" extra="-" exceptions="-"
duration="8664" url="/" server="www.test.com:8080" referer="-”

Scenario - 2
Backend server authentication:Enabled, SFOS-WAF authentication: Disabled

This is the case where backend server has basic authentication enabled and Sophos Firewall is configured
for ‘Authentication Forwarding’ to backend server.
When the Sophos Firewall is configured for authentication forwarding, the user will be prompted to
authenticate with the Sophos Firewall. If this is successful, the Sophos Firewall passes the same credentials
through to the real webserver using basic authentication.
As per the ‘Password Failure’ logs above, user seems to have entered invalid password.
And as per the ‘Username entered is not valid with backend server’ logs, where we are getting highlighted
error, seems that username itself is not valid with the backend sever.

[Fri Aug 12 03:10:58.554369 2016] [authnz_aua:error] [pid 29277:tid 3993959232] [client

192.168.1.6:64988] [jatin] user authentication failed with 'AUTH_DENIED’
[Fri Aug 12 03:11:53.705490 2016] [authnz_aua:error] [pid 29277:tid 3977173824] [client
192.168.1.6:64992] [test] frontend and backend credentials differ, authentication impossible
[Fri Aug 12 03:11:53.701347 2016] timestamp="1470967913" srcip="192.168.1.6" localip="192.168.1.254"
user="test" host="192.168.1.6" method="GET" statuscode="500" reason="-" extra="-" exceptions="-"
duration="4333" url="/" server="www.test.com:8080" referer="-"

Page 60 of 69
Module 5 – Webserver Protection

Troubleshooting WAF
Verify the supported authentication methods with curl

$ curl -i -k https://www.test.com:8080
HTTP/1.1 401 Unauthorized
Date: Fri, 12 Aug 2016 17:30:56 GMT
Server: Apache
WWW-Authenticate: NTLM
Content-Length: 381
Content-Type: text/html; charset=iso-8859-1

Troubleshooting Reverse Authentication

Verify the supported authentication methods with curl

We have several options available to confirm the backend server authentication methods. E.g. curl, broswer
debug, wget, etc

Page 61 of 69
Module 5 – Webserver Protection

Troubleshooting WAF
Solutions
Configure the real webserver to accept
basic authentication Disable reverse authentication

Troubleshooting WAF
Solutions

• It is recommended to enable basic authentication on the real web server to ensure reverse
authentication can pass the credentials through. Do not disable any of the other authentication
methods as they maybe required by other systems.
• Or disable reverse authentication; which will reduce the level of protection provided by Web
Application Firewall as it means potential attackers can reach the real web server before they have to
authenticate.

Page 62 of 69
Module 5 – Webserver Protection

SlowHTTP Protection

Page 63 of 69
Module 5 – Webserver Protection

SlowHTTP Protection
Slowloris attack method

Incomplete HTTP requests

Attacker Webserver

SlowHTTP Protection

Slow HTTP attacks are denial-of-service (DoS) attacks in which the attacker sends HTTP requests in pieces
slowly, one at a time to a Web server. If an HTTP request is not complete, or if the transfer rate is very low,
the server keeps its resources busy waiting for the rest of the data. When the server’s concurrent
connection pool reaches its maximum, this creates a DoS. Slow HTTP attacks are easy to execute because
they require only minimal resources from the attacker.

Why is this a problem and need special protection required?

• These connections look like legitimate user connections.
• Traditional rate detection techniques will skip them.
• Existing IPS/IDS solutions that rely on signatures will generally not recognize them either.
• They require very few resources and little bandwidth for execution.

Such attack can bring down a Web server, irrespective of its hardware capabilities.

Page 64 of 69
Module 5 – Webserver Protection

SlowHTTP Protection
Configuration Parameter

Timeout for receiving HTTP headers

Max amount of time

Extend soft limit by 1 second for

Bypass protection for selected every n bytes received
hosts/networks

SlowHTTP Protection
Configuration Parameter

Soft limit: Enter the minimum amount of time to receive a request header. Default: 10 seconds. The hard
limit needs to be greater than the soft limit.
Hard limit: Enter the maximum amount of time to receive the request header. Default: 30 seconds
Extension rate: Enter the amount of date volume which extends the timeout. With the extension rate, you
can increase the minimal timeout according to the data volume. For example, the soft limit allows at least
10 seconds to receive request headers, the extension rate is 500, and the hard limit is set to 30. If the client
now sends data, the soft limit timeout increases 1 second for every 500 bytes received. After 30 seconds
the client will be disconnected. Default: 5000 Bytes.
Skipped Networks/Hosts: Select or add networks/hosts that should not be affected by SlowHTTP
Protection.

If the timeout is too short, it risk dropping legitimate slow connections; and if it’s too long, it don’t get any
protection from attacks. Its recommend a timeout value based on connection length statistics, For
example, a timeout slightly greater than median lifetime of connections should satisfy most of the
legitimate clients.

Note: The SlowHTTP Protection is global option only. Hence, it will be applicable for all web-server added in
the Sophos Firewall.

Page 65 of 69
Module 5 – Webserver Protection

SlowHTTP Protection
False detection of slow HTTP sessions
• Improper configuration of ‘Slow HTTP Protection’ may lead to false positives and could
deny legitimate sessions
• Session getting denied due to SlowHTTP will cause an error code 408 in the
reverseproxy.log
[Fri Aug 12 20:02:22.271555 2016] timestamp="1471028542"
srcip="192.168.1.7" localip="192.168.1.254" user="-"
host="192.168.1.7" method="GET" statuscode="408" reason="-" extra="-
" exceptions="-" duration="13119159" url="/" server="www.dvwa.com"
referer="https://github.com/shekyan/slowhttptest/" cookie="-" set-
cookie="-" recvbytes="311" sentbytes="0" protocol="HTTP/1.1"
ctype="text/html" uagent="Mozilla/5.0 (Macintosh; Intel Mac OS X
10.9; rv:27.0) Gecko/20100101 Firefox/27.0AppleWebKit/533.21.1
(KHTML, like Gecko) Version/5.0.5 Safari/533.21.1" querystring=""
ruleid="-"

SlowHTTP Protection
False detection of slow HTTP sessions

Denied sessions can be seen with error code 408 by WAF in /log/reverseproxy.log file.

Note: There are no GUI logs available for SlowHTTP Protection of the Sophos Firewall WAF module.

Page 66 of 69
Module 5 – Webserver Protection

Minimum Escalation Requirements (MER)

• Please refer to the MER KB Article for WAF
o https://sophos.lightning.force.com/lightning/r/ka03Z0000004flKQAQ/view

Minimum Escalation Requirements (MER)

Please refer to the MER KB Article for WAF

https://sophos.lightning.force.com/lightning/r/ka03Z0000004flKQAQ/view

Page 67 of 69
Module 5 – Webserver Protection

Module objective review

On completion of this module you are now able to:
ü Identify the function of web server protection features
ü Identify the relevant information for troubleshooting issues with Webserver
Protection
ü Troubleshoot and resolve problems related to:
ü Website not reachable
ü URL hardening
ü Form hardening
ü Common Threat Filter
ü Reverse authentication
ü Webserver outage
ü WAF certificate
ü SlowHTTP Protection

On completion of this module you are now able to

ü Identify the function of web server protection features
ü Identify the relevant information for troubleshooting issues with Webserver Protection
ü Troubleshoot and resolve problems related to:
o Website not reachable
o URL hardening
o Form hardening
o Common Threat Filter
o Reverse authentication
o Webserver outage
o WAF certificate
o SlowHTTP Protection

Page 68 of 69
Module 5 – Webserver Protection

Lab 6: Web Server Protection

• Resolved an issue where a
Webmail service is not accessible
while protected with Webserver
Protection on Sophos Firewall

Page 69 of 69