Настройка межсетевого экрана начинается не с выбора модели устройства, а с набора правил. Один и тот же экран можно настроить строго или превратить в решето: разница будет только в политике. При этом типовая ситуация в компаниях выглядит так: правила заводились годами разными людьми, половина из них временные, комментариев нет, и никто не берется их трогать.
Разберем принципы, по которым строят политику. Они применимы к любому решению — встроенному экрану операционной системы, программному шлюзу или аппаратному комплексу, потому что касаются логики, а не синтаксиса конкретного продукта.
Запрет по умолчанию: с чего начинается любая политика
Есть два способа построить набор правил. Первый: разрешить все, кроме того, что явно запрещено. Второй: запретить все, кроме того, что явно разрешено.
Второй подход называется запретом по умолчанию, или default deny, и именно с него начинают строить правила фильтрации. Причина проста: список угроз невозможно перечислить заранее. Как только в сети появляется новый сервис, новый порт или новое устройство, при первом подходе они автоматически оказываются доступны. При втором — остаются закрытыми, пока кто-то осознанно не откроет доступ.
На практике это означает завершающее правило в цепочке, которое блокирует все, что не совпало ни с одним разрешающим. Дальше политика строится только через явные разрешения.
Побочный эффект такого подхода — при внедрении что-то обязательно перестанет работать, потому что о части соединений никто не знал. Это не недостаток, а обнаружение реального состояния сети. Именно поэтому переход на запрет по умолчанию делают с включенным журналированием и в спланированное окно.
Минимальные привилегии: открывать точечно, а не диапазонами
Второй принцип: каждое разрешение должно быть настолько узким, насколько позволяет задача.
Разрешение описывается четырьмя параметрами: откуда, куда, по какому протоколу, на какой порт. Хорошее правило заполняет все четыре конкретными значениями. Плохое оставляет часть открытой: «с любого адреса», «на любой порт», «весь диапазон».
Типичная история: сервису нужен доступ к базе данных, и на время отладки открывают весь диапазон портов с любого адреса внутренней сети. Отладка заканчивается, правило остается. Через год никто уже не помнит, зачем оно, и трогать боятся.
Правильный вариант — открыть конкретный порт для конкретного источника. Если источников несколько, их объединяют в группу, и правило ссылается на группу: так проще поддерживать и понятнее при чтении.
Отдельный случай — правила «наружу». Здесь тоже стоит ограничивать: если сервер должен обращаться только к нескольким внешним адресам, разрешить нужно именно их, а не весь интернет.
Порядок правил и почему он ломает логику
В большинстве решений правила обрабатываются сверху вниз до первого совпадения: как только пакет попал под правило, дальнейший просмотр прекращается. Так работают экраны на базе Linux, списки доступа на сетевом оборудовании и большинство аппаратных комплексов. Из массовых исключений стоит знать два: во встроенном экране Windows порядок правил не редактируется и запрет всегда сильнее разрешения, а в пакетном фильтре систем BSD выигрывает последнее совпавшее правило.
Отсюда классическая ошибка: широкое разрешающее правило стоит выше узкого запрещающего. Администратор добавляет запрет для конкретного адреса, проверяет — запрет не работает. Причина в том, что трафик совпал с более общим разрешением раньше и до запрета не дошел.
Практическое следствие: при добавлении правила важно не только что вы разрешаете, но и куда вставляете. Общая логика построения набора выглядит так: сначала специфические правила для отдельных адресов и сервисов, затем более общие, в конце — блокирующее правило по умолчанию.
Помогает и структура: группировать правила по назначению, отделять блоки для внешнего доступа, для межсегментных взаимодействий, для служебных сервисов. Набор, разбитый на смысловые блоки, читается и ревизуется, а сплошной список из двухсот строк — нет.
Три направления трафика: входящий, исходящий, транзитный
Политики для разных направлений строят отдельно, и о некоторых часто забывают.
Направление | Что это | На что обратить внимание |
|---|---|---|
Входящий | Обращения к защищаемым узлам | Открывать только опубликованные сервисы |
Исходящий | Обращения узлов наружу | Ограничивать, а не разрешать все подряд |
Транзитный | Трафик между сегментами | Изоляция по умолчанию, связи по разрешению |
Про входящий трафик помнят все: именно с него начинают настройку. Про транзитный вспоминают, когда появляется сегментация.
А вот исходящий трафик обычно разрешают целиком, и это упущенная возможность. Ограничение исходящих соединений серверов существенно сужает то, что можно сделать после компрометации узла: скачать дополнительные инструменты, установить связь с внешним управляющим сервером, выгрузить данные. Сервер, которому по работе нужны обновления и обращение к двум внешним сервисам, не должен иметь свободного выхода в интернет.
Инспекция состояния, или stateful-фильтрация, отслеживает сессии целиком, поэтому обратный трафик не приходится открывать вручную для каждого разрешенного соединения. Реализация различается: в решениях на базе Linux для этого заводят одно явное правило для установленных и связанных соединений, а в большинстве аппаратных комплексов и решений класса NGFW обратный трафик разрешается автоматически по таблице сессий и в политике не описывается.
Доступ к управлению: отдельная сеть и никакого интернета
Одно из самых результативных правил при минимуме усилий.
Административные интерфейсы — веб-панель самого экрана, консоли коммутаторов, порты удаленного управления серверами, интерфейсы систем хранения — должны быть доступны только из выделенной сети управления. Не из офисной сети, не из гостевой, и точно не из интернета.
Причина очевидна: получив доступ к управлению экраном, атакующий получает возможность изменить любые правила. Все остальные меры после этого не имеют значения.
Чтобы это реализовать, административные интерфейсы выносят в отдельный сегмент управления с ограниченным входом. Такой сегмент — это отдельный VLAN, и строится он на управляемых коммутаторах: на неуправляемом оборудовании отделить сеть управления невозможно.
Дополнительно: административный доступ имеет смысл ограничивать не только по сети, но и по учетным записям, с отдельными паролями и двухфакторной аутентификацией там, где она поддерживается.
Порядок внесения изменений и ревизия правил
Политика — живой документ, который стареет вместе с инфраструктурой. Без регламента она деградирует за год-два.
Комментарий к каждому правилу. Кто завел, когда, зачем, до какого срока, если правило временное. Без этого через год набор невозможно ревизовать: никто не помнит, что можно удалить.
Проверка на тестовом контуре. Изменения, которые затрагивают работающие сервисы, сначала проверяют на стенде. Если стенда нет, как минимум продумывают, что именно должно перестать работать при ошибке.
Откат изменений. Перед правкой сохраняют текущую конфигурацию и готовят план возврата. Когда меняется доступ к управлению, заранее определяют резервный способ входа на устройство, чтобы ошибка не заблокировала администратора.
Не в пик нагрузки. Изменения вносят в окно, когда цена ошибки минимальна.
Периодическая ревизия. Раз в квартал или полугодие набор просматривают целиком: удаляют временные разрешения с истекшим сроком, убирают правила под сервисы, выведенные из эксплуатации, объединяют дублирующиеся. При замене парка требования к импортозамещению сетевого оборудования учитывают до переноса правил, чтобы новая платформа поддерживала нужные сценарии фильтрации и журналирования.
Шесть ошибок, которые встречаются чаще всего
- Правило «разрешить все» на время отладки. Заводится на час, живет годами. Самая частая причина открытого доступа, о котором никто не знает.
- Доступ к управлению из внешней сети. Последствие: административный интерфейс становится прямой точкой атаки.
- Отсутствие журналирования отклонений. Без записи блокировок диагностика превращается в перебор, а расследование инцидента становится невозможным.
- Правила без комментариев. Последствие: безопасно удалить устаревшее разрешение уже невозможно.
- Разрешения по широким диапазонам. Последствие: лишние сервисы становятся доступны без деловой необходимости.
- Отсутствие ревизии. Последствие: выведенные из эксплуатации сервисы оставляют ненужные пути доступа.
С чего начать наведение порядка
Если набор правил уже запущен, разумный порядок такой. Сначала включить журналирование отклонений и понаблюдать, что реально ходит по сети — часто это дает неожиданную картину. Затем описать существующие правила: что за что отвечает, что можно удалить сразу. После этого закрыть административный доступ из общих сегментов, если он открыт. И только затем переходить к переработке набора под запрет по умолчанию.
Такой порядок дает быстрый результат на первых двух шагах и снижает риск остановки сервисов. Сегментацию и сетевое оборудование планируют вместе с политикой фильтрации, иначе правила придется переделывать после изменения топологии.