Захист WordPress

Взламали сайт на WordPress? Як очистити від вірусів та відновити роботу.

Pinterest LinkedIn Tumblr

Привіт. Не дуже приємна але дуже важлива тема сьогодні буде розглянута. Нещодавно ми вже наводили невеличку статистику від авторів плагіну Wordfence, згдіно якої кожну секунду атакують близько 100 сайтів, і це лише статистика серед тих сайтів, що надсилають анонімні статистичні дані для аналізу авторам вказаного плагіну.

Ще одна цікава статистика, про яку ми писали близько місяця тому – у приблизно 55% випадків сайти зламують через дірки у безпеці плагінів, які використовуються на цих сайтах, і ще у приблизно 15% випадків – шляхом підбору паролів адміністратора. Таким чином, складний пароль і використання мінімальної кількості перевірених плагінів – це вже 70% успіху у боротьбі із зловмисниками.

12032797_1256264801054817_4934383587872111999_o

Але поки залишимо сухі цифри в стороні, і перейдемо до практики. Я по кроках викладу Вам перевірений на практиці метод очищення сайтів на WordPress, якщо вже так сталося, і його було зламано.

Зауважте:

  • Найпростіший спосіб відновлення сайту – відновлення з резервної копії. У такому випадку Ви з найбільшою вірогідністю не пропустите нічого, відновите роботу сайту за мінімальний час і з використанням мінімальних зусиль. Отже робіть резервну копію регулярно і зберігайте десь у безпечному місці мінімум 3 копії – після створення сайту (або будь-яка найстаріша 100% робоча копія), копія тижневої давності і копія  “на вчора”. Ось приклад, як робити копії, якщо на хостингу використовується панель ISPmanager. Після великих/важливих змін на сайті робіть разову копію і “кладіть” поруч з Вашою “найстарішою”, це дозволить у випадку чого не повертатись до самого початку.
  • Описаний далі спосіб спрацьовує у більшості випадків, з якими мені довелось зустрітись, але не є панацеєю від будь-яких типів “вірусів/атак”.

1. Бекап / резервна копія.

Перше правило – завжди роби бекап.

Навіть перед початком очищення зараженого сайту потрібно зробити бекап його поточного стану. Чому? По-перше, як в анекдоті, дивись перше правило . По-друге, під час роботи із ураженим сайтом можна помилково видалити потрібну інформацію, якої немає у більш старих Ваших резервних копіях (якщо ці копії у Вас взагалі є).

Багато хто вважає, що будь-який хостинг-провайдер робить бекапи їх сайтів, отже немає сенсу морочити собі голову цим. Вони праві, але десь на відсотків 30% . Не завжди є інформація, які саме копії робить провайдер, копії чого і скільки копій зберігається. Наприклад, провайдер може робити копії Ваших сайтів, але за виключенням файлів, що за розміром більші 5мб. Це досить нормальна практика, адже більшість “скриптів”/”корисних файлів” не перевищує цю межу, а різні “відео”, архіви та інші медіа-дані, які займають багато місця – не будуть заважати провайдеру, з’їдаючи ресурси серверу резервних копій. Провайдер може зберігати дані, наприклад, за останні 2 дні. Цього цілком достатньо аби відновити роботу сайтів клієнтів у випадку якихось  проблем на стороні провайдера, але у більшості випадків Ви помітите, що сайт зламано десь за тиждень, а інколи люди місяцями про це не здогадуються (це 100% правда з особистого досвіду роботи з сайтами клієнтів). Отже, коли Ви помітите проблеми, провайдер зможе надати Вам лише копії 2-денної давнини, але від цих копій не буде користі. Ну і останнє, є такі штуки як “форс-мажор” і “закон підлості”, оці штуки зазвичай трапляються, коли Ви сподіваєтесь на допомогу “третіх” осіб замість того, щоб нести відповідальність за свої сайти особисто. Усі цифри я навів для прикладу і розуміння важливості бекапів.

2. to Be or Not to Be

