⚡ Стисла відповідь: Головна помилка — почистити видимі наслідки й заспокоїтись. За звітом Sucuri, 49,21% зламаних сайтів мали щонайменше один бекдор, а у 55,2% заражених баз даних знайшли доданих адміністраторів. Якщо не знайти точку входу й не прибрати бекдори, сайт заразять повторно за кілька днів. Порядок дій: зафіксувати стан, закрити доступи, знайти вхід, почистити, і лише потім знімати попередження Google.
Ця стаття — про те, що робити, коли вже сталось. Профілактику й вартість регулярного супроводу ми розбирали в матеріалі про технічну підтримку; тут — покрокова процедура на випадок, коли профілактика не спрацювала.
Порядок має значення, і найперший пункт суперечить інстинкту.
Не видаляйте нічого одразу. Перше бажання — стерти підозрілі файли й полегшено видихнути. Але видалені файли — це знищені докази: без них ви не дізнаєтесь, як саме зайшли, і не зможете закрити діру.
Зробіть повну копію зараженого сайту. Файли плюс база даних, окремо від звичайних бекапів. Це ваш матеріал для розслідування.
Змініть паролі — усі. Адмінка, хостинг, FTP/SSH, база даних, пошта, з якої йде відновлення пароля. Якщо зламали пошту, зміна пароля до сайту нічого не дасть.
Перевірте список користувачів. Це найшвидша перемога: у 55,2% заражених баз знаходять адміністраторів, яких туди ніхто не додавав.
Попередьте хостинг. Часто вони вже знають і можуть сказати, коли й звідки був вхід — у них є логи, яких у вас немає.
Не кожна дивна поведінка сайту — результат атаки. Але є симптоми, які майже однозначно вказують саме на неї.
| Симптом | Що це зазвичай означає |
|---|---|
| Попередження Google у видачі чи браузері | Виявлено шкідливий код або фішинг |
| У пошуку з’явились чужі сторінки з вашого домену | SEO-спам — найпоширеніший тип зараження |
| Сайт перекидає відвідувачів на чужий ресурс | Ін’єкція редиректу, часто тільки для мобільних |
| Нові адміністратори, яких ви не створювали | Бекдор через базу даних |
| Різко зросло навантаження на хостинг | Сайт використовують для розсилки чи майнінгу |
| Файли з датою зміни, коли ніхто не працював | Пряме втручання у файлову систему |
SEO-спам варто підкреслити окремо: за даними Sucuri, його знаходять на 42,22% заражених сайтів. Він найковарніший, бо власник може місяцями нічого не помічати — сторінки показуються тільки пошуковим роботам і відвідувачам з певних країн.
Перевірити просто: введіть у Google site: і ваш домен, і подивіться, чи немає в результатах сторінок, яких ви не створювали.
Це та частина, яку пропускають найчастіше — і саме через неї сайти заражають повторно.
Логіка проста: шкідливий код — це наслідок, а не причина. Якщо ви прибрали код, але лишили вразливий плагін, слабкий пароль чи відкритий доступ, через який зайшли, вас зламають знову тим самим шляхом.
Де шукати причину найчастіше:
Логи доступу за період до появи перших симптомів — головне джерело відповіді, і в Netloria розбір завжди починається саме з них, а не зі сканування файлів. Шукайте незвичні POST-запити, звернення до файлів, яких не має бути, і активність з IP, які не схожі на ваших відвідувачів.
Бекдор — це залишений зловмисником спосіб повернутись, навіть коли основну вразливість закрито. Масштаб проблеми видно з цифр: майже половина зламаних сайтів містила хоча б один, і лише за один рік фахівці Sucuri прибрали 21 062 бекдори.
Ховаються вони не там, де їх шукають новачки. Типові місця: файли в каталозі завантажень, куди взагалі не має потрапляти код; mu-plugins, які завантажуються автоматично й не видно у звичайному списку плагінів; змінений wp-config; заплановані завдання в базі, які відновлюють шкідливий код після кожної чистки; уставки в файлах теми.
Саме заплановані завдання пояснюють найчастіше запитання клієнтів: «ми все почистили, а через три дні знову те саме». Чистка прибрала наслідок, а планувальник спокійно перевстановив його вночі. Ми в Netloria на таких розборах завжди перевіряємо таблицю опцій і список cron-завдань — там ховається те, що не видно ні сканером файлів, ні оком у файловому менеджері.
Бекап — найшвидший шлях, але він має дві пастки.
Перша: копія може бути вже зараженою. Якщо зараження сталось три тижні тому, а ви відкочуєтесь на тиждень назад, ви відновлюєте сайт разом із бекдором. Тому спершу треба зрозуміти дату зараження — за логами й датами зміни файлів — і лише потім обирати копію.
Друга: відкат повертає й ту вразливість, через яку зайшли. Після відновлення обов’язково оновлюється все: ядро, плагіни, теми, паролі.
Якщо чистої копії немає, лишається довший шлях: перевстановити ядро CMS із офіційного джерела, перевстановити всі плагіни й теми заново (не оновити, а саме поставити чисті версії), і вручну почистити базу. Свої файли — завантаження, кастомний код — переносяться вибірково й з перевіркою.
Цю частину найчастіше хочеться пропустити, бо вона неприємна й не має технічного рішення.
Якщо сайт приймав замовлення, зберігав телефони, адреси доставки чи історію покупок — треба чесно оцінити, чи могли ці дані винести. Ознаки, які на це вказують: звернення до бази з незнайомого IP, великі вихідні обсяги трафіку в логах у нетипові години, архіви в каталозі, доступному ззовні, або знайдений скрипт, що вивантажує таблицю користувачів.
Далі починається неприємне: якщо витік підтверджено, про нього треба повідомити тих, чиї дані постраждали. Європейське законодавство дає на сповіщення регулятора 72 години з моменту виявлення, українське законодавство про захист персональних даних прямо такого строку не встановлює, але обов’язок захищати дані нікуди не дівається — і для бізнесу, який працює з ЄС, орієнтуватись треба саме на суворіший стандарт. З практичного боку важливіше інше: клієнти пробачають злам набагато охочіше, ніж мовчання про нього, і компанія, яка сама написала «у нас був інцидент, ось що ми зробили», втрачає репутаційно значно менше, ніж та, про чий витік люди дізнались із чужої розсилки спаму на свою адресу.
Окремо варто скинути всі сесії користувачів і примусово запросити зміну паролів, якщо на сайті були особисті кабінети. Навіть якщо база не витекла — довести це напевно вдається рідко.
Коли сайт почищено, треба ще прибрати позначку в пошуку й браузерах — сама вона не зникне.
Процедура така: у Search Console відкрити звіт «Проблеми безпеки», переконатись, що проблема більше не виявляється, і натиснути запит на перевірку. У запиті потрібно описати, що саме ви зробили для усунення — формальні відписки сповільнюють розгляд.
Дві деталі, на яких найчастіше спотикаються.
Сайт має бути доступний для сканування. Google прямо зазначає, що сторінки не повинні бути закриті в robots чи мати noindex — інакше перевірити чистоту неможливо. Класична помилка: сайт лишили в режимі обслуговування й подали запит, який гарантовано не пройде.
Строки. В офіційній документації сказано, що перевірка займає від кількох днів, а в довідці Search Console — що може розтягнутись до кількох тижнів. Цифри на кшталт «знімають за 24 години», які трапляються в статтях, походження не мають.
Також варто очистити кеш сайту й CDN перед запитом: якщо Google побачить закешовану заражену версію, перевірка провалиться.
Повернути сайт до роботи — не фінал. Без цієї частини історія повториться.
Окремо — перевірити позиції й трафік. Після SEO-спаму й попередження Google органіка зазвичай просідає, і відновлення займає тижні. Як відстежувати це коректно, ми описали в матеріалі про метрики сайту.
Кілька дій, які здаються логічними й роблять гірше.
noindex ще й б’є по позиціях сильніше, ніж саме зараження.У Netloria найчастіше ми стикаємось саме з першим і третім пунктом: сайт приходить уже після спроби самостійної чистки, з режимом обслуговування на два тижні й невиправленою базою. Розібратись після цього складніше, бо частина слідів затерта.
Самостійно реально впоратись, якщо сайт простий, є чистий бекап, а зараження свіже й очевидне.
Кликати фахівців варто, коли: сайт заражають повторно після чистки; ви не можете знайти точку входу; зламано магазин, де є дані клієнтів і платежі; зараження тривало довго й невідомо, що встигли винести; або коли сайт — основний канал продажів і кожна година простою коштує грошей.
Останній пункт найважливіший з практичного боку. Витратити два дні на самостійні спроби й у підсумку все одно звернутись — виходить дорожче, ніж звернутись одразу, бо до вартості чистки додається простій.
Орієнтири, зібрані з ринкових пропозицій: професійне очищення зазвичай вкладається в кілька сотень доларів для типового випадку й росте до півтори тисячі й вище, якщо зараження глибоке або сайт великий. Строк на типовому проєкті — від доби до двох, за умови, що є доступи й логи.
Головний множник ціни — не розмір сайту, а те, чи збереглись логи й бекапи. Розслідування без логів перетворюється на перебір, і саме він з’їдає години.
Виглядає це так. Коли логи є, робота починається з вузького запитання: що відбувалось на сайті за добу до першого підозрілого файлу — і відповідь зазвичай знаходиться за годину-дві, бо видно конкретний запит, конкретний файл і конкретний IP. Коли логів немає, доводиться йти з іншого боку: порівнювати всі файли з чистими версіями з офіційних репозиторіїв, перебирати таблиці бази вручну, шукати аномалії в датах — і цей шлях займає в рази більше часу при гіршому результаті, бо частину закладок можна просто не помітити. Тому найкорисніше, що можна зробити заздалегідь, — це навіть не бекапи, а увімкнені логи доступу з нормальним строком зберігання.
Порівняйте це з вартістю регулярного супроводу — і стане зрозуміло, чому профілактика майже завжди дешевша. Але це аргумент на майбутнє; коли сайт уже лежить, важливіше відновити його правильно, ніж шкодувати про непідключений моніторинг.
Якщо ваш сайт зараз у такій ситуації або ви хочете, щоб хтось перевірив його до того, як це станеться — напишіть нам. Ми почнемо з пошуку точки входу, а не з чистки видимого: без цього будь-яке відновлення тимчасове.
