Web Filtering - Cipafilter Documentation

Manual - Web Filtering

The first thing to decide with regard to Web filtering is whether to run individual subnets in transparent or non-transparent (proxy server) mode.
  1. Transparent mode  — no client configuration is required, the Cipafilter simply intercepts all traffic on ports 80 and 443 as it moves through the router.
  1. Non-transparent mode  — each client must be configured to make use of a proxy service provided by the Cipafilter (on port 6226, by default). For example, in Internet Explorer, the Cipafilter proxy must be added on the Connections tab under Internet Options.

Basic Configuration

Proxy Access

Only machines with IPs in the subnets listed under Proxy Access will be allowed to use the proxy service. Subnets are provided in CIDR notation . If two subnets overlap, the smallest or most specific subnet configuration applies (just like in the Routing configuration).

Transparent Proxy

  1. Yes — Clients on this subnet are allowed to use the proxy, and any HTTP(S) requests (on ports 80 and 443) which are not already destined for it are intercepted and passed through it. This ensures that clients are caught by the filter even if their browser/OS proxy settings are disabled. 
  1. No — Clients on this subnet are allowed to use the proxy, but only with explicit proxy settings (via their Web browser or OS). Transparent interception is not performed, so the client may (depending on network configuration) be able to reach the unfiltered Internet if they can disable or bypass their local proxy settings. 
  1. Disable — Clients on this subnet are not allowed to use the proxy. Transparent interception is not performed, and attempts to connect to the proxy service directly are rejected. This is the default behavior for any subnet not listed in this table.


  1. Optional — Clients on this subnet are allowed, but not required, to authenticate as a specific user. When not otherwise authenticated, users on the subnet will be placed into the Subnet Group , and will be logged under their IP address. If the user chooses to authenticate, they will be logged under the specified user name and placed into the appropriate user group (if applicable).
  1. Required / Guest — Clients on this subnet are subject to the restrictions of the Required authentication mode (see below), with the exception that visitors to the captive portal may optionally "authenticate" as a guest user. This option is useful for public Wi-Fi networks and similar, where it is desirable to enforce agreement to the network's usage policy (see Customization ) without necessarily requiring authentication as a specific user. Guest users will have privileges corresponding to the subnet's Subnet Group (see below).
It is recommended that a custom portal certificate be installed if using guest access for a public Wi-Fi network; otherwise, visitors will receive a security warning when redirected to the portal. See Portal Certificate .
  1. Required — Clients on this subnet are required to authenticate before the filter will allow them to access the Web. Users may authenticate via user name and password or (if available) a Cipafilter authentication client. Clients on both transparent and non-transparent subnets have the option to use the portal for authentication; by default, however, non-transparent subnet users receive authentication prompts via their operating system or Web browser.
Proxy and portal credentials are authenticated against the authentication services configured on the Authentication tab. Each user's Web traffic is logged by user name, if Web monitoring is active, and can have individual "filtered" or "not filtered" settings.

