Blocking access to unnecessary services or URL paths

A government agency operates a public-facing website that provides essential services such as citizen registrations, application forms, and public announcements. It also includes an internal admin portal for government staff to manage data, process applications, and handle citizen queries. The admin portal is sensitive and should only be accessible by authorized personnel.

Challenges

Without proper restrictions, attackers could discover and attempt to access sensitive admin pages or exploit unnecessary URLs, posing risks such as data breaches or system manipulation.

Solutions by FortiWeb

With FortiWeb deployed in front of your web servers, it can be configured to block access to unnecessary services or URL paths, effectively mitigating risks without requiring immediate corrections to misconfigurations on your web servers. All you need to do is configure a rule on your web servers to accept traffic only from FortiWeb's IP address, ensuring that all traffic is filtered and secured by FortiWeb before reaching your servers.

• Defined Services and HTTP Allow Methods

  FortiWeb is deployed as a reverse proxy to handle only HTTP/HTTPS traffic, ensuring that non-HTTP/HTTPS protocols, such as FTP or Telnet, are blocked at the FortiWeb layer before reaching the web servers. Additionally, you can specify which HTTP methods are allowed to further control and secure incoming traffic. This minimizes exposure to attacks targeting other services.

• URL Access Control

  • FortiWeb can be configured to restrict access to the admin portal (/admin/*) based on IP addresses. Only internal government office IPs or authenticated users are allowed to access these URLs.

  • Public pages, such as /services/*, /announcements/*, and /forms/*, remain accessible to everyone without restrictions.

  • FortiWeb can be configured to block access to deprecated or unnecessary paths like /backup, /test, or /debug that could expose sensitive data or debugging information.

  • API endpoints or developer tools that are not part of the public-facing website can also be blocked to prevent unauthorized probing or access.

Configurations on FortiWeb

By deploying a FortiWeb device in front of your web servers, you can prevent unnecessary services from being exposed to external networks by applying centralized configurations on FortiWeb rather than modifying the settings on your back-end servers. This simplifies management, especially when you have multiple back-end servers where configuring each one individually can be complex and error-prone.

With all traffic passing through FortiWeb, you can enforce security policies from a single point of control instead of managing configurations across multiple servers.

Step 1: Configuring the access list on your back-end servers to accept traffic exclusively from FortiWeb's IP address

This step is optional because once you have configured the network settings and deployed a server policy on FortiWeb, all traffic to your application is automatically scanned by FortiWeb before reaching your web servers.

However, to further strengthen security and prevent attack attempts that bypass FortiWeb and directly target your back-end servers (e.g., attackers discover your back-end servers' IP addresses and attempt direct access), you can configure access controls on your back-end servers to accept traffic only from FortiWeb’s IP address. This measure ensures that all traffic is inspected and secured by FortiWeb before it reaches your servers.

Since this involves configurations on your back-end servers, the exact steps are not covered here. Please consult the appropriate teams or roles in your organization for guidance on implementing these access controls.

Step 2: Deploying FortiWeb in Reverse Proxy mode

In Reverse Proxy mode, FortiWeb only processes and forwards HTTP/HTTPS traffic to your back-end servers.

• Only HTTP/HTTPS is routed through FortiWeb for additional scanning and processing before arriving at the servers.

• IP-based forwarding/routing for non-HTTP/HTTPS protocols (e.g., FTP, SSH) is disabled to ensure security.

To enable the Reverse Proxy mode on FortiWeb:

1. Go to System > Config > Operation.
2. From Operation Mode, select Reverse Proxy.
3. Click Apply.

Note:

• You need to adjust the physical topology to suit the new operation mode. Refer to "Topology for Reverse Proxy mode" in "Planning the network topology" in FortiWeb Administration Guide.

• You may also need to reconfigure IP addresses, static routes, bridges, and virtual servers, enable or disable SSL on your web servers, etc. For the complete configurations, see "How to set up your FortiWeb" in FortiWeb Administration Guide.

• If you want to protect TCP traffic, you can configure a TCP server policy in FortiWeb. However, FortiWeb offers limited scanning capabilities for TCP traffic, primarily focusing on protocol validation and basic filtering. See "Configuring FTP security" in FortiWeb Administration Guide.

Step 3: Configuring the allow methods of HTTP/HTTPS traffic

You can configure policies on FortiWeb to allow only specific HTTP request methods, providing an effective way to limit potential attack vectors. This is particularly useful for preventing attacks that exploit unsafe methods, such as HTTP TRACE, which can disclose sensitive information in production environments.

HTTP methods prone to being exploited by attackers

• HTTP methods like TRACE, CONNECT, and DELETE are often unnecessary for most web applications and can be exploited in attacks such as:

  • TRACE: Used in Cross-Site Tracing (XST) attacks to steal sensitive information.

  • CONNECT: May be abused to tunnel malicious traffic through the server.

  • DELETE: Can be used maliciously to delete resources.

• Methods like PUT, PATCH, and WEBDAV can allow unauthorized file uploads or modifications if not properly secured.

• Methods like PUT, PATCH, and DELETE may enable actions such as creating, updating, or deleting resources (e.g., ) which can modify your application's state.

Examples of Method Allowance configurations

• If you are a Typical Public Website that is designed to serve static or dynamic content (e.g., news articles, product pages) and handle simple form submissions (e.g., login forms, search queries). Below is the suggested HTTP Methods configuration:

  • Allow: GET, POST, HEAD

  • Deny: PUT, DELETE, TRACE, OPTIONS

• If your application involves REST API calls, such as an online shop that uses REST APIs to manage products, orders, and users, it will require a broader range of HTTP methods to support various operations. These methods enable the application to perform tasks like retrieving product details, updating order statuses, and managing user accounts efficiently.

  For example:

  • GET: To fetch product details or retrieve a list of orders.

  • POST: To create a new order or add a product to the catalog.

  • PUT: To update the stock of a product or modify an order’s status.

  • DELETE: To remove an obsolete product or cancel an order.

  • PATCH: To apply partial updates to user information or product details.

  While you can disable methods like TRACE and CONNECT to enhance security, doing so reduces the attack surface by preventing misuse.

• If your application leverages WebDAV's ability to extend HTTP for creating, editing, and managing files on remote servers—such as a Content Management System (CMS) that allows users to manage and upload content directly to your website, or a Cloud Storage Service enabling users to manage files stored on a server remotely—you may need to allow the WEBDAV methods in addition to the standard GET and POST methods.

The example above highlights the most commonly seen requirements for applications regarding HTTP methods. However, it's crucial to evaluate your website's specific needs and functionality to make informed decisions about HTTP method configurations. Tailoring the allowed methods ensures that only the necessary operations are permitted, reducing security risks while maintaining application functionality.

To configure the HTTP Allow Methods on FortiWeb:

1. Go to Web Protection > Access > Allow Method and select the Allow Method Policy tab.
2. Click Create New.
3. Configure these settings:

Name	Type a unique name that can be referenced in other parts of the configuration. The maximum length is 63 characters.
Override Header/ Override Parameter	Enable.
Allow Request	Mark the check boxes for all HTTP request methods that you want to allow for this specific policy. Methods that you do not select will be denied, unless specifically allowed for a host and/or URL in the selected Blocking access to unnecessary services or URL paths. The OTHERS option includes methods not specifically named in the other options. It often may be required by WebDAV (RFC 4918; http://tools.ietf.org/html/rfc4918) applications such as Microsoft Exchange Server 2003 and Subversion, which may require HTTP methods not commonly used by web browsers, such as PROPFIND and BCOPY.
Severity	High
Trigger Policy	Select which trigger, if any, that the FortiWeb appliance will use when it logs and/or sends an alert email about a violation of the rule. For details, see Viewing log messages.
Allow Method Exceptions	This option specifies particular HTTP request methods that are permitted for specific URLs and hosts. In this scenario, you can leave the exceptions list empty if there are no special requirements. If you need to define an exceptions list, you can do so through the Allow Method Exceptions tab in Web Protection > Access > Allow Method. This enables you to tailor HTTP method allowances for unique use cases while maintaining security and control.

4. Click OK.

Step 4: Configuring URL Access rules to restrict access to example.com/admin

Access to administrative panels for your web application should only be allowed if the client’s source IP address is an administrator’s computer on your private management network.

Step 4.1 - Create an URL Access rule to allow access to "/admin" from the administrators' source IP addresses.

1. Go to Web Protection > Access > URL Access.
2. Select the URL Access Rule tab.
3. Click Create New.
4. Configure these settings:
   

   Name	Allow-admin-access
   Host Status	Enable
   Host	example.com
   Action	Continue—The matching request will be allowed by URL access but be evaluated by any subsequent rules defined in the web protection profile.
   Severity	Medium
   Trigger Action	Select a trigger action to specify how FortiWeb will log the attack.

5. Click OK.
6. Click Create New to add a new URL access condition entry to the set.
7. Configure these settings:
   

   Source Address	Enable.
   Source Address Type	IPv4/IPv6 / IP Range
   IPv4/IPv6 / IP Range	Enter the IP address or IP range of the administrator’s computer on your private management network.
   URL Type	Simple String
   URL Pattern	/admin
   Meet this condition if:	Object matches the Source Address and the URL pattern.

8. Click OK.

Step 4.2 - Create another URL Access rule to block access to "/admin" from all source IPs

1. Go to Web Protection > Access > URL Access.
2. Select the URL Access Rule tab.
3. Click Create New.
4. Configure these settings:
   

   Name	Block-admin-access
   Host Status	Enable.
   Host	example.com
   Action	Alert & Deny—Block the request and generate an alert, log message, or both.
   Severity	Medium
   Trigger Action	Select a trigger action to specify how FortiWeb will log the attack.

5. Click OK.
6. Click Create New to add a new URL access condition entry to the set.
7. Configure these settings:
   

   Source Address	Disable
   URL Type	Simple String
   URL Pattern	/admin
   Meet this condition if:	Object matches the URL pattern and Parameters.

8. Click OK.

Step 5: Configuring URL Access rules to block access to deprecated or unnecessary paths like /backup, and /debug

1. Go to Web Protection > Access > URL Access.
2. Select the URL Access Rule tab.
3. Click Create New.
4. Configure these settings:
   

   Name	Block-backup-debug-access
   Host Status	Enable
   Host	example.com
   Action	Alert & Deny—Block the request and generate an alert, log message, or both.
   Severity	Medium
   Trigger Action	Select a trigger action to specify how FortiWeb will log the attack.

5. Click OK.
6. Click Create New to add a new URL access condition entry to the set.
7. Configure these settings:
   

   Source Address	Disable
   URL Type	Regular Expression
   URL Pattern	^/(backup|debug)$
   Meet this condition if:	Object matches the URL pattern and Parameters.

8. Click OK.

Step 6: Configuring a URL Access policy to reference the rules

1. Go to Web Protection > Access > URL Access.
2. Select the URL Access Policy tab.
   
3. Click Create New.
   
4. In Name, type a unique name that can be referenced by other parts of the configuration. The maximum length is 63 characters.
5. Click OK.
6. Click Create New to add the first rule to the set.
7. From the Access Rule Name drop-down list, select "Allow-admin-access".
   
8. Click OK.
9. Click Create New to add the second rule to the set.
10. From the Access Rule Name drop-down list, select "Block-admin-access".
    
11. Click OK.
12. Click Create New to add the first rule to the set.
13. From the Access Rule Name drop-down list, select "Block-backup-debug-access".
    
14. Click OK.

Make sure the rule ranks from the highest to the lowest as in the following order:

• Allow-admin-access

• Block-admin-access

• Block-backup-debug-access

"Allow-admin-access" should have the smallest ID number, which means it's with highest priority.

When a request comes in, FortiWeb matches it against the rules from the top to the bottom. Once a rule matches, FortiWeb takes the specified action and skips all subsequent rules. As a result, FortiWeb handles the traffic as follows:

• All traffic to /admin will be blocked, except for requests originating from the administrator’s source IPs.

• Traffic to either /backup or /debug will be blocked.

• Any other traffic that does not match the above rules will be passed to subsequent security modules for further inspection.

For more information, see Restricting access based on specific URLs.

Next steps

Apply the security rules to web protection profile and then reference the profile in a server policy. See:

• Configuring a protection profile for inline topologies

• Configuring an HTTP server policy

By leveraging FortiWeb as a reverse proxy, you not only reduce configuration effort with the back-end servers but also enhance the security, compliance, and operational efficiency of your web application infrastructure.