0,0
рейтинг
17 января 2014 в 16:14

Разработка → Атака с помощью вашего сервера времени: NTP amplification attack (CVE-2013-5211)

13 января Компьютерная команда экстренной готовности США (US-CERT) выпустила предупреждение о новом способе DDoS-атак. Зараженные компьютеры отправляют запрос monlist с поддельным IP-адресом отправителя к NTP-серверу. Запрос monlist возвращает список из последних 600 клиентов ntpd. Таким образом, небольшим запросом от зараженного компьютера к жертве отправляется большой поток UDP. В этом и заключается сущность амплификации.

Незащищенный NTP-сервер становится невольным промежуточным звеном атаки.
Атаке подвержены версии ntpd до 4.2.7p26 (стабильная сейчас 4.2.6p5).

Проверить свой сервер на уязвимость можно выполнив команду
ntpdc -c monlist адрес_сервера
Если команда выдает список клиентов (а не «timed out, nothing received»), значит система уязвима.

Устранение

Как минимум 3 способа:
1) Обновить ntpd до версии 4.2.7p26. В FreeBSD обновите порты и установите ntpd из net/ntp-devel.

Без обновления можно:
2) Отключить monlist в ntp.conf, добавив строчку
disable monitor

3) Или отключить любые запросы статуса сервера в restrict default
restrict default kod nomodify notrap nopeer noquery
restrict -6 default kod nomodify notrap nopeer noquery


