Ошибки сертификата при "перенаправлении" в DNS RPZ https/ssl

Я настроил DNS RPZ, где я "перенаправляю" пользователей в огороженный сад, используя записи DNS RPZ, когда пользователи пытаются получить доступ к списку плохих сайтов.

Допустим, пользователь пытается получить доступ к badsite.com. Перенаправление в мой огороженный сад для http-соединений работает, но для https-соединений оно вызывает ошибки сертификата, поскольку URL-адрес в браузере остается прежним (badsite.com), но разрешенный IP-адрес соединяется с моим окруженным садом (walledgarden.example.com).

Есть ли способ устранить ошибки сертификата при использовании DNS RPZ для перенаправления на соединениях https?

Источник

1 ответ

Решение

На мгновение я хочу, чтобы вы притворились, что вы автор вредоносных программ, которые успешно взломали DNS-серверы вашей компании. Вы пытаетесь использовать DNS для предоставления поддельных IP-адресов всякий раз, когда кто-то пытается посетить банк. К сожалению, эти запутанные предупреждения браузера не могут исчезнуть при вызове HTTPS.

Это в основном то, что вы просите нас помочь вам. Ваши намерения безобидны по сравнению с этим предполагаемым автором вредоносного ПО, но это не меняет того факта, что технология работает здесь, как задумано. Вы не можете создать безопасность вокруг намерения.

Поскольку действие политики происходит на уровне DNS, невозможно узнать, использует ли пользователь HTTP или HTTPS во время отправки запроса. Единственное, что вы можете контролировать, это то, собираетесь ли вы возвращать IP-адрес и каков этот IP-адрес.

Как только вы достигли этой точки, это базовый сценарий захвата HTTPS. Все те же правила применяются. Если вы можете управлять доверенными центрами сертификации, вы можете управлять браузерами. Кроме этого, нет кости.

У вас есть четыре варианта здесь:

  1. Следуйте предложению sebix в комментариях: добавьте сертификат CA на каждую рабочую станцию, на которую будет распространяться эта защита RPZ. Если это предприятие, это вполне выполнимо, и в лучшем случае такой сертификат CA может уже существовать.
  2. Разберитесь с тем, что есть сейчас, что дает людям возможность увидеть описание того, почему они не попадают на данный сайт.
  3. Измените свое переписывание, чтобы они вообще не могли получить веб-страницу. Вместо того, чтобы отправлять их на веб-страницу, "есть" запрос с rpz-drop., CNAME . (NXDOMAIN) или CNAME *. (НЕТ ДАННЫХ).
  4. Выберите IP-адрес, который всегда будет отклонять соединение с портом 443, и дайте ему A запись, которая предполагает, что происходит на уровне политики. Переписать CNAME указать на эту запись. Это, по крайней мере, даст техническому специалисту какие-то крошки, которые они найдут, когда начнут устранять неполадки. Очевидно, что эти технические люди будут в меньшинстве, но это лучше, чем ничего.

Пример № 4 будет примерно таким:

# RPZ zone file
$ORIGIN example.rpz.
badsite IN CNAME filtered-malware-site.example.com.

# normal zone file
$ORIGIN example.com.
filtered-malware-site IN A 203.0.113.1
Источник
Другие вопросы по тегам