Вопрос или проблема
Сценарий:
Веб-сервер с веб-приложением для удаленных сотрудников.
Веб-сервер находится за обратным прокси (Traefik).
На веб-сервере настроен межсетевой экран на основе хоста, чтобы разрешить соединения только от прокси на указанном порту. Эти соединения используют TLS. Единственные другие открытые порты – это SSH, Zabbix агент и NTP с 10.0.0.0/8 (SSH и Zabbix с определенных IP-адресов).
Сервер прокси слушает на портах 80 и 443 и перенаправляет порту 80 на 443 (и устанавливает заголовки HSTS).
Сервер прокси обеспечивает mTLS для домена, на котором размещено веб-приложение, но также предоставляет проксирование для других веб-серверов, которые используют только обычный TLS.
На сервере прокси настроен межсетевой экран на основе хоста, чтобы разрешить входящие соединения на портах 80/443 отовсюду, а также SSH и Zabbix агент с частных IP-адресов.
Сервер прокси в настоящее время работает на минимальной установке Oracle Linux 8 с SELinux в режиме принудительного исполнения.
Прокси находится за сетевым экраном, который NAT’ит публичный IP на частный IP и разрешает трафик только на 80/443.
Сертификаты клиентом генерируются с использованием частного CA (внутри сети, не подключенного к Интернету), и сертификаты затем устанавливаются в хранилище сертификатов пользователей, чтобы они могли получить доступ к URL веб-приложения из своих браузеров.
Вопрос:
Предполагая для целей ограничения сферы данного вопроса, что а) сертификаты остаются неповрежденными и б) не существует внутренней угрозы, какие уязвимости остаются для веб-сервера? Иными словами, какие векторы атаки доступны злоумышленнику, который находится за пределами сети и не имеет доступа к действительному сертификату?
Все угрозы остаются, за исключением небольшого количества, которые вы либо действительно смягчили (например, атаки типа “человек посередине”), либо исключили по предположению.
Например, вы не упомянули о каких-либо противодействиях для межсайтовой подделки запроса (CSRF). Если CSRF возможна, тогда все различие между “внутренним” и “внешним” разрушается, и злоумышленник может попытаться использовать весь каталог классических уязвимостей: SQL-инъекции, межсайтовый скриптинг, нарушения контроля доступа и т.д.
В целом опасно полагаться только на защиту периметра. На самом деле внутренние угрозы существуют, и закрытые ключи действительно компрометируются (особенно когда это программные ключи). Веб-приложение должно выдерживать все возможные атаки само по себе, независимо от того, сколько прокси, межсетевых экранов и т.д. вы разместили перед ним. Не предполагайте, что оно будет иметь дело только с “дружелюбными запросами”, отправленными законными пользователями.
Ответ или решение
Уязвимости веб-сервера, защищенного mTLS
В условиях современных киберугроз, даже веб-серверы, защищенные с помощью двустороннего аутентификации TLS (mTLS), могут иметь свои уязвимости. В данном анализе будут рассмотрены внешние векторы атак, которые могут угрожать веб-серверу, несмотря на наличие надежных механизмов аутентификации и защиты. Для удобства анализа ситуации, вспомним ключевые характеристики описанного окружения.
1. Угрозы на уровне веб-приложения
Несмотря на использование mTLS, веб-приложение остается подверженным ряду классических уязвимостей:
-
SQL-инъекции: Неправильная обработка входящих данных может позволить злоумышленнику выполнить произвольные SQL-команды, что может привести к утечке данных или изменению записей в базе данных.
-
Межсайтовый скриптинг (XSS): Если веб-приложение позволяет загрузку пользовательского контента, то злоумышленник может внедрить вредоносный скрипт, который будет выполняться в браузере других пользователей, что позволит красть сессии или выполнять другие вредоносные действия.
-
Недостатки в контроле доступа: Если система допускает нарушение принципа наименьших привилегий, то злоумышленник может получить доступ к данным или функциям, к которым у него нет прав.
-
Cross-Site Request Forgery (CSRF): Атаки CSRF могут быть использованы для инициации действий от имени пользователя без его ведома, если веб-приложение не защищено соответствующими токенами.
2. Ошибки в конфигурации и обновлениях
-
Неправильная конфигурация модуля прокси: Неверные настройки прокси-сервера Traefik могут привести к тому, что уязвимости других веб-сервисов, находящихся за прокси, могут быть использованы злоумышленником.
-
Отсутствие своевременных обновлений: Если операционная система или программное обеспечение веб-сервера не обновляются вовремя, это создает возможность для использования известных уязвимостей.
3. Инфраструктурные уязвимости
-
Сетевая угроза: Несмотря на наличие NAT и сетевого фаервола, если злоумышленник получит доступ к публичному IP, он может пытаться использовать обширные атаки, такие как DoS (атака отказа в обслуживании) для вывода веб-приложения из строя.
-
Мошеннические запросы: zЕсли злоумышленник может spoof (подделать) законные запросы через прокси, это может привести к тому, что вредоносный трафик будет обработан как легитимный.
4. Уязвимости в инфраструктуре безопасности
-
Клиентские сертификаты: Если использование клиентских сертификатов не защищается должным образом, например, если они хранятся в ненадежном месте, это может привести к рискам, связанным с подменой сертификатов.
-
Атаки на ОС и программное обеспечение: Даже при использовании SELinux в режиме "enforcing", существуют известные уязвимости, которые могут быть использованы для эскалации привилегий на хосте.
Выводы
Веб-серверы, защищенные mTLS, существенно снижают вероятность некоторых атак, таких как атаки "человек посередине". Однако они не могут полностью исключить все риски. Важным шагом в обеспечении безопасности веб-приложений является постоянный аудит, тестирование на уязвимости, регулярные обновления программного обеспечения и проработка всех возможных векторов атак. Понимание внутренних и внешних угроз в контексте общей безопасности системы является ключевым для построения надежной защиты.