Интеграция решений по мониторингу Netflow и SIEM

[amarao]

Я очень хочу посмотреть на серьёзную сеть (допустим, терабит на аплинках), в которой netflow "полный", а не сэмплированный. Это во-первых. Во-вторых, sflow можно выставить рейт сэмплирования в 1, будет не сэмплированный.

Так что зря вы sflow обижаете.

[alukatsky]

Есть такие сети :-) Я sflow не обижаю. Просто он разрабатывался в другой парадигме и для других задач. По сути, это облегченный Netflow. Но для целей ИБ можно и его задействовать

[amarao]

Я к тому, что netflow не предоставляет никаких преимуществ. netflow — это ad-hoc протокол от циски, в которой только с 9ой (!) версии додумались до существования ipv6. sflow же с самого начала дизайнился как vendor neutral, и без всякого умничания со стороны роутера. sflow даёт более статистически точное представление трафика (особенно, трафика, который роутер не знает). sflow можно собирать с любых устройств — как роутеров, так и коммутаторов (что условиях SDN является просто essential).

Вообще, архаичные нестандарты — это любимый конёк циско. Нельзя стать сетевым инженером, работающим с циско, без погружения в бесконечное легаси, которое никому не сдалось, но которое есть, потому что так надо было сделать в 1985 году для поддержки ipx через модем на 900 бод.

[alukatsky]

Ну согласитесь, что если заменить слово Netflow на sflow, то статья вообще не поменяется :-)

[amarao]

Поменяется, потому что тогда придётся меньше говорить слово "циско" и много больше других вендоров. Например, ваш "Netflow Generation Appliance" к sflow относится как?

[alukatsky]

Никак не относится — он же Netflow генерит :-) При правильном планировании сети нужда в таких устройствах вообще отпадет и flow можно будет брать с самого сетевого устройства

[RuIvanov]

Интересно, как можно дать «более статистически точное представление трафика (особенно, трафика, который роутер не знает» на сэмплированном трафике? Не могли бы вы пояснить?

[amarao]

У sflow в спецификации описано как делать сэмплирование, чтобы не возникало перекосов от одиноких сессий.

https://sflow.org/about/sampling_theory.php

[alukatsky]

Это классно, но относится преимущественно к траблшутингу, где отказ от анализа пакетов не сильно влияет на результат. В безопасности потеря пакетов критична

[amarao]

В своё время в шутку мы предлагали писать весь дамп трафика в elastic. Это была шутка, потому что терабиты/с в эластик (которые превратятся в десятки терабит из-за формата) — это реально шутка.

Безопасность не должна быть более безопасной, чем польза от продукта. В этом смысле кирпич — идеальный пример безопасного веб-сервера. Ноль CVE, никаких RCE, никаких уязвимостей. Никогда не будет использован как jump-host в сети. Никогда не приведёт к компрометации данных или утечке информации. Лежит себе и лежит.

Собирать "весь netflow" могут позволить себе только конторы с микроскопическим трафиком, либо с бюджетами на безопасность, которые кратно больше, чем на остальную инфраструктуру. Стоит оно того или нет...

[alukatsky]

Вот именно собирать весь Netflow, да и sflow тоже, и отдавать его в SIEM — это смысла не имеет. А вот обрабатывает его на NTA, а алерты уже отдавать в SIEM, — вполне себе решение

[RuIvanov]

Ну и чтобы окончательно закрыть тему с sFlow — он ровно такой же «нестандарт» как и Netflow, NetStream и т.д. (хотя на многие из них есть информационные RFC от IETF, для sFlow — www.ietf.org/rfc/rfc3176.txt). Единственное, что получило статус открытого стандарта — это IPFIX, сделанный как раз на базе Netflow 9. Можете сами проверить — tools.ietf.org/html/rfc5101 tools.ietf.org/html/rfc7015 и tools.ietf.org/html/rfc7011 вам в помощь.

[RuIvanov]

На большинстве реального сетевого железа терабитного класса на sFlow выставить рейт сэмплирования 1:1 на практике нельзя — нет аппаратной поддержки, не вытянет CPU. Если же городить аппартаную поддержку, проще сразу делать IPFIX. Так что в теории можно и на sFlow, а на практике всё равно IPFIX.

[amarao]

Разумеется. Но я к тому, что sflow куда более разумный формат, чем netflow. Кому-то важны терабиты, а кто-то хочет иметь 1:1 тонкой струйкой. С учётом, что sflow на инспекцию отправляет что попало (а не то, что в нестандарте придумано), то он автоматически поддерживает любую ахинею, хоть QinQinQinQ, хоть ATAoE.

[apkotelnikov]

Всем хорош xFlow анализ, да вот видит он только атаки на условно «сетевом» уровне и на высконагруженном сервисе (к примеру если некое устройство, делающее SSL offload, с числом одновременно установленных сессий в сотни тысяч и количеством новых в единицы тысяч) одновременных обрыв всех сессий с их переустановкой будет выглядеть атакой. Хотя это всего лишь легитимные пользователи перестроили свои соединения. Что касается атак уровня приложения, так их вообще не будет видно.

[alukatsky]

Ну давайте не навешивать на Netflow то, что ему не свойственно :-) На уровне приложений можно ловить различные атаки — я бы не сказал, что это невозможно. Но в целом, это не задача Netflow, и сильно будет зависеть уже от NTA. Но пример с прикладными атаками как раз хорошо показывает, зачем нужен SIEM и почему одного Netflow недостаточно.

Что касается примера с обрывом, то все зависит от того, что мы мониторим. Мы же можем отслеживать рост нагрузки на сервис и по динамике этого роста делать вывод. Если профиль будет выглядеть как «пила» (постепенный рост и падение), это одно и похоже на описанный вариант с переустановкой сессий. Если профиль выглядит как «шляпа» (внезапный рост и падение), то это может рассматриваться как DDoS. Так что все зависит от настройки анализатора Netflow