DDoS-атаки в 2022 и методы защиты от них

DDoS-атаки в 2022 и методы защиты от них Хостинг

Вариант 1.

игроки столпились у входа

Представьте, что вы играете в многопользовательскую онлайн игру. С вами играют тысячи игроков. И с большинством из них вы знакомы. Вы обговариваете детали и в час Х проводите следующие действия. Вы все единовременно заходите на сайт и создаёте персонаж с одним и тем же набором характеристик. Группируетесь в одном месте, блокируя своим количеством одновременно созданных персонажей доступ к объектам в игре остальным добросовестным пользователям, которые о вашем сговоре ничего не подозревают.

Финансовый вопрос

Стоит обсудить еще один вопрос, связанный с организацией тестирования, — стоимость всего этого мероприятия.

Amazon предоставляет подробную информацию о тарифах, но нужно понимать, что приходится платить практически за все. Тем не менее многими расчетами можно пренебречь. В первую очередь стоит посчитать стоимость трафика (зависит от региона и от того, какой итоговый объем информации будет передан) и стоимость аренды инстансов (оплата поминутная). Эти пункты образуют примерно 99 % от стоимости всей атаки.

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

Для того чтобы проиллюстрировать подсчет стоимости проведения нагрузочного тестирования, допустим, что хотим проверить устойчивость DNS-сервера к нагрузке в 10 Гб/c.

Нам известно, что используемые инструменты и возможности инстанса t3.small, запущенного в Мумбаи, позволяют выдать 500 Мб/c с одного запущенного инстанса. Цена за аренду сущности – 0,0224 $ в час, за трафик – 0,01093 $ за 1 Гб. То есть пик атаки означает одновременную работу 20 сущностей.

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

Формула расчета стоимости принимает вид:

60 с * (стоимость аренды в секунду) + 60 с * 0,5 Гб/c * (стоимость Гб трафика) = стоимость атаки с одной сущности за 60 с.

1 * (стоимость атаки с одной сущности) + 2 * (стоимость атаки с одной сущности) + ... + 20 * (стоимость атаки с одной сущности) = стоимость всей атаки

Получается, что стоимость одной атаки мощностью в 10 Гб/c на DNS-сервер – примерно 70 $. Отметим, что это приблизительная оценка, так как объем трафика нельзя абсолютно точно спрогнозировать. Подробнее про цены можно почитать здесь. Более того, правильный подход – выполнить проверку несколько раз, чтобы откалибровать настройки тестируемого сервера.

На этом все про организацию нагрузочного тестирования. Желаем не убить ваши серверы в процессе проб и ошибок.

ПРЕДУПРЕЖДАЮ

Этот вариант для опробывания только для локального хоста. Вот почему:

  • против чужих сайтов это противозаконно, и за это на Западе уже реально сидят (а значит, будут скоро сажать и здесь)
  • адрес, с которого идёт флуд, вычислят быстро, пожалуются провайдеру, а тот вынесет вам предупреждение и напомнит про первый пункт
  • в сетях с низким пропускным каналом (то есть во всех домашних) вещица не сработает. С сетью TOR всё тоже самое.
  • если её настроить должным образом, вы быстрее забьёте именно СВОЙ канал связи, чем навредите кому-то. Так что это именно тот вариант, когда груша бьёт боксёра, а не наоборот. И вариант с прокси будет проходить по тому же принципу: флуд с вашей стороны не понравится никому.

Примеры DDoS-атак разных уровней

Ниже я попробовал описать основные DDoS-атаки, которые часто встречаются для L3, L4, L7. Наиболее интересные, конечно, атаки на уровне приложения: они, по моему мнению, более разрушительные (поскольку нарушают логику работы веб-приложения, что приводит к неправильным результатам работы веб-приложения либо вообще упущению прибыли организации) и с ними тяжелей бороться (стандартные «чистилки» трафика L3, L4 тут выручат далеко не всегда, нужно ставить Web Application Firewall (WAF) и настраивать правила детекта и блокировки запросов уже на нем). Атаки L3, L4 обычно приводят просто к недоступности сервиса (он не отвечает вообще либо отвечает ошибками 5хх). Атаки L7 не всегда приводят к появлению таких ошибок.

Что такое L3/L4/L7, про которые часто упоминается в тексте?

L3 / L4 / L7 — названия уровней представления по сетевой модели ISO/OSI. Не вдаваясь в дискуссии, нужна/не нужна эта модель, жива она или мертва — в данном случае это не суть — опишу кратко:

  • L3 — сетевой уровень. Это где происходит трансляция сетевых адресов в физические адреса, на нем работает ряд протоколов маршрутизации и прочих служебных

  • L4 — транспортный уровень. Тут живут протоколы UDP и TCP, уровень отвечает за передачу данных от отправителя к получателю

  • L7 — прикладной уровень. Тут уже живут протоколы HTTP, HTTPS и работают веб-приложения — то, что видите в браузере

Если нужно больше узнать об ISO/OSI — то вэлкам в Википедию: https://ru.wikipedia.org/wiki/Сетевая_модель_OSI#Сетевой_уровень

Что есть ошибки 5хх?

Ошибки 5хх — серия кодов ошибок состояния HTTP, которые отдает сервер, когда не может обработать запрос пользователя. Чаще всего отдает 500 — «внутренняя ошибка сервера» или 502 «Bad Gateway» / 503 «Сервер недоступен». Для интересующихся, полный список можно прочитать в Википедии: https://ru.wikipedia.org/wiki/Список_кодов_состояния_HTTP#5xx

Мониторинг доступности сервиса

Дополнительно для проведения атаки потребуется наблюдать, жив ли тот сервис, который мы тестируем.

