Електронна пошта: атаки перебору на IMAP/SMTP — захистіть сервер, не заблокувавши себе

Зрозумійте, з чим боретеся: brute force vs spraying vs credential stuffing

Brute force

Класичний перебір — це багаторазові спроби вгадати пароль для одного акаунта (або невеликої кількості), поки щось не пройде.
На IMAP/SMTP це часто націлено на загальні імена користувачів, як-от admin, info, sales, а також
реальні адреси, зібрані з вашого сайту. Такі атаки галасливі: багато невдач, часто з малої кількості IP, інколи з ботнетів,
що чергують дешеві VPS-діапазони.

Password spraying

Spraying — «тонший» родич: спробувати один або кілька поширених паролів по багатьох акаунтах. Це уникає блокувань акаунтів
і виглядає не так помітно — поки не вистрелить повторно використаний пароль і не стане інцидентом.
Spraying особливо поширений на IMAP через широке публічне розкриття і швидкий цикл зворотного зв’язку.

Credential stuffing

Stuffing — це коли нападники використовують зламані пари логін/пароль з інших сайтів. Поштовий сервер — просто місце входу;
витік стався деінде. Атака зазвичай має вищий відсоток успіху, ніж brute force. Ліги у логах можуть виглядати «валідними»:
по одній спробі на акаунт, інколи успішній, а потім миттєва активність у поштовій скриньці або відправлення через SMTP AUTH.

Чому IMAP/SMTP такі привабливі цілі

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

Практичне правило: не дивіться на «brute force на IMAP/SMTP» тільки як на проблему периметра. Це проблема автентифікації, моніторингу
та управління змінами. Ви можете заблокувати тисячу IP і все одно програти через один повторно використаний пароль.

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

Кілька фактів і історичний контекст (бо пошта ніколи не вмирає)

• SMTP передував сучасному інтернету. SMTP був стандартизований на початку 1980-х і припускав більш дружню мережу. «Ворогова автентифікація в масштабі» не була в проєкті.
• IMAP старший за багато «cloud first» стратегій. IMAP з’явився також у 1980-х, оптимізований для віддаленого доступу до скриньки ще до ери смартфонів.
• Порт 25 не був призначений для входу користувача. SMTP на 25 — для сервер-сервер доставки; автентифікована відправка перейшла на 587, щоб розділити функції і політики.
• «Менш безпечні додатки» створили довгий хвіст слабкої автентифікації. Протягом років клієнти входили з простими паролями, щоб отримати пошту; сучасне MFA і паролі для додатків з’являлися пізно і нерівномірно.
• Password spraying зростав разом з політиками блокування. Коли підприємства почали блокувати акаунти після N невдач, нападники пристосувалися до низькорівневих стратегій по багатьох користувачах.
• Ботнети зробили brute force дешевим. Розподілені спроби з тисяч IP перетворюють блокування по IP на гру проти молота і крота, якщо не лімітувати і не посилювати автентифікацію.
• Поштові логи надзвичайно інформативні. Postfix/Dovecot можуть сказати, хто пробував, звідки і як часто — якщо ви зберігаєте логи достатньо довго і не тонули їх у шумі.
• «TLS скрізь» допоміг, але не проти вгадувань. Шифрування каналу запобігає перехвату; воно нічого не робить проти нападника, який вже має списки паролів.

Швидкий план діагностики (перші/другі/треті перевірки)

Коли йде активна атака, ваше завдання: (1) тримати пошту для легітимних користувачів, (2) зупинити витік,
і (3) зберегти достатньо доказів, щоб щось дізнатися. Ось порядок, який не дає збиватися з курсу.

Перше: підтвердіть, що саме не працює і де

• Користувачі не проходять автентифікацію чи не можуть встановити з’єднання? Помилки автентифікації виглядають як auth failed; проблеми з підключенням — як таймаути/відмови.
• Це IMAP, submission (587), SMTPS (465) чи щось інше? Не «виправляйте SMTP», якщо проблема в IMAP, і не блокуйте 587, якщо користувачі ним користуються.
• Сервер завантажений CPU, I/O чи таблиця з’єднань? Під перебором можна заповнити CPU (TLS + автентифікація), I/O (логи + бекенди автентифікації) або мережеві conntrack-таблиці.

