WordPress під пресою. Захистіть своїми руками

12

WordPress – зручна платформа для публікації статей і управління, яка базується на величезній кількості різноманітних сайтів. Через свою поширеність ця CMS вже давно є ласим шматком для хакерів.

На жаль, базові параметри не забезпечують належного рівня захисту, залишаючи багато дірок непокритими кредитним дефолтом. У цій статті ми розглянемо типовий «модель» хакерського сайту на WordPress і покажемо, як виправити виявлені вразливості.

Сьогодні найпопулярнішою є система управління контентом WordPress. Його частка становить 60,4% від загальної кількості сайтів, що використовують CMS-движки. З них, за статистикою, 67,3% сайтів базуються на останній версії програмного забезпечення. Тим часом, за дванадцять років існування веб-движка було виявлено 242 уразливості різного роду (за винятком уразливостей, знайдених у сторонніх плагінах і темах). Статистика сторонніх доповнень ще сумніша. Так, компанія провела аналіз 2350 русифікованих шаблонів Revisium для WordPress, взятих з різних джерел. У результаті вони виявили, що більше половини (54%) були заражені Web Shell, бекдори, blackhat seo («спам»), посилання та скрипти містили критичні вразливості. Тож сядьте зручніше, Тепер ми розберемося, як провести аудит сайту WordPress і усунути виявлені недоліки. Використовуватиметься версія 4.

Індексація сайту

Першим кроком у будь-якому тесті зазвичай є збір інформації про ціль. І тут дуже часто допомагає неправильна конфігурація сайту індексування, яка дозволяє неавторизованим користувачам переглядати вміст певних розділів сайту і, наприклад, отримувати інформацію про встановлені плагіни і теми, а також доступ до конфіденційних даних або резервних копій баз даних.. Щоб перевірити, які каталоги видно ззовні, найпростіше скористатися Google. Досить запустити запит Google Dorks типу site: example.com intitle: «index of» inurl: / wp-content /. Оператор inurl: Ви можете вказати наступні каталоги:

/wp-content/
/wp-content/languages/plugins
/wp-content/languages/themes
/wp-content/plugins/
/wp-content/themes/
/wp-content/uploads/

Якщо ви можете переглянути /wp-content/plugins/, наступним кроком є ​​збір інформації про встановлені плагіни та їх версії, що значно спрощується. Природно, ви можете заборонити індексацію за допомогою файлу robots.txt. Тому за замовчуванням він не входить в інсталяційний пакет WordPress, його необхідно створити і закинути в кореневу директорію сайту. Мануалів по створенню і роботі з файлом robots.txt досить багато, тому залиште цю тему для себе. Наведу лише один із можливих варіантів:

User-Agent: *
Disallow: /cgi-bin
Disallow: /wp-login.php
Disallow: /wp-admin/
Disallow: /wp-includes/
Disallow: /wp-content/
Disallow: /wp-content/plugins/
Disallow: /wp-content/themes/
Disallow: /?author=*
Allow: /

Якщо файли, що зберігаються в папці uploads, є конфіденційною інформацією, додайте до цього списку рядок: Disallow: /wp-content/uploads/. З іншого боку, у файлі robots.txt не рекомендується розміщувати посилання на каталоги, створені спеціально для зберігання конфіденційної інформації. В іншому випадку ви тим самим полегшуєте завдання зловмисника, адже це перше місце, куди зазвичай всі заглядають у пошуках «вкусняшки».

Плагіни безпеки для WordPress
Підключіть .htaccess

Для обмеження доступу до конфіденційної інформації краще використовувати файл .htaccess – це конфігураційний файл, який використовується веб-сервером Apache. Розглянемо можливість файлу з точки зору безпеки. З його допомогою ви можете: забороняти доступ до каталогів і файлів, блокувати різні SQL-ін’єкції та шкідливі скрипти. Для цього стандартного файлу .htaccess для CMS WordPress 4.1 потрібно трохи розширити його. Щоб закрити список файлів і папок, додайте:

Options +FollowSymLinks -Indexes
 
RewriteCond %{QUERY_STRING} base64_encode[^(]*([^)]*) [OR]

Посилання на блоки, що містять кодування Base64. Позбудьтеся посилань, що містять тег <script>:

RewriteCond %{QUERY_STRING} (<|%3C)([^s]*s)+cript.*(>|%3E) [NC,OR]

Щоб протидіяти сценаріям, які намагаються встановити глобальні змінні або змінити _REQUESTзмінну через URL:

