Prueba gratis

Настройка SQUID

Secure Tower поддерживает версии SQUID старше 3.0. Для активации ICAP в squid необходимо внести в конфиг следующие строки:

squid.conf

icap_enable onicap_send_client_ip onicap_preview_enable onicap_preview_size 4096icap_service_failure_limit -1icap_service service_req reqmod_precache 0 icap://INTERFACE_IP:1344/reqmodadaptation_access service_req allow all

где:

  • INTERFACE_IP – ip-адрес ICAP-сервера SecureTower. Эта настройка позволит контролировать нашему ICAP трафик, проходящий через squid (в том числе ssl, если его перехват настроен);
  • reqmod - используется для пересылки на ICAP исходящего трафика;
  • respmod - используется для пересылки на ICAP входящего трафика (переработаной версией ICAP в ST не поддерживается, т.к. смысла нет);
  • Режимы precache и postcache отличаются порядком получения данных. Postcache (в версии 3.4 не реализован!) - ICAP получает данные уже помещенные в кэш SQUID, precache - данные запрашиваются у оригинального сервера;
  • reqmod_precache 0 - число означает способ обработки ошибки. 0 - если ICAP не сможет обработать трафик, то соединение будет сброшено, 1 - трафик будет проигнорирован ICAP и запрос выполнится (сокращенное использование команды bypass);
  • icap_service_failure_limit нужна на загруженных серверах squid. Опция отключает контроль колчества ошибок и временное отключение icap;

Прокси сервер Squid может работать в 2 режимах: классический прокси и прозрачный. Классический способ требует настройки на софте (браузерах и др.) IP и порта прокси, в тоже время прозрачный прокси не требует дополнительной настройки на  клиентах, весь трафик направляется на шлюз в чистом виде. Эти режимы настраиваются по разному в конфиге и фаерволе сервера.

Настройка режима классического прокси сервера с работой через порт 3128:

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

squid.conf

## Recommended minimum configuration:## Example rule allowing access from your local networks.# Adapt to list your (internal) IP networks from where browsing# should be allowedvisible_hostname lnx-sqd.contoso.localacl localnet src 192.168.70.0/24acl SSL_ports port 443acl Safe_ports port 80 # httpacl Safe_ports port 21 # ftpacl Safe_ports port 443 # httpsacl Safe_ports port 70 # gopheracl Safe_ports port 210 # waisacl Safe_ports port 1025-65535 # unregistered portsacl Safe_ports port 280 # http-mgmtacl Safe_ports port 488 # gss-httpacl Safe_ports port 591 # filemakeracl Safe_ports port 777 # multiling httpacl CONNECT method CONNECT## Recommended minimum Access Permission configuration:## Deny requests to certain unsafe portshttp_access deny !Safe_ports# Deny CONNECT to other than secure SSL portshttp_access deny CONNECT !SSL_ports# Only allow cachemgr access from localhosthttp_access allow localhost managerhttp_access deny manager# We strongly recommend the following be uncommented to protect innocent# web applications running on the proxy server who think the only# one who can access services on "localhost" is a local user#http_access deny to_localhost## INSERT YOUR OWN RULE(S) HERE TO ALLOW ACCESS FROM YOUR CLIENTS## Example rule allowing access from your local networks.# Adapt localnet in the ACL section to list your (internal) IP networks# from where browsing should be allowedhttp_access allow localnethttp_access allow localhost# And finally deny all other access to this proxyhttp_access deny allhttp_port 3128# Uncomment and adjust the following to add a disk cache directory.cache_dir ufs /var/spool/squid 100 16 256# Leave coredumps in the first cache dircoredump_dir /var/spool/squidicap_enable onicap_preview_enable onicap_preview_size 4096icap_service_failure_limit -1icap_send_client_ip onicap_service service_req reqmod_precache 0 icap://192.168.70.2:1344/req_modadaptation_access service_req allow all## Add any of your own refresh_pattern entries above these.#refresh_pattern ^ftp: 1440 20% 10080refresh_pattern ^gopher: 1440 0% 1440refresh_pattern -i (/cgi-bin/|\?) 0 0% 0refresh_pattern . 0 20% 4320

Это рабочий конфиг squid на порт 3128 с активированным ICAP. Жирным выделеные 2 строчки, которые необходимо скорректировать под себя.

acl localnet src 192.168.70.0/24 - этот acl содержит диапазон сети контролируемой локальной сети и обозначает его как localnet. Далее в настройках списков контроля доступа можно использовать это обозначение.

http_port 3128 - указывает серверу порт и интерфейс для прослушки (если интерфейс не указан, то слушает все доступные).

  • icap_preview_enable on    - включает режим предпросмотра (будет браться только первые N байт из post запроса для анализа содержимого и принятия решения о действии согласно acl)
  • icap_preview_size 4096    - размер загружаемого блока для предпросмотра

