amarao (amarao_san) wrote,
amarao
amarao_san

Category:

Поведение dns-ресолвера при неответе NS'а

Вариант DNS-атаки.

Схема следующая:

A.foo1.org. IN NS AVictim
AVictim IN A vi.c.ti.m
A.foo1.org. IN NS A.foo2.org.

A.foo2.org. IN NS AVictim
AVictim IN A vi.c.ti.m
A.foo2.org IN NS B.foo1.org.

B.foo1.org. IN NS AVictim
AVictim IN A vi.c.ti.m
B.foo1.org. IN NS B.foo2.org.

B.foo2.org. IN NS AVictim
AVictim IN B vi.c.ti.m
B.foo2.org IN NS B.foo1.org.

.....
Z.foo.org IN A nor.mal.i.p

Насколько я понимаю, рекурсивные ресолверы не запоминают RST и таймауты. Таким образом, если мы выстроим цепочку достаточно длинной, то единичная рекурсивная кверя нас заставит N раз (в примере выше - 50) обратиться на IP жертвы.

Если TTL зон будет маленький, то почти каждый запрос будет вызывать ресолвинг. Плюс, каждый отдельный ресолвер будет делать всё сам, то есть если разместить ссылку на популярном ресурсе, где Z.foo.org содержит картику с котятами, то каждый клиент, который увидит картинку, вызовет 50 запросов на адрес атакуемого. Часть запросов закешируется, но TTL 1 отлично снижает процент кеширования.

Помимо котиков, в списке "используемых" систем: почтовые (HELO re.solve.me.please.com), IRC (finger), любые веб-интерфейсы, принимающие URL и ресолвящие его (looking glass, openid, etc).

Особенности атаки:
* Легитимные запросы
* Разные источники
* Маленький размер пакета

Ослабляющие особенности:
* Атакующему придётся отвечать на DNS запросы, причём даже чуть больше, чем пакетов уйдёт на атакуемого. Однако, отвечающие системы могут размещаться на всяких DNS-хостингах, что делает стоимость атаки незначительной. Плюс, атака может быть сильно распределённой, то есть разные доменные имена (2-3-4 и т.д. уровней).

Частично это можно решить, указав несколько IP нескольких жертв в виде фальшивых AVictim записей, в этом случае одна атака может происходить сразу на несколько узлов без увеличения нагрузки на DNS-хостинг со стороны атакующего.

Размер пакета для атаки сильно зависит от размера имени. В принципе, 100-120 байт на запрос вполне достижимо. Для дальнейшего положим, что размер пакета - 100 байт. При 50 запросах на query это даёт 50кб (400 килобит) атакующего трафика на запрос. Для выключения гигабитного порта нам надо прислать туда примерно 600-800 мегабит (врят ли кто-то с трафиком в 1 мегабит имеет гигабитный порт, да ещё и с гигабитным аплинком). Это всего навсего 1500-2000 запросов в секунду. Для понимания, powerdns способен обрабатывать до 80к запросов в секунду на одном ядре.

Отвечая на вопрос: зачем так сложно. Потому что если узел A пришлёт узлу Б каку, то узел А быстро внесут в блеклист. Если узел А начнёт слать узлу Б каку записав фальшивый адрес в SRC, то его быстро найдут и укорят. А вот прописать всякую херню в NS можно без всяких последствий для. И, что интересно, при наличии API у DNS-хостеров, можно делать с узкого канала.

Возникает вопрос - а где мы возьмём две тысячи запросов в секунду? Их можно собрать, размещая контент на Z.foo1.org на куче сайтов. Сам Z.foo1.org вовсе не обязан быть живым сайтом, это может быть cname на хостинг картинок, в крайнем случае, nginx с редиректами.

Выглядит слабо. Но, основное тут - совершенная легитимность каждой из операций и проблема ликвидации в разумные сроки. Потому что тот, кто контролирует NS от foo1.org контролирует всё последующее, и обороть его нормальными средствами невозможно (разве что поставить свой DNS и отвечать что-то не то на запрос NS для A.foo2.org, но это легко может быть изменено злоумышленником на другое имя - с тем же успехом).
Subscribe

  • systemd-networkd, netlink и arp флуд

    Нереально странный баг пофикшен с помощью eBPF затычки. Для меня большой неожиданностью является реакция на него.…

  • Rust soundness

    Каждый раз, когда я сталкиваюсь с маленькими "но" в Rust'е, это ощущение тщательной продуманности. Например, простейшие fold-функции для итераторов:…

  • still_ntp

    В ходе локального мозгового штурма у меня родилась суперидея. Надо написать ntp сервер, который может отдавать указанную дату. Т.е. сказали при…

  • Post a new comment

    Error

    default userpic

    Your IP address will be recorded 

    When you submit the form an invisible reCAPTCHA check will be performed.
    You must follow the Privacy Policy and Google Terms of use.
  • 1 comment