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

Сьогодні буде розкрита дуже важлива проблема – захищеність. Погодьтеся, що це чи не найважливіший аспект ведення справ в мережі і не тільки. Так що рекомендую не пропускати цю публікацію і в обов’язковому порядку ознайомитися з наведеними нижче рекомендаціями. І тоді ви зможете спати ще трішки спокійніше 😉 Всі без жартів!

У цьому пості ми розберемо рівно 10 корисних порад про те, як підвищити безпеку наших WordPress блогів різними способами.

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

А тепер дозвольте приступити до сьогоднішньої теми.

1. Прибираємо непотрібну інформацію з екрану

Проблема: Коли ви раптом не можете залогуватися у своєму блозі, WordPress виводить деяку інформацію, що про помилку. Це звичайно, добре, якщо ви забули свій пароль, але так само може бути корисним для того, хто задумав зламати ваш блог! Так чому ж не взяти й не відключити виведення на екран повідомлень про помилки при вході?

Рішення: Щоб прибрати повідомлення про помилку при вході, просто відкриваємо файл functions.php у нашої теми оформлення і вставляємо в самому початку наступний код:

add_filter(‘login_errors’,create_function(‘$a’, “return null,”));

add_filter(‘login_errors’,create_function(‘$a’, “return null,”));

Зберігаємо і йдемо перевіряти. Ось, тепер ніяких помилок 😉

Пояснення: Даний код просто додає петлю щоб переписати функцію login_errors (). Тепер повідомлення про помилку буде видавати чистий масив, так як функція, яку ми зробили, повертає значення null.

2. Використовуємо SSL

Проблема: Якщо ви турбуєтеся з приводу того, що дані можуть бути перехоплені, то безумовно треба почати використовувати SSL. Якщо раптом ви не знаєте що це таке, то SSL – шифрований протокол забезпечує безпеку передачі даних в мережах, таких як Інтернет, наприклад.

А чи знали ви що WP можна змусити використовувати SSL? Не всі хостинги дозволяють використовувати SSL, але будемо сподіватися, що ваш підтримує 😉

Рішення: Спершу перевірте, що сервер підтримує SSL (найпростіше запитати у адміна, але швидше за все SSL у вас вже включений). Потім відкрийте файл wp-config.php розташований у корені (куди встановлений сам WordPress і де знаходиться index.php) і вставте наступний код:

define(‘FORCE_SSL_ADMIN’, true);

define(‘FORCE_SSL_ADMIN’, true);

Тепер зберігаємо – ось і все готово!

Пояснення: Ну, тут нічого складного. WordPress має купу регулярних виразів для налаштування. В даному ж випадку ми просто визначили FORCE_SSL_ADMIN і присвоїли значення true. І як результат движок почав використовувати безпечне з’єднання SSL.

3. Використовуємо .htaccess для захисту файлу wp-config

Проблема: Як і будь-яка інша людина, що використовує WP для своїх проектів, ви повинні розуміти всю важливість файлу wp-config.php. Цей файл містить всі необхідні дані для доступу до Бази Даних: ім’я користувача, пароль, дані сервера і т. д. Захист wp-config.php вкрай необхідна, так як на рахунок використання можливостей Apache?

Рішення: Знаходимо файл .htaccess розташований в корені (там же де і index.php). На всякий випадок створюємо копію файлу, а то мало що… Відкриваємо файл і вставляємо наступний код:

<files wp-config.php>
order allow,deny
deny from all
</files>

order allow,deny
deny from all

Пояснення: .htaccess потужний і кращий інструмент для запобігання небажаного доступу до певних файлів на вашому сервері. У коді вище ми створили правило яке забороняє будь-які спроби доступу до файлу wp-config.php, так що жодні пекельні демони не отримають доступ до нього!

4. Чорний список небажаних користувачів і ботів

Проблема: Це правило працює як в мережі, так і в реальному житті: якщо хто-небудь, хто пристає до вас сьогодні, швидше за все пристане до вас і завтра. Чи знаєте ви, скільки спам-ботів повертаються до вас на блог по десять разів на дню, щоб запостити свої гребаные комменатрии? Вирішення проблеми дуже просто – закриємо їм доступ на блозі!

Рішення: Додаємо наступний код у наш .htaccess файл, розташований в корені:

