Блокировка сайтов Astra Linux 1.6. Решено использованием squid.

Kaktus

New member
Сообщения
30
#1
Здравствуйте.

Имеется несколько машин с Astra Linux SE 1.6, на одну установлен центр управления
drweb-11.00.2-201905070-esuite-server-unix-linux-x86_64 , на клиенты установлены - drweb-workstations_11.1.0-1905132145+mo~linux_amd64. Подскажите, чтобы разрешить трафик только на несколько ресурсов - возможно ли это реализовать средствами сервера или соответственно клиентов?
Рекомендации этого поста пока не помогают. Не ясно где взять сертификат для Mozilla.
Начали разбирать тему с саппортом DrWeb https://forum.drweb.com/index.php?showtopic=336814&p=905710
 
Последнее редактирование:

Kaktus

New member
Сообщения
30
#2
Пока что реализовали при помощи прозрачного squid 3.5 + ssl_bump
Работает только с Chromium (firefox не понимает системные настройки, и ограничить его работу возможно только принудительно указав в браузере на прокси), разрешаем при помощи whitelist.
https://wiki.astralinux.ru/pages/vi...3520#id-ИспользованиеPROXY-Web-браузерFirefox
 

oko

New member
Сообщения
1 205
#3
Можно для любого браузера через transparent-режим (прозрачный) и ssl-bump. Но squid должен функционировать на базе сервера, являющегося шлюзом по умолчанию для оконечных машин. Тогда трафик перехватывается на этапе маршрутизации (prerouting того же iptables/netfilter) и пересылается на порты squid. Подмена SSL/TLS-сертификата происходит прозрачно для пользователя. Трафик при этом не раскрывается, а только перенаправляется...
Но для, в крупных сетях и вообще для улучшения стабильности лучше все-таки:
  • доставить на оконечную машину собственный корневой сертификат, которым подписан сертификат squid;
  • прописать групповыми или иными политиками в браузере конкретный адрес и "непрозрачный" порт squid;
  • оставить в организации разрешение на использование только одного выбранного браузера, а остальной софт, который требует выход во внешку, либо прописывать вручную как исключение из общей схемы (с фиксацией), либо тоже запретить;
  • вообще весь трафик с Интернет пропускать исключительно через прокси, не допуская самовольных соединений от оконечной машины с удаленными ресурсами Интернет.
 

oko

New member
Сообщения
1 205
#4
*по просьбам трудящихся*
Выкладываю описание (копипаст) внутренней wiki на тему Squid в прозрачном режиме с ssl-перехватом на выделенном сервер-шлюзе (базируется на паре статей с habr.com и личном опыте). Проверено (и работает который год) на Debian 10/11, должно работать и на AstraLinux 1.7.
Пара основных моментов:
  • базовая схема работы любого прокси-сервера (без учета NAT и проч. сетевых штук между клиентом и удаленным ресурсом): клиент (запрос с IP-клиента) → прокси (перехват, удержание сессии с клиентом и создание новой сессии с удаленным ресурсом с использованием IP-прокси) → удаленный ресурс («видит» IP-прокси, а не IP-клиента).
  • непрозрачный режим - клиентское приложение (тот же браузер) подключается к прокси-серверу, указывая адрес и порт соединения вручную. При этом, если клиентское приложения явно перенаправляет на прокси-сервер и HTTP, и HTTPS трафик, проблем с недоверием к SSL-сертификатам и управлением SSL-сессиями не возникает.
  • прозрачный режим - клиентское приложение знать не знает о наличии прокси-сервера, но все его соединения с «внешним миром» перехватываются и подменяются прокси-сервером автоматически. Увы, «прозрачный» режим в контексте SSL-сессии возможен только путем подмены сертификата.
  • фильтрация уровней L3, L4 и L7 - Squid способен анализировать DNS-домен назначения, DNS-домен источника, их IP-адреса, имена пользователей (если настроена аутентификация пользователей на прокси-сервере), а также анализировать URL-адреса и заголовки HTTP-протокола (и некоторых других протоколов). За счет этого можно фильтровать доступ клиентских приложений к чему угодно и как угодно;
  • терминирование HTTPS-соединений - Squid за счет механизма SSL-Bump способен проводить вышеописанную фильтрацию и терминировать (обрывать) HTTPS-сессию (поскольку она зашифрована) или вообще подменять/перенаправлять всю HTTP-сессию (поскольку данные передаются в открытом виде).
