Pull to refresh

Comments 9

WOW. Как я вдохновлен статьей. Превосходно подходит для специалистов СБ.
Спасибо!!! Пусть помогает в работе
А когда уже появится хоть что-то способное бороться с масштабными DDoS?
Во-первых, мы сейчас сотрудничаем с Arbor и Radware в части AntiDDoS решений. Arbor выпускает свои решения для модулей в наши магистральные маршрутизаторы CRS. Radware также получил интеграцию в программно-управляемые сети от Cisco .
Во-вторых, что касается Cyber Threat Defence. В своей текущей версии CTD может детектировать DDoS-атаки по NetFlow. Причем во время пилотов у нас детектирование работало на скоростях около 40гбит/c (большая часть трафика была грязная). Для борьбы с DDoS рекомендуется использовать сторонние продукты, тот же RadWare — www.lancope.com/blog/ddos-attack-detection-and-mitigation/ В следующих версиях решения ожидаем больше в части борьбы с DDoS.
UFO just landed and posted this here
По факту все нетфлоу коллекторы начинают с одних действий — собирают, дедублицируют (убирают повторы) и агрегируют нетфлоу. А дальше начинаются нюансы, потому что включаются алгоритмы анализа поведения. В CTD алгоритмов несколько десятков и Suspect Long Flow один из них. Наряду с использованием стандартных алгоритмов можно создавать и свои. Понятный пример создания такого пользовательского правила/алгоритма есть здесь:
www.lancope.com/blog/stealthwatch-system-65-user-defined-threat-criteria/
С помощью пользовательского правила можно автоматически выявлять трафик с подозрением на хартблид, анализируя flow duration и client ratio: www.lancope.com/blog/heartbleed-and-stealthwatch-system/

Интеграция с облачными сервисами есть — система регулярно по подписке получает поток с репутациями IP-адресов и url-префиксов. И данные по репутациям учитываются при корреляции событий. В частности с помощью репутаций выявляются обращения к С&C ботнетов.
А в целом согласен, что алгоритмы лучше смотреть и сравнивать не на бумаге, а изучать в ходе тестирования. Тем более такая такая возможность есть.
UFO just landed and posted this here
Для того чтобы получить интересующую информацию (приватные ключи SSL или пароли) злоумышленнику придётся повторять транзакции много раз и пользовательская сессия, скорее всего, будет длиться часы

Это у Вас откуда такая информация? Вы сами-то работали с эксплоитом, от которого защищаться собираетесь? В некоторых случаях достаточно 1 запрос послать. Если это сайт с разными учётными записями и нужно добыть больше одной учётки, то да будет больше 1 запроса. Но, скажем, раз в 5\10\15 мин. Отследите такую активность?
За один запрос можно получить блок памяти 64K из памяти процесса, который использует уязвимую версию SSL. Причем в большинстве случаев блок памяти будет случайный. Вероятность, что нужная учетка находится в первом блоке есть, но она зависит от того объема памяти, который отводится на процесс. Для 10Мб heap такая вероятность меньше 1%. Соответственно нужны сотни/тысячи запросов, чтобы вытащить конкретную учетку.
Ставились эксперименты по извлечению приватного ключа сервера. нужно от 100 000 запросов до нескольких миллионов arstechnica.com/security/2014/04/private-crypto-keys-are-accessible-to-heartbleed-hackers-new-data-shows/
Если запросы маскировать — например слать из раз N-минут — то это усложняет задачу выявления. Особенно если выбирать плавающий псевдослучайный период между запросами. Но с помощью Netflow такую активность все равно можно выявить, если использовать правильные механизмы корреляции и выявления аномалий. Такие алгоритмы, которые объединяли информацию от NetFlow с журналами веб-серверов, разрабатывала команда Cognitive Security. www.slideshare.net/gdusil/portfolio-cognitive-security-corporate-introduction-12 Cognitive сейчас является частью Cisco и алгоритмы Cognitive будут использоваться в решении Cyber Theat Defence следующего поколения.
Sign up to leave a comment.