Order of Operations - Application Control and Web Filtering

The current article explains the processing order of Application Control and Web Filtering security profiles when both are applied to the same security policy.

‎

Setting up the testing environment

#

• To setup the testing environment, an Application Control profile under Security Profiles > Application Control is created. This AC profile will monitor all application categories but block the GitHub application, using Application and Filter Overrides:

• A Web Filter profile is also created under Security Profiles > Application Control where github.com will be configured with the Block action , using Static URL Filter:

• Next, a firewall policy is created for secure internet access from a specific user PC. Both security profiles (WF, AC) created in the previous steps are applied in this policy. The inspection mode for this policy will be Flow-based. Furthermore, deep-inspection SSL profile is applied:

Application Control in action

#

• From the user PC, access to https://github.com is tested:

The user receives a block message from FortiGate indicating the access was blocked because of Application Control - “Application Blocked”. The user sees the blocked application name, its category, and URL.

• To check the details of this block, first take a look at the traffic logs under Log & Report > Forward Traffic, filtering by the Source IP address and the Application Name:

Two traffic logs from the user 3 seconds apart from each other are shown, each one with a different Session ID. Check the details of the first log.

• Double click the first log to check its details:

From the Details tab some information about the traffic is confirmed:

• Session ID: 2342929
• Destination: 140.82.113.3
• Hostname: 140.82.113.3 (same as destination)
• Application Name: Github
• Control Action: drop-session

Scrolling further into the log details, an important piece of information under Other section is shown:

• apps: Github, SSL

• A more trustful way of checking the application control logs is going to Log & Report > Security Events > Application Control. Then filter by the Session ID (previously got from the traffic logs):

Check that both the Application and the Action values are different for both logs, although they belong to the same session ID. This is because, the application is initially recognized as SSL, which has an action of Pass (Monitor) according to the Application Control profile. Then, the application is re-identified more precisely as Github. All this happens in fraction of a second, which can be verified on Date/Time value of each log.

• Selecting the first application control log, the following is confirmed:
  • Under General tab, the Session ID matches the traffic log
  • Under Destination tab, the Hostname matches the Destination IP address.
  • Under Application Control tab, the identified application is SSL
  • Under Action tab, the action is Pass (matching the AC profile action for this app)

• Selecting the second application control log, the following is confirmed:
  • Under General tab, the Session ID matches the traffic log (and the previous application control log)
  • Under Destination tab, the Hostname matches the visited domain together with an additional parameter - URL “/”.
  • Under Application Control tab, the identified application is Github
  • Under Action tab, the action is now Block (matching the AC profile action for this app)

Web Filter in action

#

Because of the previous test we know that Application Control has precedence over Web Filter security profile. To confirm that Web Filter would also block the access to https://github.com , the following changes are made: 1) Remove GitHub from the Application Control Override, 2) Test user access again.

• Go To Security Profiles > Application Control, select the Application Control Profile and click on Edit.
• Under Application and Filter Overrides, select Github and click on Delete:

• Verify the application is deleted and click OK to save changes:

• Try to access again to https://github.com from the user PC:

This time the user got a different blocking message related to FortiGuard Intrusion Prevention - Access Blocked - “Web Page Blocked”. The user also sees the blocked URL.

• To check the details of this block, first take a look at the traffic logs under Log & Report > Forward Traffic, filtering by the Source IP address, Deny as Result, and the firewall Policy ID:

Two traffic log entries from the user, 4 seconds apart from each other are listed, each one with a different Session ID. Verify the details of the first log.

• Double click the first log to check its details:

From the Details tab some information about the traffic can be reviewed:

• Session ID: 3421775
• Destination: 140.82.114.4
• Hostname: 140.82.114.4 (same as destination)
• Application Name: Github
• Control Action: detected (meaning Application Control profile didn’t block the traffic because of the identified application)

Scrolling further into the log details you can also verify an important piece of information under Other section:

• Threats: github.com
• Threat Type: N/A - Static URL Filter

• Clicking on Security tab of the log details should shown as brief explanation of the Web Filter event. Here, information as the Event Type, Hostname and URL related to this web filter event can be reviewed and you can click on Show matching logs to get more details about the security event:

• A more trustful way of checking the application control logs is going to Log & Report > Security Events > Web Filter. Here, filter the Session ID checked from the traffic logs:

• Double clicking on the log, more details about the security event is returned:
  • Under General tab, the Session ID matches the traffic log.
  • Under Destination tab, the Destination IP address, Hostname, and URL are shown.

• Scrolling down further…
  • Under Action tab, the action is Blocked
  • Under Web Filter verify the information related to the web filter profile. For example the Message indicate the reason why this URL was blocked.

Conclusion

#

• In flow-based inspection mode, the firewall policy will first enforce the Application Control profile and then the Web Filter profile. So, when an application is permitted by the Application Control profile, the URL could still be blocked by the Web filter profile.
• The same tests done with proxy-based inspection mode policy and using a Proxy-based Web Filter profile provide the same processing order. First, the application control is applied and then the web filter profile.