Друге: ідентифікуйте домінуючий паттерн атаки

• Невелика кількість IP сильно б’є? Блокування по IP і мережеві ліміти працюють добре.
• Багато IP, багато користувачів, низька швидкість? Це spraying/stuffing. Потрібні обмеження по користувачу, сильніша автентифікація і виявлення аномалій.
• Чи є успішні входи? Якщо так — ви в зоні компрометації: вимикайте акаунти, міняйте паролі, перевіряйте вихідну пошту і MFA/паролі для додатків.

Третє: застосуйте мінімальні зміни для пом’якшення

• Увімкніть або посиліть існуючі обмеження (Dovecot auth penalties, ліміти SASL у Postfix, fail2ban) перед тим, як розгортати нові інструменти під час інциденту.
• Додайте білий список для вашого адміністративного каналу (VPN egress, bastion, офісний IP) перед агресивним блокуванням. Потрібен контрольований прохід, який ви зможете відкрити.
• Не «перезапускайте, поки не працює». Перезапуски можуть стерти логи, очистити стан таблиць iptables і дати ілюзію прогресу, поки атака відновиться відразу.

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

Одна цитата для запам’ятовування: «Системи виходять із ладу складними способами; надійність — це підготовка й навчання, а не заперечення збоїв.» — Річард Кук (парафраз)

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

Це не «виконайте заклинання». Це точні вправи для вашого ранубуку: команда, приклад виводу,
що це означає і що робити далі. Підлаштуйте шляхи й імена сервісів під ваш дистрибутив, але зберігайте логіку.

Завдання 1: Підтвердіть, які порти відкриті (і якими сервісами)

cr0x@server:~$ sudo ss -lntp | egrep ':(25|110|143|465|587|993|995)\s'
LISTEN 0      100          0.0.0.0:25       0.0.0.0:*    users:(("master",pid=1123,fd=13))
LISTEN 0      100          0.0.0.0:587      0.0.0.0:*    users:(("master",pid=1123,fd=15))
LISTEN 0      100          0.0.0.0:465      0.0.0.0:*    users:(("master",pid=1123,fd=16))
LISTEN 0      128          0.0.0.0:993      0.0.0.0:*    users:(("dovecot",pid=998,fd=41))
LISTEN 0      128          0.0.0.0:143      0.0.0.0:*    users:(("dovecot",pid=998,fd=40))

Що це означає: Сервіси слухають на публічних інтерфейсах для SMTP (25), submission (587/465) і IMAP (143/993).

Рішення: Якщо вам не потрібен незашифрований IMAP (143) в інтернеті — перестаньте його виставляти. Якщо порт 465 є, але не використовується, розгляньте його відключення, щоб зменшити площу атаки.

Завдання 2: Перевірте поточний тиск з’єднань (чи вас затоплюють?)

cr0x@server:~$ sudo ss -ant state established '( sport = :993 or sport = :587 )' | wc -l
842

Що це означає: 842 встановлених з’єднань на IMAPS/submission. Для великої організації це може бути нормально, для малої — катастрофа.

Рішення: Порівняйте з базовим рівнем. Якщо це в 10 разів більше норми — переходьте до розбиття по IP і лімітувань.

Завдання 3: Знайдіть топ IP-адреси, що хитають IMAPS прямо зараз

cr0x@server:~$ sudo ss -ant '( dport = :993 )' | awk 'NR>1 {print $5}' | cut -d: -f1 | sort | uniq -c | sort -nr | head
  210 203.0.113.77
  198 198.51.100.22
   95 192.0.2.14
   41 203.0.113.19

Що це означає: Кілька IP домінують. Це «легкий режим» для блокування.

Рішення: Якщо це не ваші NAT-e або відомий моніторинг — блокувати або лімітувати їх на фаєрволі. Якщо ж багато IP з невеликими показниками — переходьте до контролю по користувачу.

Завдання 4: Порахуйте помилки автентифікації за останні 10 хвилин (Dovecot)

cr0x@server:~$ sudo journalctl -u dovecot --since "10 min ago" | egrep -i 'auth failed|authentication failure' | wc -l
12458

Що це означає: Це активно і інтенсивно. За такої швидкості ви згорите CPU, логи і, можливо, бекенд автентифікації.

Рішення: Негайно ввімкніть лімітування (Dovecot auth penalties) і перевірте, чи fail2ban насправді банить.

