New to ClearOS? Or perhaps you've used older versions in the past and are feeling a bit out of sort in setting up one of the most popular features in ClearOS - Web Proxy/Content Filter Policy on your network.
If so, this guide is for you. In under 30 minutes, we'll have a system capable of applying specific policies around:
For the purposes of this tutorial, we'll go on the assumption that you have managed to install a default ClearOS server. You've completed the post-install installation wizard and jumped right through installing any added features via the Marketplace.
Essentially…you have a 'bare-bones' install, registered to the ClearCenter SDN network.
A number of apps are required in order to put together the solution we desire. Apps are separated into packages since they may do very specific tasks or represent different third-party software upstream (eg. the web proxy engine runs Squid software.
One of the many value-adds ClearOS brings to a solution like proxy/content filtration is that all of the interoperability betweens apps is taken care of 'behind the scenes'. In doing so, huge technical barriers for novice administrators are removed by creating an integrated solution.
In this guide, we're going to be making decisions based on users authenticating to the proxy server. While there is the minor inconvenience of requiring users to login when firing up their browsers, the benefits far outweigh this requirement. Policies can apply to the same users regardless of the workstation or device they are on not to mention changes can be made with ease (eg. an employees is promoted to management and requires different policy filtration settings).
As such, the first apps we need are around users and groups. ClearOS has a backend LDAP directory for such tasks and we'll assume you want to use this. The alternative is integrating with Microsoft Active Directory if you have Microsoft assets already in place for your users, but this configuration is beyond the scope of this guide.
<note tip>If you are interested in learning more about MS Active Directory integration, go here.</note>
In addition to user/group directory, we need a proxy server, a content filter and time of day plugin.
<note warning>For best performance, ClearCenter's Content Filter Blacklist and Updates is highly recommended…especially if you are worried about sites that use encryption or need to comply with industry-specific regulations.</note>
Flip through the available apps and find the required ones. To narrow your search, try searching on the terms like 'users and groups' and 'filter' in the search box.
Quick Select File can be used to quickly select groups of apps for ClearOS. For more information and example of QSF files for ClearOS, follow the links below:
No time for GUI's. We've got you covered:
yum -y install app-users app-groups app-web-proxy app-content-filter app-web-access-control
<note warning>Installing paid apps via command line/YUM is not possible. You'll need to install, for example, app-content-filter-updates, via the Marketplace.</note>
You should now have all the apps installed and ready to be configured to your use. For our example, we'll need three users to be created in the directly since we want to be able to show how to setup these users in different policy groups and have different settings applied. <note tip>If you have a lot of users, you can save time by installing an using the account import tool</note>
Navigate to System –> Users in Webconfig. We'll create three users, 'Thomas' and 'Rick' and 'TC'. Don't forget to enable the web proxy extension…it is required if a user is to be able to access the proxy server.
Good…we have our users defined.
Time to move on to groups. Groups will allow us to create policy definitions on up to 10 different groups and is very convenient in applying policies to large user directories.
You can name your group anything you want. You may already have groups defined with appropriate users in them (eg. sales, engineering etc.). This is fine if it works for you…but you may want to create groups specific to the task of applying content filter. Keep in mind a policy will apply to the first group match for a user authenticating to the proxy. If a user is in more than one group, you may get unexpected results.
For the sake of this example, we'll create two groups, 'leadership' and 'team_members' with the intention of giving leadership more lenient access to both time of day access and what content can be accessed.
Navigate to “System –> Groups” and create your groups. If you have a mail server installed, you will see an option to create a mailing list. This is not required unless you are using your groups for more than proxy/filter definitions.
With both users and groups configured, time to start up some services and make some initial configuration settings.
<note warning>An assumption is being made that your ClearOS is the acting gateway having at least two network cards - one external and the other for the LAN. If you are doing proxy/filter services on a system with 1 NIC, you'll need to use WPAD and/or firewall settings on your gateway or need to configure each client browser to use the proxy server.</note>
In Webconfig, navigate to “Gateway→Web Proxy”. Under “Settings”, click “Update”. Select “Non-Transparent + Authentication”. In the right hand menu, ensure the service is started (by starting the service, it will automatically be configured to re-start on boot.
<note warning>These days, in Transparent Mode, the proxy is becoming less and less effective as the internet is increasingly using https. Google now prefers to return https links rather than http links. The transparent proxy con only intercept http traffic and not https traffic. It is now only recommended to use one of the Non-Transparent modes only.
Because of the extra complexity of setting up workstations to use the proxy in non-transparent mode, and because of the system resources required to run the Proxy/Content Filter, imstead, Clearecenter recommend you run the Gateway Management app, available from the Marketplace</note>
<note warning>Non Transparent mode requires you to make configuration to the client browser. A firewall rule will automatically be created to prevent users from going out through standard ports (80/443). The benefit, in addition to authentication, is that you can enforce policy on domain names (not page content) on sites using HTTPS protocol (encrypted traffic).</note>
With the proxy running, let's configure the content filter. Under “Gateway→Content Filter” in Webconfig's menu.
In the 'App Policies' table, you'll see a default policy. As its name implies, this is the policy that will apply to any user where a match does not occur (due to group association). We're going to create two policies, one mapped to our 'leadership' group and the other associated with our 'team_members' group. In this way, the user Thomas (member of 'leadership') will get one policy, while Tom's team (Rick and TC) will have a different policy applied.
To create a policy, click 'Add' in the App Policies table. Simply add a policy name and select from the group dropdown to associate with users in a group.
At the end, you should have something like the settings in the table screenshot below.
For the purposes of our guide, let's configure one of the policies and make a tighter restriction on the content viewable by the group. Click on “Configure Policy” on the 'partial_access_policy_filter' policy then select “Blacklist”. Add a site like slashdot.org to block for this policy group…something that we can test against later to ensure our settings are in effect.
At this point, proxy/content should be working. To verify, edit your browser settings to enable the use of the proxy server.
In Firefox, setting the proxy is located under “Edit→Preferences→Advanced”. Select the “Network” tab and click “Settings”.
Select “Manual Proxy Settings” and enter the IP address of the LAN side of your ClearOS gateway. Port 8080 is the default for the content filter.
Close your browser and re-open it. An authentication dialog should pop up asking for your username/password. Authenticate as your user with the less restrictive access (Thomas, in our example) and navigate to our differentiator domain, slashdot.org. Access should be allowed.
Now close the browser, re-open, and login as either Rick or TC. Try navigating to slashdot.org. You will now be blocked from accessing the site with a message similar to the one below.
Of course, we've done the bare minimum in configuring the content filter policies…In fact, all we've done is to add a domain to the blacklist of one in order to prove to ourselves that the proxy filter policies are being applied to the correct user/group mapping.
At this point, you are encouraged to explore all of tools available to an administrator to modify how users browse the Internet. Click on “Configure Policy” for a specific policy group. You'll get a summary like the screenshot below. Click edit on any category to configure detailed settings of the filter.
Aside from maintaining different black/white lists, settings like:
all combine to make for a very configurable policy.
Now that the proxy and filter settings are complete, time to move on to the time-of-day access control. This app (if you have installed it) is optional and provides an simple interface to restrict the proxy's use to certain times of the day.
Before you can create any rules, you need to create one or more time definitions. These definitions will be re-used in the Access Control List rules you create.
In Webconfig, navigate to “Gateway→Web Access Control”. You will see two empty list boxes…the first containing your rules and the second containing your time definitions.
Since we're adding a time definition (or two), click on the “Add” button in the Time of Day Definitions summary. You will see the following form:
The form's fields are quite self-explanatory. Create your time entries using a a name that is easy to recall what the configuration is focused around. For this example, we'll create two time definitions named:
Keeping in line with our 'leadership' and 'team_members' theme, we'll let leadership have access to the proxy server at any time. For the team_member group, we'll take the rather extreme position of blocking them during business hours (Mon-Fri, 9:00-17:00) - more to illustrate usage than something to model your own configuration from.
After creating your rules and returning to the summary page, your Time of Day Definitions should be populated like so:
Time to create some rules. Under the “Access Control List” table, click “Add”. You'll see the following form:
Again, the form fields are pretty-much self-explanatory, but it is easy to trip up (and many administrators do) without some thought as to their configuration and application.
Using our example, let's create a time of day rule for the leadership group. Again, our sample rule won't be that inspiring, however, we're just looking to provide simple examples that can then be built on to create very complex rule sets.
The “Type” of rules allows you to either provide access or block. As simple as this field is, it makes many admins stumble because it will be the first matched rule that applies. The rules priorities are inferred based on the order they appear in the summary table. We'll see how to move rules up and down in priority in the next section, but for now, just keep that in the back of your mind when determining how you want to control usage.
For Leadership, we'll select “Allow” as a type, as we want to create a positive hit on this rule any time someone from the leadership group hits the proxy at any time of day.
Select a time of day rule created in the previous step. For 'leadership', we'll select “NoTimeRestriction”. This time rule says Sunday through Saturday from 00:00 to 24:00, apply this rule. Effectively, we have set no restrictions on when Leadership can access the proxy.
The “Restriction” field allows us to select whether the time definition we created is to apply to the rule when the actual time is within it's range or outside it's range. For Leadership, we want within time restriction. For our second rule for the 'team_member' group, we're going to go with the opposite to show you how it all works.
The final two fields let's us choose how to implement identification. We've been using user-based authentication based on groups and we're going to stay with that method here by selecting “Group” as method of identification and selecting the “leadership” group from the dropdown.
<note tip>MAC and IP based identification is available in the time of day access control, however, these methods are not supported inside the content filter app. See IP (or MAC) Based Identification section below for more information.</note>
Let's go ahead and create a second rule for the 'team_members' group so that we can verify things are working just as we did with the test domain, slashdot.org, in the previous sections.
For this group, we're going to effectively says “when the time is within a normal workday, block all users from accessing the proxy who have authenticate as a user belonging to the team_member group”.
If you're following along with the example, your summary page on the Web Access Control app should look something like this:
As mentioned earlier, the entry of each rule representing the priority is critical in setting up your configuration. The first rule to match as the logic proceeds from the first entry in the table to the last precedes all others.
In our simple case, order/priority doesn't matter since one rules applies to one group and another rule to a separate group. But it's not difficult to see how stacking up rules helps make this tool very flexible…for example, giving access to the proxy server at three intervals during the day - morning break, lunchtime and an afternoon break.
A quick note about rule type…if you are using many allow rules and if no rules match, you wish to block the user from accessing the proxy, you need to create a 'catch-all' block rule and make it the very last rule in your ACL. By default, the proxy is configured to allow access, so this final rule may be necessary, depending on your configuration.
Of course, if all your rules are 'block based', you probably don't want this blank block rule at all.
All set. With the two rules in place, it's time to test our ACL rules. Fire up the browser that is configured to use your proxy server. First, let's verify that “Thomas” can access the proxy…he should never be blocked.
Authenticating as “Thomas” proves this is the case. The first rule in our ACL table is creating a match based on the group Thomas belongs to and triggers the “ALLOW” rule.
Closing the browser and assuming you're testing this during business hours, re-start the browser client, this time logging in as the user 'tc'. You will get a blocked message from ClearOS indicating no access to the proxy is allowed at this time. This is because the user 'tc' does not belong to the leadership group, so this rule does not get triggered. The second rule does, however, and because it is of type “BLOCK”, not “ALLOW”, the positive hit on this rules triggers an event that denies access to the proxy server.
Congratulations…you now have a very robust and configurable proxy filter with content filter and time-base Access Control.
Although the software engine supports filter policies based on IP addresses of the devices accessing the proxy, Webconfig does not support this mode at the time of writing. If IP-based policies are a requirement, you'll have to configure the configuration files for the proxy/filter by modifying them yourself. This is not a supported configuration for any ClearOS Support plan.
The logs files contain a lot of very useful information when troubleshooting the proxy/filter service. In Webconfig, navigate to “Reports→Log Viewer” and search appropriate logs.
Of particular interest (and available from a SSH shell if desirable) are:
You may even want to watch log files in real-time (eg. as you are updating/refreshing your browser screen). In this case, you could run from the command line:
tail -f /var/log/squid/access.log
If you had alot of traffic on your network, you might want to filter on a certain user's IP. In that case, make the modification below
tail -f /varlog/squid/access.log | grep 192.168.1.102
Where 192.168.1.102 would be substituted for the IP address of the device of interest.
Not being onsite can present a problem in trying to determine what is happening to clients on the LAN. If you don't have access to a remote desktop, you can use the 'squidclient' tool, installed by default. Syntax is:
squidclient -h localhost -u myusername http://www.example.com
Where 'myusername' is a valid user configured to access the proxy.