Как работает ACL в Squid

Основы ACL в Squid

Рассмотрим, как именно работают ACL.

Схема управления доступом веб-прокси-сервера Squid состоит из двух разных компонентов:

• Элементы ACL — это строки директив, которые начинаются со слова «acl» и представляют типы тестов, которые выполняются для любой транзакции запроса.
• Правила списка доступа состоят из действия allow (разрешения) или deny (запрета), за которым следует ряд элементов ACL, они используются для указания того, какое действие или ограничение необходимо применить для данного запроса. Они проверяются по порядку, и поиск по списку прекращается, как только одно из правил совпадает. Если правило имеет несколько элементов ACL, оно реализуется как логическая операция И (все элементы ACL правила должны выполняться, чтобы правило считалось совпавшим).

Синтаксис acl:

acl ИМЯ ТИП ОПРЕДЕЛЕНИЕ1 ОПРЕДЕЛЕНИЕ2 ОПРЕДЕЛЕНИЕ3 ...

Примеры:

acl localnet src 192.168.0.102
acl Safe_ports port 80
acl accesses_to_google dstdomain .google.com
acl accesses_to_search_engines dstdomain .yahoo.com .google.com .vivisimo.com
acl accesses_from_marketing_department src 10.52.0.0/16
acl need_to_authenticate proxy_auth

Вы также можете использовать списки определений, которые хранятся в файлах на вашем жёстком диске. Предположим, у вас есть список URL-адресов поисковых систем, которые вы хотите разрешить:

cat /etc/squid/search-engines-urls.txt:
.google.com
.bing.com
.yandex.ru
.duckduckgo.com
.yahoo.com

Тогда ACL для этого файла будет выглядеть так:

acl accessess_to_search_engines dstdomain "/etc/squid/search-engines-urls.txt"

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

Кроме уже упомянутых типов src, port, dstdomain, proxy_auth имеется десятки других типов, например:

• localip
• localport
• proto
• method
• url_regex
• arp
• browser
• http_status
• req_header
• rep_mime_type
• time
• referer_regex

Полный список вы найдёте в документации squid: http://www.squid-cache.org/Doc/config/acl/.

Сами по себе Элементы acl ничего не меняют в поведение прокси-сервера, это только списки для дальнейшего использования с Правилами списка доступа.

Использование ACL: http_access

Если вы записали только списки управления доступом, то фактически ничего не блокируется — это всего лишь определения. ACL можно использовать в различных местах вашего squid.conf. Самая полезная функция, с которой они могут использоваться в паре, это инструкция http_access. Она работает аналогично тому, как брандмауэр обрабатывает правила. Для каждого запроса, который получает Squid, он будет просматривать все операторы http_access по порядку, пока не найдёт соответствующую строку. Затем он либо принимает, либо отклоняет запрос в зависимости от ваших настроек. Остальные правила, идущие после сработавшего, игнорируются.

Общий синтаксис http_access следующий:

http_access (allow|deny) acl1 acl2 acl3 ...

Примеры:

http_access allow localnet
http_access allow localhost
http_access deny !Safe_ports
http_access deny all
http_access allow auth_users
http_access allow all

Следующий набор позволит получить доступ администраторам (независимо от того, как выглядит этот ACL; вероятно, ACL src указывает на подсеть, в которой находятся рабочие станции администраторов). Для всех остальных он будет запрещать доступ к URL-адресам porn. Третье правило позволит всем получить доступ к веб-сайтам в обеденное время (кроме сайтов porn). И, наконец, во всех других случаях будет запрет на подключение к Интернету.

http_access allow accesses_from_admins
http_access deny accesses_to_porn_urls
http_access allow accesses_during_lunchtime
http_access deny all

То есть администраторы имеют доступ ко всем сайтам (даже porn) в любое время, а остальные пользователи имеют доступ в сеть только в обеденный перерыв.

Объединение ACL (И/ИЛИ)

