Як захистити сайт на WordPress

«Кому потрібен наш маленький сайт? Ми ж не банк», — це найчастіша фраза, яку ми чуємо від власників, чий WordPress уже зламали. І вона зрозуміла: здається, що зловмисник має спеціально обрати саме вашу компанію. Насправді ніхто не обирає. Боти щодня перебирають мільйони адрес, шукаючи відомі вразливості в плагінах, слабкі паролі й забуті тестові копії. Якщо на вашому сайті є відчинене вікно, його знайдуть автоматично — без жодного інтересу до вашого бізнесу.

Наслідки при цьому цілком персональні: спам-сторінки в індексі Google, попередження «Цей сайт може бути небезпечним» у браузері, розсилки з вашого домену, перенаправлення відвідувачів на шахрайські ресурси, а для магазину — ризик витоку даних клієнтів. Добра новина в тому, що від переважної більшості атак захищає не дорога «кібербезпека», а дисципліна в кількох базових речах. Нижче — практичні кроки, які ми впроваджуємо на сайтах наших клієнтів, у тому порядку, в якому радимо робити це вам.

Чому зламують звичайні сайти на WordPress

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

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

Причина	Як це виглядає на практиці	Що закриває ризик
Застарілі плагіни й теми	Плагін не оновлювали роками, про вразливість уже писали публічно	Регулярні оновлення, видалення зайвого
Слабкі або повторні паролі	Логін admin, пароль із назви компанії, той самий пароль, що й на пошті	Менеджер паролів, 2FA, обмеження спроб входу
«Зламані» платні плагіни	Преміум-тему завантажили безкоштовно з неофіційного сайту	Лише офіційні джерела й ліцензії
Зайві доступи	Колишній підрядник досі має акаунт адміністратора	Ролі за принципом мінімальних прав, ревізія користувачів
Слабкий хостинг і налаштування	Старий PHP, FTP без шифрування, сусідні сайти на одному акаунті	Сучасний хостинг, правильні права файлів, SFTP

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

Крок 1. Оновлення: ядро, плагіни, теми і PHP

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

Ось як ми організовуємо оновлення на сайтах, які підтримуємо:

1. Ядро WordPress. Дрібні оновлення безпеки лишаємо автоматичними — їх не варто вимикати. Великі версії встановлюємо протягом кількох днів після виходу, спершу на тестовій копії.
2. Плагіни й теми. Перевіряємо оновлення щонайменше раз на тиждень. Для перевірених, простих плагінів вмикаємо автооновлення; для критичних — магазину, конструктора сторінок, форм оплати — оновлюємо вручну після тесту.
3. Версія PHP. Стежимо, щоб сервер працював на версії, яка ще отримує виправлення безпеки. Застарілий PHP — це вразливість, яку не закриє жоден плагін.
4. Бекап перед оновленням. Завжди. Якщо щось зламається, повертаємося за кілька хвилин, а не за кілька днів.

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

Перед встановленням нового плагіна ми перевіряємо кілька речей: коли було останнє оновлення, скільки активних встановлень, чи відповідає автор на запитання в підтримці, чи не було серйозних вразливостей без швидкого виправлення. Плагін, який не оновлювали понад рік, — привід пошукати альтернативу. А «безкоштовні» версії платних тем і плагінів з неофіційних сайтів ми не встановлюємо ніколи: у таких збірках часто вже вбудований шкідливий код, і власник фактично сам заносить його на сервер.

Крок 2. Паролі, ролі та двофакторна автентифікація

Другий за поширеністю шлях на сайт — через сторінку входу. Боти перебирають популярні логіни й паролі або підставляють пари, що витекли з інших сервісів. Якщо адміністратор використовує той самий пароль, що й на старому форумі, — питання лише в часі.

Паролі та логіни

• Кожен користувач має унікальний пароль від 16 символів, згенерований менеджером паролів (Bitwarden, 1Password, KeePass чи аналог). Запам’ятовувати його не потрібно.
• Логіни на кшталт admin, administrator чи назви домену ми не використовуємо — це перше, що пробують боти.
• Паролі не пересилаємо в месенджерах і не зберігаємо в листуванні. Для передачі доступів — менеджер паролів зі спільним сховищем.
• Окремо міняємо паролі до хостингу, бази даних, SFTP і поштової скриньки, на яку відновлюється доступ до адмінки. Злам пошти — це злам сайту.

