Сайт зламали: порядок дій, поки не пізно

Коротка відповідь

1. Не видаляйте нічого. Спершу зробіть повну копію файлів і бази - вона знадобиться, щоб зрозуміти, як зайшли.
2. Закрийте доступи: паролі панелі, FTP/SFTP, бази даних, адмінки CMS, ключі API. Скиньте активні сесії.
3. Знайдіть, що змінилось: свіжі за датою файли, чужі адмін-акаунти, невідомі cron-завдання, записи в логах.
4. Відкотіться на бекап, зроблений до зламу, - але тільки після того, як знайшли діру, інакше зламають ще раз.
5. Оновіть CMS, теми й плагіни, перевірте версію PHP.
6. Приберіть наслідки: попередження в Search Console, спам-сторінки з індексу, репутацію пошти.

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

Крок 0. Переконайтесь, що це справді злам

Половина звернень «нас зламали» насправді не злам. Перед тим як панікувати, звірте симптом із таблицею.

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

Крок 1. Зняти копію «як є» - до будь-яких видалень

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

Мінімум, який треба зберегти:

• архів усієї теки сайту разом із прихованими файлами (.htaccess, .user.ini - шкідливий код любить саме їх);
• дамп бази даних;
• логи доступу й помилок за останні кілька тижнів - у DirectAdmin вони лежать у теці logs/ домену;
• список cron-завдань і поштових акаунтів.

У DirectAdmin це робиться без консолі: Extra Features → Create/Restore Backups для файлів і бази, System Info & Files → File Manager - щоб скачати теку logs/ (де що лежить у панелі - у статті про перші кроки в DirectAdmin). Якщо не впевнені, що саме зберігати, напишіть у Telegram підтримки до того, як почнете чистити: зняти копію - хвилина, а відновити стерті сліди неможливо.

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

Крок 2. Закрити двері

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

• Пароль панелі хостингу. Це головний ключ - через панель дістають усе інше.
• FTP і SFTP. Видаліть усі акаунти, яких не впізнаєте, решті змініть паролі. Найчастіша точка входу за моїм досвідом - не «хакер зламав сервер», а вірус на комп'ютері, який витягнув збережений пароль з FileZilla.
• Користувач бази даних. Новий пароль у панелі і одразу в wp-config.php або config.php, інакше сайт ляже.
• Адміністратори CMS. Змініть паролі, видаліть незнайомі акаунти, скиньте активні сесії - у WordPress це робить зміна ключів SALT у wp-config.php.
• Ключі й токени. Платіжні API, SMTP-пароль, ключі інтеграцій, токени ботів. Все, що лежало в конфігах, вважайте скомпрометованим.
• Пошта на домені. Зламану скриньку використовують для розсилки, і саме через неї домен потрапляє в чорні списки.

Паролі - різні для кожного сервісу, від 16 символів, у менеджері паролів. Один пароль на панель, пошту й адмінку означає, що злам одного = злам усього.

Крок 3. Знайти, що саме змінилось

За датою зміни файлів

Шкідливі файли майже завжди свіжіші за решту сайту. У File Manager відсортуйте теку за колонкою Modified - і одразу видно все, що з'явилось за останні дні. Особлива увага: тека завантажень (wp-content/uploads, image/catalog) - у ній не повинно бути жодного .php-файла, там тільки картинки й документи.

Якщо є SSH, той самий пошук одним рядком:

find ~/domains/вашдомен.com/public_html -name "*.php" -mtime -14 -ls

За вмістом

