Коротка відповідь: Тримайте ядро, теми та плагіни оновленими; використовуйте сильні унікальні паролі + 2FA; задайте правильні права на файли (директорії 755, файли 644, wp-config.php 640); вимкніть вбудований редактор файлів; додайте security-плагін (Wordfence або подібний) — і зміцніть сам сервер, бо на VPS WordPress захищений рівно настільки, наскільки захищена машина під ним.

Огляд

Зломи WordPress переважно заходять через четверо дверей: застарілі плагіни, слабкі/повторювані паролі, слабкі місця на рівні хостингу та «nulled» теми. На VPS ви контролюєте кожен шар, тож скромний чекліст закриває всі чотири. Ця стаття — практичний розбір; стисла версія живе у чеклісті безпеки.

Що потрібно мати

  • Серверна база зроблена: SSH-ключі, фаєрвол, без парольного входу root — див. захист VPS.
  • Робочий бекап — безпека без бекапів це половина плану.

Покрокова інструкція

  1. Оновлюйте все, де розумно — автоматично: мінорні оновлення ядра увімкнені за замовчуванням; для перевірених плагінів розгляньте автооновлення: wp plugin auto-updates enable --all (спочатку перегляньте, що у вас стоїть).
  2. Акаунти: унікальні імена адмінів (не «admin»), сильні паролі, 2FA-плагін для всіх адміністраторів, видалення невикористаних акаунтів.
  3. Права та захист файлів:
    sudo find /var/www/example.com -type d -exec chmod 755 {} \;
    sudo find /var/www/example.com -type f -exec chmod 644 {} \;
    sudo chmod 640 /var/www/example.com/wp-config.php
    Додайте у wp-config.php: define('DISALLOW_FILE_EDIT', true);
  4. Зменшіть поверхню атаки: заблокуйте xmlrpc.php на вебсервері, якщо не використовуєте, обмежте спроби входу (див. захист від brute-force), повністю видаліть неактивні теми/плагіни.
  5. Виявлення: поставте Wordfence або сканер на базі WPScan і дивіться auth-логи на сервері; щотижневий wp core verify-checksums ловить змінені файли ядра.

Типові проблеми

  • «Захищений» сайт на непатченому сервері: ОС теж потребує оновлень — unattended-upgrades закриває security-патчі на Ubuntu/Debian.
  • Nulled/піратські теми: найпоширеніше джерело малварі — ніколи їх не ставте.
  • Занадто жорсткі права ламають оновлення: якщо WordPress не може писати у wp-content, падають оновлення й завантаження — дерево має належати користувачу вебсервера.

Коли звертатися в підтримку

Підозрюєте активний злом (дефейс, спам-сторінки, аномалії трафіку)? Зробіть знімок поточного стану для форензики та відкрийте тикет — команда допоможе на рівні платформи (наприклад, мережева ізоляція), поки ви чистите застосунок.

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

Як найчастіше зламують сайти на WordPress?

Через застарілі плагіни й теми з відомими вразливостями, а далі — слабкі чи повторювані паролі. Регулярні оновлення та ввімкнена 2FA прибирають два найбільші вектори атак.

Чи потрібен security-плагін на захищеному VPS?

Так — зміцнення сервера захищає машину, а security-плагін стежить за рівнем застосунку: зловживання логіном, зміни файлів і відомо вразливі компоненти всередині самого WordPress.

Які права на файли має використовувати WordPress?

Директорії 755, файли 644, wp-config.php 640, все у власності користувача вебсервера (www-data). Ніколи не ставте 777 — це дозволяє будь-якому процесу на сервері писати у ваш код.

Схожі статті

Потрібна допомога? Звернутися в підтримку Cloud2Y →

Ця відповідь Вам допомогла? 0 Користувачі, які знайшли це корисним (0 Голосів)