Спор о том, нужен ли разбор приложений или хватает фильтрации по портам, идёт с тех пор, как появился сам разбор приложений. Аргумент противников звучит разумно: межсетевые экраны четвёртого уровня стоят в множестве организаций, работают и управляют трафиком.
Спорить я не буду. Приведу выгрузку.
Что нашлось на 443-м порту в одной корпоративной сети
Обычная компания, обычный рабочий день. Я снял выгрузку с устройства, умеющего разбор приложений, и получил 173 разных приложения на одном порту — том самом, для которого в политике написано одно правило. Полный список я публиковал тогда же, в статье от 27 апреля 2020 года.
Что там было, по категориям:
- Рабочее. Обновления операционной системы и офисного пакета, облачные документы, корпоративная почта, системы управления задачами, репозитории исходного кода, мониторинг и диагностика приложений, системы обслуживания клиентов, облачные платформы.
- Общение. Корпоративные конференции и телефония, мессенджеры — корпоративные и личные, вперемешку.
- Личное. Социальные сети, обмен фотографиями, публичные сервисы вставки текста, развлечения.
- То, что администратор не разрешал. Трафик, туннелированный внутри разрешённого протокола, и приложения, которые сознательно ходят по 443-му именно потому, что этот порт открыт всегда.
Это снимок одной сети в 2020 году, а не статистика типичной организации. Нынешний состав трафика нужно измерять заново — и в своей сети, а не по этой статье.
Схема: что лежит под одним правилом
Вопрос, на который нет ответа
Напишите правило, которое разрешает рабочие документы и обновления, но запрещает публичные сервисы вставки текста и туннелирование. Имея один критерий — номер порта TCP.
Такого правила не существует. Правило по одному номеру порта не различает приложения: оно либо пропускает всё, что идёт по 443-му, либо не пропускает ничего.
Это не значит, что политики нет вовсе. Фильтрация на третьем и четвёртом уровнях остаётся содержательной: она учитывает адреса источника и назначения, направление, протокол и состояние соединения — так этот класс средств и описан в NIST SP 800-41 Rev. 1. Нет другого: политики использования приложений. Её по номеру порта не выразить.
Что это меняет на практике
Правило по приложению — это не «то же самое, но удобнее». Это другой объект правила: вместо номера порта — то, что за ним работает. Без него разговор о том, что разрешено, ведётся в терминах, которых нет в политике.
Список приложений в сети надо сначала увидеть. До того как писать политику, снимите выгрузку с любого устройства, умеющего разбор приложений, в режиме наблюдения. Разговор о том, что разрешать, становится предметным ровно в этот момент: руководство видит не абстрактный «интернет-трафик», а названия и объёмы.
Значительная часть списка будет неожиданной. Это нормально. Смысл упражнения не в том, чтобы кого-то поймать, а в том, чтобы понять, из чего состоит трафик, за защиту которого вы отвечаете.
Разбор приложений без расшифрования видит не всё. Часть приложений опознаётся по параметрам рукопожатия и имени узла, часть — только после расшифрования, а часть не опознаётся вовсе: почему так, разобрано отдельно в статье о том, что расшифрование TLS перестало быть всевидящим оком.
Что спросить у поставщика
Не «есть ли у вас разбор приложений» — эта строка есть в любой спецификации, и она ничего не обещает про ваш трафик. Спрашивайте иначе.
Сколько приложений опознаёт продукт на вашем трафике — не в каталоге, а в тестовой выгрузке с вашей сети; это разные числа. Что происходит с неопознанным трафиком: он разрешается, запрещается или помечается. Как устроен порядок принятия решения, когда в правиле указаны и приложение, и порт: наличие обоих условий само по себе нормально — вопрос в том, можно ли по журналу объяснить, какое правило и почему сработало. И как быстро в каталог добавляются новые приложения.
Полный набор критериев с вопросами поставщику — на странице как выбрать NGFW. Чем архитектура NGFW отличается от UTM и почему число политик важнее списка функций — в отдельной статье.