Cipafilter Support:
Support@Cipafilter.com
309 517 2022 option 2
Mon - Fri 7 AM - 6 PM CT
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 80 and 443 as it moves through the router.

In 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

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).

Transparent Proxy

  • Yes — HTTP and HTTPS connections from this subnet will be transparently intercepted by the Cipafilter. When SSL decryption is configured for a group on this subnet, the HTTPS traffic will be inspected/altered in essentially the same manner as HTTP traffic; if decryption is not available, HTTPS connections will be subject to domain-based black- and white-listing only (URL blacklisting, content-aware filtering, anti-virus, and other features which rely on the unit being able to "see inside" the connection will not function).

  • No — Connections from this subnet will not be transparently intercepted by the Cipafilter unless they fall under another subnet entry in the list. (For example, a rule setting 10.1.2.0/24 to Yes will still apply to 10.1.2.3/32 if the latter is set to No.)

  • Disable — A specific rule will be created to prevent transparent interception of this subnet (overriding any other Transparent Proxy rules that may apply).

Authentication

  • 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).

  • 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).

    Note: 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.

  • 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

  • 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.

  • 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.

    Please note that, 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.

  • 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.

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).

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 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 0.0.0.0/0 subnet, which acts as a "catch-all" for any clients not specified on another subnet. Because the 0.0.0.0/0 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

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 6226 (8080 in earlier versions).

The X-Forwarded-For header is an HTTP feature which allows a proxy service to pass the IP address of the originating client. (For instance, if a client with IP address 1.2.3.4 attempts to access a Web server via the proxy server 4.3.2.1, the Web server will only see the latter address, unless the X-Forwarded-For header is provided by the proxy server.) When this option is enabled, the Cipafilter will use the X-Forwarded-For address (where available) in its logs and reports.

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 Enable Google Apps domain restriction and enter your organization's Google Apps-enabled domain(s) — multiple domains can be separated by commas, e.g. myschool.edu, myschool.com — into the Allowed Google Apps Domains field. Then, enable the corresponding option for each desired group on the Group Permissions page.

Note: 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.

Anti-Virus Settings

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

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 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

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 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.

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.

  • Client ID for Web Application — This field should match the Client ID value from the Google Developers Console.

  • Client Secret for Web Application — This field should match the Client Secret value from the Google Developers Console.

  • Google Apps Domain — This field should contain your organization's Google Apps domain (the part after the @ in your Google Apps e-mail addresses).

  • Redirect URIs — These values are generated by the filter; they are provided to facilitate the initial set-up of Google OAuth for your domain.

  • 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.

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.

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.

SSL Configuration

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 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.

Portal Certificate

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 site will be accessible only from the portal.cipafilter.com address, which some organizations are uncomfortable with for security or branding reasons.

  • The portal will display a security warning message to any user who has not yet trusted the filter's CA. This message is unattractive and confusing.

  • Some clients, particularly the browsers on older mobile devices, won't display a warning at all — the portal will simply fail to load entirely.

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 myschool.edu may wish to use portal.myschool.edu as their portal's Common Name. The Common Name must not match the host name of the filter itself.

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 192.0.2.1.

(0 vote(s))
Helpful
Not helpful

Comments (0)
©Cipafilter 2017. All Rights Reserved.