☰

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

tag-icon • tag-icon domain-name-system https redirection rpz dns-firewall
Ошибки сертификата при «перенаправлении» в DNS RPZ https/ssl

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

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

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

решение1

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

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

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

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

Здесь у вас есть четыре варианта:

  1. Следуйте совету sebix в комментариях: отправьте сертификат CA на каждую рабочую станцию, которая будет подпадать под защиту RPZ. Если это предприятие, это вполне осуществимо, и в лучшем случае такой сертификат CA может уже существовать.
  2. Действуйте так, как есть сейчас, чтобы люди могли увидеть описание того, почему они не попадают на нужный сайт.
  3. Измените свой рерайт, чтобы они вообще не получили веб-страницу. Вместо того, чтобы отправлять их на веб-страницу, «съешьте» запрос с помощью rpz-drop., CNAME .(NXDOMAIN) или CNAME *.(NODATA).
  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

Связанный контент