Завдячуючи архітектурі WordPress нам значно легше буде видалити “половину” вірусів у порівнянні з іншими системами керування сайтами. Отже другий крок, який нам потрібно зробити – це видалити усі “стандартні” файли та папки, що ми пізніше замінимо на їх “оригінальні/чисті” версії. Ці файли та папки у 99% випадків не повинні відрізнятись від оригіналу. Ось приклад файлів ураженого сайту (червоним відмічено для прикладу деякі “нестандартні” файли/папки, яких не повинно бути):

Screenshot_25

Коричневим я відмітив те, що ми залишимо – файл wp-config.php та директорія wp-content, це єдине, що нам потрібно, все інше видаляємо. Директорію wp-content ми залишаємо, оскільки у ній містяться усі наші зображення із статей та сторінок, усі плагіни та шаблон, що ми використовуємо. У файлі wp-config.php міститься інформація про доступ до бази даних та інша конфігурація. В принципі його теж можна б було видалити, але я підкажу пізніше, чому він знадобиться.

Звісно, якщо у Вас в кореневій директорії сайту є якісь “свої” папки чи файли, наприклад, як на скріншоті файли, що підтверджують права на домен для сторонніх сервісів, їх теж можна залишити, але в цій статті я не зможу розглянути способи, як їх перевірити/почистити:

Screenshot_22

Ось приклад вмісту одного з файлів, що було розміщено в кореневій директорії сайту:

Такий файл одразу розпізнається навіть windows-антивірусом як Backdoor: PHP/Small.M – в двох словах, цей файл надає можливість зловмиснику отримати доступ до Вашого сайту віддалено.

3. Видалення , відновлення

Важливий момент – починаючи з цього кроку не потрібно намагатись відкривати сайт, адмінку чи якось звертатись до сайту через браузер. Може таке бути, що під час спроби відкрити будь-яку сторінку віруси автоматично знову потраплять на сайт.

Перше, що ми робимо, видаляємо все, окрім файлу wp-config.php та директорії wp-content , як результат маємо такий вміст директорії з сайтом:

files2

Друге – створюємо в корені файл .htaccess, з наступним вмістом:

Order Deny,Allow
Deny from all
Allow from 98.244.195.106Code language: CSS (css)

Де IP адресу 98.244.195.106 потрібно замінити на Вашу, яку можна дізнатись, наприклад, відвідавши сайт http://myip.com.ua . Таким способом Ви дозволяєте доступ до Вашого сайту лише з Вашого комп’ютера.

Третє – беремо останню версію WordPress зі сторінки релізів у нас чи на офіційному сайті та завантажуємо вміст директорії wordpress, що Ви знайдете в архіві на Ваш сайт, погоджуючись із заміною файлів, що на сайті існують, на нові:

ftp_27

Четверте – один з найважливіших кроків, адже стосується заміни файлів плагінів, через які в більшості ламають сайти за статистикою. Суть кроку полягає у тому, що потрібно повністю видалити усі директорії з плагінами, а замість них завантажити “чисті” версії. Робити це досить нудно, але без цього увесь процес може бути марним. Один із способів наступний:

  • переходимо у папку /wp-content/plugins і по черзі в кожній директорії відкриваємо головний файл плагіну. Він зазвичай має співпадати за іменем з директорією:plugin
  • у цьому файлі ми знаходимо посилання на офіційну сторінку плагіну, куди ми і йдемо. Там беремо актуальну і чисту версію, з якої потім відновимо наш плагін:
plugin2
  • Я, наприклад, завантажую усі архіви в якусь порожню папку, а після працюю з усіма разом. Виходить десь так:
Screenshot_27
  • Плагіни, що не розміщені на офіційному сайті WordPress.org, наприклад цей, я зазвичай не завантажую. За потреби, можу надати пояснення і описати винятки у коментах.
  • Отже маємо набір чистих плагінів і можемо видалити усе “лайно”, яке знаходиться на їх місці, а його там ціла купа 🙂
Screenshot_28
  • Видаляємо з папки /wp-content/plugins усе, окрім файлу index.php , його ми вже замінили на чистий на одному з кроків.
  • Розпаковуємо архіви з плагінами і завантажуємо на сайт у /wp-content/plugins
Screenshot_30

