Система фильтрации интернет-трафика

Андрей Бешков

Целью данных записок является создание простой в управлении и в то же время гибкой в настройке системы фильтрации интернет-трафика. Строить её мы будем на основе FreeBSD 4.5 + Squid + SquidGuard + Berkeley DB 3.2.9 + Apache. Стоит отметить, что обсуждаемые в этой статье приемы будут работать и на основе Linux. В принципе такой комплекс можно построить на любой UNIX-совместимой системе. Главная проблема – необходимость использования версий SquidGuard и Squid для этой системы. Apache можно заменить любым другим веб-сервером или использовать уже существующий веб-сервер. Кстати, веб-сервер можно запустить на отдельной машине под управлением любой операционной системы. Не стоит отчаиваться, если база данных Berkeley DB еще не портирована для вашей платформы. SquidGuard легко может работать и без нее.

Вы можете спросить, зачем нам нужны все эти сложности? Как и любой другой ресурс, интернет-трафик имеет обыкновение заканчиваться. Да и канал от нас к провайдеру не резиновый, отсюда вывод – необходимо тем или иным способом ограничить аппетиты пользователей. С другой стороны, если начальство поймает кого-то из сотрудников за просмотром порносайтов или скачиванием mp3, нагоняй получит не только провинившийся. Администратор будет виноват в том, что позволяет сотрудникам тратить оплачиваемый организацией трафик на всякую ерунду. В то же время стоит помнить, что каждая организация имеет свои правила использования ресурсов сети Интернет. Довольно часто в списке запретов можно встретить не только эротику, но и сайты анекдотов, форумы и чаты. Например, бесплатные почтовые сайты могут быть запрещены из соображения секретности. Одновременно можно запретить пользователям скачивать из внешней сети выполняемые файлы. Это существенно снижает опасность вирусного заражения сети.

Кроме того, перед нами все еще стоит задача экономии трафика. Существенно снизить его потребление поможет запрещение бесполезной для нас баннерной рекламы. Вы могли бы спросить, что в баннерах плохого? Squid – кеширующий прокси-сервер, соответственно, скачиваемые файлы ложатся в локальный кеш. При следующих запросах эти файлы уже не будут скачиваться из Интернета. Проблема в том, что баннерная реклама построена на применении механизма CGI (Common Gateway Interface), расшифровывается как «общий интерфейс шлюза». Характерным признаком которого является использование знака «?» в адресной строке запроса. Например, адрес одного из баннеров «Украинской Баннерной Сети» выглядит так: http://banner.kiev.ua/cgi-bin/bi.cgi?h" + user + "&"+ pid + "&" + page + "&2.

К сожалению, CGI используется не только для баннерной рекламы, но и для чатов, форумов, сетевых магазинов и прочей полезной сетевой функциональности. То есть везде, где необходимо получить от пользователя данные. Затем полученные данные должны быть обработаны, а результаты работы CGI необходимо вернуть пользователю. Значит для каждого пользователя не только запросы, но и ответы будут разными. Поэтому класть полученные документы в кеш squid бесполезно. По умолчанию squid не использует кеш при работе с динамическими документами. В свою очередь, это значит, что одни и те же баннеры будут выкачиваться бесконечно. Подменяя баннеры пустыми картинками с локального веб-сервера, можно значительно снизить количество потребляемого трафика.

Многие администраторы, столкнувшись с этими проб-лемами, могут утверждать, что они легко решаются с помощью штатных средств Squid. Я не стану отрицать, что Access Control List (списки контроля доступа), сокращенно ACL, используемые в Squid, – это довольно мощный инструмент. Но для работы с ним требуется достаточно большой опыт. С другой стороны, трудно представить, как администратор будет разбираться, какие сайты он должен блокировать. Остается только вслед за пользователями ходить на все часто посещаемые сайты, и постепенно запрещать неугодные. Учитывая количество сайтов в Интернете, а также распространенность баннерной рекламы, такой путь выглядит утопией. В начале такого ошибочного пути кажется, что нужно всего лишь записывать все запрещенные сайты в отдельные файлы с помощью ACL-записей типа:

acl porno src "/usr/local/squid/etc/porno.lst"

acl erotic src "/usr/local/squid/etc/erotic.lst"

А затем запрещать их всех скопом. Но обслуживание такой системы способно превратиться в головную боль уже на первой тысяче сайтов. Squid загружает списки контроля доступа в оперативную память. С добавлением новых сайтов размер файла будет постоянно расти. Соответственно, и Squid будет занимать все больше оперативной памяти. В связи с тем, что список запрещенных сайтов неупорядочен, поиск в нем будет занимать довольно продолжительное время. SquidGuard выполняет за 12 секунд 100 000 запросов к базе, содержащей 205 900 записей. Тестирование проводилось на машине с процессором Pentium 500 МГц. Такой скорости удается добиться за счет того, что SquidGuard хранит список сайтов в форме B-дерева. Как мы видим, средствами Squid все вышеописанное выполнить достаточно тяжело. И тут в поле нашего внимания попадает класс программ под названием редиректоры. С разной степенью легкости эти программы позволяют решать наши проблемы. Используемый нами SquidGuard тоже является редиректором. Давайте коротко опишем его возможности.

n  Может разрешить доступ некоторой группе пользователей только к избранным сайтам.

n  Блокирует доступ пользователей к определенному списку адресов.

n  Помогает блокировать доступ к сайтам на основе списка регулярных выражений.

n  Запрещает использовать IP-адреса вместо доменных имен внутри URL.

n  Дает возможность перенаправить пользователей, пытающихся получить доступ к запрещенным страницам, на другую страницу, где им будет объяснена причина запрета.

n  Помогает перенаправить запросы на доставку часто скачиваемых файлов, таких как MSIE, Netscape Navigator или ICQ, к их локальным копиям.

n  Позволяет использовать разные политики доступа в зависимости от времени дня, текущей даты, дня недели.