Распределенная брутфорс-атака на CMS с точки зрения хостера

    Не секрет, что попытки подбора пароля методом перебора (брутфорс) — постоянное явление. Подбирают пароли к серверам и виртуальным машинам, к админкам сайтов и FTP-аккаунтам, к почтовым ящикам и социальным сетям.

    Обычно брутфорс идет в фоновом режиме и практически не заметен для владельцев ресурсов, т.к. не создает значительную нагрузку и не мешает работе сайта, по крайней мере до тех пор, пока злодеи не проникнут на сервер :)

    1 августа началась, пожалуй, самая мощная в рунете брутфорс-атака на сайты, созданные с помощью самых распространенных бесплатных CMS: Wordpress, Joomla! и др.

    Графики из мониторинга нагрузки

    И вот как это было:


    Мода на мега-брутфорс дошла и до нас



    Похожая атака на Wordpress-сайты была предпринята в апреле этого года. Эта атака затронула в основном западные ресурсы и российские пользователи и хостинг-провайдеры ее не заметили. На этот раз ботнет направлен прежде всего на взлом русскоязычных сайтов.

    График общей нагрузки на кластере

    Первые публичные сообщения об атаке появились 2 августа. На самом деле, аномальная активность в нашей системе мониторинга была заметна еще первого числа. До этого нагрузка, создаваемая ботами, была не так заметна. Возможно, это были пробные запуски, но мы предполагаем, что активная работа началась с малого количества зараженных машин. По мере подключения новых участников, нагрузка на инфраструктуру росла и ко 2 августа ее почувствовали на себе все российские хостинг-провайдеры и их клиенты.

    На графике выше может показаться, что что-то начало происходить еще 31 июля, я даже выделил этот момент красной линией. Как показало дальнейшее исследование, это была локальная аномалия, вызванная не началом атаки, а нагрузкой на одной из нод. По этому графику с детализацией легко выявить источник аномалии:

    График нагрузки на кластере с детализацией по нодам

    Зная ноду, можно углубиться дальше и узнать, кто именно создает нагрузку:
    График нагрузки на ноде с детализацией по виртуальным серверам
    Как видим, повышенная активность в одном из клиентских виртуальных серверов. При этом у соседей по серверу все хорошо и на других нодах все в норме. Отсюда мы делаем вывод, что случай не имеет отношения к исследуемой атаке, т.е. большой брутфорс начался 1 августа.

    Борьба с ботами


    Поведение ботов было стандартным: они обращались к типовой странице авторизации CMS. Например, для WP это страница wp-login.php. В первой фазе атаки обращения были достаточно топорными: боты сразу делали POST логина и пароля в форму без предварительного получения страницы (GET). Таким образом, на этом этапе их было очень легко отличить от настоящих пользователей, которые сначала получали страницу, а потом уже вводили логин и пароль.

    Используя эту особенность, боты достаточно быстро были заблокированы. Естественно, после этого злоумышленники внесли коррективы в поведение ботов. Они научились делать GET-POST и работать с куками.

    После этого из возможных вариантов прикрытия остались:
    1) переименование страницы авторизации;
    2) ограничение доступа к админскому разделу по ip-адресам (белый список, географический или иной принцип деления);
    3) двойная авторизация.

    Переименование страницы авторизации хорошо подходит конкретно для Wordpress, т.к. в результате ничего не ломается и можно продолжать работу. Но не факт, что этот способ хорошо работает для других CMS. В системе вполне может быть привязка к конкретному названию скрипта.
    Таким образом, этот способ не подходил для нас как хостинг-провайдера, т.к. мы просто не можем пойти и переименовать всем клиентам файлы без их ведома. Это может сделать только сам клиент.

    Ограничение доступа к админке по белому списку ip-адресов подходит далеко не всем, т.к. во-первых, практически всегда интернет-провайдеры выдают динамический адрес, который может меняться от сессии к сессии, а во-вторых, это исключает возможность доступа к админке извне, например, с мобильного устройства. Этот вариант также был отметен, как нерабочий.

    Ограничение по географической принадлежности ip работает только в случае, если у ботнета есть ярко выраженный «регион проживания», например, Вьетнам или Индия. Опять-таки для принятия единых мер на крупном хостинге такой способ не подходит, т.к. сразу находятся зарубежные клиенты, которые попадают под действие этих фильтров.

    Двойная авторизация — способ, который мы в итоге применили к сайтам, подверженным атакам на нашем шаред-хостинге. Мы установили дополнительную страницу авторизации, которая выдается при попытке обращения к админке без определенных кук. Пройдя нашу дополнительную авторизацию один раз, легитимный пользователь получает особую куку и может спокойно войти в админку CMS. При этом боты не могут пройти через страницу и не только не могут осуществлять подбор пароля к CMS, но и не создают большой нагрузки на сервер.

    Судя по новостям хостинг-провайдеров, многие воспользовались похожим методом, но установили жутко секретные пароли, узнать которые клиент мог только по запросу в техническую поддержку или в персональной электронной рассылке.

    Мы сочли такой сверх-секретный подход избыточным и некорректным по отношению к клиентам. Порой доступ в админку нужен срочно, а писать заявку, звонить или искать искомое письмо от хостера может быть очень неудобно. Поэтому данные для дополнительной авторизации мы указали на странице в явном виде, исходя из простого предположения, что боты не умеют читать и думать, а учить их конкретно для нашего случая — слишком трудоемкое и неблагодарное злодейское занятие.

    Примерно так выглядит страничка с дополнительной авторизацией (простите, было не до красивого оформления страницы):
    Пример сообщения для пользователя, желающего войти в админку.

    Также мы отказались от использования классической http-авторизации по причине того, что всплывающее окно с запросом логина и пароля — не самый удобный способ рассказать клиенту что случилось с его CMS и отчего он видит этот запрос. Такое окно блокирует браузер, пугает и мешает сориентироваться.

    Наблюдения


    Помимо борьбы с ботами нам было весьма интересно понаблюдать за тем, как координируются и распределяются их усилия. Судя по аналитике из нашей системы, количество одновременных запросов на 1 хостинговый ip-адрес устойчиво держалось не более 30 для каждой CMS, вне зависимости от количества атакуемых сайтов на этом адресе. Таким образом, если на одном ip-адресе размещались сайты и на Wordpress, и на Joomla!, то количество одновременных обращений держалось на уровне 60 штук. Это достаточно много для shared-хостинга.

    Если сайт переставал отвечать — запросы к нему мгновенно прекращались. Это разумно, т.к. злоумышленникам выгоднее оставить жертву в живых. Тем не менее, 60 одновременных запросов — достаточно большой поток, чтобы его гарантированно заметили и владельцы сайтов, и хостинг-провайдеры. Есть мнение, что злодеям разумнее было бы брутфорсить в 3-4 раза меньшим потоком запросов. В этом случае деятельность ботнета была бы гораздо менее заметна.

    Активная фаза атаки начиналась вечером и продолжалась всю ночь. Адреса сайтов ботам отдавались в алфавитном порядке.
    Таким образом, вечером начинали страдать сайты на букву А, а ближе к утру — сайты на Z. Им в этом смысле повезло чуть больше.

    И вновь продолжается бой


    Сейчас атака все еще продолжается, хотя и в существенно сниженном темпе. Нам удалось минимизировать ущерб от атаки для пользователей shared-хостинга. В зоне риска остаются пользователи выделенных физических и виртуальных серверов, т.к. централизованно прикрыть доступ к админке CMS в этом случае нельзя и меры по защите должны быть приняты администратором сервера.

    Спасибо за внимание! :)

    Всем успехов в борьбе с ботами. способы для самостоятельной защиты озвучены выше. Если у вас есть классный готовый рецепт — прошу в комменты!
    Rusonyx
    Компания

    Комментарии 38

      +3
      Не закрывать доступ в админку по IP или простой дополнительной BASIC авторизацией логином и паролем это же моветон
        0
        Это так :) Но печаль-печаль, наш опыт показывает, что так сделано примерно у 1% сайтов.
          0
          Не только ваш =) Все очень печально.
        +3
        Разумно сделали, спасибо что рассказали о проблеме и решении.
        Мой хостер принудительно закрыл доступ со всех IP и разослал письма, что для доступа к админке нужно прописать свои IP в .htaccess как разрешенные. Я был в другой стране и без ноутбука, редакторы не могли получить доступ к админке.
          +2
          Да, совсем непонятно, как можно прописать свои IP если интернет-провайдер каждый раз выдает новые. Особенно актуально для тех, кто работает с ноутбуков вне офиса и мобильных устройств.
            0
            А простенький VPN клиентам раздавать нельзя?
              0
              Ну так, для этого на флешке носи всегда с собой любимый ФТП клиент и каждый раз заходи на сервер и прописывай IP.
              А заодно можно научить делать подобное клиентов.

              /* табличка сарказм */
            0
            Любопытно что на недавнем WordCamp Russia тема безопасности и упомянутой здесь атаки не поднималась совсем. Похоже активисты сообщества уверены, что все всё давно прикрыли. Но это не так.
              0
              У моего хостера ничего кроме сообщения о факте атак не было. На шареде еле как все ворочалось и регулярно задержки превышали все разумные пределы. Прочитав одинокий твит хостера решил все исправить поскорее нагугленным плагином limit login attempts для wordpress.
                +1
                Эта атака исправляется простым nginx limit requests модулем…
                  0
                  Главное — не забыть вынести /wp-login.php в отдельный локейшен :)
                    0
                    Ограничитель частоты запросов отодвигает вероятность наступления DoS, но не может спасти от собственного брутфорса.
                      0
                      Ну можно сделать limit_request при хедере auth или конкретных POST запросах и отсутствии сессионой записи.
                      В данном случае реальное грамотное профессиональное прозрачное решение только limit_request c burst.
                      Ну или haproxy table limit или tarpit
                        0
                        реальное грамотное профессиональное прозрачное решение

                        Без блокировки атакующих после достижения какого-то порога любое решение будет неполным, особенно если долбит ботнет с большим количеством хостов.
                          0
                          Блокировка приведет к фальш-позитивам.
                            0
                            С чего вдруг? Если какой-то хост постит форму несколько десятков раз на протяжении минуты, то с вероятностью 99% это некий бот.
                              0
                              В наше время обычно делают 3-4 запроса в 5 минут, просто с тысяч IP. И многие из них легитимные.
                                0
                                И зачем легитимным логиниться 3-4 раза за 5 минут? %)
                    0
                    К нам обращались пользователи, у которых все файлы с именами admin блокировались и отдавалась 403 ошибка. Пользователи так же заверяли, что их никто не предупреждал. После нашего совета по обращению к хостеру, проблема конечно решалась, но нужно было объяснять пользователям, что это не наш косяк…

                    Как вариант, поставить на авторизацию в CMS GeoIP и его аналоги. Прописав в его настройках зону RU, у вас будет защита от заходов с «буржуйских» серверов.
                      +1
                      Проблема решается добавлением капчи в аторизационную форму. Такую форму даже пытаться брутфорсить не станут.
                        0
                        Капча распознается сейчас достаточно эффективно. Вспомнить даже статьи про капчу на хабре
                          0
                          1. Эффективность распознавания даже простых версий капчи сильно далека от 100%. Про сложные/нестандартные варианты даже и не говорим.
                          2. Сложность реализации алгоритмов распознавания капчи значительно выше чем простого брутфорсера перебирающего логины/пароли по словарю или схеме.
                          3. Задача распознавания капчи достаточно ресурсоемка, т.е. под это требуются либо дополнительные, иногда, весьма существенные вычислительные мощности, либо скорость перебора сильно падает.

                          В общем, все три фактора делают брутфорс малоэффективным. Проще бросить и поискать другую жертву или другую уязвимость, чем ломать форму с капчей брутфорсом.
                            0
                            Мне буквально недавно рассказывал хозяин одно ДЦ о том что столкнулся с тем что ддосили его клиента, и даже промежуточную капчу проходили и с валидными куками продолжали досить. Но видимо там клиент кому-то хорошо насолил
                              0
                              Есть еще параноидальные варианты и без капчи — 3 неудачных попытки авторизации и IP в бан на 5 минут
                        +1
                        Мы активно работали с одним хостингом в этом направлении.
                        _Очень_ хороший результат даёт просто ratelimit на конкретные странички авторизации. Боты видят ошибки и убираются брутить тех, у кого школоло хостер этого не умеет.
                          +1
                          Ох уж эти обезличенные графики. Ордината в килограммах или в локтях?
                            0
                            Упустил этот моменти не указал. Ордината в штуках. Показано количество активных (running) процессов.
                            0
                            Все мои сайты на Wordpress благополучно пережили распределенный брутфорс с помощью плагина Better WP Security, всем настоятельно рекомендую оный.
                              0
                              у меня в логах сегодня 15 000 запросов к странице /edit неск. раз в секунду в течение 6 часов с разных IP

                              Скриншот лога ошибок


                              CMS Drupal
                                0
                                Похоже и до друпала добрались. Есть повод принять меры :)
                                  0
                                  Эта атака началась раньше на пару недель или месяц, периодически возвращается. fail2ban-ом порезал.
                                0
                                Как видим, повышенная активность в одном из клиентских виртуальных серверов

                                Я прошу прощения, но в этом графике вообще невозможно ничего понять. Подпись есть только под одной осью и нету легенды раскрывающей это разноцветие линий

                                И ещё один момент:

                                Адреса сайтов ботам отдавались в алфавитном порядке.
                                Таким образом, вечером начинали страдать сайты на букву А, а ближе к утру — сайты на Z

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


                                  Это график, на котором наслаиваются значения количества активных процессов в каждом из серверов. Один цвет — один сервер. На скриншоте не видно, но у каждого сегмента работает подсветка и оператор видит, на какой из нод или в каком из виртуальных серверов (в зависимости от детализации) в данный момент идет высокая нагрузка.

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

                                  Легенду осознанно вырезали, т.к. что вы там хотите увидеть? Портянку из сотен идентификаторов нод?

                                  Был осуществлён перебор имени сайта, или злоумышленники передавали ботам списки реально существующих сайтов?


                                  Боты работали по спискам реально существующих сайтов.
                                  1. Перебор имени сайта выглядит нелогичной и весьма трудоемкой операцией. Это ни к чему, учитывая, что списки зарегистрированных доменных имен есть в условно отрытом доступе, пройтись по ним один раз и понять, где какая CMS — на порядок более простая задача, чем перебор имен.

                                  2. Даже если бы перебор имел место, то ни владельцам сайтов, ни хостинг-провайдеру от этого ни тепло, ни холодно, т.к. никаких обращений к серверу в случае несуществующего доменного имени не будет. Запросы будут получать только корневые NS доменной зоны, а им эта нагрузка как нам с вами дуновение лунного ветра (т.е. совершенно не заметно на общем фоне).
                                  0
                                  Забавно, но эта атака совпала у меня с действиями реальных кулхацкеров. Решив, что представилась удачная возможность слить всю бот сеть перед какой-либо серьезной атакой, в ipset ушло 7200 ботов :)
                                    +1
                                    Вместо того, чтобы заставлять вводить текст пользователя, можно было сделать это яваскриптом. Как правило боты не выполняют JS на страничках.
                                      0
                                      Это еще круче :) Спасибо за идею.
                                      0
                                      тоже столкнулся с проблемой, спасибо хостеру за оперативное решение проблемы, сайты лежали не сильно долго.
                                        0
                                        Ещё как вариант правило в fail2ban и резать файрволом чтобы боты apache не дергали лишний раз на проверку авторизации. Просто на слабых VDS даже при 2й не приятно когда дергают.

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

                                        Самое читаемое