Плюсы приведенной схемы:
  • нет необходимости настраивать прокси на каждом отдельном хосте сети;
  • http и https трафик равнозначно перехватываются squid и фильтруются по белым или черным спискам, преобразуются, меняются, перенаправляются - тут как кому захочется;
  • для клиента подмена SSL-сертификата происходит незаметно: squid перехватывает соединение, отдает назначению (web-сайту или иному ресурсу) "свой" сертификат, а потом, после фильтрации, перенаправляет оригинальное соединение клиента с данным ресурсом.
Минусы приведенной схемы:
  • нужен центральный сервер-шлюз, на который направляется весь клиентский трафик изнутри сети ("default gateway" в сетевых настройках каждого клиента);
  • трафик через этот шлюз проходит от клиентов к внешним ресурсом "транзитом";
  • https-трафик не дешифруется полностью, перехватывается только начала SSL-сессии, т.е. всецело логировать на таком шлюзе каждый пакет клиента в дешифрованном виде не выйдет.

Собственно, поехали (с)

1. Ставим Squid с поддержкой Openssl из репозитория: apt install squid-openssl

2. Генерируем сертификат для Squid (или используем уже готовый и подписанный каким-либо внутренним УЦ, если у нас реализован PKI): openssl req -new -newkey rsa:2048 -sha256 -days 3650 -nodes -x509 -extensions v3_ca -keyout /etc/squid/squidCA.pem -out /etc/squid/squidCA.pem, где:

  • rsa:2048 - алгоритм RSA и длина ключа 2048 бит;
  • sha256 - алгоритм хэширования sha256;
  • x509 - тип (стандарт) SSL-сертификата;
  • v3_ca - указатель, что SSL-сертификат будет самоподписанным (он же сертификат самоподписанного УЦ);
  • /etc/squid/squidCA.pem - путь к размещению SSL-сертификата.
3. Генерируем базу хранения SSL-сертификатов (8 Мбайт): /usr/lib/squid/security_file_certgen -c -s /var/spool/squid/ssl_db -M 8MB. Придется повторять каждый раз после очистки /var/spool/squid (например, для уничтожения кэшированных данных).

4. Подсовываем конфигурационный файл /etc/squid/squid.conf. Исправляем его под нашу структуру сети и желаемые порты. Конфигурация хорошо документирована, так что это дело техники. В приведенной конфигурации предполагается, что сервер-шлюз имеет два "внутренних" IP (для двух разных подсетей): 172.16.0.1 и .192.168.1.1. "Внешний" IP не так важен в данном случае...

# Базовые параметры
coredump_dir /var/spool/squid
visible_hostname ОТОБРАЖАЕМОЕ-ИМЯ-СЕРВЕРА (как правило FQDN-имя)
via off
forwarded_for off
shutdown_lifetime 1 seconds

# Параметры DNS (при явном указании dns_nameservers Squid не будет читать штатный /etc/resolv.conf - будет обращаться к указанному DNS-серверу)
dns_nameservers IP-АДРЕС-НУЖНОГО-DNS-СЕРВЕРА
dns_v4_first on
dns_timeout 5 seconds
check_hostnames on
allow_underscore on
dns_defnames off
ignore_unknown_nameservers on
ipcache_size 1024
ipcache_low 90
ipcache_high 95
fqdncache_size 1024

# Прозрачный порт для HTTP (перенаправление происходит автоматически через iptables):
http_port 172.16.0.1:3128 intercept
http_port 192.168.1.1:3128 intercept

# НЕпрозрачный порт для HTTP (можно указать в настройках любого клиентского приложения):
http_port 172.16.0.1:3129
http_port 192.168.1.1:3129

# Прозрачный порт для HTTPS (перенаправление происходит автоматически через iptables):
https_port 172.16.0.1:3130 intercept ssl-bump options=ALL:NO_SSLv3:NO_SSLv2 connection-auth=off cert=/etc/squid/squidCA.pem
https_port 192.168.1.1:3130 intercept ssl-bump options=ALL:NO_SSLv3:NO_SSLv2 connection-auth=off cert=/etc/squid/squidCA.pem

# Перечень портов, на которые Squid будет передавать соединение
acl SSL_ports port 443
acl Safe_ports port 80 # http
acl Safe_ports port 443 # https
acl CONNECT method CONNECT

# определяем тип acl (black_list_special - специальный черный список для этого прокси, white_list_special - белый список)
acl black_list_special dstdom_regex -i "/etc/squid/black_list_special.txt"
acl white_list_special dstdom_regex -i "/etc/squid/white_list_special.txt"

# Описание подсетей или отдельных клиентов, от которых допустимы запросы к Squid (остальные будут отбрасываться)
acl arm0 src 172.16.0.2-172.16.0.100
acl mainservers src 192.168.1.2-192.168.1.50
acl all src all