Завдання 5: Витягніть найчастіше атаковані імена користувачів (підказка spraying vs brute force)

cr0x@server:~$ sudo journalctl -u dovecot --since "30 min ago" | egrep -o 'user=<[^>]+' | cut -d'<' -f2 | sort | uniq -c | sort -nr | head
  611 user=info@example.com
  588 user=admin@example.com
  512 user=support@example.com
  498 user=sales@example.com

Що це означає: Високі лічильники по кількох поштових скриньках вказують на brute force. Якщо бачите сотні різних користувачів з малими показниками — це spraying.

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

Завдання 6: Підтвердіть, що fail2ban працює і має jail для Dovecot

cr0x@server:~$ sudo fail2ban-client status
Status
|- Number of jail:      3
`- Jail list:          dovecot, postfix-sasl, sshd

Що це означає: Є релевантні jail. Добре. Тепер перевірте, чи вони ефективні.

Рішення: Якщо немає dovecot або postfix-sasl — ви покладаєтеся на удачу і обсяг логів.

Завдання 7: Перевірте, скільки IP зараз заблоковано і чи зростає кількість банів

cr0x@server:~$ sudo fail2ban-client status dovecot
Status for the jail: dovecot
|- Filter
|  |- Currently failed: 128
|  |- Total failed:     54122
|  `- File list:        /var/log/mail.log
`- Actions
   |- Currently banned: 317
   |- Total banned:     2901
   `- Banned IP list:   203.0.113.77 198.51.100.22 192.0.2.14

Що це означає: Бани відбуваються. Показник «Currently failed» каже, що jail досі бачить спроби.

Рішення: Якщо Currently banned близький до нуля під час очевидної атаки, ваш regex фільтр неправильний, шлях до лога неправильний або логи пишуться тільки в journald.

Завдання 8: Перевірте, що поштові логи дійсно пишуться туди, куди ви думаєте

cr0x@server:~$ sudo ls -lh /var/log/mail.log
-rw-r----- 1 syslog adm 1.8G Jan  4 01:11 /var/log/mail.log

Що це означає: Файл лога існує і великий. Під атакою I/O логів може стати вузьким місцем.

Рішення: Якщо лог виривається і ви обмежені по I/O, розгляньте тимчасове лімітування і перевірте logrotate. Не вимикайте логування під час інциденту, якщо ви не на межі диска.

Завдання 9: Перевірте місце на диску (бо «пошта впала» може бути «диск повний» у костюмі)

cr0x@server:~$ df -h /var /var/log
Filesystem      Size  Used Avail Use% Mounted on
/dev/sda2       100G   96G  4.0G  97% /var
/dev/sda2       100G   96G  4.0G  97% /var/log

Що це означає: Ви на відстані 3% від самоіндукованого відключення. Під перебором логи можуть добити систему.

Рішення: Обережно звільніть місце (ротація/стиснення, архів), а потім зменшіть ампліфікацію логів, зупинивши повторні спроби автентифікації (ліміти/бани).

Завдання 10: Підтвердіть, що Postfix бачить помилки SASL при submission

cr0x@server:~$ sudo journalctl -u postfix --since "15 min ago" | egrep -i 'SASL.*authentication failed|warning: SASL' | head
Jan 04 01:02:11 mx1 postfix/smtpd[22103]: warning: unknown[203.0.113.77]: SASL LOGIN authentication failed: authentication failure
Jan 04 01:02:12 mx1 postfix/smtpd[22105]: warning: unknown[203.0.113.77]: SASL PLAIN authentication failed: authentication failure

Що це означає: Атакують також SMTP AUTH. Це звично: нападники пробують і IMAP, і submission.

Рішення: Переконайтеся, що ваш jail postfix-sasl у fail2ban відповідає цим рядкам, і при потребі застосуйте ліміти на smtpd.

Завдання 11: Перевірте лічильники nftables/iptables для поштових портів

cr0x@server:~$ sudo nft list ruleset | egrep -n 'dport (25|587|465|993|143)'
42: tcp dport { 25, 587, 465, 993 } ct state new accept

Що це означає: Ви приймаєте нові з’єднання без жодного ліміту. Під атакою це може переповнити процеси і conntrack.

