С помощью SquidGuard расширяем возможности Squid для фильтрации доступа к сетевым ресурсам

Ранее, в статье «Блокировка нежелательных сайтов списком в Squid», я приводил пример настройки Squid на запрет доступа пользователей к отдельным сайтам в соответствии с приведенным списком в текстовом файле. Теперь займемся расширением возможностей Squid путем дополнения функциональности пакетом SquidGuard.

Конфигурационный файл Squid, несмотря на кажущуюся простоту, позволяет настраивать довольно сложные правила доступа. Если внимательно почитать прилагающуюся документацию, то средствами самого Squid, можно решить массу проблем.

Однако, часто появляются реально сложные задачи, которые средствами Squid не решить. В таких ситуациях поможет SquidGuard. Это довольно мощное расширение для Squid, существенно расширяющее возможности настройки правил доступа и перенаправления пользователей. Помимо этого, есть ряд ресурсов в сети, где можно скачать уже готовые списки сайтов, разбитые по категориям.

1. Установка пакета SquidGuard

Данная статья — продолжение ранее приведенной статьи «Блокировка нежелательных сайтов списком в Squid», поэтому все объяснение строится на том, что у Вас уже установлено и настроено необходимое программное обеспечение и Вы используете дистрибутив Linux Debian.

Устанавливаем пакет SquidGuard:

# apt-get install squidguard

После установки должен появится конфигурационный файл SquidGuard /etc/squid/squidGuard.conf. Пока SquidGuard не настроен и не фильтрует Интернет трафик.

2. Установка базы данных для SquidGuard

Работа SquidGuard, в первую очередь, строится на анализе Black Lists (Черные списки Интернет ресурсов). Эти списки формируются несколькими группами на коммерческой и некоммерческой основах. Список этих групп можно посмотреть на сайте SquidGuard. Я предпочитаю использовать списки публикуемые на сайте http://urlblacklist.com/. К моменту написания статьи у них было более 2 миллионов доменов, которые разбиты по тематике, тем самым облегчается задача описания правил доступа к ресурсам. Недостатком этой базы является практически полное отсутствие ссылок на российские ресурсы, при чем это касается не только большой кучи  мелких и крупных порно-ресурсов, файлообменных сетей, варезников и прочего мусора, но и крупные социальные сети, видео хостинги и развлекательные ресурсы отсутствуют там в принципе. Что удивительно, в списках есть довольно много сайтов Украинских, при чем некоторые из них являются дочерними проектами российских или просто их дополнительными доменными именами (алиасами), но самих этих крупных ресурсов нет!  Короче, частично список придется дополнять самостоятельно.

Итак, скачиваем файл списков с сайта производителя, который больше пришелся по душе.

Распаковываете содержимое архива в каталог /var/lib/squidguard/db. Даем права доступа пользователю и группе proxy:

# chown -R proxy:proxy /var/lib/squidguard/db

Все, база данных плохих и хороших сайтиков для SquidGuard у нас готова! Теперь осталось настроить сам SquidGuard и подключить его к Squid.

3. Описание правил доступа для SquidGuard

Первым делом, чтоб не особо по-портить конфигурационный файл SquidGuard, сделаем его копию:

# cp /etc/squid/squidGuard.conf /etc/squid/squidGuard.conf-old

Открываем наш /etc/squid/squidGuard.conf и приводим его к виду (что к чему, объясню ниже):

dbhome /var/lib/squidguard/db
logdir /var/log/squid

time workhours {
 weekly mtwhf 08:00 - 23:30
 date *-*-01  08:00 - 16:30
}

src foo-clients {
 ip        192.168.1.0/24
}

dest good {
}

dest local {
}

dest social {
 domainlist    social_networks/domains
 redirect    http://www.ya.ru
}

acl {

 foo-clients within workhours {
 pass     good !in-addr !social any
 }

 default {
 pass     local none
 }
}

Теперь разберем для чего нужны все эти загадочные конструкции по секциям:

  1. time workhours — задается временной интервал в рамках которого применяется правило. Полезно, если нужно иметь один фильтр в рабочее время, другой — в нерабочее.
  2. src foo-clients — в конструкциях src задаются группы клиентов. Группировать клиентов можно по разным параметрам. Более подробную инфу в документации можно найти. В данном конкретном случае мы задаем сегмент адресов собственной локальной сети. В группах допустимо указание сегментов вида 192.168.1.5-192.168.1.15 — группа с 5 по 15 адрес.
  3. desc social — в конструкциях desct описываются назначения. В данном случае мы берем список доменов социальных сетей из скачанной ранее базы данных и отправляем пользователя на сайт Yandex. Вместо Яндекса можно указать очень грозную страницу, чтоб этому пользователю в социальные сети расхотелось заходить на работе. :-)
  4. acl — тут описываются правила доступа с учетом описанных ранее групп источников и получателей. В данном случае, группе foo-clients (пользователям нашей локальной сети), разрешено ходить по всем сайтам в рабочее время, кроме прямых IP-адресов и социальных сетей.

4. Подключение SquidGuard к Squid

Процедура подключения очень простая. В файл /etc/squid/squid.conf необходимо добавить строку:

redirect_program /usr/bin/squidGuard -c /etc/squid/squidGuard.conf

После чего перезапускаем Squid:

# /etc/init.d/squid restart

Если сделано все верно, при попытке зайти на facebook.com в период времени с 8 утра до 23:30, должна отобразиться страница поиска Яндекс.

Если обозреватель завис и очень долго ждет ответа от запрошенного узла, значит SquidGuard сконфигурирован неверно и не обрабатывает запросы. О причинах можно узнать в лог файлах в каталоге /var/log/squid.

5. Итоги настройки связки Squid и SquidGuard

В статье рассмотрена базовая настройка SquidGuard, но приведенная информация поможет с успехом развить Ваш сервер.

Еще раз хочу обратить внимание, что в приведенной базе сайтов SquidGuard отсутствуют многие российские ресурсы, поэтому Вам нужно дополнительно потрудиться, чтоб исключить из работы высь мусор.

Особое внимание стоит обратить на возможные попытки доступа пользователей к анонимным прокси, которые позволяют обходить правила корпоративного прокси сервера. Однако правило !in-addr уже отсекает довольно большое количество этих прокси, поскольку в списках они публикуются без DNS имен — одни IP-адреса.