Problem with existing sessions when schedules trigger.

Security Gateway Articles and How to's
Post Reply
Peter
Posts: 611
Joined: 10 Apr 2008, 14:14
Location: Clavister HQ - Örnsköldsvik

Problem with existing sessions when schedules trigger.

Post by Peter » 09 Oct 2014, 13:18

This How-to applies to:
  • Clavister Security Gateway version 10.x and above.
Problem:

When schedules trigger to stop allowing e.g. access to https://www.facebook.com it does not stop existing already established sessions.

Description:

An example scenario is that you are using Web Content Filtering (WCF) to control which categories that are allowed at certain time of the day. Between 08:00 and 17:00 access to Facebook should be restricted, but all other times it should be allowed.

One possible solution for this is to use WCF and block the category Facebook belongs to. The problem is that if a user logs on to Facebook at e.g. 07:00 in the morning and keeps his session active past 08:00, it will still work.

When using encrypted HTTPS sessions, it is only possible to allow/deny the category when a new session/connection is negotiated between the client and the web server. Once the client is connected, it does not give us any information that we can use to deny the category or access as the data is encrypted.

Solution

A solution that can be applied in some of these scenarios is to use Application Control (AC). This however requires that the AC database contains a signature that can detect the object involved. In this example a Facebook signature exists in the AC database that we can use.

What we need to solve this problem are two rules in the following order:
  • 1. NAT Lan Lannet Wan all-nets Service=All Application=BlockFacebook Schedule=Enabled
    2. NAT Lan Lannet Wan all-nets Service=All Application=Allow_All_Application Schedule=(not used)
The above rulesetup means that rule #1 will only trigger and block facebook on the defined time/dates as specified in the schedule, all other times rules #2 will trigger and simply allow every application.

The reason why we must use AC in #2 as well is to have the client session available in the Application Control engine. Without rule #2 we end up with the same problem of client cache, session etc. when using WCF.

Unfortunately this solution can only be applied when a signature for the involved "application" exists in the Application Control Database.

Post Reply