Этого конфига достаточно для функционирования ICAP в классическом режиме и контроле НЕ шифрованного трафика через ICAP системой SecureTower.

Настройка прозрачного режима работы прокси сервера через порт 3128.

В этом режиме трафик от клиентов идет на 80 и 443 порт, но squid слушает только свой 3128 порт. Поэтому необходимо сделать перенаправление трафика с портов 80/443 на порт 3128. Привожу необходимые правила для iptables:

iptables

*filter-A INPUT -p tcp --dport 80 -j ACCEPT-A INPUT -p tcp --dport 3128 -j ACCEPT*nat-A PREROUTING -s source_ip -p tcp --dport 80 -j REDIRECT --to-port 3128

Первые 2 правила разрешают входящий трафик на сервер для нужных портов, 4 правило редиректит нужный трафик на порт 3128.

source_ip - адрес клиента или сети (192.168.1.0/24), использующий прокси;

А так же нужна 1 строчка в конфиге, активирующая прозрачный режим:

http_port 3128 intercept

В версиях squid до 3.1 вместо intercept будет transparent. На версии 3.4 работает одинаково intercept/transparent.

Необходимо заметить, что никакой дополнительной настройки и поддержки ICAP для перехвата шифрованного трафика не нужно, все делается самим squid, и, если конфиг верный, трафик будет расшифровываться и подаваться в раскрытом виде на ICAP сервер ST.

Необходимые строки конфига для активации режима перехвата SSL:

squid.conf

http_port 3128 ssl-bump generate-host-certificates=on dynamic_cert_mem_cache_size=4MB cert=/etc/squid/ssl/squid.pem key=/etc/squid/ssl/squid.keysslproxy_flags DONT_VERIFY_PEERsslproxy_cert_error allow allalways_direct allow allssl_bump client-first allssl_bump server-first allsslcrtd_program /usr/lib64/squid/ssl_crtd -s /usr/share/squid/ssl_db -M 4MBsslcrtd_children 5

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

Строка

sslcrtd_program /usr/lib64/squid/ssl_crtd -s /usr/share/squid/ssl_db -M 4MB

указывает расположение утилиты по генерации сертов, в разных дистрибутивах будет разный путь, потому лучше искать ее поиском и указывать верный путь. Во второй части указывается папка для хранения сгенерированных сертификатов при перехвате. Ее можно создать в любом месте (если не создалась при установке), главное обеспечить ей необходимые права для доступа squid (squid:squid) , если демон работает от юзера nobody (что рекомедуется), то права nobody:xxx

Последовательность действий для генерирования сертификата и базы сертификатов:

  • генерация самоподписанного сертификата и ключа УЦ:

# mkdir /etc/squid/ssl && cd /etc/squid/ssl && chown -R squid:squid /etc/squid/ssl# openssl genrsa -out /etc/squid/ssl/squid.key# openssl req -new -key /etc/squid/ssl/squid.key -out /etc/squid/ssl/squid.csr# openssl x509 -req -days 3650 -in /etc/squid/ssl/squid.csr -signkey /etc/squid/ssl/squid.key -out /etc/squid/ssl/squid.pem

  • создаем папку и базу для сертификатов

# /usr/lib64/squid/ssl_crtd -c -s /usr/share/squid/ssl_db && chown -R squid:squid /usr/share/squid/ssl_db

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

 Со стороны Squid это все необходимое, теперь нужно настроить пере направление трафика с 443 на порт прокси:

iptables

*filter-A INPUT -p tcp --dport 80 -j ACCEPT-A INPUT -p tcp --dport 443 -j ACCEPT-A INPUT -p tcp --dport 3128 -j ACCEPT-A INPUT -p tcp --dport 3129 -j ACCEPT*nat-A PREROUTING -s 192.168.70.13 -p tcp --dport 80 -j REDIRECT --to-port 3128-A PREROUTING -s 192.168.70.13 -p tcp --dport 443 -j REDIRECT --to-port 3128

Как бонус некоторые оптимизационные параметры для squid (по сравнению с дефолтным конфигом работа значительно ускорилась):

squid.conf  Развернуть исходный код

cache_replacement_policy heap LFUDAcache_swap_low 90cache_swap_high 95maximum_object_size_in_memory 50 KBcache_mem 100 MBlogfile_rotate 10memory_pools offmaximum_object_size 50 MBquick_abort_min 0 KBquick_abort_max 0 KBlog_icp_queries offclient_db offbuffered_logs onhalf_closed_clients off

Данная настройка позволит перехватывать системе SecureTower весь HTTP/HTTPS трафик прокси сервера через свой ICAP.

Прокси сервер Squid не является SOCKS прокси и нет смысла заворачивать на него отличный от http трафик.