I-Space Research Labs

The poor man’s Websense

by on Mar.02, 2015, under Uncategorized

Like Squid but don’t want to deal with the headache of trying to block entire categories of websites? Do you like Websense but don’t want to pay a lot of money? Well, I have a solution work looking at! Consider the power and flexibility of Squid, with an icap server that can deal with categories of websites, policies based on username, group membership, or ip subnets while providing additional security features such as deep page inspection, blocking of specific file types, and blocking of ads and tracking sites.

What is icap?

Icap stands for “Internet Content Adaptation Protocol”, which is a HTTP-like protocol that proxies can use to offload certain functions such as virus scanning or content filtering. In this case, we will be using Squid to send ICAP data to qlproxy, which will tell the Squid server whether to deny or allow the connection. Qlproxy is an easy to install icap server that has a function similar to Websense, where it has a collection of websites that have been categorized into groups such as “porn” or “social media”, making it easier to allow or block things at a higher level than through normal Squid acls and blacklists.

Part of the icap specification is sending the authenticated username (if one is provided) and the client’s IP address. Qlproxy has provision for multiple policies, so a specific policy can be set to a group of users or subnets, while another policy can be applied to a different group of users or subnets. This administration is done through an easy to use web ui, and can be running with a few clicks.

Note that this setup will be utilizing Squid’s ssl-bump feature so that the decrypted request can be sent to the icap server for analysis. If this bothers you, you can disable this feature, but you will be blind whenever a user goes HTTPS. SSL-bump is a feature that allows Squid to terminate the SSL connection, much like Websense or an F5 load balancer. The client attempts to make an SSL connection through Squid, and Squid will make the connection to the client’s target, while generating a dynamic SSL cert to be presented back to the client. Since Squid now has both sides of the conversation, it is essentially a bump in the wire or, more accurately, a man-in-the-middle. The request and response data can be decrypted by Squid and send to the icap server for analysis.

For example, if we were using an icap-capable proxy such as Squid, we could send this data to a DLP server such as Vontu (now Symantec DLP). DLP would then send a response back to block the connection if a content rule was violated- such as certain words or key phrases that indicated that proprietary information was leaving the company, or potentially harmful data was being downloaded. We will be using this feature so we can examine where the client is going during an HTTPS session.

Squid Configuration

This setup will require Squid3. You can either install it as a prepackaged binary provided that it was compiled with the correct features enabled, or you can install it from source. The setup for squid3 is pretty straightforward from source, so this is the route that I chose.

The features that I wanted: icap client, ssl-bump and NTLM support for seamless and transparent authentication for MSIE and Firefox clients.

So. Download the Squid source, unpack and configure:

configure –enable-icap-client –with-openssl –enable-ssl –enable-ssl-crtd –enable-auth-basic –enable-auth-ntlm –enable-external-acl-helpers=wbinfo_group

make && make install

It’s a good idea to make sure that you have the latest libraries for things like OpenSSL. I tested this build on Kali, which had just about all the dependencies already, and CentOS which required some library installation.

So the first thing is to configure Squid and get basic proxy services working. Remember that if you’re compiling from source, you’re likely going to need to make a squid user for the daemon to drop down to, and that it will need to own the logs and cache directories. While I like the squid.documented config file, it tends to get a little unwieldily after a while working with it, so I’ve gravitated towards the squid.default config file as it’s pretty concise and very basic to get Squid up and running.

SSL-bump

Now we will enable SSL bumping. Squid will dynamically generate a certificates for the website that the client is requesting to connect to. Obviously, the client’s browser will need to trust certificates issued by Squid, so you will need to import Squid’s public certificate into your certificate store.

First, create a self-signed CA certificate for Squid.

openssl genrsa -out squid.key 2048

Second, create the certificate signing request

openssl req -new -key squid.key -out squid.csr

Finally, sign the certificate

openssl x509 -req -days 3650 -in squid.csr -signkey squid.key -out squid.cert

Squid.cert will need to be installed in your client’s browsers. I also tend to keep like things together, so if my installation directory is /usr/local/squid, I will make a /usr/local/squid/certs directory and put the certificate and key there.

Now the change to the squid.conf file:

http_port 3128 ssl-bump cert=/usr/local/squid/certs/squid.cer key=/usr/local/squid/certs/squid.key generate-host-certificates=on dynamic_cert_mem_cache_size=4MB

always_direct allow all

ssl_bump server-first all

sslproxy_cert_error allow all

sslproxy_flags DONT_VERIFY_PEER

sslcrtd_program /usr/local/squid/libexec/ssl_crtd -s /usr/local/squid/ssl_db -M 4MB

sslcrtd_children 5

After saving changes to squid.conf, you will need to prepare the certificate cache for the certs that Squid will be creating dynamically.

/usr/local/squid/libexec/ssl_crtd -c -s /usr/local/squid/ssl_db

And the squid user must own the cache directory:

chown squid:squid /usr/local/squid/ssl_db

I’ll be a nice guy and explain what these options mean

http_port 3128 ssl-bump cert=/usr/local/squid/certs/squid.cer key=/usr/local/squid/certs/squid.key generate-host-certificates=on dynamic_cert_mem_cache_size=4MB

This is the standard “Squid listens on port 3128” line and modified to enable ssl-bumping. We then specify where the privkey and public cert are located. Squid is then told to generate certificates dynamically, and that the maximum cache size is 4MB.

always_direct allow all

This tells Squid to always forward the request to the origin server without going to cache

ssl_bump server-first all

This tells Squid to go out and create the connection to the origin server first, so it can generate an SSL certificate or pull one from cache, and then create the SSL connection between Squid and the client.

sslproxy_cert_error allow all

This tells Squid to allow connections to SSL servers that have funky or suspicious certificates

sslproxy_flags DONT_VERIFY_PEER

This tells Squid to not to worry about certs that fail verification

sslcrtd_program /usr/local/squid/libexec/ssl_crtd -s /usr/local/squid/ssl_db -M 4MB

sslcrtd_children 5

These lines tell Squid where the SSL certificate generation helper program is, and how many child process can be run

Now start Squid and go to a SSL-secure website. Check the website cert, it should not throw a “certificate not trusted” error, and should be issued by your Squid server. Once this is working, you can proceed to installing the ICAP server.

Installing qlproxy

So once Squid is working, it’s time to install qlproxy and get Squid talking to it. Qlproxy can be downloaded at http://www.quintolabs.com/download_linux.php. Qlproxy has some dependencies before it can be installed, namely python, Django, Apache and some modules. The documentation at Quintolabs.com will tell you exactly what you need to install based on your distribution. If you install qlproxy after installing all the dependencies, it will generally modify your httpd.conf so that the site is activated.

Modifying Squid to talk to qlproxy

## ICAP stuff

icap_enable on

icap_preview_enable on

icap_preview_size 4096

icap_persistent_connections on

icap_send_client_ip on

icap_send_client_username on

adaptation_send_client_ip on

adaptation_send_username on

icap_client_username_header X-Client-Username

icap_service qlproxy1 reqmod_precache bypass=0 icap://127.0.0.1:1344/reqmod

icap_service qlproxy2 respmod_precache bypass=0 icap://127.0.0.1:1344/respmod


Leave a Reply

Looking for something?

Use the form below to search the site:

Still not finding what you're looking for? Drop a comment on a post or contact us so we can take care of it!

Visit our friends!

A few highly recommended friends...

Archives

All entries, chronologically...