Создаем и запускаем простейший «пинг»-скрипт, который отслеживает доступность целевых портов (53 и 80 в нашем случае).

Пример кода на Python, который позволяет автоматизировать проверку доступности:

def http(url):
    cmd = ['curl', '-w', '"%{time_total}"', '-o', '/dev/null', '-s', url]
    result = check_output(cmd).decode('utf-8')
    result = float(json.loads(result))
    return result * 1000000

def dns(ip, domain):
    cmd = ['dig', 'any', '@'+ip, domain ]
    result = check_output(cmd).decode('utf-8')
    result = int(result.split('Query time:')[1].split('msec')[0])
    return result

Полученную информацию сохраняем в лог-файле, на основе которого по итогам атаки можно будет построить график доступности ресурса.

В ходе проведения тестирования необходимо постоянно проверять «пинг»-лог, чтобы не убить ресурс окончательно и бесповоротно. Как только появляется существенная деградация и ответ на запрос занимает слишком много времени, атаку нужно прекращать.

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

О чем длиннопост?

Привет читающим этот длиннопост. Давно ничего не писал на Хабре, но 2022 год выдался достаточно непростым в плане DDoS-атак. По роду деятельности, я столкнулся с большим количеством вопросов о том, что такое DDoS-атаки, нужно ли с ними бороться (WTF??? конечно, не нужно, пусть все лежит нужно). Зрелым матерым спецам здесь вряд ли будет интересно.

Хочу сразу отметить, что некоторым читателям, погруженным в банковскую тематику, текст может показаться знакомым. И да, он в каком-то виде был выпущен для узкого круга лиц, но поскольку уже прошло достаточно времени, а данные в целом не устарели и автор этого поста был, в основном, автором этого текста, то я решил выложить его на хабр в несколько сокращенном и подредактированном варианте, дабы давать ссылку на этот пост, когда опять начнут задавать вопросы, либо для своих студентов.

Пользуясь случаем, хочу поблагодарить Qrator Labs — они не принимали участие в подготовке этого поста, но внесли очень большой вклад в оригинальный текст, известный в вышеупомянутых узких кругах. Без них он бы не родился 🙂

Краткий пересказ всех частей

Поскольку материала набралось достаточное количество, решил разнести в несколько постов, чтобы проще было читать.

Часть 1: То, что вы читаете сейчас. Самый-самый базис: что такое DDoS-атака и основные типы атак, с примерами

Часть 2: Защита от DDoS-атак. Почитать тут.

Согласование нагрузочного тестирования

Отправляем сообщение, где коротко рассказываем о своих намерениях, и получаем форму, которую должны заполнить:

Customer ID:
   Customer Name:
   Email Address:
   AWS Account ID load test will be performed from:
   Does the customer have an NDA?

Target Data

   EC2 Resources:
   Cloudfront Distribution:
   API Gateway / Lambda ID:
   ELB Names:
   Non-AWS Target:
   Region (please list all regions in scope for testing):

Source Data:

   IP Addresses:
   Source Account ID:
   Regions involved:

Testing Parameters:

   How much traffic do you plan to generate by region during testing?
   What is your expected peak load from source by region? (i.e. xx Gbps)
   What is your expected peak load at destination? (i.e. xx Gbps)
   Are you testing traffic outbound from EC2, inbound into EC2, or both?
   Are you testing traffic outbound (egress) from EC2, inbound (ingress) into EC2, or both:
   Egress. What is your expected peak load from source by region? (i.e. xx Gbps)
   Ingress. What is your expected peak load from source by region? (i.e. xx Gbps)

   Start Date:
   End Date:
   Finite testing details including timeline of testing:
   Summary of Test:
   Testing Timelines by phase including rps, pps, and Gbps:
   Peak bandwidth for each source IP:
   Tools Used for each phase of test:
   Types of testing to be performed for each phase of the request:
   What criteria/metrics will you monitor to ensure the success of this test?
   Who is performing the Load Test? (Please provide contact details):
   Does the tester have an NDA?

Testing Security

   Do you have a way to monitor the data traffic for the duration of the test to verify 
bandwidth limits do not exceed approved rates?
   Do you have a way to immediately stop the traffic if we/you discover any issue?
   2 Emergency contact names and phone numbers:

Есть несколько нюансов:

  1. У нас спрашивают, кого будем «дубасить». Имеем ли мы на это право? Говорим, что это наш ресурс (по всей видимости, никто не проверяет, так ли это) и что тестирование полностью согласовано.

  2. Нам нужно обозначить, сколько трафика создадим в каждом из регионов. В ходе переписки выясняем, что каждый регион имеет свой лимит на количество сетевого трафика. В общей сложности разрешают запросить 645 Гб/c. Считаем, сколько нужно для атаки, и набираем регионы таким образом, чтобы получилось необходимое значение.

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

  4. И в обязательном порядке всеми силами стараемся заверить, что будем вести себя хорошо, внимательно наблюдать за ходом тестирования и остановим его по первому требованию в случае необходимости.

Скорее всего, в ответ на заполненную форму попросят какие-то разъяснения, поэтому переписываемся и отвечаем на вопросы до тех пор, пока не получим разрешение на тестирование.

На все согласование уходит примерно три рабочих дня, если отвечать оперативно.

Управление инстансами

Теперь разберемся с удаленным (максимально автоматизированным) управлением инстансами.

Для этих целей можно использовать механизм AWS CLI – управление с помощью консоли.

Создаем Secret Key (Access keys (access key ID and secret access key)) и настраиваем консоль.

Теперь у нас есть доступ ко всем возможностям учетной записи.

Особенность работы с AWS состоит в том, что все действия выполняются для конкретного региона и их приходится повторять, если привлечено несколько регионов.

