Главная Networks, Security, Новое Атаки DDoS и выбор средств противостояния. Построение тестового стенда.
  • Атаки DDoS и выбор средств противостояния. Построение тестового стенда.

    В предыдущей статье мы познакомились с опасностью, которую представляют DDoS атаки, посмотрели ряд типовых атак и принципы их работы, и увидели основные методы противодействия DDoS. Итак, система противодействия DDoS атакам (а речь всегда должна идти о комплексном решении, иначе злоумышленникам будет проще найти способ атаки) должна обеспечивать решение приведенных ниже задач:

    1. Обеспечение бесперебойной работы без снижения производительности всех легитимных клиентов, независимо от того осуществляется атака или нет.
    2. Защита от всех известных классов атак.
    3. Система отражения должна срабатывать в автоматическом режиме за секунды, не требуя участия администратора.
    4. Система должна обеспечивать защиту не только на основе статических сигнатур, но и использовать модуль поведенческого анализа, позволяющий отразить атаки нулевого дня.
    5. Система должна работать на канальном уровне модели OSI и не иметь присвоенных IP адресов в сети, от узлов которой осуществляется защита.
    6. Для защиты от атак на переполнения канала связи, поставщик решения должен предложить облачный сервис очистки трафика.
    7. Необходимо обеспечить отражение атак внутри SSL трафика.
    8. Система противодействия DDoS атакам должна обладать модулем, которые позволит обеспечить борьбу со сканированием.
    9. Крайне важным является наличие единой системы управления всеми компонентами системы.
    10. Требуется эффективная система мониторинга и отчетности.
    11. Поставщик решения должен иметь в своем составе команду профессионалов, доступную в круглосуточном режиме для помощи во время атаки.

     

    Рассматривая предлагаемые на рынке решения имеет смысл выполнить проверку их работоспособности. Для этого целесообразно выделить тестовый сегмент сети и провести серию атак, чтобы удостовериться в эффективности противодействия. Имеет смысл проводить не только функциональное, но и нагрузочное тестирование. Первое дает возможность удостовериться в том, что система эффективна против определенных атак, второе же позволит проверить насколько эффективно удается справиться с большими объемами. Как же должно выглядеть это тестовое окружение и как провести атаки и проверить эффективность систем противодействия?

     

    Один из вариантов проверки своей инфраструктуры – реальная атака, выполненная настоящими киберпреступниками. Это может быть достаточно интересно, поскольку именно так может действовать любой злоумышленник, тем более, это не потребует от него знаний в области информационной безопасности. С другой стороны, это носит крайне сомнительный характер, ввиду взаимодействия с «темной» стороной в процессе проверки и финансировании киберпреступников, что никак нельзя признать правомерной деятельностью. Автор не рекомендует применять указанный способ проверки ввиду его очевидной нелегальности.

    Второй вариант – законный и основан на использовании независимой компании аудитора, которая проведет проверку защищенности инфраструктуры от разного рода злонамеренных воздействий. При этом такая компания может как иметь представления о системе заказчика, так и ничего о ней не знать. Процесс проверки, как правило, будет включать поиск и анализ уязвимостей, атаку на целевую систему. Разумеется, подобная деятельность также должна быть полностью согласована, и проводится над тестовой средой, которая моделирует реальную. Компании аудиторы ИБ должны обладать соответствующей экспертизой в требуемой области знаний и, в результате проверок, смогут предоставить отчет об уязвимостях системы и рекомендации по защите.

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

    Мы сможем самостоятельно проверить предлагаемые поставщиком средства защиты и понять насколько они соответствуют нашим ожиданиям и будут ли они эффективны против типовых атак. Еще раз хочу обратить внимание, что проведение проверки на рабочей системе может привести к крайне нежелательным последствиям, вплоть до полного отказа, с соответствующими финансовыми и репутационными потерями для предприятия, что допускать ни при каких условиях нельзя. В этой связи, проводить такое исследование возможно исключительно в рамках тестовой пилотной среды, где и будут осуществляться все испытания.

    Так как же должна выглядеть эта тестовая среда? Она должна моделировать реальную хотя бы по набору используемых служб. Тестируемые системы защиты должны по очереди включаться в это тестовое окружение, и, разумеется, на них должен проводиться идентичный набор атак. В этом случае можно оценивать системы отражения объективно.

    Конечно, среда тестирования будет существенно зависеть от того, что именно мы хотим протестировать. Если мы оцениваем только функциональные возможности отражения, не обращая внимания на то, что и сам канал связи может быть подвержен атакам, приводящим к его избыточной загрузке и, как следствие неработоспособности, то нам не потребуется включать в тестирование возможности облачной защиты для защиты канала связи. Достаточно будет только базового тестового стенда, иначе нам придется учесть и этот аспект.

    Если нас не интересует защита от атак на WEB приложения, то и модуль WAF на стенде нам не понадобится. Когда же речь идет о комплексной защите, то понадобятся все компоненты для формирования инфраструктуры безопасности.

    Начнем с самого простого варианта. Допустим мы говорим только о DDoS. В предыдущей статье мы уже предложили классификацию DDoS атак. Здесь я ее лишь напомню.

    1. Сетевые флуды;
    2. Атаки на ресурсы приложений;
    3. Сканирование;
    4. Медленные атаки малого объема;
    5. Сложные атаки на веб-приложения;
    6. Атаки под SSL.

    Для проверки систем противодействия этому набору атак предлагается схема тестового стенда, представленная на рис. 1.

    рис. 1.

     

    Выделяется три сетевых сегмента:

    Атакуемая сеть – в ней размещаются серверы, на которые будут осуществляться атаки. Обычно предлагается использовать типовой набор служб (WEB, DNS, Mail, NTP и и т. п.). Обратите внимание, на размещение модуля защиты от WEB атак, модуля WAF. Он всегда должен быть размещен за системой противодействия DDoS, и сам находится под ее защитой.

    Атакующая сеть – сеть для выполнения тестовых атак. Если речь не идет о проверке защиты от воздействия на канал связи, то вопросом облачной защиты можно пренебречь. Для выполнения тестирования можно воспользоваться такими средствами как Kali Linux, Raptor и подобными. В этой же сети имеет смысл создать и легитимного клиента, возможность работы которого мы будем оценивать во время атаки.

    Сеть управления – выделенный сетевой сегмент, предназначенный для размещения систем управления и мониторинга, а также рабочего места администратора безопасности.

    Система противодействия DDoS атакам включается перед пограничным маршрутизатором, при этом важно понимать, что она должна работать на канальном уровне модели OSI, не иметь сетевых адресов в атакующем и атакуемом сегментах.

    Такая схема оказывается вполне жизнеспособной, поскольку позволяет легко заменять DDoS протектор, сравнивая возможности разных поставщиков решения на едином наборе тестовых проверок.

     

    Продолжение следует…