Хак сайта на WordPress, кому все это нужно и советы как этого избежать / Habr
Привет хабраUser!
Эта история началась около 2-х месяцев назад, когда мой хороший друг Александр, оказывающий услуги хостинга, при очередной проверке всех виртуальных машин антивирусом обнаружил подозрительный .js файл в корневой директории моего сайта, в VDS которую обслуживаю я сам, тогда я не придал этому значение… Но думаю любой администратор хостинга сразу забеспокоился бы.
Закончилось все, спустя только 2 месяца, после блокировки моего сайта корпорацией добра:
По тексту, я хочу рассказать Вам:
Краткое содержание:
Взлом, дальше с VDS начали происходить интересные вещи: Спам рассылки по нескольким тысяч адресатов, установка подозрительных скриптов, появление странных файлов в корне основного сайта. Скажу честно — было страшно… Но похоже я победил тьму).
Вступление:
Я пишу эту статью, еще и как записную книжку, что бы можно было к ней вернуться в случае повторения проблем. Кому интересен процесс борьбы со зловредами, он будет описан ниже. Букв будет много, поэтому, кому нужны практические советы — листаем до конца.
Как взломали мой сайт на моем же хостинге на Debian Wheezy или Хак сайта на WordPress и кому все это нужно
С какими проблемами я сталкивался и как воспринимал их.
Мой сайт крутится на Debian Wheezy, установлена панель управления хостингом i-mscp (преемница ispcp), есть еще несколько сайтов, тоже личные, поэтому администратор я один и ни кому не даю доступ на свою VDS.
Все было настроено хорошо, думал я, и поэтому не парился по поводу безопасности, пользовался рутовым ssh и ставил скрипты сторонних писателей на сайт для экспериментов. Сайт на WordPress и для него просто неимоверное количество плагинов. На проверку которых я не уделял времени. Сайт рос и пополнялся все новыми плагинами и скриптами…
Зачем тебе нужные все эти плагины\расширения\скрипты?
Спросил однажды меня мой друг. Я ответил, что мне нужен “социализированный” сайт и мне нравится экспериментировать с различными скриптами, видеть как они влияют функционал сайта и его внешний вид. Я Все время пытался что то улучшить…
Проблема номер два
Прошло 2 недели, после того как я не отреагировал на первую угрозу. Я поимел следующую проблему.
Сижу на работе, и вдруг, мне в почту gmail, в папку spam начинают падать сообщения от моего почтового сервера postfix (там у меня настроена пересылка на личную почту) о том что, такое то сообщение не доставлено. Примерно 50 сообщений, о недоставке, в секунду.
Захожу на сервер и смотрю лог:
tail -f /var/log/mail.log
А там просто неимоверная скорость записи сообщений, останавливаю почтовик:
/etc/init.d/postfix stop
Спам прекращается, пытаюсь выяснить как идет рассылка, но из-за нехватки опыта ни чего не понимаю.
Опытным путем удается выяснить, что если переименовать корневую директорию основного (sysrtfm точка ру) сайта или заблокировать домен в панели управления хостинга, то спам прекращается.
Приходит осознание того, что подломали основной сайт, но как?
postsuper -d ALL
часов 8 проверял руками директории сайта на наличие левых скриптов, отключал все плагины, запускал почтовик и снова получал рассылку( грустная рожица
Тут случайно, в корневой директории сайта, обнаруживаю папку css с файлом /css/sys0972500-1.php. Зная примерную структуру своей CMS, понимаю, что его такого файла быть не должно. Скачиваю резервную копию за прошлый месяц, распаковываю, и вижу, что файла там точно быть не должно. Как он там оказался? Этот вопрос пока без ответа, но права у него такие же как у остальных файлов.
Читаем лог апача:
tail -f /var/log/apache2/sysrtfm.ru.log
и видим там:
"POST /css/sys0972500-1.php HTTP/1.1" 404 55665 "-" "-"
почти каждые 30 секунд.
Видимо кто то запускает этот скрипт издалека, инициируя рассылку.
Казалось бы, заблокировать IP и все, но он почти так же часто меняется. Удалил директорию с файлом, рассылки прекратились. Не приняв, практически, ни каких противодействий, т.к. не понял как произошёл взлом, оставил проблему как есть. Только сменил рутовый пароль на более сложный и по отключал плагины и скрипты которыми уже не пользуюсь. Следующей обнаруженной проблемой стало, то что, на столько популярный движок WordPress, что его пытается подломать все кому не лень. Почитав логи Apache2, понял, что идет постоянная brute-force login attack на форму входа в административную панель. Но т.к. я об этом давно подозревал, у меня уже был установлен плагин блокировки пользователя после нескольких неудачных попыток входа (User Locker).
tail -f /var/log/apache2/sysrtfm.ru.log
видим там:
"POST /wp-login.php HTTP/1.0" 200 6891 "http://sysrtfm.ru/wp-login.php" "Opera/9.80 (Windows NT 6.1; U; ru) Presto/2.8.131 Version/11.10"
С очень высокой периодичностью. Защита от этого метода атаки, это тема для отдельного разговора. Тут я пока поставил дополнительный плагин, блокирующий атакующего по ip адресу после нескольких попыток входа.
Проблема номер три
Зашел на VDS проверить логи и обнаруживаю, что в корне сайта все тот же файл, и опять запускается рассылка, но в гораздо меньших объемах… Взялся за голову.
Начинаю сканировать сайт online антивирусами:
Поиск по форумам результата не дает. Но нахожу одну статейку, которая мне очень помогла) До сих пор, вкладку с ней держу открытой.
В ней описывается процесс включения расширенного логирования почтового сервера, для того чтобы понять какой скрипт запускает рассылку. Исходный текст статьи под спойлером
Итак, имеем сервер на базе Debian.
Жалоба на исходящий спам с сервера.Задача: очистить очередь отправлений и обнаружить причину.
1. Подключаемся по SSH и смотрим очередь писем:
Решение: вариантов, конечно, много. Рассмотрим один из них.mailq
Да, писем много.2. Отключаем почтовый сервер (стоит postfix)
/etc/init.d/postfix stop3. Смотрим на соединения на 25й порт:
netstat -apn | grep :25
Если Established нет — значит, спам рассылается не через вредоносный скрипт, который отправляет почту в обход локального почтового сервера.4. Очищаем очередь писем
Exim:exipick -i | xargs exim -Mrm
Postfix:postsuper -d ALL
Sendmail:rm -rf /var/spool/mqueue/*
Конечно, при условии, что мы это сделать можем (в очереди могут быть реальные письма реальным пользователям).postsuper -d ALL postsuper: Deleted: 72849 messages5. Пробуем включить расширенное логирование почты:
mv /usr/sbin/sendmail /usr/sbin/sendmail.org touch /usr/sbin/sendmail chmod +x /usr/sbin/sendmailecho -n '#!/bin/bash logger -p mail.info sendmail-ext-log: site=${HTTP_HOST}, client=${REMOTE_ADDR}, script=${SCRIPT_NAME}, pwd=${PWD}, uid=${UID}, user=$(whoami) /usr/sbin/sendmail.org -t -i' > /usr/sbin/sendmail6. Запускаем почтовый сервер
/etc/init.d/postfix start7. Смотрим логи
tail -f /var/log/mail.info
Видим что-то вроде:Jan 23 16:25:25 danma logger: sendmail-ext-log: site=, client=, script=send.php, pwd=/var/www/danma/data/www/site.ru, uid=33, user=www-data Jan 23 16:25:25 danma postfix/pickup[11520]: E3CD259403D: uid=33 from= Jan 23 16:25:25 danma postfix/cleanup[11522]: E3CD259403D: message-id=Обращаю внимание, что это один из вариантов действий.
А еще бывает, что просто подобрали пароль к ящику — на это так же стоит обратить внимание!
Если есть ID письма в жалобе — стоит посмотреть его в логах отправлений.
Бывает так, что на сервере стоит опенрелей.
Взято от сюда, Автору спасибо!
После включения логирования я увидел, что спам рассылка запускается от этого скрипта (/css/sys0972500-1.php), но это было уже после того когда файл с директорией css появился в 3-й раз…
Как все таки меня подломали? Где? пока я это выяснял меня заразили еще чем то…
Проблема номер четыре
В этот раз мне написал друг, сказав, что на мой сайт его не пускает антивирус касперского,
а с другого компа не пускает гугл хром, показывая ту самую красную заглушку из шапки этой статьи… Я был очень огорчен увидев, что гугл забанил мой сайт, написав в панели инструментов вэбмастера примерно следующее:
“С вашего сайта производилась установка вредоносного ПО на клиентские ПК пользователей. Ссылки с которых производилась установка ниже:
Несколько ссылок с сайта”
Яндекс ни чего не подозревал…
- Отключил кэширующий плагин CMS, для того чтобы файлы генерировались снова, а не брались вредоносные из кэша
- Еще раз проверил сайт по базам online антивирусов, реально пригодился больше всего вот этот antivirus-alarm ru
- т.к. в этой проверке было написано:
содержит сомнительную ссылку по версии гугла: feeds feedburner com
содержит сомнительную ссылку по версии гугла: www facebook com
содержит сомнительную ссылку по версии гугла: www liveinternet ru
То снова по отключал пачку сторонних плагинов WordPress, социальные кнопки, комментарии итд…
Переход на сайты соц сетей, куда был кроспостинг моих статей были так же запрещены гуглом, из-за того, что там содержались материалы с моего сайта - Создал запрос в тех поддержку гугл на пересмотр решения о блокировке (на той же странице где описана причина блокировки, раздел “Проблемы безопасности”)
- Заполнил форму для сообщения о неверном предупреждении о фишинге.
- Т.к. 2 последних пункта рассматриваются 24 часа, я начал активно искать причину возможного взлома. Тут до меня доходит, что я не проверял ftp!
- Читаем лог proftpd сервера:
cat /var/log/proftpd/xferlog
находим там очень интересное:176.28.52.119 42278 /var/www/virtual/sysrtfm.ru/htdocs/css/sys0972500-1.php a _ i r [email protected] ftp 0 * c
И тут я все понял….(грустный смайлик( подломали аккаунт [email protected], я быстро поменял пароль и логин. А так же заблокировал все остальные ftp аккаунты. Проверив, что они ни где не задействованы.
Нашел еще запись:31.7.234.34 0 /var/www/virtual/sysrtfm.ru/htdocs/css/c3x.php b _ o r [email protected] ftp 0 * c
Это все из той же оперы, файлы удалил, но причина блокировки была не в этом. - Дальше завел тему в форуме технической поддержки вэбмастеров гугл тут.
Там добрые люди, нашли в скриптах, загружаемых с сайтом интересные вещи)
Что сделал зловред:
— Модифицировал через ftp файл wp-content/plugins/usernoise/js/usernoise.js приписав в самый конец еще один скрипт: /wp-includes/images/smilies/skynet.js
Оказалось, что этот скрипт выполнялся только если браузер не гугл хром, загружая на ПК пользователя вредоносное ПО.
— Затем был заражен файл /wp-content/plugins/lazy-load/js/lazy-load.js в который был прописан скрипт /wp-includes/images/crystal/gocubs.js - Скачал программой WinSCP сайт на свой локальный диск, запустил total commander, перешел в скачанную директорию и запустил поиск выражений по всем файлам:
cr"±"ipt skynet.js document.write
Все найденные вхождения почистил. И вроде даже ни чего лишнего не удалил. - Проверил вручную все скрипты, загружаемые браузером на наличие этих вхождений. Ни чего больше не обнаружил
Спустя 12 часов гугл разблокировал мой сайт, но статистика все равно просела(
Сейчас проблема решена, но теперь я сделал много выводов….
Как нужно было бы реагировать на самом деле.
Сейчас я понимаю, что таких проблем на сайтах любого уровня допускать нельзя, от этого зависит не только ваша безопасность и финансовое положение, но и наиболее важная финансовая безопасность ваших клиентов…
Если бы я отреагировал правильно еще 2 месяца назад, на сообщение моего друга о найденном подозрительном файле js в папке с картинками. Все было бы иначе.
Это стало мне серьезным уроком и теперь я буду более серьезно смотреть на такие вещи! Чего советую и всем начинающим вэб программистам и не только!
Кто мне помог в решении проблем и в чем заключалась помощь
- Александр Крайнев — техническая и моральная поддержка, подсказки и советы, хостинг с защитой от ddos (itservices.su) на котором лежит мой сайт.
- Google аналитика — не только инструмент для SEO, но и средство поиска уязвимости. Там я смотрел куда чаще всего стучатся пользователи, как и в более примитивном инструменте статистики сайта AWStats. Например у меня, в топ 10 посещаемых страниц входит в первое место страница авторизации WP)))) как не странно тот самый брут форс, нужно что то с этим делать.
- Форум инструментов вэбмастеров гугл — очень полезная, оказалось, штука!, всем советую.
- Панель отладки Google Chrome — без нее я вообще ни чего не сделал бы… (жмем F12 на исследуемой странице и исследуем исследуем исследуем).
- Putty, WinSCP, TotalCommander — как без них) всегда под рукой!
Какие выводы я сделал для себя, оказавшись на грани срыва
Нельзя доводить проблему до такого состояния. Возникшие проблемы с моим сайтом, и возможные проблемы с сайтами клиентов — только моя проблема из-за нехватки компетенции, которую буду наращивать в усиленном режиме ближайшее время.
Кому все это нужно?
Кому все это нужно? Все эти атаки, вирусы, шпионские программы? Многие знают ответ на эти вопросы. Я опишу свою точку зрения:
Есть множество людей\программистов\зловредов которые зарабатывают на том, чтобы предоставить ресурс для рекламных площадок или собирают информацию для ее дальнейшего использования все в тех же рекламных целях. Я думаю, что большинство атак на сайты и зловредных программ существуют для этих целей.
Рекламные компании в последующем покупают этот ресурс, чтобы подороже продать своим клиентам эту рекламную площадку.
Только представьте сеть из 100000 взломанных сайтов на бесплатном движке для блога — их взломал программист-зловред. Продал этот ресурс рекламной компании, рекламная компания готовит материал или ссылки для публикации, а программист в несколько кликов запускает всю эту компанию на взломанных сайтах, этот огромный трафик приносит колоссальные деньги по всему интернету.
Естественно возможных применений может быть масса, от безвредных школьников, которые просто учатся взламывать, до установки вредоносного ПО и кражу личных данных пользователей (передача 3-им лицам параметров кредитных карт, логинов и паролей от соц сетей) Все это носит глобальный характер и программисты-зловреды постоянно ищут уязвимости сайтов и популярных ресурсов.
Практические советы
Таких советов в интернете великое множество, я соберу тут действительно стоящие ИМХО:
- Никогда, ни в коем случае не оставляйте стандартные и простые имена пользователей для авторизации на своих сервисах (admin, user, login, administrator итд). Это позволит повысить защищенность на 50% минимум. Плюс к этому используйте капчу или проверку на человечность;
- Всегда делайте бэкап, тут не может быть вопросов, резервная копия должна быть всегда! Я например делаю РК локально и раз в ночь сливаю скриптом на яндекс диск через Webdav, а с диска раз в неделю перемещаю все на домашний компьютер:
Bash скрипт монтирования ЯД, копирования РК и отправки уведомления:#!/bin/sh # время, когда запускается бэкап STARTB="`date +%Y-%m-%d-%H:%M:%S`" # расположение резервных копий BACKUPDIR1="/var/www/virtual/sysrtfm.ru/backups/" # куда смонтирован яндекс диск YDISK="/mnt/yandex.disk" # папка на яндекс диске в которую копируем РК BTDIR="siteback" # путь до папки для РК на ЯД TARGETDIR="${YDISK}/${BTDIR}/" DATETIME="`date +%Y-%m-%d-%H_%M_%S`" # уникальное имя логфайла LOGFILEDATE="`date +%Y%m%d`" # путь до логфайла LOGFILE="/var/log/backupall-${LOGFILEDATE}.log" echo `date +%Y-%m-%d-%H:%M:%S`" старт бэкапа" >> $LOGFILE # размонтируем диск на всякий пожарный umount -f $YDISK >> $LOGFILE # монтируем ЯД echo `date +%Y-%m-%d-%H:%M:%S` "монтируем ${YDISK}" >> $LOGFILE mount -t davfs https://webdav.yandex.ru:443 $YDISK >> $LOGFILE #запуск РК echo `date +%Y-%m-%d-%H:%M:%S` "бэкапим в ${TARGETDIR}${DATETIME}" >> $LOGFILE mkdir ${TARGETDIR}${DATETIME} >> $LOGFILE cd $BACKUPDIR1 >> $LOGFILE cp -r -f -p * ${TARGETDIR}${DATETIME} >> $LOGFILE umount -f $YDISK >> $LOGFILE #отправляем админу уведомление ENDB="`date +%H:%M:%S`" # тема сообщения STARTEND="Backup script Start of ${STARTB} End of ${ENDB}" mail -s "${STARTEND}" [email protected] < $LOGFILE exit - Как бы это не банально звучало, но теперь я всем советую генерировать или придумывать гораздо более сложный пароль. Пароли можно хранить или в блокнотике (АНикиБеники туда не доберутся) или запомнить с 10 раза. Но в любом случае это проще чем восстанавливать доступ и решать проблемы из-за утечки информации;
- Если используете популярные web скрипты или CMS, следите за их обновлениями т.к. дырки есть всегда. Старайтесь не использовать не проверенные скрипты без отзывов. Не используйте старые и не поддерживаемые WEB скрипты;
- Всегда есть возможность защитить административный WEB интерфейс либо плагином, либо настройкой авторизации через .httpasswd (мастер генерации таких файлов, которые просто нужно положить в защищаемую директорию)
- Если есть возможность включения SSL доступа к вашим сервисам — включите его! SFTP, HTTPS, Четыре шага в защите SSH;
- Берегите свою почту, на которую все завязано! Сильный пароль, двухэтапная авторизация маст хэв!
Еще более маниакальных советов очень много. Но я считаю, приведенные выше самыми первыми для реализации. Дальше каждый сам для себя решит на сколько далеко он может зайти в защите своих сервисов.
PS:
И так, я победил тьму, и я очень рад) опыт накоплен, сайт работает, система живет) осталось теперь только обсудить это с уважаемым сообществом habrahabr, но для ответа в комментариях мне нужен инвайт, поэтому я прошу НЛО запостить эту статью и подарить мне на Новый Год инвайт)
И я тогда, в свою очередь, зарегистрируюсь в проекте анонимных дедов морозов и подарю залежавшиеся полезные мелочи Хабраюзерам:
С Уважением Иван Левкин.
| Термокружка Canon EF 24-105 с блендой — точная копия одноименного объектива. Кружка оснащена металлической термоколбой для сохранения постоянной температуры напитков, а так же герметично завинчивающейся крышкой с резиновой прокладкой. |
|
| Compact Slim Retractable Cable Style USB 2.0 Optical Mouse — Black (80CM-Cable) |
|
| EDUP Ultra-Mini Nano USB 2.0 802.11n 150Mbps Wifi/WLAN Wireless Network Adapter |
Что делать, если взломали сайт на WordPress
Рано или поздно ваш ресурс может быть подвергнут несанкционированному доступу, тем более, когда сайт имеет определенную популярность. Всегда нужно быть настороже и хотя бы руководствоваться начальными советами по безопасности WordPress. Это повысит уровень защиты и поможет восстановить прежнее состояние сайта.
Но если уже случился взлом, тогда рассмотрим какие меры необходимо принять, дабы спасти свой труд и дать отпор недоброжелателю. В первую очередь, как бы вы сильно не паниковали, нужно успокоиться, дышать ровно и с уверенностью решать проблему. Во вторую очередь, сразу сканируйте свой компьютер на наличие стороннего программного обеспечения (вируса). А после переходим к последующим действиям.
Как узнать, что взломали сайт?
После взлома сайта, когда злоумышленнику открывается полный доступ управления или частичный, происходит, как правило, внедрение опасных скриптов. По сути, это реклама, вирусы и прочий мусор, который точно угробит ресурс. Самые распространённые выявления взлома:
- На сайте появились не знакомые вам ссылки, ведущие на сторонние ресурсы.
- На сайте установлена непонятная переадресация.
- В кабинете вебмастера Google появилось сообщение, что на сайте обнаружены проблемы с безопасностью.
- Не можете войти в админ-панель сайта.
Если с вашим сайтом происходит что-то подобное из списка выше, то наверняка вы стали целью взломщика. В таком случае читаем ниже написанный мануал о лечение сайта и его восстановлении.
Первые меры применения при взломе сайта WordPress
Закрыть сайт на тех.обслуживание. До решения и выявления проблемы желательно ограничить посещение к ресурсу. То есть закрыть сайт на техническое обслуживание, чтобы пользователи не ощутили ни удобства в случае, если на сайте будет установлена переадресация на порно-ресурсы или вирусные сайты.
Сканирование ПК. Существует большая разновидность программных вирусов, целью которых является за получение личных данных. Они могут попасть на компьютер самыми различными путями. У вас на ПК должен быть установлен работающий антивирус, способный находить паразитов, а не заводить с ними дружбу. Вашим первым действием будет тщательное сканирование ПК на поиск вирусов, программ, ворующих пароли и.д. Это поможет определить вашу уязвимость.
Обращение к хостингу-провайдеру. Дальше следует обратиться к вашему хостингу с вопросом их безопасности. Так как, может быть, имеются следы массового взлома сайтов, которых объединяет один и тот же хостинг. Это будет явным признаком исходящей проблемы. А также обратите внимания на попытку смена почты вашего аккаунта и другие ранее неизвестные вам изменений. В общем, что-то странное и непонятное.
Логи сайта. В тех. поддержки хостинга запросите журнал (лог-файлы) веб-сервера, FTP-сервера за весь доступный период. Проанализируйте их в поиске странных изменений или даже входов на сайт. Возможно, удастся обнаружить исходную точку взлома или же укажет правильный путь поиска. В общем, любые крошки, следы могут оказаться очень важной деталью.
Смена паролей. Прежде чем вы начнете искать на сайте вирус, следует вначале сменить все пароли и логины на всех ресурсах, программах имеющие хоть какое-то отношение к вашему сайту. И конечно же, изменить пароли и логины к взломанному сайту, базе данных, FTP-клиенту, cPanel, расширению протокола SFTP, эл.почте. Еще один момент, смотрите чтобы в БД не было создано новых пользователей, если такие имеются, то полностью удаляйте их.
Восстановить сайт из резервного копирования. Полагаться наудачу, да еще в таком деле, будет очень глупой ошибкой. Нельзя думать, что файлы сайта, как и сама база дынных останутся в целом состоянии. Всегда, запомните, всегда у вас должно быть свежее резервное копирование полного сайта, это как раз на критический случай. Вам нужно будет полностью удалить файлы сайта, залить новые из бэкапа и точно так же проделать с БД. Только используйте бэкап, созданный до взлома сайта.
Обновление ПО. Часто случается причиной взлома – уязвимость плагинов, особенно, старых версий. Всегда при доступном обновлении модулей, тем и самой платформы следует обновляться. В новых версиях разработчики стараются закрыть все доступные дыры. Естественно, это повышает безопасность. Поэтому нужно об этом не забывать и следить за обновлением.
Сервисы поиска вирусов на сайте. В интернете можно найти много различных сервисов по поиску вирусов на сайте. Они могут оказаться полезными, даже, несмотря на то, что многие из них бесплатные. Кроме сервисов, имеются также отдельные скрипты, плагины, сканирующие сайт. Некоторые из них: https://www.virustotal.com/, http://antivirus-alarm.ru/proverka/, http://xseo.in/viruscan, https://sitecheck.sucuri.net/, https://www.revisium.com/ai/
Что делать, если нет резервного копирования сайта
Без резервного копирования будет очень трудно восстановить сайт, но все-таки это возможно. Придется проявить больше усилий, стараний, времени, ну, или обратиться к специалистам за небольшую плату. По сути, проделывается все то, что написано выше. Главное, найти уязвимость, то есть откуда был совершен подкоп: подбор пароля в админ-аккаунту, кража пароля FTP-клиента, дыры в темах, плагинов и т.д.
Это основная часть работы, а дальше следует найти тот самый неуловимый вирус. Необходимо просмотреть все папки сайта начиная с корневых, заглянуть в конфигурационный файл (.htaccess), посмотреть все индексные файлы. Искать нужно файлы, изменённые за последнее время, php-скрипты (веб-шеллы) обычно именуемые довольно странно (drvx.php, tvd1660f.php), и смотреть все остальные файлы, которые могут вызывать сомнения. Первую очередь проверьте директории, разрешающие загрузку файлов (uploads, tmp, images, cache, user_files и т.д.)
Еще о безопасности
В заключение добавлю еще несколько полезных советов о безопасности. Для удобства они изложены в статье о файле .htaccess в WordPress, где вы найдете способы блокировки и защиты важных файлов. А также задумайтесь о переходе на выделенный сервер, если того позволяют средства.
Официальный мануал WordPress в случае взлома сайта: https://codex.wordpress.org/FAQ_My_site_was_hacked
Еще один мануал — http://www.secbot.org/what-todo-if-hacked/
На этом, пожалуй, закончим.
Происходит редирект, взломали сайт | WordPress.org Русский
Модератор Yui(@fierevere)
ゆい
https://ru.wordpress.org/support/topic/%d0%b2%d0%b7%d0%bb%d0%be%d0%bc%d0%b0%d0%bb%d0%b8-%d1%81%d0%b0%d0%b9%d1%82%d0%bf%d1%80%d0%be%d0%b8%d1%81%d1%85%d0%be%d0%b4%d0%b8%d1%82-%d1%80%d0%b5%d0%b4%d0%b8%d1%80%d0%b5%d0%ba%d1%82/
дубль, и там я вам кинула ссылку на страницу в кодексе, что нужно делать
ту тему закрою, т.к. в ней меньше информации
Сегодня была такая же тема, оказалось все проще чем кажется, надо лишь зайти в Базу Данных, и там в wp_options вернуть siteurl на свой.
Модератор Yui(@fierevere)
ゆい
в wp_options вернуть siteurl
обычно взломщики такого не делают, разве что случайно что-то пошло у них не так.
Такое обычно делают сами администраторы сайта
обычно взломщики такого не делают, разве что случайно что-то пошло у них не так.
Такое обычно делают сами администраторы сайта
У меня вот так произошло, вчера утром взломщик как то зарегистрировался и сменил siteurl.
Этот сайт делает по другому
Он прописывает вирус в head блогах. Это в шаблонах. При чем в любых CMS
А так же в корне
wp-load.php
wp-links-opml.php
Удаляйте его код.
Модератор SeVlad(@sevlad)
wp.me/3YHjQ
Удаляйте его код.
Вы перепутали тех. форум с ТВ «шоу».
sevlad, а Вы бы лучше рекомендации давали, а не прикалывались. Не хорошо так модератору!!!
Нужно перелазить эти файлы
wp-load.php
wp-links-opml.php
А в Вашей теме в файле header.php может быть такие коды, удалите их.<script language=javascript>var _0xfcc55=["\x66\x72\x6F\x6D\x
(@sevlad)
wp.me/3YHjQ
а Вы бы лучше рекомендации давали, а не прикалывались. Не хорошо так модератору!!!
Они даны сразу же в первом ответе (yui). Печально, что их не замечают и дают разные «советы» — фантазии.
А в обязанности модератора как раз и входит следить за порядком на форуме.
«heavenlydevil (@heavenlydevil)
4 мес., 3 нед. назад
Сегодня была такая же тема, оказалось все проще чем кажется, надо лишь зайти в Базу Данных, и там в wp_options вернуть siteurl на свой.»
Сегодня именно этим способом вылечился. Да, и кроме siteurl нужно так же и home изменить на свой домашний url поменять! Спасибо, heavenlydevil!
Сегодня именно этим способом вылечился.
Неужели кроме этого больше ничего нет? Звучит как-то слишком просто.
конечно не просто — надо плагин удалить, который виноват в этом. Иначе снова появится сайт для редиректа.
Самой основной защитой является установка постоянно обновляемых и с высоким рейтингом плагинов. Там, где разработчики следят за своими плагинами — там меньше всего вероятность взлома.
Далее нужно устанавливать защиту на свои блоги, а не делать это тогда, когда жаренный петух в задницу клюнул.
11 апреля у меня тоже был взломан блог, и точно также был редирект на другие страницы. Я сам не смог найти причину и обратился к специалисту. Он мне сказал, что это муторное дело, но вылечить можно. Но нет гарантии того, что все удалится. Поэтому предложил мне менее затратное дело, сделать на хостинге откат блога, что я и сделал.
Откатил я на сервере свой блог до бекапа за 9 апреля. В результате я потерял только несколько комментариев своих читателей и пришлось заново опубликовать один пост. Поэтому, если вы точно знаете дату взлома и у вас делаются на вашем хостинге регулярно на автомате бекапы, то смело откатывайте и не морочьте себе голову. Для перестраховки делайте откат на несколько дней назад. Лучше потерять несколько комментариев и постов (потом возобновить), нежели все время быть в напряге и думать, не осталось еще чего-то.
Кстати, мой блог в поисковых системах после взлома был помечен, как опасный для посещений. В Гугле после отката сходу был дан моему блогу зеленый свет, а Яндекс расчехлялся целую неделю. Я уже обращался в службу поддержки веб-мастера, но, как обычно, ответил Платон Щукин, типа наш антивирус обходит сайты раз в неделю и мы не можем повлиять на его график обхода. Вы представляете, целую неделю мне пришлось ждать и терять трафик. В общем Яндекс конченный урод, извините, но это так и есть.
Самой основной защитой является установка постоянно обновляемых и с высоким рейтингом плагинов. Там, где разработчики следят за своими плагинами — там меньше всего вероятность взлома.
Это большое заблуждение. К примеру, владельцы сайтов часто любят устанавливать плагины «безопасности», ну чтобы вроде бы как оградить свои проекты от взломов. В итоге эти самые плагины «безопасности» сами иногда становятся точкой входа в систему, и высокий рейтинг плагина не даёт никаких гарантий. Или ещё частый случай: установили, активировали и забыли, ничего толком и не настроив. Или другой подход: установили, активировали и выкрутили на максимум, так что либо сами потом не могут нормально пользоваться сайтом, либо растут «отказы».
Я сам не смог найти причину и обратился к специалисту. Он мне сказал, что это муторное дело, но вылечить можно. Но нет гарантии того, что все удалится. Поэтому предложил мне менее затратное дело, сделать на хостинге откат блога, что я и сделал.
Это не специалист, а любитель. Ну или вас просто «вежливо отшили».
Поэтому, если вы точно знаете дату взлома и у вас делаются на вашем хостинге регулярно на автомате бекапы, то смело откатывайте и не морочьте себе голову.
Далеко не всегда всё так хорошо, и нет гарантии, что у вас бекап не будет с другими закладками или что вы сможете всё обновить достаточно оперативно, прежде чем вас попытаются на автомате взломать снова.
Вы представляете, целую неделю мне пришлось ждать и терять трафик. В общем Яндекс конченный урод, извините, но это так и есть.
Яндекс никак не отвечает за стабильную работу вашего сайта, и странно обвинять компанию в своих ошибках. Гугл — это Гугл, у них другие мощности и другие возможности.
С той же проблемой боролся две недели, постоянно после отката с бекапа вставляли редирект максмимум через 6-8 часов после восстановление, нагуглил что уявзмим плагин Related Posts Yuzo, после сноса плагина взломы прекратились. Может у Вас та же история.
вот решение: https://searchengines.guru/showthread.php?t=1013982&page=2
zashibiz, 1 — за почти полгода, думаю, ТС уже решил свою проблему; 2 — про «Yuzo» тут уже несколько тем есть и описаны решения; 3 — вот это: «Дата регистрации: 27.04.2019» и «Ответов создано: 1» со ссылкой на сторонний ресурс выглядит как-то подозрительно.
Почему взламывают WordPress-сайты, и как этого избежать?
WordPress является самым популярным в мире “движком” для генерации готовых веб-сайтов. На его основе создано и успешно функционирует более 31% всех сайтов в Интернете, что означает сотни миллионов веб-ресурсов по всему миру. Такая популярность WordPress позволяет хакерам легко находить менее безопасные сайты и использовать их в своих корыстных целях.
У хакеров есть разные мотивы для взлома веб-сайта. Некоторые из них – новички, которые просто учатся использовать менее безопасные сайты. По большей части за взломом преследуются следующие цели:
- распространение вредоносного ПО;
- использование сайта для атаки на другие сайты;
- рассылка спама в Интернете;
- добывание криптовалют.
С учетом вышесказанного, давайте рассмотрим некоторые из главных причин взлома сайтов WordPress и способы их предотвращения.
1. Небезопасный хостинг
Общеизвестно, что все веб-сайты размещаются на веб-сервере хостинга. Но некоторые хостинговые компании не обеспечивают надлежащую защиту своей хостинговой платформы. Это делает все веб-сайты, размещенные на их серверах, уязвимыми для попыток взлома.
Этого можно легко избежать, выбрав лучший хостинг-провайдер WordPress для вашего сайта (например, Beget). Это гарантирует, что ваш сайт размещен на безопасной платформе. Правильно защищенные серверы могут блокировать многие из наиболее распространенных атак на сайты WordPress.
2. Использование простых паролей
Пароли – это ключи к вашему сайту WordPress. Вы должны убедиться, что используете уникальный пароль для каждой учетной записи, поскольку они могут предоставить хакеру полный контроль над вашим сайтом.
Наиболее уязвимыми являются:
- учетная запись администратора WordPress;
- учетная запись панели управления хостингом;
- FTP-аккаунты;
- база данных MySQL;
- учетные записи электронной почты.
Все эти учетные записи защищены паролями. Использование слабых паролей облегчает хакерам их взлом.
Вы можете легко избежать этого, используя уникальные и надежные пароли для каждой учетной записи. О том, как создать надежный пароль, мы писали в одной из наших прошлых статей.
3. Незащищенный доступ к админ-разделу
Область администрирования WordPress предоставляет пользователю доступ для выполнения различных действий сайте. Это также наиболее часто атакованная область сайта WordPress.
Оставляя ее незащищенной, хакеры могут попробовать разные подходы к взлому вашего сайта. Вы можете затруднить их работу, добавив уровни аутентификации в свой каталог администратора WordPress.
Сначала вы должны защитить паролем свою административную область WordPress. Это добавляет дополнительный уровень безопасности, и каждый, кто пытается получить к ней доступ, должен будет ввести дополнительный пароль.
Кроме того, следует обеспечить надежные пароли для всех пользователей вашего сайта. Вы также можете добавить двухфакторную аутентификацию, чтобы еще более затруднит проникновение хакеров в область администрирования WordPress.
4. Неверные права доступа файлов
Права доступа для файлов – это набор специальных правил, используемых вашим веб-сервером. Они помогают веб-серверу контролировать доступ к файлам на вашем сайте. Неправильные права доступа могут дать хакеру доступ для записи и изменения этих файлов.
Для всех ваших файлов WordPress права доступа должны иметь значение 644, а для папок – 755.
5. Отказ от обновлений ядра WordPress
Некоторые WordPress-пользователи боятся обновлять свои сайты WordPress, опасаясь, что это нарушит их работу.
Следует отметить, что каждая новая версия WordPress исправляет ошибки и уязвимости безопасности. Если вы не обновляете WordPress, вы намеренно оставляете свой сайт уязвимым.
Если вы опасаетесь, что обновление “сломает” ваш сайт, то можете создать полную резервную копию WordPress перед запуском обновления. Таким образом, если что-то пойдет не так, вы можете легко вернуться к предыдущей версии.
О том, как в WordPress сделать резервную копию сайта, мы детально рассматривали в одном из прошлых материалов.
6. Отказ от обновлений плагинов и тем
Обновление до свежих версий плагинов и тем, как и ядра WordPress, тоже является очень важным. Устаревшие их версии также могут сделать ваш сайт уязвимым для хакеров.
“Дыры” в безопасности и ошибки часто обнаруживаются в плагинах и темах WordPress. Обычно их авторы быстро исправляют их. Однако, если пользователь не обновляет свою тему или плагин, то они ничего не могут с этим поделать.
Убедитесь, что ваша тема WordPress и плагины обновлены.
7. Использование простого FTP вместо SFTP/SSH
Учетные записи FTP используются для загрузки файлов на ваш веб-сервер с помощью FTP-клиента (например, FileZilla). Большинство хостинг-провайдеров поддерживают FTP-соединение с использованием разных протоколов. Вы можете подключиться, используя простой FTP, SFTP или SSH.
Когда вы подключаетесь к своему сайту с помощью простого FTP, ваш пароль отправляется на сервер незашифрованным. Его можно легко украсть. Вместо использования FTP вы всегда должны использовать SFTP или SSH.
Вам не нужно будет менять свой FTP-клиент. Большинство FTP-клиентов могут подключаться к вашему сайту по SFTP, а также SSH. Вам просто нужно изменить протокол на SFTP/SSH при подключении к серверу вашего сайта.
8. Использование admin в качестве логина администратора
Использование admin в качестве логина администратора WordPress не рекомендуется. Следует немедленно изменить его на другое имя пользователя. Это было подробно описано в нашем материале.
9. Использование “зануленных” тем и плагинов
Как было детально рассмотрено в нашей статье, Nulled-продукты являются пиратскими копиями платных тем и плагинов, распространяемых незаконно в Интернете. Они не только могут поставить под угрозу безопасность вашего веб-сайта, но также стать причиной кражи конфиденциальной информации.
Вы всегда должны загружать плагины и темы WordPress из надежных источников, таких как веб-сайт разработчиков плагинов/тем или официальных репозиториев WordPress.
Если вы не можете позволить себе или не хотите покупать премиум-плагин или тему, то для этих продуктов всегда есть бесплатные альтернативы. Они могут быть не такими хорошими, как их платные версии, но все же будут выполнять свою работу и, самое главное, сохранят ваш сайт в безопасности.
10. Отсутствие защиты файла wp-config.php
wp-config.php – основной файл конфигурации WordPress, в котором хранятся секретные ключи безопасности, данные для подключения к базе данных и прочая важная информация. Если эти данные попадут в руки хакеров, то они смогут получить полный контроль над вашим сайтом. Как защитить wp-config.php, было рассмотрено в следующем материале.
11. Используется стандартный префикс таблиц базы данных
Многие эксперты рекомендуют изменить установленный по умолчанию префикс таблиц WordPress. Эксперты рекомендуют использовать более сложный префикс, что усложнит для хакеров “угадывание” имен вашей базы данных.
Подробная инструкция изменения префиксов таблиц описано в нашей статье.
Если Вам понравилась статья — поделитесь с друзьями
Как взломать сайт на WordPress с помощью комментария
Как взломать сайт на WordPress с помощью комментария
Как взломать сайт на WordPress с помощью комментария
Всем привет сегодня расскажу как взломать сайт на WordPress с помощью комментария. На платформе WordPress работает пятая часть всех сайтов в интернете, так что малейшая уязвимость в CMS или популярных плагинах привлекает пристальное внимание. Тем более такой мега-баг, какой обнаружил финский хакер Йоуко Пиннонен (Jouko Pynnönen) из компании Klikki Oy. Он раскрыл технические подробности в минувшее воскресенье.
Как взломать wordpress
Критическая уязвимость 0day (на момент публикации в воскресенье патча не было, но он вышел в понедельник) затрагивает встроенную систему публикации комментариев WordPress, которая до сих пор широко используется на многих сайтах. Оказывается, если опубликовать достаточно длинный комментарий (64k символов), то можно вызвать баг, который приводит к исполнению постороннего кода с этой HTML-страницы.
Образец комментария
Как взломать сайт на WordPress с помощью комментария-01
<a title='x onmouseover=alert(unescape(/hello%20world/.source)) style=position:absolute;left:0;top:0;width:5000px;height:5000px AAAAAAAAAAAA...[64 kb]..AAA'></a>Код будет исполнен для каждого, кто зайдёт на страницу с таким комментарием, в том числе на компьютере администратора системы, установив в системе бэкдор
Как взломать сайт на WordPress с помощью комментария-02
Уязвимость актуальна для WordPress 4.2 и более ранних версий. Она похожа на аналогичный баг с комментариями, который исправили на прошлой неделе, но там исполнение кода инициировалось через специальный символ, а здесь — через объём комментария.Патч вышел в понедельник 27 апреля.
Если вы не обновляете ваш движок, то взлом сайта на wordpress будет на много проще для злоумышленика, ставьте апдейты своевременно.
Материал сайта pyatilistnik.org
Иван СеминКак хакеры используют взломанные WordPress-сайты – Oddstyle.ru – все о WordPress
Мы часто разговаривали с владельцами сайтов, которые были весьма удивлены, что их сайты становились целью атак со стороны злоумышленников. Большинство из них исходили из предположения, что если на сайте нет ценных данных для кражи, таких как номера кредитных карт, то взлом сайта будет являться бесполезным трудом. К сожалению, они оказывались неправы. Злоумышленники могут получать доход с посетителей взломанных сайтов самыми разными способами, не только при помощи кражи данных. Веб-сервер может использоваться для выполнения вредоносных программ и размещения различного контента.
В прошлом месяце мы провели исследование, которое включало в себя следующий вопрос для людей, отметивших, что их сайт был взломан:
«Что хакеры сделали с вашим сайтом?»
Мы получили в общей сложности 873 ответа, которые были каталогизированы нами, как показано на графике ниже. Многие из ответов подпадали под разные категории.
Мы не стали размещать такие ответы, как «установили бэкдор» или «установили вредоносное ПО». Это может быть сделано с разными целями. Вместо этого мы решили узнать, как именно злоумышленники использовали взломанный сайт.
Как видно из диаграммы, злоумышленники выполняют самые разные вещи с взломанными WordPress-сайтами. Давайте рассмотрим каждый из этих вариантов, чтобы лучше понять, как противостоять взломщикам.
Дефейс сайта / вывод сайта из строя
В некоторых случаях хакеры заменяют ваш контент своим собственным. Чаще всего этим промышляют террористические группы, публикуя свои политические заявления на взломанных ресурсах. Еще одним распространенным случаем является простое хвастовство со стороны хакеров – они гордятся тем, что взломали ваш сайт. Во всех этих случаях нападающий не делает совершенно ничего, чтобы скрыть последствия взлома – любой посетитель сайта сразу же поймет, что ресурс был взломан.
В других случаях нападающие просто выводят ваш сайт из строя. Исходя из нашей практики, в большинстве случаев злоумышленник просто допускает какую-либо ошибку и случайно «вырубает» сайт.
Пример дефейса:
Чем это полезно для нападающих?
Для тех, кто взламывает ваш сайт и публикует на нем свою политическую пропаганду, ваша площадка – это просто способ бесплатно прорекламировать свои взгляды. Злоумышленники, хвастающиеся тем, что взломали ваш сайт, ищут признания.
Рассылка спама
Email-спам остается огромной проблемой. Согласно Statistica, в декабре 2015 на долю спама пришлось 54.4% всего email-трафика сети. По данным опрошенных нами пользователей, 19.8% взломанных WordPress-сайтов использовались для рассылки email-спама.
В большинстве случаев владелец сайта довольно долгое время не знал, что произошел взлом его ресурса. В некоторых случаях владельцы сайта отмечали падение производительности сайта или проблемы с использованием сервера. Либо их хостер отмечал это и рассылал им предупреждения.
К сожалению, довольно большой процент владельцев сайтов узнавали о рассылке спама только тогда, когда их домен был внесен в черный список различных сервисов, таких как, к примеру, Spamhaus. Если вы полагаетесь на email для общения с клиентами, то в таком случае это может иметь разрушительные последствия.
Чем это полезно для нападающих?
Нападающий получает двойной профит. Во-первых, он бесплатно использует ресурсы сервера, за которые вы платите. Во-вторых, пока злоумышленник не успел разрушить вашу репутацию, он может извлечь выгоду для себя из рассылки email с вашего домена и IP-адреса. В конечном счете, взломщики пытаются заставить пользователей перейти на их вредоносные сайты.
SEO-спам
Есть много способов эксплуатации вашего сайта злоумышленниками для улучшения ранжирования своих сайтов в поисковой системе. Первый способ – простое размещение страниц на вашем домене, получая выгоду от его хорошей репутации и авторитетности. Пример такой страницы ниже.
Другой способ – размещение ссылок на другие сайты на вашем ресурсе. Это позволит злоумышленникам получить неплохой прирост в плане SEO. Обратные ссылки до сих пор остаются важным SEO-фактором, поэтому хакер, взломавший многочисленные сайты, может добиться серьезного роста SEO-показателей.
Многие наши респонденты использовали термин «фарма-хак», чтобы описать данный тип атак, поскольку эти атаки не так давно использовались для продвижения фармацевтических сайтов.
Пример html-страницы, которую нападавший скрыл на зараженном сайте.
Чем это полезно для нападающих?
Я считаю, что многие из вас знают, что выход в топ поисковой выдачи – отличный способ привлечь трафик к сайтам. С помощью SEO-спама хакеры могут направлять трафик с легитимных сайтов на свои собственные ресурсы.
Вредоносные редиректы
Редиректы – невероятно эффективный способ направления трафика к вредоносным сайтам. Пользователю даже не нужно кликать по ссылкам или рекламе – он сразу же перенаправляется на сайт злоумышленников.
Иногда атакующие прибегают к очень агрессивному подходу, перенаправляя весь трафик к вредоносным сайтам. Однако в большинстве случаев хакеры используют меры, позволяющие избежать обнаружения – к примеру, перенаправляют только некоторые URL-запросы или активируют редирект только для определенных браузеров или типов устройств.
Чем это полезно для нападающих?
Основная мотивация для хакеров – получить трафик для своего вредоносного контента.
Размещение фишинговых страниц
Фишинговые страницы пытаются обмануть посетителя, заставив его предоставить конфиденциальную информацию. В некоторых случаях фишинговые страницы маскируются под популярные банки или магазины, пытаясь заполучить ценную информацию, такую как номер кредитной карты. Иногда они создаются для получения логина и пароля к разным сайтам, включая ваш WordPress-сайт.
Пример фишинговой страницы:
Чем это полезно для нападающих?
Ценность номера вашей кредитной карты очевидна. Злоумышленники могут использовать полученные данные для входа в ваши онлайн-аккаунты, применяя их в социальном инжиниринге или для фишинговых атак и компрометации вашей личности.
Распространение вредоносного ПО
Как только хакеры взломали ваш сайт, они могут установить вредоносный софт, который будет ставить разные вирусы на компьютеры посетителей вашего сайта без их ведома. Это – самое страшное последствие для вас как владельца сайта.
Если Google обнаружит, что это произошло, он будет сигнализировать об этом другим посетителям. В итоге SEO-показатели вашего сайта заметно просядут. Что еще хуже, посетители вашего сайта, зараженные вирусами, вряд ли будут тепло относиться к вам.
Влияние этого на вашу репутацию будет длительным и очень серьезным. К счастью, только 2.9% респондентов сообщили об этом.
Чем это полезно для нападающих?
Установка вредоносного софта на сотнях и тысячах компьютеров посетителей вашего сайта предоставит нападающему прямой доступ к ценной информации и нанесению ущерба пользователям.
Кража пользовательских данных
Мы были приятно удивлены, что, несмотря на наше предположение, что взломщиков интересуют ценные данные пользователей, лишь 1.1% наших респондентов сообщили о краже данных в результате взлома их WordPress-сайтов.
Мы считаем, что главная причина этого кроется в том, что большинство WordPress-сайтов не хранит ценные данные пользователей (кроме логинов/паролей и, возможно, email-адресов). Также стоит отметить, что владельцам взломанных сайтов достаточно сложно обнаружить случившееся воровство данных, поэтому цифры, скорее всего, являются преуменьшенными.
Чем это полезно для нападающих?
Украденные пользовательские данные могут использоваться для восстановления доступа к сайту, даже если сам сайт уже был очищен от вирусов. Комбинация логина и пароля может также подходить и к другим сайтам, если пользователь применяет одни и те же данные.
Украденные email-адреса могут использоваться для спама. Очевидно, более высокую ценность имеет такая информация, как данные кредитных карт.
Атака на другие сайты
В некоторых случаях злоумышленник принимает решение использовать ваш веб-сервер как платформу для проведения атак на другие сайты. Это относительно редко встречается на практике, если анализировать ответы наших респондентов – примерно в 0.7% случаев.
Чем это полезно для нападающих?
Атакующий бесплатно использует ваш сервер в своих целях. К тому же злоумышленники с большей вероятностью смогут обойти защиту своих целей, используя атаки с вашего домена и IP-адреса. По крайней мере, до тех пор, пока они не разрушат вашу репутацию.
Программы-вымогатели
Это такие программы, которые блокируют доступ к вашему сайту и требуют оплаты, чтобы вы смогли вновь пользоваться ресурсом. Этот тип атак недавно попал в объективы блогов и прессы. Мы были удивлены тем, что только 0.6% опрошенных нами людей сообщили про данный тип атак.
Пример подобных атак:
Чем это полезно для нападающих?
Если у вас нет бэкапов, то в таком случае вы можете принять решение, что оплата злоумышленнику – единственный способ сохранить свой сайт. Вы переведете ему средства, в результате чего взломщик сможет заработать на вас. Выгода – основной мотив этого подхода.
Размещение вредоносного контента
Хакеры будут использовать ваш сервер для размещения вредоносных файлов, которые могут вызываться с других серверов. По существу, они используют ваш хостинг-аккаунт в качестве файлового сервера.
Чем это полезно для нападающих?
Атакующий получает бесплатное хранилище файлов, которое имеет отличную репутацию (доверенный домен и IP-адрес).
Referrer-спам
Если вы использовали ранее Google Analytics, вы, скорее всего, сталкивались уже с referrer-спамом. Referrer-спам – это трафик, который приходит с поддельного реферера. Спамер пытается заставить владельца сайта перейти по ссылке в реферере, привлекая трафик на свой сайт.
Пример такого спама:
Чем это полезно для нападающих?
Как уже было со многими другими видами вредоносной активности, хакеры пытаются бесплатно использовать ваш сервер, прикрываясь доверенным IP-адресом. Их конечная цель – привлечь трафик к своим сайтам. А уже на сайтах может располагаться вредоносное ПО.
Заключение
Если вы считали ранее, что ваш сайт не является «лакомым кусочком» для злоумышленников, то теперь, мы надеемся, вы уже так не считаете. Теперь вы знаете, какие мотивы имеют злоумышленники, почему они ломают сайты, как они их потом эксплуатируют.
Немного о бэкапе, или как я случайно взломал чужой блог на WordPress
Итак, это небольшая запись о том, как взломать блог на вордпресс. Не поймите меня неправильно — вернее о том, как у меня это совершенно случайно получилось. Долго думал, писать все-таки об этом, или нет, так как нехорошие люди могут воспользоваться этим в своих весьма нехороших целях, но потом — решил таки написать. Потому что если даже я, который не имеет никакого отношения к защите, сайтам и т.д. смог это сделать, то юные кулхацкеры, просто со скуки ищущие, как взломать сайт или блог на вордпресс — уж тем более смогут, и предупредить об этом на будущее всех остальных все-таки надо. Ну, и тем более, пробежавшись по просторам интернета — оказалось, что в настоящее время сайтов, подверженных такой уязвимости — практически нет, и лучше уже сейчас обозначить проблему, чтобы они не появились и в дальнейшем.
А началось все до жути банально — я, раньше делавший бэкап сайта вручную путем тупого копирования всех существующих папок на сервере себе на локальный компьютер, затем лезущий в phpMyAdmin, и оттуда сохраняющий дамп базы, решил поставить себе плагин, позволяющий делать это в автоматическом режиме. Выбор пал на BackWPup, как обладающий самыми широкими настройками по регулярности бэкапов, позволяющий делать копии не только базы данных, но и всех файлов на сайте, а также поддерживающий создание бэкапов не только на сервере, но и скидывание их по ФТП, в дропбокс, e-mail, и т.д.
И вот, раздумывая, куда бы класть файлы по фтп, я набрел на один очень занятный хостинг файлов, а вернее — файлхранилище с доступом по ftp — fileplaneta.com. Однако, как оказалось при ближайшем рассмотрении, он не только не шифрует ссылки на закачанные на него файлы, но и по умолчанию при загрузке включает их публичный доступ, так что все файлы, как на ладони высвечиваются у любого пользователя зашедшего на этот ресурс, более того — присутствует сортировка и продвинутый поиск. Сразу возникла мысль — как же так, это значит, что любой бэкап, закачаный туда, сразу станет достоянием общественности? Решил это проверить. BackWPup создает по умолчанию архивы со стандартными наименованиями, по которым я и задал поиск, сразу же найдя пару. Нет, это какой-то бред, подумал я, такого просто не может быть. Ладно, давайте посмотрим, а можно ли вообще что-нибудь с этим сделать. Честно говоря, все остальное я делал, вовсе не намереваясь кого-либо ломать, или чего еще в этом духе, абсолютно не разбираясь в этом, и предполагая, что где-то там будет непреодолимая преграда и защита, которую я просто не смогу пройти. Иными словами, на примере найденых бэкапов хотел проверить, что же меня ждет, если я к нему (файлпланете) привяжу BackWPup. Но все произошло так быстро, что я даже не успел опомниться. В скачаном бэкапе конечно же, лежал файл wp-config.php, в котором, конечно же, лежали в незашифрованом виде все данные доступа к базе данных сайта, включая логин, пароль, хост, к которому коннектится. Запустил первый попавшийся клиент для управления и администрирования MySQL под windows (первым попался какой-то SQLyog Community Edition — жутко тупая программа в сравнении с phpMyAdmin, как мне показалось — но честно говоря, я в этом абсолютно не разбираюсь, поэтому точно утверждать не буду, может это в умелых руках — наоборот верх совершенства :)). Ввел туда всю информацию из wp-config.php, нажал кнопку соединиться — бац — я в чужой базе данных. Нет, понятно, что реальные е-мэйлы автора, умело скрытые на сайте, логины и пароли в зашифрованом виде были доступны из ее дампа уже в бэкапе — но то, что можно будет так просто войти — этого я уже совсем не ожидал. Стало интересно, а смогу ли я войти в сам блог? Кул хацкер, скорее всего, недолго думая, поменял бы пароли админов, а заодно и е-мэйл, и выслал бы себе новый. Но поскольку меньше всего я хотел кому-то причинить какой-либо вред, то я просто создал в таблице wp_users еще одного пользователя, назвав его незамысловато wordpress, и даже не вводя е-мэйл, никнейм, и всю основную лабуду, сгенерировал MD5 пароль, тоже вставив его в таблицу, после чего дал этому юзеру права администратора в таблице wp_usermeta, присвоив значение wp_user_level равный 10 и прописав wp_capabilities в виде a:1:{s:13:»administrator»;b:1;}. Еще безопаснее для блога, конечно, было подобрать пароль по md5 хэшу, (судя по всему, он был не сильно сложный), но меня интересовала принципиальная возможность входа в админку, поэтому совсем уж заморачиваться я не стал. В браузере к адресу сайта я добавил /wp-admin, ввел логин wordpres и пароль, для которого я генерировал md5 хэш, и спустя секунду я был уже в админке. Это я все так долго описываю, а на самом деле все заняло не больше двух минут, из которых самое долгое — было скачивание windows клиента для администрирования MySQL. Честно говоря, я аж офигел, ну никак не ожидал такого, и под некоторым впечатлением нахожусь даже сейчас. Сначала я подумал, что надо написать автору сайта на е-мэйл, чтобы он убрал бэкапы с этого хостинга, поменял все пароли (никто не знает ведь, кто еще мог уже успеть скачать бэкап его сайта до меня, маловероятно, что я первый до этого додумался), и впредь более осмотрительно относился к безопасности, но звучало все это так невероятно, что для демонстрации возможности я оставил предупреждение в виде черновика в самой админке, хотя так и подмывало нажать кнопочку опубликовать :).
После чего еще и комментарий к одной из записей отправил, чтобы черновик случайно не затерялся. Ну и предупредил автора, что через неделю опубликую информацию о этой дыре и способам защиты на своем проекте, чтобы он успел все закрыть, и удалить. Сейчас все закрыто и удалено, так что я со спокойной душой публикую эту запись.
Анализируя произошедшее, можно вывести несколько основных причин, по которым это все стало возможным. Ни одна из них в отдельности не привела бы к такому результату, но в совокупности — они дали такой вот печальный результат:
1. Выкладывание бэкапа на общественный ресурс.
2. Доступ любого пользователя к ссылке на его скачивание.
3. Возможность удаленного редактирования базы данных.
Остается порадоваться за автора сайта, что к нему на огонек зашел я, а не какой-нибудь юноша с горящим взором. Могло бы закончиться от выкладывания неприличной картинки в блоге, до удаления всего блога вместе со всеми бэкапами во всех облаках (BackWPup замечательно из своей админки позволяет это делать), ну кроме, естественно, локальных копий, которые не все и не всегда-то и делают, надеясь на облачные хранилища.
Так же по окончанию изучения возможностей и дыр плагина backWPup, а также аналогичных плагинов, да и вообще бэкапов, родились следующие мысли и рекомендации:
1. Файлпланете.ком — луч лютой ненависти. Нельзя так относится к данным своих пользователей.
2. Когда пользуетесь опцией скидывания файла по фтп — аккуратнее с закачкой на какой-нибудь общественный ресурс. Как мы помним, яндекс даже смс-ки на мегафоне проиндексировал, а если ссылки на бэкапы будет проиндексированы, то злые люди смогут искать по названиям файлов, содержащим в себе, например, backwpup, использовать прямую ссылку на этот архив, поскольку находясь что в облаке, что на хостинге (в подавляющем большинстве случаев) он абсолютно не защищен и доступен для скачивания первому встречному. Иными словами, зная или подобрав ссылку на архив, злоумышленник может спокойно полакомиться всеми данными сайта. Храните резервные копии в безопасном месте.
3. Удаленное управление базой данных — зло. Гораздо лучше, если она будет на localhost, и доступна из кабинета хостера, это хоть чуть усложнит жизнь взломщикам. Естественно, в кабинет должен быть свой пароль, а не такой же, как на базу.
4. Делая бекап сайта — BackWPup не просто так создает каталог со сложным названием, типа backwpup-9x9z9-logs, в который кладет логи. Не надо светить где-либо название этого каталога. Файл лога имеет стандартное название — типа backwpup_log_2010-01-01_04-08-08.html, ну или такой же архив. Учитывая, что бэкапы делаются, как правило, не реже раза в неделю, и зная название каталога, даже несмотря на то, что добавляется дата и время создания — подобрать название ссылки к логу простым парсером не составит никакого труда — а по ним прямая ссылка до самого файла бэкапа вычисляется на раз. Также не надо класть их, и сами бэкапы в каталоги с простым названием. И вообще, подумайте — так ли нужны вам логи о процессе бэкапа. Ну и естественно — название самого файла бэкапа. Прямая ссылка на скачивание файла бэкапа с вашего сервера — должна быть максимально закрыта от скачивания, придумайте сложный префикс перед названием, уберите backwpup из него.
5. Крайний идиотизм вордперсса — хранить все данные о базе данных, включая пароль, в незашифрованном виде, но наверное, иначе нельзя. Используйте для базы данных пароль, отличающийся от всех остальных паролей — конечно, это не спасет, если wp-config.php кто-нибудь скачает из какого-нибудь архива (слава богу, просто с сайта скачать его не даст апач), но по крайней мере, он сможет залезть только в ваш блог, но не почту, скажем. Да и вход в сам блог будет невозможен, в случае, если у вас нет удаленного управления базой. И запомните — какие бы Login LockDown вы не ставили (который сам по себе — не слишком безопасен и имеет несколько неприятных особенностей (но незаменим при совместном использовании с ThreeWP Activity Monitor) — без «3вп активити монитора» лучше пользуйтесь Login Security Solution (этот, правда до конца не блокирует IP, а просто увеличивает время ввода данных) или Limit Login Attempts (этот, правда, не защищает от горизонтальных атак) и оба они не совсем совместимы с ThreeWP Activity Monitor) — если будете разбрасываться своими бэкапами в общем, и wp-config.php в частности — ничем хорошим это не закончится.
6. Поищите, а нет ли какого скрытого администратора у вас на блоге?
7. Либо сделайте логин админа немного более сложным, чем название сайта и автора, и закройте его от чужих глаз, либо установите один из плагинов, которые ограничиваю число попыток авторизации — опять же, если вы раскидываетесь базами и архивами, вас это не спасет, но от тупого перебора паролей — может помочь.
8. Бэкапьте информацию на локальный компьютер — даже если вредители смогут добраться до всех ваших облачных файлохранилищ, то вы сможете восстановить информацию со своего компьютера.
Честно говоря, об этом всеми уже сто раз писалось. Понятно, что если вас захотят поломать серьезно — то все это что мертвому припарки. Понятно, что способов противостоять терморектальному криптоанализу — еще не изобретено, да и дыры в темах, плагинах и самом вордпрессе открывают широкие возможности для их использования. К примеру, все перечисленные советы никак не помогли при взломе моего сайта, выполненного через дыру в теме — в файле thimthumb.php — обязательно проверяйте его версию при установке какой-либо темы. Сервис Ай-болит — может пригодится уже после того, как появились подозрения на то, что сайт взломан.
Но тем не менее — защититься от школьников — поможет. Когда я сам ощутил панику от того, как я легко и непринужденно, сам того не ожидая, зашел в админку чужого блога — я, мягко говоря, задумался над всеми этими проблемами. И один из следующих обзоров я как раз посвящу вопросам комплексной защиты вордпресс.
1