Сайт заражено вірусом: що робити

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

Ми регулярно лікуємо зламані сайти — переважно на WordPress, але принципи однакові для будь-якої CMS. У цій статті розберемо, за якими ознаками впізнати зараження, що власнику зробити в перші години, як виглядає нормальне лікування, як повернути довіру Google і, головне, як закрити діру, щоб історія не повторилася.

Звідки береться «вірус» на сайті

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

У наших проєктах найчастіші точки входу такі:

• Застарілі плагіни й теми. Розробник уже випустив виправлення, але сайт не оновлювали місяцями. Для ботів це відкриті двері.
• «Зламані» (nulled) платні теми й плагіни. Їх завантажують із сумнівних сайтів, щоб не платити за ліцензію. Дуже часто бекдор уже вшитий у такий архів.
• Слабкі або повторні паролі до адмінки, хостингу, FTP. Пароль, який уже витік з іншого сервісу, перевіряють першим.
• Заражений комп’ютер когось із команди. Шкідлива програма краде збережені паролі FTP чи панелі хостингу, і зловмисник заходить «легально».
• Забуті копії сайту. Папки на кшталт /old/, /test/, тестові піддомени зі старою версією CMS, яку ніхто не оновлює.
• Сусіди на хостингу. На дешевому віртуальному хостингу з погано налаштованими правами зараження може перейти з одного сайту на інший в межах одного акаунта.

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

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

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

Ознаки, що сайт заражено

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

Що ви помічаєте	Що це може означати	Де перевірити
Перекидає на сторонні сайти, але не завжди	Умовний редирект: лише для мобільних, лише з пошуку чи лише при першому візиті	Смартфон через мобільний інтернет, перехід із Google, вікно інкогніто
Червоний екран попередження в браузері	Сайт потрапив у списки Google Safe Browsing	Search Console, розділ «Проблеми безпеки»
Позначка «Цей сайт, можливо, зламано» у пошуку	Google знайшов спамні сторінки або підмінений вміст	Пошук site:вашдомен, Search Console
В індексі тисячі сторінок про ліки, казино, репліки	Спам-ін’єкція: сторінки генеруються скриптом	Звіт «Сторінки» в Search Console, пошук site:
Хостинг заблокував акаунт або пише про розсилку	Сайт розсилає спам або атакує інші сервери	Листи хостингу, поштові логи, навантаження на сервер
Нові адміністратори, яких ніхто не створював	Зловмисник закріпився в адмінці	Список користувачів CMS

Інші тривожні сигнали: незнайомі PHP-файли в папці завантажень, різке зростання навантаження на сервер без зростання відвідуваності, листи з корпоративної пошти, які раптом почали потрапляти в спам, дивні скрипти на сторінці оформлення замовлення, раптове падіння органічного трафіку. Окремо перевірте сайт саме на смартфоні: мобільна версія — це те, як вас оцінює Google, і саме там найчастіше «живуть» приховані редиректи. Про важливість мобільної версії ми докладно писали в статті «Як досягти успіху в mobile-first index».

Одна ознака ще нічого не доводить: редирект може бути налаштуванням рекламного скрипта, а навантаження — наслідком атаки ботів, а не зараження. Але якщо збігаються дві-три з таблиці, діяти треба одразу.

Перші години: що робити власнику

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

