Безпека сайту 2026: HTTPS, 2FA, WAF, бекапи 3-2-1 — повний гайд

Як захистити сайт від хакерів: 7 робочих кроків

На нашу думку, можна сміло сказати що сайт без захисту у 2026 році живе рівно до моменту, поки його не знайде перший автоматичний сканер. А знаходять усіх — тому що боти ходять по всьому інтернету і шукають дві речі: відкриті адмінки і застарілі CMS. Великі портали з командою інженерів і малий блог на WordPress для них однакова мішень, бо атака масова і неперсоналізована.

Парадокс у тому, що 90% реальних інцидентів — це не складні таргетовані атаки, а елементарні речі: слабкий пароль адміна, плагін який не оновлювали півтора року, або відкритий 22-й порт з root-логіном. Хакери не «зламують» сайт — вони заходять у нього через те, що власник сам залишив відкритим.

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

Що насправді втрачає бізнес після зламу

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

1. Випадання з пошуку Google

Якщо Google Safe Browsing виявляє на сайті шкідливий код, ресурс отримує позначку «Цей сайт може зашкодити вашому комп'ютеру» у видачі, тоді користувачі бачать червоний екран замість контенту. На повернення в індекс після очищення йде від кількох днів до кількох тижнів — і весь цей час органічний трафік фактично нульовий.

2. Блокування на рівні браузерів

Chrome, Safari та Firefox синхронізуються зі списками шкідливих сайтів. Тобто навіть якщо людина має пряме посилання, браузер просто не пустить її без додаткового кліку «Все одно перейти». Конверсія такого «трафіку» близька до нуля.

3. Юридичні наслідки

Витік персональних даних (емейли, телефони, історія замовлень) — це сфера дії GDPR у Європі або відповідного закону про захист персональних даних у конкретній юрисдикції. Штрафи рахуються від обороту компанії, і повідомити постраждалих клієнтів зобов'язує закон — а це окрема репутаційна криза.

4. Майнінг та спам-розсилка від вашого імені

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

Крок 1. HTTPS + HSTS — базовий мінімум

HTTPS у 2026 — це навіть не питання безпеки, а технічна гігієна. Без нього сучасні браузери показують попередження, форми входу позначаються як небезпечні, а Google понижує сайт у видачі. Будь-який Wi-Fi у кав'ярні — це потенційна точка перехоплення трафіку, якщо сайт ходить через чистий HTTP.

Який сертифікат обрати

HSTS — другий шар над HTTPS

Сам по собі HTTPS не врятує від атаки типу downgrade, коли зловмисник примушує браузер відкрити сайт по HTTP при першому з'єднанні. Заголовок HSTS говорить браузеру: «з цим доменом ходи лише по HTTPS, без винятків».

Для Nginx додається одним рядком у server-блок:

add_header Strict-Transport-Security "max-age=31536000; includeSubDomains; preload" always;

Крок 2. Оновлення CMS, плагінів і бібліотек

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

Що робити з ядром CMS

• Увімкнути автоматичні мінорні оновлення — це security-патчі, вони не ламають сумісність.
• Мажорні оновлення (5.x → 6.x) ставити вручну після тесту на staging-копії сайту.
• Підписатися на security-розсилку розробника CMS — критичні дірки часто закривають екстренними патчами.

Що робити з плагінами і темами

• Раз на місяць проводити аудит: видалити все, чим не користуєтесь. Чим менше коду — тим менша поверхня атаки.
• Перевіряти дату останнього оновлення плагіна. Якщо розробник не випускав фіксів понад 12 місяців — це червоний прапор, плагін фактично кинутий.
• Ніколи не ставити «нулені» (nulled) платні теми з торентів. У 99% випадків там вшитий бекдор, який буде працювати тихо, поки сайт не використають у спам-розсилці.

Правило перед оновленнями

Перед будь-яким мажорним оновленням — бекап. Перед оновленням крупного e-commerce плагіна (WooCommerce, Magento модулі) — бекап і staging-тест. Бекап, який зробили «вже після», нічим не допоможе.

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

Більшість серйозних зламів адмінок — це не «хакерство», а банальний brute-force або credential stuffing (підстановка паролів, які витекли в інших місцях). Боти намагаються зайти 24/7, і якщо пароль admin / 123456 / qwerty — справа кількох хвилин.

