Захист сайту від вірусів і зламу: повний гайд 2026

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

Ця стаття буде корисною власникам сайтів, розробникам, адміністраторам, вебмайстрам і всім, хто відповідає за працездатність вебресурсу.

Зміст

• Як виглядають загрози у 2026 році
• Актуальні вектори зламу
• Що втрачає бізнес після зламу
• Базовий рівень: доступи та оновлення
• Периметр: WAF, CDN і захист від ботів
• Заголовки безпеки та cookie
• Захист сервера й хостингу
• Ланцюг постачання: плагіни, теми, залежності
• Резервні копії за правилом 3-2-1
• Моніторинг і раннє виявлення
• Як перевірити, чи заражений сайт
• Що робити, якщо сайт уже зламали
• Чекліст за рівнями
• Часті запитання

Як виглядають загрози у 2026 році

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

Друга зміна — мотивація. Класичне «дефейс заради розваги» майже зникло. Сучасний злам монетизують тихо:

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

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

Актуальні вектори зламу

Вразливості плагінів, тем і CMS

Це вектор номер один для сайтів на WordPress, Joomla, Drupal, OpenCart та інших популярних CMS. Небезпечні не тільки старі версії ядра: значна частина інцидентів припадає на розширення, які давно не оновлює автор, або на теми, куплені на маркетплейсах і потім ніколи не оновлені.

Що робити: увімкнути автоматичні оновлення безпеки, видалити все, чим не користуєтесь, і раз на квартал перевіряти дату останнього оновлення кожного плагіна.

Скомпрометовані облікові записи

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

Окремий сучасний ризик — крадіжка сесійних cookie шкідливим ПЗ або розширенням браузера. Такий токен дає доступ в обхід пароля й навіть двофакторної автентифікації, доки сесія жива.

Що робити: унікальні паролі з менеджера паролів, обов’язкова двофакторна автентифікація або паскі для всіх адміністраторів, обмежений час життя сесії й примусовий вихід усіх сесій після будь-якої підозри.

Атака через ланцюг постачання

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

Помилки конфігурації

Величезна частка інцидентів не потребує жодної вразливості в коді. Типові знахідки автоматичних сканерів:

• доступні ззовні файли .env, .git/, config.php.bak, дампи бази у корені сайту;
• відкриті у зовнішню мережу порти баз даних, Redis, Memcached без пароля;
• тестові й staging-копії сайту на піддоменах, доступні всім і роками не оновлювані;
• увімкнений лістинг директорій і доступний каталог із бекапами;
• debug-режим на продакшні, який показує шляхи, версії та фрагменти коду.

Ін’єкції та вразливості коду

SQL-ін’єкції, XSS та завантаження довільних файлів нікуди не поділися — вони просто перемістилися з ядра CMS у самописний код: кастомні форми, інтеграції, обробники REST-запитів, імпорт прайсів. Причина завжди одна — дані від користувача потрапляють у запит або у вивід без валідації та екранування.

API-ендпоїнти та автоматизація

REST API, вебхуки, XML-RPC, інтеграції з CRM і маркетплейсами — це повноцінні двері в систему, у яких часто немає ані ліміту запитів, ані нормальної автентифікації. Токени інтеграцій нерідко лежать у репозиторії або в незахищеному конфізі.

Атаки на доступність (DDoS L7)

Сучасний DDoS майже не «валить» канал — він імітує реальних користувачів і б’є по найважчих сторінках: пошук, фільтри каталогу, кошик. Сотні запитів на секунду до сторінки, яка виконує важкий SQL-запит, кладуть сайт швидше за терабіти трафіку.

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

Базовий рівень: доступи та оновлення

Це той мінімум, що закриває більшість масових автоматизованих атак. Якщо часу мало — робіть саме це.

1. HTTPS без винятків

Безкоштовні сертифікати з автоматичним продовженням через ACME давно є стандартом і доступні майже в кожній панелі керування хостингом. Важливий не лише сам сертифікат:

• увімкніть примусовий редирект з HTTP на HTTPS;
• додайте заголовок HSTS, щоб браузер узагалі не намагався ходити по HTTP;
• переконайтеся, що немає mixed content — картинок і скриптів, які досі підвантажуються по HTTP;
• налаштуйте автопродовження і сповіщення, щоб сертифікат не «протух» у вихідні.

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

2. Двофакторна автентифікація та паскі

Обов’язково для всіх адміністраторів, редакторів і для панелі хостингу, DNS-провайдера й реєстратора домену. Найкращий варіант — паскі або апаратний ключ, далі — застосунок-автентифікатор. SMS як другий фактор варто вважати останнім вибором: перевипуск SIM-карти давно є робочою схемою атаки.

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

