Как готовить кальмара, думаю что не я один сталкивался с задачей настройки Squid'а для разграничения доступа сотрудникам предприятия, но при этом он должен быть «прозрачным». Другими словами конфигурация показанная далее удовлетворяет трём условиям:
- Имеется список запрещенных интернет-ресурсов, доступ к которым закрыт у всех пользователей (Пример: социальные сети);
- Имеется список разрешенных интернет-ресурсов, доступ к которым открыт у всех пользователей (Пример: портал государственных услуг);
- Имеется список ip-адресов пользователей которые должны иметь доступ ко всем интернет-ресурсам кроме входящих в список запрещенных.
Хотелось бы уточнить по последнему пункту, так как шлюз «прозрачный», то использовать доменную авторизацию пользователей мы не можем, по данной причине выбрано разграничение именно по ip-адресам.
В качестве базовой конфигурации использовались материалы из статьи «Прозрачный» Squid с фильтрацией HTTPS ресурсов без подмены сертификатов (x86). Так как установка и настройка компонентов в данной статье описаны достаточно подробно, я пропущу данную информацию.
Программное обеспечение использованное мной для тестирование конфигурации:
- Gentoo Linux версии Base System release 2.2;
- Squid 3.5.22;
- OpenSSL 1.0.2j
Итак, файл /etc/squid/squid.conf:
acl localnet src 192.168.0.0/16 # RFC1918 possible internal network
acl SSL_ports port 443
acl Safe_ports port 80 # http
acl Safe_ports port 21 # ftp
acl Safe_ports port 443 # https
acl Safe_ports port 70 # gopher
acl Safe_ports port 210 # wais
acl Safe_ports port 1025-65535 # unregistered ports
acl Safe_ports port 280 # http-mgmt
acl Safe_ports port 488 # gss-http
acl Safe_ports port 591 # filemaker
acl Safe_ports port 777 # multiling http
acl Safe_ports port 901 # SWAT
acl CONNECT method CONNECT
#Добавление в acl трёх списков: запрещенные, разрешенные и группа расширенного доступа
acl denied_urls url_regex "/etc/squid/denied_urls"
acl allowed_urls url_regex "/etc/squid/allowed_urls"
acl extended_access_group src "/etc/squid/extended_access_group"
http_access deny !Safe_ports
http_access deny CONNECT !SSL_ports
http_access allow localhost manager
http_access deny manager
#Ключевая строчка из-за которой долго ломали голову, так как без нее запрос сертификатов к сайтам
# на https не осуществляется.
#Разрешаем осуществлять коннект к ресурсу, если https
http_access allow localnet CONNECT
#Запрещаем всем доступ на запрещенные сайты
http_access deny denied_urls
#Этим правилом разрешаем всем кто не в группе расширенного доступа ходить только на
#разрешенные сайты
http_access deny !extended_access_group !allowed_urls
http_access allow localnet
http_access allow localhost
http_access deny all
#Обязательно один из портов должен быть в таком виде и являться заглушкой
http_port 3130
http_port 3128 intercept
https_port 3129 intercept ssl-bump options=ALL:NO_SSLv3:NO_SSLv2 connection-auth=off cert=/etc/squid/squidCA.pem
always_direct allow all
sslproxy_cert_error allow all
sslproxy_flags DONT_VERIFY_PEER
#Правила доступа для ssl
acl allowed_urls_ssl ssl::server_name_regex "/etc/squid/allowed_urls"
acl denied_urls_ssl ssl::server_name_regex "/etc/squid/denied_urls"
acl step1 at_step SslBump1
ssl_bump peek step1
ssl_bump terminate denied_urls_ssl
ssl_bump splice extended_access_group
ssl_bump terminate !allowed_urls_ssl
ssl_bump splice all
sslcrtd_program /usr/lib/squid/ssl_crtd -s /var/lib/ssl_db -M 4MB
#cache_dir ufs /var/cache/squid 100 16 256
coredump_dir /var/cache/squid
refresh_pattern ^ftp: 1440 20% 10080
refresh_pattern ^gopher: 1440 0% 1440
refresh_pattern -i (/cgi-bin/|\?) 0 0% 0
refresh_pattern . 0 20% 4320
Перед запуском Squid'а не забываем создать три файла в /etc/squid/. denied_urls и allowed_urls вида:
geektimes.ru
habrahabr.ru
toster.ru
windowsupdate.microsoft.com
И extended_access_group вида:
192.168.1.5 #Иванов И.И.
192.168.1.87 #Петров П.П.
192.168.1.108 #Сидоров С.С.
При обращении по http на запрещенный сайт выдаст стандартную заглушку Squid'а, а по https — «ERR_SSL_PROTOCOL_ERROR».
Спасибо за прочтение статьи.
Комментарии (24)
MagicGTS
08.11.2016 20:58Отвечу за автора: не всегда такой вариант работает, и часто нужно просто иметь статистику.
avesnin
08.11.2016 21:59А если добавить ещё разделение ширины канала для групп пользователей — вообще замечательно будет.
zuzzer
09.11.2016 04:17А потом захочется получать группы из AD, потом разобраться с автоматизацией для 100+ пользователей, потом сделать гибкие черные/белые групповые/персональные списки и их перекрытие и т. д. Вот тут-то и начинается веселье с конфигами.
GoldJee
09.11.2016 04:13Спасибо за статью. Настроил Squid с использованием приведенного конфига.
Решил потестировать. В Firefox в настройках прокси указал следующее:
В результате для любого адреса, даже из списка разрешенных, браузер выдает ошибку «Проксии-серрвер отказывается принимать соединения».
С машины, на которой установлен Squid, попробовал сделать
>telnet 127.0.0.1 3128
В результате:
Trying 127.0.0.1…
telnet: Unable to connect to remote host: Connection refused
ЧЯДНТ?
Заранее прошу прощения, если вопрос глупый. У меня нет опыта настройки Squid, а ваше руководство я решил взять в качестве старта.stork_teadfort
09.11.2016 04:28Проблема в том, что вы не понимаете идею прозрачного прокси — его не нужно указывать «В Firefox в настройках прокси». Просто укажите прокси как основной шлюз.
NioriX
09.11.2016 04:35Возможно стоит сделать прокси не прозрачным. Т.е. убрать опцию intercept. В конфигурации из статьи предполагается что траффик от пользователей просто приходит по маршрутам на сквид, либо сквид является «шлюзом по умолчанию». А уже на нем через фаирвол траффик заворачивается на порты 3128 и 3129. В том и прозрачность, что браузет не подозревает о прокси. У вас же он прописан явно. Хотя по телнету порты должны отвечать в любом случае. Значит свид не стартует, Тут причин может быть туча. Может в конфиге таки ошиблись. Может у вас selinux не дает сквиду слушать нестандартные порты, может фаирвол. Все зависит от ОС и настроек. тут без логов сложно что то сказать. Так что сперва смотрите как в принципе настраивается сквид на вашей ОС, а уже когда хоть что то заработает пробуйте конфиг из статьи.
GoldJee
09.11.2016 13:50Большое спасибо всем прокомментировавшим мое сообщение.
Действительно, я неверно понимал идею «прозрачности».
Разобрался с вопросом, модифицировав дефолтный конфиг сквида и добавив нужные строки.
TheRexx
09.11.2016 04:36Проверьте все ли вы сделали по статье указанной до конфигурации. Идея в том, что указывать прокси в настройках браузера не нужно, у вас просто должен быть маршрут до Squid, либо default route на него. А на самом сервере со Squid:
iptables -t nat -A PREROUTING -p tcp -m tcp -s 192.168.1.0/24 --dport 443 -j REDIRECT --to-ports 3129 iptables -t nat -A PREROUTING -p tcp -m tcp -s 192.168.1.0/24 --dport 80 -j REDIRECT --to-ports 3128
То есть вы заворачиваете входящий трафик по 80 на 3128 порт, и по 443 на 3129
kucheriavij
09.11.2016 08:28несколько лет назад делал все тоже самое, только со squidguard, и как выше писали, впоследствии руководству, захотелось и черные, и белые списки, и груповые политики, и еще и собирать статистику каждого пользователя, и смотреть траффик, и все это без авторизации, так как денег на машину под контролер домена не хотели выделять. А закончилось все тем, что пользователи все это обходили через анонимайзеры, в итоге затея провалилась с треском
SergeyHa
09.11.2016 12:49перекрыть доступ к анонимайзерам? запретить тор сеть по хешу экзешника запускатора?
kucheriavij
09.11.2016 12:58Несколько лет назад, это в году этак 2010, про тор тогда мало кто знал (мои пользователи точно не знали), а анонимайзеры я устал перекрывать, закрываешь один, они другой находят. Вообще в моем случае сама идея регулировать трафик была дебильной
sergeysakirkin
10.11.2016 04:05Противостояние щита и меча.
Самая действенная политика — белые списки.kucheriavij
10.11.2016 08:52Это имеет смысл когда ты работаешь в каком-нибудь ЗАО «Тандер», где только в главном офисе 5к сотрудников. А когда это обычная провинциальная веб студия с 20 сотрудниками, какие нафиг запреты. Поэтому идея и провалилась с треском, люди не могли работать нормально, в итоге все к чертям послали руководство, и он остался у разбитого корыта
zuzzer
09.11.2016 17:06Хм, а как привязывались пользователи к IP в условиях DHCP? Мне с ходу видятся два, немного костыльных, варианта: а) дружить с DHCP сервером и держать в squidguard'е и агрегаторе статистики данные по выданным адресам (плохо, привязываемся к машине, а не пользователю) и б) ставит на машины микроагента, который будет стучать с интервалом в эннадцать секунд на прокси и сообщать текущего активного пользователя. Ну и по прежнему вести учет кто откуда (тоже плохо, т. к. надо софтину могут, к примеру, прибить и надо изобретать дополнительные проверки). Всё остальное решается или обвязкой скриптовой прокси или административно.
kucheriavij
09.11.2016 20:30Я первый вариант использовал. Статистику так и не сделал, это был мой личный протест, так как у руководства разыгралась на тот момент параноя))
cjava
10.11.2016 04:05А никто не делал авторизацию по ip адресу через агента на клиенте? По аналогии с Microsoft ISA Agent. Агент отправляет данные о пользователе, выполнившем вход на хосте и IP адрес хоста. На стороне Squid'а на основе правил для пользователей обновляется ACL с ip адресом.
Hissing_Bridge
10.11.2016 04:05По-моему статья припозднилась лет на *цать. Та же хабра, да и вообще интернет переполнены статьями о настройки прозрачного проксирования. Тут же просто листинг конфига.
DaemonGloom
Простите, а чем вас не устроила авторизация kerberos/ntlm и автоопределение прокси через опцию dhcp? Для пользователя будет проходить вполне незаметно.
Shi
А что делать с мобильными устройствами? Там NTLM не катит(
TheRexx
Было бы интересно посмотреть такую отказоустойчивую конфигурацию, с DHCP, устройств на 300-350.
saamich
Можно уточнить — в чем отказоустойчивость вашей конфигурации- в статье этого не увидел.
TheRexx
В комментарии выше, имеется ввиду, отказоустойчивый DHCP. И он не несёт саркастического оттенка. Есть такая реальная задача.