Що таке нормальний пароль у 2026

• Довжина — від 16 символів. Складність важлива менше, ніж довжина: correct horse battery staple зламати важче, ніж P@ss1!
• Унікальний для кожного сервісу. Якщо пароль один на 10 акаунтів — після першого витоку всі 10 в зоні ризику.
• Створюється генератором, а не вигадується вручну. Випадкові 20–30 символів неможливо запам'ятати — і не треба, для цього є менеджери.
• Не зберігається у текстовому файлі, у браузері без майстер-пароля, або у месенджері. Тільки у спеціалізованому менеджері: Bitwarden, 1Password, KeePassXC (у них же є вбудований генератор).

2FA — те, що зупиняє 99% автоматичних атак

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

Крок 4. Захист на рівні сервера

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

Базовий стек серверного захисту

1. Web Application Firewall (WAF)

WAF аналізує HTTP-трафік перед тим, як він дійде до сайту, і блокує типові патерни атак: SQL-ін'єкції, XSS, спроби path traversal, експлойти на конкретні CVE. На рівні сервера це може бути ModSecurity з правилами OWASP CRS, на CMS-рівні — Wordfence або Sucuri.

2. Захист від DDoS

Volumetric-атаки (потужні потоки сміттєвого трафіку) у 2026 році вимірюються в десятках і сотнях Гбіт/с. Самостійно з одного сервера від них не захиститися — потрібна інфраструктура з фільтрами на рівні дата-центру. Application-layer атаки (повільні запити, які виглядають як легітимні) ловляться вже на рівні WAF.

3. Ізоляція проєктів

На якісному VPS-хостингу кожен клієнт сидить у власному KVM-контейнері з виділеними ресурсами — атака на сусіда не може торкнутися вашого сервера фізично, бо ізоляція забезпечена на рівні гіпервізора. У вашому розпорядженні власне ядро ОС, власний firewall, власні логи — нічого з цього не «протікає» між клієнтами. Якщо в когось на тому ж залізі зламали проєкт, ваш стоїть осторонь.

4. Fail2ban проти brute-force

Утиліта, яка моніторить логи (auth.log, nginx access.log) і автоматично банить IP-адреси після N невдалих спроб. Базовий конфіг для SSH:

[sshd]
enabled = true
port = 22
filter = sshd
logpath = /var/log/auth.log
maxretry = 3
findtime = 600
bantime = 3600

3 невдалі спроби за 10 хвилин — бан на годину. Для адмінок CMS пишеться окремий фільтр під /wp-login.php або /administrator.

💡 Простий додатковий трюк: змініть дефолтний SSH-порт з 22 на щось нестандартне (наприклад, з діапазону 49152+). Це не зупинить таргетовану атаку — якщо за ваш сервер взялися персонально, сканер портів все одно знайде новий. Але переважна більшість автоматичного brute-force б'є лише в 22-й порт, тому така зміна одразу відсікає основну масу шуму в логах.

5. Обмеження доступу до адмінки за IP

Якщо ви заходите в адмінку з кількох постійних локацій (офіс, дім, VPN), має сенс закрити її повністю на nginx-рівні:

    location /wp-admin {
    allow 198.51.100.42;   # офіс
    allow 203.0.113.0/24;  # робочий VPN
    deny all;
}

6. Security Headers

add_header X-Frame-Options "SAMEORIGIN" always;
add_header X-Content-Type-Options "nosniff" always;
add_header Referrer-Policy "strict-origin-when-cross-origin" always;
add_header Content-Security-Policy "default-src 'self'; img-src 'self' https:; script-src 'self'" always;

CSP — найскладніший з них, його треба налаштовувати під конкретний сайт, інакше зламає аналітику і зовнішні скрипти. Перевірити свій рівень захисту можна на securityheaders.com.

Крок 5. Регулярне сканування на шкідливий код

Навіть з ідеальним налаштуванням сайт може отримати малварь через інший вектор: вірус на робочому комп'ютері адміна вкрав FTP-доступи, або один з розробників випадково закомітив у репозиторій ключі від продакшна. Тому правило «довіряй, але перевіряй» — це не банальність, а робочий принцип.

