Comments 18
UFO just landed and posted this here
Иван, эти атаки как раз и идут от клиентов провайдера. Такие клиенты обычно заражены всякой дрянью (даже корпоративщики).
То что кэш нужно закрывать от внешних клиентов это истина, которую в принципе не нужно объяснять.
Ссылка в тексте на открытый ресолвер была приведена для того, что показать, что набор портов, которые использует malware — невелик.
Какое используется ПО — не важно, все подвержены атаке, пороги просто будут другие.
То что кэш нужно закрывать от внешних клиентов это истина, которую в принципе не нужно объяснять.
Ссылка в тексте на открытый ресолвер была приведена для того, что показать, что набор портов, которые использует malware — невелик.
Какое используется ПО — не важно, все подвержены атаке, пороги просто будут другие.
Есть такое, пока анализируем логи и прописываем временно у себя такие домены второго уровня. Как бы научить DNS сервер самостоятельно временно блокировать последующие запросы к домену второго уровня, если он ранее не ответил.
Из open source DNS серверов я не знаю, кто может это делать автоматом.
Допилить можно 2-мя способами:
1. в bind есть блок, который отвечает за мониторинг запросов (параметры конфигурации clients-per-query, max-clients-per-query). По умолчанию для статистики рассматриваются FQDN. То есть этот блок нужно допилить так, чтобы статистика ещё считалась по доменам 2-го и 3-го уровня. Для других open source думаю так же можно найти подходящее место для анализа и статистики;
2. автоматизировать процесс анализа запросов и статистики, если, конечно, QPS не очень большой. Например, сервер DNS может отправлять лог-файлы через syslog (как внутри системы, так и на внешний сервер), которые будут сохранятся в БД и периодически (раз в минуту анализироваться). При большей нагрузке (сказать сложно какой именно) можно вешать свою программу на обработку входящего сислог. Если от дополнительной нагрузки (от syslog) у нас перестал справляться DNS, то смотрим пункт 1 :)
Допилить можно 2-мя способами:
1. в bind есть блок, который отвечает за мониторинг запросов (параметры конфигурации clients-per-query, max-clients-per-query). По умолчанию для статистики рассматриваются FQDN. То есть этот блок нужно допилить так, чтобы статистика ещё считалась по доменам 2-го и 3-го уровня. Для других open source думаю так же можно найти подходящее место для анализа и статистики;
2. автоматизировать процесс анализа запросов и статистики, если, конечно, QPS не очень большой. Например, сервер DNS может отправлять лог-файлы через syslog (как внутри системы, так и на внешний сервер), которые будут сохранятся в БД и периодически (раз в минуту анализироваться). При большей нагрузке (сказать сложно какой именно) можно вешать свою программу на обработку входящего сислог. Если от дополнительной нагрузки (от syslog) у нас перестал справляться DNS, то смотрим пункт 1 :)
Ув. Homas, на ваш взгляд, какой смысл злоумышленнику выводить из строя кэширующий сервер из внутренней сети провайдера? Какова его цель, чего он хочет добиться?
В данный момент лично мне кажется, что авторы malware реализуют данную атаку для чего-то другого, например, с целью облегчить задачу cache poisoning на атакуемом сервере. Можете подтвердить это?
В данный момент лично мне кажется, что авторы malware реализуют данную атаку для чего-то другого, например, с целью облегчить задачу cache poisoning на атакуемом сервере. Можете подтвердить это?
И вдогонку вопрос: а на кого направлены Reflection-атаки, если сервер закрыт от внешних клиентов? Внутрь сети? Или на сам кэширующий сервер (тогда мы возвращаемся к первому вопросу)?
Reflection атака (эффективна в сочетании с Amplification) нацелена на определенный IP (сайт, сервер). Этот IP может находится в пределах сети ISP или за её пределами. DNS-запросы поступают от клиентов этого ISP. Проблемы начинаются тогда, когда оператор не контролирует какие пакеты уходят из его сети/сегментов сети, то есть атакующий может заспуфить IP и его кэш начнет отвечать на адрес 8.8.8.8, который нашей сети не принадлежит.
Весной 2013 года проходила конференция Yandex, где приводились цифры, что 25% провайдеров (или сетей, уже не помню) не контролируют исходящие пакеты из своей сети.
Дополнительные угрозы состоят в том, что клиенты оператора не всегда защищают свои устройства предоставляющие услуги DNS (например маршрутизаторы). Осенью я сканировал /16 своего провайдера и обнаружил в ней 70 открытых рекурсивных DNS серверов (доступность из внешнего мира я проверял со своего сервера в Германии).
Весной 2013 года проходила конференция Yandex, где приводились цифры, что 25% провайдеров (или сетей, уже не помню) не контролируют исходящие пакеты из своей сети.
Дополнительные угрозы состоят в том, что клиенты оператора не всегда защищают свои устройства предоставляющие услуги DNS (например маршрутизаторы). Осенью я сканировал /16 своего провайдера и обнаружил в ней 70 открытых рекурсивных DNS серверов (доступность из внешнего мира я проверял со своего сервера в Германии).
Если вы про hetzner, то с тех пор не так уж и много поменялось…
Вы же говорите, что доступ к серверу от внешних клиентов был закрыт. Тогда сервер просто не должен был отвечать на reflection-запросы, потому что source IP у них из внешней сети. Или доступ был только на внешнем интерфейсе закрыт, а ограничений по source IP запроса не было?
Да, вы правы. Ещё не проснулся утром :).
Reflection только внутри сети, acl нужно и на кэше прописывать.
Reflection только внутри сети, acl нужно и на кэше прописывать.
Ну вот :-) Тогда не очень понятно, зачем нужен Reflection внутри приватной сети провайдера. Кого этой атакой вышибать-то? Домашних абонентов?
Внутри провайдерской сети единственная (ну хорошо, почти единственная) осмысленная атака на DNS (если он наружу не выглядывает) — это как раз cache poisoning или DNS answer spoofing различными методиками. Всё остальное создаст проблемы исключительно внутри закрытой сети, но не снаружи. А изнутри сети и так можно много чего сделать, DNS для этой цели, конечно, тоже можно использовать, но это выглядит как overkill.
В то же время cache poisoning — это реальная и серьёзная проблема. Я прямо сейчас смотрю на 40-тысячный китайский ботнет, целиком построенный на cache poisoning внутри нескольких провайдерских сетей. И для таких атак 40 тысяч IP-адресов (которые, причём, из NAT-пула, то есть за ними ещё раз в 5 больше физических машин) — это не предел.
Внутри провайдерской сети единственная (ну хорошо, почти единственная) осмысленная атака на DNS (если он наружу не выглядывает) — это как раз cache poisoning или DNS answer spoofing различными методиками. Всё остальное создаст проблемы исключительно внутри закрытой сети, но не снаружи. А изнутри сети и так можно много чего сделать, DNS для этой цели, конечно, тоже можно использовать, но это выглядит как overkill.
В то же время cache poisoning — это реальная и серьёзная проблема. Я прямо сейчас смотрю на 40-тысячный китайский ботнет, целиком построенный на cache poisoning внутри нескольких провайдерских сетей. И для таких атак 40 тысяч IP-адресов (которые, причём, из NAT-пула, то есть за ними ещё раз в 5 больше физических машин) — это не предел.
Зачем — цели могут быть разные, начиная с того, что нужно навредить клиентам этого провайдера (по услугам Internet, хостинг, хостин DNS) и заканчивая общим вредом инфраструктуре провадера (обиженный клиент, сотрудник, конкурент).
Я знаю пример, когда студент (дело было в Штатах) не хотел сдавать экзамен и поэтому организовывал атаку (арендовал ботнет) на сеть колледжа.
Я знаю пример, когда студент (дело было в Штатах) не хотел сдавать экзамен и поэтому организовывал атаку (арендовал ботнет) на сеть колледжа.
Цели могут быть разные начиная от заказа конкурентов и заканчивая общей политической ситуацией, когда атакуют всех.
По поводу cache poisoning, на первый взгляд задача не упрощается (для атаки используются левые домены), так как помимо атакующих запросов остаются все остальные запросы.
Если для атаки используется какой-то легитимный домен, то тут уже можно рассматривать и cache poisoning и NXDomain атаку на авторитативный сервер.
По поводу cache poisoning, на первый взгляд задача не упрощается (для атаки используются левые домены), так как помимо атакующих запросов остаются все остальные запросы.
Если для атаки используется какой-то легитимный домен, то тут уже можно рассматривать и cache poisoning и NXDomain атаку на авторитативный сервер.
Если ваш сервер перестаёт отвечать на запросы клиентов, то, как минимум, упрощается задача подсовывания поддельных ответов клиентам. Дальше надо смотреть на параметры и поведение сервера, возможно, «отравить» можно и его.
Заказ конкурентов, мне кажется, маловероятен — уж больно много труда ради столь малой отдачи. Должна быть какая-то иная причина.
Кстати, а 100 запросов/с — это скорость всех ботов суммарно, так? А у каждого в отдельности какая скорость?
Заказ конкурентов, мне кажется, маловероятен — уж больно много труда ради столь малой отдачи. Должна быть какая-то иная причина.
Кстати, а 100 запросов/с — это скорость всех ботов суммарно, так? А у каждого в отдельности какая скорость?
Когда пытаются отравить кэш, то делают это на уровне организации/провайдера. Каждому конкретному клиенту (если это не целенаправленная жертва) смысла отравлять кэш нет, так как требуется много ресурсов.
По поводу заказа конкурентов — труда не много:
1. Сеть ботнетов для проведения атаки арендуется достаточно дешево. Вот пример по стоимости аренды сети botnet (цены указаны на 2013):
www.havocscope.com/how-to-ddos-by-renting-botnet/
2. На устройствах клиентов оператора помимо дыры с открытым ресолвером может быть настроен forwarding — запросов на сервер провайдера (проверить достаточно просто, послав запрос на свой DNS). Просканировать сети операторов на открытые ресолверы дело нескольких минут/десятков минут;
3. Провести «вирусную» акцию например, попросить установить «исследовательский» софт за небольшие деньги (от 1 цента до 1 доллара). Есть на эту тему исследование «An empirical study on incentivizing users to ignore security advice»
Стандартные настройки bind 9.10 — 1000 исходящих запросов в секунду и время таймаута 10 секунд (кол-во исходящих запросов можно увеличить, таймаут уменьшить нельзя). То есть чтобы забить все исходящие соединения нам нужно генерировать по 100 запросов в секунду всего. Кол-во запросов в секунду от каждого бота в принципе не важно, но чем больше будет зараженных систем, тем сложнее их отсечь на уровне query rate limit. Я посмотрел в одном pcap (атака была на минимальном уровне), каждый зараженный компьютер генерировал около 5 паразитных запросов в секунду
По поводу заказа конкурентов — труда не много:
1. Сеть ботнетов для проведения атаки арендуется достаточно дешево. Вот пример по стоимости аренды сети botnet (цены указаны на 2013):
www.havocscope.com/how-to-ddos-by-renting-botnet/
The price to rent 1,000 infected computers in the United States costs $180. If the hosts are located in the United Kingdom, the price is $240. France and Russia both costs $200, Canada costs $270, and 1,000 infected computers located around the world costs $35. There is a daily limit of 20,000 hosts.
2. На устройствах клиентов оператора помимо дыры с открытым ресолвером может быть настроен forwarding — запросов на сервер провайдера (проверить достаточно просто, послав запрос на свой DNS). Просканировать сети операторов на открытые ресолверы дело нескольких минут/десятков минут;
3. Провести «вирусную» акцию например, попросить установить «исследовательский» софт за небольшие деньги (от 1 цента до 1 доллара). Есть на эту тему исследование «An empirical study on incentivizing users to ignore security advice»
Стандартные настройки bind 9.10 — 1000 исходящих запросов в секунду и время таймаута 10 секунд (кол-во исходящих запросов можно увеличить, таймаут уменьшить нельзя). То есть чтобы забить все исходящие соединения нам нужно генерировать по 100 запросов в секунду всего. Кол-во запросов в секунду от каждого бота в принципе не важно, но чем больше будет зараженных систем, тем сложнее их отсечь на уровне query rate limit. Я посмотрел в одном pcap (атака была на минимальном уровне), каждый зараженный компьютер генерировал около 5 паразитных запросов в секунду
> Каждому конкретному клиенту (если это не целенаправленная
> жертва) смысла отравлять кэш нет, так как требуется много ресурсов.
Если знать, какое именно доменное имя подменять, ресурсов требуется намного меньше :-)
> Сеть ботнетов для проведения атаки арендуется достаточно дешево.
Да, но чтобы атаковать конкурента описанным образом, вам нужно арендовать ботнет строго внутри сети этого конкурента. А это куда сложнее, чем арендовать просто абстрактный русский или канадский ботнет. Чисто эмпирически я даже не уверен, что это возможно — вряд ли злоумышленник захочет раскрывать вам IP-адреса ботнета до того, как получит деньги, ему это опасно и невыгодно.
> Провести «вирусную» акцию например, попросить установить
> «исследовательский» софт за небольшие деньги (от 1 цента до 1 доллара).
Сотрудники БСТМ МВД РФ лично скажут злоумышленнику спасибо за такую акцию, они подобные атаки щёлкают как орехи :-)
DDoS-атаки, конечно, в подавляющем большинстве случаев вызваны как раз конкуренцией, и разумно подозревать конкурентов в желании насолить, но всё-таки меня этот случай заинтересовал как раз потому, что мне кажется, что здесь что-то другое. Я потому и спрашивал про рейт запросов от одного бота: если он составляет менее 1 запроса в 2-3 секунды, то это может быть, например, поиск командного центра по детерминированному алгоритму, или ещё что-нибудь в этом духе.
> жертва) смысла отравлять кэш нет, так как требуется много ресурсов.
Если знать, какое именно доменное имя подменять, ресурсов требуется намного меньше :-)
> Сеть ботнетов для проведения атаки арендуется достаточно дешево.
Да, но чтобы атаковать конкурента описанным образом, вам нужно арендовать ботнет строго внутри сети этого конкурента. А это куда сложнее, чем арендовать просто абстрактный русский или канадский ботнет. Чисто эмпирически я даже не уверен, что это возможно — вряд ли злоумышленник захочет раскрывать вам IP-адреса ботнета до того, как получит деньги, ему это опасно и невыгодно.
> Провести «вирусную» акцию например, попросить установить
> «исследовательский» софт за небольшие деньги (от 1 цента до 1 доллара).
Сотрудники БСТМ МВД РФ лично скажут злоумышленнику спасибо за такую акцию, они подобные атаки щёлкают как орехи :-)
DDoS-атаки, конечно, в подавляющем большинстве случаев вызваны как раз конкуренцией, и разумно подозревать конкурентов в желании насолить, но всё-таки меня этот случай заинтересовал как раз потому, что мне кажется, что здесь что-то другое. Я потому и спрашивал про рейт запросов от одного бота: если он составляет менее 1 запроса в 2-3 секунды, то это может быть, например, поиск командного центра по детерминированному алгоритму, или ещё что-нибудь в этом духе.
1. Да, вполне логично. Просто цена за такую аренду будет выше. IP-адреса никому передавать не надо. Клиент платит не за IP, а за атаку. Все сети европейских провайдеров есть в БД RIPE, которая находится в свободном доступе. Владелец сети ботнет 100% знает какие провайдеры заражены.
2. Когда botnet/malware ищет командный центр, имхо, светиться ему никакого смысла нет. 1 запрос в 2-3 секунды будут маловаты для проведения атаки (конечно если в сети провайдера не тысяча таких зловредов). В собранном трафике (это были часы средней нагрузки) за 5 минут было обнаружено от 30 до 80 атакующих IP (в разных pcap по разному).
2. Когда botnet/malware ищет командный центр, имхо, светиться ему никакого смысла нет. 1 запрос в 2-3 секунды будут маловаты для проведения атаки (конечно если в сети провайдера не тысяча таких зловредов). В собранном трафике (это были часы средней нагрузки) за 5 минут было обнаружено от 30 до 80 атакующих IP (в разных pcap по разному).
Sign up to leave a comment.
Случайные и фантомные домены (random subdomain, phantom domain), DDoS атака на кэширующий DNS