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

Коротка відповідь: Ізолюйте сервер (блокування фаєрволом чи вимкнення з Клієнтського кабінету), оцініть ситуацію через KVM Console, збережіть докази, змініть усі облікові дані з чистого пристрою, а потім відбудуйте: перевстановіть ОС і відновіть дані з бекапу, зробленого до компрометації. Чистити систему з root-доступом атакувальника «на місці» майже ніколи не можна довіряти.

Огляд

Щойно атакувальник мав root, підозрілими є кожен бінарник, cron-завдання й обліковка на машині. Професійний план: стримати → розслідувати → відбудувати, саме в цьому порядку. Швидкість важлива подвійно: щоб обмежити шкоду вашим даним і щоб сервер не атакував інших — це також питання політики щодо зловживань.

Що потрібно мати

• Доступ до Клієнтського кабінету (керування живленням, KVM Console) з довіреного пристрою.
• Останній чистий бекап і його дату.
• Чисту машину для всієї роботи з відновлення — вважайте, що ваші звичні ключі/паролі могли викрасти.

Покрокова інструкція

1. Стримайте: заблокуйте весь вхідний/вихідний трафік, крім вашого адмін-IP, на фаєрволі або зупиніть сервер зі сторінки послуги, якщо він активно атакує інших.
2. Оцініть через KVM Console: шукайте невідомих користувачів (/etc/passwd), процеси (ps auxf), сокети (ss -tulpn), записи cron, SSH-ключі в authorized_keys і сліди входу в логах автентифікації та веб-логах.
3. Збережіть докази: скопіюйте відповідні логи з сервера перед очищенням, якщо потрібен розбір причин чи звіт.
4. Змініть облікові дані з чистого пристрою: пароль Клієнтського кабінету, SSH-ключі, секрети застосунків, ключі БД і API — все, що знала машина.
5. Відбудуйте: перевстановіть ОС, захистіть її (чеклист), закрийте вразливість-вхід, потім відновіть дані застосунків із докомпрометаційного бекапу — див. також інструкцію з фокусом на відновлення.
6. Перевірте перед запуском: оновлені пакети, відсутність відновлених веб-шелів (проскануйте відновлені дані — інструкція зі сканування), моніторинг на місці.

Типові проблеми

• Видалити шкідника й жити далі: персистентність живе у cron, systemd-юнітах, SSH-ключах і підмінених бінарниках — краще відбудуйте.
• Відновлення інфікованого бекапу: скануйте відновлений вміст і беріть бекап з дати до вторгнення.
• Не закрита точка входу: той самий вразливий плагін експлуатують повторно за лічені дні.

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

Повідомте підтримку Cloud2Y, якщо сервер розсилав abuse (спам, сканування, флуди), якщо ви отримали abuse-повідомлення або потрібна допомога з живленням/KVM під час стримування. Проактивна комунікація робить відновлення співпрацею, а не примусом.

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

Який найперший крок після виявлення зламу?

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

Можна просто видалити шкідливе ПЗ і працювати далі?

Це ризиковано — атакувальники з root лишають закладки в cron, systemd-юнітах, SSH-ключах і підмінених бінарниках. Єдиний надійний стан — чисте перевстановлення ОС плюс відновлені дані.

Чи мушу я повідомляти Cloud2Y про злам сервера?

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

Схожі статті

• Що робити, якщо сервер скомпрометовано
• Як перевірити сервер на шкідливе ПЗ
• Як читати логи автентифікації
• Політика щодо зловживань і заборонені дії

Потрібна допомога? Звернутися в підтримку Cloud2Y →