Після того як сайт або блог створений і запущений, перед кожним стоїть завдання захисту ресурсу від шкідливих програм і хакерських зломів. Як правило, більшість власників популярної системи управління контентом (CMS) Wordpress встановлюють середню ступінь захисту і припускають, що кілька встановлених плагінів забезпечать високий рівень захисту. У той же час має місце думка про те, що "мій сайт або блог навряд чи може цікавити хакерів", але саме на такі ресурси хакери орієнтуються в першу чергу. Адже зламавши ваш абсолютно нешкідливий блог "ні про що", який на вашу думку не повинен залучати зловмисників, ви тим самим стаєте одним з багатьох розповсюджувачів шкідливого коду для його кінцевої мети. У цій статті розглянемо методи захисту движка Wordpress.
На сьогоднішній день Wordpress є одним з найпопулярніших CMS в світі. Блоги, міні-сайти, а також цілі портали - будується, взявши за основу Wordpress. За легкістю освоєння все ж криються питання, які пов'язані з безпекою сайту. Великого поширення CMS - все більша увага з боку зловмисників.
Програмісти завжди намагаються, щоб GET- і POST- запити були захищені, але цього недостатньо. Також необхідно захищати блог від всіляких XSS-ін'єкцій, іноді і від спроб модифікації змінних GLOBALS і _REQUEST.
Основні методи захисту CMS Wordpress
1. Захищаємо Wordpress від XSS-ін'єкцій.
1.1. Якщо ви хостів на віртуальному кластерному хостингу дата-центру UNIT-IS або на віртуальному сервері (VPS) в разі використання в якості веб-сервера Apache, вставте код в файл .htaccess, розташований в корені сайту (не забувайте робити резервну копію цього файлу перед внесенням будь-яких змін).
RewriteRule ^ (. *) $ Index.php [F, L]
Дані код дозволяє перевіряти всі можливі запити. Але, якщо ж запит містить тег або, можливо, спробу модифікувати значення змінних GLOBALS і _REQUEST, тоді він просто блокує його і видає користувачеві помилку 403.
1.2. У випадку з VPS і встановленим NGINX як самостійним веб-сервером (+ php-fpm), в останніх версіях розробником впроваджена штатна захист NAXSI (NGINX ANTI XSS SQL INJECTION).
Файрвол веб-додатків (WAF) для NGINX, який допомагає в захисті від XSS, SQL-ін'єкцій, CSRF, а також Local Remote File Inclusions.
Ubuntu, Debian, Netbsd, Freebsd: можливо у вигляді пакету.
Наприклад, в серверній Ubuntu 12.04 досить зробити
apt-get install nginx-naxsi
Також і інші Linux-системи:
Якщо пакети ще не з'явилися, тоді збираємо nginx + naxsi з готових початкових кодів:
tar xvzf nginx-x.x.xx.tar.gz
tar xvzf naxsi-x.xx.tar.gz
(Замість x.x.x.x - необхідно поставити доступні актуальні версії)
і вже після перезапустите конфігурацію (service nginx reload).
Якщо при спробі зайти в адмін панель CMS Wordpress ви помилитеся з введенням логіна або пароля, движок негайно вам про це повідомить. Навіщо хакеру знати, що паролі, який він підбирає - невіра?
2. Прибираємо показ зайвої інформації
Слід відкрити functions.php, який лежить в папці з активною темою
блогу (wp-content / themes / назва-вашій-теми /) і, безпосередньо,
додати наступний код:
add_filter ( 'login_errors', create_function ( '$ a', "return null;"));
зберігаємо файл. Тепер ніяких повідомлень.
3. Примусове використання SSL
Якщо ви хочете, щоб інформація, яку ви передаєте була захищена, тоді вам необхідно використовувати SSL-протокол, який забезпечує цілісність і конфіденційність обміну даними. В окремих випадках це може утруднити роботу процесу підбору паролів роботами. У Wordpress'e це зробити дуже просто.
Перш за все дізнаємося, чи є можливість на вашому тарифному плані
використовувати SSL. Якщо так, то відкриваємо файл wp-config.php (в корені
сайту) і додаємо наступне:
4. Використовуємо .htaccess для захисту файлу wp-config
wp-config.php містить абсолютно всі дані, які необхідні для
підключення до нашого сервера MySQL, а також до бази даних. захистити
доступ - одна з найголовніших і найскладніших завдань.
В першу чергу необхідно Розміщена файл .htaccess в корені нашого сайту, далі додати наступні рядки:
5. Приховування версії Wordpress
Движок автоматично вставляє номер поточної версії CMS в вихідний
код кожної сторінки. Не завжди є час або можливість оновити
движок. А це означає, що людина знає, яка версія Wordpress'a варто,
знає, які слабкі місця на вашому сайті ще присутні. що слід
робити? Необхідно прибрати додавання в вихідний код версії CMS
Відкриваємо functions.php, і додаємо:
Бажано також видалити файл readme.html в кореневій папці сайту. У ньому теж міститься інформація про поточну версію Wordpress.
6. Убиваем адміна! Немає дефолтного юзернейм «admin».
Зловмисникам набагато легше отримати доступ до вашого сайту при
допомоги Брута, особливо, якщо логін вже відомий. Найлегше зламати
сайти, якщо стоїть стандартний логін «admin» для адміністірованія сайту.
У версії 3.0 CMS WorsPress і вище, є можливість змінити
стандартний логін для адміністратора. Для всіх інших (попередніх) версій
необхідно виконати один SQL-запит (наприклад через phpMyAdmin):
UPDATE wp_users SET user_login = 'Ваш новий логін' WHERE user_login = 'Admin';
7. Організація попередньої аутентифікації на файлі wp-login.php
Як правило, першим потрапляє під удар файл входу в адміністративну
панель wp-login.php. Найпростіший метод захисту, це приховати цей файл
(Перейменувати або зробити доступним на довільному порту). Але інколи
такі методи приносять масу незручностей, наприклад для блогів з великим
засобами PHP, конфіги веб-сервера чіпати не станемо, що додасть
методу найбільшої універсальності.
Створюємо файл preauth.php з наступним кодом:
header ( 'WWW-Authenticate: Basic realm = "Administration Area"');
header ( 'HTTP / 1.1 401 Unauthorized');
if ($ _SESSION [ 'pre']! = 1) echo 'Preauthentication required!';
if (! isset ($ _ SERVER [ 'PHP_AUTH_USER']) or! isset ($ _ SERVER [ 'PHP_AUTH_PW']))
> Else if ($ _ SERVER [ 'PHP_AUTH_USER'] == $ u and md5 ($ _ SERVER [ 'PHP_AUTH_PW']) == $ p)
Де $ p - заздалегідь згенерований md5-хеш пароля, $ u - логін (НЕ
встановлюйте ті ж логін і пароль, що використовуєте для входу через
Модифікуємо файл wp-login.php, прописуємо код на самому початку файлу, після "
запитаний логін і пароль з файлу preauth.php, в разі коректного
подвійно ускладнить підбір паролів зловмисником, а й надасть
несподіванка ботам, які навряд чи очікують таку відповідь від стандартної
форми входу движка. Варто врахувати що файл wp-login.php буде перезаписан
при оновленні CMS, тому необхідно прописати рядок
Послідовність дій по усуненню наслідків
Якщо вас вже зламали, то самий безвідмовний "лікування" наслідків
злому і модифікації вашого сайту або блогу, а також бази даних - це
бекап. Якщо ви самостійно не робили резервних копій, зверніться в
Але відновлення з резервної копії недостатньо, один раз зламавши сайт, до вас можуть повернутися ще.
Найпростіше це побачити за датою зміни файлу;
- Постарайтеся відразу визначити, які саме файли були замінені,
це може бути як index.php, так і файли шаблонів, зображень і т.п.
часу зміни файлів і зіставлення з записами в логах дозволяють
висновок
Безпека вашого сайту або блогу - завдання не тільки розробника,
але і наша, дата-центру UNIT-IS, ніж зобов'язані забезпечити максимальну
захищеність наших серверів, але і власника сайту. Замовляючи хостинг для WordPress
в дата-центрі UNIT-IS, ви впевнені в якості та високої надійності
серверів! Наші системні адміністратори завжди готові допомогти в разі
виникнення будь-яких питань.
Наостанок наведемо кілька тривіальних порад вебмайстру:
- ніде не зберігайте облікові дані доступу;
- використовуйте довгі комплексні паролі і нестандартні логіни, періодично виконуйте їх зміну;
- своєчасно оновлюйте ядро Worpress і підключаються плагіни з виходом оновлень;
- при виборі плагіна перевіряйте надійність джерела, а також наявність незакритих уразливостей;
- стежте за правами на файли скриптів і особливо критичні файли конфігурації;
- періодично, в тому числі зовнішніми сервісами, перевіряйте доступність конкретних розділів свого сайту;
- зберігайте локальні копії бекапів сайту і бази даних.