Сегодня стало очевидно, что контроль наложения правил в сети стал необходим для отслеживания, насколько эффективно эти правила соблюдаются. Опыт показывает, что, к сожалению, в реальности теория регулировки сети политиками и правилами часто далека от реальности. Причинами этого являются, в частности, неправильная конфигурация, плохая архитектура, аварии оборудования, пренебрежения политиками и уязвимости используемого оборудования. Количество переменных факторов в современных сетях не позволяет гарантировать эффективность работы системы наложения правил. Мониторинг реального состояния позволяет восстановить ситуацию.

Когда вам надо восстановить факты, очень важно иметь надежный источник информации. Механизм наложения правил в условиях аварии является плохим свидетелем по двум причинам. Во-первых, если он скомпрометирован, то надежность его логов очень сомнительна. Во-вторых, это механизм был обойден (например, маршрутизацией), то он вообще не имеет обзора нужных коммуникаций. NetFlow является отличным источником данных по трем причинам. Во-первых, это то, что называется "нечаянный свидетель", не зависящий от механизма наложения правил. Во-вторых, сейчас NetFlow уже  повсеместно внедрен, позволяя осуществлять мониторинг везде, вне зависимости о того, где маршрутизируются коммуникации. В-третьих, эти данные создаются на каждом интерфейсе, через который проходит коммуникация, что позволяет получить подтверждение из многих источников данных.

Используя данные NetFlow из существующей инфраструктуры, можно верифицировать несколько сценариев наложения правил.

Группируя IP-адреса клиентов в хост-группу, а внешние IP-адреса из черных списков в дополнительные группы хостов, можно генерировать сигнал, когда, скажем, будет попытка коммуникации (двунаправленной) или состоявшееся соединение (двунаправленное) с хостами из блок-листа. Такие правила мониторинга могут создаваться для дублирования аналогичных правил в архитектуре наложения правил.

 

Кроме того, поскольку NetFlow может использоваться для исторического анализа,  то могут генерироваться гистограммы запрещенного трафика.

При разрешении проблем с этим случаем коммуникаций, на которые не подействовали существующие правила, можно проанализировать детальные записи каждого потока, чтобы понять, как такое могло произойти.

Кроме мониторинга того, как осуществляется блокировка по IP, NetFlow может использоваться для мониторинга запрещенных сервисов, путем проверки номеров портов, которые используются. В примере ниже незащищенный протокол Telnet блокируется на файерволе и контролируется системой Lancope StealthWatch. 

 

Мониторинг внутреннего контроля

Для защиты во внутренней сети используется специальный контроль, для того чтобы убедиться, что неавторизованные пользователи не могут получить доступ к данным. В примере ниже показано простое правило, включающее сигнал, когда не срабатывает политика, не позволяющая пользователям получать доступ к защищенным данным банковских карт (соответствие требованиям PCI).

 

Если использовать функциональность глубокой инспекции пакетов (DPI, deep packet inspection) в StealthWatch FlowSensor, в потоковые логи может быть добавлена информация о приложениях. Это позволяет осуществлять непрерывный или исторический мониторинг прокси или файервола приложений для определения их эффективности в деле противодействия неавторизованным коммуникациям. Ниже приведена политика, сигнализирующая при успешной коммуникации типа P2P наружу сети.

 

Вот гистограмма, показывающая тренд трафика, который не был блокирован.

 

Всеобъемлющий мониторинг с помощью NetFlow может также использоваться для проверки того, что входящие коммуникации не обошли файервол или другие механизмы с помощью вредоносного ПО или каким-либо еще способом. Ниже показано простое правило, "высматривающее" SQL-соединения, которые не блокировал файервол.

Тщательная обработка записей NetFlow, полученных из существующей сетевой инфраструктуры, обеспечивает надежное и точное средство для определения, насколько правильно существующий механизм определения политик обрабатывает трафик. При этом можно включить предупреждения в реальном времени, либо использовать исторический анализ для определения проблем.