Прокси-серверы (proxy server) появились на заре эпохи Интернета, когда пользователей этой сети становилось все больше и больше, а внешние ip-адреса стоили немалых денег

Вид материалаДокументы

Содержание


HTTP прокси-сервер
HTTPS прокси-сервер
FTP прокси-сервер
SOCKS прокси-сервер
Прокси-сервер Squid
Начальные настройки squid для доступа пользователей
Изучаем acl (списки контроля доступа)
Ограничения пользователей
Ограничения по времени
Оптимизируем кеширование объектов в squid
Возможности DansGuardian
Подобный материал:


Прокси-серверы (proxy server) появились на заре эпохи Интернета, когда пользователей этой сети становилось все больше и больше, а внешние IP-адреса стоили немалых денег. Тогда основным назначением proxy-серверов являлась организация доступа в Интернет локальных пользователей без добавления их компьютеров к Глобальной сети, то есть без назначения внешних IP-адресов компьютерам, а выход в Интернет осуществлялся только с одного внешнего IP-адреса. Слово proxy в переводе с английского означает «доверенное лицо» или «представитель». Условно говоря, прокси-сервер действует от лица клиента в Интернете, и для других пользователей Сети виден только сам сервер (его IP-адрес), а не клиент (IP-адрес компьютера пользователя скрыт от посторонних глаз). Таким образом, кроме общего доступа в Интернет локальных пользователей, которые не имеют прямого выхода в Сеть, такие серверы позволяют соблюсти приватность работы в Интернете. Вследствие того, что компьютеры обычных пользователей не размещены непосредственно в Сети, снижается угроза хакерских атак, поскольку прямого доступа к компьютерам локальной сети нет.

Обычные, широко применяемые сейчас маршрутизаторы по сути являются одним из видов прокси-серверов — NAT proxy. Они тоже позволяют организовать доступ в Интернет локально подключенных к маршрутизатору компьютеров путем подмены исходящего IP-адреса в IP-пакетах. Но маршрутизатор, поддерживающий технологию NAT (Network Address Translation), имеет некоторые минусы по сравнению с обычным программным прокси-сервером. Маршрутизатор никак не анализирует проходящий через него трафик и типы протоколов, через которые пользователи работают с Интернетом, поэтому администрировать (в данном случае ограничивать пользователей по конкретным параметрам при доступе в Сеть) такие устройства практически невозможно. Прокси-сервер может находиться в любой точке Интернета и, если правила доступа разрешают, позволяет работать с любым клиентом независимо от его местонахождения. Для работы NAT, как правило, необходимо физическое подключение локального компьютера к маршрутизатору (например, через локальную сеть), поскольку маршрутизатор работает через жестко установленные маршруты пакетов. Также стоит отметить, что обычный маршрутизатор не позволяет кэшировать часто используемые объекты для более быстрого обращения к ним пользователей, поскольку он только перенаправляет пакеты от одного узла Сети к другому.

Существует несколько типов прокси-серверов, каждый из которых имеет узкую специализацию, то есть поддерживает работу только с одним или несколькими протоколами. Самыми распространенными на данный момент являются http-, Socks- и NAT-прокси. Последние входят в стандартные компоненты современных операционных систем, таких как Linux и Windows. По своим характеристикам программные прокси-серверы NAT практически не отличаются от аппаратных (маршрутизаторов) и существенно уступают в администрировании узкоспециализированным прокси-серверам. Рассмотрим наиболее популярные типы прокси-серверов.

HTTP прокси-сервер — один из самых распространенных типов прокси-серверов в мире. Как видно из названия, он предназначен для работы с HTTP-протоколом и позволяет работать браузерам и другим подобным программам. Браузер запрашивает страницу у прокси-сервера, который, в свою очередь, запрашивает ее из собственного кэша. Если страница не найдена в кэше или имеет параметры, которые запрещают ее кэширование, прокси-сервер запрашивает ее у соседнего прокси-сервера или напрямую обращается к сайту и после успешной загрузки страницы выдает ее пользовательскому приложению. Поскольку далее в статье будет рассматриваться один из HTTP прокси-серверов — Squid, перечислим основные возможности этого типа прокси-серверов:
  • позволяют кэшировать часто используемые данные (веб-страницы), благодаря чему сокращается внешний трафик и ускоряется загрузка страниц конечным пользователем. Однако Интернет становится все более динамичным, и зачастую многие веб-серверы запрещают прокси-серверам кэшировать данные или налагают ограничение на определенные страницы, поэтому прирост в экономии трафика не очень существен и может составлять до 15%. Если вопрос о трафике стоит остро, то многие HTTP прокси-серверы поддерживают игнорирование заголовков META в страницах, тем самым, позволяя кэшировать динамичные данные;
  • ограничивают доступ не только к определенным сайтам, но и к конкретным разделам сайта, за счет чего достигается большая гибкость в администрировании пользователей. Кроме того, доступ к сайтам определенной группы можно разрешать лишь после дополнительной аутентификации;
  • некоторые HTTP прокси-серверы позволяют ограничивать скорость загрузки информации, расставляя приоритеты по типам файлов. Благодаря этому можно блокировать высокую скорость загрузки, например видеофайлов или музыкальных композиций;
  • поддерживают резку рекламных блоков (баннеров) путем замещения исходной картинки или аплета своим кодом, что сокращает дополнительный трафик;
  • возможно разделение конкретных сайтов на работу через те или иные дополнительные прокси-серверы или интернет-каналы, что позволяет более экономно управлять трафиком и выбирать оптимальные каналы связи;
  • одна из важных особенностей HTTP прокси-сервера — возможность ведения подробной статистики по каждому пользователю. Это позволяет анализировать использование трафика отдельными пользователями, а также выявлять наиболее часто применяемые веб-серверы;
  • позволяют работать не только с протоколом HTTP, но и с другим подобным протоколом — FTP, а в случае необходимости — блокировать его.

