Як перевірити сайт на віруси й закрити дірки в захисті

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

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

Як зазвичай ламають сайти

Забудьте про хакера, який цілеспрямовано атакує саме вас. У 95% випадків усе прозаїчніше: боти безперервно обходять інтернет і перевіряють сайти на відомі вразливості. Знайшли застарілий плагін — залили шкідливий код. Далі сайт використовують не проти вас, а як ресурс: для розсилки спаму, редиректу відвідувачів на партнерські сторінки або прихованого майнінгу.

Три найчастіші двері, через які заходять:

• Застарілий плагін або тема. Найпоширеніший варіант у WordPress. Вразливість публікують, і за кілька годин боти вже перевіряють усі сайти світу.
• Вкрадений пароль. Часто не з вашого сайту, а з іншого сервісу, де ви використали той самий. Або з зараженого комп'ютера через FTP-клієнт, який зберігає паролі у відкритому вигляді.
• Відкритий службовий файл. Про це нижче окремо — це недооцінена й дуже дешева для зловмисника лазівка.

Крок 1. Просканувати код на шкідливі сигнатури

Відкрийте перевірку сайту на віруси й вставте адресу. Інструмент аналізує код головної сторінки на характерні ознаки зараження:

• eval(atob(...)) — виконання закодованого коду. У нормальному сайті такого не буває майже ніколи;
• приховані iframe нульового розміру — класичний спосіб підвантажити чужу сторінку непомітно;
• майнери криптовалюти, які вантажать процесор відвідувача;
• обфускований JavaScript зі змінними на кшталт _0x4f2a — код навмисно зроблений нечитабельним;
• редиректи на сторонні домени через window.location.

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

Крок 2. Перевірити, чи не лежать у відкритому доступі службові файли

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

Той самий інструмент перевіряє доступність типових адрес. Найнебезпечніші дві:

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

Тека .git/config — через неї можна відновити весь вихідний код сайту разом з історією змін. А в історії часто лежать паролі, які колись закомітили, а потім видалили — з робочої копії вони зникли, з історії ні.

Крім них перевіряються wp-config.php.bak, backup.zip, dump.sql, phpinfo.php і лістинг тек. Кожен із цих файлів — окрема історія про те, як «тимчасово поклав і забув».

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

Крок 3. Подивитись на заголовки безпеки

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

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

Крок 4. Перевірити SSL-сертифікат

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

Перевірка SSL показує емітента й кількість днів до завершення. Поставте нагадування за два тижні до дати — навіть автоматичне оновлення Let's Encrypt іноді ламається після зміни конфігурації сервера, і про це дізнаються вже від клієнтів.

Крок 5. Навести лад із паролями й доступами

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

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

Що робити, якщо зараження вже сталося

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

1. Змінити всі паролі. Хостинг, FTP, SSH, адмінка, база даних. Спершу це, бо зараження зазвичай починається саме зі вкраденого доступу.
2. Розгорнути чисту резервну копію — зроблену до дати зараження. Як налаштувати бекапи, щоб така копія завжди була, ми розбирали в статті про резервне копіювання.
3. Оновити CMS і всі розширення. Якщо цього не зробити, вас зламають тим самим способом наступного тижня.
4. Перевірити список користувачів адмінки й видалити чужі облікові записи.
5. Перевірити заплановані завдання (cron) — зловмисники залишають там скрипт, який відновлює зараження.
6. Надіслати сайт на перевірку в Google Search Console, якщо він потрапив під позначку небезпечного. Без цього попередження в браузері лишиться навіть після чистки.

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

Чек-лист: десять хвилин раз на місяць

1. Сканування на шкідливий код — сигнатури й службові файли.
2. Заголовки безпеки — принаймні HSTS і X-Frame-Options.
3. SSL — понад два тижні до завершення.
4. Список користувачів адмінки — жодного зайвого.
5. Оновлення CMS і плагінів — усе актуальне.

Це не забирає часу, зате знаходить проблему до того, як її знайде Google. Решта перевірок — швидкість, індексація, пошта — зібрані в нашому каталозі з 43 інструментів.

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