Pull to refresh

Comments 16

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


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

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

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


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

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

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

Никак не относится — он же Netflow генерит :-) При правильном планировании сети нужда в таких устройствах вообще отпадет и flow можно будет брать с самого сетевого устройства
Интересно, как можно дать «более статистически точное представление трафика (особенно, трафика, который роутер не знает» на сэмплированном трафике? Не могли бы вы пояснить?
Это классно, но относится преимущественно к траблшутингу, где отказ от анализа пакетов не сильно влияет на результат. В безопасности потеря пакетов критична

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


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


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

Вот именно собирать весь Netflow, да и sflow тоже, и отдавать его в SIEM — это смысла не имеет. А вот обрабатывает его на NTA, а алерты уже отдавать в SIEM, — вполне себе решение
Ну и чтобы окончательно закрыть тему с 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 вам в помощь.
На большинстве реального сетевого железа терабитного класса на sFlow выставить рейт сэмплирования 1:1 на практике нельзя — нет аппаратной поддержки, не вытянет CPU. Если же городить аппартаную поддержку, проще сразу делать IPFIX. Так что в теории можно и на sFlow, а на практике всё равно IPFIX.

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

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

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