3. Унікальні паролі та менеджер паролів

Довжина важливіша за екзотичні символи: 16+ символів, згенерованих випадково, унікальних для кожного сервісу. Не зберігайте паролі у браузері на робочій машині розробника й ніколи не передавайте їх у месенджерах — використовуйте спільне сховище менеджера паролів.

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

4. Принцип найменших привілеїв

• жодного облікового запису з логіном admin або administrator;
• контент-менеджеру — роль редактора, а не адміністратора;
• окремий обліковий запис для кожної людини, без спільних «командних» доступів;
• підрядникам — тимчасовий доступ, який ви відкликаєте одразу після завершення робіт;
• у бази даних сайту — окремий користувач БД лише з потрібними правами, без GRANT ALL на весь сервер.

5. Оновлення як процес, а не як подія

Увімкніть автоматичні оновлення безпеки для ядра CMS і для плагінів, у яких ви впевнені. Для критичних проєктів схема інша: staging-копія → оновлення → перевірка ключових сценаріїв → продакшн. Обов’язково робіть бекап перед оновленням — це має бути автоматична частина процесу, а не ваша дисципліна.

6. Закрийте адмінку від масового перебору

• ліміт спроб входу з блокуванням IP після кількох невдач;
• обмеження доступу до /wp-admin, /wp-login.php чи аналогів за IP або через базову HTTP-автентифікацію;
• вимкнення XML-RPC, якщо ви ним не користуєтесь;
• заборона перелічування користувачів через REST API та архіви авторів;
• вимкнення редагування файлів тем і плагінів прямо з панелі (DISALLOW_FILE_EDIT для WordPress) — це закриває улюблений шлях зловмисника до встановлення бекдора;
• однакова відповідь при неправильному логіні й неправильному паролі, щоб не підказувати існування облікового запису.

Периметр: WAF, CDN і захист від ботів

WAF (Web Application Firewall) фільтрує запити ще до того, як вони дійдуть до вашого коду. Це найшвидший спосіб закрити щойно оприлюднену вразливість, поки ви ще не встигли оновитись — так званий віртуальний патчинг.

Два рівні на вибір:

• Хмарний WAF/CDN — трафік іде через мережу провайдера, шкідливі запити відсікаються до вашого сервера. Плюс: захист від DDoS, кешування, приховування реального IP. Мінус: залежність від зовнішнього сервісу.
• WAF на рівні сервера — модуль на самому вебсервері з набором правил. Плюс: повний контроль. Мінус: споживає ресурси вашого сервера й не рятує від об’ємного DDoS.

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

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

Заголовки безпеки та cookie

Кілька рядків у конфігурації сервера прибирають цілий клас атак у браузері. Мінімальний набір:

• Strict-Transport-Security — примусовий HTTPS на рівні браузера;
• Content-Security-Policy — найпотужніший інструмент проти XSS і скімінгу: явно перелічує, звідки дозволено завантажувати скрипти. Впроваджуйте поступово, спершу в режимі report-only;
• X-Content-Type-Options: nosniff — забороняє браузеру «вгадувати» тип файлу;
• Referrer-Policy — не віддає повні URL із внутрішніх сторінок стороннім сайтам;
• Permissions-Policy — вимикає непотрібні API: камеру, мікрофон, геолокацію.

Для cookie сесій обов’язкові атрибути Secure, HttpOnly і SameSite. Для сторонніх скриптів, які ви все ж підключаєте, використовуйте Subresource Integrity — якщо файл на чужому сервері підмінять, браузер просто не виконає його.

Захист сервера й хостингу

Ізоляція сайтів

Класична проблема shared-хостингу: кілька сайтів під одним користувачем. Ламають найслабший — отримують усі. Правильна конфігурація: окремий системний користувач і окремий пул PHP-FPM для кожного сайту, окремий користувач бази даних, заборонений доступ до чужих директорій.

Права доступу до файлів

Стандарт — 755 для директорій і 644 для файлів, 600 для конфігураційних файлів із паролями. Права 777 не потрібні ніколи. Вебсервер не повинен мати права запису в директорію з кодом — лише в каталог завантажень і кешу. І в цьому каталозі має бути заборонено виконання PHP: саме так більшість бекдорів потрапляє на сайт через форму завантаження зображення.

Доступ до сервера

• SSH лише за ключами, автентифікацію за паролем вимкнути повністю;
• вхід під root заборонити, працювати через окремого користувача з sudo;
• FTP замінити на SFTP — звичайний FTP передає пароль у відкритому вигляді;
• фаєрвол за принципом «заборонено все, крім потрібного»: залишити 80, 443 і порт SSH;
• бази даних, кеш і черги — слухають лише localhost або приватну мережу;
• автоматичне блокування після серії невдалих спроб автентифікації.

