Squid сообщение о блокировке

Обновлено: 05.07.2024

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

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

• на каком уровне модели OSI могут работать коммутаторы?
• как лучше организовать работу сети организации с множеством отделов?
• для чего использовать технологию VLAN?
• для чего сервера стоит выносить в DMZ?
• как организовать объединение филиалов и удаленный доступ сотрудников по VPN?
и многие другие.

Уже знаете ответы на вопросы, перечисленные выше? Или сомневаетесь? Попробуйте пройти тест по основам сетевых технологий. Всего 53 вопроса, в один цикл теста входит 10 вопросов. Каждый раз набор вопросов разный. Тест можно проходить неоднократно без потери интереса. Бесплатно и без регистрации.

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

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

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

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

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

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

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

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

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

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

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

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

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

squid-url-acl-001.jpg

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

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

и изменим запрещающее правило следующим образом:

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

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

Заблокирует доступ к социальной сети Мой мир, но не будет препятствовать доступу к Майл.ру.

squid-url-acl-002.jpg

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

и все что содержит точку перед искомым адресом будет заблокировано, то с основным доменом сложнее, самое время вспомнить про полный формат адреса:

squid-url-acl-003.jpg

Напоследок рассмотрим еще одну ситуацию, как сделать, чтобы на заблокированом сайте были доступны некоторые страницы. Например, страничка компании в Вконтакте или вы хотите обезопасить определенные адреса от случайного попадания под фильтр в будущем. Для этого следует добавить к системе "белый" список. Создадим файл списка:

внесем в него нужные адреса, для примера разблокируем страничку Вконтакте новостного портала Утро.ру:

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

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

squid-url-acl-004.jpg

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

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

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

• на каком уровне модели OSI могут работать коммутаторы?
• как лучше организовать работу сети организации с множеством отделов?
• для чего использовать технологию VLAN?
• для чего сервера стоит выносить в DMZ?
• как организовать объединение филиалов и удаленный доступ сотрудников по VPN?
и многие другие.

Уже знаете ответы на вопросы, перечисленные выше? Или сомневаетесь? Попробуйте пройти тест по основам сетевых технологий. Всего 53 вопроса, в один цикл теста входит 10 вопросов. Каждый раз набор вопросов разный. Тест можно проходить неоднократно без потери интереса. Бесплатно и без регистрации.


читать про ssl-bump


Я бы рыл в сторону acl regexp

P.S: Еще рекомендую почитать про squidguard, он возможно Вам облегчит настройку всех этим ACL


Никак. SSL для того и сделан был, чтобы никакое Порошенко не лезло между клиентом и сервером.

Как вариант, вам правильно предложили ssl-bump.
Нужно будет всем пользователям порекомендовать установить ваш сертификат, чтобы вы могли успешно проводить MITM атаку с подменой ответа.

Схема контроля доступа в Squid достаточно развита и тяжела для понимания некоторым людям. Она состоит из двух различных компонентов: элементов ACL, и списков доступа. Список доступа состоит из директивы allow или deny и указанных вслед за ней элементами ACL.

элементы ACL

Замечание: Информация, представленная здесь верна для версии 2.4.

Не все элементы ACL могут быть использованы со всеми видами списков доступа (описаны ниже). К примеру, snmp_community предназначено для использования тольско совместно с snmp_access. Типы src_as и dst_as используются только в списках доступа cache_peer_access.

Тип arp элемента ACL треюбует специально опции --enable-arp-acl. Кроме того, код ARP ACL портируется не на все операционные системы. Это работает на Linux, Solaris, и некоторых *BSD системах.

Элемент ACL SNMP и список доступа требуют конфигурационной опции --enable-snmp .

Некоторые элементы ACL могут вносить задержки в работу кеша. Например, использование src_domain и srcdom_regex требует обратного преобразования клиентского IP. Это преобразование вносит некоторую задержку в обработку запроса.

Каждый элемент ACL обозначается уникальным именем. Имя элемента ACL содержит список значений. Когда проверяется совпадения для некольких значений используется логическое И. Другими словами, элемент ACL совпал когда совпало одно из значений.

Вы не можете указывать одинаковое имя для двух различных типов элементов ACL. Это вызовет синтаксическую ошибку.

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

Списки доступа

Правило списка доступа состоит из слова allow или deny, с последующим указанием списка имен элементов ACL.

Список доступа состоит из одного или более правил списков доступа.

Правила списков доступа проверяются в порядке их объявления. Поиск по по списку прекращается как только одно из правил совпадает.

Если правило содержит несколько элементов ACL, используется логическое ИЛИ. Другими словами, все элементы ACL, указанные в этом правиле должны совпасть, чтобы правило сработало. Это значит, что есть возможность написать правило, которое никогда не сработает. К примеру, номер порта никогда не может быть равен 80 И 8000 одновременно.

Если ни одно из правил не сработало, по умолчанию будет произведено действие обратное указанному в последнем правиле списка. Поэтому хоррошей идеей будет явно указать действие по-умолчанию. Наилучший выбор для этого - ACL all. Например:

10.2 Как мне разрешить моим клиентам использовать кеш?

