Брутфорс-атаки, направленные на WordPress-сайты, всегда были очень популярны. Фактически атаки методом брутфорса против любых существующих CMS – обычное явление, однако всегда интересно, какие инструменты использовались для этого.
Вы создаете сайт, поскольку это очень просто сделать сегодня, публикуете контент, и в течение нескольких недель какие-то пользователи пытаются неоднократно войти в консоль. Такие попытки входа в систему идут из ботнетов, они автоматизированы, и их цель проста – «захватить столько сайтов, сколько получится, угадывая пароли». Как только они найдут пароль, который будет подходить, они начинают пользоваться сайтом для распространения разных вирусов, спама и т.д.
Вот лишь небольшой пример нашего собственного honeypot’а, который регистрирует сотню попыток входа в день путем тестирования различных комбинаций логина и пароля:
user: admin, pass: admin user: admin, pass: 123456 user: admin, pass: 123123 user: admin, pass 112233 user: admin, pass: pass123 ..
Пароли могут выглядеть глупо, однако после попыток ввода 200-300 популярных паролей злоумышленники все же могут получить контроль над сайтом.
XMLRPC wp.getUsersBlogs
Первоначально брутфорс-атаки всегда осуществлялись через /wp-login.php, однако в последнее время для этого все чаще используется метод wp.getUsersBlogs XMLRPC, чтобы угадать столько паролей, сколько получится. Использование XMLRPC – более быстрый и сложный для обнаружения метод. Не спутайте этот пост с тем, что мы уже публиковали в марте, когда мы заметили, что XMLRPC используется для DDOS-атак сайтов. В данном случае злоумышленники несколько усовершенствовали свой подход, пытаясь угадывать логин и пароль, что, естественно, отличается от DDOS-атак.
Такая атака возможна, поскольку многочисленные вызовы в реализации WordPress XMLRPC требуют логина и пароля. В данном виде атак, как мы заметили, используется wp.getUsersBlogs (и иногда wp.getComments), однако могут применяться и другие вызовы. Если вы передадите им логин и пароль, то они ответят вам, является ли данная комбинация корректной или нет:
<methodCall><methodName>wp.getUsersBlogs</methodName><params><param><value> <string>admin</string></value></param> <param><value><string>112233</string></value></param></params> </methodCall>
В примере выше злоумышленники пытались проверить логин admin и пароль 112233.
Крупномасштабный брутфорс
Чтобы исследовать масштаб этой атаки, мы обратились к логам. Несколько прошлых недель оказались довольно интересными, с начала июня атаки выросли в десять раз и включили в себя примерно 2 миллиона попыток входа, которые произошли с 17,000 разных IP. В определенные дни было почти 200,000 попыток входа.
Единственная причина, по которой эти числа не стали выше, заключается в том, что мы уничтожаем логи после блока попыток, поэтому все, что вы видите – это постепенное увеличение атак, однако не полная картина происходящего. И это довольно страшно для владельцев сайтов.
Другой интересный аспект атаки – имена пользователей. Вместо того чтобы просто пытаться ломать пользователя с логином admin, злоумышленники пытаются определить доменное имя и выяснить реального администратора сайта, используя его логин вместо стандартного admin. Вот основные имена пользователей, которые пытались ломать:
179005 test 167147 admin 32030 sitedomain (domain modified to protect the innocent) 15850 sitedomain2 (domain modified to protect the innocent) 9590 realsiteadmin (user name modified to protect the innocent) 9564 realsiteadmin2 (user name modified ..)
Таким образом, из двух миллионов попыток только 167,000 использовали имя пользователя admin. Это демонстрирует тот факт, что простое отключение пользователя с логином admin не поможет, если злоумышленники могут узнать реального пользователя сайта. Именно по этой причине мы больше не делаем ставку на отказ от имени пользователя admin для повышения безопасности.
Что касается паролей – злоумышленники используют самые популярные пароли, найденные во многих словарях:
1dc13d admin 123123 admin1 admins 123456 12345678 7777777 letmein 121212 qweqwe iloveyou administrator holysh!t 55555 1q2w3e qwerty wordpress wpsite internet asdfghjkl 121314 lollipop killer pass lovers hello dragon admin123 office jerome fyfcnfcbz
Защита от брутфорса
Есть много способов защититься от брутфорс атак. Если у вас есть выделенный сервер, вы можете установить OSSEC и позволить ему автоматически блокировать IP-адреса, которые слишком много раз вводят неправильные пароли. Мы предлагаем автоматическую защиту от брутфорса в нашем файрволе (CloudProxy), поэтому если вам требуется решение в один клик, вы можете воспользоваться им.
Естественно, многие инструменты прикладного уровня (т.е. плагины) помогают справиться с брутфорс атаками. Однако ни один из плагинов, который мы попробовали, не защитил нас от вызовов XMLRPC, за исключением нашего собственного плагина. Вероятно, поэтому мы и видим такое изменения в методах атак.
Источник: blog.sucuri.net
После прошлогодней волны (или в начал этого года была?) на WP и Joomla, мой хостер (не буду спамить :D) сам прошелся скриптом поиска админок по серверу и прикрутил htpasswd.
И этот метод надежнее рекламируемого плагина в сотни раз. И не надо мучить WP лишними плагинами.
Для пользовательской регистрации полезна капча. Для пользовательской авторизации — вариант встроенный во многие форумные движки — ошибся пять раз, отдыхай 15 минут.
htpasswd — хорошее решение.
Главное — защищать и сам файл .htpasswd. Некоторые хостеры криво настраивают htaccess — к нему можно получить доступ просто вбив в адресной строке браузера: sait.ru/.htaccess.
Если есть доступ к htpasswd, то можно будет узнать и все пароли, даже если они там хранятся в зашифрованном виде, вопрос времени.
Способ с плагином подойдет новичкам, которые не слишком хорошо разбираются в дебрях кода и хотят просто себя предохранить на будущее. Тем более, Sucuri — проверенный сайт, авторитетный, ему можно вполне доверять.
Это где же такое видано? По умолчанию эти файлы закрыты. Я не знаю способа открыть к ним доступ и гугл тоже. Новичок тем более не сможет такое сделать.
А также хранить .htpasswd в папке сайта не есть хорошо.
С правами доступа накосячат, и файл открыт широкой общественности :)
Далеко не все хостеры прикрывают такие банальные дыры. Сам сталкивался с этим, когда хостер предлагал доступ по FTP через плагин в админке, обычный FTP был закрыт. В итоге я заметил, что они не ограничили уровни доступа корневой папкой, и через этот плагин можно было выйти на их сервер и просматривать все блоги, которые были созданы и работали на том же самом тарифе. Возможно, что был открыт доступ даже для удаления файлов, я сам не пробовал во избежание потом претензий ко мне. Просто указал им на это, и они прикрыли такую дыру. А хостинг достаточно известный :)
Даже знания программирования не требовалось для этого, то же самое мог повторить любой новичок.
Ни с какими правами доступа не получишь доступ из вне. Это меняется, если меняется, только на стороне сервера. Или в крайнем случае через сам .htaccess.
Что касается доступа к папкам выше пользовательской, то это проблема действительно может быть. И если на то пошло, то если человек сможет залить шел или попасть в админку, то htaccess и htpasswd ему ни как не нужны будут и они были тут не при чем.
Равно как и плагин выше озвученный ни как не спасет.
Да и на таком хостинге, если знать конечно заранее, можно купить хостинг и творить со всеми сайтами что угодно. Тут уже ни что не спасёт.
Так что не надо кидаться в крайности.