HTTPS прокси-сервер — по сути дела, это точно такой же HTTP прокси-сервер, как и описанный выше. Основным отличием данного типа прокси-серверов является возможность шифрования передаваемых между клиентом, прокси-сервером и конечным сервером данных, о чем и сообщает буква «s» в его названии. Прокси-сервер, работающий по протоколу HTTPS, лишь организует канал передачи между клиентом и сервером и не позволяет анализировать проходящую по нему информацию. Соответственно возможности HTTPS, по сравнению с HTTP, существенно уже. В то же время этот прокси-сервер может быть использован в качестве прокси-сервера для иных, отличных от HTTPS протоколов — pop, smtp, imap и ряда других. В любом случае прокси-сервер такого типа значительно повышает безопасность конфиденциальной информации, хотя и имеет некоторые недостатки. Обычно HTPPS прокси-сервер совмещают с HTTP прокси-сервером, что делает его более универсальным и гибким при настройке клиентов.

FTP прокси-сервер — этот тип прокси-сервера предназначен для работы с протоколом FTP. Клиент обращается к прокси-серверу, а он передает запрос FTP-серверу. Существует два варианта работы клиента FTP через прокси-сервер. Первый вариант, когда запросы к FTP-серверу передаются через HTTP прокси-сервер, поддерживает большинство HTTP прокси-серверов, поскольку он удобен для браузеров, но при этом некоторые функции работы с FTP-сервером будут недоступны. Вторым вариантом как раз является работа через отдельный FTP прокси-сервер, и в этом случае поддерживаются все опции этого протокола — такого соединения требует большинство специализированных FTP-клиентов. Отметим, что прокси-серверы данного типа применяются редко, поскольку обычный HTTP прокси-сервер в большинстве случаев удовлетворяет потребности обычных пользователей, которые лишь загружают информацию с FTP-серверов, при этом не используя все доступные FTP-протоколу функции.

SOCKS прокси-сервер — работает на основе специально разработанного протокола SOCKS (сокращенно от SOCKetS). В настоящий момент последней версией протокола является SOCKS 5. Она позволяет производить аутентификацию пользователей на серверной стороне, что повышает гибкость настройки подобных систем. Прокси-серверы SOCKS являются универсальными и позволяют пользователю работать через любой другой протокол с практически любым видом сервисов в Интернете. Одна из особенностей прокси-серверов этого типа — возможность работы от внешних клиентов с внутресетевыми серверами, расположенными за межсетевыми экранами. Такой подход позволяет широко использовать этот вид прокси для обеспечения доступа клиентов как из локальной сети, так и в обратном направлении. Поскольку этот протокол является одним из самых популярных на данный момент, созданы специальные программы, например FreeCap (www.freecap.ru), предоставляющие возможность пропускать клиентское программное обеспечение в Интернет через этот протокол даже при отсутствии поддержки его этим программным обеспечением.

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

Прокси-сервер Squid

Проект прокси-сервера Squid (www.squid-cache.org) в свое время отделился от ныне платного проекта Harvest и разрабатывается несколькими энтузиастами во главе с Duane Wessels из Национальной лаборатории по исследованию сетей (National Laboratory for Applied Network Research). Сервер Squid — это высокопроизводительный кэширующий прокси, ориентированный прежде всего на работу с пользователями, которые занимаются активным серфингом в Интернете. Squid поддерживает работу пользователей с такими протоколами, как FTP, HTTP, HTTPS и GOPHER. В отличие от других подобных проектов, прокси-сервер Squid обладает интересной особенностью — выполнение запросов пользователей реализовано в нем как один большой неблокируемый процесс ввода-вывода, что обеспечивает более высокую производительность сервера в целом. Поскольку сервер Squid является кэширующим прокси, он поддерживает широкие возможности по построению иерархической структуры связи кэш-серверов на основе протоколов ICP/UDP (Internet Cache Protocol), HTCP/TCP и multicast. Такая система позволяет получить высокую производительность и оптимизировать пропускную способность канала в Интернет. Кэш сервера разделяется на виртуальный, который находится в оперативной памяти компьютера, и обычный, который хранится на жестком диске. Наиболее часто используемые объекты хранятся в оперативной памяти, что ускоряет процесс их отсылки клиентам. Также в виртуальной памяти хранится большая часть запросов DNS. Squid в полной мере поддерживает SSL (HTTPS), что обеспечивает конфиденциальность передаваемой пользователями информации и приватность их работы в Интернете. Также нельзя обойти вниманием широкие возможности по аутентификации пользователей на основе различных методик: NCSA, LDAP, MSNT, NTLM, PAM, SMB, SASL и др. Все дополнительные программы для аутентификации пользователей идут в комплекте с основным ядром программы. Как видно из перечисленных методик, Squid поддерживает авторизацию пользователей средствами сервисов не только на Linux-, но и на Windows-платформе (MSNT и NTLM)

