Pull to refresh
2
0
Владимир Илибман @Setewik

User

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

Information

Rating
Does not participate
Location
Киев, Киевская обл., Украина
Registered
Activity