Невдала спроба входу не означає злам
У журналах сервера, доступного з інтернету, швидко накопичуються десятки записів про невдалі спроби входу через SSH. Через це легко впасти в одну з двох крайнощів: терміново блокувати все підряд або відмахнутися від подій як від звичайної активності ботів.
Почніть із головного: з’ясуйте, чи вдалося комусь увійти і що змінилося після цього. Самі спроби підібрати ім’я користувача чи пароль не означають, що сервер зламали.
Приводом для цієї пам’ятки стало незалежне дослідження Uphill Security. У липні 2026 року 15 ізольованих SSH-пасток цієї мережі зафіксували 1 531 053 спроби входу з 6 790 унікальних IP-адрес. Ці цифри описують лише одну мережу пасток, а не весь інтернет, тому стан свого сервера оцінюйте за його журналами.
Почніть із чотирьох перевірок
- Зафіксуйте, який сервер, часовий пояс і період ви перевіряєте. Збережіть копію потрібних записів у захищеному місці, де їх не буде перезаписано.
- Відокремте невдалі спроби від успішних входів. Формулювання залежать від операційної системи й джерела журналу, тому перевіряйте зміст запису, а не орієнтуйтеся лише на одне ключове слово.
- Для кожного успішного входу перевірте, чи дозволено цей обліковий запис, хто саме входив і чи очікуваними були час та джерело підключення.
- Перевірте, що відбувалося після входу: чи змінювалися користувачі та дозволені ключі, чи запускалися незнайомі процеси й чи з’явилися нові з’єднання від сервера назовні.
Не видаляйте журнали й не перезапускайте сервер лише для того, щоб припинити потік сповіщень. Спочатку збережіть записи. Якщо перезапуск потрібен з іншої причини, дотримуйтеся прийнятого у вашій організації плану реагування.
Коли потрібне термінове реагування
Одна незнайома подія сама по собі не доводить злам. Проте успішний вхід, якого ніхто не може пояснити, новий адміністративний обліковий запис, доданий ключ, незнайомий процес або неочікуване вихідне з’єднання треба негайно перевірити вручну.
Якщо для події немає підтвердженого пояснення або зберігається ризик несанкціонованого доступу, дійте за планом реагування на інциденти. Він може передбачати ізоляцію сервера від мережі, збереження журналів і заміну з довіреного середовища тих облікових даних, яких міг торкнутися інцидент.
Такі дії стримують можливий інцидент, але не показують, чи був злам і наскільки далеко він зайшов.
SSH-пастка не захищає робочі системи
SSH-пастка — це ізольований сервер-приманка для спостереження за спробами доступу, а не засіб захисту робочого середовища. Вона показує, як часто й за якими схемами намагаються увійти, але не повинна мати доступу до реальних сервісів.
Тримайте пастку окремо від робочих систем і не зберігайте на ній робочі ключі, облікові дані чи секрети. Заблокуйте маршрути до внутрішніх мереж, обмежте вихідний трафік і передавайте записи до окремого захищеного сховища. Не підключайтеся до пастки робочим адміністративним ключем.
Якщо таку ізоляцію неможливо гарантувати, пастку краще не запускати.
Збирайте лише потрібні дані
Корисний мінімум — час і часовий пояс, ідентифікатор сервера, джерело підключення, введене ім’я користувача, результат і метод автентифікації. Цього досить, щоб порахувати частоту та знайти повторювані схеми.
Обмежте доступ до журналів, визначте мету аналізу та зберігайте записи лише стільки, скільки для неї потрібно. Не публікуйте паролі, ключі, токени чи повні IP-адреси. Не збирайте паролі, якщо вони не потрібні для окремого, заздалегідь погодженого дослідження.
Перенесіть уроки на реальний сервер
Перед вимкненням парольного входу переконайтеся, що можете увійти за ключем з іншого сеансу, відкрити консоль відновлення й повернути конфігурацію з резервної копії. Так ви не відріжете собі адміністративний доступ.
Після цього, де можливо, вимкніть парольний вхід, використовуйте окремі адміністративні облікові записи та обмежте SSH-доступ. Дозволяйте підключення лише через VPN, із визначених мереж або через бастіонний сервер.
Обмежте частоту повторних спроб і налаштуйте сповіщення про успішні входи та зміни ключів. Ці заходи не замінюють автентифікацію за ключами, мережеві обмеження й перевірку журналів.
Де допоможе ШІ
Якщо правила вашої організації дозволяють, локальний або корпоративний інструмент може згрупувати знеособлені події за часом, результатом і схожими ознаками. Передавайте лише потрібні поля: час, результат, метод автентифікації, умовну назву облікового запису та випадковий псевдонім джерела, створений локально й незмінний у межах вибірки.
Не використовуйте для цього простий хеш IP-адреси: усі можливі IPv4-адреси можна перебрати й знайти початкову адресу. Таблицю відповідностей між справжніми адресами та псевдонімами зберігайте у захищеному середовищі й не передавайте моделі.
Попросіть окремо перелічити успішні входи й дані, яких бракує. Не передавайте IP-адреси, паролі, ключі чи токени й не просіть модель вирішувати, чи сервер зламано.
Модель не бачить повного стану сервера. Звірте її підрахунки з первинним журналом і вручну перевірте кожну успішну автентифікацію.
Небезпечні скорочення
Не вважайте кожну невдалу спробу інцидентом, не покладайтеся насамперед на постійне блокування IP-адрес і не під’єднуйте пастку до робочих систем. Головне питання залишається незмінним: чи хтось успішно увійшов і що сталося після цього?
Джерела
Короткий чеклист
- зберегти записи журналу за потрібний період і зафіксувати часовий пояс
- відокремити невдалі спроби входу від успішних
- перевірити нові ключі, користувачів, процеси та з’єднання
- не підключати SSH-пастку до внутрішньої мережі
- перевірити відновлення доступу, а потім посилити захист SSH
Згрупувати знеособлені події SSH для ручної перевірки
Допоможи провести попередній аналіз подій SSH. Вхідні дані: - сімейство операційної системи та джерело журналу; - часовий пояс і період, який треба перевірити; - знеособлені рядки з часом, результатом входу, методом автентифікації, умовною назвою облікового запису та випадковим псевдонімом джерела, незмінним у межах вибірки; - час запланованих технічних робіт. Не запитуй і не відновлюй IP-адреси, паролі, ключі, токени чи справжні імена користувачів. Формат відповіді: 1. коротке резюме, яке не робить висновку про злам; 2. групи повторюваних подій за часом, результатом і шаблоном; 3. окремий список успішних входів для ручної перевірки; 4. дані, яких бракує; 5. подальші безпечні перевірки — від простих до поглиблених.