П’яте – ми проводимо аналогічну операцію з шаблонами. Тут менше дурної роботи, адже шаблон Ви можете використовувати лише один (максимум два у випадку з дочірньою темою, але це окрема розмова). Отже потрібно зайти в директорію з шаблонами /wp-content/themes , перейменувати папку з Вашим активним (сподіваюся, Ви знаєте, який шаблон використовуєте) , а усі інші папки/файли видалити (окрім файлу index.php , його ми вже замінили на чистий на одному з кроків). Тоді замість такого:

Screenshot_31

отримуємо чисту директорію з однією папкою, що ми перейменували (не важливо, яку нову назви папки обрано):

Тепер потрібно лише перейти на сайт, де Ви завантажували шаблон, і аналогічно плагінам скопіювати чистий шаблон у /wp-content/themes. Якщо Ви використовували безкоштовний шаблон з WordPress.org , його можна знайти за назвою папки тут https://wordpress.org/themes/ , якщо купували – завантажити там, де купували. Якщо все зовсім погано 🙂 і чистий шаблон знайти не вдається – завантажте з https://wordpress.org/themes/ будь-який , що Вам подобається, наприклад стандартний https://wordpress.org/themes/twentysixteen/. В жодному випадку не рекомендую використовувати той, що ми хвилину тому перейменували!

Шосте – потрібно перевірити/почистити директорії, що залишились, а саме /wp-content/languages та /wp-content/uploads . Зазвичай усе всередені /wp-content/languages можна видалити. У цій папці зберігається у більшості випадків лише переклад самого “WordPress”, якщо Ви використовуєте мовну версію відмінну від англійської. Аби цей переклад знову там з’явився, буде достатньо наприкінці обрати в адмінці англійську мову, зберегти налаштування, а потім обрати потрібну (наприклад, українську) і знову зберегти налаштування:

Screenshot_34


Найцікавіше можна знайти у /wp-content/uploads . За замовчуванням у цій папці можуть бути лише такі файли:

Зображення – .jpg , .jpeg , .png , .gif , .ico ,
Документи – .pdf , .doc , .docx , .ppt , .pptx , .pps , .ppsx , .odt , .xls , .xlsx , .psd
Аудіо – .mp3 , .m4a , .ogg , .wav
Відео – .mp4 , .m4v , .mov , .wmv , .avi , .mpg , .ogv , .3gp , .3g2

  • На практиці, більшість з нас на сайт завантажують лише зображення , з цього виходить, що в даній директорії не повинно бути нічого окрім зазначених вище файлів (або тільки зображень).
  • Також у більшості випадків усі файли/зображення знаходяться у папках з структурою рік/місяць, наприклад /wp-content/uploads/2016/01 . Тож всі інші директорії теж потрібно видалити

Нижче я навів приклад стрілками, які директорії та файли є зайвими у папці /wp-content/uploads/ . Звісно можуть бути виключення (наведено синіми стрілками), але раджу і їх видалити, в будь-якому випадку Ви зробили повну копію на початку, отже маєте ці папки/файли про всяк випадок. Тож потрібно пройтись по усім папкам/підпапкам і залишити тільки потрібні файли та директорії.

Сьоме – багато вірусів завантажують саме у папку /wp-content/uploads/. Як вже зрозуміло, там можуть бути лише картинки , документи чи тому подібне. Але в жодному разі там не має бути скриптів / файлів *.php . Аби вберегти себе від того, коли ці файли все ж там з’являться чи Ви просто пропустили при очищенні їх – створимо у папці /wp-content/uploads/ файл .htaccess з наступним вмістом:

<Files *.php> 
deny from all 
</Files>Code language: HTML, XML (xml)

Це забороняє доступ будь-кому до файлів *.php у папці /wp-content/uploads/ , такий собі додатковий рівень захисту. Плюс, якщо немає, створіть поруч файл index.php з наступним вмістом, аби через браузер не можна було напряму переглядати вміст директорії /wp-content/uploads/ :

<?php // Silence is golden.Code language: HTML, XML (xml)

4. wp-config.php