Чтобы компьютер мог работать как прокси-сервер для локальной сети, он должен иметь как минимум две сетевые карты, ну допустим (eth0) смотрит в интернет и (eth1) общается с локальной сетью (на некоторых дистрибутивах требуется явное указывание метрики). Машина должна видеть компьютеры локальной сети, выходить в Интернет.

НАЧАЛЬНЫЕ НАСТРОЙКИ SQUID ДЛЯ ДОСТУПА ПОЛЬЗОВАТЕЛЕЙ

Перед тем как запускать сервер, необходимо отредактировать конфигурационный файл squid.conf, который по умолчанию располагается в папке /etc/squid/. По умолчанию ни один из пользователей не сможет воспользоваться прокси-сервером без редактирования конфигурационного файла.

Почти 3000 строк, но не пугайтесь реальный конфиг намного короче, можно редактировать дефолтный файл, а можно создать свой, предварительно сохранив старый.


Самое элементарное, что нам после установки следует сделать, так это разрешить доступ пользователям нашей локальной сети. Для этого служат параметры http_port, http_access. Кроме этого, мы заведем acl (список контроля доступа) для нашей локальной сети.


И так, http_port нам нужен постольку, поскольку наш прокси сервер Squid должен обслуживать только компьютеры нашей локальной сети и быть невидимым для внешнего мира, дабы исключить возможность "плохим людям" внешней сети воспользоваться нашим каналом или трафиком, а

в случае, если будут обнаружены "дыры" в коде прокси сервера Squid, воспользоваться ими.


Параметр http_access используется для разрешения или запрещения доступа к определенным ресурсам, определенным адресам либо с определенных адресов, к определенным сайтам, по определенным протоколам, портам и всему тому, что непосредственно указано с помощью Acl (списков контроля доступа).


Таблица N 1. Некоторые подсети.


|Диапазон адресов |Полная форма |Краткая форма

192.168.0.1-192.168.0.254 192.168.0.0/255.255.255.0 192.168.0.0/24

192.168.20.1-192.168.20.254 192.168.20.0/255.255.255.0 192.168.20.0/24

192.168.0.1-192.168.254.254 192.168.20.0/255.255.0.0 192.168.20.0/16

10.0.0.1-10.254.254.254 10.0.0.0/255.0.0.0 10.0.0.0/8



Предположим, что у Вас сеть с адресами от 192.168.0.1 до 192.168.0.254,

тогда добавим новый Acl (см. таблицу N1):


acl LocalNet src 192.168.0.0/24


Предположим, что у Вас прокси сервер Squid расположен по адресу

192.168.0.1 на порту 3128, тогда пишем в файле конфигурации:


http_port 192.168.0.1:3128


Следующим нашим действием будет запрет использования нашего прокси

сервера, кроме как пользователями нашей локальной сети:


http_access allow LocalNet

http_access deny all


В данном случае слово allow является разрешением, а слово deny

запрещением, то есть мы разрешаем доступ к прокси серверу Squid с

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


Будьте внимательны, указывая http_access, так как Squid использует их в

порядке указания Вами.


ИЗУЧАЕМ ACL (СПИСКИ КОНТРОЛЯ ДОСТУПА)


Система управления доступом в прокси сервере Squid является очень гибкой и обширной. Она состоит из элементов со значениями и списков доступа c указанием allow (разрешение) или deny (запрещение).


Формат Acl следующий:


acl имя элемент список


Формат списка доступа:


http_access указание имя_acl


Мы рассмотрим некоторые элементы, которые позволяет использовать прокси

сервер Squid, конечно же, с примерами:


* acl имя src список


С помощью этого элемента (src) мы указываем IP-адрес источника, то есть

клиента от которого пришел запрос к нашему прокси серверу.


В следующем примере мы разрешим Васе Пупкину (хрестоматийный персонаж) (Pupkin) и бухгалтерии(buhs) доступ к нашему прокси серверу, а всем

остальным запретим:


acl buhs src 192.168.0.1-192.168.0.9

acl Pupkin src 192.168.0.10

http_access allow buhs

http_access allow Pupkin

http_access deny all


* acl имя dst список


Данный элемент (dst) указывает IP-адрес назначения, то есть IP-адрес

того сервера, доступ к которому желает получить клиент прокси сервера.


В следующем примере мы запретим Васе доступ к подсети 194.67.0.0/16 (к

примеру, в ней находится тот же aport.ru):


acl Net194 dst 194.67.0.0/16

http_access deny Pupkin Net194


* acl имя dstdomain список


С помощью этого элемента (dstdomain) мы указываем домен, доступ к которому желает получить клиент прокси сервера.


