Як захистити сайт від злому

Захист сайту від зламу

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

Як зловмисники отримують початковий доступ

Майже ніколи злам не починається з підбору пароля адміністратора напряму — це занадто повільно за увімкненого блокування спроб входу. Реальні вектори частіше інші: викрадені облікові дані FTP із зараженого комп'ютера розробника, відома вразливість у конкретній версії плагіна, яку не оновили вчасно, або фішинговий лист, через який пароль від панелі керування потрапив не в ті руки. Захист від кожного з цих векторів різний, тому одного заходу недостатньо — потрібен набір бар'єрів.

Основні правила

• Використовуйте складні паролі для cPanel, FTP і бази даних
• Регулярно оновлюйте CMS, теми і плагіни
• Видаляйте невикористовувані плагіни і теми
• Увімкніть двофакторну автентифікацію в білінгу

Як виглядає атака в логах сервера

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

1.2.3.4 - - [30/Sep/2026:03:14:11] "GET /wp-config.php.bak HTTP/1.1" 404
1.2.3.4 - - [30/Sep/2026:03:14:12] "GET /.env HTTP/1.1" 404
1.2.3.4 - - [30/Sep/2026:03:14:13] "GET /xmlrpc.php HTTP/1.1" 200
1.2.3.4 - - [30/Sep/2026:03:14:14] "POST /wp-login.php HTTP/1.1" 200

Код 404 на перших двох рядках — це нормально, файли захищені відсутністю. А от 200 на xmlrpc.php і wp-login.php означає, що ці точки входу доступні і по них можна перебирати паролі — саме їх потрібно закривати в першу чергу.

Захист WordPress

• Встановіть плагін Wordfence або Sucuri
• Змініть стандартну URL-адресу входу /wp-admin
• Обмежте кількість спроб входу
• Вимкніть XML-RPC якщо не використовуєте

Wordfence і Sucuri: чим відрізняються

Wordfence працює всередині самого WordPress і не зупинить атаку до того, як запит дійде до PHP; повноцінний WAF перед сервером, наприклад ModSecurity або Cloudflare, фільтрує трафік раніше.

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

Захист файлів

# Заборонити доступ до .htaccess
<Files .htaccess>
    Order allow,deny
    Deny from all
</Files>

Якщо підозрюєте, що сайт вже заражений, перший практичний крок — знайти файли, змінені за останні дні, коли зазвичай ніхто не вносив правок у код:

# Файли, змінені за останні 7 днів
find /var/www/site -type f -mtime -7 -name "*.php"

# Підозрілі конструкції в PHP-файлах (не вирок, але привід перевірити руками)
grep -rl "eval(base64_decode" /var/www/site --include="*.php"

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

Коли самих плагінів недостатньо

• Вразливість нульового дня в самій CMS — плагін безпеки виявить підозрілу активність постфактум, але не закриє дірку, для якої ще немає сигнатури.
• Скомпрометований пароль адміністратора — двофакторна автентифікація і складні паролі важливіші за будь-який сканер файлів.
• Вразливий код у саморобній частині сайту — антивірусні плагіни шукають відомі сигнатури шкідливого коду, а не логічні помилки у вашому власному PHP.

Перевірка, що захист працює

1. Запросіть curl -I https://ваш-домен/wp-config.php.bak — має повернутися 404, а не 200.
2. Перевірте, що /wp-admin дійсно перенаправляє на нову адресу входу, а не відповідає старою формою.
3. Спробуйте 5–6 разів ввести неправильний пароль поспіль — має спрацювати блокування за IP або затримка перед наступною спробою.
4. Запросіть curl -I https://ваш-домен/xmlrpc.php — якщо XML-RPC вимкнено, відповідь має бути 403 або 404, а не 200.

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