Рішення: Додайте лімітування нових з’єднань на портах IMAP/SMTP AUTH, з обережними порогами й біллістами.

Завдання 12: Перевірте використання conntrack (тихий вбивця під час потоків)

cr0x@server:~$ sudo sysctl net.netfilter.nf_conntrack_count net.netfilter.nf_conntrack_max
net.netfilter.nf_conntrack_count = 247812
net.netfilter.nf_conntrack_max = 262144

Що це означає: Ви близькі до максимуму conntrack. Коли ви його досягнете, легітимні з’єднання почнуть падати дивними способами.

Рішення: Обмежте нові з’єднання, розгляньте підвищення conntrack max (з урахуванням пам’яті), і відкидайте очевидно зловмисні джерела раніше в ланцюгу.

Завдання 13: Визначте, чи у вас вузьке місце на CPU під TLS/автентифікацією

cr0x@server:~$ top -b -n 1 | head -20
top - 01:04:33 up 21 days,  2:11,  1 user,  load average: 18.42, 17.90, 14.20
%Cpu(s): 86.5 us,  9.2 sy,  0.0 ni,  1.1 id,  0.0 wa,  0.0 hi,  3.2 si,  0.0 st
PID USER      PR  NI    VIRT    RES    SHR S  %CPU  %MEM     TIME+ COMMAND
998 dovecot   20   0  786972  41280  12624 R  215.0   0.5  52:10.11 dovecot/auth
1123 root     20   0  145772  12204   8560 S   85.0   0.1  31:02.24 master

Що це означає: Dovecot auth жере CPU. Це може бути перевірка bcrypt/sha512-crypt під атакою (очікувано) або затримки LDAP, що викликають повтори (гірше).

Рішення: Додайте ліміти автентифікації і перевірте стан бекенду автентифікації. Не «оптимізуйте» хеші вниз; це обмін довгострокової безпеки на тимчасовий спокій.

Завдання 14: Перевірте, чи справді LDAP — це вузьке місце

cr0x@server:~$ sudo journalctl -u dovecot --since "10 min ago" | egrep -i 'ldap|connect\(\) failed|timed out' | tail -5
Jan 04 01:00:17 mx1 dovecot: auth: Error: ldap(example.com): Connection timed out
Jan 04 01:00:21 mx1 dovecot: auth: Error: ldap(example.com): Unable to connect to server: Can't contact LDAP server

Що це означає: Атака тепер — DoS для бекенду автентифікації. Навіть легітимні входи можуть падати, бо LDAP насичений або недоступний.

Рішення: Поставте агресивні ліміти перед LDAP (Dovecot auth policy, fail2ban), і розгляньте кешування або локальну автентифікацію для критичних акаунтів.

Завдання 15: Підтвердіть, що ви випадково не дозволяєте незашифровані входи

cr0x@server:~$ sudo dovecot -n | egrep -i 'disable_plaintext_auth|auth_mechanisms|ssl'
disable_plaintext_auth = yes
auth_mechanisms = plain login
ssl = required

Що це означає: TLS обов’язковий, незашифровані логіни вимкнені, але ви все одно дозволяєте PLAIN/LOGIN поверх TLS (це нормально). Якщо ssl = yes і disable_plaintext_auth = no, є ризик.

Рішення: Тримайте TLS обов’язковим. Якщо старі клієнти вимагають незашифрований доступ — виправляйте клієнти; не знижуйте рівень захисту сервера.

Завдання 16: Перевірте обмеження сервісу submission у Postfix (щоб обмежити шкоду після компрометації)

cr0x@server:~$ sudo postconf -n | egrep -i 'smtpd_tls_auth_only|smtpd_recipient_restrictions|smtpd_client_message_rate_limit'
smtpd_tls_auth_only = yes
smtpd_recipient_restrictions = permit_sasl_authenticated,reject_unauth_destination
smtpd_client_message_rate_limit = 200

Що це означає: Авторизація тільки по TLS увімкнена, неавторизоване ретрансляцію заблоковано, і є ліміт повідомлень на клієнта.

Рішення: Якщо немає ліміту відправлення — один скомпрометований акаунт може відправити багато, перш ніж ви це помітите. Додайте розумні обмеження і налаштуйте алерти на сплески.

Багаторівневі заходи, що працюють у продакшені