В следующем примере мы запретим Васе доступ к варезным сайтам nnm.ru и

kpnemo.ru:


acl SitesWarez dstdomain .nnm.ru .kpnemo.ru

http_access deny Pupkin SitesWarez


В случае если будет необходимо указать домен источника, то используйте

srcdomain.


* acl имя [-i] srcdom_regex список

* acl имя [-i] dstdom_regex список


Данные элементы отличаются от srcdomain и dstdomain лишь тем, что в них

используются регулярные выражения, которые в данной статье мы не

рассматриваем, но пример всё-таки приведём:


Acl SitesRegexSex dstdom_regex sex

Acl SitesRegexComNet dstdom_regex \.com$ \.net$

http_access deny Pupkin SitesRegexSex

http_access deny Pupkin SitesRegexComNet


В данном примере мы запретили доступ Пупкину Василию на все домены,

содержащие слово sex и на все домены в зонах .com и .net.


Ключ -i призван игнорировать регистр символов в регулярных выражениях.


* acl имя [-i] url_regex список


С помощью этого элемента (url_regex) мы указываем шаблон регулярного

выражения для URL.


Пример указания файлов с расширением avi, начинающихся на слово sex:


acl NoAviFromSex url_regex -i sex.*\.avi$


В случае если Вы желаете указать шаблон только для пути URL, то есть

исключая протокол и имя хоста (домена), то используйте urlpath_regex.


Пример для указания музыкальных файлов:


acl media urlpath_regex -i \.mp3$ \.asf$ \.wma$


* acl имя_acl port список


Указание номера порта назначения, то есть порта, к которому желает

подключится клиент нашего прокси сервера.


Как пример, запретим всем использование программы Mirc через наш прокси

сервер:


Acl Mirc port 6667-6669 7770-7776

http_access deny all Mirc


* acl имя_acl proto список


Указание протокола передачи.


Как пример, запретим вышеупомянутому Васе использование протокола FTP

через наш прокси сервер:


acl ftpproto proto ftp

http_access deny Pupkin ftpproto


* acl имя_acl method список


Указание метода http запроса клиентом (GET, POST).


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


acl SiteMailRu dstdomain .mail.ru

acl methodpost method POST

http_access deny Pupkin methodpost SiteMailRu


ОГРАНИЧЕНИЯ ПОЛЬЗОВАТЕЛЕЙ


Достаточно часто в нашей стране возникает ситуация, что канала доступа в глобальную сеть Интернет на всех пользователей не хватает и возникает желание дать каждому по максимуму, но при этом не дать каналу "загнуться" из-за любителей позагружать файлы.


Средства прокси-сервера Squid позволяют этого добится несколькими путями:


- первый путь это оптимизация кеширования объектов;


- второй - это ограничение по времени определенных пользователей, что не

совсем корректно;


- третий путь заключается в ограничении скорости для определенных типов

файлов, пользователей и всего того, что определено нами через Acl.


ОГРАНИЧЕНИЯ ПО ВРЕМЕНИ


Ограничить пользователей по времени можно следующим образом:


acl имя time дни чч:мм-ЧЧ:ММ


Где день: M - Понедельник, T - Вторник, W - Среда, H - Четверг, F -

Пятница, A - Суббота, S - Воскресенье.


При этом чч:мм должно быть меньше чем ЧЧ:ММ, то есть можно указать с

00:00-23:59, но нельзя указать 20:00-09:00.


Давайте запретим всё тому же Васе иметь доступ в сеть Интернет с 10 до

15 часов каждый день:


acl TimePupkin time 10:00-15:00

http_access deny Pupkin TimePupkin


Если хочется разрешить Васе пользоваться программой Mirc с 13 до 14

часов, то пишем:


acl TimePupkin time 13:00-14:00

http_access allow Pupkin TimePupkin Mirc

http_access deny Pupkin Mirc


А что делать, если необходимо запретить или разрешить в определенные дни недели? Squid также позволяет это сделать, к примеру с 13 до 14 в понедельник и в воскресенье:


acl TimePupkin time MS 13:00-14:00


Как видите, ничего сложного в этом нет.


ОПТИМИЗИРУЕМ КЕШИРОВАНИЕ ОБЪЕКТОВ В SQUID

-----------------------------------------


Существует множество типов файлов, которые обновляются, не достаточно часто, чтобы позволить прокси серверу реагировать на заголовки от веб-серверов о том, что данный объект не подлежит кешированию либо он был на удивление только что изменён. Это довольно частая ситуация.


Для разрешения таких ситуаций призван параметр refresh_pattern в файле настроек прокси-сервера Squid, но полностью с формулами и т.п. мы его рассматривать не будем.


Формат:


refresh_pattern [-i] строка МИНВ процент МАКСВ параметры


Данный параметр используется для того, чтобы определить возраст объекта (считайте файла) в кеше, следует ли его обновлять или нет.


МИНВ (минимальное время) - время в минутах, когда объект, имеющийся в

кеше считается свежим.


МАКСВ (максимальное время) - максимальное время в минутах, когда объект

считается свежим.


Параметры - это один или несколько следующих параметров:


- override-expire - игнорировать информацию об истечении свежести объекта