10.3 Как мне настоить Squid, чтобы он не кешировал определенный сервер?

10.4 Как мне организовать ACL списка запрета?

Предположим, к ппримеру, что вы желаете избавить пользователей от доступа к рецептам.

Первый способ - запретить любой URL, содержащий слова ``cooking'' или ``recipe.'' Вы могли бы использовать следующую конфигурацию: url_regex значит искать указанное вами регулярное выражение в поступившем URL. Заметьте, что это регулярное выражение чувствительно к регистру символов, т.е. URL, содержащие ``Cooking'' не будут запрещены.

10.5 Как мне блокировать доступ к кешу определенны пользователям и группам?

Ident

Вы можете использовать ident lookups чтобы разрешить доступ к вашему кешу определенным пользователям. Это потребует запуска процесса ident server на клиентской машине(ах). В вашем конфигурационном файле squid.conf вам необходимо будет написать нечто подобное:

Proxy Authentication

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

В Squid вер.2 аутентификация производится через внешний процесс. Информацию как настроить это см. в разделе Configuring Proxy Authentication.

10.6 А у вас есть CGI-программа, позволяющая пользователям менять свой пароль доступа к прокси?

Pedro L Orso переделал htpasswd от Apache в CGI-скрипт, называемый chpasswd.cgi.

10.7 Есть ли способ осуществлять поиск ident только для определенного хоста и сравнивать результат со списком пользователей в squid.conf?

Если вы используете ACL типа user в squid conf, то Squid будет выполнять ident lookup для каждого клиентского запроса. Другими словами, Squid-1.1 выплоняет ident поиск для всех запросов или не выполняет вообще. Объявление ACL типа user включает поиск ident, вне зависимости от значения ident_lookup.

Однако, хотя запросы ident выплоняются для каждого запроса, Squid не ожидает их завершения, если ACL того не требует. Взгляните на следующую конфигурацию: Запросы, пришедшие с 10.0.0.1, будут разрешены немедленно, т.к. не указано пользователя для этого хоста. Однако запросы с 10.0.0.2 будут разрешены только после завершения поиска ident и если установлено, что имя пользователя kim, lisa, frank или joe.

10.8 Типичные ошибки

Логическое И/ИЛИ

К примеру, следующая конфигурация контроля доступа никогда не будет работать: Для того, чтобы запрос был разрешен, он должен совпасть и с acl ``ME'' И acl ``YOU''. Это невозможно, т.к. IP-адрес в данном случаю может совпасть либо с одним либо с другим acl. Это должно быть заменено на: Такая конструкция тоже должна работать:

перепутанные allow/deny

Я перечитал несколько раз мой squid.conf, поговорил с коллегами, почитал FAQ и документацию по Squid Docs и никак не могу понять почему следующее не работает.

Я успешно подключаюсь к cachemgr.cgi с нашего web-сервера, но хотелось бы использовать MRTG для мониторинга различных параметров нашего прокси. Когда я пытаюсь использовать 'client' или GET cache_object с машины, на которой работает проски, то всегда получаю "доступ запрещен".

Приведенная здесь задача состоит в том, чтобы разрешить запросы кеш-менеджера с адресов localhost и server и запретить все остальные. Такая политика описывалась правилом:

Проблема состоит в разрешении запроса, правило доступа не срабатывает. К примеру, если IP-адрес источника localhost, тогда ``!localhost'' - ложь и правило доступа не срабатывает, Squid продолжает проверять другие правила. Запросы к кеш-менеджеру с адреса server работают, т.к. server находится в подсети ourhosts, сработает второе правило и запрос будет разрешен. Это значит также, что любой запрос кеш-менеджера из ourhosts будет разрешен.

To implement the desired policy correctly, the access rules should be rewritten as Если вы используете miss_access, не забывайте также добавить правило miss_access для кеш-менеджера:

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

Различия между src и srcdomain типами ACL.

Для типа ACL srcdomain Squid делает обратное преобразование клиентского IP-адреса и проверяет соответствие результата домену, описанному в строке acl. Для типа ACL src Squid вначале преобразует имя хоста в IP-адрес и только потом сравнивает с клиентским IP. Тип ACL src предпочтительнее, чем srcdomain т.к. он не требует преобразования адреса в имя при каждом запросе.

10.9 Я установил собственные контроли доступа, но они не работают! Почему?

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

В squid.conf включите отладку для секции 33 на уровне 2. К примеру: Потом перезапустите Squid.

Теперь, ваш cache.log должен содержать строку для каждого запроса, которая поясняет запрещен или резрешен запрос и с каким ACL он совпал.

Если это не дало вам достаточно информации, чтобы избавиться от проблемы, вы можете также включить детальную отладку процесса обработки ACL Перезапустите Squid.

Теперь ваш cache.log должен содержать детальную трассировку всего процесса контроля доступа. Будте внимательны, на каждый запрос будет по несколько несколько строк.

10.10 Прокси-аутентификация и братские кеши

Только ОДИНОМУ кешу в цепочке разрешено ``использовать'' заголовок Proxy-Authentication в запросе request . Если такой заголовок имел место , то он не должен быть пропущен другим прокси.

