Comments 9
я бы netflow направил в какую-нибуль лог-менеджмент систему с развитыми инстурментами аналитики и уже там делал бы итоговый анализ. Заодно по реультатам внедрения фаервола в организации и миониторинг появится ;)
Да, расскажите чем поможет ваш дамп трафика в работающей штатно системе в которой 3 плеча резервных LAN каналов и 5 WAN. Всё это счастье с OSPF и VRRP. Будете ломать каждый канал и собирать дампы для каждой ситуации?
Зачастую, фаервол уже есть и миграция идёт на другого вендора. Но в любом случае подход работаем как роутер не правильный.
Если маленькая компания, то такие методы с дампами не нужны, поскольку админ знает куда и что должно ходить.
Если средне-большая, где требуется интегратор, то дамп трафика уже не понадобится, поскольку невозможно во всём трафике разобраться. И зачастую новая система устанавливается сбоку, куда зеркалируется трафик и на этом основании делаются правила (точнее они делается из требований безопасности и бизнеса, а применяются они для материализации данных запросов)
Сугубо побаловаться, да, интересное решение. Но в заголовок "Внедрение межсетевого экрана без боли" не вписывается. По своему опыту, скажу, Внедрение межсетевого экрана - всегда боль.
Солар вроде как позиционируется как компания, в том числе, решающая вопрос ИБ. Очень странно видеть такой подход "опишем как разрешено, все что сейчас ходит", а дальше разберёмся. Во первых не будет никакого дальше, во вторых межсетевой экран предназначен для разграничения ИС с разным уровнем защищённости и все взаимодействия между такими ИС определяется, в первую очередь, матрицей доступа. Не спорю, предложенный способ очень хорошо закрывает задачу "внедрить межсетевой экран и закрыть акты", но совсем не решает задачу по защите ресурсов заказчика.
Так там же в заключении написано:
Полученные данные нельзя сразу использовать для написания политик: они
требуют анализа человеком. Но мы получаем информацию, с которой можно
дальше работать, чтобы создавать правила. Прежде всего, нужно проверить
данные на предмет легитимности: действительно ли все эти соединения
должны присутствовать.
Иначе можно было напрямую pcap-ы конвертировать в политики и ни каких проблем :)
Единственный верный ответ на вопрос "должны ли эти соединения присутствовать" содержится в матрице доступа. Особенно в случае наличия сервисов потребность в которых нерегулярна.
Ну получили вы какие то там потоки данных и что? Ответ на вопрос "должны ли такие соединения иметь возможность установиться или нет" эти данные не содержат. Я понимаю - нормальное обследование делать и лень и денег не приносит, только проблемы ибо заказчик, как правило, не очень то жаждет глобальных исследований и не готов платить за это соответвующие деньги. Но и Ваш подход не имеет никакого отношения к ИБ. Так по быстрому влепить фв и гордо заявить "теперь все защищено" :-(:-(:-(
Внедрение межсетевого экрана без боли: анализируем реальный трафик на этапе подготовки