Вряд ли сейчас найдется системный администратор, работающий в сфере образования, который не знает что такое ФЗ-436 "О защите детей от информации, причиняющей вред их здоровью и развитию" со всеми вытекающими последствиями. Наиболее острой для меня эта проблема стала после получения распоряжения от руководителя подготовиться к приходу прокуратуры. Из известных на тот момент мне решений:
- Squid + DG + каким то образом настраивать обновление списков, которые должны коррелировать со списком запрещенных ресурсов Минюстом
- Решения для рабочих станций (NetPolice, iCensor и т.п.)
- Различные "виндосерверные" решения, выступающие в роли шлюза
ни одно не показалось мне привлекательным. Имея маломощный сервер и 50 рабочих станций, нуждающихся в защите, хотелось бы использовать Unix-like решение. Очевидно, что без Squid не обойтись. Начались поиски решения удовлетворяющего установленные требования. В результате был найден интересный вариант от не безызвестной компании Entensys, выпускающей ПО под названием UserGate. Программное решение для контентной фильтрации называется UserGate WebFilter. Основываясь на опыте давно ушедших лет, тех лет, когда интернет траффик был дороже золота, и, когда прокси был просто необходим, UserGate не нравился ввиду своей глючности и ресурсоемкости (в контексте тех самых прошлых лет), однако, позабыв старые обиды, а также несмотря на то, что продукт проприетарный, было решено его опробовать.
ЧАСТЬ 0. Возможности продукта
.
Перечислю наиболее важные для меня возможности:
- Фильтрация по двум направлениям: DNS и HTTP
- Морфологический анализ страницы
- Наличие автоматически обновляемых черных и белых списков доменов, морфологической базы
- Приятная мелочь - фильтрация результатов поисковых запросов
- Возможность гибкой настройки всего вышеперечисленного через веб-интерфейс
- И самое главное: соответствие требованиям законодательства
Всю остальную информацию, в том числе цены и полный перечень возможностей можно получить на сайте Entensys.
ЧАСТЬ 1. Подготовка к установке
Что касается системных требований: как заявляет сам производитель, ПО будет работать на следующих ОС:
- Ubuntu Server 12.04 i386, amd64
- Ubuntu Desktop 12.04 i386, amd64
- Debian 6, 7 i386, amd64
- CentOS 6 i386, amd64
Минимальные требования к железу, до 100 пользователей: Intel® Atom™ D2500 1.86GHz, 2Gb RAM, HDD 500Gb
Ну и разумеется прокси сервер Squid, собранный с поддержкой ICAP-клиента, а так же клиентский машины, заранее настроенные на использование прокси. Требования к версии Squid не указываются, однако интуиция подсказывает что достаточно не менее 3.0.
На деле имеется следующее: Intel Core2Duo, 4GB RAM с установленной Debian 7 на борту и Squid3 в режиме transparent.
ЧАСТЬ 2. Установка
У компании Entensys имеются свои репозитории, поэтому установка до безобразия тривиальна:
sudo apt-get install webfilter3
Первоначальная настройка сводится к следующему:
- Заходим в веб-интерфейс по адресу serverip:4040
- Выбираем тип узла "Главный"
- Указываем пароли и жмем "Установить"
- Настраиваем Squid по инструкции в документации
Webfilter генерирует все необходимые конфигурационные файлы и запускает демоны.
Сразу после установки напугало количество прослушиваемых портов, однако в моей ситуации, с политикой DROP в цепочке INPUT таблицы filter, особой угрозы это не представляет. Во всей этой куче прослушиваемых портом различимы 1344 (ICAP сервер), 4040 (веб-интерфейс), 10053 (backend для DNS Запросов).
По ходу адаптации нового ПО к локальной инфраструктуре столкнулся с такой особенностью: помимо основного демона webfilter3 имеется так же init скрипт webfilter3_rules, который при старте добавляет правила в iptables для перенаправления всего входящего dns траффика на 10053 порт, для его фильтрации, а также, правила для перенаправления http траффика. Для меня (параноика), имеющего собственноручно настроенный firewall, вмешательство в таблицы iptables было просто недопустимо, поэтому:
sudo /etc/init.d/webfilter3_rules stop sudo insserv -r webfilter3_rules
Теперь встает вопрос о том, как фильтровать входящие dns запросы. Логичным кажется перенаправление через iptables с порта 53 на 10053. Для тех у кого нет собственных dns записей, у кого весь dns-траффик беспрекословно форвардится на другой сервер, это решение отлично подойдет (или оставить включенным webfilter3_rules). У меня же имелись статические записи в /etc/hosts и в конфиге dnsmasq, кроме того, имелись особые опции работы dnsmasq. Поэтому я решил поступить следующим образом:
#/etc/dnsmasq.conf no-resolv server=<server-ip>#10053 //Важно указать ip сервера из той же подсети, в которой находятся фильтруемые клиенты.
При такой конфигурации dnsmasq будет перенаправлять запросы, на которые не смог ответить сам, DNS фильтру.
ЧАСТЬ 3. Настройка
Настройка работы фильтра осуществляется через веб-интерфейс. Все детали настройки подробно расписаны в документации. Краткий алгоритм минимальной настройки следующий:
- Добавляем группу пользователей. Настраиваем используемые списки. В моем случае были использованы все встроенные списки
- Добавляем пользователей. Доступны следующие механизмы авторизации:
- ip
- диапазон ip
- логин: пароль посредством radius-сервера
- Создаем правила фильтрации:
- Для наиболее строгой фильтрации, логика правила должна быть "ИЛИ"
- Выбираем категории сайтов которые будут запрещены (порнография и насилие, мошеннические сайты и пр.)
- Выбираем категории морфологии, которые будут учтены при анализе содержимого страницы
- Настраиваем индивидуальное расписание работы правила. (В случае если логика правила "ИЛИ", логичным будет оставить все дни пустыми, в противном случае, правило будет срабатывать при любом запросе в отмеченный день)
- Активируем созданное правило фильтрации в настройках пользователя или группы
- Изменяем адрес страницы на которую будет перенаправлен пользователь в случае блокировки страницы
- Проверяем работу правил:
- Переходим в меню "Проверить URL"
- В качестве проверяемого адреса используем pornhub.com или pornolab.net
- Нажимаем проверить
- В случае правильной настройки результат должен иметь следующий вид:
где не пустое значение в поле "Блокировка по правилам" означает что правило включено и работает
Минимальная настройка произведена и достаточна для полноценного функционирования фильтрации, далее, используя документацию, настраиваем фильтрацию под свои собственные нужды.
ЧАСТЬ 4. Тестирование
Скорость
Закономерный вопрос: "Насколько фильтрация замедляет загрузку сайтов". Изначально хотел провести тестирование и сравнить скорость загрузки различных сайтов и предоставить результат в виде таблицы. Замеры производились с помощью инструментов разработчика встроенных в Chrome. Если в случае с загрузкой без фильтра можно было вычислить среднее время загрузки исходя из 10 запросов, то под фильтром время загрузки колебалось уже очень сильно, в некоторых случаях от 100 до 500 мс, поэтому я решил что такой сравнительный анализ ничего не даст. Факт в том, что время загрузки возрастает, самое большее что мне удалось поймать - в 3 раза. Однако, имея высокоскоростной интернет, разница между 100 мс и 300 мс, глазу не ощутима, разница между 200 мс и 600 мс ощутима совсем слегка и особого дискомфорта не доставляет. В общем, по субъективным ощущениям, сайты грузятся быстро.
Фильтрация
Фильтрация в UserGate WebFilter просто потрясающая. Список запрещенных доменов очень обширный. Большинство "плохих" сайтов на которые я пытался зайти, отбрасываются именно по спискам доменов, таким образом до морфологического анализа дело даже и не доходит.
Что касается морфологического анализа - тут тоже все очень хорошо. В качестве теста пробовал заходить на сайты, которые находятся в списке экстремистских материалов, утвержденном минюстом. Отрабатывает отлично. Тем не менее, случаи пропуска нежелательного контента тоже были, но их количество стремится к нулю.
Отказоустойчивость
На момент написания статьи сервер работает чуть более месяца, перезагрузка ни разу не потребовалась: ни демона webfilter, ни сервера целиком. В пиковые часы HTTP траффик проходит через сервер со скорость до 8 Мб\с в течении продолжительного времени. На глюки, зависания и прочие неисправности, пользователи не жалуются.
Заключение
От работы с данным ПО остались исключительно приятные впечатления. Весь заявленный функционал работает исправно. Учитывая невысокую стоимость ПО (например: на 50 ПК годовая лицензия обойдется в 13 500 р.), по моему личному мнению, данное ПО является идеальным решением контентной фильтрации в учебных заведениях.