1) Зменшіть площу атак (не зламавши клієнтів)

Кожен відкритий порт — це контракт з інтернетом. Тримайте ті контракти, які потрібні; припиняйте ті, що не потрібні.
Більшість організацій можуть зробити наступне:

• Публікуйте IMAPS (993) і submission (587). Розгляньте відключення незашифрованого IMAP (143) на публічних інтерфейсах.
• Тримайте порт 25 для сервер-сервер SMTP, але не дозволяйте там автентифікацію користувачів. Користувачі повинні автентифікуватись на 587 (або 465, якщо треба).
• Якщо ви публікуєте autodiscover/autoconfig — переконайтесь, що вони вказують тільки на захищені порти.

Чим більше протоколів ви викриваєте, тим більше політик потрібно узгодити. На практиці «узгоджена політика» — це місце, де виникають інциденти.

2) Лімітуйте нові з’єднання на межі мережі

Це найшвидший важіль, коли ви перевантажені. Лімітування дає час і захищає conntrack та таблиці процесів.
Воно не вирішить spraying, але зупинить безперервне «відбивання» по серверам.

Обмежте нові з’єднання до 993 і 587 для кожного джерела IP. Будьте консервативні: ви формуєте інтернет, а не караєте його.
Також: додайте білий список для VPN egress і моніторингових запитів.

3) Використовуйте fail2ban, але ставтеся до нього як до коду

fail2ban ефективний, коли:

• Ваші логи там, де fail2ban їх читає.
• Regex відповідає точному формату ваших логів.
• Bantime/findtime/maxretry підлаштовані під патерн нападника.
• Ви не баните власний NAT чи сканер безпеки.

При spraying maxretry може бути неактуальним: нападники роблять по одній спробі з кожного IP. Тому важливі обмеження по користувачу.

4) Обмежуйте автентифікацію по користувачу, а не лише по IP

Контролі по IP провалюються проти ботнетів. Контролі по користувачу провалюються проти розподіленого вгадування, якщо у вас немає хорошого захисту від переліку користувачів.
Тим не менш, обмеження по користувачу — це різниця між «шумом атаки» і «LDAP у вогні».

У Dovecot можна ввести penalties для автентифікації і обмежити одночасні запити автентифікації. Мета — не зупинити кожну спробу, а зробити атаку дорогою,
при цьому зберігши роботу реальних користувачів.

5) Посилюйте автентифікацію: MFA де можливо, паролі для додатків де потрібно

Якщо ви можете впровадити MFA для IMAP/SMTP — зробіть це. На практиці багато традиційних IMAP/SMTP клієнтів не підтримують інтерактивне MFA,
тому доводиться використовувати паролі для додатків або OAuth-механізми залежно від екосистеми.

Якщо ваше середовище само-хоститься і не інтегроване з провайдером ідентичності з сучасною автентифікацією, прагматичний підхід:

• Сильна політика паролів на боці сервера (довжина і відкидання поширених паролів).
• Відключайте логін для розділених скриньок, де можливо; використовуйте делегацію.
• Вимагайте TLS, відключайте застарілу автентифікацію там, де можливо.

6) Виявляйте компрометацію, стежачи за тим, що відбувається після успішної автентифікації

Успішні входи під час атаки — це справжня катастрофа. Ваш моніторинг повинен сигналити про:

• Перші входи з нових IP для користувача, особливо з незвичних географій.
• Різке зростання відправлень через SMTP AUTH із поштової скриньки, яка зазвичай тільки приймає.
• Успішний IMAP-вхід, після якого йде миттєве масове завантаження (патерни ексфільтрації різняться, але сплески об’єму показові).

7) Захистіть адміністраторів: створіть «завжди працюючий» шлях доступу

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

• Майте VPN зі стабільними вихідними IP і додайте їх у білий список для керування і (за потреби) для поштових портів.
• Тримайте позасерверний консольний доступ (cloud serial console, iDRAC/iLO) — тестуйте щомісяця.
• Зберігайте процедури відновлення в місці, доступному, коли пошта не працює. Якщо ваш ранубук живе в email — у вас буде важкий вечір.

Жарт №2: Найпростіший спосіб довести, що у вас немає позасерверного доступу — заблокувати свій IP і потім «SSH сильніше».

Три корпоративні історії з практики

