Как готовить кальмара, думаю что не я один сталкивался с задачей настройки 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)


  1. DaemonGloom
    08.11.2016 20:17

    Простите, а чем вас не устроила авторизация kerberos/ntlm и автоопределение прокси через опцию dhcp? Для пользователя будет проходить вполне незаметно.


    1. Shi
      08.11.2016 21:17

      А что делать с мобильными устройствами? Там NTLM не катит(


    1. TheRexx
      09.11.2016 05:11

      Было бы интересно посмотреть такую отказоустойчивую конфигурацию, с DHCP, устройств на 300-350.


      1. saamich
        09.11.2016 10:41

        Можно уточнить — в чем отказоустойчивость вашей конфигурации- в статье этого не увидел.


        1. TheRexx
          09.11.2016 11:03

          В комментарии выше, имеется ввиду, отказоустойчивый DHCP. И он не несёт саркастического оттенка. Есть такая реальная задача.


  1. MagicGTS
    08.11.2016 20:58

    Отвечу за автора: не всегда такой вариант работает, и часто нужно просто иметь статистику.


  1. avesnin
    08.11.2016 21:59

    А если добавить ещё разделение ширины канала для групп пользователей — вообще замечательно будет.


    1. zuzzer
      09.11.2016 04:17

      А потом захочется получать группы из AD, потом разобраться с автоматизацией для 100+ пользователей, потом сделать гибкие черные/белые групповые/персональные списки и их перекрытие и т. д. Вот тут-то и начинается веселье с конфигами.


  1. GoldJee
    09.11.2016 04:13

    Спасибо за статью. Настроил Squid с использованием приведенного конфига.
    Решил потестировать. В Firefox в настройках прокси указал следующее:
    image
    В результате для любого адреса, даже из списка разрешенных, браузер выдает ошибку «Проксии-серрвер отказывается принимать соединения».

    С машины, на которой установлен Squid, попробовал сделать
    >telnet 127.0.0.1 3128
    В результате:
    Trying 127.0.0.1…
    telnet: Unable to connect to remote host: Connection refused

    ЧЯДНТ?

    Заранее прошу прощения, если вопрос глупый. У меня нет опыта настройки Squid, а ваше руководство я решил взять в качестве старта.


    1. stork_teadfort
      09.11.2016 04:28

      Проблема в том, что вы не понимаете идею прозрачного прокси — его не нужно указывать «В Firefox в настройках прокси». Просто укажите прокси как основной шлюз.


    1. NioriX
      09.11.2016 04:35

      Возможно стоит сделать прокси не прозрачным. Т.е. убрать опцию intercept. В конфигурации из статьи предполагается что траффик от пользователей просто приходит по маршрутам на сквид, либо сквид является «шлюзом по умолчанию». А уже на нем через фаирвол траффик заворачивается на порты 3128 и 3129. В том и прозрачность, что браузет не подозревает о прокси. У вас же он прописан явно. Хотя по телнету порты должны отвечать в любом случае. Значит свид не стартует, Тут причин может быть туча. Может в конфиге таки ошиблись. Может у вас selinux не дает сквиду слушать нестандартные порты, может фаирвол. Все зависит от ОС и настроек. тут без логов сложно что то сказать. Так что сперва смотрите как в принципе настраивается сквид на вашей ОС, а уже когда хоть что то заработает пробуйте конфиг из статьи.


      1. GoldJee
        09.11.2016 13:50

        Большое спасибо всем прокомментировавшим мое сообщение.
        Действительно, я неверно понимал идею «прозрачности».
        Разобрался с вопросом, модифицировав дефолтный конфиг сквида и добавив нужные строки.


    1. 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


  1. Cas1204
    09.11.2016 04:15

    Спасибо огромное, статья очень помогла! Поправьте маленькую опечатку в конфиге: не
    ssl_bump terminate denied_ssl, а
    ssl_bump terminate denied_urls_ssl


    1. TheRexx
      09.11.2016 04:15

      Спасибо, исправил.


  1. kucheriavij
    09.11.2016 08:28

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


    1. SergeyHa
      09.11.2016 12:49

      перекрыть доступ к анонимайзерам? запретить тор сеть по хешу экзешника запускатора?


      1. kucheriavij
        09.11.2016 12:58

        Несколько лет назад, это в году этак 2010, про тор тогда мало кто знал (мои пользователи точно не знали), а анонимайзеры я устал перекрывать, закрываешь один, они другой находят. Вообще в моем случае сама идея регулировать трафик была дебильной


        1. sergeysakirkin
          10.11.2016 04:05

          Противостояние щита и меча.
          Самая действенная политика — белые списки.


          1. kucheriavij
            10.11.2016 08:52

            Это имеет смысл когда ты работаешь в каком-нибудь ЗАО «Тандер», где только в главном офисе 5к сотрудников. А когда это обычная провинциальная веб студия с 20 сотрудниками, какие нафиг запреты. Поэтому идея и провалилась с треском, люди не могли работать нормально, в итоге все к чертям послали руководство, и он остался у разбитого корыта


    1. zuzzer
      09.11.2016 17:06

      Хм, а как привязывались пользователи к IP в условиях DHCP? Мне с ходу видятся два, немного костыльных, варианта: а) дружить с DHCP сервером и держать в squidguard'е и агрегаторе статистики данные по выданным адресам (плохо, привязываемся к машине, а не пользователю) и б) ставит на машины микроагента, который будет стучать с интервалом в эннадцать секунд на прокси и сообщать текущего активного пользователя. Ну и по прежнему вести учет кто откуда (тоже плохо, т. к. надо софтину могут, к примеру, прибить и надо изобретать дополнительные проверки). Всё остальное решается или обвязкой скриптовой прокси или административно.


      1. kucheriavij
        09.11.2016 20:30

        Я первый вариант использовал. Статистику так и не сделал, это был мой личный протест, так как у руководства разыгралась на тот момент параноя))


  1. cjava
    10.11.2016 04:05

    А никто не делал авторизацию по ip адресу через агента на клиенте? По аналогии с Microsoft ISA Agent. Агент отправляет данные о пользователе, выполнившем вход на хосте и IP адрес хоста. На стороне Squid'а на основе правил для пользователей обновляется ACL с ip адресом.


  1. Hissing_Bridge
    10.11.2016 04:05

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