Сайт став повільним, хоча відвідувачів більше не було. Процесор завантажений навіть уночі, у поштовій черзі накопичуються невідомі листи, а провайдер повідомляє про підозрілі запити з IP-адреси сервера. Перша думка зазвичай проста: щось зламалося. Але проблема може бути серйознішою. Сервер іноді продовжує працювати цілком нормально на вигляд, поки стороння людина вже використовує його для розсилання спаму, атак на інші ресурси або доступу до даних.
Злам рідко вдається підтвердити за одним симптомом. Високе навантаження може створити резервне копіювання, помилка в коді чи наплив ботів. Незнайомий файл іноді додає оновлення. Підозра стає обґрунтованою, коли кілька нетипових змін з’являються одночасно й для них немає очевидного пояснення.
Які ознаки можуть вказувати на злам сервера
Насамперед варто порівняти поточну роботу системи з її звичайним станом. Адміністратор приблизно знає, скільки ресурсів споживає сайт, коли запускаються фонові завдання та який обсяг трафіку проходить через сервер. Різка зміна цього ритму потребує перевірки.
До основних ознак підозрілої активності належать:
- процесор, оперативна пам’ять або диск постійно навантажені без зрозумілої причини;
- з’явилися невідомі процеси, служби, користувачі чи завдання в планувальнику;
- у журналах є успішні входи з незнайомих IP-адрес або в незвичний час;
- файли сайту чи системні налаштування змінилися без участі адміністратора;
- сервер надсилає багато листів, створює сторонні з’єднання або генерує незвичний трафік;
- IP-адреса потрапила до спам-баз або надійшла скарга на атаки з вашого сервера.
Кожен із цих пунктів окремо ще не є доказом зламу. Але коли сервер одночасно починає споживати більше ресурсів, з’єднуватися з невідомими адресами й запускати незнайомий процес, пояснювати все звичайним збоєм уже не варто.
Навантаження зросло, хоча на сайті нічого не змінилося
Найпомітніший сигнал – сайт раптом починає гальмувати. Сторінки відкриваються довше, панель керування реагує із затримкою, а процесор тримається біля максимального навантаження. Іноді так працює прихований майнер. В інших випадках сервер перебирає паролі, сканує мережі або виконує команди зловмисника.
Спочатку потрібно подивитися, який саме процес споживає ресурси. Знайома назва також не гарантує безпеки: шкідливу програму можуть замаскувати під системну службу. Важливі шлях до файлу, користувач, від імені якого він запущений, час появи та мережеві підключення.
Звертати увагу потрібно й на диск. Велика кількість операцій запису іноді означає, що програма створює тимчасові файли, архівує викрадені дані або постійно відновлює видалений шкідливий код. Якщо навантаження виникло одразу після оновлення, імпорту чи запуску резервної копії, причина може бути цілком нормальною. В інших ситуаціях краще не відкладати перевірку.
У системі з’явилися невідомі входи
Журнали авторизації часто дають більше інформації, ніж загальний графік навантаження. Підозрілими є успішні входи з адрес, якими адміністратори не користуються, підключення посеред ночі або авторизація після сотень невдалих спроб.
Після отримання доступу зловмисник не обов’язково продовжує входити через викрадений пароль. На Linux він може додати власний SSH-ключ, створити нового користувача чи надати йому право виконувати команди адміністратора. На Windows Server варто перевірити склад групи адміністраторів, входи через віддалений робочий стіл, нові служби та зміни політик безпеки.
Через це звичайна зміна пароля не завжди розв’язує проблему. Якщо в системі залишився сторонній обліковий запис, ключ або прихований сервіс, доступ швидко відновлять.
Файли змінилися без вашої участі
Після зламу сайту шкідливий код часто ховається серед звичайних файлів CMS. Він може мати непримітну назву, лежати в каталозі завантажень або маскуватися під частину плагіна. Візуально сайт при цьому працює як раніше.
Наслідки помічають пізніше. Відвідувачів перенаправляє на сторонні сторінки, у пошуку з’являються чужі матеріали, браузер попереджає про небезпечний ресурс. Іноді шкідливий код спрацьовує лише для користувачів із певних країн або мобільних пристроїв, тому власник сайту нічого не бачить зі свого комп’ютера.
Перевіряти варто файли, які не мали змінюватися останнім часом, а також каталоги з правом запису. Якщо підозрілий файл після видалення з’являється знову, десь залишився процес, заплановане завдання або інший скрипт, який його відновлює.
Про проблему повідомив провайдер або поштовий сервіс
Іноді власник дізнається про злам не з панелі моніторингу. Хостинг-провайдер може зафіксувати сканування чужих портів, спроби підбору паролів або аномально велику кількість вихідних з’єднань. Поштова служба може обмежити відправлення, а IP-адреса сервера потрапить до списків спамерів.
Таке повідомлення не варто сприймати як помилкове лише тому, що сайт продовжує працювати. Зловмиснику часто невигідно ламати його повністю. Значно корисніше непомітно користуватися ресурсами сервера якомога довше.
Причиною може бути не повний доступ до операційної системи, а один заражений сайт, вразливий плагін або викрадений пароль від поштової скриньки. Проте локальна проблема здатна перерости в серйозніший злам, якщо шкідливий код отримає додаткові права.
Що робити при підозрі на злам
Не потрібно починати з хаотичного видалення файлів і перезавантаження сервера. Разом із ними можуть зникнути журнали, активні з’єднання та інші сліди, які допомогли б зрозуміти спосіб проникнення. Спочатку бажано обмежити зовнішній доступ, зберегти логи й зафіксувати поточний стан системи.
Далі перевіряють активні процеси, користувачів, ключі, мережеві з’єднання, заплановані завдання та останні зміни у файлах. Паролі потрібно змінювати з безпечного пристрою. Це стосується не лише доступу до сервера, а й панелі керування, CMS, бази даних, пошти та інших пов’язаних сервісів.
Знайти й видалити один заражений файл недостатньо. Потрібно закрити вразливість, через яку він потрапив на сервер, перевірити інші сайти й переконатися, що сторонніх каналів доступу не залишилося. Іноді надійніше розгорнути чисту систему та відновити перевірені дані з резервної копії, ніж намагатися очистити сервер вручну.
Якщо власного досвіду для аналізу недостатньо, краще залучити системного адміністратора або фахівця з кібербезпеки. Він допоможе визначити, як сторонній код потрапив у систему, чи залишилися приховані канали доступу та які дані могли бути скомпрометовані. Резервні копії при цьому варто зберігати окремо від основного сервера й періодично перевіряти, чи можна з них відновити проєкт. Вони не запобігають зламу, але дають змогу повернути сайт до чистого стану, якщо зараження або пошкодження виявили надто пізно.
Залишити відповідь