Актуальні версії середовища

PHP-версії, що вийшли з підтримки, більше не отримують виправлень безпеки — навіть якщо сайт на них працює. Те саме стосується ОС, вебсервера й СУБД. Раз на квартал перевіряйте, чи не наближається дата закінчення підтримки того, на чому працює ваш проєкт.

Конфігурація PHP

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

Ланцюг постачання: плагіни, теми, залежності

Кожен встановлений плагін — це чужий код із повними правами на вашому сайті. Правила відбору:

• тільки офіційні репозиторії CMS і сайти розробників. «Нульовані» преміум-плагіни з торентів — це майже гарантований бекдор, і це найдешевший спосіб втратити сайт;
• перед встановленням дивіться дату останнього оновлення, сумісність із поточною версією CMS і те, як швидко автор реагує на повідомлення про баги;
• видаляйте, а не деактивуйте невикористовувані плагіни й теми: код деактивованого плагіна все одно лежить на сервері й може бути викликаний напряму;
• тримайте мінімум сторонніх скриптів на сайті. Кожен віджет чат-ботів, аналітики чи піксель — це право виконувати довільний JS на ваших сторінках, включно зі сторінкою оплати;
• для самописного коду — фіксуйте версії залежностей у lock-файлах і регулярно перевіряйте їх сканером вразливостей;
• секрети (API-ключі, паролі БД, токени) ніколи не потрапляють у репозиторій. Якщо ключ хоч раз опинився в комміті — вважайте його скомпрометованим і перевипускайте.

Резервні копії за правилом 3-2-1

Бекап не запобігає зламу, але саме він визначає, чи буде інцидент неприємністю на дві години, чи катастрофою на два тижні.

Правило 3-2-1: три копії даних, на двох різних носіях або майданчиках, одна з них — поза інфраструктурою сайту.

Що робить бекап справді робочим:

• Копія поза сервером. Бекап на тому ж сервері зашифрує або видалить той самий зловмисник, що дістався до системи;
• Незмінне (immutable) сховище або окремий обліковий запис із правами лише на запис — щоб скомпрометований сервер не міг стерти архіви;
• Достатня глибина зберігання. Зараження часто виявляють через тиждень-два. Якщо у вас лише три останні щоденні копії — усі три вже заражені. Тримайте щоденні за 2 тижні, щотижневі за 2-3 місяці;
• Файли й база разом, з узгодженою точкою в часі;
• Шифрування архівів, бо бекап містить усю вашу базу клієнтів;
• Перевірка відновлення. Раз на квартал розгортайте копію на тестовому майданчику. Бекап, який ніколи не відновлювали, — це не бекап, а припущення.

Моніторинг і раннє виявлення

Мета — дізнатися про проблему першим, а не від клієнта чи від попередження в браузері. Мінімальний набір:

• Контроль цілісності файлів — сповіщення про будь-яку зміну файлів ядра, тем і плагінів поза процесом оновлення. Це найнадійніший спосіб зловити бекдор;
• Моніторинг доступності й вмісту — не лише «сайт відповідає 200», а й перевірка, що на сторінці є очікуваний фрагмент і немає чужих скриптів;
• Аналіз логів — сплески 404 і 403 означають активне сканування; серія POST на файл, якого не має існувати, означає, що бекдор уже завантажили;
• Google Search Console — розділ проблем безпеки повідомить про виявлений шкідливий код і про ручні санкції. Bing Webmaster Tools дає схожі сповіщення;
• Сповіщення про нових користувачів з адміністративними правами й про зміну критичних налаштувань;
• Контроль DNS і домену — сповіщення про зміну NS-записів і про наближення дати продовження домену;
• Сповіщення у месенджер, а не на пошту, яку ніхто не читає у вихідні.

Як перевірити, чи заражений сайт

Типові ознаки, які помітні без спеціальних інструментів:

• у видачі пошуку під вашим доменом з’явилися чужі сторінки — фармацевтика, азартні ігри, репліки;
• сайт нормально відкривається у вас, але редиректить на сторонній ресурс з мобільного або при переході з пошуку;
• у панелі з’явився невідомий користувач з правами адміністратора;
• у корені або в каталозі завантажень лежать PHP-файли з випадковими назвами;
• сайт різко «поважчав» без причини, зросло навантаження на CPU;
• хостинг надіслав попередження про розсилання спаму;
• у коді сторінки з’явився незнайомий скрипт з чужого домену;
• у файлі .htaccess або в конфігурації сервера з’явилися нові правила редиректу.