и использовать МИНВ.


- override-lastmod - игнорировать информацию о дате изменения файла и

использовать МИНВ.


- reload-into-ims - вместо запроса клиентского запроса "не кешировать

документы" (no-cache) посылать запрос "Если изменен с"

(If-Modified-Since)


- ignore-reload - игнорировать запросы клиентов "не кешировать документы"

(no-cache) или "перезагрузить документ" (reload).


И так, мы подошли к самому главному. Ну, так какие же типы файлов реже всех обновляются? Как правило, это разнообразные музыкальные файлы и картинки.


Установим свежесть объектов, для этого для картинок и музыкальных файлов укажем, скажем, так для примера, целых 30 дней (43200 минут):


refresh_pattern -i \.gif$ 43200 100% 43200 override-lastmod override-expire

refresh_pattern -i \.png$ 43200 100% 43200 override-lastmod override-expire

refresh_pattern -i \.jpg$ 43200 100% 43200 override-lastmod override-expire

refresh_pattern -i \.jpeg$ 43200 100% 43200 override-lastmod override-expire

refresh_pattern -i \.pdf$ 43200 100% 43200 override-lastmod override-expire

refresh_pattern -i \.zip$ 43200 100% 43200 override-lastmod override-expire

refresh_pattern -i \.tar$ 43200 100% 43200 override-lastmod override-expire

refresh_pattern -i \.gz$ 43200 100% 43200 override-lastmod override-expire

refresh_pattern -i \.tgz$ 43200 100% 43200 override-lastmod override-expire

refresh_pattern -i \.exe$ 43200 100% 43200 override-lastmod override-expire

refresh_pattern -i \.prz$ 43200 100% 43200 override-lastmod override-expire

refresh_pattern -i \.ppt$ 43200 100% 43200 override-lastmod override-expire

refresh_pattern -i \.inf$ 43200 100% 43200 override-lastmod override-expire

refresh_pattern -i \.swf$ 43200 100% 43200 override-lastmod override-expire

refresh_pattern -i \.mid$ 43200 100% 43200 override-lastmod override-expire

refresh_pattern -i \.wav$ 43200 100% 43200 override-lastmod override-expire

refresh_pattern -i \.mp3$ 43200 100% 43200 override-lastmod override-expire


Показанные Выше настройки лишь пример, для того, чтобы была понятна

суть.


Теперь можете проверить эффективность своего прокси сервера, она уж

точно возрастет.

Пример файла конфигурации SQUID

#IP интерфейса и порт, где будет SQUID

http_port 192.168.0.1:3128 transparent


#Порт icp

icp_port 0


#Не кешировать скрипты

acl QUERY urlpath_regex cgi-bin

no_cache deny QUERY


#Кол-во ОЗУ для SQUID

#Укажите здесь кол-во памяти (имеется ввиду ОЗУ) выделенной под кеширование. #Предупреждение: реально Squid использует больше, чем указанное здесь значение. Золотое #правило: если вы имеете N мегабайт свободной памяти, которую можете отдать под Squid, #укажите здесь значение N/3.


cache_mem 32 MB


#Формат хранилища SQUID - ufs. Размер кеша(МБ): 1000. Кеш первого уровня: 16, кеш второго - 256.

cache_dir ufs /var/spool/squid 1000 16 256


#Путь к лог-файлу доступа к SQUID(Статистика работы через SQUID)

cache_access_log /var/log/squid/access.log


#Путь к лог-файлу SQUID - в нем события запуска SQUID и дочерних программ

cache_log /var/log/squid/cache.log


#Путь к лог-файлу Strore

cache_store_log /var/log/squid/store.log


#Ротация логов

logfile_rotate 10


#Таблица MIME-типов для SQUID

mime_table /usr/share/squid/mime.conf


#PID-файл SQUID

pid_filename /var/run/squid.pid


#Пользователь для анонимного доступа к FTP

ftp_user anonymous@


#SQUID формирует страницу с папками на FTP - этот параметр - кол-во папок

ftp_list_width 32


#Пассивный режим FTP

ftp_passive on


#Проверка подлинности FTP

ftp_sanitycheck on


#Адрес(а) DNS сервера(ов) можете тут указать свое

dns_nameservers 192.168.0.1


#Списки контроля доступа

#Сам сервер

acl phoenix src 192.168.0.1/255.255.255.255


#Сегмент сети с адресами 192.168.0.2-255

acl office src 192.168.0.2-192.168.0.255/255.255.255.255


#Стандартные ACL

acl all src 0.0.0.0/0.0.0.0


#Все

acl manager proto cache_object

acl localhost src 127.0.0.1/255.255.255.255


#Адрес localhost

acl SSL_ports port 443 563


#Порты SSL

acl SMTP port 25


#Для защиты от спама ;) Оказывается SQUID может делать relay


#Порты, которые будет пропускать SQUID


#Служебные ACL

acl Safe_ports port 80

acl Safe_ports port 21

acl Safe_ports port 443 563


#https, snews

acl Safe_ports port 777


#multiling http

acl CONNECT method CONNECT

#Теперь разрешаем доступ тому, кто указан в ACL