Що сканувати і чим

• Файлова система: ClamAV, maldet (Linux Malware Detect), Imunify360. Запускати по cron мінімум раз на добу для активних проєктів.
• Цілісність системних файлів CMS: Wordfence для WordPress порівнює файли з еталонними з офіційного репозиторію — будь-яка зміна викликає алерт.
• Зовнішнє сканування: Sucuri SiteCheck, VirusTotal — перевіряють сайт з точки зору відвідувача, ловлять редиректи на фішинг і впроваджений JS.
• База даних: у WordPress зловмисники часто додають фейкових адмінів або вставляють спам у wp_options. Раз на місяць варто переглядати таблицю users і подивитися на post_content на наявність дивних <script>.

Що робити, коли знайшли

Крок 6. Принцип мінімальних привілеїв

Власники сайтів часто роздають доступи з логікою «нехай має все, раптом знадобиться». Це найгірший підхід з точки зору безпеки. Чим більше людей мають Admin-права — тим більше векторів атаки на ці акаунти, і тим важче розслідувати інцидент.

Розподіл ролей у CMS

• Адміністратор — мінімум людей, ідеально 1-2. Доступ до плагінів, користувачів, налаштувань.
• Редактор — для контент-менеджерів. Може публікувати все, але не лізе в плагіни.
• Автор — для зовнішніх копірайтерів. Публікує лише свої матеріали.
• SEO / аналітика — окрема роль через плагін типу User Role Editor, доступ лише до релевантних розділів.

Доступи для розробників і підрядників

• Окремий SSH-ключ для кожного розробника. Root-доступу не давати взагалі — для конкретних команд писати правила в sudoers.
• SSH тільки за ключами, парольна автентифікація вимкнена (PasswordAuthentication no у sshd_config).
• Доступи фрілансерам — створюйте одразу з обмеженим терміном дії (наприклад, через chage -E у Linux). Тоді не доведеться пам'ятати про видалення після завершення проєкту — акаунт експайриться сам.
• Для тимчасових задач — sudo з логуванням замість прямого root.

Крок 7. Бекапи за правилом 3-2-1

Це останній рубіж оборони. Якщо ransomware зашифрував файли, або розробник через помилку дропнув продакшн-базу — без бекапа втрата може бути повною і незворотною. Правило 3-2-1 — це індустріальний стандарт, який сформулювали ще до епохи хмар, і він досі актуальний.

Що означає «3-2-1»

• 3 копії даних — оригінал + дві резервні. Не одна, не «треба буде колись».
• 2 різних типи носіїв або систем — наприклад, бекап на тому ж сервері + бекап у віддаленому сховищі. Якщо обидві копії на одному диску — це не дві копії.
• 1 копія повністю відокремлена — у хмарі, на іншому континенті, офлайн. Якщо ransomware дотягнеться до сервера і знищить локальні бекапи, ця копія — те, що врятує бізнес.

Як часто робити бекапи

Топ-5 помилок, які роблять майже всі

1. «Мій сайт занадто маленький, кому я потрібен». Боти не вибирають жертв за розміром бізнесу. Вони сканують /16 і /24 підмережі підряд, шукаючи відомі дірки. Маленький сайт цікавий тим, що його ніхто не охороняє.
2. Один пароль на хостинг, домен і пошту. Якщо пароль витече з будь-якого з трьох — зловмисник отримує контроль над усім. Включно з можливістю перевести домен на інший реєстратор.
3. «Бекап є у хостера, нащо мені свій». Бекапи на тому самому сервері, де живе сайт, — це не бекапи, а ілюзія. У разі компрометації сервера або ransomware вони підуть разом із продакшеном.
4. Доступ до адмінки з громадського Wi-Fi без VPN. Навіть з HTTPS є вектори, які працюють на рівні DNS і ARP-спуфінгу. Або VPN, або не логіньтеся на критичні сервіси з кав'ярні.
5. Ігнорування логів. У access.log і auth.log часто можна побачити атаку за день-два до того, як вона спрацює. Але туди ніхто не дивиться, поки сайт не впав. Базовий моніторинг (Fail2ban + сповіщення в Telegram або на пошту) — це година налаштування і місяці спокою.

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