# Параметры разрешения и блокировки доступа по умолчанию
http_access deny !Safe_ports
http_access deny CONNECT !SSL_ports
http_access allow localhost manager
http_access deny manager

# Параметры разрешения доступа от нужных объектов с учетом черных и белых списков
# - параметры выполняются Squid построчно, поэтому важен порядок записей
# - allow разрешить, deny - запретить
http_access allow all white_list_special
http_access deny all black_list_special
http_access allow arm0
http_access allow mainservers
http_access allow localhost
# - последним всегда указываем блокировать все и ото всех
http_access deny all

# Все запросы, проходящие через этот прокси, МОЖЕМ (если хотим) переводить на другой прокси
#cache_peer IP-АДРЕС-ВЫШЕСТОЯЩЕГО-ПРОКСИ parent 3128 0 proxy-only default no-netdb-exchange no-digest
#cache_peer_access IP-АДРЕС-ВЫШЕСТОЯЩЕГО-ПРОКСИ allow all
#never_direct allow all

# Дополнительные опции SSL (закомментировано для случая ПЕРЕНАПРАВЛЕНИЯ на вышестоящий прокси-сервер)
#always_direct allow all
always_direct allow all
sslproxy_cert_error allow all
sslproxy_flags DONT_VERIFY_PEER
sslcrtd_program /usr/lib/squid/security_file_certgen -s /var/spool/squid/ssl_db -M 8MB
acl step1 at_step SslBump1
ssl_bump peek step1
ssl_bump splice all

# Опции кэширования (подходят для инфраструктуры в 100 одновременных клиентов)
cache_dir ufs /var/spool/squid 20248 64 256
maximum_object_size_in_memory 32 MB
maximum_object_size 16 MB
minimum_object_size 10 KB
# - выделяем 1Гб ОЗУ под кэширование
cache_mem 1024 MB
cache_swap_low 90
cache_swap_high 95
memory_replacement_policy lru

# настраиваем журнализацию (ротация 0, потому что файлы журналов контролируются logrotate)
logformat speciallog %{%d.%m.%Y %H:%M:%S}tl - %>a - %un - "%rm %ru" - "%{User-Agent}>h" - %>Hs %<st %Ss:%Sh
cache_store_log none
client_db off
buffered_logs on
# - не забываем настроить /etc/logrotate.d/squid
logfile_rotate 0
#...первый лог-формат для SARG
access_log /var/log/squid/access_sarg.log
#...второй для человекочитабельности
access_log /var/log/squid/access_text.log speciallog

# Отображения страниц ошибок средствами Squid (можно подправить шаблоны для корпоративного стиля), но работает это только для HTTP
error_directory /usr/share/squid/errors/ru
error_map ERR_ACCESS_DENIED 403,404,407,408,423,500,502,503,504,523,526
deny_info ERR_ACCESS_DENIED black_list_special
 

oko

New member
Сообщения
1 205
#5
5. Настраиваем правила netfilter/iptables. Применяем их так, как хочется (мне удобнее хранить в файле /etc/iptables.rule и подгружать средствами отдельного самописного systemd-Unit с /etc/rc.local при загрузке системы). Пример правил фильтрации и перенаправления трафика приведен для указанного выше случая: два "внутренних" IP (для двух разных подсетей): 172.16.0.1 и .192.168.1.1; "внешний" IP - A.B.C.D.

# ТРАНСЛЯЦИЯ СЕТЕВОГО ТРАФИКА
*nat
:pREROUTING ACCEPT [0:0]
:INPUT ACCEPT [0:0]
:OUTPUT ACCEPT [0:0]
:pOSTROUTING ACCEPT [0:0]
# -- Правила перевода входящих соединений HTTP/HTTPS на порты Squid в прозрачном режиме на этом сервере
-A PREROUTING -s 172.16.0.0/24 -p tcp -m tcp --dport 80 -j DNAT --to-destination 172.16.0.1:3128
-A PREROUTING -s 192.168.1.0/24 -p tcp -m tcp --dport 80 -j DNAT --to-destination 192.168.1.1:3128
-A PREROUTING -s 172.16.0.0/24 -p tcp -m tcp --dport 443 -j DNAT --to-destination 172.16.0.1:3130
-A PREROUTING -s 192.168.1.0/24 -p tcp -m tcp --dport 443 -j DNAT --to-destination 192.168.1.1:3130
# -- Правила для остального трафика, тразитно проходящего через шлюз, и NAT во внешние сети (при необходимости)
#-A POSTROUTING -s 172.16.0.0/24 -j SNAT --to-source A.B.C.D
#-A POSTROUTING -s 192.168.1.0/24 -j SNAT --to-source A.B.C.D