http_access allow phoenix


http_access allow office

http_access deny !Safe_ports

http_access deny SMTP

http_access deny all

http_access deny banners1 all

http_access deny banners2 all


#Разрешаем ICP-доступ всем

icp_access deny all


#Каталог со страницами неполадок SQUID

error_directory /usr/share/squid/errors/Russian-1251


#Ограничение трафика

delay_pools 3


#Выделяем 3 пула задержки

delay_class 1 2

delay_class 2 3

delay_class 3 2


#delay_parameters [номер пула] [all_downl/all_size] [net_downl/net_size] [one_downl/one_size]

# all - на всех

# net - на подсеть

# one - на отдельный адрес

# downl - скорость заполнения части (байт/сек)

# size - объем части пула (байт)


#Для пула класса 1 используется только all

#Для пула класса 2 используется all и net

#Для пула класса 3 используется all, net и one


delay_access 1 allow phoenix


#Разрешаем серверу ходить через 1-й пул

delay_access 1 deny all


#Остальным запрещаем

delay_parameters 1 -1/-1 -1/-1


#Параметры 1-го пула - без ограничений

delay_access 2 allow office


#Разрешаем комп. классу ходить через 2-й пул

delay_access 2 deny office


#Остальным запрещаем

delay_parameters 2 10000/10000 10000/10000 8000/8000


#Параметры 2-го пула: канал на все и сеть - 8 #кбсек(64 кбитсек) и на каждую машину не более 4 кбсек

delay_access 3 deny all


#Остальным запрещаем

delay_parameters 3 6000/6000 -1/-1


#Параметры 3-го пула: канал на все - 6 кбсек(56 кбитсек), а как они его поделят - не наши проблемы ;)


Для первого запуска squid нужно инициализировать кэш, это делается командой

sguid –z

в дальнейшем запуск squid –а производися командой

service squid start

Dansguardian или «Танцующий стражник»

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

Для того чтобы уменьшить нагрузку на внешний канал, используют кэширующий сервер, который при каждом запросе складывает файлы в локальный кэш. Теперь при последующем запросе они не будут скачиваться повторно. Проблема возникает обычно с динамически генерируемыми ссылками, которые используются в форумах, чатах и в баннерных сетях. С другой стороны, стоит запретить пользователям посещать страницы с определенным содержанием, скачивать музыку, фильмы и прочее. Использование Access Control List (ACL) не всегда может решить эту проблему. Выходом из этой ситуации будет фильтрация не по конкретному адресу, а по содержимому. Сегодня особенно часто упоминается в этом контексте squidGuard ( ссылка скрыта), который представляет собой дополнение к Squid. Более гибким и удобным решением является DansGuardian ( ссылка скрыта), к тому же недавно анонсирована следующая версия  2.9 продукта, имеющая некоторые особенности.

Возможности DansGuardian

DansGuardian представляет собой фильтр web-контента, работающий во всех операционных системах, на которых компилируется Squid — Linux, FreeBSD, OpenBSD, NetBSD, MacOS X, HP–UX и Solaris. Хотя ничто не мешает использовать его в паре с другими прокси-серверами, например Oops. В своей работе DansGuardian использует несколько методов фильтрации, среди которых фильтрация по ссылке, IP-адресу, домену и пользователю, содержимому, расширению файлов, метке PICS (Platform for Internet Content Selection — ссылка скрыта) и MIME-фильтрация. Дополнительно POST контроль позволяет ограничивать или вообще блокировать загрузку. Большие списки адресов и доменов DansGuardian обрабатывает быстрее, чем squidGuard. Система может работать в режиме белого списка, когда блокируются все сайты, кроме занесенных в этот список. В качестве blacklist могут быть использованы списки некоторых других проектов, например squidGuard. Предусмотрен мягкий режим, когда запрещенные ресурсы не блокируются, но администратор получает информацию о пользователях, посещавших такие страницы. Начиная с версии 2.9 DansGuardian может использовать в качестве контент-фильтра внешние утилиты, например антивирус. На сегодняшний день в качестве внешнего антивируса может использоваться Clamav и антивирус Касперского, поэтому на этапе конфигурирования путь к библиотеке libclamav или клиенту антивируса Касперского должен быть виден pkg–config. Кроме того, зайдя на страницу Extras & Add-ons ( ссылка скрыта) вы можете познакомиться со списком различных расширений к DansGuardian, среди которых антивирус, анализаторы журналов, шаблоны страниц и рисунков, blacklist и скрипты для их автоматического обновления.

Конфигурационный скрипт в большинстве случаев правильно настраивает все основные параметры. По умолчанию для прокси-сервера устанавливается пользователь nobody, но в дистрибутивах используется squid или oops, поэтому установите соответствующее значение опциями with-proxyuser и with-proxygroup:


$ ./configure --with-proxyuser=squid --with-proxygroup=squid


Далее стандартные make и make install. После чего в /etc должен появится каталог dansguardian, содержащий файлы настроек. Скрипт dansguardian.pl, который выводит html-страницу вместо блокированной, должен оказаться в каталоге cgi-bin web-сервера. Если используется logrotate, то в каталоге /etc/logrotate.d/ будет лежать файл dansguardian, при помощи которого будут определены параметры очистки журнала. Иначе для этих целей будет использоваться шелл-скрипт logrotation. В этом случае необходимо позаботиться о его запуске посредством cron, например, прописав в crontab такие строки:


