Для полноценного и безопасного функционирования информационной сети существует множество инфраструктурных сервисов, которые обеспечивают ее работоспособность. Одним из таких является прокси, который представляет собой промежуточный узел. Его задача пропускать сквозь себя соединение и выполнять его обработку: кэшировать запросы и ответы, выполнять SSL Bumping, аутентифицировать пользователя в сети и фильтровать сетевые пакеты.
В данном материале, рассмотрим один из примеров такого сервиса и настроим его!
Что такое прокси?
Proxy – это промежуточный узел, основная цель которого обработать проходящий трафик и передать дальше. В корпоративных сегментах сети он используется, как единая сетевая точка выхода пользователей, что позволяет проводить авторизацию и контроль действий. Как описывалось выше его функционал по контролю трафика почти не ограничен:
- SSL bumping;
- Кэширование запросов;
- Аутентификация клиента;
- Сниффинг трафика;
- Контроль посещаемых ресурсов.
И это логично ведь пользовательский трафик, буквально, размазан по сетевой инфраструктуре и в такие моменты его очень сложно отследить, поэтому единая точка исправляет это. Схематично алгоритм работы выглядит так:
Однако кроме корпоративного сегмента, прокси позволяет анонимизировать сетевой трафик, подменяя адрес отправителя внутри пакета. Такую функциональность относительно существующей технологии используют хакеры или и люди, которые скрывают свои цифровые следы. Классически, строя цепочку из прокси, их еще называют proxy-chain, что позволяет скрыть себя за несколькими сетевыми кардонами.
Но как технически реализовано перенаправление трафика в одну точку? Все просто, если в случае reverse-proxy за это отвечает DNAT, который по правилу направит на нужный адрес и порт, то в данном контексте forward-proxy установит с сервером соединение по порту в заранее и внутри этого соединения клиент будет передавать уже нужные пакеты в payload-сегменте.
Упрощенная настройка (без аутентификации)
Для работы с сервисом установим все необходимые пакеты и зависимости:
apt update && apt install squid -y 
Классически файл конфигурации сервера располагается по пути /etc/squid/squid.conf:
nano /etc/squid/squid.conf Рассмотрим настройку нескольких функций сервера, начиная с самой простой и базовой. Удалите все содержимое старой конфигурации и пропишите директивы:
acl mynet src 192.168.1.0/24
http_access allow mynet
http_access deny all
http_port 3128
cache_mem 256 MB
Где каждая из них имеет свою функциональность:
- acl src – именованный список ACL с указанием сегмента сети;
- http_access allow – разрешение на подключение локальной сети к прокси, так как по умолчанию стоит запрет на соединение. Так же данное разрешение позволяет работать по http;
- http_port – порт, на котором будет висеть прокси;
- cache_mem – выделяет кэш-память под задачи кэширования запросов.
После чего сохраним файл и перезапустим сервис, а так же проверим его работоспособность:
systemctl restart squid && systemctl status squid && curl -x "http://ip-proxy:port-proxy" "target"
Но если вы вытащите такую машину наружу, то скорее всего она станет частью инфраструктуры для маскировки чьей-то DDoS или иной атаки, поэтому необходима аутентификация!
Для выполнения тестов, вы можете использовать изолированную среду VPS сервера, на любой из двух платформ vStack cloud или же VMware cloud. Нажмем на кнопку Создать сервер и выберем конфигурацию, подходящую под наши задачи, затем нажмем кнопку Создать.
Потребуется некоторое время для развертывания серверных мощностей. После чего вы можете подключиться любым из удобных способов.
Классическая настройка с аутентификацией
Для защиты прокси-сервера будем использовать классическую аутентификационную HTTP-форму, с помощью заранее установленного модуля. Для начала сформируем учетную запись под которой будет аутентифицироваться пользователь:
sudo apt update && sudo apt install apache2-utils sudo htpasswd -c /etc/squid/passwd 
Фактически в данном контексте прокси является веб-сервисом, которое принимает входящие соединения и поэтому существует возможность использовать модули аутентификации различных механизмов и протоколов. В том числе PAM, который расширяет уровень возможностей своей базой библиотек:
Для того, чтобы аутентификация начала работать перейдем к конфигу и установим параметры, политики для нее:
acl mynet src 192.168.1.0/24
http_access allow mynet
http_port 3128
cache_mem 256 MB
auth_param basic program /usr/lib/squid/basic_ncsa_auth /etc/squid/passwd
auth_param basic realm "Proxy Authentication Required"
acl authenticated proxy_auth REQUIRED
http_access allow authenticated
Верхний блок оставим без изменений, так как он задает политику сегмента сети, рассмотрим написанный блок ниже. Директива auth_param задает параметр аутентификации – библиотеку для проверки пользователя с нашими учетными записями в первой строчке, во второй строку перед самой проверкой. В третьей строке acl proxy_auth параметр значит, что перед подключением будет проверка, а http_access применяет это ранее написанное правило.
Проверим настройку после перезагрузки сервиса:
sudo systemctl restart squidПопробуем соединиться без учетной записи, а затем сразу с ней:
curl -x "http://ip-adders:port" "target-url" && curl -x "http://username:passwd@ip-adders:port" "target-url"
Как видно в результате аутентификация прошла успешно и веб-сервер вернул корректный ответ. Но что если кроме авторизации и контроля пользователей, вам необходимо проводить сниффинг трафика и просматривать, что делают и ищут сотрудники через SSL?
Расширенная настройка с SSL-Bumping
Подобная настройка позволит реализовать подмену сертификата оригинального на собственно подписанный, его предварительно необходимо добавить в доверенные, всем устройствам групповыми политиками. Сам процесс коммуникации будет выглядеть следующим образом:
- Клиент подключается к HTTPS-сайту через Squid.
- Squid перехватывает соединение и устанавливает своё зашифрованное соединение с клиентом.
- Squid устанавливает отдельное зашифрованное соединение с целевым сервером.
- Squid расшифровывает трафик между клиентом и сервером, может его фильтровать или логировать.
- Squid передаёт данные клиенту, подписанные своим сертификатом.
Для начала работы проверьте наличие функционала вашего прокси-сервера, так как билды разные, то и где-то ssl-bumping может отсутствовать:
sudo squid -v | grep "*-ssl*" 
Если у вас нет подобной функции, то доустановите ПО:
sudo apt install squid-openssl И перейдите к созданию сертификата с использованием утилиты:
/usr/lib/squid/security_file_certgen -c -s /var/lib/squid/ssl_db -M 4MB
chown -R squid:squid /var/lib/squid/ssl_dbТак же не забудьте настроить конфиг для бампинга соединения:
http_port 3128 ssl-bump cert=/var/lib/squid/ssl_db/myCA.pem key=/var/lib/squid/ssl_db/myCA.key
ssl_bump peek all
sslcrtd_program /usr/lib/squid/security_file_certgen -s /var/lib/squid/ssl_db -M 4MB
После чего сохраните конфигурацию и перезапустите сервис, прокси должно начать подмену сертификатов. Обратите внимание, что некоторые сайты защищаются от MitM дополнительной проверкой на уровне http сертификата в памяти и если он не совпадает с оригинальным, то соединение блокируется, что может вызвать проблемы у клиентов вашей сети. В таких случаях, для них можно написать исключение.
Данный инфраструктурный сервис является неотъемлемой частью корпоративной сети, а также подсистемы безопасности, позволяя реализовывать авторизацию, фильтрацию контента, а так же являясь шлюзом для пользователей, контролировать посещаемые ресурсы.
