Настройка Ubuntu Server после установки: полное руководство для администратора

Ubuntu Server держит больше 33% рынка веб-серверов — это данные W3Techs за 2025 год, и цифра не удивляет. Мы сами ставим его на подавляющее большинство серверов клиентов. После установки ISO вы получаете голый терминал — никакой графики, минимум пакетов. Canonical сделали это намеренно: лишние процессы жрут память и расширяют поверхность атаки. Но именно поэтому после первой загрузки система ещё не готова к реальной нагрузке. В этом руководстве мы пройдём каждый этап настройки с нуля — от обновления ядра до мониторинга. Все команды проверены на Ubuntu Server 22.04 и 24.04 LTS, работают на VPS, bare-metal и виртуалках одинаково.

Обновление системы и ядра

Первое, что делаем на любом свежем сервере — обновляем пакетную базу и ставим все доступные апдейты. Между датой сборки ISO и моментом вашей установки могут пройти месяцы. За это время выходят десятки патчей, в том числе критические CVE для ядра. Пропустить этот шаг — значит выпустить сервер в интернет уже уязвимым.

# Обновить списки пакетов из репозиториев
sudo apt update

# Посмотреть, какие пакеты имеют обновления
sudo apt list --upgradable

# Установить все доступные обновления
sudo apt upgrade -y

# Обновить ядро и системные пакеты (dist-upgrade разрешает зависимости)
sudo apt dist-upgrade -y

# Удалить неиспользуемые пакеты
sudo apt autoremove -y

# Перезагрузить для применения нового ядра
sudo reboot

Создание рабочего пользователя и настройка sudo

Работать под root — это плохо. Не «нежелательно», а именно плохо — так говорят и CIS Benchmark, и NIST. При установке Ubuntu Server создаёт непривилегированного пользователя автоматически, но если вы разворачивали систему из облачного образа, пользователя, скорее всего, придётся создать руками. Почему sudo лучше, чем пароль root? Всё просто: каждая привилегированная команда пишется в /var/log/auth.log. Когда что-то пойдёт не так — а рано или поздно идёт — у вас будет полный журнал, кто и что делал.

# Создать пользователя
sudo adduser sysadmin

# Добавить в группу sudo
sudo usermod -aG sudo sysadmin

# Проверить группы пользователя
groups sysadmin

# Переключиться на нового пользователя для проверки
su - sysadmin
sudo whoami  # должен вернуть root

Настройка SSH: ключи ed25519, смена порта, отключение паролей

SSH — это, как правило, единственный способ попасть на сервер удалённо. Базовая конфигурация OpenSSH в Ubuntu работает, но для боевой среды её недостаточно. Мы регулярно смотрим логи клиентских серверов: обычный VPS с открытым портом 22 получает от 5 000 до 50 000 брутфорс-атак в сутки. Да, именно столько. Правильная настройка SSH закрывает эту проблему практически полностью.

Генерация ключей ed25519 на клиентской машине

Ed25519 вместо RSA — это не просто модная рекомендация. Алгоритм построен на эллиптических кривых, ключ всего 256 бит против 4096 у RSA, при этом криптографическая стойкость выше. Плюс работает заметно быстрее при установке соединения. Если генерируете ключи сейчас — берите Ed25519, без вариантов.

# На КЛИЕНТСКОЙ машине (вашем рабочем ПК)
ssh-keygen -t ed25519 -C "admin@company.ru" -f ~/.ssh/id_ed25519_server

# Скопировать публичный ключ на сервер
ssh-copy-id -i ~/.ssh/id_ed25519_server.pub sysadmin@server_ip

# Проверить вход по ключу (не должен запрашивать пароль сервера)
ssh -i ~/.ssh/id_ed25519_server sysadmin@server_ip

Закалка конфигурации sshd

Убедились, что авторизация по ключу работает? Тогда идём ужесточать конфигурацию. Открываем /etc/ssh/sshd_config и вносим изменения:

# Сменить порт (выберите нестандартный из диапазона 1024-65535)
Port 2222

# Запретить вход root
PermitRootLogin no

# Отключить аутентификацию по паролю
PasswordAuthentication no

# Отключить пустые пароли
PermitEmptyPasswords no

# Использовать только протокол 2
Protocol 2

# Ограничить количество попыток аутентификации
MaxAuthTries 3

# Отключить X11 forwarding (на сервере GUI не нужен)
X11Forwarding no

# Задать таймаут неактивности (300 секунд = 5 минут)
ClientAliveInterval 300
ClientAliveCountMax 2

# Разрешить вход только определённым пользователям
AllowUsers sysadmin

# Проверить синтаксис конфигурации перед перезапуском
sudo sshd -t

# Перезапустить SSH
sudo systemctl restart sshd

Настройка файрвола UFW

UFW — это надстройка над iptables/nftables, которая поставляется с Ubuntu. Писать правила на чистом iptables можно, но зачем, если UFW позволяет сделать то же самое человеческим языком. На свежем сервере файрвол выключен — нужно включить его и прописать правила до того, как сервер примет первый запрос из интернета.

