From: Олег Палухин
Date: Mon, 18 Jun 2009 17:02:14 +0000 (UTC)
Subject: Устанавливаем во FreeBSD связку Squid + squidGuard + с-icap
Материал предоставлен редакцией журнала Системный администратор.
Опубликовано в журнале "Системный администратор" N 3 2009
Работа современного офиса сегодня немыслима без Интернета. Как
ограничить доступ к нежелательным ресурсам в Сети, отнимающим у
сотрудников рабочее время? В этом поможет совместная работа
прокси-сервера Squid с редиректором запросов SquidGuard и сервером
ICAP.
Общеизвестно стремление среднестатистического офисного работника к
свободному серфингу на просторах Интернета, особенно в рабочее время,
особенно когда на расстоянии пары кликов различные "Одноклассники" и
"В Контакте", наконец когда появляется все больше и больше программ и
сервисов, не требующих установки на компьютер, а довольствующихся лишь
наличием выхода в Интернет, и программой - обозревателем
интернет-страниц. Отсюда возникает насущная необходимость для
руководства предприятия направлять подобного рода "веб-деятельность"
своих сотрудников ближе к их прямым рабочим обязанностям.
В качестве одного из решений можно использовать прокси-сервер доступа в
Интернет Squid в сочетании с URL-редиректором squidGuard, а
также организовать проверку http-трафика на вирусы. Для выполнения
последней задачи в нашей компании применили Clam Antivirus, работающий
через сервер ICAP (Internet Content Adaptation Protocol). Предлагаю
вашему вниманию небольшую заметку об установке и настройке
вышеупомянутых продуктов для совместной работы по обеспечению доступа
пользователей к Интернету.
Прежде чем приступить непосредственно к описанию установки перечислю
то, что уже должно быть установлено на вашем сервере:
n операционная система - мы будем производить установку на FreeBSD
7.1-SATBLE;
* веб-сервер - подойдет любой от Apach до lighttpd;
* брандмауэр - pf, ipf или ipfw, настроенный для прозрачного
перенаправления http-запросов пользователей на порт прокси-сервера
Squid, мы использовали pf.
Используемое программное обеспечение и его версии:
* прокси-сервер Squid - версия squid-3.0.13;
* squidGuard, URL redirector - версия squidGuard-1.4;
* ICAP-сервер c-icap - версия 060708.
Установка Squid
Прокси-сервер Squid представляет собой весьма гибкое в конфигурировании
и обладающее широкими возможностями средство для организации доступа
пользователей в Интернет. Я опишу здесь простую конфигурацию, вполне
пригодную для использования в небольших или средних по количеству
сотрудников организациях.
Устанавливаем Squid из портов FreeBSD, перемещаемся в директорию порта:
# cd /usr/ports/www/squid30/
В config-опциях после команды:
# make config
отмечаем нужные:
SQUID_DELAY_POOLS;
SQUID_PF;
SQUID_ICAP.
Теперь смело собираем и устанавливаем программу:
# make && make install && make clean
Затем меняем содержимое конфигурационного файла squid.conf в директории
/usr/local/etc/squid/:
# Привилегированный пользователь
acl BosS src 172.25.1.3
# Наша локальная сеть - источник запросов к прокси-серверу
acl LocalneT src 172.25.0.0/16
# ICQ, как и любой другой порт, можно разрешить или закрыть, ниже будет понятно как
acl IcQ port 5190
# На каком порту принимает запросы Squid, опцию transparent здесь не указываем, так как Squid
# собан с поддержкой прозрачного проксирования с помощью пакетного фильтра pf (опция SQUID_PF)
http_port 8080
# Пускаем всех из локальной сети в Интернет
http_access allow LocalneT
# Запрещаем всем остальным
http_access deny all
# Здесь указываем программу-редиректор, у нас -- это squidGuard. В предыдущих версиях Squid этот параметр
# назывался redirect_program
url_rewrite_program /usr/local/bin/squidGuard -c /usr/local/etc/squid/squidGuard.conf
# Управление скоростью доступа в Интернет посредством пулов
# Количество пулов доступа
delay_pools 2
# Первая цифра -- номер пула, вторая -- класс пула, мы используем пулы только первого класса,
# без деления на подсети
delay_class 1 1
# Отдельному пользователю 10 Кб/с
delay_class 1 1
delay_parameters 1 100000/100000
delay_access 1 allow BosS
delay_access 1 deny all
# Поддержка функционала icap-клиента:
icap_enable on
icap_preview_enable on
icap_preview_size 128
icap_send_client_ip on
icap_service service_avi_req reqmod_precache 0 icap://localhost:1344/avscan
icap_service service_avi respmod_precache 1 icap://localhost:1344/avscan
icap_class class_antivirus_req service_avi_req
# Для каждого имени icap_service указываем отдельную строку icap_class, а не все сервисы
# в одной строке, как предлагается в configuration guide на сайте проекта c-icap:
# "icap_class class_antivirus service_avi service_avi_req", иначе Squid при запуске выдаст сообщение:
# "WARNING: Multiple ICAP services per icap_class
# are not yet supported."
icap_class class_antivirus service_avi
# Соответственно получаем две строки icap_access для двух классов icap_class
icap_access class_antivirus_req allow all
icap_access class_antivirus allow all
Отмечу, что в примере конфигурационного файла не указана директория
хранения кеша запросов и его максимальный размер, это говорит лишь о
том, что используются значения этих параметров по умолчанию, которые
можно посмотреть в файле /usr/local/etc/squid/squid.conf.default. С
Squid все. Запускать его без squidGuarda пока не будем. Еще раз скажу,
что здесь описан простой случай прозрачного проксирования без множества
существующих в Squid полезных вещей, таких как аутентификация
пользователей, параметры оптимизации кеширования и пр.
Установка squidGuard
SquidGuard также легко находится в портах - /usr/ports/www/squidguard/.
Просто устанавливаем его как обычно:
# make && make install && make clean
Во время установки squidGuard поместит списки блокировки в
/var/db/squidGuard и сделает их принадлежащими учетной записи squid и
группе squid, - что должно совпадать с учетной записью, под которой
работает прокси-сервер Squid (см. значения переменных
cache_effective_user и cache_effective_group в файле
/usr/local/etc/squid/squid.conf). Можно пользоваться этими блэклистами,
можно другими, коммерческими или бесплатными; вся информация по
получению блэклистов есть на http://squidguard.org/blacklists.html ,
я беру их здесь: http://cri.univ-tlse1.fr/blacklists . Получив так
или иначе архив с блэклистами, распаковываем их в директорию, которая в
файле конфигурации squidGuard.conf указана в значении параметра dbhome,
и не забываем, что dbhome со всем содержимым должен принадлежать
пользователю squid. Теперь перейдем к настройкам в
/usr/local/etc/squid/squidGuard.conf, ниже пример содержания этого
файла с краткими пояснениями:
# Место расположения блэклистов и логов
dbhome /var/db/squidGuard/blacklists
logdir /var/log
# Можно задавать ограничения доступа по времени и дням
# сокращения для дней недели: #s = sun, m = mon, t =tue,
# w = wed, h = thu, f = fri, a = sat
# У нас описаны дневные часы ежедневно c 6 утра
# до 10 вечера, что будет использовано ниже
time WORKHOURS {
weekly * 06:00 -- 22:00
date *.*.01 06:00 -- 22:00
}
# От кого будут приходить запросы
source LOCALNET {
ip 172.25.0.0/16
}
# Далее идут собственно описания ресурсов (так называемые
# DESTINATION CLASSES), доступ к которым запрещен (blacklists)
# или разрешен (whitelists) - указание на содержимое dbhome;
# мы будем использовать только блэклисты
# Название подкаталога блэклистов
destination adult {
# Указание на блэклист доменов, здесь указываются,
# какие домены блокируются, -- т.е. если в файле
# указан domen.com, то закрыт доступ к домену
# полностью и к host.domen.com и к games.foo.domen.com
# и т. д. Могут быть указаны также только поддомены,
# например subdomen.host.com: это закрывает доступ
# только к поддомену и ко всем его cобственным
# поддоменам, а доступ к host.com остается открытым.
# Но обратите внимание! Если в файле доменов указаны
# и domen.com и subdomen.domen.com, то доступ будет
# закрыт только к этим двум доменам, а, скажем,
# foo.domen.com будет доступен
domainlist adult/domains
# Указание на блэклист URL, т.е. блокируется доступ
# к конкретным страницам, если указано
# example.com/some/path/to/page.html, то блокируется
# доступ только к
# http://www.example.com/some/path/to/page.html,
# http://example.com/some/path/to/page.html,
# http://ftp.example.com/some/path/to/page.html
# Файл регулярных выражений в URL запроса, используется
# стандартный синтаксис, который можно узнать
# по man regex; здесь можно запретить, например,
# всевозможные мультимедиа-файлы:
# (.mp3|.wmv|.flv|.avi|.mp4)$
expressionlist audio-video/expressions
}
destination blog {
domainlist blog/domains
urllist blog/urls
# Так включается запись в лог нарушителей, пытавшихся
# пройти на запрещенные ресурсы
# И, наконец, пишем кому (LOCALNET), когда (within WORKHOURS)
# и куда запрещен/разрешен доступ, здесь у нас запрещен
# доступ по всем вышеописанным блэклистам
# URL, заменяющий запрещенный к доступу -- то,
# что увидит пользователь - любитель фривольных
# ресурсов; это может быть сделанная вами
# бан-страница и расположенная на локальном
# веб-сервере, это может быть даже главная
# страница вашего корпоративного ресурса
# в Интернете
redirect http://host/ban.html
}
}
Далее просто перескажу несколько строк из документации на сайте
проекта. Перед запуском squidGuard нужно инициализировать блэклисты,
т.е. построить базу, squidGuard использует BerkeleyDB, что ускоряет
работу по проверке и блокированию запросов:
# squidGuard -C all
В зависимости от количества используемых блэклистов время инициализации
будет разным, от секунд до нескольких минут; по окончании инициализации
в log-файле squidGuard должно быть нечто, подобное этому:
2009-02-27 16:42:44 [78281] squidGuard 1.4 started (1235741910.112)
2009-02-27 16:42:44 [78281] db update done
2009-02-27 16:42:44 [78281] squidGuard stopped (1235742164.788)
После инициализации блэклистов директория, их содержащая, будет
принадлежать учетной записи root, поэтому меняем "хозяина":
# chown -R squid:squid /path/to/blacklists
Либо можно изначально провести инициализацию блэклистов от имени
учетной записи squid, если текущая учетная запись имеет на это право
(см. man sudoers):
# sudo -u squid $(which squidGuard) -C all
И можем сначала проверить, что squidGuard инициализировал листы
успешно:
Если все работает нормально, то на экране увидим redirect URL нашей
бан-страницы, указанной в squidGuard.conf:
http://host/ban.html 172.25.1.3/- - -
Можем запускать Squid:
# /usr/local/etc/rc.d/squid start
В логах Squid напишет, что запустил 5 дочерних процессов squidGuard,
эта цифра предусмотрена по умолчанию, ее можно менять в зависимости от
нагрузки на сервер в squid.conf параметром url_rewrite_children
<число_процессов>. Можно проверять работу Squid и squidGuard с
клиентских машин запросами через интернет-браузер.
Установка ClamAV и c-icap
ClamAV устанавливаем из портов (/usr/ports/security/clamav) привычным
способом:
# make && make install && make clean
Используем опции конфигурации по умолчанию, предлагаемые при установке.
Настройки демона clamd в /usr/local/etc/clamd.conf тоже можно оставить
без изменений после установки.
C-icap придется собирать и устанавливать из исходных кодов, так как на
момент написания статьи порт /usr/local/www/c-icap содержал версию
программы за июнь 2006 года, и заставить ее работать со Squid 3.0 мне
не удалось. Загружаем исходный код c-icap. Распаковываем в рабочую
директорию и собираем с такой опцией:
# ./configure --prefix=/usr/local
Дальше все, как обычно:
# make && make install
Конфигурационный файл c-icap.conf будет находиться в /usr/local/etc/,
вот его содержимое:
# файл хранения pid основного процесса icap-сервера
PidFile /var/run/c-icap.pid
# Параметр можно не указывать, но файл сокета управления
# по умолчанию должен находиться именно здесь, его нужно
# создать командой "touch /var/run/c-icap/c-icap.ctl"
#CommandsSocket /var/run/c-icap/c-icap.ctl
# Время в секундах, после которого неактивное соединение
# закрывается
Timeout 300
# Icap-сервер старается не закрывать соединение с клиентом,
# ожидая новых запросов
KeepAlive On
# Максимальное число незакрываемых соединений в ожидании
# новых запросов
MaxKeepAliveRequests 100
# Максимальное время в секундах ожидания новых запросов
KeepAliveTimeout 600
# Начальное число процессов сервера, каждый процесс
# генерирует треды для обслуживания запросов
StartServers 3
# Максимальное число процессов сервера
MaxServers 30
# Если число запущенных тредов меньше указанного,
# icap-сервер генерирует новые
MinSpareThreads 10
# Если число тредов больше указанного, icap-сервер
# убивает дочерние
MaxSpareThreads 300
# Начальное число тредов для каждого дочернего процесса
ThreadsPerChild 30
# Максимальное число запросов, которое может обслужить
# дочерний процесс, как только оно достигнуто, процесс
# умирает, 0 -- отключает параметр
MaxRequestsPerChild 0
# Порт, на котором принимает запросы icap-сервер
Port 1344
# Учетная запись - владелец процессов icap-сервера
User cicap
# Группа владельцев процессов icap-сервера
Group cicap
TmpDir /var/tmp/c_icap
# Максимальный объем памяти в байтах, занимаемый объектом,
# обрабатываемым c-icap
# Список групп типов файлов для сканирования, поддерживаемые
# типы указываются в файле /usr/local/etc/c-icap.magic,
# о котором сказано ниже
srv_clamav.ScanFileTypes TEXT DATA EXECUTABLE ARCHIVE GIF JPEG MSOFFICE
# Какой процент данных будет отдаваться сервером icap
# до выполнения проверки всех данных запроса
srv_clamav.SendPercentData 5
# Если файл больше указанного размера, то включается
# предыдущий параметр SendPercentData
srv_clamav.StartSendPercentDataAfter 2M
# Максимальный размер файлов, которые сканируются ClamAV
srv_clamav.MaxObjectSize 5M
# Максимальное количество файлов в архиве, используется
# библиотекой ClamAV, 0 отключает параметр
srv_clamav.ClamAvMaxFilesInArchive 0
# Максимальный размер архива
srv_clamav.ClamAvMaxFileSizeInArchive 50M
# Максимальный уровень рекурсии
srv_clamav.ClamAvMaxRecLevel 5
# Следующие директивы описывают режим работы
# viralator like, srv_clamav проверяет тип файла, и если
# он указан в директиве srv_clamav.VirScanFileTypes --
# загружает файл для проверки на вирусы и только потом
# отдает его пользователю ссылкой на локальном веб-сервере
# Место для скачиваемых файлов, на эту директорию должны
# быть права у вашего локального веб-сервера
srv_clamav.VirSaveDir /var/tmp/c_icap
# Интервал в секундах между сообщениями о ходе закачки
# файла для проверки
srv_clamav.VirUpdateTime 15
# Тип файлов или группы типов файлов, для которых
# используется предварительная закачка для проверки
# на вирусы; типы указаны все в том же файле c-icap.magic
srv_clamav.VirScanFileTypes ARCHIVE EXECUTABLE
# Ссылка на локальном веб-сервере на закачанный файл,
# отдаваемая пользователю после проверки файла на вирусы,
# для этого используется скрипт get_file.pl,
# расположенный в директории contrib дистрибутива c-icap
В заключение описания настройки c-icap пара слов о файле
/usr/local/etc/c-icap.magic, где перечислены группы типов файлов и
сигнатуры для их распознавания. Приведу фрагмент его содержимого,
описывающий исполняемые файлы:
Скрипт запуска устанавливается c-icap-портом FreeBSD, так как мы
собирали c-icap не из порта, у нас его не было; называем файл скрипта
c_icap, делаем исполняемым и помещаем в /usr/local/etc/rc.d/. А в
rc.conf вносим такие строки:
Наконец, запустив все необходимое, проверим работу всей связки. Для
начала можно сходить на любой запрещенный сайт - в браузере должна
появиться бан-страничка squidGuarda, после чего попробовать скачать
один из файлов с [3]http://www.eicar.org/anti_virus_test_file.htm - это
страница с тестовыми вирусами, результат обнаружения вируса показан на
рисунке.
Сообщение об обнаружении вируса в загружаемом файле
Заключение
Здесь мы привели самые простые варианты конфигурации используемых
компонентов контроля доступа пользователей в Интернет как рабочий
пример для возможных решений. В вашей власти как схемы настройки, так и
сам набор компонентов.
Vova
