Комментарии 40
Очень часто встречаю
«запрос с поддельным IP-адресом отправителя»
и всегда возникает вопрос — как? как они такое делают?
Разве ДЦ не проверяют на принадлежность их сети IP отправителя? А интернет провайдеры?
«запрос с поддельным IP-адресом отправителя»
и всегда возникает вопрос — как? как они такое делают?
Разве ДЦ не проверяют на принадлежность их сети IP отправителя? А интернет провайдеры?
Я не сетевик, но попробую ответить.
NTP использует в качестве транспорта UDP, который не устанавливает соединения. Т.е. у конечного получателя нет способа проверить отправителя.
У некрупного провайдера вряд ли будет много подключений, и нельзя будет фильтровать входящий пакет по тому, откуда он пришел.
Существует рекомендация (BCP 38) провайдерам фильтровать исходящие пакеты их клиентов и зарезать пакеты с поддельным IP.
NTP использует в качестве транспорта UDP, который не устанавливает соединения. Т.е. у конечного получателя нет способа проверить отправителя.
У некрупного провайдера вряд ли будет много подключений, и нельзя будет фильтровать входящий пакет по тому, откуда он пришел.
Существует рекомендация (BCP 38) провайдерам фильтровать исходящие пакеты их клиентов и зарезать пакеты с поддельным IP.
Позвольте вас поправить. Провайдер вполне себе может фильтровать _входящий_ пакет от своего абонента и отбрасывать все то, что не принадлежит к его сети (начиная от банального ACL по source, и продолжая, к примеру, uRPF — www.cisco.com/web/about/security/intelligence/unicast-rpf.html).
Но я думаю вопрос bimcom был о том, почему провайдеры это не делают? Это уже вопрос к конкретным провайдерам, которые позволяют spoofed трафик из своих сетей и единого ответа, боюсь, нет.
Но я думаю вопрос bimcom был о том, почему провайдеры это не делают? Это уже вопрос к конкретным провайдерам, которые позволяют spoofed трафик из своих сетей и единого ответа, боюсь, нет.
Ну я это примерно и имел в виду в последнем предложении.
Найти датацентр, где возможен ip spоofing — это еще надо постараться. На роутере фильтруется ip отправителя в заголовке, и пакет не уходит. Бывает, что в схему вовлечен сам провайдер, который пропускает пакеты с подмененным ip от определенного клиента.
Постараться можно. Помимо датацентров, которые позволяют любой трафик, есть еще и пользователи доступа, и т.д. Если бы найти такого провайдера было сложно — мы бы с вами вообще не беспокоились про ip spoofing и баг, упомянутый в статье, в частности.
Печально, но в популярном Hetzner и Leaseweb на наших серверах смогли воспользоваться этой уязвимостью. Заметили мы это только потому что резко вырос UDP трафик
Вас атаковали извне хетзнера и воспользовались открытой дырой на вашем сервере. Хетзнер 100% не выпускает ip spoofing.
Хороший провайдер конечно проверяет сорс адрес входящего от абонента пакета ( это одна команда на оборудовании — если сорс влетающего в интерфейс пакета ни из той сети, что висит на интерфейсе — то дропать). Не все делают, и это грустно. А вот то что такие дыры (возможности в протоколах, которые включены по дефолту) до сих пор есть в софте — это печально. Некоторые Днс сервера так по дефолту при устанловке настроенны отвечать всем и про всё — это тоже бред, но не квалифицированным админам нравится — поставил и забыл.
Спасибо, закрыл дырку у себя. Более того, я и не знал, что мой NTP-сервер пользуется такой сумасшедшей популярностью, учитывая, что его адрес знаю только я (как мне казалось).
Вы еще в логи ssh посмотрите повнимательнее, если он у вас наружу висит — тоже много нового для себя узнаете.
учитывая, что его адрес знаю только я (как мне казалось).
Мир IPv4 — тесен, можно за несколько минут просканировать на нужный порт.
blog.erratasec.com/2013/09/masscan-entire-internet-in-3-minutes.html
В CentOS по умолчанию прописан
restrict 127.0.0.1 (аналогично для ipv6).
У меня так домашний Mikrotik был напрочь изнасилован тысячами клиентов, которые как-то его нашли. Забивали половину канала. Не задумывался об этом. Теперь правило firewall блокирует доступ к ntp извне. Подскажите, а как это расползается вообще? Что-то вроде DHT? Напомнило муравейник и кусок еды. Один нашел и сразу все дорожку протоптали.
Ну, вероятно, есть ботнет, который в распределенном и неторопливом режиме сканит весь инет посылая правильные ntp-сообщения (при этом каждый конкретный бот делает это не слишком часто и не на соседние адреса, а по нахождении — публикует результат в шифрованном виде в каком-нибудь распределенном хранилище). Потом другие боты это дешифруют и используют. Как-то так, вероятно…
Если не ошибаюсь, то в RouterOS при начальной настройке в правилах файрвола запрещены все новые подключения «снаружи». По идее такое возможно только в случае, если вы шаманили с файрволом. У простых пользователей не должна возникать такая проблема. :)
Я видывал контр-страйк атаки примерно такого же вида примерно на 2-3 гигабита. Запрашивали список то ли игроков, то ли сессий с cs-серверов в интернете.
Всё осложнялось тем, что валв отдаёт список cs серверов, то есть ddos-атаку легко координировать.
Всё осложнялось тем, что валв отдаёт список cs серверов, то есть ddos-атаку легко координировать.
Хостимся у hetzner, мне написали из поддержки что мой сервак таким образом проэксплуатировали, закрыл дырку в тот же день. Это было как раз 4-5 дней назад.
На январских праздниках приходила абуза от хостера, атаковали чьи-то игровые сервера. Оказалось виноват ESXi 4.1 с установками по умолчанию (ставил сам хостер!). Написал в блог howto с картинками как полечить: How to prevent malicious usage of VMware ESXi in NTP reflection attacks
Пикантная подробность: данная уязвимость была исправлена в релизе ntp 4.2.7p26, выпущенном в первой половине 2010 года. Действительно, самое время кому-то обновиться.
С непубличным ntpd всё достаточно просто — restrict default ignore, открыть только нужные, и без разницы, какая версия.
Я столкнулся с куда более серьёзной проблемой — куча открытых ntpd и рекурсивных dns у моих клиентов (я провайдер).
Попытка обзвона ничего не дала — большинство вообще не понимает, о чём речь.
В итоге решил проблему просто — 100 килобит исходящего udp с портов 53 и 123 с каждого клиента.
Нормальной работе обоих протоколов никак не помешает (ну разве что кроме случая реального высоконагруженного публичного сервера у клиента, но таковых нет). А флуд невозможен — упрётся в шейп и всё.
Я столкнулся с куда более серьёзной проблемой — куча открытых ntpd и рекурсивных dns у моих клиентов (я провайдер).
Попытка обзвона ничего не дала — большинство вообще не понимает, о чём речь.
В итоге решил проблему просто — 100 килобит исходящего udp с портов 53 и 123 с каждого клиента.
Нормальной работе обоих протоколов никак не помешает (ну разве что кроме случая реального высоконагруженного публичного сервера у клиента, но таковых нет). А флуд невозможен — упрётся в шейп и всё.
FastVPS — реселлер Hetzner в России, прислал вот такое малопонятное письмо с угрожающей темой. Хотел бы послать их (я не знал, что во FreeBSD ntpd доступен снаружи), но нашел этот пост.
Здравствуйте, Денис!
В адрес Вашего сервера поступила жалоба:
We have received spam/abuse notification from certbund@bsi.bund.de.
Please take the necessary steps to prevent this from happening again in future.
Furthermore, we would request that you provide both ourselves and the person who has submitted this complaint with a short statement within 24 hours. This statement should include details of the events leading up to the incident and the steps you are taking to deal with it.
Various blog posts have been reporting on a new way of NTP server misuse
and abuse. This abusive use can cause a more reflected and intense
denial-of-service attack to be performed.
An update to Version 4.2.7 or higher is recommended. Amplifier is the term
given to an attack based on the ratio of a small request (1 UDP package)
to a very large reply (max. 600 IP addresses). The feature has been actively
exploited for DDoS attacks since December 2013.
Information regarding the vulnerability with reference to your products
is available from Meinberg, HP and Juniper.
If an update to Version 4.2.7 or higher is not possible, the option «noquery»
can be set in the configuration file which takes effect once the service is
restarted and prevents the request from being processed.
As the German authority responsible for IT security, the BSI has obtained
details of German NTP server IP addresses.
We are offering you these details for your IP address area. You have the
possibility of using the enclosed details to inform your customers.
The log data shows the following data fields:
— ASNno: added based on IP address via Cymru's services
— IP: ip v4 address at the time of the timestamp, which responded to the
vulnerable NTP request
— Timestamp: the date and time of the request
— Country/gTLD: added via geoip databases
— ASNname: added based on IP address via Cymru's services
— Port: is 123 for the UDP transport protocol, UDP is not given but implied
Further information:
[1] Short Info CB-K14/0020 Update 2 — NTP: Misuse of monlist command enables
denial-of-service attack
www.cert-bund.de/advisoryshort/CB-K14-0020%20UPDATE%202
[2] DRDoS / Amplification Attack using ntpdc monlist command
support.ntp.org/bin/view/Main/SecurityNotice#DRDoS_Amplification_Attack_using
[3] Understanding and mitigating NTP-based DDoS attacks
blog.cloudflare.com/understanding-and-mitigating-ntp-based-ddos-attacks
[4] DDoS via NTP-Reflection (deutsch)
www.cert.at/services/blog/20140108163933-1003.html
[5] Vulnerability Summary for CVE-2013-5211
web.nvd.nist.gov/view/vuln/detail?vulnId=CVE-2013-5211
[6] NTP can be abused to amplify denial-of-service attack traffic
www.kb.cert.org/vuls/id/348126
[7] Secure NTP Template
www.team-cymru.org/ReadingRoom/Templates/secure-ntp-template.html
— Kind regards from Team CERT-Bund
Просьба проверить выше изложенный материал, разобраться в проблеме и сообщить нам о принятых действиях.
Мы ждем Вашего ответа в течение 12 часов.
C уважением, специалист службы поддержки FastVPS LLC
Дмитрий Скаленко
Да. Спасибо за публикацию!
Зарегистрируйтесь на Хабре, чтобы оставить комментарий
Атака с помощью вашего сервера времени: NTP amplification attack (CVE-2013-5211)