Comments 38
Не закрывать доступ в админку по IP или простой дополнительной BASIC авторизацией логином и паролем это же моветон
Разумно сделали, спасибо что рассказали о проблеме и решении.
Мой хостер принудительно закрыл доступ со всех IP и разослал письма, что для доступа к админке нужно прописать свои IP в .htaccess как разрешенные. Я был в другой стране и без ноутбука, редакторы не могли получить доступ к админке.
Мой хостер принудительно закрыл доступ со всех IP и разослал письма, что для доступа к админке нужно прописать свои IP в .htaccess как разрешенные. Я был в другой стране и без ноутбука, редакторы не могли получить доступ к админке.
Любопытно что на недавнем WordCamp Russia тема безопасности и упомянутой здесь атаки не поднималась совсем. Похоже активисты сообщества уверены, что все всё давно прикрыли. Но это не так.
У моего хостера ничего кроме сообщения о факте атак не было. На шареде еле как все ворочалось и регулярно задержки превышали все разумные пределы. Прочитав одинокий твит хостера решил все исправить поскорее нагугленным плагином limit login attempts для wordpress.
Эта атака исправляется простым nginx limit requests модулем…
Главное — не забыть вынести /wp-login.php в отдельный локейшен :)
Ограничитель частоты запросов отодвигает вероятность наступления DoS, но не может спасти от собственного брутфорса.
Ну можно сделать limit_request при хедере auth или конкретных POST запросах и отсутствии сессионой записи.
В данном случае реальное грамотное профессиональное прозрачное решение только limit_request c burst.
Ну или haproxy table limit или tarpit
В данном случае реальное грамотное профессиональное прозрачное решение только limit_request c burst.
Ну или haproxy table limit или tarpit
К нам обращались пользователи, у которых все файлы с именами admin блокировались и отдавалась 403 ошибка. Пользователи так же заверяли, что их никто не предупреждал. После нашего совета по обращению к хостеру, проблема конечно решалась, но нужно было объяснять пользователям, что это не наш косяк…
Как вариант, поставить на авторизацию в CMS GeoIP и его аналоги. Прописав в его настройках зону RU, у вас будет защита от заходов с «буржуйских» серверов.
Как вариант, поставить на авторизацию в CMS GeoIP и его аналоги. Прописав в его настройках зону RU, у вас будет защита от заходов с «буржуйских» серверов.
Проблема решается добавлением капчи в аторизационную форму. Такую форму даже пытаться брутфорсить не станут.
Капча распознается сейчас достаточно эффективно. Вспомнить даже статьи про капчу на хабре
1. Эффективность распознавания даже простых версий капчи сильно далека от 100%. Про сложные/нестандартные варианты даже и не говорим.
2. Сложность реализации алгоритмов распознавания капчи значительно выше чем простого брутфорсера перебирающего логины/пароли по словарю или схеме.
3. Задача распознавания капчи достаточно ресурсоемка, т.е. под это требуются либо дополнительные, иногда, весьма существенные вычислительные мощности, либо скорость перебора сильно падает.
В общем, все три фактора делают брутфорс малоэффективным. Проще бросить и поискать другую жертву или другую уязвимость, чем ломать форму с капчей брутфорсом.
2. Сложность реализации алгоритмов распознавания капчи значительно выше чем простого брутфорсера перебирающего логины/пароли по словарю или схеме.
3. Задача распознавания капчи достаточно ресурсоемка, т.е. под это требуются либо дополнительные, иногда, весьма существенные вычислительные мощности, либо скорость перебора сильно падает.
В общем, все три фактора делают брутфорс малоэффективным. Проще бросить и поискать другую жертву или другую уязвимость, чем ломать форму с капчей брутфорсом.
Мы активно работали с одним хостингом в этом направлении.
_Очень_ хороший результат даёт просто ratelimit на конкретные странички авторизации. Боты видят ошибки и убираются брутить тех, у когошкололо хостер этого не умеет.
_Очень_ хороший результат даёт просто ratelimit на конкретные странички авторизации. Боты видят ошибки и убираются брутить тех, у кого
Ох уж эти обезличенные графики. Ордината в килограммах или в локтях?
Все мои сайты на Wordpress благополучно пережили распределенный брутфорс с помощью плагина Better WP Security, всем настоятельно рекомендую оный.
у меня в логах сегодня 15 000 запросов к странице /edit неск. раз в секунду в течение 6 часов с разных IP
CMS Drupal
Скриншот лога ошибок
CMS Drupal
Как видим, повышенная активность в одном из клиентских виртуальных серверов
Я прошу прощения, но в этом графике вообще невозможно ничего понять. Подпись есть только под одной осью и нету легенды раскрывающей это разноцветие линий
И ещё один момент:
Адреса сайтов ботам отдавались в алфавитном порядке.
Таким образом, вечером начинали страдать сайты на букву А, а ближе к утру — сайты на Z
Был осуществлён перебор имени сайта, или злоумышленники передавали ботам списки реально существующих сайтов?
Я прошу прощения, но в этом графике вообще невозможно ничего понять. Подпись есть только под одной осью и нету легенды раскрывающей это разноцветие линий
Это график, на котором наслаиваются значения количества активных процессов в каждом из серверов. Один цвет — один сервер. На скриншоте не видно, но у каждого сегмента работает подсветка и оператор видит, на какой из нод или в каком из виртуальных серверов (в зависимости от детализации) в данный момент идет высокая нагрузка.
В данном случае выбрано именно такое представление, чтобы показать, что 31 числа наибольший вклад в суммарную нагрузку на нодах дал всего один виртуальный сервер. Т.е. это флуктуация, а не закономерность. Далее видно, что когда началась атака, нагрузка выросла на множестве нод одновременно и это дало значительный суммарный рост нагрузки, который мы и наблюдали на графиках мониторинга. И это была уже не флуктуация, а распределенная атака на множество ресурсов.
Легенду осознанно вырезали, т.к. что вы там хотите увидеть? Портянку из сотен идентификаторов нод?
Был осуществлён перебор имени сайта, или злоумышленники передавали ботам списки реально существующих сайтов?
Боты работали по спискам реально существующих сайтов.
1. Перебор имени сайта выглядит нелогичной и весьма трудоемкой операцией. Это ни к чему, учитывая, что списки зарегистрированных доменных имен есть в условно отрытом доступе, пройтись по ним один раз и понять, где какая CMS — на порядок более простая задача, чем перебор имен.
2. Даже если бы перебор имел место, то ни владельцам сайтов, ни хостинг-провайдеру от этого ни тепло, ни холодно, т.к. никаких обращений к серверу в случае несуществующего доменного имени не будет. Запросы будут получать только корневые NS доменной зоны, а им эта нагрузка как нам с вами дуновение лунного ветра (т.е. совершенно не заметно на общем фоне).
Забавно, но эта атака совпала у меня с действиями реальных кулхацкеров. Решив, что представилась удачная возможность слить всю бот сеть перед какой-либо серьезной атакой, в ipset ушло 7200 ботов :)
Вместо того, чтобы заставлять вводить текст пользователя, можно было сделать это яваскриптом. Как правило боты не выполняют JS на страничках.
тоже столкнулся с проблемой, спасибо хостеру за оперативное решение проблемы, сайты лежали не сильно долго.
UFO just landed and posted this here
Sign up to leave a comment.
Распределенная брутфорс-атака на CMS с точки зрения хостера