WordPress – одна з найпопулярніших та найрозвинутіших систем керування веб-контентом у світі. Близько 40% усіх сайтів у мережі Інтернет побудовані саме на CMS WordPress. Ця багатоцільова і кросплатформна система з відкритим кодом має мільйони розширень і доповнень у вигляді різноманітних тем, плагінів, компонентів. Однак така популярність спричиняє і певні ризики. Щороку фіксуємо велику кількість атак і вразливостей на сайти під управлінням WordPress. У цьому керівництві ви дізнаєтесь як тримати сайт на постійному замку й не дати пасти під навалою раптових кіберзагроз. Комплексні та дієві рекомендації усім власникам WordPress.
- Хто і навіщо зламує WordPress?
- Рекомендації безпеки WordPress
- Використовувати тільки HTTPS
- Використовувати заголовки безпеки HTTP Security Headers
- Увімкнути багатофакторну аутентифікацію (2FA/MFA)
- Захистити файлову систему WordPress (file permissions)
- Заборонити відкритий лістинг директорій (Directory listing)
- Захистити сторінку входу в WordPress
- Відключити стандартний планувальник WordPress (wp-cron)
- Обмежити доступ до REST API (wp-json)
- Змінити ім’я користувача по замовчуванню та підібрати складний пароль
- Перевірити привілеї і доступи користувачів WordPress
- Захистити облікові записи
- Приховати версію ядра WordPress та CSS/JS компонентів у коді сайту
- Змінити стандартний префікс бази даних WordPress
- Моніторити зміни у вихідному коді сайту
- Вимкнути вбудований редактор коду WordPress
- Обмежити інформацію у robots.txt
- Застосувати захист від ботів Captcha
- Підключити антиспам-систему
- Фільтрувати вхідний трафік
- Регулярно сканувати і оновлювати WordPress
- Здійснювати регулярне резервне копіювання
- Здійснювати регулярний моніторинг системних журналів (логів сервера)
- Налаштувати безпеку сервера
- Що робити якщо WordPress зламали?
- WordPress Security Setup checklist
- Додаткові джерела та посилання
Хто і навіщо зламує WordPress?
Користувачі часто запитують: “Хто і навіщо буде мене ламати? Кому я та мій сайт потрібен?”.
Їм потрібні не ви чи ваші сайти. Їм потрібні – ваші ресурси. Будь-який сайт – це інструмент, ресурс, знаряддя, додаткові потужності, які можуть бути використані у різноманітних цілях, до прикладу:
- організація ботнет і проведення DDOS-атак з використанням IP-адреси та потужності сервера, на якому розміщений сайт;
- побудова PBN-сіток сайтів й розгортання “чорного” BlackHat SEO;
- організація дорвеїв і клоак, продаж реклами і монетизація трафіку;
- розміщення рекламних, партнерських, шпигунських посилань;
- встановлення прихованого майнера криптовалют;
- встановлення прихованого інтернет-парсера;
- встановлення прихованого стилера, який стежитиме за відвідувачами і збиратиме їх персональні дані для подальшої продажі логів у даркнеті;
- електронна розсилка спаму, відправка фішингових листів засобами WordPress.
А тепер уявіть, що таких сайтів — тисячі. Виходить прибутковий бізнес.
Найрозповсюдженіші типи кібератак на WordPress:
- XSS-ін’єкції — втілення шкідливого JavaScript коду в веб-об’єкти і елементи сайту та його виконання на боці сервера;
- SQL-ін’єкції — взлам та модифікація бази даних через несанкціоновані запити до неї;
- Local File Inclusion/Remote File Inclusion (LFI/RFI) — використання локальних та віддалених файлів для отримання конфіденційної інформації і несанкціонованого доступу;
- DOS/DDOS-атаки — відправка великої кількості хаотичних HTTP-запитів з різних IP, спрямованих на вразливу веб-сторінку чи об’єкт;
- Brute-Force — атаки “грубої сили”, масовий перебір комбінацій та значень даних авторизації.
Рекомендації безпеки WordPress
Використовувати тільки HTTPS
Доведено, що сайти на незахищеному HTTP-протоколі є більш вразливими, аніж сайти на HTTPS (Hypertext Transfer Protocol Secure). Для хакерів вони є ласим шматочком, адже незахищене з’єднання дає можливість експлуатувати різноманітними вразливостями: SQL/PHP/XSS-ін’єкції, DOS/DDOS, LFI/RFI та багато інших.
Щоб перевести сайт на захищений HTTPS-протокол, необхідно встановити на сервері SSL-сертифікат. Існують як платні (COMODO, DigiCert) так і безкоштовні сертифікати (LetsEncrypt, Cloudflare).
Додатково варто подбати, щоб на сервері використовувалися останні версії протоколу шифрування передачі даних TLS – 1.2-1.3. Також рекомендується активувати протокол HTTP/2, який оптимізований під повнофункціональне використання TLS.
Перевірити коректність встановлення і налаштування SSL/TLS можна з допомогою сервісів:
- testssl.sh (версія для командного рядка Linux);
- Qualys SSL Labs (веб-версія).
Використовувати заголовки безпеки HTTP Security Headers
HTTP Security Headers — це заголовки безпеки, які віддає сервер по HTTP-протоколу з метою зашифровати передачу даних під час з’єднання.
Заголовки, які рекомендується додати:
Strict-Transport-Security– так-званий HSTS заголовок, який унеможливлює доступ по HTTP-протоколу та змушує веб-браузер примусово використовувати HTTPS-з’єднання;Content-Security-Policy– один з найважливіших заголовків, який являє собою політику безпеки для контролю внутрішніх та зовнішніх HTTP-з’єднань;X-Frame-Options– захищає від несанкціонованого показу вашого сайту у вигляді iframe на інших ресурсах, унеможливлює Hijacking/Clickjacking маніпуляції;X-Content-Type-Options– захищає контент від сніффінгу, спуфінгу та інших атак;Referrer Policy– визначає які функції API та мультимедіа можуть використовуватись на сайті.
👉 Детальніше про HTTP-заголовки на сторінці OWASP>>
Переглянути яких HTTP-заголовків не вистачає можна з допомогою таких онлайн-сервісів:
Увімкнути багатофакторну аутентифікацію (2FA/MFA)
Багатофакторна аутентифікація – це додатковий шар захисту облікового запису, який окрім пароля, передбачає введення коду авторизації, який надходить на електронну пошту, мобільний застосунок (Google Authentificator) або в desktop-додаток (KeepassXC).
У 80% випадків наявність багатофакторної аутентифікації (2FA/MFA) стає на заваді зламу. Без 2FA – зловмиснику залишається просто підібрати логін і пароль до вашого сайту.
Для інтеграції двофакторної авторизації в WordPress існує чудовий плагін-фаєрвол – Wordfence Security. Необхідно перейти в меню WordPress -> Wodfence Security й обрати пункт Login Security, після чого з’явиться вкладка Two-Factor Authentification з відповідними налаштуваннями:
Якщо сайтом користуються інші користувачі, рекомендується обов’язково активувати 2FA-авторизацію для усіх типів облікових записів. Це можна зробити на вкладці Settings:
Захистити файлову систему WordPress (file permissions)
Усі файли і папки WordPress повинні бути надійно захищеними, інакше постає ризик витоку та розкриття даних, а разом з тим і несанкціонованого доступу
Система CMS WordPress по замовчуванню має наступну файлову структуру:
- ├──
index.php– це індексна, домашня сторінка WordPress, яка у свою чергу підключає головну сторінку активної теми; - ├──
license.txt– це файл публічної угоди користувача про безкоштовне використання WordPress за ліцензією GNU / OpenSource. Його можна видалити або заборонити доступ, щоб приховати сліди CMS; - ├──
readme.html– це публічний файл з довідковою інформацією для адміністратора по встановленню WordPress, містить детальний опис кроків встановлення, а також інформацію про системні вимоги посилання WordPress. В старіших версіях WordPress він розкривав поточну версію CMS. За потреби його можна видалити або обмежити доступ; - ├──
wp-activate.php– це службовий файл, який використовується для активації електронної пошти під час створення або реєстрації нового користувача; - ├──
wp-admin– службова директорія WordPress, яка містить ресурси адмін-панелі WordPress, при переході по ній система здійснює автоматичний редирект на сторінку входу в адмін-панель з формою авторизаціїwp-login.php; - ├──
wp-blog-header.php– це службовий файл ядра WordPress, який здійснює ініціалізацію основних початкових компонентів при завантаженні сайту; - ├──
wp-comments-post.php– це службовий файл WordPress, який відповідає за обробку та публікацію коментарів, які надсилаються користувачами на сайт. Якщо функція публікації коментарів для відвідувачів увімкнена, цим файлом можна зловживати; - ├──
wp-config.php– основний службовий файл WordPress, в якому прописується конфігурація CMS-системи, повинен бути захищений, адже містить усі налаштування і доступи до бази даних WordPress; - ├──
wp-config-sample.php– публічний файл, який служить шаблоном для конфігурації CMS WordPress та підготовки основного wp-config.php. Рекомендується його вилучати після кожного оновлення WordPress, або просто обмежити публічний доступ; - ├──
wp-content– це службова директорія WordPress, яка містить усі основні користувацькі дані, необхідні для роботи сайту: теми, плагіни, директорію сайту, кеш, папка завантажень та інше; - ├──
wp-cron.php– вбудований планувальник WordPress, який виконує фонові завдання CMS за розкладом. Рекомендується перейти на серверний планувальник cronjob (див. нижче); - ├──
wp-includes– основна службова директорія WordPress, яка містить критично важливі файли ядра CMS. Тут зберігаються сертифікати, шрифти, файли JavaScript, віджети та ін.; - ├──
wp-links-opml.php– це службовий файл WordPress, який відповідає за роботу посилань з так-званого “Блогролу” – функції, яка в останніх версіях є вимкненою і майже не використовуєть; - ├──
wp-load.php– це службовий файл, який використовується для підвантаження функціоналу WordPress в різних скриптах; - ├──
wp-login.php– сторінка доступу до WordPress, яка по замовчуванню знаходиться у публічному доступі, а тому рекомендується обмежити її; - ├──
wp-mail.php– це службовий файл, який використовується для публікації контенту через надіслані email-листи. Може використовуватися в атаках, а тому краще обмежити доступ; - ├──
wp-settings.php– це службовий файл, який відповідає за підключення усіх налаштувань та конфігурацій WordPress; - ├──
wp-signup.php– це службовий файл, який виконує функцію реєстрації нового користувача, а також нового сайту, якщо включена опція “Мультисайт”. Якщо реєстрація користувачів увімкнена, може застосовуватися для спам-атак. Рекомендується обмежити доступ; - ├──
wp-trackback.php– це службовий файл, який відповідає за обробку відстеження в рамках функціоналу WordPress Pingback, що реалізує сповіщеннях з інших блогів, якщо на них з’явиться зворотне посилання на ваш сайт. Цією функцією серйозно зловживають, часто викликаючи DDoS. Рекомендується обмежити доступ; - └──
xmlrpc.php– це протокол віддаленого доступу до CMS WordPress. Через нього та функції API деякі плагіни, наприклад Jetpack, можуть дистанційно обмінюватися інформацією з сайтом. На жаль, цим протоколом також часто зловживають, наприклад можуть провести DDOS або SSRF-атаку. Рекомендується обов’язково обмежити публічний доступ до цього файлу.
Найкритичнішим з усіх є системних файлів є wp-config.php – у ньому міститься вся ключова інформація щодо конфігурації WordPress та під’єднання до бази даних сайту:
Найпростіший спосіб захистити wp-config — перенести на рівень вище, за межі кореневого каталогу WordPress (public_html або www) й встановити права доступу 0600, що унеможливить неавторизований доступ.
Ще один службовий файл, про який варто подбати – debug.log. Він знаходиться в директорії /wp-content. Цей файл зберігає журнали подій WordPress та застосовується для відладки. В ньому фіксуються усі системні попередження та помилки з вказаними шляхами до проблемних рерсурсів. Необхідно виставити права читання і перегляду на цей файл лише для Адміністратора — 0660.
Маючи приватний доступ до debug.log, можна вимкнути публічне виведення системних помилок на сторінках сайту, що є важливим в цілях безпеки. Для цього необхідно в wp-config.php додати рядок:
define('WP_DEBUG_DISPLAY', true);
Ще одним джерелом розкриття інформації про WordPress є публічнодоступні файли readme.txt, які знаходяться в директоріях плагінів і розкривають технічні деталі про них. Вони ні на що не впливають і без них можна обійтися. Однак для зловмисника інформація в них є вкрай важливою, адже дає можливість підібрати експлойт під конкретну версію плагіна. Цей витік можна легко побороти, виконавши команду на автоматичний пошук та вилучення файлів readme:
sudo find /home/example.com/public_html -name "readme*" -exec rm -f {} \;
У 2018 році користувачі WordPress дізналися про вразливість CVE-2018-6389, яка дозволяла маніпулювати ресурсами JavaScript через компонент loads-script.php. Зловмисники через доступ до /wp-admin/load-scripts.php?load= підвантажували велику кількість JS-скриптів і в результаті викликали відмову в обслуговуванні на боці сервера, тобто проводили DDoS. Щоб захистити сайт від такого навантаження, необхідно обмежити до файлу load-scripts.php (а також load-styles.php) публічний доступ й додати в wp-config.php наступну директиву:
define( 'CONCATENATE_SCRIPTS', false );
У висновку це збереже ваші ресурси, а також пришвидшить роботу сайту (за умови що ви використовуєте HTTP/2).
Ще однією поширеною атакою на WordPress є WPSetup Hack, яка полягає у публічному доступі до файлів інсталяції /wp-admin/setup-config.php та /wp-admin/install.php. Таким чином зловмисник може спробувати повторно запустити процес встановлення WordPress. Якщо ви розгорнули свіжий сайт і не розпочали процес встановлення WordPress, тоді він може прописати власні дані конфігурації, зокрема доступ до бази даних на своєму віддаленому сервері і таким чином захопити ресурс. Найкращим способом є просто обмежити доступ до обох файлів.
Перелік файлів та директорій WordPress, публічний доступ до яких рекомендується обов’язково обмежити (надати код відповіді сервера 40X для всіх неавторизованих користувачів):
- /.htaccess
- /wp-config.php
- /wp-login.php
- /xmlrpc.php
- /wp-trackback.php
- /readme.html
- /wp-config-sample.php
- /wp-links-opml.php
- /wp-signup.php
- /wp-mail.php
- /wp-content/debug.log
- /wp-admin/load-scripts.php
- /wp-admin/load-styles.php
- /wp-admin/setup-config.php
- /wp-admin/install.php
- /wp-settings.php
- /wp-includes/
- /wp-content/uploads/
Примітка: Як саме обмежується доступ на вашому сервері – читайте в документації розробників. Наприклад, для Apache серверів це може бути директива
RewriteCond/RewriteRuleв файлі .htaccess. Для Nginx та LiteSpeed необхідно додати відповідні правила у файли конфігурації віртуальних хостів.
Для решти папок та файлів CMS WordPress рекомендує встановити наступні права доступу відповідно:
find /path/to/your/wordpress/install/ -type d -exec chmod 755 {} \;find /path/to/your/wordpress/install/ -type f -exec chmod 644 {} \;
Можна також включити автоматичне виставлення прав доступу для файлів і папок в wp-config.php, додавши такі рядки:
define(‘FS_CHMOD_FILE’, 0644); define(‘FS_CHMOD_DIR’, 0755);
Примітка: для критично важливих файлів налаштуйте права 640, 600 або 440. Розібратися з їх значеннями можна в онлафн-сервісі CHMOD-CALCULATOR.
Заборонити відкритий лістинг директорій (Directory listing)
Відкритий лістинг директорій (Directory listing, CWE-548) — це вразливість, яка дає можливість переглядати файлову структуру сайту публічно через інтернет.
Зловмисник може повністю дослідити структуру сайту, ідентифікувати компоненти: теми, плагіни, стилі, скрипти тощо. Може дізнатися розташування службових файлів, наприклад логів, дампів, файлів конфігурації. Усе це допоможе йому вдало спланувати атаку.
Ось команда, яка переводить дані з відкритого лістингу директорій у читабельний формат у командному рядку:
curl -s -X GET https://example.com/wp-includes/ | html2text
Відключити лістинг директорій просто – достатньо у файлі .htaccess прописати директиву: Options All -Indexes.
Захистити сторінку входу в WordPress
По замовчуванню, доступ в адмін-панель WordPress здійснюється за URL-адресою example.com/wp-admin, яка є публічнодоступною і переспрямовує користувача на сторінку з формою входу example.com/wp-login.php.
Дуже часто боти атакують цю форму, намагаючись підібрати логін та пароль. WordPress повідомляє про некоректно введені дані, що дає їм можливість відсіяти неуспішні спроби. Загалом, усе це створює ризик несанкціонованого доступу і тільки навантажує сервер/
Існує кілька способів, як вирішити цю проблему. Найпростіший – змінити URL-адресу сторінки входу в адмінку WordPress можна з допомогою плагіна WPS Hide Login:
Окрім того можна додатково обмежити кількість невдалих спроб входу в адмінку WordPress. Відповідні налаштування містить плагін Wordfence Security – вкладка Brute Force Protection у розділі All options:
Існує також окремий плагін для обмеження спроб входу – Limit Login Attempts Reloaded:
Limit Login Attempts Reloaded – Login Security, Brute Force Protection, Firewall
Ще один дієвий спосіб як захистити адмінку WordPress без жодних плагінів (рекомендую) – це обмежити доступ до example.com/wp-admin з допомогою фільтрації по IP або ж створити додаткову преавторизацію HTTP Authorization до сторінки входу з допомогою методу htapsswd:
Відключити стандартний планувальник WordPress (wp-cron)
WP-CRON — це вбудований планувальник WordPress, який дозволяє здійснювати публікацію записів за розкладом. По-замовчуванню, файл wp-cron.php є загальнодоступним й може також стати мішенню DDOS. Окрім того він споживає системні ресурси і на слабких серверах сповільнює WordPress. Я рекомендую відключити його і натомість активувати серверний планувальник Crontab.
Для цього необхідно перейти в файл конфігурації wp-config.php й додати наступний рядок:
define( 'DISABLE_WP_CRON', true );
Після цього підключитися до сервера по SSH і виконати команду:
crontab -e
Відкриється редактор серверного планувальника. Необхідно додати команду, яка запускатиме планувальник wp-cron за розкладом (наприклад, кожних 5 хвилин):
*/5 * * * * wget -qO- https://example.com/wp-cron.php &> /dev/null
Для власників веб-серверів LiteSpeed/OpenLiteSpeed можна у цілях безпеки перекрити будь-які зовнішні запити до wp-cron.php. Для цього необхідно перейти в меню Server Configuration > General й увімкнути опцію Use Client IP in Header, а потім для Virtual Host (домену) прописати окремі правила в Rewrite Rules (вказавши IP-адресу вашого сервера):
RewriteCond %{REMOTE_ADDR} !^XXX\.XXX\.XXX\.XXX
RewriteCond %{REQUEST_URI} xmlrpc.php|wp-cron.php [NC]
RewriteRule .* - [F,L]
Рекомедую додатково встановити плагін Advanced Cron Mananger, щоби мати можливість контролювати виконання завдань відразу з адміністративної частини WordPress:
Обмежити доступ до REST API (wp-json)
REST API — це технологія, яка дозволяє різним плагінам, додаткам, обліковим записам віддалено взаємодіяти з WordPress. Цю технологію використовують деякі компоненти для синхронізації і оновлення контенту.
Інформація в REST API передається у форматі JSON. Якщо доступ до REST API не обмежено, кожен бажаючий може відкрити URL-посилання, наприклад https://example.com/wp-json/wp/v2/users і провести атаку енумерації користувачів.
Подібним чином можна розкрити ID та інші деталі WordPress:
curl https://example.com/wp-json/wp/v2/posts | jq– публікації;curl https://example.com/wp-json/wp/v2/tags | jq– теги;curl https://example.com/wp-json/wp/v2/comments | jq– коментарі;curl https://example.com/wp-json/wp/v2/categories | jq– категорії;- ..інший контент.
У 2017 році в WordPress була зафіксована серйозна вразливість – Unauthenticated Content Injection, яка дозволяла через підключені по REST API плагіни провести екскалацію привілеїв і зламати більше 2 млн. сайтів.
Рекомендується обмежити доступ по REST API для неавторизованих запитыв. Існують плагіни, які автоматизують цей процес, наприклад Disable REST API:
Змінити ім’я користувача по замовчуванню та підібрати складний пароль
Ім’я користувача (username) WordPress за замовчуванням, наприклад “admin”, дуже легко визначити, а далі спробувати підібрати пароль до нього. Тому при створенні облікових записів дотримуйтесь складних нестандартних імен та багатозначних паролів (до 20-ти і більше символів), які містять літери верхнього та нижнього регістру, цифти та спеціальні знаки.
На жаль, ім’я вже існуючого облікового запису в WordPress неможливо змінити. Але можна створити нового користувача, вилучити старого і зв’язати усі його записи та права з новим користувачем:
Перевірити привілеї і доступи користувачів WordPress
Якщо на сайті доступна реєстрація, або ним користуються різні люди, варто перевірити їх облікові записи і привілеї. Доволі часто користувачі стають жертвами атак, а їх облікові записи зламуються і можуть бути змінені з метою отримання несанкціонованого доступу.
По замовчуванню, в WordPress діє рольова система з наступними типами і характеристиками користувачів:
- Administrator – повний доступ до всіх функцій WordPress;
- Editor – редактор, може публікувати та керувати публікаціями інших;
- Author – може публікувати та керувати лише власними публікаціями;
- Contributor – дописувач, можу створювати публікації, але не публікувати і не керувати ними;
- Subscriber – підписник, може мати власний профіль і керувати ним, переглядати публікації.
👉 Детальніше про ролі користувачів на офіційному сайті WordPress>>
Захистити облікові записи
Варто також подбати про захист облікових записів авторів від такої атаки як WordPres User Enumeration. Це техніка брутфорс-перебору, яка дає можливість дізнатися справжні логіни користувачів, які використовуються для доступу до адмін-панелі. Хакери парсять URL-адреси сторінок авторів, наприклад /?author=1. Знаючи логіни та імена користувачів в системі, вони можуть приступити до підбору паролів та зламати сайт.
Необхідно заборонити доступ до цих URL-адрес, прописавши в файлі конфігурації веб-сервера .htaccess правило:
RewriteCond %{QUERY_STRING} ^author=([0-9]*)
RewriteRule .* http://example.com/? [L,R=302] Або скористатись плагіном GOTMLS, який cамостійно блокуватиме будь-які спроби запитів до ?author=:
Приховати версію ядра WordPress та CSS/JS компонентів у коді сайту
У вихідному коді сторінок сайту WordPress розкриває чимало технічної інформації, наприклад номер версії ядра (через тег <meta generator>), версії CSS-стилів і JS-скриптів (додаючи до їх URL-адрес параметри з номерами). Цю інформацію дуже легко спарсити такими інструменти командого рядка як: curl, wfuzz, wpscan.
Цього варто уникати, адже розкривши технічні деталі, зловмисник запросто зможе відшукати вразливості, а потім написати шкідливий сценарій або підібрати готовий експлойт для їх експлуатації.
Приховати версії компонентів WordPress найпростіше з допомогою плагінів безпеки Wordfence Security та Sucuri Security:
Можна також вручну дописати код в functions.php:
function remove_version_info() { return ''; } add_filter('the_generator', 'remove_version_info');
Або цей код (використовується інший метод):
// remove version from head
remove_action('wp_head', 'wp_generator');
// remove version from rss
add_filter('the_generator', '__return_empty_string');
// remove version from scripts and styles
function collectiveray_remove_version_scripts_styles($src) {
if (strpos($src, 'ver=')) {
$src = remove_query_arg('ver', $src);
}
return $src;
}
add_filter('style_loader_src', 'collectiveray_remove_version_scripts_styles', 9999);
add_filter('script_loader_src', 'collectiveray_remove_version_scripts_styles', 9999); Не варто забувати і про HTML-коментарі, котрі додаються компонентами CMS або самими розробниками й також розкривають технічну інформацію:
Рекомендується здійснити стискання і міфікацию вихідного коду, вилучаючи з нього усе зайве, роблячи його складним для зовнішнього прочитання.
Змінити стандартний префікс бази даних WordPress
По-замовчуванню, база даних WordPress має префікс wp_. Це полегшує зловмисникам пошук та виявлення таблиць бази даних.
Змінити префікс можна з допомогою серверної утиліти PhpMyAdmin або спеціальних плагінів WordPress:
Моніторити зміни у вихідному коді сайту
Для цього рекомендую встановити плагіни Sucuri Security та Wordfence Security:
Sucuri Security – Auditing, Malware Scanner and Security Hardening
Wordfence Security – Firewall, Malware Scan, and Login Security
Обоє містять функціонал для відстеження змін на сайті, наприклад:
- Історія успішних входів на сайт WordPress;
- Список невдалих входів на сайт, включаючи спроби атак;
- Сповіщення на email про кожен новий вхід на сайт;
- Зміни в ядрі WordPress;
- Зміни і порівняння у вихідному коді файлів WordPress;
- Список плагінів, які потребують оновлення.
Вимкнути вбудований редактор коду WordPress
У CMS WordPress Адміністратор може редагувати вихідний код файлів, теми та плагіни одразу в адмін-панелі з допомогою вбудованого редактора коду (Appearance -> Theme Editor):
Однак це створює додаткові ризики безпеки. Хакери нерідко проникають в адміністративну частину й завдяки увімкненому редактору залишають реверс-шели в файлах тем, наприклад в файлах 404.php або footer.php, після чого віддалено керують сервером зі своєї хост-машини (атаки Remote Code Execution (RCE)).
Рекомендується працювати з файлами сайту лише через захищені протоколи sFTP або SSH. Вимкнути вбудований редактор коду WordPress можна додавши в wp-config.php рядок:
// Disable WordPress file editor define( 'DISALLOW_FILE_EDIT', true );
Обмежити інформацію у robots.txt
Robots.txt — це службовий файл, який встановлює правила індексації сайту для пошукових ботів. З його допомогою можна заборонити пошуковим системам індексувати ті чи інші сторінки сайту.
Часто Адміністратори намагаються через robots.txt приховати якомога більше службових директорій та конфіденційних файлів сайту. Таким чином вони полегшують роботу зловмисникам і видають список прихованих ресурсів, які ті використовують як ціль для своїх атак:
Отже, robots.txt варто створювати якомога лаконічнішим. Для блокування індексації тих чи інших веб-сторінок рекомендується застосовувати тег <meta name =”robots” content=”noindex, nofollow”>, а також серверні права доступу на файли і папки (chmod, chown). Таким чином, якщо пошуковий бот або відвідувач полізуть туди куди не треба, від сервера надійде код 403 – “Відмова у доступі”.
Застосувати захист від ботів Captcha
Captcha (Completely Automated Public Turing Test) — це автоматична система перевірки та захисту електронних ресурсів від ботів та спаму. Технологія перевіряє цифровий слід відвідувача: IP-адресу, країну, User-Agent та інші параметри. Якщо виявить підозру, попросить підтвердити, що ви не бот, інакше обмежить доступ.
З допомогою Captcha можна захистити будь-які сенситивні об’єкти та елементи на сайті, наприклад форми, кнопки, поля вводу і таке інше. Це чудовий захист від спамерів.
Відсутність капчі, дає можливість атакуючому провести ін’єкцію шкідливого коду, підмінити або перехопити дані, завантажити шелл:
Увімкнути капчу на WordPress-сайті можна з допомогою сервісу hCaptcha / Cloudflare Turnstile та плагіну Wordfence Security, або будь-якого іншого який підтримує reCAPTCHA v2/v3.
Підключити антиспам-систему
Способів як це зробити – насправді безліч. Починаючи від інтеграцій таких загальновідомих рішень як Fail2ban та SpamAssasin, та закінчуючи встановленням спеціального плагіна для WordPress.
Одним із кращих є Maspik, який налаштовується у два кліки, містить багато правил та інтеграцій:
Фільтрувати вхідний трафік
Зловмисники намагатимуться просканувати ваш сайт, перебираючи різні комбінації URL-адрес (фаззінг), відправляючи GET (отримання) та POST (відправка) запити, підмішуючи до них різноманітні нелогічні і динамічні параметри, які називаються “payloads”, щоб таким чином виявити слабкі точки.
Фільтрація трафіку дозволить своєвчасно виявляти подібні кіберзагрози, відхиляти і блокувати будь-які невалідні та шкідливі HTTP-запити, токсичні User-Agent’и, хости, геолокації, адреси і так далі. А головне – приховати IP-адресу сайту, на яку націлюються хакери!
Реалізувати всі вищеперераховані функції можна з допомогою хмарного онлайн-сервісу Cloudflare WAF. Ви отримаєте надійний зовнішній мережевий екран-брандмауер для вашого сайту. Ви також зможете сформувати будь-які свої правила блокування у разі виявленнях тих чи інших несанкціонованих дій та аномалій.
Додатковим шаром безпеки для CMS WordPress буде також вищезгаданий Wordfence Security:
Регулярно сканувати і оновлювати WordPress
Зберігайте сайт в актуальному стані. Мало не щодня в інтернеті з’являються нові загрози та вразливості. Не використовуйте піратські “nulled” та “warez” плагіни – вони можуть містити шкідливий код (закладки, бекдори) й сповільнювати роботу сайту, викликаючи збої та помилки.
Просканувати WordPress та всі його компоненти допоможуть наступні плагіни:
Wordfence Security – Firewall, Malware Scan, and Login Security
Також додатково рекомендую скористатися окремими зовнішніми DAST-сканерами, які дозволять самотужки провести аудит безпеки й комплексно оцінити його захищеність, наприклад:
Здійснювати регулярне резервне копіювання
Резервна копія (backup) — це дамп, дублікат даних електронного ресурсу, який включає увесь вміст — файли і папки сайту, базу даних. Збережений дамп дає можливість швидко відновити сайт до попереднього стану.
Ось плагіни, які підійдуть для резервного копіювання WordPress:
Здійснювати регулярний моніторинг системних журналів (логів сервера)
Уважно спостерігаючи за системними журналами, можна виявити і погасити будь-яку атаку ще в її зародковій формі.
Кожен веб-сервер по замовчуванню генерує 2 типи логів:
- Access.log – логи доступу, в яких реєструються відвідувачі та їх дії, будь-які HTTP-запити (GET/POST/HEAD/OPTIONS і т.д.), включаючи пошукових та інших ботів;
- Error.log – логи помилок, у яких реєструються будь-які проблеми, баги, конфлікти на рівні системи.
Окрім цього у WordPress існує власний log-файл:
- Debug.log – логи відладки ядра WordPress, де реєструються будь-які важливі поовідомлення та помилки на рівні СMS.
Дуже важливо їх щоденно передивлятися і моніторити, що забезпечити стабільне та надійне функціонування електронного ресурсу. Це можна робити як з допомогою автоматизованих систем, наприклад GoAccess або Zabbix, так і стандартними засобами командного рядка Linux, наприклад:
tail -n 50 access.log– перегляд останніх 50 рядків журналу;tail -n 100 -f access.log– виводить останні 10 рядків журналу і стежить за наступними запитами в режимі реального часу;tail -f access.log | grep "ERROR"– фільтрація логів в режимі реального часу;tail -f access.log error.log– перегляд декількох логів одночасно в режимі реального часу;grep "User-Agent" access.log | grep "YYYY-MM-DD"– пошук в логах запитів від заданого юзер-агента та за вказаною датою.
Виявлені шкідливі IP-адреси варто перевіряти, вносити в чорні списки та блокувати на рівні сервера з допомогою фарєвола. Одним з кращих рішень є CSF Firewall – синхронізується з IPTablecs, LFD, Fail2ban, ClamAV, дозволяє формувати різноманітні правила доступу, обмежувати доступ за геолокацією, формувати білі та чорні списки і багато іншого.
Налаштувати безпеку сервера
Варто дбати не тільки про безпеку сайту, а й сервера на якому він розміщений. Якщо сервер вразливий, то всі старання щодо захисту WordPress будуть зведені нанівець.
Зокрема, перевірте все, що стосується мережевих TCP/UDP портів:
- Закрийте порт бази даних — 3306
- Закрийте порт Remote Desktop Protocol — 3389
- Закрийте або приховайте порти хостинг-панелі (cPanel, VestaCP, CyberPanel, DirectAdmin, Plesk або ін.)
- Закрийте будь-які інші порти інтерфейсів, котрі не використовуються або мають високий ступінь важливості
- В ідеалі, бажано залишити публічно доступними лише порти HTTP — 80 та HTTPS — 443
Проведіть аудит безпеки SSH-з’єднання, яке найчастіше піддається bruteforce атакам:
- Змінити стандартний номер порта (замість 22 поставити будь-яке п’ятизначне число, попередньо надавши доступ у мережевому екрані на рівні сервера/хостинга)
- Заборонити вхід на сервер під обліковим записом root
- Дозволити вхід на сервер тільки з вашого IP
- Дозволити вхід на сервер лише по SSH-ключу безпеки
Встановіть спеціалізовані програмні модулі для захисту сервера:
Що робити якщо WordPress зламали?
- Негайно змінити паролі до всіх технічних засобів, вузлів, адміністративних частин та компонентів сайту, включаючи субдомени, сервери, хостинг-панель. Оновити доступи до всіх адмінок та служб керування: SSH, FTP, PhpMyadmin і т.д.
- Тичасово вимкнути публічний доступ до сайту.
- Зробити резервну копію усього сайту – файлів і бази даних. Це можна зробити швидко в командному рядку Linux, підключившись по SSH:
zip -r website-backup.zipтаmysqldump -u username -p databasename > dump_file.sql. - Деактивувати тимчасово усі плагіни. Можна просто перейменувати папку
/wp-content/pluginsі плагіни деактивуються скопом. - Видалити усіх користувачів сайту WordPress, створити нового Адміністратора (дописи старих адміністраторів автоматично експортуються в новий обліковий запис).
- Перевірити усі файли WordPress: тему (index.php, header.php, footer.php, functions.php і т.д.), ядро (wp-config.php, wp-settings.php, wp-load.php, wp-login.php і т.д.). Вмістилищем шкідливого коду можуть бути JavaScript і PHP скрипти, а також будь-які інші файли: документи, архіви, зображення (file.jpg.php, file.pdf.php, exploit.ico і ін.).
- Деактивувати або вилучити усі сторонні теми WordPress крім системних.
- Видалити будь-які підозрілі посилання, файли або папки з назвами, які не мають відношення до CMS WordPress і можуть бути шкідливими (напр., adminer, wso, r57, c99, hiddencode і т.п.).
- Перевірити файли .htaccess, robots.txt, sitemap.xml.
- Перевірити файли конфігурацій PHP, MySQL, SSH.
- По поможливості зробити відкати до “заводського стану” усіх службових компонентів і файлів WordPress.
- Перевірити планувальник Crontab на наявність несанкціонованих задач.
- Згенерувати нові ключі безпеки WordPress (Salt Keys) і оновити їх в wp-config.php (рядок AUTH KEYS).
- Запустити автоматичнее відновлення бази даних WordPress, додавши у wp-config.php рядок:
define( ‘WP_ALLOW_REPAIR’, true );та перейшовши за посиланнямhttps://your-site.com/wp-admin/maint/repair.php - Провести там також перевірку і оптимізацію таблиць бази даних MySQL. Не зайвим буде перевірити таблиці
wp_users(наявність прихованих користувачів) і wp_posts, wp_meta (на наявність шкідливого коду). - Перевірити сайт на шкідливий код спеціалізованими сканерами:
- Провести ручний пошук по базі даних – зробити її дамп, скачати SQL-файл на локальний комп’ютер, відкрити в редакторі вихідного коду Sublime Text або SciTE Editor та через пошук/заміна або регулярні вирази прибрати його. Варто звернути на такі вирази як: base64_decode, eval, document write та інші. Очищену базу зберегти у тому самому форматі і кодуванні та імпортувати назад.
- Звернутися до спеціалістів KR. Laboratories – ми допоможемо з захистом сайту на WordPress.
- Перейти на якісний та захищений хостинг, що унеможливить зараження від сайтів-сусідів і вразливостей самого хостингу.
- Перенести домен сайту на обслуговування в DNS Cloudflare.
WordPress Security Setup checklist
| Вразливість | Вплив | Усунення |
| Вивід версії CMS WordPress у вихідному коді | Знаючи версію CMS, можна підібрати експлойти і проексплуатувати їх. | Приховати версію WordPress з допомогою плагіну (WordFence, Sucuri, Clearfy) або через функцію у functions.php. |
| Лістинг директорій | Отримання структури сайту, доступ до внутрішніх файлів та папок сайту. | Внести відповідну директиву в .htaccess, виставити коректні права доступу на файли і папки. |
| Відсутність багатофакторної авторизації (2FA/MFA) | Підбір облікових даних і злам користувача з допомогою Bruteforce-перебору. | Підключити плагін двофакторної авторизації, наприклад WordFence Security. |
| Вивід версій компонентів WordPress у вихідному коді | Можна визначити застарілі компоненти і підібрати до них експлойти. | Відключити вивід версій для скриптів, плагінів, компонентів WordPress через плагін або функцію у functions.php. |
| Публічний доступ до форми авторизації wp-login.php | Боти можуть регулярно атакувати сторінку входу на сайт, спричинити навантаження на сервер та провести Bruteforce-перебір облікових даних. | Налаштувати преавторизацію HTTP Authorization через файл конфігурації веб-сервера htpasswd. Або змінити URL-адресу сторінки входу на сайт: замість /wp-login.php вказати будь-яке інше розташування. Можна також скористатись плагіном WPS Hide Login. |
| Публічний доступ до служби віддаленого керування WordPress – xmlrpc.php | DDoS-атака на службу XML-RPC, отримання технічних даних WordPress. | Відключити службу, якщо вона не використовується, або обмежити доступ віддавши код відповіді сервера 403 для всіх неавторизованих запитів. |
| Активний планувальник WordPress – WP-CRON | DDoS-атака на службу WP-CRON, перенавантаження сервера, технічні проблеми WordPress. | Відключити вбудований планувальник WordPress, натомість включити серверний планувальник Crontab. |
| Файли license.txt, readme.html та інші у публічному доступі | Витік службової та конфіденційної інформації WordPress, яка може використовуватися для підготовки атак. | Обмежити доступ до файлів з допомогою конфігурації веб-сервера (наприклад, .htaccess). |
| Файл debug.log у публічному доступі | Витік технічної інформації WordPress, яка може бути використана для підготовки атак. Можна проаналізувати стан сайту, дізнатися несправності і помилки, отримати список плагінів та серверних локальних директорій. | Обмежити доступ через файл конфігурацію веб-сервера. |
| Публічний доступ до службових директорій WordPress – /wp-admin, /wp-content/uploads, /wp-content/themes, /wp-content/plugins, /wp-includes та інших | Витік службової, конфіденційної, технічної інформації. Можна отримати доступ до системних файлів, проаналізувати структупу, дізнатися компоненти, підшукати експлойти та проексплуатувати їх. | Виставити коректні права на файли і папки WordPress, обмежити доступ з допомогою конфігурації веб-сервера. |
| Публічний доступ до файлів load-scripts.php і load-styles.php | Створює ризик DDoS-атаки. | Обмежити публічний доступ до файлів load-scripts.php і load-styles.php через конфігурацію веб-сервера. |
| Публічний доступ до файлів wp-config-sample.php, install.php, upgrade.php | Створює ризик витоку даних і несанкціонованог доступу, DDoS-атаки. | Обмежити публічний доступ до файлів wp-config-sample.php, install.php, upgrade.php. |
| Відсутність антибот-системи Captcha | Можливість провести ряда так: Email form spam, SQL/PHP/XSSi, MITM, DoS/DDoS та інші шкідливі навантаження, які можуть привести до компрометації, виведення з ладу або несанкціонованого доступу. | Підключити антибот-систему від Cloudflare, Google reCaptcha, hCaptcha або іншу. Інтегрувати її з допомогою плагіну WordFence Security або інших плагінів. Помістити чекбокс Captcha на всіх сторінках взаємодії користувача з сайтом (кнопки, форми, підписка, коментарі). |
| Кількість невірних спроб входу в адмін-панель WordPress необмежена | Атаки Bruteforce/DoS, навантаження, ризик підбору облікових даних і зламу WordPress. | Встановити плагін WordFence Security або Limit Login Attempts, які дозволяють встановити ліміт кількості невдалих спроб входу, а також не відображають підказок про невдалі спроби. |
| Доступ до ресурсів WP-JSON необмежено | Можливість проведення енумерації облікових записів, публікацій та інших типів записів й компонентів WordPress. Розкриття службової і технічної інформації, яка може бути використана для проведення атак. | Встановити плагін Disable REST API та обмежити доступ до ресурсів WP-JSON, зокрема /wp-json/wp/v2/users, /wp-json/wp/v2/posts, /wp-json/wp/v2/categories, /wp-json/wp/v2/tags, /wp-json/wp/v2/comments та інших. |
| Ввімкнений вбудований редактор коду в адмін-панелі WordPress | Ризик несанкціонованого доступу до файлової системи, розкриття конфіденційної інформації, можливість ексалації привілеїв, порушення цілісності і доступності сайту. | Вимкнути вбудований редактор коду в файлі конфігурації WordPress – wp-config.php. |
| Файл robots.txt містить шляхи до службових файлів і директорій сайту | Можливість проведення мережевої розвідки, визначення слабких місць в структурі сайту для націлювання різноманітних атак. | Зробити файл robots.txt мінімально інформативним, прибрати будь-яку чутливу інформацію про розташування адміністративних ресурсів. Внести директиви для блокування шкідливих інтернет-ботів. Для обмеження доступу до секретних директорій використовувати замість robots.txt файл конфігурації веб-сервера (напр., .htaccess) і тег meta robots. |
| База даних WordPress використовує стандартний префікс wp_ | Можливість проведення атак на MySQL базу даних WordPress. Ризик несанкціонованого доступу, компрометація службових даних. | Змінити префікс бази даних по-замовчуванню. Наприклад, це можна зробити з допомогою плагінів All in One Security або Brozzme DB Prefix. |
| HTTP-заголовки не оптимізовано | Проведення широкого ряду атак різного рівня по HTTP-протоколу. Зловмисник може здійснити спуфінг або хіджекінг. | Прибрати будь-які зайві чи застарілі HTTP-заголовки, відконфігурувати їх параметри. Додати заголовки безпеки HTTP Security Headers. Прибрати із HTTP-заголовків будь-яку конфіденційну інформацію, наприклад розголошення версії веб-сервера та його компонентів. |
| Відкриті мережеві TCP/UDP-порти | Проведення широкого ряду атак на стек TCP/IP, визначення топології мережі та версій серверного програмного забезпечення з метою подальшого підбору експлойтів і експлуатації. | Залишити публічно відкритими лише порти 80 і 443 або підключити CDN Cloudflare для маскування IP-адрес мережевих інтерфейсів та фільтрації трафіку. |
| Резервне копіювання файлів і бази даних WordPress не налаштовано | Неможливість оперативного відновлення даних після атаки або помилкової операції. Ризик втрати даних. | Налаштувати автоматичне резервне копіювання директорів сайту і бази даних на сервері. Або встановити плагін WordPress. Наприклад, BackWPup або UpdraftPlus з подальшим зберіганням дампів у хмарному сховищі (Dropbox, Google Drive аоб інше). |
| Моніторинг подій та змін WordPress не налаштовано | Неможливість запобігти несанкціонованим змінам у вихідному коді файлів сайту та здійснити їх відкат. Ризик несанкціонованого доступу. | Встановити плагін Sucuri Security для моніторингу за змінами у файлах та Wordfence Security контролю за подіями (наприклад, історія авторизацій, інцидентів). |
| Вихідний код сайту не стиснено | По замовчуванню вихідний код сайту має повністю читабельну деревовидну структуру, що дає зловмиснику добре проаналізувати його структуру, визначити компоненти, дізнатись технології та спланувати атаку. | Стиснути вихідний код сайту – провести мініфікацію HTML/CSS/JS, ускладнивши таким чином його прочитання. Також, можна відключити перегляд вихідного коду у браузері – заблокувавши комбінацію клавіш CTRL+U. |
| Вихідний код сайту містить чутливі дані | Будь-які зайві або чутливі дані (наприклад, токени, коди доступу) надають додаткову інформацію для планування і здійснення атак. Зайва інформація у вихідному коду, наприклад коментарі також може спричиняти технічні проблеми, знищувати швидкодію сайту. | Проінспектувати увесь вихідний код і прибрати будь-яку зайву інформацію: коментарі розробника, коментарі з назвами та версіями компонентів, коментарі плагінів, токени доступу, URL-посилання і таке подібне. |
| Вихідний код сайту невалідний | Ризик технічних проблем і помилок безпеки. | Провести повну валідацію вихідного коду сайту у відповідності з стандартом W3C. Видалити зайві теги, будь-який прихований код, замінити застарілий синтаксис. |
| Відсутній захист контенту від несанкціонованого копіювання | Ризик несанкціонованого копіювання авторського контенту, пессимізація текстів, зменшення позицій і довіри збоку пошукових систем. Репутаційні збитки. Зловмисник може застосувати різні техніки “чорного SEO” для викрадення і публікації вашого контенту на своїх ресурсах. | Налаштувати автоматичну вставку копірайту при копіюванні текстів з вашого сайту. Усі зображення, брендові знаки і символи – запатентувати. Віддавати перевагу формату .webp. Підключити DMCA Protection для всіх сторінок сайту. Додатково можна підключити стандарт BIMI, який авторизує та вставляє логотип бренду в email-листах. Прописати умови використання контенту в Політиці конфіденційності і Правилах сайту. |
| Відсутні сторінки Політика конфіденційності (Privacy Policy) та Правила сайту (Terms of Use) | Ці сторінки є обов’язковими з точки зору регламенту про захист даних GDPR. Їх відсутність дає простір для маніпуляцій з вашим контентом та зменшує довіру до сайту збоку користувачів і пошукових систем. | Створити сторінки Політика конфіденційності та Правила сайту. Вичерпно прописати текст для них відповідно до GDPR. |
| Файл конфігурації PHP.INI не оптимізовано | Відсутність коректних налаштувань в PHP.INI приводить до помилок та ризиків безпеки, підвищеного навантаження та сповільнення роботи сайту. | Провести оптимізацію налаштувань PHP.INI для сайту WordPress, задати значення для директив: max_execution_time, max_input_time, max_input_vars, memory_limit, post_max_size, upload_max_filesize, allow_url_fopen, allow_url_include, session.cookie_httponly, session.cookie_samesite, session.cookie_secure. |
| На сайті включений показ системних помилок | Вивід помилок сайту на екрані в браузері повідомляє про вразливі компоненти та розташування системних папок і файлів. Це дає змогу підшукати вразливості та проексплуатувати їх. | Необхідно відредагувати файл конфігурації wp-config.php та додати/змінити наступні директиви: define (‘WP_DEBUG “, false); define(‘WP_DEBUG_DISPLAY’, false); |
| Відсутня заборона на виконання файлів у папці /wp-content/uploads | Дає простір для проведення атак з віддаленим виконанням шкідливого коду – Remote Code Execution (RCE), File Upload Attack, LFI/RFI. Ризик несанкціонованого доступу та втрати даних. | Заборонити несанкціоноване завантаження і виконання файлів різного розширення (.php, .phtml, .php.jpg і ін.) у папці WordPress – uploads, встановивши плагін Wordfence Security або самостійно додавши відповідну директиву в конфігурацію веб-сервера (.htaccess). |
| Ключі безпеки WordPress не змінювалися більше 2-х років (WP SALT KEYS) | Ключі безпеки CMS WordPress знаходяться у файлі конфігурації wp-config.php та використовуються системою для шифрування даних. Часто вони можуть бути скомпрометовані, особливо часто це стається при перенесенні сайту на інший сервер. | Зенерувати нові ключі тут (https://api.wordpress.org/secret-key/1.1/salt/) та оновити їх у файлі wp-config.php. Або через плагін Sucuri Security. |
| На сайті присутній користувач з логіном admin | Користувач з логіном admin, зазвичай, належить адміністратору WordPress. Знайти такий обліковий запис дуже легко. Зловмиснику після цього залишається тільки підібрати пароль до нього для отримання несанкціонованого доступу. Тому не рекомендується використовувати імена, які вказують на права адміна. | Необхідно створити нового користувача з правами адміністратора, вказавши унікальний логін (раніше ніде не застосований) та складний пароль (довжиною не менше 20 знаків, комбінуючи символи верхнього та нижнього регістру), а користувача admin – вилучити, перенісши його матеріали на новий акаунт. |
| Відсутній редирект з http на https версію сайту | HTTP-протокол є незахищеним та вразливий до цілого ряду атак. | Перевірити наявність SSL-сертифікату та встановити усі необхідні редиректи для усіх сторінок з HTTP на захищену HTTPS-версію сайту. |
| Публічний доступ до панелі PhpMyAdmin | Ризики несанкціонованого доступу та злам бази даних. | Обмежити доступ до панелі PhpMyAdmin, наприклад змінити URL-входу та дозволити лише для довіреного списку IP. Зробити доступним тільки на конкретному мережевому порту. |
| Використовуються NS-сервери хостинг-провайдера | Витік і розкриття конфіденційних даних, які можуть бути використані для націлення атак. Дає можливість дізнатися IP-адресу сервера та суміжних ресурсів, скласти карту мережі, провести DDoS-атаки та атаки на DNS. Виведення сайт з ладу. | Перевести сайт на обслуговування до DNS Cloudflare. Замаскувати усі публічні IP-адреси. Розподілити і розмежувати різні корпоративні сервіси (файли, пошта). |
Додаткові джерела та посилання
- KR. Laboratories. Збірка документів на тему безпеки WordPress.
- SUCURI. 12 Best Practices to Secure Your WordPress Login Page
- LINKEDIN. How to Prevent WordPress Session Hijacking Attacks
- Medium. WordPress Static Analysis Code
Автор: © Konrad Ravenstone, KR. Laboratories Research
