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

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

Крок перший: хто заходив

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

last -20
lastb | head -20
who

last показує останні успішні входи, lastb — невдалі, who — того, хто підключений просто зараз. Важлива не кількість, а форма. Тисячі невдалих спроб з адрес, які більше не повертаються, — звичайний фоновий перебір; він іде проти будь-якої публічної адреси без упину й не означає нічого.

Насторожити має інше:

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

Окремо перевірте, чи не з’явилися незнайомі ключі. Файл ~/.ssh/authorized_keys — найпоширеніший спосіб залишитися всередині: пароль можна міняти скільки завгодно, ключ залишається.

cat ~/.ssh/authorized_keys
sudo cat /root/.ssh/authorized_keys

Кожен рядок там — чийсь доступ. Якщо ви не можете сказати, чий саме, вважайте його чужим.

Крок другий: що змінилося в системі

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

На Debian та Ubuntu еталон уже є: кожен пакет знає контрольні суми власних файлів.

sudo apt install debsums
sudo debsums -c

Команда виводить файли, що відрізняються від того, що встановив дистрибутив. Частина знахідок буде легітимною — конфігураційні файли в /etc для того й існують, щоб їх редагували. Змінений виконуваний файл у /usr/bin, /usr/sbin чи /bin на сервері, якого ви руками не торкалися, — зовсім інша річ.

Друге джерело — свіжі файли там, де їх бути не повинно. Вебшелл зазвичай сидить у каталозі завантажень і має вигляд невинного .php:

find /var/www -type f -name '*.php' -mtime -14 -ls

Чотирнадцять днів — лише відправна точка; беріть період, за який ви точно нічого не публікували.

Крок третій: що йде назовні

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

ss -tulpn
ss -tp state established

Перша команда показує, що слухає, друга — що підключено просто зараз. Читайте стовпець процесу. Питання викликають: незнайомий процес, що слухає на 0.0.0.0; вихідні з’єднання на високі порти адрес, з якими вашому застосунку немає справ; і насамперед процес, запущений з /tmp або /dev/shm — нічого легітимного з цих каталогів не працює.

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

Якщо ознаки є

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

Порядок, який зберігає і дані, і картину:

  1. Зробіть знімок диска в провайдера, якщо така можливість є. Це єдиний крок, який згодом не повторити.
  2. Відріжте машину від мережі або закрийте все, крім власної IP-адреси, — але не вимикайте її. Вимкнення втрачає список процесів і відкриті з’єднання, а це половина доказів.
  3. Скопіюйте журнали з машини: /var/log/auth.log, журнали вебсервера, вивід трьох команд вище.
  4. І лише тепер з’ясовуйте, як вони потрапили всередину.

Чисте перевстановлення — правильний фінал, якщо доступ було отримано з правами root. Жодне прибирання не гарантує, що нічого не залишилося. Але перевстановлювати, не розібравшись у причині, немає сенсу: ту саму діру ви повернете на свіжу систему.

Як зробити, щоб питання не виникало раптово

Усе вищезазначене — разова ручна перевірка, і вона відповідає на питання «що відбувається просто зараз». Біда в тому, що питання зазвичай ставлять пізно: коли вже написав провайдер або впав сайт.

Кожна з цих перевірок існує як окремий інструмент, здатний стежити безперервно: невдалі входи — fail2ban, зміни файлів — AIDE, цілісність пакетів — debsums, відкриті порти — регулярний знімок ss. Встановити їх поодинці неважко; важко виробити звичку щодня заходити й читати шість різних виводів, тому на практиці їх ніхто й не читає.

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