Готово!
Скоро материал придет на указанную электронную почту. Также подписывайте на нас в Facebook
Ok
Обратный прокси из KWTS: проверка входящего трафика на наличие «малвари»
Ведущий системный архитектор ICL Services Константин Янсон описал в статье на Хабре пробу использования решения Kaspersky Web Traffic Security в качестве обратного прокси. Ниже приводим текст оригинальной публикации.
В данной статье рассмотрим попытку использования решения Kaspersky Web Traffic Security (KWTS) в качестве обратного прокси (Reverse Proxy). Такой вариант использования не является стандартным и описанным в документации, поэтому данная статья может быть полезной для тех, кто уже выбрал это решение или планирует его использовать в качестве обратного прокси.
Сценариев применения много – например, таким образом можно защитить внутренние ресурсы от внешних атак, основанных на вредоносных файлах. Основная фишка KWTS – это база файловых угроз, которая регулярно обновляется и пользуется заслуженной популярностью. Протокол ICAP позволяет использовать решение в разных сценариях. Я не буду сравнивать другие решения, позволяющие реализовать такой функционал: их безусловно много.
Сфокусируюсь только на возможностях именно решения KWTS, проверю его в деле, и покажу, что оно работает как ожидалось. Статья содержит инструкцию по установке, примеры конфигов и результаты проверки решения файлами с «вредоносами». Также в конце будут отмечены некоторые «неудобства» и особенности.
Описание стенда
В нашей тестовой инфраструктуре были развернуты три незащищенных приложения:
- OWASP Juice Shop v20.2.0, веб-приложение, содержащее уязвимости;
- Damn Vulnerable Web Application (DVWA), веб-приложение, содержащее уязвимости;
- File Browser 2.63.23, веб-приложение для загрузки файлов, файловое хранилище).
Приложения не поддерживают HTTPS и шифрования трафика и так или иначе позволяют провести загрузку файлов на диск сервера.
Для защиты приложений был развернут прокси-сервер на основе Kaspersky Web Traffic Security и сервер Squid версии 6.13 с поддержкой OpenSSL.
С компьютеров пользователей проводились симуляции атак, напрямую к приложению и, через KWTS, для проверки «защиты»:
- загрузка файлов стандартным способом;
- загрузка файлов через эксплуатацию уязвимостей;
- сканирование сайтов на наличие уязвимостей.
Установка
KWTS можно установить как виртуальный аплаенс и как набор отдельных компонентов. Второй вариант более гибкий по конфигурации и поддерживает довольно широкий список операционных систем, так как зависимости минимальны. В данной статье не буду подробно останавливаться на деталях установки и конфигурирования ОС, корректных сетевых параметров, локальных фаерволах и удаленного доступа, думаю уже достаточно статей на эту тему.
В моем примере используется ОС Ubuntu 24.04.3 LTS и установка KWTS в виде отдельных компонентов.
Наш обратный прокси будет фактически состоять из двух довольно независимых компонентов: KWTS и Squid. KWTS будет выполнять роль ICAP сервера и предоставлять интерфейс управления политиками, а Squid возьмет на себя основную роль по работе с HTTP/HTTPS трафиком.
KWTS: установка
До начала установки потребуется установить Nginx:
apt-get install nginx -y
systemctl enable nginx
service nginx start
Проверяем:
service nginx status
Скачиваем дистрибутив KWTS с официального портала.
Устанавливаем:
dpkg -i kwts_6.1.0-4762_amd64.deb
Решение установлено, осталось только его настроить с помощью встроенного скрипта:
/opt/kaspersky/kwts/bin/setup.py –install
Проходимся по шагам установки, нужно выбрать язык и согласиться с лицензионным соглашением и политиками от разработчиков. Выбрать IP-адрес и порт. Если на компьютере присутствует несколько сетевых карт, выбрать ту, что будет использована для сервера ICAP и системы управления. Обратите внимание, что HTTP прокси-сервер (Squid) будет настраиваться позже.
В заключение будет необходимо задать пароль администратора. KWTS в своем составе не имеет встроенного средства управления локальными пользователями. Фактически локально можно создать только одного пользователя – Administrator. Для реализации многопользовательского сценария администрирования и ролевой модели потребуется интеграция с Microsoft Active Directory.
В конце следует задать пароль. Если это первый узел, то пароль нужно придумать уникальный, и разумеется «крипто-стойкий». Если вы добавляете узел в кластер, то пароль будет единым на всех узлах.
После этих простых шагов будет сконфигурировано и запушено несколько сервисов:
-
kwts.uwsgi, kwts.celerybeat, kwts.celeryd, kwts.redis.service, kwts.service, kwtsdb.service
Также у вас появится доступ к системе управления через браузер:
Если это первый сервер ICAP, то после входа с паролем, заданным на предыдущем шаге, нужно будет создать новый кластер (нажать на кнопку).
Если это еще одна «нода» существующего кластера, то ее добавление надо будет производить на мастер-узле (Control node).
Пока не добавлена лицензия, KWTS будет работать с ограниченным функционалом. Любые проверки «антивирусного движка» будут приводить к блокировкам трафика. Работать будут только простые политики для трафика, не требующие сигнатурной базы данных. Пока вы не получили лицензию, не используйте эти политики, это позволит без задержек сконфигурировать остальной функционал.
Формально лицензирование осуществляется по количеству пользователей, но у KWTS нет технической возможности посчитать и визуализировать текущее потребление лицензий. Т.е. у администратора нет даже инструмента, позволяющего посчитать количество пользователей и оценить реальное потребление.
Теоретически это можно сделать, только используя внешний анализатор логов, но там тоже нет четкого алгоритма расчета. Производитель рекомендует при расчете количества лицензий считать сотрудников организации, использующих прокси, но для варианта с reverse-proxy, и тем более ICAP-сервера, явного и внятного ответа, «как правильно считать», нет.
SQUID
Производитель рекомендует использовать широко известный и популярный Squid, что открывает огромные возможности по тонкой настройке и оптимизации. Это является огромным плюсом для тех, кто способен разобраться в нюансах конфигурирования сквида, и минусом для тех, кто планировал формат «все включено» и «далее-далее-далее». Производитель публикует на сайте базовый конфиг, но для создания высоконагруженного и производительного кластера придется погрузиться в дебри тонкой конфигурации операционной системы и самого сквида.
В моем примере я разберу вариант, не описанный в документации вендора и мало представленный в других статьях: мы развернем сервер прокси «наоборот», реализуя формат обратного прокси.
Устанавливаем сквид:
apt install squid-openssl -y
systemctl enable squid
service squid start
Проверяем:
service squid status
Конфигурирование SQUID
До начала конфигурирования необходимо получить SSL-сертификат для защищаемого сайта и ключ (без пароля) в формате РЕМ.
-
/etc/squid/crt-reverse-proxy.pem– WEB сертификат, должны присутствовать поля ALT, в которых указаны адреса всех приложений, используемые в ссылках (можно и wildcard). Для более корректного отображения сайта в некоторых браузерах лучше добавить всю цепочку сертификатов. -
/etc/squid/key-reverse-proxy.pem– ключ, без пароля.
В качестве точки подключения будет использоваться машина с установленным Squid сервисом (Frontend). После проверки все запросы будут перенаправляться уже по не зашифрованному протоколу HTTP на приложения (Backend). Важно, чтобы сам сквид получал расшифрованные данные, поэтому шифрование должно происходить либо на нем, либо на внешнем балансировщике. В моем примере сквид будет играть роль TLS «фронта» для сайтов, не поддерживающих TLS.
Заполняем конфиг Squid /etc/squid/squid.conf:
#Тут можно определить IP адреса пользователей приложений. В моем примере доступ к приложениям разрешен всем (all/any)
acl ExternalUserIP src all
http_access allow ExternalUserIP
#Frontend для приложения «File Browser 2.63.23»
https_port 8080 accel name=Frontend-01 cert=/etc/squid/crt-reverse-proxy.pem key=/etc/squid/key-reverse-proxy.pem defaultsite=juiceshop-proxy.demo.land:8080
cache_peer juiceshop.demo.land parent 8080 0 no-digest no-query proxy-only no-netdb-exchange originserver name=Backend-01
acl Site-01 myportname Frontend-01
cache_peer_access Backend-01 allow Site-01
cache_peer_access Backend-01 deny all
#Frontend для приложения «Damn Vulnerable Web Application (DVWA)»
https_port 4280 accel name=Frontend-02 cert=/etc/squid/crt-reverse-proxy.pem key=/etc/squid/key-reverse-proxy.pem defaultsite=juiceshop-proxy.demo.land:4280
cache_peer juiceshop.demo.land parent 4280 0 no-digest no-query proxy-only no-netdb-exchange originserver name=Backend-02
acl Site-02 myportname Frontend-02
cache_peer_access Backend-02 allow Site-02
cache_peer_access Backend-02 deny all
#Frontend для приложения «OWASP Juice Shop v20.2.0»
https_port 8000 accel name=Frontend-03 cert=/etc/squid/crt-reverse-proxy.pem key=/etc/squid/key-reverse-proxy.pem defaultsite=juiceshop-proxy.demo.land:8000
cache_peer juiceshop.demo.land parent 80 0 no-digest no-query proxy-only no-netdb-exchange originserver name=Backend-03
acl Site-03 myportname Frontend-03
cache_peer_access Backend-03 allow Site-03
cache_peer_access Backend-03 deny all
#Конфигурация отправки данных на ICAP сервер KWTS
icap_enable on
adaptation_send_username on
adaptation_send_client_ip on
icap_connect_timeout 4 second
icap_service kwts_req reqmod_precache icap://127.0.0.1:1344/av/reqmod bypass=0
icap_service kwts_res respmod_precache icap://127.0.0.1:1344/av/respmod bypass=0
icap_service_failure_limit -1
adaptation_access kwts_req allow all
adaptation_access kwts_res allow all
После изменения конфигурации /etc/squid/squid.conf потребуется перезапустить сервис:
squid -k reconfigure
Note: Параметры no-digest, no-query, proxy-only, no-netdb-exchange, originserver важны чтобы сквид не пытался воспринимать наши приложения как нижестоящий сервер.
Этой конфигурации достаточно для работы Squid в режиме Reverse Proxy с незначительной нагрузкой для большинства приложений. Для нагруженных кластеров и «особых» приложений необходимо будет подтюнить ряд параметров, которые в моем примере приняли значение «по умолчанию».
Продолжение статьи читайте на Хабре.
Подпишитесь на рассылку и будьте в курсе наших последних новостей