59 23 * * 07 /etc/dansguardian/logrotation


И наконец, в /etc/rc.d будет скопирован файл, необходимый для автоматического запуска DansGuardian при загрузке системы. Проследите, чтобы DansGuardian обязательно запускался после Squid, иначе процесс закончится с ошибкой.

После инсталляции редактируем файл конфигурации /etc/dansguardian/dansguardian.conf. Основные опции:

# Вывод информации пользователю

# -1 = незаметный режим, страницы не блокируются, но ведется протокол;

# 0 = выводится только 'Access Denied';

# 1 = сообщается, почему, без указания ресурса;

# 2 = полный отчет;

# 3 = рекомендуемый режим, используется html-шаблон;

reportinglevel = 3

# Здесь указывается на каталог с html-шаблонами, которые будут использоваться вместо cgi-сценария.

languagedir = '@DGDATADIR@/languages'

# Подкаталог шаблона с соответствующим языком, в версии 2.9 наконец появился русифицированный шаблон.

language = 'russian-koi8-r'

# Уровень регистрации

# 0 = ничего, 1 = только запрещенные, 2 = все текстовые, 3 = все запросы

loglevel = 2

# Регистрация исключений (полезен при анализе, когда запрещенный сайт по непонятной причине прошел через фильтр)

logexceptionhits = on

# Формат файла журнала

# 1 = формат DansGuardian, 2 = CSV, 3 = формат Squid, 4 = разделенный табуляцией

logfileformat = 1

# Нахождение файла журнала, обычно задается при конфигурировании

#loglocation = '@DGLOGLOCATION@/access.log'

# По умолчанию прослушиваются все сетевые интерфейсы (пустой параметр)

# при необходимости можно задать один IP-адрес

filterip =

# порт, на котором DansGuardian будет слушать

filterport = 8080

# IP-адрес прокси

proxyip = 127.0.0.1

# порт прокси-сервера

proxyport = 3128

# адрес cgi-страницы web-сервера, при помощи которой будет выводиться информация о блокировке

# при reportinglevel = 3 можно не трогать.

accessdeniedaddress = 'R.YOURDOMAIN/cgi-bin/dansguardian.pl'

# Нестандартный разделитель (нужен при использовании accessdeniedaddress)

nonstandarddelimiter = on

# Включение подмены баннеров определенным изображением и местонахождение этого файла

# вместе с утилитой поставляется один gif-файл, на сайте проекта можно найти ссылки на другие варианты

usecustombannedimage = 1

custombannedimagefile = '@DGDATADIR@/transparent1x1.gif'

# Ниже задаются фильтрующие группы, которые могут быть применены к определенным пользователям. Установка соответствия "пользователь — фильтрующая группа" задается в файле, указанном в параметре filtergroupslist в виде =filter<1-9> fedja=filter1. Сами же фильтры для групп задаются в файле dansguardianfN.conf, где N — номер группы.

filtergroups = 1

filtergroupslist = '@DGCONFDIR@/lists/filtergroupslist'


# Этот файл содержит список IP-адресов клиентов и имена пользователей, которым в доступе к сети будет отказано

bannediplist = '@DGCONFDIR@/lists/bannediplist'

banneduserlist = '@DGCONFDIR@/lists/banneduserlist'

# Этим IP-адресам и пользователям доступ разрешен в полном объеме, т.е. без фильтрации

exceptioniplist = '@DGCONFDIR@/lists/exceptioniplist'

exceptionuserlist = '@DGCONFDIR@/lists/exceptionuserlist'

# список фраз, при обнаружении которых страница будет блокирована

# фразы должны быть заключены в конструкцию вида , при необходимости опцией Include могут быть подключены внешние файлы

bannedphraselist = '@DGCONFDIR@/lists/bannedphraselist'

# следующий файл содержит список фраз с соответствующей положительной или отрицательной величиной; если такие фразы обнаруживаются на странице, вычисляется итоговая величина (naughtynesslimit), при достижении которой страница блокируется

weightedphraselist = '@DGCONFDIR@/lists/weightedphraselist'

naughtynesslimit = 50

# Список фраз, которые не будут фильтроваться

exceptionphraselist = '@DGCONFDIR@/lists/exceptionphraselist'

# Список доменов, которые не будут фильтроваться

exceptionsitelist = '@DGCONFDIR@/lists/exceptionsitelist'

# часть сайта, которая не будет фильтроваться, даже если он запрещен в banned*

exceptionurllist = '@DGCONFDIR@/lists/exceptionurllist'

# список сайтов, которые полностью должны блокироваться

# в архиве нет готового blacklist’a, его необходимо скачать и установить отдельно, сняв комментарии с конструкций Include

bannedsitelist = '@DGCONFDIR@/lists/bannedsitelist'

# Здесь указывается часть сайта, которая должна быть блокирована

bannedurllist = '@DGCONFDIR@/lists/bannedurllist'

