Як контролювати сайт протягом місяця після злому

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

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

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

Моніторинг доступності

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

• Перевіряйте головну сторінку та кілька важливих розділів, наприклад сторінку контакту, форму заявки або каталог.
• Контролюйте HTTP-коди відповіді: помилки 500, 502, 503, 504 можуть вказувати на проблеми сервера або перевантаження.
• Звертайте увагу на раптові редиректи, повідомлення про шкідливий сайт і зміну вмісту сторінок.
• Перевіряйте час відповіді. Різке уповільнення може бути наслідком шкідливого скрипта, прихованого майнера або масових запитів.

Одного сповіщення про недоступність недостатньо. Зафіксуйте час збою, URL, код відповіді та повідомлення моніторингу. Ці дані допоможуть порівняти інцидент із записами сервера й визначити, чи проблема пов’язана з атакою, хостингом або технічними змінами.

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

Контроль змін файлів

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

Особливу увагу приділіть:

• файлам у каталогах wp-content/uploads, wp-content/plugins і wp-content/themes;
• файлам wp-config.php, .htaccess та конфігураціям веб-сервера;
• новим PHP-файлам у папках завантажень, кешу або тимчасових каталогах;
• несподіваним змінам системних файлів WordPress;
• скриптам із незрозумілими назвами, обфускованим кодом або викликами eval, base64_decode та подібних конструкцій.

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

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

Перевірка нових користувачів

Перегляньте всі облікові записи WordPress, хостингу, FTP або SFTP, бази даних і пов’язаних поштових скриньок. Зламаний сайт може продовжувати контролюватися через користувача, якого створили під час атаки.

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

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

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

Search Console і чорні списки

Після злому регулярно перевіряйте Google Search Console та інші інструменти для вебмайстрів. Пошукова система може виявити шкідливий код або сторонні сторінки не одразу, а через кілька днів після їх появи.

• Переглядайте розділ із проблемами безпеки.
• Перевіряйте ручні заходи, індексацію нових сторінок і незвичні пошукові запити.
• Аналізуйте звіт про охоплення та сторінки, які раніше не створювалися власником сайту.
• Слідкуйте за попередженнями браузерів, антивірусів і поштових сервісів.

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

Перед поданням запиту на повторну перевірку потрібно переконатися, що причина усунена. Якщо просто надіслати запит на перегляд, не видаливши бекдор або не закривши вразливість, попередження може повернутися. Зберігайте копії повідомлень Search Console, результати сканувань і дати виконаних робіт.

План реагування

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

1. Зафіксувати симптом: час, URL, скриншот, текст помилки та дії, після яких вона з’явилася.
2. Обмежити доступ до адміністративної панелі, якщо є ознаки активної атаки.
3. Не видаляти файли та не перевстановлювати сайт до створення резервної копії й копій журналів, якщо це не потрібно для негайного блокування загрози.
4. Змінити скомпрометовані паролі з безпечного пристрою та відкликати зайві сесії й ключі.
5. Перевірити файли, користувачів, базу даних, завдання cron і журнали сервера.
6. Переконатися, що сайт доступний, форми працюють, а редиректи та вміст сторінок не змінилися.
7. Зафіксувати виконані дії та результати перевірки.

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

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