Двофакторна автентифікація

2FA — один із найефективніших заходів за співвідношенням зусиль і результату. Навіть якщо пароль витік, без коду з телефону увійти не вийде. У ядрі WordPress двофакторної автентифікації немає, тому ми підключаємо її через плагін — наприклад, офіційний Two Factor, Wordfence Login Security чи модуль комплексного плагіна безпеки. Обов’язково — для адміністраторів і редакторів, бажано — для всіх, хто може публікувати контент.

Ми радимо коди з застосунку-автентифікатора або апаратні ключі, а не SMS. І обов’язково зберігаємо резервні коди в менеджері паролів: людина, яка загубила телефон, не повинна блокувати роботу всього сайту.

Ролі за принципом мінімальних прав

У WordPress є стандартні ролі: адміністратор, редактор, автор, учасник, підписник. Копірайтеру достатньо ролі автора, контент-менеджеру — редактора, менеджеру магазину — ролі «Менеджер магазину» у WooCommerce. Адміністраторів має бути один-два. Раз на квартал ми проводимо ревізію: видаляємо акаунти колишніх співробітників і підрядників, а тимчасові доступи для розробника відкриваємо лише на час робіт.

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

• обмеження кількості спроб входу з тимчасовим блокуванням IP;
• вимкнення xmlrpc.php, якщо його не використовують мобільні застосунки чи інтеграції, — через нього також перебирають паролі;
• контроль паролів застосунків (Application Passwords): якщо їх ніхто не використовує, функцію можна вимкнути.

Перейменування сторінки входу з /wp-admin/ на щось інше ми вважаємо корисним, але другорядним заходом. Воно зменшує «шум» від ботів у журналах, проте не замінює сильних паролів і 2FA.

Крок 3. Бекапи, з яких справді можна відновитися

Бекап — це не захист від зламу, а страховка на випадок, коли все інше не спрацювало. І саме тут ми найчастіше бачимо ілюзію безпеки: «у нас хостинг робить копії». На практиці виявляється, що копії зберігаються лише кілька днів, лежать на тому самому сервері, що й сайт, або ніхто ніколи не пробував із них відновитися.

Ми орієнтуємося на правило 3-2-1: три копії даних, на двох різних типах сховищ, одна з них — поза основним сервером. Для WordPress це означає таку схему:

1. Що копіюємо: і файли (тема, плагіни, завантаження, wp-config.php), і базу даних. Копія лише бази без медіафайлів — половина сайту.
2. Як часто: для сайту-візитки достатньо щоденних копій, для магазину чи сайту з постійними заявками — копії бази кілька разів на день.
3. Де зберігаємо: окрім копій хостингу — зовнішнє хмарне сховище з окремим доступом, якого немає в адмінці сайту. Якщо зловмисник отримає контроль над сервером, він не повинен мати змоги видалити і бекапи.
4. Скільки зберігаємо: щонайменше 30 днів історії. Злам часто помічають не одразу, і свіжі копії вже містять шкідливий код. Потрібна точка, коли сайт був гарантовано чистий.
5. Перевірка: раз на квартал розгортаємо бекап на тестовому середовищі й перевіряємо, що сайт працює. Бекап, з якого ніхто не відновлювався, — це лише надія.

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

Крок 4. Права доступу та налаштування сервера

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

