Перед многими системными администраторами встает вопрос ограничения доступа пользователей к тем или иным ресурсам сети интернет. В большинстве случаев в ресурсоемкой и сложной контент фильтрации нет необходимости, вполне достаточно URL-списков. Реализовать такой метод вполне возможно средсвами прокси-сервера squid не привлекая стороннего ПО.

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

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

В дальнейшем мы будем подразумевать, что читатель обладает начальными навыками администрирования Linux. Также напомним, что все приведеные ниже команды следует выполнять от супрепользователя.

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

Touch /etc/squid/blacklist

и приступим к его заполнению. При указании URL следует использовать RegExp синтаксис, мы не будем подробно останавливаться на этом вопросе, так как это выходит за рамки статьи, подробнее с правилами RegExp можно ознакомиться . Для примера заблокируем популярные соцсети:

Vk\.com
odnoklassniki\.ru

Обратите внимание, точка в RegExp является служебным симоволом и поэтому должна быть экранирована символом \ (обратный слеш).

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

Acl url_filtred src 10.0.0.100-10.0.0.199

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

Затем подключим наш список:

Acl blacklist url_regex -i "/etc/squid/blacklist"

Ключ -i указывает на то, что список нечувствителен к регистру.

Теперь перейдем в секцию правил и перед правилом

Http_access allow localnet

Http_access deny blacklist url_filtred

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

Сохраним изменения и перезапустим squid:

Service squid restart

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

Причина размещения данной статьи следующая: очень часто на форумах встречаю как TC приводят примеры своих конфигов с чудовищной мешаниной директив acl и http_access , особенно в темах рассматривающих проблемы с доступом к squid . Настраивая какую-либо систему я стараюсь придерживаться какого-то логичного порядка. Постараюсь сегодня Вам донести, какого порядка http_access придерживаюсь я.

Основная идея заключается во фразе выдернутой из сквидового мануала по http_access :

If none of the "access" lines cause a match, the default is the opposite of the last line in the list. If the last line was deny, the default is allow. Conversely, if the last line is allow, the default will be deny. For these reasons, it is a good idea to have an "deny all" entry at the end of your access lists to avoid potential confusion.

Дословно следующее:

Если не попалось правило "access", то по умолчанию будет применено правило, противоположное последнему в списке. Если последнее правило deny, то по умолчанию применится allow. Наоборот, если последняя строчка allow, по умолчанию будет deny. Поэтому хорошей идеей будет иметь правило "deny all" в конце вашего списка правил во избежании возможных недоразумений.

Я уже рассматривал некоторые советы и правила в статье . Сейчас постараюсь донести свое видение порядка acl и http_access . Собственно, порядок директив acl абсолютно не имеет никакого значения. Главное, чтобы acl были определены ДО правил http_access (я не нашел этому подтверждения в мануалах, но я имел некоторые проблемы с доступом при размещении acl после http_access). Я стараюсь группировать acl по одинаковым типам.

Настройка http_access в squid

Именно порядком размещения директив http_access определяется, получит клиент доступ к кэшу или нет. Алгоритм обработки запроса к кэшу следующий:

1. Каждый запрос последовательно сравнивается с каждой строчкой правил http_access.
2. Пока запрос не совпадет с одним из правил access или deny он будет следовать от правила к правилу и сверять свои полномочия.
   Тут все просто. Давайте разберем следующие правила:
3. Если в http_access указано несколько acl, то применяется логическое И. Пример: http_access allow|deny acl И acl И... ИЛИ http_access allow|deny acl И acl И... ИЛИ
4. Если запрос не попал ни под какое правило, то по-умолчанию, squid использует правило противоположное последнему. # у нас есть единственное разрешающее правило для некоторого acl user: http_access allow user # если при доступе к squid, запрос не попал в этот acl, то к нему будет применено действие deny. # А если у нас есть два правила http_access allow user http_access deny user2 # и запрос не входит ни в acl user, ни в acl user2, то к нему применится allow. # То есть действие противоположное последнему http_access deny user2

Это основы основ. Но есть некоторые нюансы, выявленные при эксплуатации.

Тюнинг http_access)

Мы знаем, что существуют acl, использующие внешние . Либо другие модули (например, srcdomain и srcdom_regex требующие резолвинга). Можно сделать логический теоретический вывод, что данные acl могут работать несколько медленней, нежели acl src или dst или аналогичные. Согласно wiki, разработчики делят быстрые\медленные acl по следующим группам(с версии squid 3.1.0.7):

Соответственно, если мы указываем первыми правила запрета, особенно если они "быстрые" (например такие

Http_access deny manager http_access deny !Safe_ports http_access deny CONNECT !SSL_ports

) то они очень быстро отрабатывают, снижая нагрузку за счет того, что до правил использующих аутентификацию доходят меньше запросов, те которые действительно в этом нуждаются. Итак, старайтесь размещать запрещающие правила http_access, использующие acl без внешних модулей как можно выше, далее размещайте разрешающие правила. Ну и последним не забываем указать deny all (to avoid potential confusion).

Траблшуттинг acl и http_access

Если при компоновке директивы http_access все же есть некоторые проблемы и нужный пользователь не получает доступа можно попытаться использовать опцию . Пример:

Debug_options ALL,1 33,2

После реконфигурирования squid в cache.log начнут падать сообщения о разрешении\запрещении доступа по каждой сессии и имя acl, согласно которого доступ предоставлен или нет. Если же данной информации недостаточно, то можно включить большую детализацию:

Debug_options ALL,1 33,2 28,9

Резюме

На этом сегодня все.Сегодня рассмотрели вопрос настройки acl и http_access. Логику обработки директив http_access и познакомились с некоторыми рекомендациями. Возможно, кто-то из читателей меня поправит, за что буду очень благодарен. Кроме данной статьи рекомендую ознакомиться с http://wiki.squid-cache.org/SquidFaq/SquidAcl.

С Уважением, Mc.Sim!

Проблема следующая. На предприятии AD, выход в инет через прокси, есть ДМЗ. Прокси и его порт прописываюся в настройках браузера, в разделе _подключения_. Для доступа в ДМЗ используется ISA 2006 (у меня стоит Isa client 2004). В инет ходим через squid.

После установки Windows 7 (на чистую машину) IExplorer настроил как обычно, прописал прокси и порт, но IExplorer отказывается выходить в инет (соответственно отваливается возможность активации и получения обновлений). При запуске запрашаваются логин и пароль, но в итоге получаю страничку со следующим сообщением:
==============================
ОШИБКА: Доступ к кэшу запрещён.

ОШИБКА

Доступ к кэшу запрещён

Произошла следующая ошибка:

• Доступ к кэшу запрещён

Извините, Вы не можете запросить:

Http://go.microsoft.com/fwlink/? из этого кэша до тех пор, пока не пройдёте аутентификацию.

Для этого Вам необходим Netscape версии 2.0 либо выше, или Microsoft Internet Explorer 3.0, или HTTP/1.1 совместимый броузер. Пожалуйста свяжитесь с администратором кэша , если у Вас возникли проблемы с аутентификацией, либо смените Ваш пароль по умолчанию.

В FireFox такой проблемы нет . В настройках указал прокси, ввел логин и пароль и вот сижу, пишу это письмо.
На XP и Vista тоже все OK .

Ставил следующие сборки 7100(rus), 7201, сейчас стоит 7231(rus) - ситуация не меняется.

Вопрос, что и где подкрутить?