Інцидент №1: Неправильне припущення, що «тільки IMAP»

Середня фірма використовувала класичний стек Postfix + Dovecot. Вночі почав рости IMAP brute force.
На виклику побачили очевидне: тисячі невдач за хвилину. Припущення: «Це тільки IMAP, SMTP буде в порядку.»
Вони заблокували кілька IP і пішли на перерву.

Вранці керівники не могли відправляти пошту. Проблема була не в SMTP. Це була автентифікація.
Dovecot був налаштований робити запит до LDAP для кожної спроби входу, і brute force фактично став стрес-тестом для LDAP.
Затримки LDAP зросли, запити автентифікації накопичились, і та сама LDAP-служба також обслуговувала SMTP AUTH (submission). Тож submission теж почав таймаутитись.

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

Вирішення не було героїчним. Вони ввімкнули Dovecot auth throttling і мережеве лімітування нових IMAPS-з’єднань,
потім підстроїли fail2ban, щоб швидше банити повторювачів. LDAP відновився за кілька хвилин.
Після стабілізації вони переглянули цільовані акаунти, змусили скинути паролі для кількох розділених скриньок і ввели паролі для додатків.

Урок: не мисліть протоколи окремими, коли вони користуються тим самим бекендом автентифікації. Під атакою все, що торкається автентифікації, стає одним цілим.

Інцидент №2: Оптимізація, яка повернулась бумерангом

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

Компанія мала віддалених співробітників за великими домогосподарськими ISP і концентратор VPN.
Коли сотні користувачів перепідключилися після відновлення Wi‑Fi, вони виглядали як невелика кількість джерельних IP (NAT і VPN egress).
Нове правило вирішило, що «сотні легітимних користувачів» — це «один дуже активний атакуючий».
IMAP став ненадійним саме тоді, коли він потрібен найбільше.

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

Вони відновились, додавши явні біллісти для VPN egress і офісних NAT-діапазонів, перейшовши від «з’єднань за секунду» до «невдач автентифікації за одиницю часу» там, де можливо,
і додавши логування для правил drop з вибіркою. Також вони задокументували поведінку клієнтів: мобільні IMAP-клієнти можуть відкривати кілька паралельних з’єднань і агресивно перепідключатись.

Урок: оптимізації на межі мережі потребують емпатії до поведінки клієнтів, а не лише зневаги до атак. І мовчазні drops гарні, доки не треба дебажити о 03:00.

Інцидент №3: Нудна практика, що врятувала день (базова лінія + безпечний білліст)

Команда фінансових сервісів мала нудну звичку: щоквартально записували «нормальні» діапазони для підключень IMAP, невдач автентифікації
і пропускної здатності submission. Також підтримували невеликий, перевірений білліст: IP їхнього VPN egress, систему моніторингу
і діапазон break-glass bastion. Ніхто не вихвалявся цим. Це ніколи не потрапляло в слайд-дек.

Коли прийшла brute force-атака, on-call порівняв живі метрики з базовими і одразу побачив різницю: невдач автентифікації в 50 разів більше від норми,
але успішних входів майже не було. Це вказувало на brute force, а не на скомпрометований акаунт.
Вони активували схвалене заздалегідь зміна: посилити penalties Dovecot і зменшити дозволений рівень нових підключень для IMAPS.

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

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

Урок: нудні базові лінії і нудні біллісти — це те, як перетворити інцидент безпеки на рутинний робочий день.

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

1) Симптом: IMAP працює для деяких користувачів, випадково падає для інших

Корінь проблеми: Лімітування по IP або fail2ban банить NAT/VPN вихідні IP. Багато користувачів користуються одним вихідним IP.

Виправлення: Додайте в білий список VPN/офісні вихідні IP. Надавайте перевагу лімітуванню по користувачу для невдач автентифікації. Додайте логування/вибірку для фаєрвол-дропів, щоб бачити, що блокується.

2) Симптом: Навантаження сервера високе, але мережевий трафік не шалений

Корінь проблеми: CPU горить на TLS-handshake і перевірці паролів; нападникам не потрібна велика пропускна здатність.

Виправлення: Лімітуйте нові з’єднання, увімкніть penalties автентифікації і переконайтеся, що повторне використання TLS-сесій налаштовано належним чином. Тримайте сильні хеші паролів; обмежуйте спроби, а не знижуйте захист.