Зараз ми відновимо / почистимо цей важливий файл в корені Вашого сайту. Зробити це не дуже складно, з чистим вордпресом Ви завантажили файл wp-config-sample.php – це і є “незаймана” версія wp-config.php . Нам лише потрібно перенести туди певні налаштування. Відкриваємо обидва файли для редагування, беремо дані з wp-config.php і вставляємо у wp-config-sample.php , а саме:

  • налаштування підключення до бази даних (клікайте)
  • ключі аутентифікації (клікайте)
  • префікс таблиць (клікайте)
  • зберігаємо зміни.
  • видаляємо wp-config.php
  • змінюємо назву wp-config-sample.php на wp-config.php

п.с. Перед перенесенням інформації про підключення до бази даних я б ще радив хоча б змінити пароль до бази, і тоді використовувати вже новий. Зазвичай це можна зробити через хостинг-панель Вашого хостинг-провайдера.

5. Поїхали

Цього має бути достатньо аби перейти вже до нашої адмінки. Отже відкриваємо http://vash_site/wp-admin

Нас чекають наступні справи та сюрпризи :

  • перше, що треба – зайти в меню “Користувачі”, подивитися, чи немає зайвих адміністраторів та змінити паролі усім адміністраторам, що залишились.
  • відкривши меню “Плагіни”, ми можемо побачити, що певні плагіни були відключені , оскільки ми видалили їх папки. Інші плагіни залишаться на місці, їх налаштування мають зберегтися.
  • в меню “Вигляд” Ви можете побачити, що Ваша активна тема пошкоджена (це якщо ви не знайшли її “чистого” варіанту) , в такому випадку просто активуйте нову, яку ми завантажили пару кроків тому.
  • Видаліть код з файлу .htaccess у корені сайту, що ми додали на початку статті для обмеження доступу
  • Зайдіть в меню “НалаштуванняПостійні посилання” і натисніть Зберегти, це заново створить в корені сайту файл .htaccess з потрібним вмістом для відкриття сторінок з гарними url-ами.

Фініта

Звісно, окрім зміни паролів доступу до адмінки і бази даних, бажано змінити паролі і на хостингу (до хостинг-панелі/FTP та інші) .

На виході Ви не завжди отримаєте 100% той самий сайт, що був до моменту зламу, але у вас буде сайт і буде збережено Ваш контент. В залежності від хостингу, програм та налаштувань, що Ви використовуєте – можуть бути певні специфічні нюанси на кожному кроці, на жаль, я ніяк не можу їх усі врахувати і описати. Також зауважте, якщо Ваші сайти є способом заробітку і приносять гроші, не варто  нехтувати їх захистом, це може обійтися дорожче. Тож раджу також ознайомитись з нашими статтями у розділі “Про Захист WordPress” , присвятити певний час та сили для покращення безпеки Вашого сайту або скористатися послугами сторонніх спеціалістів.

Додатково раджу після очищення чи для профілактики вже зараз скористатися наступними плагінами:

  • https://wordpress.org/plugins/tac/
  • https://wordpress.org/plugins/exploit-scanner/
  • https://wordpress.org/plugins/wp-antivirus-site-protection/
  • https://wordpress.org/plugins/antivirus/
  • https://wordpress.org/plugins/gotmls/
  • https://wordpress.org/plugins/wemahu/

Якщо у Вас виникнуть додаткові питання – буду радий відповісти. Не забувайте підписуватись на нашу розсилку (форма нижче) та “лайкати” у соцмережах наші сторінки і записи 🙂

Дмитро Кондрюк в веб-індустрії з 2003 року. В 2009р. заснував проект Український WordPress (що у подальшому став офіційним сайтом команди локалізації WordPress в Україні). З 2010 року засновник і технічний директор проекту Український хостинг для WordPress (WPHost.me) - повноцінного хостинг-сервісу, максимально оптимізованого на використання CMS WordPress.

коментарі 4

  1. У меня постоянно настроен автоматический бєкап. Было дело, раз взломали. Но особо ничего не натворили, просто ссылок своих напихали в статьи. 

    • Часто вы и не знаете, что на самом деле сделали \”хакеры\”. Сейчас большинство взломов происходит ради закачки \”кода\”, который тихонько рассылает СПАМ с вашего домена, не мешая работать сайту вообще

Коментувати