Брутфорс, який ніколи не спить: як захистити сервер від атак підбору паролів у 2025 році

Прямо зараз, поки ви читаєте це речення, десятки ботів стукають у двері вашого сервера. Вони не втомлюються, не п'ють каву і не беруть вихідних. Щосекунди вони перебирають комбінації логінів і паролів - methodично, безупинно, автоматично. Це брутфорс-атака, і якщо ви думаєте, що ваш маленький сервер нікому не цікавий - у мене для вас погані новини. За даними Cloudflare, у 2024 році середній сервер, підключений до інтернету, отримував від 1 200 до 4 500 спроб несанкціонованого входу на добу. Не на тиждень. На добу. І 2025-й не став милосерднішим.

Що таке брутфорс і чому він досі працює

Брутфорс - це як злодій, який стоїть біля замка і перебирає ключі. Тільки замість фізичного зв'язки у нього мільярди комбінацій, а замість рук - скрипт на Python, який працює із швидкістю тисяч спроб на хвилину. Здавалось би, примітивна техніка з 90-х. Але вона досі входить у топ-5 найпоширеніших векторів атак. Чому?

Тому що люди залишаються людьми. admin:admin, root:123456, user:password - ці комбінації зустрічаються на серверах частіше, ніж ви готові визнати. Дослідження NordPass за 2024 рік показало, що пароль "123456" утримує першість уже шостий рік поспіль. Шостий. Рік.

Сучасні брутфорс-інструменти - Hydra, Medusa, Burp Suite - вміють набагато більше, ніж просто перебирати символи. Вони використовують:

• Словникові атаки - готові бази з мільйонами реальних зламаних паролів
• Credential stuffing - паролі, вкрадені з одного сервісу, пробуються на іншому
• Гібридні методи - комбінування словникових слів із числами та символами
• Розподілені атаки - тисячі IP-адрес одночасно, щоб обійти блокування

І ось що найгірше: навіть невдала брутфорс-атака шкодить. Вона з'їдає ресурси CPU, забиває логи, уповільнює легітимні з'єднання. Ваш сервер буквально витрачає час на обслуговування зловмисників замість ваших клієнтів.

Перша лінія оборони: SSH і порти

Якщо ваш SSH-порт досі 22 - вітаю, ви полегшили життя кожному боту в інтернеті. Так, зміна порту - це не захист сама по собі. Це як переставити вхідні двері на бічну стіну будинку. Професіонал знайде. Але 90% автоматичних сканерів навіть не шукатимуть. Вони сканують порт 22 і йдуть далі, до наступної жертви.

Перше правило серверної безпеки 2025 року: відключіть автентифікацію по паролю для SSH повністю. Використовуйте тільки ключі. Це не порада для просунутих - це мінімальний стандарт. Генеруєте пару ключів Ed25519, копіюєте публічний ключ на сервер, вимикаєте PasswordAuthentication у sshd_config. П'ять хвилин роботи - і словникові атаки на SSH стають безглуздими.

Далі - вимкніть вхід під root. Директива PermitRootLogin no. Навіть якщо атакуючий якимось дивом отримає валідний ключ, він потрапить у непривілейований акаунт. Між ним і повним контролем стоятиме ще один бар'єр.

Fail2Ban та його сучасні альтернативи

Fail2Ban - це як охоронець, який рахує невдалі спроби і після третьої каже: "Все, хлопче, ти в бані". Він моніторить логи, знаходить підозрілі патерни і додає IP-адресу в firewall. Класика. Працює. Але у 2025 році потребує правильного налаштування.

"Fail2Ban із дефолтною конфігурацією - це парасолька з дірками. Вона створює ілюзію захисту, поки не починається справжній дощ." - Daniel Miessler, автор книги "The Real Internet of Things"

Ось мій рекомендований мінімум для jail.local:

1. Зменшіть maxretry до 3 спроб (дефолт - 5, це забагато)
2. Збільшіть bantime мінімум до 3600 секунд (година), а краще - використовуйте bantime.increment = true для експоненціального зростання
3. Додайте jail'и не тільки для SSH, а й для Apache/Nginx, Postfix, Dovecot - все, що приймає автентифікацію
4. Налаштуйте сповіщення на email - ви маєте знати, коли вас атакують
5. Використовуйте recidive jail для рецидивістів - повторні порушники блокуються на тиждень

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

