Обратный прокси на базе KWTS: проверка входящего трафика на вредоносные файлы
Kaspersky Web Traffic Security (KWTS) обычно применяют для анализа веб-трафика, проходящего через прокси-сервер. Однако решение можно использовать и в нестандартном сценарии - как элемент обратного прокси, защищающего внутренние веб-приложения от загрузки вредоносных файлов.
Такой подход особенно актуален для сервисов, где пользователи могут отправлять данные на сервер: файловых хранилищ, корпоративных порталов, систем документооборота, CMS и веб-приложений с функциями импорта. Даже если само приложение не содержит известных уязвимостей, возможность загрузки файлов остается потенциальным каналом проникновения вредоносного кода.
В рассматриваемой схеме KWTS используется совместно с Squid. Антивирусная система анализирует содержимое запросов через протокол ICAP, а Squid принимает входящие соединения, перенаправляет их к внутренним приложениям и передает данные на проверку.
Архитектура тестового стенда
Для проверки были развернуты три приложения:
- OWASP Juice Shop версии 20.2.0 - намеренно уязвимое веб-приложение;
- Damn Vulnerable Web Application (DVWA) - учебная площадка с распространенными уязвимостями;
- File Browser версии 2.63.23 - файловое хранилище с возможностью загрузки объектов на сервер.
Все сервисы работали без HTTPS. Это упрощало эксперимент, поскольку Squid мог анализировать HTTP-запросы без дополнительной настройки расшифровки TLS. Каждое приложение позволяло тем или иным способом сохранить переданные пользователем файлы на диске.
В качестве операционной системы использовалась Ubuntu 24.04.3 LTS. KWTS устанавливался в виде отдельных компонентов, а не готового виртуального устройства. Такой вариант дает больше свободы при выборе архитектуры, сетевых настроек и способа интеграции с уже существующей инфраструктурой.
В стенде проверялись несколько сценариев:
1. обычная загрузка файла через интерфейс приложения;
2. передача файла с использованием уязвимости веб-приложения;
3. попытка обратиться к приложению напрямую, минуя защитный контур;
4. подключение к ресурсу через обратный прокси;
5. сканирование опубликованных сервисов на наличие уязвимостей.
Установка компонентов
Перед развертыванием KWTS устанавливается Nginx:
```bash
apt-get install nginx -y
systemctl enable nginx
systemctl start nginx
systemctl status nginx
```
Далее загружается дистрибутив Kaspersky Web Traffic Security и выполняется установка пакета:
```bash
dpkg -i kwts_6.1.0-4762_amd64.deb
```
После этого запускается штатный скрипт первичной настройки:
```bash
/opt/kaspersky/kwts/bin/setup.py -install
```
В процессе установки необходимо выбрать язык интерфейса, принять лицензионные условия, указать IP-адрес и порт управления. Если сервер оснащен несколькими сетевыми интерфейсами, важно выбрать тот, через который будут доступны ICAP-служба и консоль администрирования.
На этом этапе Squid еще не настраивается: он устанавливается и конфигурируется отдельно.
После завершения начальной настройки задается пароль администратора. Локальная модель пользователей в KWTS ограничена: фактически самостоятельно создается только учетная запись Administrator. Если требуется несколько администраторов с разными полномочиями, понадобится интеграция с Microsoft Active Directory и настройка ролей через каталог.
Роль Squid и взаимодействие с ICAP
В предложенной архитектуре компоненты разделены по функциям:
- KWTS отвечает за анализ объектов, применение политик и антивирусную проверку;
- Squid принимает HTTP-запросы и выполняет роль обратного прокси;
- ICAP обеспечивает передачу содержимого из Squid в KWTS;
- внутренние приложения остаются недоступными напрямую из внешней сети.
Таким образом, запрос пользователя сначала попадает на Squid. Прокси определяет целевой внутренний сервис, передает содержимое на проверку в KWTS и только после успешного анализа направляет запрос приложению.
При обнаружении вредоносного объекта соединение может быть разорвано, а клиенту возвращается страница блокировки. Важно учитывать, что ICAP проверяет именно передаваемое содержимое, поэтому корректность обработки больших файлов, потоковых запросов и нестандартных методов HTTP зависит сразу от нескольких компонентов.
Настройка обратного прокси
Для каждого приложения в Squid создается отдельное правило маршрутизации. Например, внешний адрес может направлять запросы к определенному внутреннему серверу, а разные имена хостов - к разным приложениям.
На практике необходимо заранее определить:
- какие внешние адреса будут опубликованы;
- какие внутренние IP-адреса соответствуют приложениям;
- допустимые HTTP-методы;
- максимальный размер загружаемых объектов;
- время ожидания ответа;
- правила для служебных и статических ресурсов;
- порядок применения ICAP-проверок.
В конфигурации Squid также задаются параметры подключения к ICAP-сервису KWTS. Для защиты файловых операций важно направлять на проверку не только ответы серверов, но и запросы пользователей, содержащие тело сообщения. Иначе антивирус может видеть уже сформированный ответ, но не сможет своевременно остановить загрузку опасного объекта.
Правила Bypass, Access и Protection
Особое внимание следует уделить исключениям. Правило Bypass позволяет пропускать трафик мимо анализа, однако чрезмерное использование таких исключений фактически обнуляет защиту.
Исключения допустимы для технических запросов, которые невозможно корректно обработать через ICAP, но каждое из них должно быть обосновано. Нельзя без необходимости исключать целый домен, каталог загрузки или все запросы определенного типа.
Правила Access определяют, какие клиенты получают доступ к опубликованным приложениям. Здесь можно ограничить источники по IP-адресам, подсетям, группам пользователей или сетевым интерфейсам.
Раздел Protection отвечает за действия при обнаружении угроз. В зависимости от политики объект можно заблокировать, поместить в карантин, записать событие в журнал или разрешить передачу только после дополнительной проверки. Для внешних сервисов безопаснее использовать режим блокировки по умолчанию.
Проверка загрузки файлов
Первый тест выполняется через File Browser. Пользователь загружает файл стандартным способом, а запрос проходит через Squid и ICAP-сервис KWTS.
При наличии вредоносного содержимого KWTS должен распознать объект по сигнатуре или другому механизму анализа и не позволить передать его приложению. При этом необходимо проверять не только сообщение в браузере, но и фактическое состояние файловой системы: опасный файл не должен появляться в каталоге назначения.
Следует учитывать, что тестирование нельзя проводить на реальных вредоносных программах. Для безопасной проверки применяются специальные тестовые строки и файлы, предназначенные для проверки антивирусных систем. Они имитируют обнаружение угрозы, но не представляют опасности для инфраструктуры.
Загрузка через уязвимости
Второй сценарий связан с эксплуатацией слабых мест Juice Shop или DVWA. Если приложение принимает файл через уязвимый endpoint, запрос все равно должен проходить через обратный прокси и ICAP-анализ.
Это позволяет проверить, действительно ли защита контролирует весь входящий поток, а не только загрузки, инициированные через штатный пользовательский интерфейс. Если опасный файл блокируется только при обычной отправке, но проходит через альтернативный URL или нестандартный HTTP-метод, политика настроена неполно.
Однако KWTS не заменяет WAF и средства защиты самого приложения. Антивирусная проверка обнаруживает вредоносное содержимое, но не всегда способна определить SQL-инъекцию, обход авторизации, подмену параметров или логическую ошибку в бизнес-процессе. Поэтому обратный прокси нужно рассматривать как дополнительный уровень обороны.
Что показало тестирование
При корректной связке Squid и KWTS входящие файлы проходят проверку до передачи внутреннему серверу. Вредоносные тестовые объекты блокируются, а событие фиксируется в журналах. При прямом подключении к приложению, минуя прокси, такой контроль отсутствует.
Из этого следует важный практический вывод: внутренние сервисы нельзя оставлять доступными из внешней сети. Даже хорошо настроенный reverse proxy не защищает приложение, если атакующий может обратиться к его реальному IP-адресу напрямую.
На сетевом уровне следует разрешить доступ к приложениям только от адресов Squid. Дополнительно применяются локальный firewall, сегментация VLAN, отдельные подсети для серверов и запрет маршрутизации из пользовательских сетей к backend-узлам.
Эксплуатационные особенности
В многопользовательской среде понадобится интеграция с Active Directory. Она позволит централизовать учетные записи, назначать роли и отзывать доступ при увольнении или изменении обязанностей сотрудника.
Обновления KWTS, антивирусных баз, Squid и операционной системы должны выполняться регулярно. Для ОС важно отключить ненужные службы, ограничить административный доступ, использовать SSH-ключи, включить журналирование и контролировать изменения конфигурации.
Отдельно стоит настроить мониторинг:
- количество заблокированных объектов;
- ошибки ICAP;
- время обработки запросов;
- заполнение диска;
- нагрузку на CPU и память;
- число активных соединений Squid;
- недоступность внутренних приложений;
- попытки обхода прокси.
Большие файлы и длительные загрузки могут заметно увеличивать нагрузку. Поэтому нужно заранее проверить лимиты размера, тайм-ауты и параметры буферизации. При высокой нагрузке может потребоваться несколько узлов, балансировка и резервирование.
Отказоустойчивость и аудит
Один экземпляр Squid или KWTS становится единой точкой отказа. Для критичных сервисов рекомендуется предусмотреть резервный прокси, виртуальный IP-адрес, балансировщик или иной механизм автоматического переключения.
Журналы должны храниться централизованно и защищаться от удаления. В них важно фиксировать клиента, целевой ресурс, имя файла, результат проверки, причину блокировки и идентификатор события. Это помогает расследовать инциденты и выявлять повторяющиеся атаки.
Перед вводом схемы в эксплуатацию необходимо провести нагрузочные испытания. Проверять следует не только обнаружение угроз, но и корректность работы обычных пользователей: авторизацию, загрузку больших файлов, скачивание, потоковые операции и восстановление после отказа компонентов.
Итоги
Связка Kaspersky Web Traffic Security и Squid позволяет построить обратный прокси, который анализирует входящий HTTP-трафик и блокирует вредоносные файлы до их попадания во внутренние приложения. Решение подходит для сервисов с функцией загрузки данных и может стать дополнительным уровнем защиты уже существующей инфраструктуры.
При этом KWTS не является полноценной заменой WAF, безопасной разработки, сетевой сегментации и контроля доступа. Максимальный эффект достигается только при комплексной настройке: внутренние сервисы закрываются от прямого доступа, исключения Bypass минимизируются, ICAP проверяет все релевантные запросы, а события регулярно анализируются администраторами.
Главная практическая ценность такой архитектуры - возможность централизованно проверять входящие объекты, не встраивая антивирусную логику в каждое приложение отдельно.