Часто вам нужно комбинировать ACL. Допустим, вы хотите разрешить доступ к google.com только для бэк-офиса. Для этого нужно объединить два ACLS с помощью логического И. Это выглядело бы так:

http_access allow accesses_to_google.com accesses_from_back_office

Если вы хотите использовать ИЛИ и сказать, что либо доступ из бэк-офиса, либо доступ к google.com разрешён, правило будет выглядеть так:

http_access allow accesses_to_google.com
http_access allow accesses_from_back_office

Подводя итог: для И необходимо размещение условий в одной строке. Для ИЛИ необходимо использование отдельных строк.

Следующий набор правил неправильный, он никогда не сработает:

acl ME src 10.0.0.1
acl YOU src 10.0.0.2
http_access allow ME YOU

Чтобы разрешить доступ через прокси IP адресам 10.0.0.1 и 10.0.0.2 правило нужно записать так:

acl ME src 10.0.0.1
acl YOU src 10.0.0.2
http_access allow ME
http_access allow YOU

Другие правила списка доступа

Кроме http_access имеется пара десятков других типов, например:

• http_reply_access
• icp_access
• miss_access
• cache
• url_rewrite_access

Полный список в документации: http://www.squid-cache.org/Doc/config/

Правило http_access по умолчанию

Если во всём конфигурационном файле отсутствуют строки с «http_access», то по умолчанию запрос отклоняется.

Если ни одна из строк «http_access» не приводит к совпадению, значение по умолчанию — противоположно последней строке в списке. Если последняя строка была deny, по умолчанию применяется значение allow. И наоборот, если последняя строка allow, по умолчанию будет применено deny. Чтобы не запутаться рекомендуется иметь запись «deny all» в конце ваших списков доступа, чтобы избежать возможной путаницы. То есть после всех правил просто добавляйте строку:

http_access deny all

Ошибки при использовании http_access

Рассмотрим комбинацию правил «блокировка сайтов + авторизация на прокси-сервере», почему следующий набор неправильный?

http_port 4080
via off

auth_param basic program /usr/lib/squid/basic_ncsa_auth /etc/squid/passwd
auth_param basic children 5
auth_param basic realm Squid Basic Authentication
auth_param basic credentialsttl 2 hours
auth_param basic casesensitive on
auth_param basic realm Squid proxy for HackWare.ru
acl auth_users proxy_auth REQUIRED
http_access allow auth_users

acl bad_urls dstdomain "/etc/squid/blacklisted_sites.acl"
http_access deny bad_urls

Дело в том, что вначале срабатывает правило требующее авторизации на сервере, а именно «http_access allow auth_users». Все последующие директивы http_access просто пропускаются, поэтому сайты не блокируются.

Рассмотрим следующий пример:

http_port 4080
via off

# Здесь блокировка сайтов
acl bad_urls dstdomain "/etc/squid/blacklisted_sites.acl"
http_access deny bad_urls

auth_param basic program /usr/lib/squid/basic_ncsa_auth /etc/squid/passwd
auth_param basic children 5
auth_param basic realm Squid Basic Authentication
auth_param basic credentialsttl 2 hours
auth_param basic casesensitive on
auth_param basic realm Squid proxy for HackWare.ru
acl auth_users proxy_auth REQUIRED
http_access allow auth_users

Поднятая блокировка сайтов срабатывает первой. Причём, ещё даже авторизации на прокси.

Ещё один вариант:

http_port 4080
via off

auth_param basic program /usr/lib/squid/basic_ncsa_auth /etc/squid/passwd
auth_param basic children 5
auth_param basic realm Squid Basic Authentication
auth_param basic credentialsttl 2 hours
auth_param basic casesensitive on
auth_param basic realm Squid proxy for HackWare.ru
acl auth_users proxy_auth REQUIRED

acl bad_urls dstdomain "/etc/squid/blacklisted_sites.acl"

http_access allow auth_users !bad_urls

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

Смотрите также руководство по настройке Squid: Как создать и настроить прокси-сервер Squid