Возможно, вы вообще не знали, что ваш NTP-сервер виден наружу (-:. Тогда отключите доступ к нему полностью.

Я столкнулся с этой проблемой еще в ноябре, когда NTP-трафик на моем публичном NTP stratum1.net стал 30Гб в час. Заметил я это не сразу, т.к. даже на процессоре Atom загрузка была менее 5%. Тогда я написал bash-скрипт, который смотрел статистику трафика граничного брандмауэра за последние полчаса (через netflow) и автоматически добавлял правило deny для слишком активных клиентов. И вот через два месяца стало понятно, что это было.

Источники:


support.ntp.org/bin/view/Main/SecurityNotice#DRDoS_Amplification_Attack_using
www.kb.cert.org/vuls/id/348126
www.opennet.ru/opennews/art.shtml?num=38855

P.S. В недавнем топике был описан частный случай атаки vmware esxi.
Владислав Росс @gag_fenix
карма
169,8
рейтинг 0,0
Программист
Реклама помогает поддерживать и развивать наши сервисы

Подробнее
Спецпроект

Самое читаемое Разработка

Комментарии (40)

  • 0
    Очень часто встречаю
    «запрос с поддельным IP-адресом отправителя»
    и всегда возникает вопрос — как? как они такое делают?
    Разве ДЦ не проверяют на принадлежность их сети IP отправителя? А интернет провайдеры?
    • 0
      Я не сетевик, но попробую ответить.
      NTP использует в качестве транспорта UDP, который не устанавливает соединения. Т.е. у конечного получателя нет способа проверить отправителя.
      У некрупного провайдера вряд ли будет много подключений, и нельзя будет фильтровать входящий пакет по тому, откуда он пришел.
      Существует рекомендация (BCP 38) провайдерам фильтровать исходящие пакеты их клиентов и зарезать пакеты с поддельным IP.
      • 0
        Позвольте вас поправить. Провайдер вполне себе может фильтровать _входящий_ пакет от своего абонента и отбрасывать все то, что не принадлежит к его сети (начиная от банального ACL по source, и продолжая, к примеру, uRPF — www.cisco.com/web/about/security/intelligence/unicast-rpf.html).
        Но я думаю вопрос bimcom был о том, почему провайдеры это не делают? Это уже вопрос к конкретным провайдерам, которые позволяют spoofed трафик из своих сетей и единого ответа, боюсь, нет.
        • 0
          Ну я это примерно и имел в виду в последнем предложении.
        • 0
          Найти датацентр, где возможен ip spоofing — это еще надо постараться. На роутере фильтруется ip отправителя в заголовке, и пакет не уходит. Бывает, что в схему вовлечен сам провайдер, который пропускает пакеты с подмененным ip от определенного клиента.
          • 0
            Постараться можно. Помимо датацентров, которые позволяют любой трафик, есть еще и пользователи доступа, и т.д. Если бы найти такого провайдера было сложно — мы бы с вами вообще не беспокоились про ip spoofing и баг, упомянутый в статье, в частности.
          • 0
            Печально, но в популярном Hetzner и Leaseweb на наших серверах смогли воспользоваться этой уязвимостью. Заметили мы это только потому что резко вырос UDP трафик
            • 0
              Вас атаковали извне хетзнера и воспользовались открытой дырой на вашем сервере. Хетзнер 100% не выпускает ip spoofing.
              • 0
                Хороший провайдер конечно проверяет сорс адрес входящего от абонента пакета ( это одна команда на оборудовании — если сорс влетающего в интерфейс пакета ни из той сети, что висит на интерфейсе — то дропать). Не все делают, и это грустно. А вот то что такие дыры (возможности в протоколах, которые включены по дефолту) до сих пор есть в софте — это печально. Некоторые Днс сервера так по дефолту при устанловке настроенны отвечать всем и про всё — это тоже бред, но не квалифицированным админам нравится — поставил и забыл.
                • 0
                  Все эти протоколы: IP, TCP, UDP, DNS и так далее разработаны в мохнатые 80-е годы, т.е. еще до грехопадения, когда не было ни хакеров, ни DDoS.
                  • 0
                    согласен, всё это мериканскоИнституское легаси; )
                    • 0
                      Ага, эти протоколы разрабатывались для университетских и военных сетей, а сейчас используются для сетей общего пользования.
  • 0
    Спасибо, закрыл дырку у себя. Более того, я и не знал, что мой NTP-сервер пользуется такой сумасшедшей популярностью, учитывая, что его адрес знаю только я (как мне казалось).
    • 0
      Вы еще в логи ssh посмотрите повнимательнее, если он у вас наружу висит — тоже много нового для себя узнаете.
      • 0
        Частично решается нестандартными портами типа 55023
        • +1
          Угу, и запретом на password-авторизацию до кучи.
          • 0
            Каюсь — парольный использую. Удобно. Ключи у меня между серверами моими для передачи файлов через ssh-туннели. Типа залить по rsync отцу на его сервер свежие фотографии внука.
    • 0
      учитывая, что его адрес знаю только я (как мне казалось).

      Мир IPv4 — тесен, можно за несколько минут просканировать на нужный порт.
      blog.erratasec.com/2013/09/masscan-entire-internet-in-3-minutes.html
    • 0
      В CentOS по умолчанию прописан restrict 127.0.0.1 (аналогично для ipv6).
      • 0
        Эта строчка сама по себе ничего не запрещает. Там дефолтная политика «разрешить все», и эта строчка к этой политике добавляет еще и запись «разрешить с 127.0.0.1».

        А вот так — ок:
        restrict default ignore restrict 127.0.0.1
        • 0
          Выше там только restrict default kod nomodify notrap nopeer noquery, разрешающая всем остальным только спрашивать время. Т. е. статус не отдается.
  • 0
    У меня так домашний Mikrotik был напрочь изнасилован тысячами клиентов, которые как-то его нашли. Забивали половину канала. Не задумывался об этом. Теперь правило firewall блокирует доступ к ntp извне. Подскажите, а как это расползается вообще? Что-то вроде DHT? Напомнило муравейник и кусок еды. Один нашел и сразу все дорожку протоптали.
    • 0
      Ну, вероятно, есть ботнет, который в распределенном и неторопливом режиме сканит весь инет посылая правильные ntp-сообщения (при этом каждый конкретный бот делает это не слишком часто и не на соседние адреса, а по нахождении — публикует результат в шифрованном виде в каком-нибудь распределенном хранилище). Потом другие боты это дешифруют и используют. Как-то так, вероятно…
      • 0
        То есть это ненормальная ситуация, когда находят мой нигде не опубликованный сервер? Я просто думал это какой-то вариант самоорганизации сети. Типа DHT. Предположил, что до меня канал лучше и чьи-то запросы попадали ко мне как к ближайшему.
        • 0
          Почему ненормально? Если сервер общается с внешним миром, то его IP элементарно увидеть. Дальше portscan по всем найденным IP или вообще по всей подсети.
    • 0
      Если не ошибаюсь, то в RouterOS при начальной настройке в правилах файрвола запрещены все новые подключения «снаружи». По идее такое возможно только в случае, если вы шаманили с файрволом. У простых пользователей не должна возникать такая проблема. :)
      • 0
        Нет, на сброшенных настройках с нуля там чисто. Я не блокирую доступ снаружи внутрь. Все равно port forwarding. Наружу торчат только те порты, которые используются. И все на нестандартных номерах >40000
  • +5
    Я видывал контр-страйк атаки примерно такого же вида примерно на 2-3 гигабита. Запрашивали список то ли игроков, то ли сессий с cs-серверов в интернете.

    Всё осложнялось тем, что валв отдаёт список cs серверов, то есть ddos-атаку легко координировать.
    • 0
      Изящно.
  • +2
    Хостимся у hetzner, мне написали из поддержки что мой сервак таким образом проэксплуатировали, закрыл дырку в тот же день. Это было как раз 4-5 дней назад.
    • +1
      Рекомендую не игнорировать. У нас блокировали IP после нескольких предупреждений в начале января.
  • 0
    На январских праздниках приходила абуза от хостера, атаковали чьи-то игровые сервера. Оказалось виноват ESXi 4.1 с установками по умолчанию (ставил сам хостер!). Написал в блог howto с картинками как полечить: How to prevent malicious usage of VMware ESXi in NTP reflection attacks
    • 0
      Оказалось виноват ESXi 4.1 с установками по умолчанию (ставил сам хостер!).

      Хостер тут не при чем — это баг VMware не закрыла.
      • 0
        По хорошему хостер мог бы закрыть управляющие адреса (iLO, ESXi и т.п) VPN'ом. Некоторые так уже делают.
  • 0
    Пикантная подробность: данная уязвимость была исправлена в релизе ntp 4.2.7p26, выпущенном в первой половине 2010 года. Действительно, самое время кому-то обновиться.
    • 0
      CentOS 6 вообще живет на 4.2.6p5 =)
    • 0
      Проблема в том, что стабильные версии — четные. Сейчас — 4.2.6.
  • +2
    С непубличным ntpd всё достаточно просто — restrict default ignore, открыть только нужные, и без разницы, какая версия.
    Я столкнулся с куда более серьёзной проблемой — куча открытых ntpd и рекурсивных dns у моих клиентов (я провайдер).
    Попытка обзвона ничего не дала — большинство вообще не понимает, о чём речь.

    В итоге решил проблему просто — 100 килобит исходящего udp с портов 53 и 123 с каждого клиента.
    Нормальной работе обоих протоколов никак не помешает (ну разве что кроме случая реального высоконагруженного публичного сервера у клиента, но таковых нет). А флуд невозможен — упрётся в шейп и всё.
  • 0
    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
    Дмитрий Скаленко
  • 0
    Да. Спасибо за публикацию!

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