Какие внешние уязвимости остаются у веб-сервера, защищенного mTLS?

Сценарий:

Веб-сервер с веб-приложением для удаленного персонала. Веб-сервер находится за обратным прокси (traefik). Веб-сервер имеет настроенный на основе хоста брандмауэр, который позволяет соединения только от прокси на определенном порту. Эти соединения используют TLS. Единственные другие открытые порты – это ssh, zabbix agent и ntp из 10.0.0.0/8 (ssh и zabbix с конкретных IP-адресов).

Прокси-сервер слушает на 80 и 443 портах и перенаправляет 80 на 443 (и устанавливает заголовки HSTS). Прокси-сервер требует mTLS для домена, на котором размещено веб-приложение, но также проксирует другие веб-серверы, которые используют только обычный TLS. Прокси-сервер имеет настроенный на основе хоста брандмауэр, который позволяет входящие соединения на 80/443 из любой точки и ssh и zabbix agent с частных IP-адресов. Прокси-сервер в настоящее время работает с минимальной установкой Oracle Linux 8 с SELinux в режиме принудительного контроля.

Прокси находится за сетевым брандмауэром, который выполняет NAT публичного IP-адреса на частный и позволяет трафик только на 80/443.

Сертификаты клиентов генерируются с использованием частного CA (внутренняя сеть, не подключенная к Интернету), и затем сертификаты устанавливаются в хранилище сертификатов пользователей, чтобы они могли получить доступ к URL веб-приложения из своих браузеров.

Вопрос:

Предполагая для ограничения объема этого вопроса, что a) сертификаты остаются неповрежденными и b) нет инсайдерских угроз, какие уязвимости остались для веб-сервера? Другими словами, какие векторные атаки имеются у злоумышленника, который находится вне сети и не имеет доступа к действительному сертификату?

Все угрозы остаются, кроме небольшого количества, которые вы либо действительно смягчили (например, атаки типа “человек посередине”), либо исключили по предположению.

Например, вы не упомянули никаких мер против подделки межсайтовых запросов (CSRF). Если CSRF возможна, то вся разница между “инсайдером” и “внешним” исчезает, и злоумышленник может попробовать весь каталог классических атак: SQL-инъекции, межсайтовый скриптинг, эксплуатацию нарушенного контроля доступа и т. д. Кликджекинг может быть еще одним методом, позволяющим законному пользователю невольно выполнять действия от имени злоумышленника.

В целом опасно полагаться только на безопасность на периметре. Помимо CSRF и кликджекинга, инсайдерские угрозы действительно существуют, и приватные ключи могут быть скомпрометированы (особенно когда пользователи хранят их в виде файлов без должной защиты). Поэтому веб-приложение должно быть способно противостоять всем возможным атакам самостоятельно, независимо от того, сколько прокси, брандмауэров и т. д. вы установили перед ним. Не предполагайте, что ему придется иметь дело только с “безобидными” запросами, отправленными законными пользователями.

Вы на самом деле не остановили атаки через веб… сервер все еще доступен через общедоступный интернет на портах 80 и 443. В любое количество атак на веб-серверы все еще доступны потенциальным хакерам.

Поскольку это не веб-приложение, к которому вы хотите предоставить доступ широкой публике, вы должны поместить все это за частным VPN (например, wireguard и т. д.) и разрешить подключение только авторизованным пользователям.

Вы упомянули, что тот же прокси обслуживает ряд различных доменов, и некоторые из этих доменов не требуют клиентских сертификатов, поэтому в дополнение к атакам, упомянутым в других местах, вы должны убедиться, что вы не уязвимы для фронтирования доменов. Если кто-то устанавливает TLS-соединение для одного из доменов без клиентского сертификата, но после подключения делает запрос с заголовком “Host”, который принадлежит домену, требующему клиентский сертификат, успешен ли этот запрос?