Last modified 7 months ago Last modified on 2011-10-16 11:42:31

Frequently Asked Questions

  1. Blocking of Sites, Domains and URLs
    1. How to Block Specific Domain/URL
    2. How to Block IP Addresses in URL

  1. Blocked / Redirected HTML Page
    1. What Is Incident ID?
  1. Filtering Exclusions
    1. Why exclusion list is not reloaded after HUP?


Blocking of Sites, Domains and URLs

How to Block Specific Domain/URL

In order to block specific domain, site or url open the qlhttpb.conf file situated in /opt/quintolabs/qlproxy/etc/httpblock.conf and add a regexp entry in the form of <url = regexp>.

For example, to block Google's image search add the following entry url = http://.*\.google\.com/imghp\?.* to the blacklist. To block youtube.com, facebook.com or twitter.com add the following entries to the blacklist:

   url = http://.*\.youtube\.com/.*
   url = http://.*\.facebook\.com/.*
   url = http://.*\.twitter\.com/.*

How to Block IP Addresses in URL

It is sometimes required to block access to web sites by their IP addresses (this technique is typically used by users to avoid URL filtering). In order to do that open the httpblock.conf file situated in /opt/quintolabs/qlproxy/etc/httpblock.conf and add the following regexp entry:

   url = http://\d+\.\d+\.\d+\.\d+/.*

Blocked / Redirected HTML Page

What Is Incident ID?

The "Access Denied" HTML page that is shown to user when the system detects a forbidden request/response contains the so called "Incident ID". This ID can be used by the administrator to find out the reason why the specific request/response was blocked. Type the following in your terminal

   cat /var/opt/quintolabs/qlproxy/log/access.log | grep <specify the incident id>

the results printed on the screen will show the reason for blocking (AD, HTTP BLOCK, URL BLOCK and so on). It is also possible to find the log entry for a blocked response in the web UI of the qlproxy on the incidents page.

Filtering Exclusions

Why exclusion list is not reloaded after HUP?

Q: The /opt/quintolabs/qlproxy/etc/exceptions.conf file states that after I modify settings in it the only thing I have to do is to issue the HUP signal to qlproxyd daemon. But when I do that the newly added exclusion entries are not working?

A: The internal design of the qlproxyd daemon is geared toward keeping current active incoming ICAP connections intact after a HUP reload. It means that all only new connections are processed with modified configuration settings (i.e. new exclusion settings). Squid on the other hand uses persistent connection in ICAP transactions with qlproxyd - so it is possible that new connection from browser to squid will be processed by the old connection from squid to qlproxyd - thus making new exclusions seem to not work.

The workaround here is either wait a little when you are not interested in immediate application of new exclusion settings or just restart the qlproxyd daemon.