Порівняння інструментів захисту від брутфорсу

Я зібрав таблицю, яка допоможе обрати правильний інструмент залежно від вашого сценарію. Тестував на VPS із 2 CPU і 4 GB RAM під Ubuntu 24.04:

Окремо хочу згадати Endlessh - це не зовсім захист, а скоріше пастка. Він тримає з'єднання відкритим і нескінченно повільно відправляє SSH-банер. Бот підключається і... застрягає. На годину. На дві. Ваш реальний SSH працює на іншому порту, а бот марнує свої ресурси. Краса.

Двофакторна автентифікація на сервері - не тільки для Gmail

Коли я кажу "2FA на сервері", більшість людей дивиться на мене так, ніби я пропоную встановити турнікет у квартирі. Але це працює. І це простіше, ніж здається.

Google Authenticator PAM-модуль дозволяє додати TOTP-коди до будь-якого входу в систему. Навіть якщо хтось вкраде ваш SSH-ключ (так, таке буває - через скомпрометовані ноутбуки, бекапи в незашифрованих хмарах, або банальний фішинг), без шестизначного коду з телефону він нікуди не потрапить.

Альтернатива - апаратні ключі FIDO2/U2F. YubiKey або SoloKeys. Фізичний пристрій, який треба торкнутися для підтвердження входу. OpenSSH підтримує FIDO2 нативно з версії 8.2. Це рівень захисту, який використовують Google і Meta для своїх інженерів. І він доступний вам за 25-50 євро.

Комбінація SSH-ключа + TOTP або FIDO2 робить класичний брутфорс математично безнадійним. Навіть якщо атакуючий якось підбере ключ - а це вже за межами реального - йому ще потрібен другий фактор, який змінюється кожні 30 секунд.

Моніторинг: бачити атаку до того, як вона стала проблемою

Захист без моніторингу - це як замок на дверях без вічка. Ви не знаєте, хто стукає, скільки їх, і чи не пробують вони вже вікна.

Мінімальний набір моніторингу у 2025 році:

• Логування всіх спроб автентифікації - journalctl -u sshd має стати вашим ранковим ритуалом (або автоматизуйте це)
• Алерти на аномалії - якщо з однієї підмережі приходить 500+ спроб за годину, ви повинні знати про це в реальному часі
• Геоблокування - якщо ваші адміністратори сидять у Києві і Варшаві, навіщо дозволяти SSH-з'єднання з В'єтнаму?
• Аудит sudo-команд - навіть після входу моніторте, що відбувається всередині

Інструменти на вибір: Grafana + Loki для візуалізації логів, Wazuh як повноцінна SIEM-система для серверів, або навіть простий скрипт на bash, який надсилає в Telegram кожну успішну SSH-сесію. Останній варіант я особисто використовую на своїх серверах - п'ять рядків коду, а спокою додає як хороший замок.

Є ще один нюанс, про який рідко говорять. Rate limiting на рівні firewall. Навіть до Fail2Ban. Iptables або nftables можуть обмежити кількість нових з'єднань на порт - скажімо, не більше 4 за хвилину з однієї IP. Це працює на рівні ядра, споживає мінімум ресурсів і відсікає найтупіших ботів ще до того, як вони створять запис у лозі.

Що буде, якщо нічого не робити

Я знаю, про що ви думаєте. "У мене маленький сервер, хто мене зламає?" Розповім коротку історію. Знайомий з Кракова запустив невеликий інтернет-магазин на VPS за 10 євро на місяць. Не налаштував нічого - дефолтний SSH на 22 порту, пароль root із 8 символів, жодного Fail2Ban. Через три тижні сервер став частиною ботнету. Розсилав спам. Хостер заблокував акаунт. Бекапів не було. Три тижні роботи, каталог товарів, фото - все згоріло.

Ціна лінощів: приблизно 2 000 євро втраченого часу і прибутку. Ціна захисту: 30 хвилин налаштування.

Брутфорс не зникне. Штучний інтелект тільки робить його розумнішим - атаки стають адаптивними, вони вчаться обходити прості правила блокування, імітують поведінку людини. Але й захист еволюціонує. Питання лише одне: ви будете серед тих, хто адаптувався, чи серед тих, чий сервер тихо майнить криптовалюту для когось іншого?