Меня интересует установка межсетевого экрана. Это будет включать ваш обычный NAT с перенаправлением портов для входящих соединений.
Однако я хочу, чтобы исходящие соединения использовали белый список имен хостов. Я также хочу, чтобы то же устройство действовало в качестве DNS-сервера, который используют мои ПК, чтобы оно всегда знало последний IP-адрес для любого имени хоста в белом списке, когда ПК пытается к нему подключиться.
Это может быть Cisco IOS, рекомендуемая альтернатива, или реальный сервер Illumos или Linux. Я думаю, что использование сервера даст мне больше гибкости, но я открыт для предложений.
Вот что я хочу: (исходящие соединения от пользователя в моей сети)
ПК пользователя выполняет поиск в DNS для данного сайта (например, serverfault.com).
Сервер межсетевого экрана сравнивает это с белым списком имен хостов, и, если это разрешено, полученные IP-адреса передаются обратно на ПК.
Если поиск DNS был разрешен, то список доступа IP немедленно обновляется с учетом самых последних результатов DNS. (с разумным истечением срока)
(необязательно, но желательно) прослушать TCP-соединение, чтобы проверить имя хоста HTTP- или HTTPS-соединения. Таким образом, мы можем предотвратить доступ к сайту, не внесенному в белый список, который может существовать на общем IP-адресе из белого списка.
Я думаю, что смогу выполнить пункты 1-3 с ipfilter
в сочетании с настраиваемым DNS-сервером для обработки белого списка и запуска добавлений в ipfilter
. Это звучит разумно, или возникнут неизбежные проблемы с ipfilter
не распознает изменения сразу? я точно уверен ipfilter
будет работать с Linux / Illumos NAT.
Есть ли приложение для Linux или Illumos, которое уже выполняет белый список IP-адресов, инициируемый DNS? (мешает мне заново изобретать колесо)
Я не слышал о том, чтобы IOS запускала DNS-сервер. Есть ли решение в Cisco IOS, которое справляется с этим? Есть ли очевидное решение, о котором я должен знать, или это просто необычная установка брандмауэра?
Согласно нашему обсуждению в комментариях, похоже, что вы путаете роль межсетевого экрана с ролью прозрачного прокси.
Брандмауэры не полагаются на разрешение DNS для реализации политик доступа. На это есть несколько причин, по которым Я покрыл раньше. Наиболее важные причины:
Прозрачные прокси обычно перехватывают трафик HTTP + DNS и применяют средства управления доступом на основе запрашиваемых имен хостов. На этом уровне IP-адрес не учитывается. Если запрошенный объект не соответствует разрешенному имени, страница с ошибкой возвращается непосредственно из самого прозрачного прокси без перенаправления запроса на предполагаемый ресурс.
Основное различие - это уровень, на котором работают эти устройства. Поскольку прозрачный прокси должен заботиться только об именах, а не об IP-адресах, которые эти имена разрешают, вы не столкнетесь с теми же логическими проблемами, что и межсетевой экран.