3) Симптом: сплески «authentication failed», потім спрацьовують алерти LDAP/AD

Корінь проблеми: Бекенд автентифікації — вузьке місце; brute force стає DoS для автентифікації.

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

4) Симптом: fail2ban показує нуль банів під час очевидної атаки

Корінь проблеми: Неправильний шлях до лога, несумісність journald vs файл або regex фільтр не відповідає формату Dovecot/Postfix.

Виправлення: Перевірте вхід логів. Прогнавши fail2ban-regex по реальним рядкам логів, підтвердіть, що jail посилається на правильні файли.

5) Симптом: диск наповнюється вночі, потім сервіси падають

Корінь проблеми: Ампліфікація логів під час атаки + слабкий logrotate + малий розділ /var. Іноді в купі з ввімкненим детальним debug-логуванням автентифікації.

Виправлення: Налаштуйте logrotate, стискайте логі, зберігайте логи на окремому файловому розділі, якщо можете, і зупиніть потік автентифікації лімітуваннями/банами.

6) Симптом: скарги на спам від вашого домену, потрапляння в чорні списки, незадоволені клієнти

Корінь проблеми: Успішний credential stuffing або слабкі паролі для SMTP AUTH. Нападники використовують ваш сервер як ретранслятор, автентифікуючись легітимно.

Виправлення: Скиньте паролі уражених акаунтів, увімкніть MFA/паролі для додатків де можливо, додайте ліміти відправлення по користувачу і налаштуйте алерти на аномальну активність відправлення.

7) Симптом: ви заблокували «атакуючих», але атака триває незмінно

Корінь проблеми: Розподілений ботнет або великі IP-пули; блокування по IP одне лише не встигне.

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

8) Симптом: Після «посилення безпеки» легітимні клієнти не можуть підключитись

Корінь проблеми: Вимкнені протоколи/порти без інвентарю клієнтів (старі пристрої, принтери, моніторинг, бізнес-застосунки).

Виправлення: Проведіть інвентар клієнтів, опублікуйте підтримувані налаштування (993/587, TLS обов’язковий) і забезпечте період міграції. Блокуйте застарілий доступ поетапно, а не одним великим змінами в п’ятницю ввечері.

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

Фаза 0: Не заблокуйте себе (зробіть це перед банами)

1. Підтвердіть позасерверний доступ (cloud console, IPMI, serial). Тестуйте вхід, а не лише наявність.
2. Додайте в білий список управлінський вихід (VPN, bastion, офіс) у фаєрволі та ignore-списках fail2ban.
3. Зробіть знімок поточних налаштувань (скопіюйте релевантні конфіги; запишіть поточні правила фаєрвола і налаштування jail у fail2ban).
4. Перевірте запас місця на /var і /var/log. Під атакою логи можуть стати причиною відключення.

Фаза 1: Стабілізація під час активного brute force (15–60 хвилин)

1. Підтвердіть масштаб атаки: тільки IMAP, тільки SMTP AUTH або обидва. Використовуйте journald або підрахунок у mail.log.
2. Застосуйте мережеве лімітування для нових з’єднань до 993/587 (обережно; біллістуйте відомі спільні виходи).
3. Увімкніть/перевірте бан інструментів fail2ban для Dovecot і postfix-sasl. Переконайтеся, що джерело логів правильне.
4. Увімкніть Dovecot auth throttling для захисту бекенду автентифікації і CPU.
5. Слідкуйте за conntrack і лімітами процесів. Якщо ви близькі до максимуму — лімітування підключень обов’язкове.

Фаза 2: Зменште радіус ураження (той же день)

1. Визначте цільовані акаунти (розділені скриньки, керівники, фінанси). Вважайте їх високим ризиком.
2. Скиньте облікові дані для акаунтів з підозрілими успішними входами, а не для всіх «про всяк випадок». Панічні скидання створюють відмови в підтримці.
3. Вимкніть IMAP-логін для розділених скриньок, де можливо; використовуйте делегацію.
4. Вимагайте TLS-only і сучасні порти: IMAPS 993, submission 587. Видаліть публічний 143, якщо можливо.
5. Додайте обмеження відправлення для SMTP AUTH, щоб містити скомпрометовані акаунти.

Фаза 3: Закріпіть результат (наступний спринт)