# Установить политику по умолчанию: блокировать всё входящее
sudo ufw default deny incoming

# Разрешить всё исходящее
sudo ufw default allow outgoing

# Разрешить SSH на нестандартном порту
sudo ufw allow 2222/tcp comment 'SSH'

# Разрешить HTTP и HTTPS (если на сервере будет веб)
sudo ufw allow 80/tcp comment 'HTTP'
sudo ufw allow 443/tcp comment 'HTTPS'

# Включить файрвол
sudo ufw enable

# Проверить статус и список правил
sudo ufw status verbose

Лимитирование подключений

У UFW есть встроенный rate limiting. Он автоматически блокирует IP, если тот делает больше 6 подключений за 30 секунд:

# Вместо обычного allow — используем limit
sudo ufw limit 2222/tcp comment 'SSH rate-limit'

Настройка времени и NTP-синхронизации

Неправильное время на сервере — источник очень неприятных проблем. Слетают TLS-сертификаты, ломается Kerberos-аутентификация, cron-задачи срабатывают не тогда, когда нужно, а в логах появляются записи из «прошлого». В Ubuntu 18.04+ есть systemd-timesyncd, но для продакшена мы рекомендуем chrony: он точнее и лучше справляется с нестабильными сетевыми задержками, что на VPS встречается постоянно.

# Проверить текущее время и часовой пояс
timedatectl

# Просмотреть доступные часовые пояса
timedatectl list-timezones | grep Moscow

# Установить московское время
sudo timedatectl set-timezone Europe/Moscow

# Установить chrony вместо стандартного timesyncd
sudo apt install chrony -y

# Проверить статус синхронизации
chronyc tracking

# Проверить источники времени
chronyc sources -v

Установка и настройка fail2ban

Fail2ban смотрит логи сервисов — SSH, nginx, Apache — и блокирует IP-адреса, которые ведут себя подозрительно. Это не замена UFW, а дополнение к нему. UFW работает со статическими правилами, Fail2ban — с поведением. Вместе они закрывают большинство сценариев автоматизированных атак.

# Установить fail2ban
sudo apt install fail2ban -y

# Создать локальную конфигурацию (не редактируйте jail.conf!)
sudo cp /etc/fail2ban/jail.conf /etc/fail2ban/jail.local

Редактируем /etc/fail2ban/jail.local:

[DEFAULT]
bantime  = 3600
findtime = 600
maxretry = 3
banaction = ufw

[sshd]
enabled = true
port    = 2222
filter  = sshd
logpath = /var/log/auth.log
maxretry = 3

# Перезапустить и включить автозагрузку
sudo systemctl restart fail2ban
sudo systemctl enable fail2ban

# Проверить статус jail-ов
sudo fail2ban-client status
sudo fail2ban-client status sshd

Настройка swap-файла

На VPS с 1-4 ГБ оперативки swap-файл — это не роскошь, а страховка. Сам по себе swap медленнее RAM в разы, но он спасает от OOM Killer, который при нехватке памяти начинает убивать процессы. Иногда — самые важные. Лучше пусть сервер немного притормозит, чем упадёт база данных в пиковый момент.

# Проверить текущий swap
sudo swapon --show

# Создать swap-файл размером 2 ГБ
sudo fallocate -l 2G /swapfile

# Установить права (только root)
sudo chmod 600 /swapfile

# Инициализировать swap
sudo mkswap /swapfile

# Активировать
sudo swapon /swapfile

# Проверить
free -h

# Добавить в fstab для автозагрузки
echo '/swapfile none swap sw 0 0' | sudo tee -a /etc/fstab

Оптимизация swappiness

# Для серверов рекомендуется низкое значение (10-20)
# По умолчанию 60 — слишком агрессивно для сервера
sudo sysctl vm.swappiness=10

# Сделать постоянным
echo 'vm.swappiness=10' | sudo tee -a /etc/sysctl.conf

Автоматические обновления безопасности

Руками обновлять пакеты — правильная привычка. Но критические патчи безопасности не должны ждать, пока у вас дойдут руки. Пакет unattended-upgrades в Ubuntu установлен по умолчанию, однако нормально не настроен — это нужно сделать явно.

# Убедиться что пакет установлен
sudo apt install unattended-upgrades -y

# Запустить интерактивную настройку
sudo dpkg-reconfigure -plow unattended-upgrades

Смотрим и правим конфигурацию в /etc/apt/apt.conf.d/50unattended-upgrades:

Unattended-Upgrade::Allowed-Origins {
    "${distro_id}:${distro_codename}-security";
    "${distro_id}ESMApps:${distro_codename}-apps-security";
};

// Автоматическая перезагрузка если требуется (по расписанию)
Unattended-Upgrade::Automatic-Reboot "true";
Unattended-Upgrade::Automatic-Reboot-Time "04:00";

