CIpafilter Documentation - Web Filtering
Posted by Jim Giseburt, Last modified by Jim Giseburt on 09 May 2017 05:18 PM
The first thing to decide with regard to Web filtering is whether to run individual subnets in transparent or non-transparent (proxy server) mode.
In transparent mode, no client configuration is required — the Cipafilter simply intercepts all traffic on ports
In non-transparent mode, each client must be configured to make use of a proxy service provided by the Cipafilter (on port
Subnets Authorized to Use Proxy Services
Only machines with IPs in the subnets listed under Subnets Authorized to Use Proxy Services will be allowed to use the proxy server. Subnets are provided inCIDR notation. If two subnets overlap, the smallest or most specific subnet's configuration applies (just like in the Routing configuration), with the exception of the Transparent Proxy option as described below.
Note: The Cipafilter's non-transparent proxy functionality is "always on" for any subnets listed here (although you need not use it).
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.
Note: 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).
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 Optionalauthentication subnet, and for all users on a subnet with Force Subnet Group enabled.
Note: 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 Groupsetting 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
When Web Reporting is enabled, user activity and filter trips are collected for the Web Reports system to analyze. If this feature is not enabled, the Cipafilter will not record user activity other than for the purpose of e-mailing the administrator when the Web filter is tripped.
The Proxy Port is the port that the Cipafilter listens for proxy connections on when being used as a non-transparent proxy. The default value is
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
To make use of this feature, select Enable Google Apps domain restriction and enter your organization's Google Apps-enabled domain(s) — multiple domains can be separated by commas, e.g.
By default, Web downloads and e-mail attachments 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.
Note: 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.
Transparent Proxy Exceptions
When in transparent mode, connections to subnets listed under Transparent Proxy Exceptions will not be intercepted by the proxy server. This is useful for applications and services which are not compatible with the transparent proxy method.
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.
Note: 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. Note that 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 OAuth 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, the Google OAuth Settings section must be filled in correctly. 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
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.
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.
Block all non-Web traffic when authentication is required
By default, when Required authentication is enabled for a subnet, Web access (ports
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 Google OAuth Settings section must be filled in correctly. For more information, see Google OAuth.
Note: This option is ignored when using the Google OAuth back-end; since the Google back-end and the portal can not function together without the Google front-end, the front-end is always enabled when the back-end is in use.
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.
Note: Since the Google OAuth back-end does not accept bare credential log-ins, this option is forcibly disabled when Google is the only configured the only configured authentication service.
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). Please note that 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.
Google OAuth Settings
In order to make use of the Google OAuth options on this page, 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.
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
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.
Note: 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.
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 Configuration 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 SSL 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.
Please note that, 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.
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
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.
The captive portal is SSL-encrypted (that is, it uses the HTTPS protocol) for security. Without this encryption, it would be extremely easy for anyone on your organization's network to view the traffic moving between other clients and the portal, and by inspecting that traffic, they would be able to capture the user names and passwords of anyone logging in.
To achieve protection from this sort of snooping, the portal must use a certificate. This certificate is in turn signed by a certificate authority (CA). By default, the CA used to sign the portal's certificate is the same one which is created in the SSL Configuration section (mentioned above).
However, this default configuration can be problematic:
The Portal Certificate feature provides a solution to all of these concerns, by allowing an organization to specify its own custom certificate, particularly one which has been signed by a trusted public CA.
To use the feature, enter the desired information into the Custom Certificate Information section. Much of this will be the same as what is entered under SSL Certificate Information (described above). The Common Name field is of particular importance — it represents the site address that will be used for the portal when this feature is active. As an example, an organization with the domain
Once the certificate information has been entered, clicking Generate Request will generate a certificate signing request (CSR) for download. This CSR file is used by a certificate authority to generate the needed certificate file. Simply submit this file to the certificate provider of your choice, such as Namecheap or GoDaddy. Typically, one can expect a certificate suitable for this purpose to cost between 5 and 30 USD per year. Note: Cipafilter does not endorse or recommend any particular certificate provider.
The certificate provider should respond with a public certificate and a CA bundle; once these are in hand, they need simply to be uploaded to the filter via the Upload Custom Certificate Data section.
It is also possible for an organization to use a wildcard certificate or one signed by an internally trusted CA, but this is not currently exposed to the Web interface. If you would like assistance configuring the portal this way, or if you have any other questions at all, tech support will be happy to assist you through the process.
Finally, whatever Common Name is chosen for the portal must have a record on or accessible to whatever DNS server (internal or external) the portal's clients are using. The recommended configuration is to point the custom domain to the special "bogon" IP address that the filter uses for the portal internally — this address is