Как стать автором
Обновить

Комментарии 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.
НЛО прилетело и опубликовало эту надпись здесь
По факту все нетфлоу коллекторы начинают с одних действий — собирают, дедублицируют (убирают повторы) и агрегируют нетфлоу. А дальше начинаются нюансы, потому что включаются алгоритмы анализа поведения. В 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 ботнетов.
А в целом согласен, что алгоритмы лучше смотреть и сравнивать не на бумаге, а изучать в ходе тестирования. Тем более такая такая возможность есть.
НЛО прилетело и опубликовало эту надпись здесь
Для того чтобы получить интересующую информацию (приватные ключи 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 следующего поколения.
Зарегистрируйтесь на Хабре, чтобы оставить комментарий