# список регулярных выражений, при совпадении с которым URL будет блокирован

bannedregexpurllist = '@DGCONFDIR@/lists/bannedregexpurllist'

# список сайтов, к которым применяется только фильтрация фраз

greysitelist = '@DGCONFDIR@/lists/greysitelist'

# тоже только справедливо для части сайта

greyurllist = '@DGCONFDIR@/lists/greyurllist'

# список расширений файлов, типов MIME и меток PICS, которые будут запрещены к загрузке.

bannedextensionlist = '@DGCONFDIR@/lists/bannedextensionlist'

bannedmimetypelist = '@DGCONFDIR@/lists/bannedmimetypelist'

picsfile = '@DGCONFDIR@/lists/pics'

# Список регулярных выражений вида "sex"->"censored", при совпадении с первым выражением оно будет заменено вторым.

contentregexplist = '@DGCONFDIR@/lists/contentregexplist'

# Количество разрешенных страниц, которые не надо проверять повторно

# Работает также и для антивирусного плагина

# 0 = выключен (рекомендуется для интернет-провайдеров)

# 1000 = рекомендуется для большинства пользователей

# 5000 = рекомендуемый максимальный предел, а также при использовании антивируса

urlcachenumber = 1000

# Файлы, просмотренные антивирусом, могут быть сохранены в чистом кэше и больше не сканироваться

scancleancache = on

# Удаление пробелов и HTML-кода перед проверкой; режим 0 и 1 позволяет экономить ресурсы процессора

# 0 = только обработка в сыром виде

# 1 = удаление пробелов и HTML кода

# 2 = оба метода (по умолчанию)

phrasefiltermode = 2

# Принудительный перевод всех букв в нижний регистр, для последующего сравнения

# 0 = перевод букв в нижний регистр

# 1 = регистр не изменяется

preservecase = 0

# Перевод шестнадцатеричного кода в символы

# 0 = выключен

# 1 = включен

hexdecodecontent = 0

# Проверка DNS- или IP-адреса, т.е. если пользователь, вместо запрещенного сайта, введет его адрес, DansGuardian обнаружит это. Отсутствие локального DNS может замедлить работу.

reverseaddresslookups = off

reverseclientiplookups = off

# Построение кэша запрещенных сайтов, увеличивает эффективность.

# Для мощных компьютеров не требуется.

createlistcachefiles = on

# POST protection т.е. ограничение загрузки файлов, в том числе и MIME

# установка в -1 отключает опцию, 0 — полное блокирование, число указывает на размер в Кб (например 512 = 512 Кб)

#maxuploadsize = 512

#maxuploadsize = 0

maxuploadsize = -1

# Иногда web-сервер помечает двоичный файл как текстовый, и DG проверяет его.

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

# Величина не должна превышать значения maxcontentramcachescansize

maxcontentfiltersize = 256

# Удаление файлового кэша после завершения загрузки

deletedownloadedtempfiles = on

# Конфигурирование дополнительных сканеров содержимого, например антивирусных

# можно использовать одновременно сразу несколько сканеров, но это увеличит нагрузку

#contentscanner = '@DGCONFDIR@/contentscanners/clamav.conf'

#contentscanner = '@DGCONFDIR@/contentscanners/clamdscan.conf'

#contentscanner = '@DGCONFDIR@/contentscanners/kavav.conf'

#contentscanner = '@DGCONFDIR@/contentscanners/kavdscan.conf'

#contentscanner = '@DGCONFDIR@/contentscanners/icapscan.conf'

Остальные опции можно пока оставить в значении по умолчанию.

Скачиваем blacklist, распаковываем его в /etc/dansguardian/ и не забываем снять комментарии в файле bannedsitelist. Самому составлять параметры PICS довольно неудобно, лучше взять со страницы Extras подготовленные по различным уровням файлы и подключить их в picsfile опцией Include.

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

клиент (web-браузер) -> DansGuardian (8080) -> Squid (3128) -> Сервер (80)

Поэтому на следующем шаге необходимо сделать так, чтобы клиенты соединялись с сервером не напрямую, а через DansGuardian. Можно, конечно, и перенастроить все web-браузеры, чтобы они использовали прокси-сервер на 8080 порту, но при большом их количестве это довольно трудоемкое занятие, да и такой защите грош цена. Лучше для этого использовать возможности iptables, заставив его принудительно перенаправлять запросы с 80 и 3128 портов на порт 8080.

# /sbin/iptables -t nat -A OUTPUT -p tcp --dport 80 -j REDIRECT --to-ports 8080

# /sbin/iptables -t nat -A OUTPUT -p tcp --dport 3128 -j REDIRECT --to-ports 8080

Все, теперь настала пора запускать Squid, DansGuardian и приступать к тестированию. Для тестирования можно использовать набор страниц ссылка скрыта. Например, при попытке получить доступ к странице, содержащей в ссылке слово «sex» система вывела такое сообщение 



А в журнале появилась такая запись:

2005.7.29 22:42:24 — 127.0.0.1 / /index.php?sex *DENIED* Banned Regular Expression URL: (|[-\?+=&/_])(…………)s?([-\?+=&/_]|$) GET 0