10.11 Какой самый простой способ запретить все адреса назаначения кроме одного?

10.12 Кто-нибудь имеет списки порно-сайтов и прочего?

  • Pedro Lineu Orso's List
  • Linux Center Hong Kong's List
  • Snerpa, исландский ISP использует DNS-базу данных IP-адресов запрещенных сайтов, содержащих порно, насилие и т.п., которая обрабатывается небольшим редиректором, написанным на perl. Информацию об этом см. на странице INfilter .

10.13 Squid не распознает мой поддомен

Есть хитрая проблема с контрольм доступа, основанным на имени домена, когда один элемент ACL является является поддоменом другого элементаy. К примеру, взляните на такой списко:

Корень проблемы в структуре данных для индексирования доменных имен в списках контроля доступа. Squid использует Splay trees для списка доменных имен. Как и другие структуры данных в виде дерева, алгоритм поиска требует функции сравнения, которая возвращает -1, 0 или +1 для любой пары ключей (доменных имен). Эт оподобно тому как работает strcmp().

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

10.14 Почему Squid запрещает доступ к некоторым портам?

Это опастно - разрешать Squid содениятся по определенным номерам портов. Демонтсрацией этого может послужить использование Squid кем-либо как SMTP (email) релея. Уверен, что вы знаете, что SMTP релей - один из способов, при помощи кторого спамеры имеюь возможность засорять почтовые ящики. Что бы предотвратить релей почты, Squid запрещает запросы в URL которых указан порт номер 25. Для предостерожности другие порты также должны быть блокированы.

Другой подход - запретить опастные порты. Список опастных портов должен выглядеть примерно так: . и возможно некторые другие.

Загляните в файл /etc/services вашей системы, чтобы получить полный список портов и протоколов.

10.15 А Squid поддерживает использование базы данных типа mySQL для хранения списков ACL?

Замечание: Информация верна для версии 2.2.

Нет, не поддерживает.

10.16 Как мне разрешить доступ к определенному URL только с одного адреса?

Этот пример разрешает доступ к special_url только для special_client. Любому другому клиенту доступ к special_url запрещен.

10.17 Как мне разрешить некоторым клиентам использовать кеш в определенное время ?

Скажем у вас есть две рабочие станции, для которых доступ в Интерент должен быть разрешен только в рабочее время (8:30 - 17:30). Вы можетет использовать нечто подобное:

10.18 Как мне разрешить некоторым пользователям использовать кеш только в определенное время?

10.19 Проблемы с IP ACL-ми, содержащими сложные маски

Замечание: представленная здесь информация верна для версии 2.3.

Следующий ACL дает противоречивый или неожиданный результат: Причина в том, что IP-список доступа помещается в структуру данных в виде ``splay''-дерева. Это дерево треубет сортировки ключей. Когда вы указываете сложную или нестандартную маску (255.0.0.128), это приводит к неверной работе функции сравнивающей пару адрес/маска.

Лучшее решение избавится от проблемы - использовать отдельные имена ACL для каждого значения ACL. Например, измените вышеуказанное на :

10.20 Могу ли я устанавливать ACL-лы, основанные на MAC-адресах, а не на IP?

Да, для некторых операционных систем. В Squid этоназывается ``ARP ACLs'' и поддерживается на Linux, Solaris и возможно для BSD вариантов.

ЗАМЕЧАНИЕ: Squid может определить MAC-адрес клиента только для свое подсети. Если клиент находится в другой подсети, Squid не сможет найти его MAC-адрес.

Чтобы использовать контроль доступа по ARP (MAC), вам прежде всего необходимо скомлилировать Squid c поддержкой этой возможности. Это делается при помощи конфигурационной опции --enable-arp-acl: Если src/acl.c не компилируется, значит возможно ARP ACL не поддерживается вашей системой .

Если всеоткомпилировалось, вы можете добавить несколько строк ARP ACL в ваш squid.conf:

10.21 Отладка ACL

10.22 Могу ли я органичить количество соединений для клиента?

ACL типа maxconn треубет использования client_db . Если вы отключили client_db (к примеру, использовав client_db off) то ACL maxconn не будет работать.

Заметьте также, что вы вы должны объявлять maxconn совместно с типом пользователя (ident, proxy_auth) раньше, чем объявляется тип по IP-адресу.

Появилась необходимость настроить в Squid перенаправление на определенный сайт в случае если пользователь пытается зайти на сайт который находится в списке заблокированных. Я нашел для себя несколько способов реализовать данную задачу.

Рассмотрим способ мгновенного редиректа на заданный сайт и редирект с отображением страницы ERR_ACCESS_DENIED (входящую в состав Squid) и через несколько секунд выполнять редирект на заданную страницу.


Проделываться все будет на Squid 3.5.19 (статья по установке) установленным на Ubuntu server 14.04. Но уверен что способы будут работать и на отличных от моих параметров.

Первый способ. Мгновенный редирект на заданную страницу.

Данный способ крайне просто в применении. В данном способе используем директиву deny_info, синтаксис ее выглядит так:

Читайте также: