Что может означать правило доступа по имени хоста на каждом уровне сети
Имя службы можно применять на уровне DNS, браузера, прокси или межсетевого экрана. Выберите уровень, который видит ту идентичность, которой вы хотите управлять.
Три человека просят одно и то же одними и теми же словами: заблокировать доступ к одному имени службы. Один имеет в виду, что браузер не должен открывать сайт, другой — что настольный голосовой клиент не должен достигать своего сервера, а третий — что группа подрядчиков не должна пользоваться определённым внутренним приложением. Предложение одинаковое, а механизмы исполнения почти ничего общего не имеют.
Выбирайте уровень по идентификатору, который он действительно видит, а затем по клиентам, которые он охватывает. Начинать с команды межсетевого экрана, которую вы уже знаете, — это путь, на котором правила в итоге ничего не блокируют или блокируют слишком много.
Имя — не идентичность, которую может проверить каждый уровень
Netfilter и подобные фильтры пакетов видят адреса, протоколы и порты. Они не видят имён хостов, и к тому моменту, когда пакет до них доходит, имя уже разрешено. Правило, написанное против адреса, — это правило об этом адресе, какое бы имя пользователь ни ввёл, чтобы до него добраться.
Политика DNS стоит раньше на пути и видит запрос, который является другим объектом, чем следующее за ним соединение. Она управляет ответами, которые возвращает контролируемый резолвер, а не уже открытыми соединениями и не клиентами, настроенными в обход этого резолвера. Разрешённый адрес может измениться и между проверкой политики и следующим запросом, поэтому ответ DNS не является долговременным заявлением об авторизации.
Высшие уровни видят больше контекста и охватывают меньше клиентов. Этот обмен и есть вся тема, и он объясняет, почему ни одна строка таблицы никогда не является правильным ответом. Выберите строку, которая видит идентификатор, о котором на самом деле ваша политика. Затем примите охват, который подразумевает эта строка.
Что может идентифицировать каждый уровень
Читайте таблицу от среднего столбца наружу: идентификатор, который уровень может видеть, определяет политику, которую он может честно исполнять.
| Layer | Identifier it sees | What it cannot see |
|---|---|---|
| Packet filter | address, protocol, port | the name, or which other services share that address |
| DNS policy | the queried name and the answer handed back | connections made by clients that ignore the resolver |
| Managed browser | supported URL patterns on managed profiles | non-browser clients, or unmanaged devices |
| CONNECT proxy | host and port for tunnelled requests | the path inside an encrypted request |
Уровень входит в политику только тогда, когда видимый им идентификатор совпадает с идентификатором, которым управляете вы. Таблица также объясняет, почему правило, написанное на одном уровне, редко переносится на другой без нового решения о том, что оно защищает.
Где очевидное правило терпит неудачу
Правило адреса точно правильно для службы с выделенным адресом, который вы контролируете, и эту собственность следует записать в политику. Оно точно неправильно для всего, что стоит за общим адресом доставки контента, где то же правило затрагивает несвязанные службы, а обновлённый ответ DNS не превращает правило в авторизацию по имени хоста.
Политика управляемого браузера выражает веб-ограничение более прямо, чем скопированный список адресов, но применяется к браузерам и профилям, которыми управляет система управления.
Это правило браузера ничего не делает с голосовым клиентом, отправляющим UDP на другой хост, а его шаблоны определяются этим продуктом, а не заимствованными откуда-то соглашениями о подстановочных знаках. Прокси CONNECT также получает хост и порт для туннелированного запроса и не может прочитать путь внутри зашифрованного сеанса. Проектируйте правило вокруг того, что раскрывает протокол. Затем запишите, что оно оставляет непокрытым, потому что именно этот пробел станет источником следующего запроса.
Выбирайте по клиентам, а не по команде
Спросите, каких клиентов политика должна охватывать и каких может пропустить. Политика управляемого браузера охватывает то, до чего доходит система управления, и останавливается на границе браузера. Политика резолвера охватывает всё, что использует ваш резолвер, а это более широкое множество, и она открыто отказывает всем, кто этого не делает.
Для службы, которой вы управляете, авторизация в приложении сильнее любой сетевой границы, потому что она следует за учётной записью, а не за путём. Маршрут VPN — это достижимость и ничего больше: возможность отправить пакет службе не является разрешением ею пользоваться. Там, где важный идентификатор — пользователь или разрешение канала, применяйте его там, а сетевое правило рассматривайте как второй уровень.
Напишите правило в терминах ресурса
Защитимая политика называет ресурс, идентичности, приложения в области охвата и путь, который их несёт, включая оба используемых семейства адресов. Она также указывает, что произойдёт с общей инфраструктурой, которую правило затронет попутно.
Эта формулировка создаёт решение, которое кто-то сможет проверить позже. Правило, обоснованное сегодняшним разрешённым адресом, создаёт инцидент при первом изменении адреса, и никто не сможет объяснить, почему блокировка когда-либо была правильной.