|
Атаки DDoS. Часть 7. Бронепробиваемость
Главная /
Архив номеров / 2016 / Выпуск №06 (59) / Атаки DDoS. Часть 7. Бронепробиваемость
Рубрика:
Безопасность
Facebook
Мой мир
Вконтакте
Одноклассники
Google+
Леонид Шапиро, архитектор ИТ-систем, MVP, MCT, MCSE, MCITP:EA, MCSE:S, MCSE:M
Атаки DDoS
Часть 7. Бронепробиваемость
Проверка систем отражения DDoS-атак. Проведение тестовых испытаний (сетевые флуды, прикладные атаки, сканирование)
 Все описанное в этой статье не является know-how. Все методики были опубликованы в открытых источниках. Автор взял на себя труд только свести их в единое целое и описать процесс тестирования средств защиты от DDoS-атак.
Как мы могли увидеть из предыдущих статей цикла [1-6], атаки DDoS приносят реальный ущерб компаниям, и, соответственно, очевидна потребность в защите. То есть мы говорим даже не столько об отражении атак как таковых, сколько об обеспечении работы легитимных пользователей.
В статье [5] мы рассмотрели, какие компоненты должны присутствовать в системах защиты от DDoS-атак, теперь разберемся, как проверить функциональные возможности подобных решений.
На рынке представлен ряд программно-аппаратных средств, позволяющих противостоять воздействию злоумышленников. Как проверить эффективность решения, предлагаемого поставщиком? Существуют различные способы как это сделать, но все они основаны на тестовом испытании.
Как проверить эффективность средств противодействия DDoS
Сегодня существует огромное количество нелегальных «интернет-сервисов», позволяющих заказать атаку на конкурента.
Следует понимать, что деятельность по проведению DDoS и иных атак нелегальна и подлежит преследованию в соответствии с 272-й статьей Уголовного кодекса Российской Федерации, причем ответственности подлежит как заказчик, таки исполнитель.
Тем не менее если мы отправим типовой запрос в поисковую систему, то обнаружим множество ссылок (см. рис. 1).
Рисунок 1. Результат запроса «Заказать DDoS-атаку»
Один из вариантов проверки своей инфраструктуры – реальная атака, выполненная настоящими киберпреступниками. Это может быть достаточно интересно, поскольку именно так может действовать любой злоумышленник, тем более это не потребует от него знаний в области информационной безопасности. С другой стороны, это носит крайне сомнительный характер ввиду взаимодействия с «темной» стороной в процессе проверки и финансирования киберпреступников,что никак нельзя признать правомерной деятельностью.
Автор не рекомендует применять указанный способ проверки ввиду его очевидной нелегальности.
Второй вариант – законный и основан на использовании независимой компании-аудитора, которая проведет проверку защищенности инфраструктуры от разного рода злонамеренных воздействий. При этом такая компания может как иметь представление о системе заказчика, так и ничего о ней не знать. Процесс проверки, как правило, будет включать поиск и анализ уязвимостей, атаку на целевую систему. Разумеется, подобная деятельность также должна быть полностью согласована и проводиться над тестовой средой, которая моделирует реальную. Компании – аудиторы ИБ должны обладать соответствующими знаниями и в результате проверок, смогут предоставить отчет об уязвимостях системы и рекомендации по защите.
Наконец третий вариант – самостоятельная проверка наличия уязвимостей в системе и эффективности противостояния атакам. Этот вариант не всегда возможен ввиду отсутствия знаний в области информационной безопасности внутри компании, и тем не менее многие тесты вполне можно проделать самостоятельно, пользуясь рекомендациями и средствами независимых сообществ разработчиков, которые предоставляют нам эффективный инструментарий и методики тестирования защищенности систем.
Мы сможем самостоятельно проверить предлагаемые поставщиком средства защиты и понять, насколько они соответствуют нашим ожиданиям и будут ли они эффективны против типовых атак. Еще раз хочу обратить внимание, что проведение проверки на рабочей системе может привести к крайне нежелательным последствиям, вплоть до полного отказа, с соответствующими финансовыми и репутационными потерями для предприятия, что допускать ни при каких условиях нельзя. В связи с этим, проводить такое исследование возможно исключительно в рамках тестовой пилотной среды, где и будут осуществляться все испытания.
Так как же должна выглядеть эта тестовая среда? Тестовая инфраструктура должна моделировать реальную, хотя бы по набору используемых служб. Примерную структурную схему можно увидеть на рис. 2.
Рисунок 2. Структурная схема защиты корпоративного ЦОД
В идеальном варианте тестирование защиты от DDoS-атак должно быть не только функциональным, но и нагрузочным. Необходимо проверить не только возможность отражения определенного класса атак, но и оценить возможность отражения атак большого объема, которые могут заполнить канал связи ЦОД, но это уже следующий этап проверки. Отражение подобных атак возможно путем перенаправления трафика организации на центры очистки. Мы пока сосредоточимся на функциональном тестировании.
Что касается списка проводимых атак, то обычно будет интересовать воздействие на службы, которые присутствуют в компании.
Существуют типовые классы DDoS-атак, упомянутые в статье [2], защищенность от которых целесообразно проверить.
- Сетевые DoS/DDoS-флуды.
- Прикладные DoS/DDoS-флуды.
- Сканирование и подготовка к атакам.
- Атаки прикладного уровня/Силовые атаки на взлом сервера.
- Медленные атаки малого объема.
- Атаки на веб-приложения.
- Атаки внутри зашифрованного трафика.
Тестовые атаки представляют собой воздействие на целевую систему, с помощью которого можно проверить ее защищенность.
Можно предложить следующие рекомендации по проверке систем защиты.
- Во-первых, все проводимые тесты должны быть идентичны для всех поставщиков решений по противодействию атакам.
- Во-вторых, для оценки рисков работы незащищенных систем стоит провести пробную атаку без использования каких-бы то ни было средств противодействия.
- В-третьих, используемый инструментарий для проведения проверки должен быть идентичен для всех проверяемых комплексов защиты.
- В-четвертых, тестовая среда также должна быть единой для всех.
В идеальном варианте осуществляется проверка на одном и том же тестовом стенде всех поставщиков решений, по заранее подготовленному и согласованному списку тестов, одним и тем же инструментарием для выполнения атак, просто переключаясь с одного комплекса противодействия на другой. То есть надо собрать оборудование всех испытываемых производителей в одном центре обработки данных и провести конкурентный тест.
Именно такой вариант может дать объективную картину их возможностей и позволит провести сравнение.
В качестве средства проверки защищенности можно порекомендовать виртуальные или физические машины Kali Linux [7], развернутые в тестовой корпоративной среде.
Показания функционирования корпоративной сети во время тестирования должны фиксироваться в журналах регистрации.
Крайне важным является не только сам факт отражения зловредного воздействия, но и время, которое потребовалось на обнаружение атаки. Кроме того, необходимо проверить, насколько эффективно работает легитимный пользователь податакой, может ли он или она работать со своими ресурсами, возникают ли задержки или блокирование требуемых сервисов.
Когда речь идет об атаках на веб-приложения, то есть об OWASP Top 10 [8], то в этом случае критерием успеха будет являться факт обнаружения попытки негативного воздействия. Например, злоумышленник пытается выполнить SQL-инъекцию, что обнаруживается системой и приводит к блокировке атакующего узла.
Что такое Kali Linux?
Сегодня Kali Linux [9] является, пожалуй, лучшим решением с точки зрения функциональных возможностей для проведения аудита безопасности и содержит огромное количество инструментов для выполнения проверок. Оно построено наоткрытом исходном коде и является бесплатным.
Не следует использовать предлагаемые Kali Linux инструменты для какой-то иной деятельности, кроме аудита ИБ, согласованного с заказчиком. Цель использования этих средств – проверка защищенности информационных систем [10].
В наличии качественная документация [10] и поддержка сообщества [11]. Все это делает Kali Linux самым удачным вариантом для функционального тестирования и аудита безопасности.
Компоненты тестового стенда
Итак, мы определились с методикой проведения испытаний, инструментарием, теперь надо понять, как же будет выглядеть тестовый стенд. Здесь должны присутствовать следующие инфраструктурные уровни:
- Вычислительная инфраструктура.
- Сетевая инфраструктура.
- Инфраструктура информационной безопасности (ИБ).
- Инфраструктура мониторинга, управления и отчетности.
Вычислительная инфраструктура состоит из атакующих станций, выполняющих различные виды DDoS-атак, рабочих мест, используемых для проверки работоспособности целевой системы, атакуемых серверов и сервера управления системой защиты от DDoS-атак.
В составе сетевой инфраструктуры работают виртуальные Ethernet-коммутаторы, физические Ethernet-коммутаторы, маршрутизаторы IP-трафика.
Инфраструктура ИБ содержит тестируемые средства защиты разных производителей, которые и подвергаются испытаниям.
Инфраструктура мониторинга, управления и отчетности состоит из соответствующих средств, предлагаемых поставщиками решений, а также рабочего места администратора безопасности.
Соответственно, если обратиться к рис. 2, то при испытаниях разных производителей решений замене подлежат модули противодействия DDoS-атакам, модуль WAF и система управления. Остальные компоненты будут оставаться неизменными.
Разумеется, схема отражает лишь общие структурные компоненты и не учитывает особенностей работы разных поставщиков решения с зашифрованным трафиком, а также не показывает работы с облачными средами. Но нужно помнить,что методы работы с SSL/TLS-трафиком у разных поставщиков систем противодействия атакам варьируются. Что касается облачных решений, то они потребуют перенаправления трафика на центры очистки облачного провайдера, в остальном же методика тестирования останется прежней.
Типовые DDoS-атаки с помощью Kali Linux
Проверка отражения сетевых флудов
Итак, структура испытательного стенда и подходы к тестированию определены, теперь можно перейти непосредственно к проверке систем защиты.
Начнем с атак на исчерпание ресурсов и рассмотрим сетевые флуды [12]. Это атаки сетевого уровня модели OSI [13]. Примерами таких атак служат SYN Flood, TCP flood, ICMP flood, UDP flood.
Разумеется, этот список не полон и может быть расширен, например, за счет IP flood с некорректно сформированными пакетами, так называемыми аномалиями, и прочими атаками. В конечном счете перечень испытаний всегда согласовывается с заказчиком, именно ему и предстоит определить перечень необходимых тестов.
Здесь приводятся наиболее часто встречающиеся в практике примеры атак сетевого уровня. Суть представленных атак подробно рассматривалась в статье [2], где можно познакомиться с «физическим смыслом» этих зловредных воздействий на систему.
Для любого из рассматриваемых испытаний мы осуществляем первую проверку без использования системы защиты и оцениваем возможности работы легитимного пользователя. Очевидно, что она будет либо невозможна, либо существенно затруднена. Удостоверившись в этом, переходим к проверкам соответствующих систем противодействия, последовательно рассматривая системы противодействия DDoS каждого поставщика, проверяя факт отражения атаки, время, которое потребовалось для этого, и, наконец, возможность работы пользователя под атакой при использовании системы противодействия.
Для проведения таких тестов нам потребуется провести соответствующие атаки.
Пробная атака TCP SYN на целевой веб-сервер может быть организована с помощью утилиты HPING3 [14].
Синтаксис команды может выглядеть следующим образом:
hping3 -S <IP address of protected server> -i u1 --rand-source -p 80
Hping3 будет отправлять SYN-запросы на порт 80 (-p). Атакуемый сервер будет вынужден отвечать с SYN+ACK. Так как мы используем случайный IP-адрес (rand-source), соединение никогда не будет выполнено. В результате сервер будет избыточно загружен обработкой мусорного трафика, что может сказаться на работе легитимных пользователей.
Примером TCP flood является атака TCP RST, рассмотренная в статье [2]. Синтаксис команды может выглядеть так:
hping3 <IP address of protected server> -p 80 -R --rand-source --faster
В этом случае сервер вынужден обрабатывать шквал RST-запросов, что приводит к его избыточной нагрузке. -R показывает, что выполнить надо атаку RST.
Примеры ICMP и UDP flood-атак:
UDP flood: hping3 --udp <IP address of protected server> -i u1 --rand-source -p 80
ICMP flood: Hping3 --icmp <IP address of protected server> -i u1 --rand-source
Цель ICMP и UDP flood – привести к нестабильности работы системы, заставить ее терять пакеты, при этом объем трафика может быть слишком большим.
Тестируем атаку на службу разрешения имен DNS – DNS flood. Эту атаку можно классифицировать и как прикладную, поскольку она может привести к отказу сервера, и как сетевой флуд, так как приводит к избыточной загрузке канала.
hping3 --udp <IP address of protected server> -i u1 --rand-source --destport 53 -x -g 500 -m 1000 -d 1000 & hping3 -- udp <IP address of protected server> -i u1 --rand-source --destport 53)
Выполните реальный HTTP-запрос к целевому веб-серверу с той же рабочей станции, с которой осуществляется атака. При выполнении запроса к веб-серверу легитимный трафик должен проходить, а пользователь получать доступ к серверу даже в процессе атаки. То есть блокироваться должен только трафик атаки. Если же этого не происходит, то система противодействия атакам не может ее правильно отразить. А если мощность сервера достаточная?
Для усложнения задачи целесообразно провести несколько атак единовременно, тем самым смоделировав так называемую многовекторную атаку, пример которой мы видим на рис. 3.
Рисунок 3. Многовекторная атака (пример тестирования с помощью утилиты HPING3)
Проверка отражения прикладных атак
Проверка противостояния прикладным атакам является важнейшим элементом испытаний надежности системы защиты. Рассмотрим некоторые примеры таких атак и посмотрим, справится ли с ними испытываемая система отражения.
Еще одной популярной атакой на приложения является HTTP page flood. Именно этот способ успешно применила небезызвестная группа Anonymous для атак на ряд государственных учреждений США. Для этих целей применялись утилиты HOIC и LOIC [15]. Следует проверить системы отражения DDoS-атак на эффективную борьбу с этими средствами.
Утилиты обладают графическим интерфейсом и позволяют организовать атаку, не требуя глубоких знаний, они широко доступны в интернете и позволяют строить бот-сети атакующих.
Противодействие сканированию
В статье [3] мы увидели, что обычно любые хакерские атаки предваряют разведка и поиск уязвимостей, что делается путем сканирования. Несмотря на то что некоторые производители решений от DDoS-атак по-прежнему продолжают игнорировать опасность такой деятельности, не обеспечивая свои системы возможностью противодействия, защищаться от сканирования следует.
Необходимо проверить тестируемые средства защиты корпоративной инфраструктуры на устойчивость к подобным «разведывательным действиям». Для этих целей будем использовать утилиту nmap [16], позволяющую выполнить как TCP, так и UDP- сканирование. Нам же потребуется проверить, сумеет ли испытываемая система обнаружить и отразить такую разведку.
Ниже приводятся примеры простейшего TCP и UDP-сканирования, однако утилиты nmap дают значительно больше возможностей для выявления открытых портов, операционных систем и сервисов, работающих на исследуемом узле.
nmap -sU -F <IP address of protected server>
nmap -sS -F <IP address of protected server>
Кроме того, будет целесообразно проверить с помощью сетевого монитора, например WireShark или Network Monitor [17], какое количество зловредного трафика достигает цели, прежде чем система противодействия DDoS сможет отразить атаку, и как много времени потребовалось на срабатывание системы.
Дополнительным важным аспектом проверки является проверка отображения атаки в системе управления, мониторинга и отчетности поставщика решения. Следует учесть такие характеристики, как удобство работы с системой администратора безопасности, отображение параметров атак и применяемых контрмер, графическое отображение информации, наличие системы оповещений и отчетности и т.п.
На рис. 4, 5, 6 представлены элементы системы мониторинга, предлагаемой компанией Radware. Обратите внимание на рис. 6, где по графику можно увидеть, что между стартом атаки и началом ее отражения проходит менее 20 секунд.
Рисунок 4. Мониторинг атак в реальном времени
Рисунок 5. Краткая информация об атаках
Рисунок 6. График роста входящего трафика атаки и интенсивности отражения
Разумеется, эти критерии в большей степени носят субъективный характер, в отличие от таких, как, скажем, временные показатели обнаружения и отражения атаки. Тем не менее при выборе решения следует их учитывать. Только исходя изполученных в результате исследования данных можно будет сделать вывод об эффективности той или иной системы отражения DDoS-атак.
В дальнейшем мы рассмотрим проверку устойчивости систем противодействия DDoS к другим классам атак, посмотрим, как настраиваются системы отражения DDoS-атак на примере Radware Defense Pro.
- Шапиро Л. Атаки DDoS. Часть 1. Война объявлена... // «БИТ», №5, 2015 г. – С. 28-31 (http://bit.samag.ru/archive/article/1504).
- Шапиро Л. Атаки DDoS. Часть 2. Арсенал противника. // «БИТ», №6, 2015 г. – С. 24-27 (http://bit.samag.ru/archive/article/1521).
- Шапиро Л. Атаки DDoS. Часть 3. Разведка. // «БИТ», №7, 2015 г. – С. 12-15 (http://bit.samag.ru/archive/article/1536).
- Шапиро Л. Атаки DDoS. Часть 4. Военные хитрости. // «БИТ», №8, 2015 г. – С. 22-23 (http://bit.samag.ru/archive/article/1559).
- Шапиро Л. Атаки DDoS. Часть 5. Основные принципы выбора системы защиты от DDoS атак. // «БИТ», №9, 2015 г. – С. 34-38 (http://bit.samag.ru/archive/article/1580).
- Шапиро Л. Атаки DDoS. Часть 6. Защита корпоративной инфраструктуры. Знакомство с Radware Defense Pro. Защита корпоративного ЦОД. // «БИТ», № 5, 2016 г. – С. 32-35 (http://bit.samag.ru/archive/article/1689).
- Kali Linux – https://www.kali.org.
- OWASP Top Ten – https://www.owasp.org/index.php/Category:Attack.
- Цели использования Kali Linux – https://www.kali.org/about-us.
- Документация Kali Linux – http://docs.kali.org.
- Сообщество Kali Linix – https://www.kali.org/community.
- Denial-of-service attack – https://en.wikipedia.org/wiki/Denial-of-service_attack.
- Модель OSI – https://en.wikipedia.org/wiki/OSI_model.
- HPING3 – http://tools.kali.org/information-gathering/hping3.
- Утилиты HOIC и LOIC – https://en.wikipedia.org/wiki/High_Orbit_Ion_Cannon.
- NMAP – http://tools.kali.org/information-gathering/nmap.
- Мониторинг и анализ сетевого трафика – https://www.wireshark.org, https://www.microsoft.com/en-us/download/details.aspx?id=4865.
В начало⇑
Facebook
Мой мир
Вконтакте
Одноклассники
Google+
Комментарии отсутствуют
Комментарии могут отставлять только зарегистрированные пользователи
|
_cover.jpg)
_cover.jpg)
_cover.jpg)
_cover.jpg)
