Интересно, как можно дать «более статистически точное представление трафика (особенно, трафика, который роутер не знает» на сэмплированном трафике? Не могли бы вы пояснить?
На большинстве реального сетевого железа терабитного класса на sFlow выставить рейт сэмплирования 1:1 на практике нельзя — нет аппаратной поддержки, не вытянет CPU. Если же городить аппартаную поддержку, проще сразу делать IPFIX. Так что в теории можно и на sFlow, а на практике всё равно IPFIX.
При чём тут «сомнительный»? Оно либо работает, либо нет, разрешение имён либо корректно, либо нет. Если вам эта функция не нужна — просто настройте правильно VPN, DNS и инфраструктуру. То, о чём вы пишете, отношения к AnyConnect'у в любом случае не имеет.
Вообще-то это стандартная функция, и зависит она не от клиента, а от VPN-шлюза. Реализована почти на любом VPN-шлюзе, претендующем на звание энтерпрайзного. Обычно называется DNS doctoring, DNS rewrite и т.д., нужна если вы используете NAT или split-tunneling.
Функционал инспектирования DNS doctoring позволяет устройству безопасности ASA перезаписывать (rewrite) DNS A-записи и PTR-записи.
DNS Rewrite нужен если:
Используется NAT64 или NAT 46, DNS-сервер во внешней сети. Тогда нужно делать конвертацию DNS-ответов между форматами DNS A-записей (для IPv4) и AAAA-записей (IPv6).
DNS-сервер во внешней сети, клиент во внутренней, требуется разрешать fully-qualified domain names для других хостов во внутренней сети (например, корпоративный веб-портал и т.д.).
DNS-сервер во внутренней сети и отвечает на запросы ответами с внутренними адресами, клиенты снаружи, и клиенты запрашивают fully-qualified domain names серверов, которые находятся во внутренней сети.
P.S: Есть важное уточнение — если вы используете домен верхнего уровня, все нижестоящие также идут в исключение, я попросил Диму про это в статье добавить подробнее.
Именно для решения данной проблемы и используется глобальная репутация — мы видим обращения к нетипичным внешним IP/FQDN и смотрим их репутацию (плюс известную нам из TALOS корреляцию c инфраструктурой ботнетов). Обойти все три технологии обнаружения одновременно можно, но крайне трудозатратно и дорого.
Инструмент, который использовали авторы — github.com/cisco/joy
В решении ETA функции сбора телеметрии (локально в сети, с помощью виртуальных или аппаратных коллекторов) делает Stealthwatch, он же запрашивает глобальную систему репутации Cognitive Threat Analytics об репутации и взаимосвязи внешних элементов (внешние IP, к которым шли необычные обращения, SHA256 хэши файловых образцов, если используется Cisco AMP, запрашиваемые во внешний мир подозрительные URL и FQDN). CTA требует явной настройки и по умолчанию выключен.
«Большинство систем мониторинга (безопасности) используют сигнатурный подход для обнаружения угроз. Обычно они мониторят содержимое сетевых пакетов и ищут шаблоны, которые в их базе данных шаблонов представляют заранее идентифицированные, известные угрозы. NBAD-системы в большей степени полезны в обнаружении векторов угроз в двух случаях, когда системы, использующие сигнатурный подход не могут [обнаружить] новые, неизвестные ранее атаки, когда трафик угрозы идёт по зашифрованному каналу, как происходит в случае каналов контроля и управления [вредоносного ПО] для некоторых ботнетов».
«Для того, чтобы NBAD был максимально эффективен, необходимо использовать базовые линии нормального сетевого или пользовательского поведения, которые должны вычисляться на протяжении определённого временного периода».
И где тут сказано, что NBAD использует сигнатуры?
Никаких сигнатур там нет — есть анализ поведения и/или аномалий. Можно, конечно и их назвать сигнатурами второго порядка, но это уже терминологические дебаты. Работает это следующим образом — строятся базовые линии поведения для заданных временных интервалов (например, минута/ 5 минут/ 30 минут/ час / неделя и т.д.), для них ищем аномалии для заданной группы хостов, либо ищем поведение, характерное для вредоносов. Про новое ПО в статье нет ни слова, более того, написано что это работает для известного ВПО.
Существует, и не одна. Более того, сделать свою базу (для своей компании) вполне посильная задача, полно open-source инструментов. Есть и целый класс коммерческих решений Network Behavior Anomaly Detection — en.wikipedia.org/wiki/Network_Behavior_Anomaly_Detection
Телеметрия собирается локально, на сенсоры, установленные в сети. Не хотите делать глобальную корреляцию — никто не заставляет, по умолчанию она выключена.
Это не так просто сделать, как кажется на первый взгляд, плюс это само по себе является хорошим индикатором для систем статического и динамического анализа — легитимное ПО так не делает.
Телеметрия анализируется локально (в Stealthwatch — habrahabr.ru/company/cisco/blog/229073 ), наружу отдаётся только то, на чём можно сделать глобальную корреляцию (и то, если это явно настроить). Отдаётся информация о внешних IP, хэшах ВПО, FQDN-имена запрашиваемых сайтов — для того чтобы понять инфраструктуру вредоноса.
Именно так, только ещё нужно написать свои классификаторы, а чтобы их написать — нужны образцы трафика ВПО и легитимных приложений, плюс понимание что искать.
Использовалась телеметрия из нескольких офисов Cisco, конечно же, насколько мне известно. У нас довольно большая территориально-распределённая сеть разных офисов, так что для моделирования они подходят неплохо.
Функционал инспектирования DNS doctoring позволяет устройству безопасности ASA перезаписывать (rewrite) DNS A-записи и PTR-записи.
DNS Rewrite нужен если:
www.cisco.com/c/en/us/td/docs/security/asa/asa912/configuration/firewall/asa-912-firewall-config/nat-reference.html#ID-2091-0000048c
Именно для облачных сервисов есть неплохая статья на community — community.cisco.com/t5/vpn/split-tunnel-webex-outlook365-zoom-skype/m-p/4049533#M270748
Мой коллега, Дмитрий Казаков, также написал статью здесь, на Хабре, с разбором этой темы. habr.com/ru/company/cisco/blog/493774
P.S: Есть важное уточнение — если вы используете домен верхнего уровня, все нижестоящие также идут в исключение, я попросил Диму про это в статье добавить подробнее.
В решении ETA функции сбора телеметрии (локально в сети, с помощью виртуальных или аппаратных коллекторов) делает Stealthwatch, он же запрашивает глобальную систему репутации Cognitive Threat Analytics об репутации и взаимосвязи внешних элементов (внешние IP, к которым шли необычные обращения, SHA256 хэши файловых образцов, если используется Cisco AMP, запрашиваемые во внешний мир подозрительные URL и FQDN). CTA требует явной настройки и по умолчанию выключен.
«Для того, чтобы NBAD был максимально эффективен, необходимо использовать базовые линии нормального сетевого или пользовательского поведения, которые должны вычисляться на протяжении определённого временного периода».
И где тут сказано, что NBAD использует сигнатуры?