• Права файлів. Типова безпечна схема: 755 для каталогів, 644 для файлів, суворіші права для wp-config.php (наприклад, 640 або 600, залежно від хостингу). Права 777 «щоб усе працювало» — пряме запрошення для зловмисника.
• Заборона редагування коду з адмінки. Рядок define('DISALLOW_FILE_EDIT', true); у wp-config.php прибирає вбудований редактор тем і плагінів. Якщо хтось отримає доступ до адмінки, він не зможе одразу вписати шкідливий код через браузер.
• Заборона виконання PHP у каталозі завантажень. У /wp-content/uploads/ мають лежати картинки й документи, а не скрипти. Правило на рівні сервера не дасть запустити завантажений туди файл.
• SFTP або SSH замість FTP. Звичайний FTP передає пароль у відкритому вигляді. Для SSH ми використовуємо ключі замість паролів.
• HTTPS на всьому сайті з автоматичним продовженням сертифіката та редиректом з HTTP.
• Окремий користувач бази даних для кожного сайту, з правами лише на свою базу.
• Ізоляція сайтів. Якщо на одному хостинг-акаунті живуть п’ять сайтів, злам найслабшого заражає всі. Старі тестові копії й забуті проєкти ми або видаляємо, або виносимо в окремі акаунти.

Окремо ми закриваємо доступ ззовні до службових файлів: резервних копій у кореневому каталозі, файлів журналів, .git, архівів на кшталт site-backup.zip. Такі «забуті» архіви з паролями до бази — класична знахідка під час аудиту. До речі, на якість хостингу варто дивитися не лише з погляду безпеки: від нього напряму залежить і швидкість, про яку ми детально говоримо в межах послуги оптимізації сайту.

Крок 5. WAF і захист від ботів

WAF (Web Application Firewall) — це фільтр, який аналізує запити до сайту й відсікає підозрілі ще до того, як вони дійдуть до WordPress. Він блокує типові атаки, відомі шкідливі IP, сканери вразливостей і масовий перебір паролів. Головна цінність WAF у тому, що він часто закриває свіжу вразливість у плагіні ще до того, як ви встигли його оновити.

Є два основні підходи, і вони добре доповнюють один одного:

Тип	Приклади	Переваги	Обмеження
Хмарний WAF	Cloudflare, Sucuri	Фільтрує трафік до сервера, знімає навантаження, часто дає CDN і прискорення	Потребує правильного налаштування DNS і кешу, інакше можна зламати форми чи кошик
WAF на рівні WordPress	Wordfence, Solid Security, аналоги	Бачить контекст WordPress, поєднується зі сканером файлів і 2FA	Працює на тому самому сервері й споживає його ресурси

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

Окрім WAF, ми налаштовуємо обмеження частоти запитів до сторінки входу, форм і пошуку, а також захист форм від спаму (наприклад, невидиму капчу). Це не лише безпека: боти, що бомбардують форми й пошук, створюють зайве навантаження і сповільнюють сайт для реальних відвідувачів.

Крок 6. Моніторинг: помітити проблему за години, а не за місяці

Найнеприємніші зломи — тихі. Сайт виглядає нормально, а тим часом у ньому живуть спам-сторінки, прихований редирект для мобільних відвідувачів чи скрипт, що краде дані з форм. Власник дізнається про це через місяці — від клієнтів, від хостингу, який заблокував акаунт, або від Google. Моніторинг потрібен, щоб скоротити цей час до годин.

Наш мінімальний набір моніторингу для бізнес-сайту:

• Моніторинг доступності з перевіркою кожні кілька хвилин і сповіщенням на пошту чи в месенджер.
• Контроль цілісності файлів: сканер порівнює файли ядра й плагінів з оригіналами та повідомляє про зміни. Для ядра це можна зробити й командою wp core verify-checksums у WP-CLI.
• Журнал дій користувачів: хто входив, хто створив нового адміністратора, хто встановив плагін. Поява невідомого адміністратора — тривожний сигнал номер один.
• Google Search Console: звіт «Проблеми безпеки» і сповіщення на пошту. Різкий стрибок кількості проіндексованих сторінок або дивні запити у звіті «Ефективність» часто першими сигналізують про спам-сторінки.
• Сповіщення про вхід в адмінку з нового пристрою чи країни для адміністраторів.

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

Як це виглядає на практиці

Типова ситуація: сайт компанії на WordPress, зроблений кілька років тому. Підрядник давно не на зв’язку, адмінкою користуються троє співробітників під одним логіном admin. Встановлено понад тридцять плагінів, частину з яких не оновлювали з моменту запуску, тема куплена «зі знижкою» на сторонньому сайті. Бекапи робить хостинг, але зберігає лише кілька днів.