1. Зафіксуйте, що бачите. Скриншоти, адреси, час, звідки заходили, з якого пристрою. Це допоможе знайти шкідливий код і зрозуміти, коли почалося зараження.
2. Не видаляйте все підряд і не відновлюйте бекап навмання. Поспішне видалення знищує сліди, за якими можна знайти точку входу. А бекап може бути зараженим так само, як живий сайт.
3. Зробіть повну копію поточного стану — файли й базу даних. Так, заражену. Вона потрібна для аналізу, і її не можна використовувати для відновлення.
4. Змініть паролі з чистого пристрою: панель хостингу, FTP/SFTP, база даних, адміністратори CMS, пошта, до якої прив’язаний домен. Якщо є сумнів щодо робочого комп’ютера — використайте інший.
5. Обмежте шкоду. Якщо сайт перекидає людей на шахрайські ресурси або краде платіжні дані, краще тимчасово закрити його сторінкою обслуговування, ніж тримати відкритим.
6. Повідомте хостинг. Хороший хостинг має логи доступу, може підказати, що відбувалося, і перевірити сусідні сайти в акаунті.
7. Для магазину — повідомте платіжного провайдера, якщо є підозра, що зачеплено сторінку оплати. Це не формальність: так ви захищаєте покупців і себе.

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

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

Як лікують сайт: покроково

Нормальне лікування — це не запуск одного сканера. Це послідовність кроків, де кожен закриває свою частину проблеми.

Крок 1. Діагностика

Спершу ми порівнюємо файли сайту з оригінальними: ядро CMS, плагіни й теми можна звірити з офіційними версіями тих самих номерів. Усе, що відрізняється або не повинно там бути, — під підозрою. Далі шукаємо нещодавно змінені файли, PHP-скрипти в папках, де їх не має бути (наприклад, у завантаженнях), і типові ознаки замаскованого коду — довгі закодовані рядки, виклики на кшталт eval(base64_decode(...)), підключення файлів з дивними назвами.

Окремо перевіряємо базу даних. У WordPress шкідливий код часто сидить у таблиці налаштувань, у тексті записів і віджетів, у запланованих завданнях, а також ховається за прихованими користувачами з правами адміністратора. Переглядаємо .htaccess, конфігураційні файли, завдання cron на сервері. І обов’язково — логи доступу, щоб знайти, через який файл або яку форму зайшов зловмисник.

Крок 2. Очищення

• Ядро CMS, плагіни й теми замінюємо чистими копіями з офіційних джерел, а не «вирізаємо» з них підозрілі рядки.
• Неліцензійні теми й плагіни видаляємо повністю і замінюємо легальними або аналогами.
• Плагіни, які давно не оновлюються розробником, прибираємо.
• Шукаємо й видаляємо бекдори — вони майже завжди є, навіть якщо видимий симптом був один.
• Очищаємо базу: шкідливі скрипти в контенті, сміттєві записи, чужих користувачів.
• Видаляємо згенеровані спамні сторінки й файли.

Крок 3. Закриття вразливості

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

Крок 4. Заміна всіх ключів

Паролі ви вже змінили, але цього мало. Ми оновлюємо секретні ключі CMS (у WordPress це salts у wp-config.php), щоб розлогінити всі старі сесії, і перевипускаємо ключі API: платіжних систем, поштових сервісів, CRM. Якщо зловмисник бачив конфігурацію, він бачив і їх.

Крок 5. Повторна перевірка

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

Іноді постає питання: лікувати чи відновлювати з бекапу? Порівняння варіантів:

Варіант	Коли підходить	Ризики
Відновлення з бекапу	Точно відомо, коли почалося зараження, і є чиста копія, старша за цю дату	Втрата нових замовлень і контенту; без закриття вразливості сайт зламають знову
Ручне лікування	Сайт живий, зміни свіжі, бекапу немає або він сумнівний	Вимагає досвіду: пропущений бекдор означає повторне зараження
Перенесення на чисту установку	Зараження глибоке, сайт старий, плагінів багато і половина не підтримується	Довше за часом, потрібна перевірка всього контенту, що переноситься

Після лікування: Google, пошта і позиції

Чистий сайт ще не означає, що відвідувачі й пошукова система вже про це знають. Цей етап часто пропускають, а потім дивуються, чому трафік не повертається.