1. Базуйте нормальну поведінку: невдачі автентифікації/хв, підключення, типові регіони джерел, типові швидкості відправлення.
2. Підключіть алерти на важливі аномалії: успішний вхід з нового ASN/країни, сплески невдач автентифікації по користувачу, сплески вихідного трафіку по користувачу.
3. Посиліть паролі: довжина, заборонені паролі та політика ротації, що узгоджена з вашою платформою ідентичності.
4. Плануйте сучасну автентифікацію, якщо ваша екосистема це підтримує. Якщо ні — плануйте паролі для додатків і обмеження прав.
5. Проводьте game days: симулюйте brute force, перевіряйте бани, біллісти, і чи можете ви адмініструвати сервер.

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

1) Чи варто просто блокувати всі країни, крім нашої?

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

2) Політики блокування акаунтів: добра ідея чи підступна пастка?

Блокування можуть зупинити brute force, але також можуть дозволити DoS проти користувачів (нападники навмисно викликають блокування).
Надавайте перевагу лімітуванню та адаптивним правилам ризику; якщо блокуєте — робіть це коротко і під моніторингом.

3) Чи достатньо fail2ban?

Сам по собі — ні. fail2ban чудовий проти повторюваних невдач з одного IP. Він слабкий проти розподіленого spraying і stuffing.
Поєднуйте його з обмеженням по користувачу, сильною автентифікацією і виявленням аномалій для успішних входів.

4) Чому не відключити IMAP взагалі?

Іноді можна — і це прекрасно. Часто не вдається через застарілі клієнти, робочі процеси або застосунки, що опитують IMAP.
Якщо мусите тримати IMAP, тримайте його тільки на 993, вимагайте TLS і обмежуйте, хто може його використовувати.

5) Чи варто знизити вартість хешування паролів, щоб зменшити навантаження CPU під атакою?

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

6) Як уникнути бану нашого VPN або офісного NAT?

Підтримуйте невеликий перевірений білліст і документуйте його як продакшн-код. Додавайте ці IP у ignore-списки fail2ban і правила фаєрвола.
Потім тестуйте щоквартально. «Ми думаємо, що egress VPN ще той IP» — це не тест.

7) Який найчіткіший знак, що акаунти справді скомпрометовані?

Успішні входи з незвичних IP з подальшими сплесками відправлень, зміни правил у пошті (якщо є) або великі/швидкі скачування через IMAP.
Також: користувачі, які повідомляють «я не відправляв цього листа» — це людська система моніторингу, яку легше пропустити.

8) Чи переносити submission на порт 465 чи 587?

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

9) Чи безпечно блокувати порт 25, щоб зупинити атаки?

Блокування вхідного 25 порушить доставку пошти від інших серверів, якщо ви не використовуєте шлюз. Якщо у вас є поштовий шлюз — добре, блокуйте 25 на бекенді.
Якщо цей хост — ваш MX, порт 25 має залишитись відкритим. Зосередьтесь на запобіганні зловживанням і захисті ресурсів.

10) Що робити, якщо атака робить сервер нестабільним і потрібне негайне полегшення?

Застосуйте мережеві ліміти на нові з’єднання до 993/587 і тимчасові бани для топ IP, потім перевірте, що адмін-доступ у вас працює.
Спочатку стабілізуйте, потім тонко налаштуйте. Не робіть п’ять архітектурних змін в одному інциденті.

Наступні кроки, які не підведуть вас пізніше

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

• Зменшіть площу: IMAPS (993) і submission (587) — ваші за замовчуванням; не виставляйте публічно незашифрований IMAP (143), якщо немає жорсткої потреби.
• Стабілізуйте під навантаженням: лімітуйте нові з’єднання, захищайте conntrack і лімітуйте автентифікацію, перш ніж ваш каталог стане колатералкою.
• Зробіть fail2ban реальним: правильні логи, правильні regex, розумні вікна бану і явні біллісти для спільних виходів.
• Плануйте випадки успіху: стежте за успішними входами під час атак і обмежуйте вихідну відправку, щоб знизити ризик шахрайства і потрапляння в чорні списки.
• Захистіть власний доступ: протестована позасерверна консоль і задокументований білліст — це не «приємна річ». Це спосіб безпечно виправити продакшн.

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