Що перевірити вручну: дати зміни файлів (сортування за датою моментально показує все, що змінювали вчора), список адміністраторів, заплановані завдання cron, автозавантажувані записи в опціях бази, вміст каталогу завантажень на предмет виконуваних файлів. Порівняння файлів сайту з чистою копією тієї ж версії CMS дає найточніший результат.

Автоматизувати перевірку допоможуть сканери безпеки: плагіни рівня Wordfence, Sucuri Security чи Solid Security для WordPress уміють і сканувати файли, і стежити за цілісністю, і блокувати підозрілі запити. Але пам’ятайте: сканер знаходить відоме йому, а свіжий цільовий бекдор може не потрапити в сигнатури.

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

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

1. Зафіксуйте стан. Перш ніж щось чистити, зробіть повну копію файлів і бази «як є» та збережіть логи вебсервера. Це ваш єдиний матеріал для розслідування.
2. Ізолюйте. Увімкніть режим обслуговування або закрийте сайт для відвідувачів, щоб не заражати користувачів і не поглиблювати санкції.
3. Відкличте всі доступи. Змініть паролі адміністраторів, БД, SSH/SFTP, панелі хостингу, реєстратора домену. Перевипустіть API-ключі й токени інтеграцій. Для WordPress — оновіть ключі й солі автентифікації: це примусово завершить усі активні сесії.
4. Знайдіть точку входу. За логами знайдіть перший підозрілий запит і час першої зміни файлів. Без цього кроку прибирання марне.
5. Відновіть чистий код. Найнадійніше — перевстановити ядро CMS, теми й плагіни з офіційних джерел, а не «лікувати» файли. Кастомний код перевіряють вручну або відновлюють із системи контролю версій.
6. Перевірте базу даних. Шкідливий код часто живе в опціях, у контенті записів і у віджетах, а не тільки у файлах.
7. Приберіть закріплення. Зайві адміністратори, чужі завдання cron, підозрілі правила в конфігурації сервера, ключі SSH, яких ви не додавали.
8. Закрийте вразливість. Оновіть усе, видаліть плагін-джерело, виправте помилку конфігурації. Якщо цього не зробити, попередні сім кроків нічого не варті.
9. Поверніться у видачу. Після очищення надішліть запит на перевірку у Search Console і переконайтеся, що позначку про небезпеку знято.
10. Оцініть витік даних. Якщо є ознаки доступу до персональних даних клієнтів — повідомте користувачів. Це не лише юридична вимога, а й питання довіри.

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

Чекліст за рівнями

Мінімум (робиться за один вечір):

• HTTPS з автопродовженням і примусовим редиректом;
• двофакторна автентифікація для всіх адміністраторів, хостингу, DNS і реєстратора;
• унікальні паролі з менеджера паролів, жодного облікового запису admin;
• автоматичні оновлення безпеки CMS;
• видалені невикористовувані плагіни й теми;
• автоматичні бекапи поза сервером;
• ліміт спроб входу.

Стандарт (для комерційного сайту):

• WAF або хмарний захист із закритим прямим доступом до сервера;
• заголовки безпеки й правильні атрибути cookie;
• контроль цілісності файлів зі сповіщеннями;
• окремий системний користувач і пул PHP-FPM для кожного сайту;
• SSH за ключами, FTP вимкнено;
• staging-копія для тестування оновлень;
• бекапи 3-2-1 з перевіркою відновлення раз на квартал.

Підвищений рівень (магазини, персональні дані, платежі):

• Content-Security-Policy у бойовому режимі й SRI для сторонніх скриптів;
• централізовані логи з алертами на аномалії;
• сканування залежностей на вразливості в процесі складання;
• сегментація: окремі середовища для розробки, тесту й продакшну;
• регламент реагування на інцидент, записаний до того, як він стався;
• періодичне зовнішнє тестування на проникнення.

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

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

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

Чи захищає SSL-сертифікат від вірусів?

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

Чи можуть зламати невеликий сайт-візитівку, який нікому не цікавий?

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

Як часто оновлювати CMS і плагіни?

Оновлення безпеки — одразу, бажано автоматично. Функціональні — за графіком, через staging, раз на 2-4 тижні. Ключовий показник — не частота, а час від виходу патча до його встановлення.

Чи допоможе зміна адреси адмінки?

Частково. Це прибирає шум від масових ботів і знижує навантаження, але не є захистом: адресу можна визначити іншими способами. Використовуйте це як доповнення до двофакторної автентифікації й ліміту спроб входу, а не замість них.

Що робити з тестовими копіями сайту?

Закривати паролем на рівні сервера, забороняти індексацію й видаляти одразу після завершення робіт. Забутий staging-піддомен зі старою версією CMS — один із найпоширеніших шляхів у продакшн.

Підсумок

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

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