// Уведомления по email
Unattended-Upgrade::Mail "admin@company.ru";
Unattended-Upgrade::MailReport "on-change";

Настройка hostname и базовой сети

Правильный hostname — это мелочь, которая экономит много времени потом. Когда у вас десяток серверов в мониторинге и в логах мелькает непонятный «ubuntu», это раздражает. В Ubuntu Server 18.04+ сетью управляет Netplan.

# Задать hostname
sudo hostnamectl set-hostname web-prod-01

# Проверить
hostnamectl

# Отредактировать /etc/hosts
sudo nano /etc/hosts
# Добавить: 127.0.1.1  web-prod-01

Базовая конфигурация Netplan (статический IP)

# /etc/netplan/01-netcfg.yaml
network:
  version: 2
  ethernets:
    eth0:
      addresses:
        - 192.168.1.100/24
      gateway4: 192.168.1.1
      nameservers:
        addresses:
          - 8.8.8.8
          - 1.1.1.1

# Применить конфигурацию
sudo netplan apply

Базовый мониторинг и полезные утилиты

На каждом сервере должен быть базовый набор инструментов для диагностики — без них работать неудобно. Ставим всё одной командой:

# Диагностические утилиты
sudo apt install -y htop iotop iftop ncdu tmux curl wget net-tools dnsutils

# htop — интерактивный монитор процессов (замена top)
# iotop — мониторинг дисковых операций по процессам
# iftop — мониторинг сетевого трафика в реальном времени
# ncdu — визуальный анализ занятого дискового пространства
# tmux — терминальный мультиплексор (незаменим при длительных операциях)
# net-tools — ifconfig, netstat (классика)
# dnsutils — dig, nslookup

Настройка логирования через journald

# Ограничить размер журнала (чтобы не съел весь диск)
sudo nano /etc/systemd/journald.conf

# Установить:
# SystemMaxUse=500M
# MaxRetentionSec=30day

# Перезапустить
sudo systemctl restart systemd-journald

# Проверить текущий размер логов
journalctl --disk-usage

Защита shared memory и сетевого стека

Несколько sysctl-параметров реально меняют картину с безопасностью на серверном Linux. Добавьте их в /etc/sysctl.conf — это занимает пять минут, а эффект ощущается сразу:

# Защита от IP spoofing
net.ipv4.conf.all.rp_filter = 1
net.ipv4.conf.default.rp_filter = 1

# Игнорировать ICMP-редиректы (защита от MITM)
net.ipv4.conf.all.accept_redirects = 0
net.ipv6.conf.all.accept_redirects = 0

# Не отправлять ICMP-редиректы
net.ipv4.conf.all.send_redirects = 0

# Защита от SYN flood
net.ipv4.tcp_syncookies = 1

# Логировать «марсианские» пакеты
net.ipv4.conf.all.log_martians = 1

# Защита shared memory
# Добавить в /etc/fstab: tmpfs /run/shm tmpfs defaults,noexec,nosuid 0 0

# Применить настройки
sudo sysctl -p

Настройка автоматических бэкапов

Без бэкапов все предыдущие настройки — просто иллюзия безопасности. Диск умирает неожиданно. Минимум, с которого мы рекомендуем начинать, — ежедневный архив критических директорий через cron:

#!/bin/bash
# /opt/scripts/daily-backup.sh
BACKUP_DIR="/var/backups/daily"
DATE=$(date +%Y%m%d)

mkdir -p "$BACKUP_DIR"

# Бэкап конфигураций
tar czf "$BACKUP_DIR/etc-$DATE.tar.gz" /etc/

# Бэкап домашних директорий
tar czf "$BACKUP_DIR/home-$DATE.tar.gz" /home/

# Удалить бэкапы старше 30 дней
find "$BACKUP_DIR" -name "*.tar.gz" -mtime +30 -delete

# Сделать скрипт исполняемым
sudo chmod +x /opt/scripts/daily-backup.sh

# Добавить в cron (ежедневно в 3:00)
echo "0 3 * * * root /opt/scripts/daily-backup.sh" | sudo tee /etc/cron.d/daily-backup

Итоговый чек-лист настройки Ubuntu Server

1. Обновление — apt update && apt dist-upgrade
2. Пользователь — создан рабочий пользователь с sudo, root заблокирован
3. SSH — ключи ed25519, нестандартный порт, вход по паролю отключён
4. Файрвол — UFW включён, снаружи торчат только нужные порты
5. Fail2ban — брутфорс SSH и других сервисов заблокирован автоматически
6. Время — часовой пояс выставлен, chrony держит NTP-синхронизацию
7. Swap — swap-файл создан, swappiness подкручен под реальную нагрузку
8. Обновления безопасности — unattended-upgrades работает без вашего участия
9. Hostname и сеть — Netplan настроен и проверен
10. Мониторинг — htop, iotop, journald готовы к работе
11. Sysctl hardening — сетевой стек закрыт от типовых атак
12. Бэкапы — ежедневное резервное копирование висит в cron