Назад | Перейти на главную страницу

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

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

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

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

На мгновение я хочу, чтобы вы представили себя автором вредоносного ПО, успешно взломавшим 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