<Limit GET, POST, PUT>
order allow,deny
allow from all
deny from 123.456.789
</LIMIT>

order allow,deny
allow from all
deny from 123.456.789

Увага! Не забудьте поміняти 123.456.789 на реальний ip-адресу того, кого хочете заблокувати.

Пояснення: В черговий раз переконуємося, що Apache потужний інструмент, який в даному випадку дозволяє нам дозволити доступ до блогу всім, крім людей або роботів з зазначеними IP.

Для блокування декількох ip-адрес можна використовувати наступний запис:

<Limit GET, POST, PUT>
order allow,deny
allow from all
deny from 123.456.789
deny from 93.121.788
deny from 223.956.789
deny from 128.456.780
</LIMIT>

order allow,deny
allow from all
deny from 123.456.789
deny from 93.121.788
deny from 223.956.789
deny from 128.456.780

5. Захищаємо свій WP-блог від ін’єкцій

Проблема: Захист динамічного сайту особливо важлива. Багато розробники захищають запити GET і POST, але іноді цього буває недостатньо. Ми теж постараємося захистити свій блог від ін’єкцій на будь-яких спроб змінити змінні PHP GLOBALS і _REQUEST.

Рішення: Наступний код буде блокувати ін’єкції і спроби змінювати змінні. Слід вставити його у файл .htaccess:

Options +FollowSymLinks
RewriteEngine On
RewriteCond %{QUERY_STRING} (\<|%3C).*script.*(\>|%3E) [NC,OR]
RewriteCond %{QUERY_STRING} GLOBALS(=|\[|\%[0-9A-Z]{0,2}) [OR]
RewriteCond %{QUERY_STRING} _REQUEST(=|\[|\%[0-9A-Z]{0,2})
RewriteRule ^(.*)$ index.php [F,L]

Options +FollowSymLinks
RewriteEngine On
RewriteCond %{QUERY_STRING} (\|%3E) [NC,OR]
RewriteCond %{QUERY_STRING} GLOBALS(=|\[|\%[0-9A-Z]{0,2}) [OR]
RewriteCond %{QUERY_STRING} _REQUEST(=|\[|\%[0-9A-Z]{0,2})
RewriteRule ^(.*)$ index.php [F,L]

Пояснення: Використовую можливості .htaccess ми можемо перевіряти запити. Те, що ми зробили, перевіряє, чи містить запит і він намагається змінити значення змінних GLOBALS і _REQUEST. Якщо трапляється що-небудь подібне, запит блокується і видається 403 помилка в браузері.

6. Боремося з парсерами і граберами.

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

Рішення: Для захисту блогу проти цих злих дій необхідно додати код в файл .htaccess. Повторюся – не забувайте робити резервну копію файлу.

RewriteEngine On
#Replace ?myblog\.ru/ with your blog url
RewriteCond %{HTTP_REFERER} !^http://(.+\.)?myblog\.ru/ [NC]
RewriteCond %{HTTP_REFERER} !^$
#Replace /images/nohotlink.jpg with your “don’t hotlink” image url
RewriteRule .*\.(.jpe?g|gif|bmp|png)$ /images/nohotlink.jpg [L]

RewriteEngine On
#Replace ?myblog\.ru/ with your blog url
RewriteCond %{HTTP_REFERER} !^http://(.+\.)?myblog\.ru/ [NC]
RewriteCond %{HTTP_REFERER} !^$
#Replace /images/nohotlink.jpg with your “don’t hotlink” image url
RewriteRule .*\.(.jpe?g|gif|bmp|png)$ /images/nohotlink.jpg [L]

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

На сайтах, які будуть посилатися на ваші картинки, автоматично буде показано зображення nohotlink.jpg. Будьте уважні, необхідно заздалегідь підготувати дану картинку, щоб вона відображалася на сайтах негідників =)

Пояснення: За допомогою цього коду, перше, що ми зробили це перевірку реферрера (referrer) на відповідність ДО нашого блогу і що він не порожній. Якщо це не так і запитуваний файл має розширення JPG, GIF, BMP або PNG, замість нього з’явиться картинка-пустушка.

7. Створюємо плагін для захисту нашого блогу від шкідливих URL-запитів

Проблема: Хакери та інші злидні часто використовують всякі лихі запити для пошуку вузьких місць і атаки. WordPress має непогану початкову захист, але досконалості немає межі!

Рішення: Створюємо текстовий файл і додаємо в нього наступний код. Зберігаємо файл під ім’ям blockbadqueries.php. Після цього завантажуємо його в папку wp-content/plugins і активуємо наш плагін через адмінку як і будь-який інший. Тепер наш блог захищений від шкідливих запитів.


/*
Plugin Name: Bad Block Queries
Plugin URI: http://perishablepress.com/press/2009/12/22/protect-wordpress-against-malicious-url-requests/
Description: Protect WordPress Against Malicious URL Requests
Author URI: http://perishablepress.com/
Author: Perishable Press
Версія: 1.0
*/

global $user_ID;
if($user_ID) {
if(!current_user_can(‘level_10’)) {
if (strlen($_SERVER[‘REQUEST_URI’]) > 255 ||
strpos($_SERVER[‘REQUEST_URI’], “eval(“) ||
strpos($_SERVER[‘REQUEST_URI’], “CONCAT”) ||
strpos($_SERVER[‘REQUEST_URI’], “UNION+SELECT”) ||
strpos($_SERVER[‘REQUEST_URI’], “base64”)) {
@header(“HTTP/1.1 414 Request-URI Too Long”);
@header(“Status: 414 Request-URI Too Long”);
@header(“Connection: Close”);
@exit;
}
}
}
?>

255 ||
strpos($_SERVER[‘REQUEST_URI’], “eval(“) ||
strpos($_SERVER[‘REQUEST_URI’], “CONCAT”) ||
strpos($_SERVER[‘REQUEST_URI’], “UNION+SELECT”) ||
strpos($_SERVER[‘REQUEST_URI’], “base64”)) {
@header(“HTTP/1.1 414 Request-URI Too Long”);
@header(“Status: 414 Request-URI Too Long”);
@header(“Connection: Close”);
@exit;
}
}
}
?>

Пояснення: Даний код досить простий. Він перевіряє надмірно довгі запити (більше ніж 255 символів) і перевіряє наявність у них eval або base64 php-функцій в URI. Якщо виконується одна з умов, плагін відправляє 414 помилку (хто не знає: 414 Request-URI Too Long (Запитуваний URI занадто довгий)).

8. Видаляємо номер версії движка…я серйозно 😉

Проблема: Як ви, напевно, знаєте, WordPress автоматично відображає поточну версію движка, яку ви використовуєте. Це небезпечно якщо ви оперативно не оновлюйтеся до актуальної версії (хоч це і строго рекомендується розробниками, але зізнайтеся, всі ми цим грішимо). Ось тому варто ускладнити хакерам життя!

Рішення: Додайте такий рядок у файл functions.php вашої теми оформлення. Зберігаємо, оновлюємо сторінку і вуаля – немає більше номера версії.

remove_action(‘wp_head’, ‘wp_generator’);

remove_action(‘wp_head’, ‘wp_generator’);

9. Змінюємо стандартне ім’я адміністратора «admin»

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

Але знаючи логін безперечно набагато легше підібрати правильну комбінацію логін-пароль. Ось тому і треба міняти стандартний «admin» на що-небудь складніше.

До речі, WordPress 3.0 дозволяє змінювати ім’я через адмінку. Отже, цей пункт важливий, якщо ви використовуєте стару версію WP і старий «admin» аккаунт.

Рішення: Достатньо просто запустити наступний SQL-запит для вашої БД, наприклад через phpMyAdmin:

UPDATE wp_users SET user_login = ‘NewUsername’ WHERE user_login = ‘Admin’;

UPDATE wp_users SET user_login = ‘NewUsername’ WHERE user_login = ‘Admin’;

10. Запобігаємо прямий перегляд директорій

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

Рішення: Просто додайте такий рядок у конфігурацію Apache або в .htaccess файл:

OptionsIndexes

Options -Indexes

Пояснення: Майте на увазі, що це не теж саме, що додавання Disallow: /wp* в файл robots.txt. Це не заборонить індексацію директорії, а заборонить юзерам перегляд.

Натхнення взялося звідси: 10 Useful WordPress Security Tweaks

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

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

З повагою, Олександр Алаєв