Portal Log-In

  1. Enable — Users on this subnet may use the captive portal system for authentication, if they visit it manually or if they would be subject to redirection due to the Required authentication type.
  1. Persistent — This option is the same as Enable , except that users on this subnet will be authenticated persistently (their browser's authentication state will be remembered by the filter). Normally, when a user authenticates to the portal, their authentication state is remembered only until the session expires (after the amount of time specified on the Web Filtering or Group Permissions page has passed — the default is 12 hours). If this option is checked, a token representing each user's portal authentication state will be stored in their browser's cookies for an effectively permanent term. When the portal detects one of these token cookies, it will be verified for authenticity and, if successful, the user will be re-authenticated automatically — they will not actually see the portal again unless they navigate to it themselves.
Although the user's authentication state is maintained persistently, the authenticated client must be periodically verified by the filter. Verification is required after the time-out period specified on the Web Filtering page is exceeded. (Persistent authentication does not respect the per-group authentication time-out setting.) Once that time has elapsed, the user's session will expire and they will be temporarily de-authenticated, forcing their browser to be redirected to the portal again. Users who are actively browsing the Web will not notice this happening, but if for example an iPad user is using a non-browser app when their session expires, they will be required to return to the browser app and make a Web request to restart their session. Since this option requires cookies, the effect is per-device and per-browser — a user who accesses the network via multiple machines will need to authenticate at least once from each of them. Using a different browser, deleting the original browser's cookies, or removing the user's token via the Authentication Tools page will clear the effect.
  1. Disable — Clients on this subnet will never be automatically redirected to the portal for authentication; users with browser proxy settings will be made to authenticate using their operating system or browser's standard credential prompt, and users subject to transparent proxy will not be prompted to authenticate at all. In addition to not being redirected when authentication is required, users on a disabled subnet will be unable to authenticate to the portal if they navigate to it manually (this may be significant if administrators commonly use the portal to temporarily increase privileges for a client, for instance). However, users will always have the option to view the portal by navigating to it manually, if for example they need to reference the AUP or install an SSL certificate.
In all cases, the use of a Cipafilter authentication client will bypass redirection to the portal.

Force Subnet Group

Selecting this option forces clients on the specified subnet to always use the group selected as the Subnet Group (instead of using any groups that may be defined in LDAP, for example).

Subnet Group

This drop-down lists all of the groups configured on the Group Permissions page. The group selected here will be used for unauthenticated users on an Optional authentication subnet, and for all users on a subnet with Force Subnet Group enabled.

If Required authentication is not selected, workstations with a Cipafilter authentication client installed will be automatically authenticated and filtered based upon the workstation users' group memberships. Workstations without the Cipafilter authentication client will be filtered based upon the Subnet Group setting for the subnet, with the option to authenticate as another user via the portal system or proxy settings.

Insert Remote-Filtering (1-to-1) Rule

This button, shown at the bottom of the list of authorized subnets, inserts a rule into the table to be used for remote filtering / 1-to-1 initiatives. This is simply a shortcut for creating a rule for the subnet, which acts as a "catch-all" for any clients not specified on another subnet. Because the rule authorizes anyone on the Internet to use the filter as a proxy, it is strongly recommended that authentication be Required for this subnet.

Advanced Configuration

This tab contains more advanced filtering and reporting settings.
  1. Proxy listens on port ____   defines the port on which the Cipafilter listens for (non-transparent) proxy connections. By default, the filter uses port 6226. (8080 is often used instead, but it is a frequent target of port scanning.) The proxy port must not interfere with other services running on the filter, so values like 22 and 80 are prohibited.
  1. Enable Web reporting toggles reporting of Web activity (searches, violations, etc.). This feature must be enabled to make use of the Web Reports feature, as well as many of the notifications on the Notifications page.
  1. Enable application reporting toggles reporting of Bandwidth Control and Application Control data. This enables the analysis of non-Web traffic in Web Reports .
  1. Respect X-Forwarded-For header toggles the behavior of the proxy server with respect to the HTTP X-Forwarded-For header, which is used by many proxy servers to pass a client's original IP address to upstream servers. (For instance, if a client with IP address attempts to access a Web site via the proxy server, the Web site will only see the latter address, unless the proxy server provides the former via X-Forwarded-For or similar.) When this option is enabled, the Cipafilter will use the X-Forwarded-For address (where available) in its logs and reports. However, placing other proxy services behind the Cipafilter is strongly discouraged.

Proxy Auto-Configuration (PAC)

Many browsers and operating systems support the use of a PAC (proxy auto-configuration) file. There are several benefits to this feature:
  1. Centralized configuration — PAC files can be deployed to a large number of devices, which will then automatically pull down future configuration changes.
  1. Customization — PAC files may incorporate advanced logic in order to control precisely when and how different clients are able to access certain sites.
  1. Bandwidth/performance benefits — It is often undesirable to pass requests for software updates and the like through the proxy server; a PAC file can be used to instruct clients to bypass the proxy when making these requests. In cases where the user is remote, this can offer significant bandwidth and performance advantages on both sides.
  1. Security — Recent browsers support secure HTTPS proxy, which encrypts all traffic between the client and the proxy server. This prevents malicious actors from obtaining proxy users' credentials or viewing their Web traffic (even unsecured Web traffic is encrypted). So far, most browsers that implement this feature require a PAC file to make use of it.
PAC files can be maintained and deployed in a number of different ways, but, for the sake of convenience, each Cipafilter offers its own pre-configured and ready-to-use files. These are available under the following locations at all of the filter's Web addresses:
  1. /pac/proxy-auto.pac — HTTPS (secure) with HTTP (insecure) fallback for clients that don't support it. This file is recommended for use with mixed and legacy devices.
  1. /pac/proxy-https.pac — HTTPS (secure) only. No compatibility is offered for clients that don't support secure proxy. Using this file prevents legacy devices from accidentally leaking proxy credentials.
Both of these files require the use of a custom portal domain (see Portal Certificate ) in order to facilitate the secure proxy functionality.

The following additional options are offered to control clients' interactions with the proxy server:
  1. Requests for local IP addresses bypass proxy — Passing requests for local IP addresses (such as through the proxy is usually unnecessary, and can in fact disrupt access in some cases. Enabling this option allows clients to bypass the proxy when accessing local network services.
Unless Pre-resolve DNS names to IP addresses is enabled (see below), this option will only have an effect when the client has explicitly requested a URL containing an IP address.
  1. Requests for plain (domain-less) host names bypass proxy — When a client requests a host name without a domain (for example, fileserv), it is usually the case that the host exists on the local network. Enabling this option allows clients to bypass the proxy when accessing services with these "plain" host names.
  1. Requests for hosts/URLs on Super Whitelist bypass proxy — Entries on the Super Whitelist usually correspond to software-update services, app stores, and so on, which either don't work with the proxy or generate so much traffic that they can overwhelm it. Enabling this option allows clients to bypass the proxy when the site they're requesting would be subject to the Super Whitelist . This is especially helpful for remote users.
There are some limitations as to which Super Whitelist entries can be accounted for in the PAC file. Notably, URLs with paths and many REGEX: entries are not supported.
  1. Pre-resolve DNS names to IP addresses — By default, the PAC file only tests against the host that the client has explicitly requested (whether it be a DNS name or an IP address). When this option is enabled, the browser will be instructed to pre-resolve DNS names to IP addresses so that the PAC file can also check those (where applicable). For example, if the client requests the domain foo.bar.com, and that domain resolves to the local IP address, the request will be correctly detected as a local IP when this option is enabled.
There is a minor impact on client-side performance when this option is enabled, since the browser has to look up the IP of every DNS host. Most browsers cache the result, so it is usually not a significant issue, but it can cause problems if DNS resolution is slow or unreliable. Issues may also occur if the client's DNS server returns different results from the filter's.
  1. Requests for IPs in Destination-Based Exceptions bypass proxy — Enabling this option checks client requests against the subnets defined on the Destination-Based Exceptions list. Pre-resolution (see above) must be enabled for this option to function.
PAC files can be deployed by the filter's DHCP server via the WPAD URL setting on the DHCP Server page.

Google Apps Domain Restriction

Many Google Web properties, including Gmail, support a custom header which restricts log-in access to accounts which are members of a specified domain. For instance, if an organization at myschool.edu used Google Apps for e-mail and document sharing, they could restrict users to accessing those sites only through their myschool.edu accounts; trying to log in with any other accounts (including "consumer" Gmail accounts) would result in an error.

To make use of this feature, select Restrict Google Apps access to domains ____ and enter your organization's Google Apps-enabled domain(s) — multiple domains can be separated by commas, e.g. myschool.edu, myschool.com. Then, enable the corresponding option for each desired group on the Group Permissions page.

The google.com domain must be subject to SSL decryption for this feature to work. For more information, please see Block access to consumer accounts - Google Apps Help.


By default, Web downloads are run through the filter's anti-virus engine. Unchecking the Enable anti-virus option will globally disable this functionality. It is strongly recommended to leave this and all other anti-virus features enabled, unless there is another equivalent facility on the network or running locally on client machines.

PDF files are a common vector for infection, as the PDF format is extremely complex and featureful, potentially allowing arbitrary code execution. When a PDF is passed to the anti-virus system, it will be flagged as potentially malicious if it can not be assessed for safety due to the file being encrypted or similar. This is considered good security practice; however, some organizations which deal frequently with documents from multiple sources may be frustrated by this behavior. In this case, PDF scanning may be disabled entirely by unchecking the Perform PDF anti-virus scanning option.

Similarly, encrypted files (including ZIPs, PDFs, and others) may contain an infection source, and the anti-virus system by default blocks these files as well, since they can not be scanned. Unchecking Block encrypted archives and PDFs will disable this behavior.

The options for disabling PDF scanning and disabling encrypted archive scanning both affect PDFs — the former disables all scanning of PDF files, while the latter disables all scanning of encrypted files (including encrypted PDFs). While both options have their advantages and disadvantages, disabling encrypted archiving scanning is recommended in situations where the trouble is specifically with encrypted documents, since non-encrypted PDFs will still be scanned.

Destination-Based Exceptions

Destination-based exceptions can be used to prevent the transparent filtering of traffic to the specified subnets. These exceptions apply both to transparent proxy and to group-blacklist blocking performed by the application firewall ( Application Control ); they do not apply to browser/OS proxy, to the standard Firewall , to manual Application Control rules, or to Bandwidth Control .

A single IP or subnet may host assets for multiple services, or host multiple services itself — for example, it is common for many different Web sites to use the same cloud-computing network. Indiscriminately adding exceptions for networks like these can open access to services that one might not expect. It is recommended that this feature be used as sparingly as possible.


Authentication settings for proxy services and the captive portal are configured here. Cipafilter supports multiple authentication methods via a fall-back scheme — any number or combination of methods may be supplied, and the filter's authentication engine will try each in order until one succeeds or the list is exhausted.

Because the available methods are tried one at a time, each additional entry added to the list may incur a certain performance cost at authentication time. For this reason, it is recommended that the most frequently used methods be listed first. For example, if teachers use one directory service and students use another, the students' service should usually be placed ahead of the teachers', since it will be authenticated against far more often.

Supported LDAP directory services include Windows Active Directory , Apple Open Directory , and Novell eDirectory . To utilize LDAP authentication, a search base and the IP of your directory server must be provided. Active Directory authentication also requires access to a user account that has read permissions for all of the directory's user/group objects. Each LDAP method additionally supports SSL (LDAPS) — it is strongly recommended that this option be enabled, where available, to prevent users from intercepting traffic between the filter and the directory server. Most LDAP-based directory software provides this functionality.

Cipafilter does not currently check the validity of the certificate used for LDAPS, since most directory servers use self-signed certificates.

The filter can often detect the domain and/or search base required for a specified LDAP server; clicking the Auto-detect LDAP settings (magic wand) button can auto-fill these values into the table, where available. The auto-detection feature does not auto-fill the SSL/LDAPS setting — please configure this accordingly before pressing the button.

In addition to LDAP services, Cipafilter can also use Google Directory as an authentication back-end. This feature enables the use of Google Apps as a directory service; users will be authenticated according to their Google credentials, and group memberships will be derived from their Google groups (distribution lists). In order to select this option, you must configure a Google service account and provide domain-specific information in the Domains and Administrators table on the Google OAuth tab; each domain so configured can be added to the Authentication table to enable authentication via multiple Google Apps directories. For more information, see Google OAuth .

Authentication is also supported via the local User Manager service — please see User Manager for details.

Filter groups are defined on the Group Permissions page. Each user who successfully authenticates will be checked for membership in a group of the same name in the directory service. If a membership is found, the user will be configured according to the permissions of that group. If no membership is found, the permissions for the default group (or the effective Subnet Group ) will be used instead.

Cipafilter checks these group memberships upon each user's first access and caches the information for up to one hour, depending on the protocol. Click Save and Apply on the User Manager page of the Web interface to clear this cache.

Under this section you will also find a link to the Authentication Tools page; this page is intended for troubleshooting, particularly with the assistance of tech support, and can be used to view/modify the current state of the filter's authentication system.

Portal Settings

  1. Users with browser proxy settings prefer portal for authentication By default, clients using browser proxy settings to interact with the filter (that is, clients subject to the non-transparent proxy mode) authenticate via their operating system or browser's credential prompts. Enabling this option will instead redirect these users to the portal, giving them effectively the same authentication experience as transparently proxied clients. If Use Portal is disabled for the user's subnet, they will continue to use the normal proxy authentication methods.
  1. Block all non-Web traffic when authentication is required By default, when Required authentication is enabled for a subnet, Web access (ports 80 and 443) is blocked to affected clients until they authenticate. For some organizations, this is sufficient. However, it does leave other ports open, potentially allowing clients to access non-Web-based network resources (for example, chat clients or file-sharing software). Enabling this option will prevent this, by extending the block to (almost) all other traffic until the client has been authenticated.
  1. Use Google OAuth for portal authentication   This option enables a special Google "front-end" log-in method, which displays a Sign in with Google button on the portal. Clicking this button will direct the user to a page where they can authenticate with their Google credentials, which are subsequently passed back to the filter. In order to enable this option, the Portal OAuth Client section on the Google OAuth tab must be filled in correctly. For more information, see Google OAuth .
  1. Allow non-Google (LDAP) log-ins from portal By default, when using the Google OAuth portal log-in, the normal "back-end" log-in form (which accepts credentials for the authentication services specified above) is disabled. Checking this box will re-enable this log-in form. This is useful if some users do not have Google accounts, but do have credentials on the back-end.
  1. Expire portal authentication after ____ This field specifies the default amount of time a portal log-in session should last for. The default value is 12 hours, but it can be increased or decreased according to an organization's needs. For instance, a school may wish to have the session last only until the end of a class period. This value may be overridden for non-persistent authentications on a per-group basis via the Group Permissions page (if the option is set there, that value will be used; otherwise, this one will).
This value also applies to guest users. See the description of the Persistent portal authentication option for more information regarding how these two settings interact.

RADIUS Accounting

Cipafilter is able to track user log-ins via RADIUS accounting. In this scenario, a supported network access server (NAS), such as a wireless access point, negotiates authentication with a dedicated RADIUS server, which subsequently forwards accounting data to the filter. As the filter receives this data, it updates its authentication database accordingly, authing or de-authing users as required.

This feature requires one or more independent RADIUS servers, each configured to forward accounting information to the filter, as well as one or more NAS devices which communicate with the RADIUS server(s). In order to integrate with Cipafilter, each NAS must support the Framed-IP-Address accounting attribute. (This attribute is supported by many enterprise-class wireless solutions, including Cisco/Meraki and Aruba.)

To enable this feature, configure your RADIUS server(s) to forward accounting information to the filter (using a shared secret key for security). Then add each server's address and its shared key to the RADIUS Accounting table. (The filter's RADIUS service is automatically enabled when a server is defined here.)

When a user attempts to access the network via a NAS, the NAS device will ask the RADIUS server to authenticate the user. If successful, the server will forward the authenticated user name and IP address to the filter, which will be (re-)injected into the local authentication database. Note that the RADIUS server does not pass group or password information; as such, the filter will always use the group information from the first authentication back-end on which the user name exists.

At this time, a Cipafilter can not act as a RADIUS server itself — in other words, it can not handle RADIUS authentication/authorization requests on its own. A dedicated server must be configured to interface with the NAS.

Google OAuth

The Cipafilter can interface with Google via OAuth 2.0 to provide both portal and Google Directory back-end authentication services. This can be configured for one or more domains. For detailed instructions on configuring these features, please see Google OAuth .

Service Account Key

A Google service account is a special account authorized to act on behalf of an administrative user and to access resources without requiring user interaction. A unique client ID is generated and stored along with other identifying information in a JSON service account key file. When that key file is uploaded here, the client ID displayed can be authorized to access Google resources across myriad domains.

Domains and Administrators

For each domain that you intend to use for Google authentication, you must provide a domain and the e-mail address of an account in that domain with administrative access.

Portal OAuth Client

In order to make use of Google OAuth as a portal authentication method, the settings in this section must be filled in, and a Google domain administrator account authorized. For detailed instructions on obtaining or configuring these values, please see Google OAuth .

  1. Client ID for Web Application — This field should match the Client ID value from the Google Developers Console.
  1. Client Secret for Web Application — This field should match the Client Secret value from the Google Developers Console.
  1. Google Apps Domain — This field should contain the Google Apps domain (the part after the @ in your Google Apps e-mail addresses) used to create this OAuth client.
  1. Redirect URIs — These values are generated by the filter; they are provided to facilitate the initial set-up of Google OAuth for your domain.
  1. Google Access Token — This field will indicate whether Google OAuth is properly configured. If it does not, you may need to click Authorize a Google Domain Administrator Account.
This section is also used in legacy (non-service-account) configurations to authorize the filter for Google Directory access.

SSL Compatibility

By default, the Cipafilter is unable to see inside of secure (HTTPS) connections. SSL decryption is a process whereby the filter inserts itself between the client (browser) and the server (Web site) and builds its own HTTPS connection between the two. This allows the filter to make use of all of its standard capabilities, such as URL blacklisting, pornography detection, and anti-virus, just as it could with an insecure connection. The initial set-up for this process is handled on the SSL Compatibility tab.

To perform SSL decryption, the Cipafilter must be able to generate and serve local SSL certificates to clients connecting to secured sites. A root certificate authority (CA) is required to sign these certificates; creating this root CA is accomplished by entering the desired information into the Root Certificate Information section and then clicking the Generate Certificate button below. The specified information will appear in the certificate details for any filtered HTTPS connection.

After the certificate authority has been generated, SSL decryption will be available to all filter groups; the exact decryption behavior, including which sites should be decrypted, can be configured on the Group Permissions page.

Although generating the certificate authority is technically the only requirement to enable SSL decryption functionality, users will repeatedly be prompted to ignore security alerts in their browsers (or even be prevented from accessing certain sites entirely) unless they have trusted the generated CA. Users can download the CA certificate at any time by visiting the captive portal ( portal.cipafilter.com/ssl ); it will also be installed automatically (for browsers which respect the operating system's certificate store) by the Cipafilter authentication clients for Mac and Windows.
Generating and deploying a root certificate is strongly recommended, even if SSL decryption is disabled, as the same certificate may be used when presenting block pages and redirecting unauthenticated users to the captive portal. Clients that have not been configured to trust the filter's root certificate will repeatedly encounter SSL handshake errors and/or security warnings in these circumstances, potentially causing user confusion and impacting the performance of the filter.

A note about the HTTPS protocol

HTTPS is not a fully separate protocol from HTTP; rather, it is HTTP over a secure connection. In other words, all of the traffic within the secure layer works in the same way as non-secure HTTP traffic. This is an important distinction for a filtering appliance, as it affects what the filter can and can't do with secure connections.

When a client (such as a Web browser) accesses a secure Web site, it creates the secure connection before any actual HTTP traffic is passed back and forth. This is why it is not possible to blacklist entire URLs when SSL decryption is disabled — the URL request occurs inside of the secure connection, so the filter can't see it without intercepting that connection.

Another consequence of this behavior is that the domain name the client establishes the connection with may not be the same as the domain name of the specific Web site it is trying to reach. This is because multiple Web sites may use the same IP address, and the traditional method of distinguishing between different sites on the same address (the HTTP Host header) is, once again, only visible from inside of a secure connection.

To address this problem, a technology called Server Name Indication (SNI) was created, and Cipafilter uses this to make the black- and white-listing of HTTPS sites more accurate. However, this functionality only works when the client supports it. Notably, older mobile browsers and versions of Internet Explorer running on Windows XP have no SNI support, nor do many non-browser applications (such as Google synchronization tools). Accordingly, blacklist entries may have unexpected results when these clients are involved.

    • Related Articles

    • Manual - Web Reports

      This newer Web-reporting system features an improved interface, better filtering, new data, and several other additions over the legacy system. User interface Most Web-reporting report pages offer the following interface features: Date picker — The ...
    • Manual

      This article provides links to the individual sections of the Cipafilter product manual.  A PDF of the Cipafilter product manual is attached to this article. Introduction Interface Conventions Installation Status Management Users Hot Spare ...
    • Manual - Introduction

      Cipafilter is a powerful routing platform capable of delivering an evolving tool set to protect your enterprise. Cipafilter's philosophy is to provide a cuing edge, well rounded, and aggressive network control solution to meet your current and future ...
    • Manual - Interface Conventions

      Most page/section headers, as well as certain option labels, within the Web interface can be clicked to produce the relevant section of this manual. Clicking a Save Changes button will cause the configuration options on any particular page to be ...
    • Manual - Group Permissions

      Permissions for groups of users are managed here. Each group has individual settings for the different filtering technologies available, as well as a separate whitelist and blacklist. On this page, you can also edit the global whitelist and blacklist ...