• Search Console. Якщо в розділі «Проблеми безпеки» є повідомлення, після очищення надсилаємо запит на перевірку з коротким описом зробленого. Червоний екран у браузері знімається після того, як Google підтвердить, що сайт чистий.
• Спамні сторінки. Згенеровані адреси мають віддавати код 404 або 410. Перенаправляти їх на головну не варто: для Google це виглядає як підміна. Для пришвидшення можна тимчасово приховати їх через інструмент видалення URL.
• Технічна гігієна. Перевіряємо карту сайту, robots.txt, canonical і hreflang — зловмисники іноді змінюють і їх. Що з цього має бути в порядку на здоровому сайті, ми описували в матеріалі «Внутрішня SEO-оптимізація сайту».
• Пошта. Якщо сайт розсилав спам, перевіряємо, чи не потрапили IP сервера і домен до чорних списків, і налаштовуємо SPF, DKIM та DMARC.
• Аналітика. Порівнюємо трафік і конверсії до і після, щоб побачити реальний масштаб втрат.

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

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

Як не допустити повторення

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

• Регулярні оновлення ядра, плагінів і тем — з тестуванням на копії сайту, а не «натиснути все одразу в п’ятницю ввечері».
• Мінімум плагінів. Кожен зайвий плагін — це і вразливість, і навантаження. Чистка зайвого заодно пришвидшує сайт; цим ми займаємося в межах послуги оптимізації сайту.
• Тільки ліцензійні теми й плагіни з офіційних джерел.
• Двофакторна автентифікація для всіх адміністраторів і для панелі хостингу.
• Унікальні паролі в менеджері паролів, окремий акаунт для кожної людини і мінімальні права: копірайтеру не потрібна роль адміністратора.
• SFTP замість FTP і заборона редагування файлів з адмінки (у WordPress — DISALLOW_FILE_EDIT).
• WAF — фаєрвол вебзастосунків на рівні хостингу, CDN або плагіна, який відсікає типові атаки до того, як вони дійдуть до сайту.
• Бекапи поза сервером з історією за кілька тижнів і регулярною перевіркою, що з них справді можна відновитися.
• Моніторинг: контроль змін файлів, перевірка доступності, повідомлення Search Console на пошту, яку хтось читає.

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

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

Типова ситуація з практики

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

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

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

Помилки, які затягують лікування

1. Відновити бекап і вважати проблему вирішеною. Без закриття вразливості це лише відстрочка.
2. Видалити видимий шкідливий файл і зупинитися. Бекдори зазвичай розкладені в кількох місцях.
3. Змінити пароль лише до адмінки. Хостинг, FTP, база, пошта та ключі API залишаються в зловмисника.
4. Перевіряти сайт лише з робочого комп’ютера. Умовні редиректи власнику не показуються.
5. Не надіслати запит на перевірку в Google. Сайт чистий, а попередження висить тижнями.
6. Повернутися до старих звичок: nulled-тема, спільний пароль на всю команду, оновлення «колись потім».

Короткий чекліст

• Зафіксувати симптоми і зробити копію зараженого стану.
• Змінити всі паролі з чистого пристрою, повідомити хостинг.
• Знайти точку входу, замінити ядро й плагіни чистими копіями, почистити базу.
• Видалити бекдори, чужих користувачів, забуті копії сайту.
• Оновити все, перевипустити ключі CMS і API.
• Надіслати запит на перевірку в Search Console, прибрати спамні сторінки з індексу.
• Налаштувати оновлення, 2FA, WAF, зовнішні бекапи й моніторинг.

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

Чи можна просто відновити сайт з бекапу?

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

Скільки часу займає лікування?

Невеликий сайт з одним типом зараження зазвичай вдається вилікувати за день-два. Глибоко заражений магазин зі старими плагінами може потребувати кількох днів роботи й подальшого спостереження. Зняття попередження Google займає ще деякий час після запиту на перевірку.

Чи допоможе плагін-антивірус?

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

Чи вплине зараження на позиції в Google?

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

Підсумок

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

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