RewriteCond %{QUERY_STRING} GLOBALS (=|[|%[0-9A-Z]{0,2}) [OR]
RewriteCond %{QUERY_STRING} _REQUEST (=|[|%[0-9A-Z]{0,2})

Щоб протистояти запитам блокування SQL-ін’єкції до URL-адреси, що містить певні ключові слова:

RewriteCond %{query_string} concat.*( [NC,OR]
RewriteCond %{query_string} union.*select.*( [NC,OR]
RewriteCond %{query_string} union.*all.*select [NC]
RewriteRule ^(.*)$ index.php [F,L]

Щоб зіпсувати життя звичайним інструментам злому, фільтрує певні агенти користувача:

SetEnvIf user-agent «Indy Library» stayout=1
SetEnvIf user-agent «libwww-perl» stayout=1
SetEnvIf user-agent «Wget» stayout=1
deny from env=stayout
Захищає файли

Було б добре обмежити доступ до критичних файлів, які зберігають конфігурацію або просто можуть надати зловмиснику певну інформацію. Ви можете вибрати наступних кандидатів:

  • Wp-config.php містить назву бази даних, ім’я користувача, пароль і префікс таблиці;
  • .htaccess;
  • Readme.html і ru_RU.po, які містять версію WordPress;
  • Install.php.

Це робиться наступним чином:

<Files file_name>
Order Allow,Deny
Deny from all
</Files>

Файл .htaccess, що містить ці рядки, має бути в тому самому каталозі, що й захищений файл. Тоді не дозволяйте список користувачів (пам’ятаєте, трохи вище ми говорили про те, як легко отримати список користувачів?):

RewriteCond %{QUERY_STRING} author=d
RewriteRule ^ /? [L,R=301]

Ну що ще? Ви можете дозволити вхід тільки з вказаних IP-адрес. Для цього створіть файл .htaccess у своєму wp-admin з такими правилами:

AuthUserFile /dev/null
AuthGroupFile /dev/null
AuthName "Access Control"
AuthType Basic
order deny,allow
deny from all
allow from 178.178.178.178  # IP Home computer
allow from 248.248.248.248  # IP Work computer

Метод не дуже гнучкий і застосовний тільки в тому випадку, якщо ви працюєте з обмеженою кількістю фіксованих IP-адрес. В іншому випадку рекомендується встановити пароль до папки wp-admin panel через хостинг (якщо така функція).

WWW

Набір правил 5G Blacklist і 6G Blacklist beta від Perishable Press, який дозволяє працювати з поширеними шкідливими URL-запитами для WordPress.

Додаткові заходи

Крім того, що було сказано вище, можна додати наступні рекомендації. По-перше, використовуйте лише останні версії WordPress та його компонентів – це усуне відомі вразливості. По-друге, видалити плагіни і теми, які теж можна проексплуатіровать. По-третє, завантажуйте теми та плагіни WordPress із надійних джерел, таких як сайти розробників і офіційний сайт WordPress. Як і домашній комп’ютер, необхідно періодично перевіряти свій веб-ресурс Web Antivirus, наприклад AI-Bolit. Якщо у вас є доступ до веб-сервера, настрою права доступу до файлів і каталогів. Як правило, WordPress встановлює повні права на етапі інсталяції, але при необхідності можна встановити вручну chmod. Для каталогу – chmod 755, для файлів – chmod 644. Переконайтеся, що права 777 призначені тільки тим об’єктам, яким це необхідно (іноді це необхідно для нормальної роботи деяких плагінів). Якщо WordPress перестав нормально функціонувати, поекспериментуйте з правами доступу: спочатку спробуйте 755, потім 766 і, нарешті, 777. Для всього htaccess-файлу виставте chmod 444 (тільки для читання). Якщо сайт більше не працює, спробуйте поекспериментувати зі значеннями 400, 440, 444, 600, 640, 644.

Перемістіть файл wp-config.php. Цей файл містить інформацію про налаштування, MySQL, префікс таблиці, секретні ключі тощо. Тому необхідно перенести файл, недоступний з Інтернету. Якщо сайт не знаходиться в папці public_html, то перетягніть файл wp-config.php на рівень папки вище, і WordPress автоматично знайде його в кореневому каталозі (застосовується, якщо на цій CMS розміщено лише один сайт).

Щоб ускладнити оболонку кастингу, вимкніть можливість редагування потоків консолі WordPress. Для цього вставте наступний рядок у файл wp-config.php:

define ('DISALLOW_FILE_EDIT', true) ;

Ще одне слабке місце – файл install.php (в папці wp-admin). Тому краще видалити, заблокувати або змінити. Виконайте одну з наступних дій:

  1. Просто видаліть цей файл – після встановлення він більше не потрібен.
  2. Заборонити доступ до файлу через .htaccess.
  3. Перейменуйте вихідний файл install.php (наприклад, install.php.old) і створіть новий файл install.php із таким вмістом:
<?php header("HTTP/1.1 503 Service Temporarily Unavailable"); ?>
<?php header("Status 503 Service Temporarily Unavailable"); ?>
<?php header("Retry-After 3600"); // 60 minutes ?>
<?php mail("[email protected]", "Database Error", "There is a problem with teh database!"); ?>
<!DOCTYPE HTML PUBLIC "-//W3C//DTD XHTML 1.0 Strict//EN" "http://www.w3.org/TR/xhtml1/DTD/xhtml1-strict.dtd">
<html xml:lang="en"xmlns="http://www.w3.org/1999/xhtml"lang="en">
<head>
<meta http-equiv="Content-Type"content="text/html; charset=utf-8" />
<title>Error Establishing Database Connection</title>
</head>
<body>
<h1>Error Establishing Database Connection</h1>
<p>We are currently experiencing database issues. Please check back shortly. Thank you.</p>
</body>
</html>

Окрім сповіщення відвідувачів сайту, цей скрипт виконує наступне:

  • Надсилає клієнту та пошуковим системам код статусу 503 («Сервіс недоступний»);
  • Визначає інтервал часу, через який клієнти та пошукові системи можуть повернутися на сайт (регульований параметр);
  • Повідомити електронною поштою про проблему з базою даних для відповідних дій.

Справа в тому, що в більш ранніх версіях WordPress (<= 2.7.1) при збоях MySQL (наприклад, DDoS-атака) CMS робить можливим перевстановлення. Крім того, може статися і несправність / пошкодження однієї з таблиць WordPress. Зокрема, атака можлива при пошкодженні таблиці ks29so_options (у WordPress 2.6.2) або ks29so_users (у WordPress 2.0.3 і 2.0.11). Тобто в різних версіях WP різні таблиці при основній перевірці в інсталяторі – це може бути або таблиця ks29so_options, або ks29so_users.

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

Корисні посилання
Закриття

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

Цей веб -сайт використовує файли cookie, щоб покращити ваш досвід. Ми припустимо, що з цим все гаразд, але ви можете відмовитися, якщо захочете. Прийняти Читати далі