Перші 30 хвилин після встановлення Ubuntu Server — критичні. Стандартний образ не готовий до бойових навантажень: відкритий SSH, root-доступ за паролем, ліміт open files 1024 і жодних автооновлень. За першу добу сервер сканують сотні ботів з ботнетів Mirai та Qbot. На практиці 80% серверів в інфраструктурі наших клієнтів приходять з цими проблемами. Нещодавно до нас звернувся стартап: їхній сервер зламали на другий день після розгортання, витекли користувацькі дані. Ми усунули наслідки і заново налаштували систему так, щоб це не повторилося. Наш процес hardening Ubuntu Server гарантує, що система готова до атак з першого дня.
Ми налаштовуємо Ubuntu Server з нуля — від bare-metal до хмарних інстансів у AWS, GCP, Yandex Cloud. Окрім безпеки, ми оптимізуємо продуктивність: налаштовуємо swap, збільшуємо file-max, підбираємо планувальник I/O (none для SSD, mq-deadline для HDD), вмикаємо TCP BBR для мережевої пропускної здатності. Все це знижує latency і запобігає вильотам при піковому навантаженні. Canonical рекомендує виконати hardening після першого входу.
Які проблеми вирішуємо
-
Безпека за замовчуванням: на хмарних образах часто ввімкнено root-логін. Ми вимикаємо парольну аутентифікацію, налаштовуємо fail2ban з параметрами maxretry=3, bantime=3600, findtime=600, і UFW з білими IP-адресами адміністраторів. Додатково: аудит користувачів, видалення невикористовуваних акаунтів, налаштування sudo через групу
wheel. -
Продуктивність: стандартні ліміти open files (1024) не підходять для навантажених застосунків. Ми збільшуємо їх до 65536 і коригуємо
vm.swappiness(10–20 сервери БД, 60 — для десктопів). Для високонавантажених веб-серверів налаштовуємоnet.core.somaxconn = 1024. - Керованість: без автоматизації оновлень сервер ризикує отримати вразливість. Ми налаштовуємо unattended-upgrades з повідомленнями, а також підключаємо моніторинг Prometheus node_exporter і централізований збір логів через Loki.
Чому стандартне встановлення не підходить для продакшену?
За рекомендацією Canonical, після першого входу необхідно виконати hardening. Ми заміряли: час злому сервера з відкритим портом SSH за паролем — менше 2 годин. Тому перші 30 хвилин після запуску — критичні. Якщо не закрити ці дірки, ви ризикуєте не лише даними, але й репутацією. На практиці ми бачимо, що пропуск hardening Ubuntu Server призводить до інцидентів: злом SSH, простої через неправильний мережевий конфіг (наприклад, вимкнення IPv6 без налаштування DNS-резолвера), збої через переповнення файлових дескрипторів.
| Порівняння підходів | Ручне налаштування | Автоматизація Ansible |
|---|---|---|
| Час на 1 сервер | 4–8 годин | 2–3 години (перший) |
| Повторюваність | Низька, ризик помилки | Висока, версіонування в Git |
| Підтримка парку | Складно | Один плейбук для всіх |
| Вартість інцидентів | Висока | Зниження на 30% |
Автоматизація Ansible прискорює налаштування в 2–3 рази порівняно з ручним. Економія бюджету на інцидентах становить 30–40% після впровадження автоматизації.
Як виконати базовий hardening за 5 кроків?
- Вимкніть root-логін за паролем і налаштуйте SSH-ключі.
- Встановіть і налаштуйте UFW з білим списком IP.
- Встановіть fail2ban з параметрами захисту SSH.
- Налаштуйте unattended-upgrades з повідомленнями.
- Збільште ліміти open files до 65536.
Приклад конфігурації fail2ban
# /etc/fail2ban/jail.local [sshd] enabled = true maxretry = 3 bantime = 3600 findtime = 600 Як прискорити розгортання сервера за допомогою автоматизації?
Використання Ansible або Terraform скорочує час налаштування кожного наступного сервера до 2–3 годин. Ми готуємо ролі для Debian/Ubuntu (common, security, monitoring, time) і зберігаємо їх у Git разом із конфігурацією Terraform для хмарних провайдерів. Це гарантує повторюваність і версіонування. При перестворенні інстанса достатньо запустити один плейбук. Якщо вам потрібне повторюване налаштування для парку серверів — зв'яжіться з нами, ми підготуємо Ansible-ролі.
Як ми налаштовуємо Ubuntu Server під ключ
Конкретний кейс: налаштування сервера для high-load API на Go. Після мінімального встановлення виконуємо:
# Перевірка поточних користувачів і портів
who
ss -tlnp
# Вимкнення root-логіну за паролем
sed -i 's/^PermitRootLogin.*/PermitRootLogin prohibit-password/' /etc/ssh/sshd_config
sed -i 's/^PasswordAuthentication.*/PasswordAuthentication no/' /etc/ssh/sshd_config
systemctl reload ssh
Створюємо користувача app, додаємо SSH-ключ. Далі базова конфігурація:
# Оновлення пакетів
apt update && apt full-upgrade -y
# Часова зона і hostname
timedatectl set-timezone Europe/Kyiv
hostnamectl set-hostname prod-api-01
# Ліміти для навантажених сервісів
cat >> /etc/security/limits.conf << 'EOF'
* soft nofile 65536
* hard nofile 65536
* soft nproc 32768
* hard nproc 32768
EOF
Налаштовуємо захист:
# UFW
ufw default deny incoming
ufw default allow outgoing
ufw allow from <office-ip> to any port 22
ufw --force enable
# fail2ban
apt install -y fail2ban
cp /etc/fail2ban/jail.conf /etc/fail2ban/jail.localІ автооновлення:
apt install -y unattended-upgrades dpkg-reconfigure --priority=low unattended-upgrades Для синхронізації часу використовуємо systemd-timesyncd або chrony — залежно від вимог. Для фінансових застосунків ставимо chrony з ручним налаштуванням NTP-серверів. Приклад конфігурації chrony для продакшену:
server 0.pool.ntp.org iburst server 1.pool.ntp.org iburst allow 10.0.0.0/8 Що входить у налаштування
- Аудит поточного стану сервера (хмарний образ, bare-metal).
- Hardening SSH, UFW, fail2ban, limits, NTP.
- Встановлення та налаштування ПЗ під задачу (nginx, PostgreSQL, Redis, Docker).
- Скриптінг і передача плейбука Ansible для відтворення.
- Документація: підсумкова конфігурація, інструкція з експлуатації.
- Підтримка: 30 днів безкоштовних консультацій після здачі.
У результаті ви отримуєте сервер, готовий до продакшену з першого дня. Вартість налаштування окупається протягом кількох місяців за рахунок запобігання простоям і зломам.
Процес роботи та терміни
| Етап | Тривалість |
|---|---|
| Аудит і планування | 1–2 години |
| Встановлення та hardening | 4–8 годин |
| Налаштування прикладного ПЗ | від 4 годин |
| Тестування та документація | 2–4 години |
| Передача знань | 1 година |
Ручне налаштування одного сервера займає 1–2 дні. Для парку серверів використовуємо Ansible — скорочуємо час до 2–3 годин на кожен наступний. Середня економія бюджету клієнта за рахунок автоматизації — 30% часу на інциденти.
Чому варто довірити налаштування нам?
Ми займаємося DevOps-інфраструктурою понад 5 років, виконали налаштування для 40+ проектів — від стартапів до enterprise. Гарантуємо відповідність найкращим практикам безпеки (CIS benchmark за запитом). Для налаштування сервера під ваш проект — зв'яжіться з нами. Отримайте консультацію з hardening Ubuntu Server.