Ми починаємо зі свіжого бекапу на зовнішнє сховище й перевірки файлів на сторонній код. Потім створюємо персональні акаунти з потрібними ролями, вмикаємо 2FA, видаляємо невикористані плагіни, замінюємо тему з неофіційного джерела ліцензійною, оновлюємо все інше й PHP. Далі — права файлів, заборона редагування коду з адмінки, хмарний WAF, моніторинг доступності й цілісності файлів, налаштування Search Console. Після цього сайт переходить на регулярне обслуговування: оновлення щотижня, ревізія доступів щокварталу, тестове відновлення з бекапу. Ніхто не може пообіцяти, що зламу не буде ніколи, — але ризик падає кардинально, а якщо щось станеться, ми помітимо це швидко й відновимося з чистої копії.

Помилки, які ми бачимо найчастіше

1. «Встановили плагін безпеки — і забули». Плагін без оновлень, 2FA і бекапів — це табличка «Обережно, злий пес» без собаки.
2. Спільний логін для всіх. Неможливо зрозуміти, хто що зробив, і неможливо забрати доступ в однієї людини.
3. Деактивовані, але не видалені плагіни. Їхній код лишається на сервері й може бути вразливим.
4. Бекапи лише на тому самому сервері. Разом із сайтом зникають і копії.
5. Оновлення «колись потім» через страх, що сайт зламається. Рішення — тестова копія і бекап, а не відмова від оновлень.
6. Забуті тестові копії та старі сайти на тому самому хостингу, які ніхто не оновлює.
7. Відновлення з бекапу без пошуку причини. Якщо не закрити діру, через яку зайшли, сайт заразять знову за кілька днів.

Короткий чек-лист безпеки WordPress

• Ядро, плагіни, теми й PHP оновлені; зайві плагіни видалені.
• Усі плагіни й теми — з офіційних джерел.
• Унікальні паролі з менеджера паролів, жодного логіна admin.
• 2FA для всіх адміністраторів і редакторів.
• Кожен користувач має персональний акаунт із мінімальною потрібною роллю.
• Автоматичні бекапи файлів і бази, зовнішнє сховище, історія від 30 днів, перевірене відновлення.
• Права файлів налаштовані, редагування коду з адмінки вимкнене, PHP в uploads заборонений.
• SFTP або SSH з ключами, HTTPS на всьому сайті.
• WAF і обмеження спроб входу.
• Моніторинг доступності, цілісності файлів, журнал дій, Search Console.

Часті запитання

Чи достатньо встановити один плагін безпеки?

Ні. Плагін безпеки — корисний шар, але він не оновить за вас інші плагіни, не зробить зовнішній бекап і не змусить співробітників користуватися унікальними паролями. Захист працює лише як система: оновлення, доступи, бекапи, налаштування сервера, фільтрація трафіку й моніторинг.

Чи безпечніший сайт на іншій CMS чи «самописний»?

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

Як часто треба займатися безпекою сайту?

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

Що робити, якщо сайт уже зламали?

Не видаляти все поспіхом і не відновлювати бекап наосліп. Спершу змінити всі паролі (адмінка, хостинг, база, пошта), зберегти поточний стан для аналізу, знайти точку входу, очистити сайт або відновити його з гарантовано чистої копії, закрити вразливість і лише потім повертати сайт у роботу та подавати запит на перевірку в Search Console. Якщо немає досвіду, краще одразу звернутися до фахівців: помилки на цьому етапі коштують дорожче. Що власник може зробити сам, а що краще доручити спеціалістам, ми розбирали в статті «Самостійне просування: як це працює».

Підсумок

Захист сайту на WordPress — це не одна чарівна кнопка, а шість простих звичок: вчасні оновлення, надійні паролі з 2FA, перевірені бекапи поза сервером, правильні права й налаштування хостингу, WAF і моніторинг. Кожна з них окремо закриває частину ризиків, а разом вони роблять ваш сайт значно складнішою ціллю, ніж тисячі інших, які боти зламають швидше.

Безпека особливо важлива для магазинів, де на кону дані клієнтів і платежі. Якщо ви плануєте запуск, ми закладаємо ці практики ще на етапі розробки інтернет-магазину.

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