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

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

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

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

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

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


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

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

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

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

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


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

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

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

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


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

2. Даже если бы перебор имел место, то ни владельцам сайтов, ни хостинг-провайдеру от этого ни тепло, ни холодно, т.к. никаких обращений к серверу в случае несуществующего доменного имени не будет. Запросы будут получать только корневые NS доменной зоны, а им эта нагрузка как нам с вами дуновение лунного ветра (т.е. совершенно не заметно на общем фоне).
Забавно, но эта атака совпала у меня с действиями реальных кулхацкеров. Решив, что представилась удачная возможность слить всю бот сеть перед какой-либо серьезной атакой, в ipset ушло 7200 ботов :)
Вместо того, чтобы заставлять вводить текст пользователя, можно было сделать это яваскриптом. Как правило боты не выполняют JS на страничках.
тоже столкнулся с проблемой, спасибо хостеру за оперативное решение проблемы, сайты лежали не сильно долго.
Ещё как вариант правило в fail2ban и резать файрволом чтобы боты apache не дергали лишний раз на проверку авторизации. Просто на слабых VDS даже при 2й не приятно когда дергают.
Only those users with full accounts are able to leave comments. Log in, please.