Для создания нового инстанса из образа, который мы выше смастерили (подразумеваем, что есть публичный ami-ID, который используем в скрипте), выполним следующие действия:

  • создаем SSH-ключ и добавляем его в AWS:

yes n |ssh-keygen -q -t rsa -f $KEYNAME -m pem -N "" > /dev/null
chmod 400 $KEYNAME
aws ec2 import-key-pair --region $REGION --key-name $KEYNAME --public-key-material file:///$(pwd)/$KEYNAME.pub

  • создаем security-group, который разрешает доступ к машине по SSH. В противном случае входящие SSH-соединения будут запрещаться:

SECURITY="ssh-group"
aws ec2 create-security-group --region $REGION --group-name $SECURITY --description "Just ssh. Nothing more"
IP_RANGE="0.0.0.0/24"
aws ec2 authorize-security-group-ingress --region $REGION  --group-name $SECURITY --protocol tcp --port 22 --cidr $IP_RANGE

  • создаем инстанс с созданными ранее ключом и security-group и указываем ID образа. Число инстансов, создаваемых единовременно, может быть произвольным:

IMG='ami-0d0eaed20348a3389'
NUM=1
aws ec2 run-instances --region $REGION --image-id $IMG --count $NUM --instance-type t2.micro --key-name $KEYNAME --security-groups default $SECURITY > instances.json

  • ждем, пока машина проинициализируется. Это занимает какое-то время: сначала мы получаем ответ об успехе (instances.json), но в это время машина только создана, но еще не запущена (например, ей еще не присвоен IP-адрес). Необходимо дождаться завершения запуска (обычно для этого достаточно минуты).

aws ec2 describe-instances --region

Далее выполняем SSH-команды, указав SSH-ключ, созданный выше:

ssh -I $KEYNAME -oStrictHostKeyChecking=no ubuntu’'+ins_dns echo‘'O’'

SSH-команды позволяют управлять атакой и получать всю информацию о состоянии атаки, так как мы снабдили инстансы всеми необходимыми скриптами и инструментами.

Разница между выключением и удалением заключается в том, что мы посылаем разные сигналы. Stop – чтобы выключить, terminate – чтобы выключить и сразу же удалить.

В целях мониторинга входящего трафика инстанса используем следующую команду с указанием ID инстанса: когда начинается замер трафика, когда заканчивается, за какой период значения суммируются:

aws cloudwatch get-metric-statistics --region REGION --namespace AWS/EC2 \
        --statistics Sum --metric-name NetworkIn 
        --start-time $STARTTIME --end-time $FINISHTIME
        --period $PERIOD --dimensions Name=InstanceId,Value=$INCTANCEID

Какой он вообще бывает, дедос

DDoS — он такой, разный. Но все ж особой фантастики тут нет, достаточно прозаичные вещи. От L3 (сетевой уровень) до L7 (прикладной). Обычно классифицируют так:

В отдельный подкласс обычно выделяют, так называемые, Amplification-атаки. Их отличительной особенностью является использование промежуточных уязвимых компьютеров для увеличения «плеча» атаки в 2-3 раза. Amplification-атаки классифицируются в зависимости от протокола, используемого для усиления мощности атаки: NTP Amplification, DNS Amplification, SSDP Amplification и подобное.

2.      Атаки на инфраструктуру, целью которых является нарушение нормального (штатного) функционирования промежуточного и служебного оборудования: маршрутизаторов, межсетевых экранов и т.д. В качестве таких атак могут выступать SYN flood, Route Loop DDoS и пр. Кривые анонсы BGP, которые были на слуху, тоже можно отнести к такого типа атакам. Хотя и не всегда они были вызваны злонамеренными действиями, а объяснялись банальной криворукостью.

3.      Атаки на транспортный уровень (L4), в частности, с использованием различных этапов TCP-соединения. Это связано с тем, что протокол TCP достаточно сложен с вычислительной точки зрения и допускает эксплуатацию атакующим ряда узких мест, например, алгоритмов установления и закрытия TCP-соединения. В качестве примеров такой атаки могут выступать SYN Flood, ACK Flood, TCP Connection Flood и подобные. Ну, в целом это наиболее распространенная атака в силу простоты ее реализации.

4.      Атаки на встроенные механизмы протоколов SSL/TLS. Эти протоколы ещё более сложны, чем TCP, поэтому атакующий может ставить своей целью воздействие на них. Например, можно говорить об атаках на сам процесс установки SSL/TLS взаимодействия (TLS handshake), отправке «мусорных» пакетов серверу или злоупотреблении функциями согласования ключевой информации и подобное.

5.      Атаки на сервис прикладного уровня (L7-атаки). Эти атаки взаимодействуют непосредственно с приложением, причём надо отметить, что в последние годы это воздействие распространяется не только на «классический» HTTP, но и на HTTPS, DNS, VoIP, SMTP, FTP и другие прикладные протоколы. В случае c протоколом HTTP, атакующий может дополнительно маскировать свои деструктивные действия внутри SSL/TLS-трафика, что значительно усложняет противодействие. Такие атаки могут подразделяться на следующие виды:

a.      Медленные атаки малого объема, так называемые «Low and Slow». Этот вариант представляет опасность в силу малой заметности и продолжительного времени нарастания зловредного воздействия. Обычно здесь речь идет о воздействии на приложения и иногда на серверные ресурсы;

b.      Атаки, основанные на значительном числе произвольных «мусорных» запросов. Целью таких атак обычно является мощный «кумулятивный» удар по системе, вследствие которого она долгое время не сможет обрабатывать запросы от легитимных пользователей. Характерным примером является атака типа WordPress Pingback DDoS. Хотя эта атака однозначно обнаруживается и фильтруется по типовым HTTP-заголовкам, тем не менее, она может составлять серьёзную проблему для атакуемого ресурса, поскольку полоса такой атаки может достигать десятков Гбит/с и в состоянии превысить показатели по доступности канальной ёмкости и производительности HTTP-сервера;

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

