Введение
В данной статье рассмотрим попытку использования решения Kaspersky Web Traffic Security (KWTS) в качестве обратного прокси (Reverse Proxy). Такой вариант использования не является стандартным и описанным в документации, поэтому данная статья может быть полезной для тех, кто уже выбрал это решение или планирует его использовать в качестве обратного прокси.
Сценариев применения много – например, таким образом можно защитить внутренние ресурсы от внешних атак, основанных на вредоносных файлах. Основная фишка KWTS – это база файловых угроз, которая регулярно обновляется и пользуется заслуженной популярностью. Протокол ICAP позволяет использовать решение в разных сценариях. Я не буду сравнивать другие решения, позволяющие реализовать такой функционал: их безусловно много. Сфокусируюсь только на возможностях именно решения KWTS, проверю его в деле, и покажу, что оно работает как ожидалось. Статья содержит инструкцию по установке, примеры конфигов и результаты проверки решения файлами с «вредоносами». Также в конце будут отмечены некоторые «неудобства» и особенности.
П.С. Ранее я писал что решение довольно хорошо интегрируется с SD-WAN тут и тут.
Описание стенда
В нашей тестовой инфраструктуре были развернуты три незащищенных приложения:
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-сервера, явного и внятного ответа, «как правильно считать», нет.
Итак, сервер ICAP и система управления готовы, и теперь на них можно будет подавать трафик с «какого-то» прокси сервера. В нашем случае – это Squid.
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 с незначительной нагрузкой для большинства приложений. Для нагруженных кластеров и «особых» приложений необходимо будет подтюнить ряд параметров, которые в моем примере приняли значение «по умолчанию».
KWTS: Конфигурирование правил
Теперь доступ к нашим приложениям регулируется в двух местах: на уровне Squid и в графическом интерфейсе KWTS. На уровне сквида, в squid.conf, мы разрешили доступ всем пользователям без каких-либо дополнительных ограничений. Сквид имеет довольно мощный арсенал возможностей для правил доступа, но для целей данной статьи мы рассмотрим исключительно возможности KWTS.
Bypass
Для нашего примера необходимо убрать правило, ограничивающее сканирование файлов большого размера. Это правило включено по умолчанию для пользователей прямого прокси и будет пропускать файлы превышающее определенный размер. Если для прямого прокси эта политика может иметь хоть какие-то «оправдания», то для обратного это явно вредная функция.
Access
Настраиваем правила доступа к приложениям. Используем Traffic Filter на основе URL:
В моем случае разрешены все обращения по указанному URL с «подкаталогами».
При необходимости можно использовать следующие возможности фильтрации входящих подключений через KWTS:
Protection
Настроить действия при обнаружении вредоносных вложений. В случае обратного прокси базы данных для Phishing и Malicious link срабатывать не будут. Стоит надеется только на защиту на уровне Malware, Document with Macro и Encrypted objects.
Функционал будет работать только при наличии лицензии иначе, включение этой политики приведет к блокировке передачи данных.
Тестирование
Так как рассмотренный сценарий не является стандартным, описанным производителем, важным этапом является проверка его работы. Проведем тестовые «атаки» на приложения напрямую (без KWTS) и используя «защиту».
Файл virus-01.html:
Файл «virus-02.pdf»:
Файл viris-03.doc:
Файл virus-04.doc зашифрован паролем, поэтому по нему вердикта нет.
File Browser: Закачиваем файл
Вначале проверим возможность закачки для незащищенного подключения без KWTS:
Файлы с вредоносным ПО загружены без проблем:
Теперь попробуем провести копирование уже через HTTPS и KWTS. KWTS блокирует трафик:
Видим, что файлы не были скопированы:
KWTS заблокировал передачу файлов:
Видим, что KWTS успешно справляется с блокировкой и анализом вредоносных вложений для приложений в которых происходит загрузка файлов.
Используем уязвимость кода в приложении
Попробуем воспользоваться уязвимостью в коде «сайта-приложения» Damn Vulnerable Web Application и загрузить на сервер вредоносный файл «нестандартным» способом.
Использую самописный простой скрипт для эксплуатации уязвимости. Вначале без KWTS:
python3 dvwa_file_upload_habr_demo.py -u "http://juiceshop.demo.land:4280/" --cookie "PHPSESSID=92fd02e2b617902d03e04ce53f19e09b; security=low" --only-custom --file ./virus-02.pdf
Результат: файл с малварью (virus-02.pdf) удалось загрузить на сервер:
Пытаемся загрузить файлы с вирусом теперь уже через KWTS:
python3 dvwa_file_upload_habr_demo.py -u "https://juiceshop-proxy.demo.land:4280/" --cookie "PHPSESSID=92fd02e2b617902d03e04ce53f19e09b; security=low" --only-custom --file ./virus-04.doc
python3 dvwa_file_upload_habr_demo.py -u "https://juiceshop-proxy.demo.land:4280/" --cookie "PHPSESSID=92fd02e2b617902d03e04ce53f19e09b; security=low" --only-custom --file ./virus-01.html
Новые файлы (virus-04.doc и virus-01.html) на сервере не появились:
KWTS обнаружил в трафике угрозу и заблокировал передачу:
Сканируем сайт на уязвимости
Запустим сканирование на уязвимости наших веб-ресурсов (приложений) через KWTS и посмотрим, будут ли какие-то блокировки и «сигналы».
Использую популярный сканер Greenbone (OpenVAS):
Тут чуда не случилось, и 99.9% запросов тестирования уязвимостей срабатывает без ограничений. Вот пример аудита с KWTS:
Не буду приводить все попытки проверки уязвимостей, их тысячи, но были разрешены практически все «тесты» стандартных сигнатурных уязвимостей. Но это ожидаемо, KWTS не является решением класса WAF, и ждать от него такого функционала не стоит. Его – задача анализ файлов и URL для исходящего трафика. Для сценария обратного прокси срабатывать будут только файловые «защиты».
Тем не менее, подчеркну то, что при использовании KWTS как обратного прокси появляется возможность оперативно ограничить доступ к какому-то разделу сайта или ограничить выполнение какого-то запроса. Как инструмент применения обходного решения, в виде блокировки политиками, KWTS справляется вполне нормально. Вот пример заблокированных попыток подключения:
Эти подключения с изображения выше не удовлетворяли политикам типа Access.
Заметки
Многопользовательский режим и роли
Как писал выше, одной из особенностей KWTS является отсутствие базы данных собственных пользователей. Локально присутствует только пользователь Administrator. Остальные пользователи должны быть интегрированы через MS AD (LDAP и/или Kerberos). При этом ролевая модель присутствует и можно разделить полномочия различных пользователей.
Обновления и харденинг ОС
Следите за уязвимостями KWTS, Squid и ОС. Для такого ПО как Squid регулярно обнаруживаются уязвимости и выходят исправления. Как ни странно, но «брошенное» средство защиты может оказаться менее защищенным чем защищаемое приложение. В моем случае Squid был настроен без «харденинга» и в сканере уязвимостей показал даже худший результат, чем отдельные приложения. Например, в моем примере сквид не скрывает свое присутствие, и можно даже обнаружить версию ПО.
Тюнинг сквида и проксирования приложений
В данной статье рассмотрен стандартный конфиг для реализации функционала обратного прокси. В случае большой нагрузки понадобится настроить (убрать) кэширование, увеличить количество файловых дескрипторов файлов, отключить аудит некоторых событий на уровне Squid, настроить TCP стек, для приема большого количества сессий, поведение TCP/HTTP сессии к бэкэнду и другое.
Отказоустойчивость
KWTS позволяет «собирать» отказоустойчивые и производительные кластеры. Есть инструменты синхронизации конфигурации KWTS, но нет синхронизации конфигов сквида, так как это считается внешним приложением.
В сочетании в SD-WAN открываются больше возможностей по балансировке, встроенной в это инфраструктурное решение. Детали интеграции я описывал ранее:
Аудит
KWTS не славится своим аудитом и удобным интерфейсом для просмотра событий. События генерируются очень подробные и в большом объеме. Это является причиной того, что пользоваться встроенными средствами KWTS для анализа журналов аудита становится практически невозможно при большом количестве соединений. С этой задачей справляются внешние «лог-коллекторы», в том числе и варианты opensource.
Важно не забыть сконфигурировать «logroate», чтобы в какой-то момент сервер не встал из-за переполненного диска. Логов может быть много, и это вопрос довольно короткого промежутка времени.
Мониторинг
Следить за «сработкой» антивирусного движка можно тремя способами:
в графическом интерфейсе (неудобно);
в событиях аудита, но понадобится система с возможностью корреляции типа SIEM или проще;
через SNMP протокол во внешней системе мониторинга, например, Zabbix (да, необычно, но можно фиксировать события безопасности в Zabbix).
Выводы
KWTS не является идеальным и универсальным решением, но может быть использован в «корпоративном секторе» для шифрования соединения и обработки входящего трафика к HTTP приложениям. Надо понимать, что это только один «кирпичик» защиты. Полноценная защита потребует реализации других средств, но это уже предмет других статей – кстати, доступных на Хабре и не только.