# ФИЛЬТРАЦИЯ СЕТЕВОГО ТРАФИКА
# -- Входящие соединения:
-A INPUT -m conntrack --ctstate INVALID -j DROP
#-A INPUT -s IP-АДРЕС-КАКОГО-НИБУДЬ-АРМ-УПРАВЛЕНИЯ-ДЛЯ-ДОСТУПА-К-ЭТОМУ-ШЛЮЗУ-ПО-SSH -j ACCEPT
-A INPUT -i lo -j ACCEPT
-A INPUT -m conntrack --ctstate ESTABLISHED -j ACCEPT
# -- разрешаем нужным клиентам ходить на непрозрачный порт Squid (прокси прописан на клиенте вручную)
-A INPUT -i eth0 -s 172.16.0.5/32 -p tcp -m tcp --dport 3129 -j ACCEPT
# -- разрешаем остальным нужным подсетям обращаться на прозрачные порты Squid
-A INPUT -s 172.16.0.0/24 -p tcp -m multiport --dports 3128,3130 -j ACCEPT
-A INPUT -s 192.168.1.0/24 -p tcp -m multiport --dports 3128,3130 -j ACCEPT
# -- добавляем иные правила соединений от клиентов (или из внешних сетей), входящих на шлюз (например, обращение к DNS-сервису, тоже размещенному на этом шлюзе и т.д.)
...
# -- Транзитные соединения:
-A FORWARD -m conntrack --ctstate INVALID -j DROP
-A FORWARD -m conntrack --ctstate ESTABLISHED -j ACCEPT
# -- добавляем иные правила соединений от клиентов (или из внешних сетей), проходящих транзитом через этот шлюз (например, выводим не только HTTP/HTTPS-трафик изнутри во внешние сети)
...
# -- Исходящие соединения (в примере ниже разрешает шлюзу как отвечать на соединения клиентов и внешних сетей, так и самому генерировать соединения к клиентам или к внешним сетям - изменяем по вкусу):
-A OUTPUT -o lo -j ACCEPT
-A OUTPUT -j ACCEPT
COMMIT

6. Принимаем изменение конфигураций Squid и выполняем очистку кэша (рекомендуется после каждого изменения squid.conf). Заодно убеждаемся, что нет ошибок, либо разбираемся с ними самостоятельно - вывод squid весьма подробный: squid -k reconfigure и squid -z

7. Рестартуем сервис squid, проверяем его безошибочный старт (в том числе по файлу журнала, указанному в директиве cache_access_log): service squid restart и service squid status

8. Если все прошло успешно, пробуем подключаться из браузера:
  • вначале указываем в браузере адрес шлюза и непрозрачный порт в параметрах прокси-сервера;
  • затем пробуем подключаться через шлюз без указания прокси-сервера в браузере;
  • внимательно читаем файл журнала Squid, указанного в директиве access_log.
  • к сожалению, метод blacklist и whitelist, заполняемых вручную, не очень удобен и после внесения любых изменений в них придется рестартовать Squid.
9. Генерация blacklist и whitelist - отдельная тема для разговора. В приведенных примерах фильтрация ресурсов по черным и белым спискам использует параметр "dstdom_regex" - анализ URL-адреса домена, к которому выполняется подключение от клиента через Squid, с применением метода REGEXP (регулярные выражения). Хороший ответ по возможным директивам фильтрации приведен тут. Ниже приведены примеры dstdom_regex-фильтрации (.* - любые символы, $ - конец доменного имени, \. - экранирование символа .)

Пример 1 (подсеть серверов Telegram):
^.*149\.154\.167\..*$
^.*149\.154\.175\..*$

Пример 2 (все домены 2 и выше уровня, оканчивающиеся на google вне зависимости от .ru, .com и т.д.):
^.*google\..*$

Пример 3 (любые домены, содержащие в своем название слово microsoft):
^.*microsoft.*$

Пример 4 (все домены 2 и выше уровня, оканчивающиеся на drweb.ru):
^.*drweb\.ru$

Пример 5 (без комментариев):
^.*\.nato$
^.*\.us$
^.*\.uk$

На самом деле, именно для контентной фильтрации (на L7) куда корректнее использовать дополнительные средства типа AdZapper (вырезание рекламы), SquidGuard, а также различные антивирусные движки для автоматической проверки HTTP/HTTPS-соединений. Потому что парой-тройкой blacklist-списков не получится интеллектуально блокировать нужное и разрешать другое нужное одновременно. Но это отдельная тема...