Зачем используется DDOS атака ?

Взлом WiFi применяется для забора пароля беспроводной сети. Атаки в форме «человек-посередине» позволят слушать интернет-трафик. Анализ уязвимостей с последующей подгрузкой конкретного эксплойта даёт возможность захвата целевого компьютера. А что же делает DDOS атака ? Её цель в конечном итоге — отбор прав на владение ресурсом у законного хозяина. Я не имею ввиду, что сайт или блог вам не будет принадлежать. Это в том смысле, что в случае удачно проведённой атаки на ваш сайт, вы потеряете возможность им управления. По крайней мере, на некоторое время.

Однако в современной интерпретации DDOS атака чаще всего применяется для нарушения нормальной работы любого сервиса. Хакерские группы, названия которых постоянно на слуху, совершают нападения на крупные правительственные или государственные сайты с целью привлечь внимание к тем или иным проблемам. Но почти всегда за такими атаками стоит чисто меркантильный интерес: работа конкурентов или простые шалости с совсем неприлично незащищёнными сайтами. Главная концепция DDOS состоит в том, что к сайту единовременно обращается огромное количество пользователей, а точнее запросов со стороны компьютеров-ботов, что делает нагрузку на сервер неподъёмным. Мы нередко слышим выражение «сайт недоступен», однако мало, кто задумывается, что скрыто на самом деле за этой формулировкой. Ну, теперь-то вы знаете.

DDos — Distributed Denail of Service Attack

Каждый веб-сервер имеет свою собственную способность обрабатывать запросы в определенное время. DDos может произойти, когда веб-сервер или система получает так много запросов в одно время, что не может их обработать, тогда система зависает или автоматически отключается. В результате веб-сайт терпит крах или временно не работает. Когда сайт становится жертвой DDos-атаки, он теряет всю выделенную ему пропускную способность, что приводит к временному отказу сервера сайта. Перегрузка сети или наводнение веб-сервера огромным количеством запросов за один раз приводит к отключению передачи данных между сервером и пользователем. Таким образом, сайт переходит в состояние временного простоя или сталкивается с проблемой недоступности сервера из-за DDos-атаки на сайт. Пока системный администратор не проанализирует все запросы, невозможно отфильтровать запросы злоумышленников.

Существует несколько способовдля DDos веб-сайта. Я упоминаю здесь DDos из командной строки вручную и автоматический DDos с помощью бесплатных инструментов.