Класичні маркери в коді: eval(, base64_decode(, gzinflate(, довгий рядок без пробілів у кінці файла, @$_POST одразу після відкриваючого тега. Один такий рядок, дописаний у кінець functions.php, - і в зловмисника є повний доступ, навіть якщо ви змінили всі паролі.

У логах

У access.log знайдіть звернення до підозрілого файла - там буде IP, час і найголовніше: який запит стався перед появою цього файла. Зазвичай це і є точка входу: старий плагін, форма завантаження без перевірки типу, або POST на xmlrpc.php сотнями за хвилину.

Те, що забувають перевірити

• Cron-завдання - шкідник додає своє, і сайт «сам себе» перезаражає після чистки.
• .htaccess у кожній теці, а не тільки в корені.
• База даних: у WordPress - таблиця wp_options, поля з JavaScript, чужі адміни в wp_users, скрипти в кінці статей.
• Сусідні сайти. Якщо на одному акаунті хостингу висить п'ять сайтів, зараження одного майже завжди означає зараження решти - у них спільна тека користувача.

Крок 4. Відкат із бекапа - і чому це не завжди рішення

Відкат на копію тижневої давнини виглядає найшвидшим виходом, і часто ним і є. Але тримайте в голові три речі.

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

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

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

У Hosturm бекапи знімаються щодня автоматично, зберігаються поза сервером із сайтом і відновлюються за запитом у підтримку. Це страховка від «згорів диск» і від «сайт зламали», але не заміна оновленням: бекап рятує наслідки, а не причину. Що входить у кожен тариф - на сторінці тарифів.

Крок 5. Прибрати наслідки для пошуку і пошти

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

• Search Console → Проблеми з безпекою. Після чистки натисніть «Запит на перевірку». Розгляд зазвичай займає від кількох годин до кількох діб.
• Спам-сторінки з індексу. Вони мають віддавати 404 або 410. Найгірше - лишити редирект на головну: для пошуку це виглядає як спроба зберегти дорвей.
• Sitemap. Перегенеруйте - у ньому не має лишитись чужих адрес.
• Пошта. Перевірте домен і IP у чорних списках, почистіть чергу вихідних листів, перевипустіть SMTP-паролі. Якщо розсилка йшла з вашої скриньки, доведеться подавати заявку на видалення зі списків - це найдовше з усього.
• SPF і DKIM. Налаштовані записи не дають розсилати спам «від вашого імені» з чужих серверів і прискорюють повернення довіри.
• SSL. Перевірте, що сертифікат на місці і редирект на HTTPS працює - деталі в статті про SSL і HTTPS.

Через що ламають найчастіше

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

1. Стара CMS, тема або плагін. Уразливість публікують, за кілька днів по ній автоматично проходяться боти. Сайт, який не оновлювали рік, зламають не персонально - його знайде сканер.
2. «Нульовані» платні теми й плагіни. Безкоштовна копія преміум-теми з торента у 9 випадках з 10 містить закладку. Це не злам - це ви самі встановили доступ.
3. Слабкий або повторно використаний пароль. admin + пароль з бази витоків підбирається за секунди.
4. Вірус на комп'ютері власника. Витягує збережені паролі з FTP-клієнта і браузера. Сервер тут ні до чого.
5. Форма завантаження без перевірки. Дозволяє покласти .php замість картинки - і далі це вже повноцінна оболонка.

Стара версія PHP теж грає роль: сайт на PHP 7.4 не отримує оновлень безпеки з 2022 року. На наших серверах стандарт - Apache 2.4 з PHP 8.3 і OPcache, версію можна перемкнути в панелі під конкретну CMS.

Що зробити, щоб не повторилось

• Оновлення раз на місяць, у календарі. Ядро, теми, плагіни - і перевірка сайту після. П'ятнадцять хвилин раз на місяць дешевші за добу чистки.
• Двофакторна автентифікація на панель хостингу й на адмінку CMS - вимикає атаку підбором повністю.
• Окремий акаунт на кожен важливий сайт, а не десять проєктів в одній теці користувача. Тоді злам одного не тягне за собою решту. У тарифі «Старт» за 142 грн/міс - 1 сайт і 10 GB NVMe SSD; для кількох проєктів є плани на 5 і 10 сайтів.
• Права на файли 644 і теки 755. Права 777 - запрошення записати в теку що завгодно.
• Бекап поза сервером. Копія, що лежить поруч із сайтом, гине разом із ним.
• Прибрати те, що не використовується. Вимкнений плагін і забутий тестовий піддомен ламаються так само, як робочі.

Коротко: порядок дій

1. Зняти повну копію файлів, бази й логів - до чистки.
2. Змінити паролі: панель, FTP, база, адмінка, пошта, ключі API.
3. Знайти свіжі й чужі файли, перевірити cron, .htaccess і базу.
4. Оновити CMS та плагіни, закрити знайдену діру.
5. Відновитись із бекапа, зробленого до дати зламу.
6. Запит на перевірку в Search Console, спам-сторінки в 410, перевірка пошти.
7. Увімкнути 2FA і поставити оновлення в календар.

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