Problem description

When a configured IP rule set entry’s schedule triggers to stop allowing (for example, to allow access to Facebook), it will not close existing established sessions.

An example scenario

An example scenario is if we 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, access to Facebook will continue to 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, the established data/communication does not give us any information that we can use to deny the category or access as all the data is encrypted.

Problem 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 IP policies in the following order:

• The above rule setup 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.

Related articles