Метод #1: Как DDos-атаковать сайт вручную с помощью командной строки Windows

  • Выберите небольшой сайт, который вы хотите DDos-атаковать.
  • Найдите IP-адрес сайта. Чтобы найти IP-адрес конкретного сайта, просто используйте следующую команду:
    ping www.example.com -t
  • Теперь введите следующую команду:
    ping [ip address] -t -l 65500
  • Запустите команду на несколько часов. Если возможно, используйте несколько компьютеров для одновременного выполнения одной и той же команды.
  • Теперь, когда вы зайдете на сайт через 2 или 3 часа, вы увидите сообщение «сайт временно не работает» или «сервер недоступен».
  • Примечание: У вас должно быть интернет соединение с неограниченной пропускной способностью. В противном случае вы потеряете всю пропускную способность интернета для выполнения задания.

    Метод #2: DDos-атака сайта с помощью LOIC автоматически

    Для того чтобы замедлить работу сайта или полностью отключить его, вам понадобится инструмент под названием LOIC (Low Orbit Ion Canon). Давайте посмотрим, как провести DDos-атаку на сайт с помощью низкоорбитальной ионной пушки.

  • Скачайте программу по следующей ссылке:
    http://sourceforge.net/projects/loic/
  • После того, как вы скачаете программу, извлеките ее на рабочий стол Windows.
  • Перейдите на сайт: Дважды щелкните по иконке программы, чтобы открыть ее. LOIC является портативным программным обеспечением и не требует установки.
  • Теперь введите адрес веб-сайта.который вы выбираете в поле ‘целевой URL’.
  • В поле IP необязательно указывать IP целевого сайта. Вы можете получить IP-адрес сайта с помощью команды ping из Windows.
  • Нажмите кнопку ‘lock on’, которая находится рядом с текстовым полем.
  • В разделе ‘Атака’ не изменяйте таймаут, HTTP-подсайт, полосу скорости.
  • Под ‘TCP/UDP Message’, введите все, что вы хотите правильно.
  • В поле ‘Port’ измените значение порта целевого сайта. В большинстве случаев должно работать значение ’80’.
  • В поле ‘Метод’ из выпадающего списка выберите опцию UDP.
  • Снимите флажок «Ждать ответа».
  • Измените значение потока до 20, если у вас хороший компьютер. В противном случае оставьте значение 10.
  • Нажмите кнопку «IIMA CHARGIN MAH LAZER».
  • Запустите программу хотя бы на час. Затем посетите сайт, на который вы нацелились, и вы должны увидеть там проблему «Service Unavailable». Это способ DDos-атаки на сайт и временного прекращения его работы.

    Метод #3: Как использовать Google Spreadsheet для DDos веб-сайта

    Google всегда использует краулер feedfetcher для захвата изображения, а затем отображает кэш-изображение. Google использует ту же технику с помощью Google Spreadsheet для кэширования и отображения любого изображения, которое находится внутри значения =image(«»). Например, если я помещу функцию =image(«https://www.techperiod.com/wp-content/uploads/2016/01/LOIC.png») в электронную таблицу, она получит изображение и отобразит его.

    Используя запрос со случайными параметрами, можно попросить feedfetcher crawler просмотреть один и тот же файл несколько раз. Если я использую ссылку на большой файл pdf, Google feedfetcher crawler ничего не получит. Но он многократно просматривает сайт, что приводит к потере пропускной способности/трафика. Поскольку он ничего не извлекает, нет опасений потерять пропускную способность.

    В этом случае функция электронной таблицы должна быть примерно такой:

    =image("http://example.com/sample.pdf?r=0")
    =image("http://example.com/sample.pdf?r=1")
    =image("http://example.com/sample.pdf?r=2")
    ......
    ......
    =image("http://example.com/sample.pdf?r=999")
    =image("http://example.com/sample.pdf?r=1000")
    

    Таким образом, используя один ноутбук, любой может создать сайт и отправить 250 ГБ трафика в течение 45 минут.

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

    Пара слов о векторах атак

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

    В чем опасность сканирования применительно к DDoS?

    Сканирование сети — и использование сетевых сканеров — означает разведку сети. Обычно стараются достичь следующих целей (одной или нескольких):

    • Определение находящихся в сети узлов (сетевое сканирование)

    • Выявление открытых портов и функционирующих сервисов (сканирование портов)

    • Выявление известных уязвимостей веб-приложений (сканирование безопасности)

    Имея на руках эти данные, атакующий может скорректировать свои усилия: например, зная, что какая-то уязвимость приводит к падению условного веб-сервера (что расценивается как отказ в обслуживании, DoS) — он может перестать вас атаковать HTTP-флудом, а использовать эту уязвимость (смена вектора атаки).

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

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

    В тоже время, само по себе сканирование не всегда является злонамеренным действием, все зависит от его целей. Службы информационной безопасности или сотрудники ИТ вполне могут прибегнуть к сканированию для выявления уязвимостей инфраструктуры и выполнения иных задач.

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

    DDoS-атаки в 2022 и методы защиты от них

    Подготовка инфраструктуры

    После согласований сталкиваемся с необходимостью подготовить инфраструктуру для тестирования. Дело в том, что во время проверки нам нужно будет оперативно:

    • включать инстанс;

    • запускать тестовую атаку;

    • собирать статистику о ходе проведения;

    • останавливать тестовую атаку;

    • выключать инстанс.

    DDOS атака с помощью программ.

    Для более наглядного примера воспользуйтесь программой Low Orbit Ion Cannon (Ионная пушка с низкой орбиты). Или LOIC. Самый скачиваемый дистрибутив располагается по адресу (работаем в Windows):

    ! Ваш антивирус должен отреагировать на файл как на вредоносный. Это нормально: вы уже знаете, что качаете. В базе сигнатур он помечен как генератор флуда — в переводе на русский это и есть конечная цель бесконечных обращений на определённый сетевой адрес. Я ЛИЧНО не заметил ни вирусов, ни троянов. Но вы вправе засомневаться и отложить загрузку.

    скачать LOIC

    Так как нерадивые пользователи забрасывают ресурс сообщениями о вредоносном файле, Source Forge перекинет вас на следующую страницу с прямой ссылкой на файл:

    скачать LOIC по прямой ссылке

    Окно программы выглядит вот так:

    low orbit ion canon

    Пункт 1 Select target позволит злоумышленнику сосредоточиться на конкретной цели (вводится IP адрес или url сайта), пункт 3 Attack options позволит выбрать атакуемый порт, протокол (Method) из трёх TCP, UDP и HTTP. В поле TCP/UDP message можно ввести сообщение для атакуемого. После проделанного атака начинается по нажатии кнопки IMMA CHARGIN MAH LAZER  (это фраза на грани фола из популярного некогда комиксмема; американского мата в программе, кстати, немало). Всё.

    Атаки сетевого уровня (L3)

    В результате, при относительно небольшом трафике, можно добиться перегрузки по количеству пакетов. Атакуемый узел начинает работать нестабильно, терять пакеты.

    Усиление атаки достигается использованием бот-сети («ботнета»), когда запросы приходят с тысяч узлов. Кроме этого, можно отправить запрос по широковещательному адресу с поддельным адресом-источника пакета (так называемые Smurf-атаки). Отправка эхо-запроса ICMP на широковещательный адрес заставляет все узлы в этой сети отправить эхо-ответы на подмененный адрес, который и является адресом жертвы, то есть происходит усиление атаки (Amplification). Схема на рисунке ниже.

    DDoS-атаки в 2022 и методы защиты от них

    Принципы атаки схожи с предыдущим вариантом и заключаются в отправке множества UDP-пакетов на определённые номера портов атакуемого узла, который для каждого полученного пакета должен идентифицировать соответствующее приложение, отправив ответное ICMP-сообщение «адресат недоступен» или, в худшем случае, передать данные UDP-пакета пользовательскому приложению и оттранслировать полученный ответ.

    В итоге, атакуемая система окажется перегруженной, поэтому после начала атаки зловредный трафик может быстро захватить всю доступную полосу пропускания, не оставив ничего легитимному трафику, что и является целью атакующего – не дать работать легитимным пользователям. Подменив IP‑адреса источников в UDP-пакетах, атакующий может перенаправить поток ICMP-ответов и тем самым сохранить работоспособность атакующих узлов, а также обеспечить их маскировку.

    Следует отметить, что ни ICMP flood, ни UDP flood не используют уязвимостей системы, то есть мы имеем дело со стандартными принципами работы стека протокола TCP/IP.

    Кроме того, существуют методы, позволяющих значительно (в 10-1000 раз) усилить атаку, например, направив исходный трафик атаки не непосредственно на атакуемый узел, а на уязвимый промежуточный сервер, обеспечивающий усиление (Amplification).

    Атаки на транспортный уровень

    Атаки на транспортном уровне сети обычно эксплуатируют основные «узкие места» в реализации протокола TCP при установке сессии. Обычно это либо этап установления сессии, либо атака на таблицу соединений протокола TCP. Ниже разберем основные типы атак.

    Атака типа SYN flood эксплуатирует особенность стека протоколов TCP/IP – потребность установки TCP-сессии. В отличие от UDP, где это не требуется, при TCP-взаимодействии необходимо, чтобы отправитель «договорился» с получателем перед тем, как что-то будет отправлено. Для этого используется механизм three-way handshake – «тройного рукопожатия», или трехэтапного подтверждения. Принцип его работы выглядит следующим образом:

    1.      Клиент посылает пакет с TCP-сегментом SYN (Synchronize);

    2.      Сервер отвечает пакетом с сегментом SYN-ACK (Synchronize-Acknowledge);

    3.      Клиент подтверждает прием пакета SYN-ACK пакетом ACK (Acknowledge).

    На этом процедура установления соединения завершается. Но, что существенно, сервер обязан выделить все необходимые ресурсы в момент получения SYN-сегмента от клиента, до отсылки ответного пакета SYN-ACK.

    Сложность использования этих методов состоит в том, что для генерации SYN Cookies необходимы адекватные текущему уровню атак вычислительные мощности и сетевые ресурсы с пропускной способностью от 100 Гбит/с и более. Защищённая инфраструктура должна обладать этими ресурсами в обязательном порядке.

    DDoS-атаки в 2022 и методы защиты от них

    TCP Connection Flood

    Для более успешного противодействия такой атаке обычно ограничивают таймауты на установление и поддержание (в состоянии бездействия, idle time) TCP-соединений. Как правило, оптимальное значение – около 60 секунд, но оно может варьироваться в зависимости от задач, возложенных на сервер.

    В то же время, категорически нельзя использовать «чёрные списки» для фильтрации любых атак, не задействующих открытые TCP-соединения, например, для борьбы с SYN flood или ICMP flood. Использование «чёрных списков» для этой цели может привести к недоступности сервиса для легитимных пользователей, а в дальнейшем – к исчерпанию памяти и других вычислительных ресурсов средства фильтрации трафика.

    Атаки, основанные на протоколе SSL/TLS

    HTTPS Flood – атака на Secure Socket Layer (SSL): с ростом популярности этого метода шифрования, используемого в различных сетевых протоколах, он также стал мишенью для атакующих. Концептуально SSL или его современная версия – TLS – используется поверх TCP/IP, обеспечивая безопасность соединений путем шифрования и аутентификации сторон.

    DDoS-атаки, связанные с протоколом SSL/TLS, принимают различные формы: они могут быть нацелены на механизм взаимодействия при установлении SSL/TLS-сессии и выражаться в отправке «мусорных» данных на сервер SSL/TLS или эксплуатации определенных функций, связанных с процессом согласования ключей шифрования SSL/TLS. Такого рода атаки обычно считаются «асимметричными», так как сервер расходует на обработку атаки с использованием SSL/TLS гораздо больше ресурсов, чем требуется для ее запуска.

    Например, атака THC-SSL-DoS использует малое количество пакетов для приведения в состояние «отказ в обслуживании» даже достаточно мощного сервера. В ходе этой атаки сначала инициируется SSL взаимодействие для установки сессии, а затем немедленно запрашивается процедура повторного согласования ключа шифрования.

    Этот инструмент постоянно повторяет запрос на повторное согласование до тех пор, пока все ресурсы сервера не будут исчерпаны. Атакующие предпочитают запускать атаки с использованием SSL, потому что установка каждой сессии SSL требует примерно в 15 раз больше ресурсов на стороне сервера, чем на стороне клиента. Фактически, один обыкновенный домашний персональный компьютер при определенных условиях может вывести из строя целый web‑сервер, использующий SSL, а несколько компьютеров могут вывести из строя всю серверную часть (даже целую ферму) защищенных онлайн сервисов.

    Атаки на web-приложения

    Наиболее распространенными DDoS-атаками, нацеленными на приложения, являются разновидности атак на протокол HTTP. В литературе для обозначения таких атак обычно используется обобщенный термин HTTP flood. Обычно для их осуществления используется бот-сеть из зараженных устройств, но в ряде случаев в состав атакующих вполне могут входить и добровольцы, например, когда речь идет о целенаправленной хактивистской деятельности.

    В атаке могут использоваться любые HTTP-запросы, но обычно используют GET и POST. Атака также может осуществляться с использованием шифрованных TLS-сессий. Конечной целью атаки является исчерпание ресурсов web‑приложения. Тут надо понимать, что «железных» ресурсов сервера еще может оставаться много — и незабитого канала тоже может (но не обязательно) остаться много. Но узким местом станет именно само веб-приложение: из-за особенностей конфигурации или в силу других причин оно либо просто перестанет обслуживать легальные запросы, либо просто упадет.

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

    Угрозы от этой атаки — исчерпание канальной емкости и отказ на уровне обработки запросов, так как у любого HTTP-сервера, а тем более – web-приложения или ресурсов, обеспечивающих его работу (система авторизации, СУБД и др.), есть свой предел производительности. В результате, легальный запрос не будет обработан, а пользователь не получит своей порции цифрового контента.

    DDoS-атаки в 2022 и методы защиты от них

    HTTP-атаки с использованием шифрования (HTTPS Flood)

    В настоящее время практически все разработчики используют в своих приложениях SSL/TLS для шифрования трафика и обеспечения сквозной безопасности при передаче данных. Любая DDoS-атака на приложение, допускающее шифрование, может быть запущена поверх трафика, зашифрованного SSL/TLS, что создает определенные трудности в ее идентификации. Большинство технологий противодействия DoS атакам не производят реальной проверки трафика SSL, так как это требует расшифровки зашифрованных данных.

    WordPress Pingback DDoS

    Определенная популярность есть у Reflection DDoS-атак уровня L7 (приложений). Наиболее характерным примером такой атаки является WordPress Pingback DDoS, которую и рассмотрим.

    Основной её принцип заключается в следующем. Чрезвычайно распространённый web-фреймворк WordPress до определенных версий предоставлял публичное API, позволяющее запросить любую web-страницу с любого удалённого HTTP-сервера без авторизации. Таким образом, отправив небольшой (до 400 байт) запрос на уязвимый WordPress-сервер, можно было инициировать загрузку любой крупной страницы (или файла, если это возможно без авторизации) с атакуемого сервера на уязвимый сервер.

    В ходе такой атаки определённая нагрузка ложится и на уязвимый WordPress-сервер, однако, в силу того, что в нападении участвует несколько тысяч WordPress-серверов и атака разделяется между ними примерно равномерно, нагрузка на каждый отдельный сервер обычно не является критичной и может быть даже не замечена системным администратором на фоне ежедневной средней загрузки. Основная же доля нагрузки приходится именно на атакуемый ресурс.

    Интересно, что эта атака, несмотря на то, что WordPress давно исправил уязвимость была популярна и в 2021, и 2022 г, поскольку в Интернете находилось порядка нескольких миллионов WordPress-серверов, пригодных для эксплуатации в атаке типа WordPress Pingback DDoS, и, как минимум, в ряде инцидентов принимало участие одновременно до 350 тыс. уязвимых серверов. Так как в большинстве случаев фреймворк WordPress развёрнут не на рабочей станции (как обычный модуль бот-сети), а на сервере с неплохой производительностью и канальной ёмкостью, то атаки типа Pingback DDoS на канальном уровне достигали уровня в 10 Гбит/с и более.

    В тоже время, атака типа WordPress Pingback DDoS, организуемая на HTTP-ресурс без шифрования, достаточно легко идентифицируется и несложно фильтруется при наличии достаточной производительности и канальной ёмкости (от 20 Гбит/с).

    Важной особенностью Pingback-атаки является то, что уязвимый сервер в состоянии запрашивать произвольные крупные web-страницы как по HTTP, так и по HTTPS, то есть внутри зашифрованной SSL/TLS-сессии. Это приводит к невозможности фильтрации такой Reflection-атаки при отсутствии адекватных механизмов анализа зашифрованного трафика. Для борьбы с Pingback DDoS в общем случае требуется раскрытие текстовой информации, содержащейся внутри TLS-сессий.

    В целом, не надо думать, что Pingback-атаки характерны только для WordPress. Они могут вылезти на любом приложении, которое позволяет перенаправить запрос (в силу своей архитектурной особенности или ошибок конфигурации). Поэтому, очень важно, при настройке веб-приложений максимально минимизировать возможности запросов для неавторизованных пользователей — особенно это касается той части, которая отвечает за обработку API.

    Full Browser Stack-атаки и имитация поведения пользователя

    Одной из самых сложной для идентификации и фильтрации разновидностью атаки уровня приложения являются, так называемые, FBS‑атаки (от англ. «Full Browser Stack» – полноценная среда браузера). В этом случае для генерации паразитных запросов используются не обычные легковесные библиотеки, имитирующие браузер, а полноценный экземпляр браузера, способный корректно формировать запросы (либо качественный эмулятор), загружать с атакуемого web-сервера изображения и CSS-стили, выполнять HTTP-переадресацию и JavaScript-код. Такую атаку очень сложно отследить и классифицировать, анализируя каждый пакет или каждый запрос в отдельности, поскольку каждый отдельный запрос полностью легитимен и идентичен пользовательскому.

    Для борьбы с такими атаками недостаточно тривиальных проверок наподобие HTTP-редиректов и JavaScript-проверок. Используются, как правило, нестрогие статистические алгоритмы, анализ истории поведения пользователей, поиск закономерностей и мониторинг состояния защищаемого сервера. Подобный анализ, как правило, чрезвычайно вычислительно сложен и подразумевает хранение больших объёмов данных с возможностью быстрого поиска по ним. Таким образом, решение по фильтрации атак уровня приложения (L7-атак) должно быть в состоянии работать с большими объёмами данных в реальном времени.

    Медленные атаки малого объема (Slow and Low)

    DDoS атаки не всегда подразумевают большой объем трафика и бот-сети из сотен узлов. Иногда вполне достаточно даже одного компьютера, чтобы остановить работу сервиса. Существует целый класс атак, направленных на приложения, то есть работающих на L7 (прикладном) уровне модели ISO/OSI, использующих минимум ресурсов. Зачастую бывает вполне достаточно и одного компьютера, используются стандартные принципы работы прикладных протоколов. Но их негативное воздействие оказывается весьма значительным, вплоть до полной остановки работы сервисов.

    Речь идет о медленных атаках небольшого объема («Slow and Low»). Ниже приведены некоторые представители подобного рода атак.

    Are You Dead Yet / RUDY

    Принцип этой атаки базируется на стандартном поведении протокола HTTP при обработке запросов POST.

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

    Когда легитимный пользователь заполняет web-форму, на сайт отправляется всего несколько пакетов, после чего сессия с web-сервером закрывается, ресурсы освобождаются. Сервер готов обслуживать запросы других пользователей. Атакующий, использующий специальный инструмент, например, RUDY (сам инструмент достаточно древний и стал именем нарицательным для подобных инструментов, которые разрабатываются и в 2022), действует иначе. Отправляемые на web-сервер данные разбиваются на множество мелких пакетов, каждый из которых содержит лишь небольшой объем данных, например, один байт. Запросы на сервер отправляются со случайным интервалом, что не дает возможность серверу сразу закрыть сессию, поскольку передача данных еще не завершена.

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

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

    DDoS-атаки в 2022 и методы защиты от них

    Если этот раздел читают «старички в ИБ», то тут наверное они усмехнутся: LOIC, HOIC, HULK, SLOWLORIS — это набор скрипткиддисов, не так ли? 🙂 И зачем раскапывать стюардессу. Но как бы ни так — и инструменты, и методы внезапно ожили в 2021 / 2022 — пруф, к примеру, отчет Radware (ссылка). Поэтому желательно знать принципы таких атак.

    Атака SlowLoris, также как и предыдущая, базируется на стандартном поведении протокола HTTP при обработке запросов. Для закрытия HTTP сессии необходимо прислать соответствующую последовательность.

    Собственно говоря, так и поступает легитимный пользователь. Правильный запрос на получение данных с web-сервера (Get Request) обычно состоит из одного пакета и завершается специальной последовательностью в конце для разрыва сессии.

     Суть атаки заключается в следующем: используя специальный инструмент SlowLoris или подобные, атакующий генерирует множественные подключения к целевому web-серверу, при этом соединения не закрываются, поскольку в запросе будет отсутствовать соответствующая последовательность символов. В результате, ресурсы сервера будут исчерпаны и легитимные пользователи не смогут подключиться. Цель атакующего достигнута – работать с сайтом невозможно. Большой объем трафика или значительное количество пакетов не требуется, чтобы вывести ресурс из строя.

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

    DDoS-атаки в 2022 и методы защиты от них

    Другим характерным примером атаки на приложения, не связанным напрямую с протоколом HTTP, является DNS flood. Организация его не составляет большого труда, что, собственно, и послужило залогом его большого распространения.

    Наверное, на этом стоит закончить длинное описание атак, но нужно упомянуть OWASP (Open Web Application Security Project) — это сообщество ведет периодически обновляемый список OWASP Top 10, в котором перечислены наиболее опасные уязвимости в системе безопасности web-приложений. Использование уязвимостей из этого списка зачастую приводит к различным нарушениям в работе web-приложения либо к его полной остановке, что по сути является DoS.

    Вариант 2.

    толпа
    Представьте, что кому-то вздумалось нарушить автобусное сообщение в городе по определённому маршруту с целью не допустить добросовестных пассажиров к пользованию услугами общественного транспорта. Тысячи ваших друзей единовременно выходят на остановки в начале указанного маршрута и бесцельно катаются во всех машинах от конечной до конечной, пока деньги не кончатся. Поездка оплачена, но никто не выходит ни на одной остановке, кроме конечных пунктов назначения. А другие пассажиры, стоя на промежуточных остановках, грустно смотрят удаляющимся маршруткам вслед, не сумев протолкнуться в забитые автобусы. В прогаре все: и владельцы такси, и потенциальные пассажиры.

    В реальности эти варианты физически не претворить в жизнь. Однако в виртуальном мире ваших друзей могут заменить компьютеры недобросовестных пользователей, которые не удосуживаются хоть как-то защитить свой компьютер или ноутбук. И таких подавляющее большинство. Программ для проведения DDOS атаки множество. Стоит ли напоминать, что такие действия противозаконны. А нелепо подготовленная DDOS атака, неважно с каким успехом проведённая, обнаруживается и карается.

    Как проводится DDOS атака ?

    Кликая по ссылке сайта, ваш браузер отсылает запрос серверу на отображение искомой страницы. Этот запрос выражается в виде пакета данных. И не одного даже, а целого пакета пакетов! В любом случае объём передаваемых данных на канал всегда ограничен определённой шириной. А объём данных, возвращаемых сервером, несоизмеримо больше тех, что содержаться в вашем запросе. У сервера это отнимает силы и средства. Чем более сильный сервер, тем дороже он стоит для владельца и тем дороже предоставляемые им услуги. Современные серверы легко справляются с резко возросшим наплывом посетителей. Но для любого из серверов всё равно существует критическая величина пользователей, которые хотят ознакомиться с содержанием сайта. Тем яснее ситуация с сервером, который предоставляет услуги по хостингу сайтов. Чуть что, и сайт-потерпевший отключается от обслуживания, дабы не перегрузить процессоры, которые обслуживают тысячи других сайтов, находящиеся на том же хостинге. Работа сайта прекращается до момента, когда прекратится сама DDOS атака . Ну, представьте, что вы начинаете перезагружать любую из страниц сайта тысячу раз в секунду (DOS). И тысячи ваших друзей делают на своих компьютерах тоже самое (distributed DOS или DDOS)… Крупные серверы научились распознавать, что началась DDOS атака , и противодействуют этому. Однако хакеры тоже совершенствуют свои подходы. Так что в рамках этой статьи, что такое DDOS атака более развёрнуто, я уже объяснить не смогу.

    Подготовка

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

    Сравнив политику различных облачных сервисов (кто-то безжалостно банит учетную запись, с которой, предположительно, были выполнены действия, приводящие к отказу ресурса) в отношении проведения нагрузочного тестирования с использованием их функционала, мы решили остановиться на Amazon Web Services (AWS). В их документах указано, что AWS допускает проведение нагрузочного тестирования, но просит согласовать его, отправив письмо на определенный адрес.

    Читайте также:  Dns спринтхост
    Оцените статью
    Хостинги