Не секрет, что попытки подбора пароля методом перебора (брутфорс) — постоянное явление. Подбирают пароли к серверам и виртуальным машинам, к админкам сайтов и 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 в этом случае нельзя и меры по защите должны быть приняты администратором сервера.
Спасибо за внимание! :)
Всем успехов в борьбе с ботами. способы для самостоятельной защиты озвучены выше. Если у вас есть классный готовый рецепт — прошу в комменты!
Обычно брутфорс идет в фоновом режиме и практически не заметен для владельцев ресурсов, т.к. не создает значительную нагрузку и не мешает работе сайта, по крайней мере до тех пор, пока злодеи не проникнут на сервер :)
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 в этом случае нельзя и меры по защите должны быть приняты администратором сервера.
Спасибо за внимание! :)
Всем успехов в борьбе с ботами. способы для самостоятельной защиты озвучены выше. Если у вас есть классный готовый рецепт — прошу в комменты!
