Базовый hardening Ubuntu Server после установки

Начните с назначения сервера и пути восстановления доступа

Hardening — это приведение системы к проверяемому baseline, а не последовательное отключение всего незнакомого. Зафиксируйте роль узла, владельца, критичные процессы, входящие и исходящие соединения, источники администрирования и зависимости: DNS, NTP, репозитории, каталог пользователей, мониторинг и резервное копирование. Без этого нельзя отличить лишний сервис от необходимого и оценить последствия ограничения сети.

До изменения удалённого доступа подтвердите работу консоли гипервизора, BMC или панели облачного провайдера. Проверьте, что аварийная учётная запись и процедура восстановления доступны не только на самом сервере. Текущую SSH-сессию держите открытой, а каждое изменение проверяйте из второй сессии. Это не заменяет откат, но позволяет исправить конфигурацию, если новый вход перестал работать.

Определите поддерживаемую версию Ubuntu и срок её сопровождения. Защитные настройки не компенсируют окончание обновлений. Для production также запишите окно обслуживания, допустимую перезагрузку и способ проверить приложение после неё. Снимок виртуальной машины может ускорить технический откат, но не является единственной резервной копией и не гарантирует согласованность данных приложения.

Установите обновления и контролируйте источники пакетов

Обновите индекс пакетов и изучите список доступных обновлений до установки. На новом сервере обычно разумно применить все обновления из утверждённых репозиториев, затем проверить необходимость перезагрузки. На работающей системе сначала оцените изменения ядра, библиотек и сервисов, которые будут перезапущены. Команда apt upgrade не отменяет проверки приложения и не должна бесконтрольно запускаться посреди рабочего дня.

Оставляйте только необходимые репозитории с проверяемым владельцем и ключом подписи. Сторонний install-скрипт, который добавляет репозиторий и выполняется от root, является частью цепочки поставки; его нужно изучать и фиксировать версию. Не отключайте проверку TLS или подписи пакетов ради устранения ошибки загрузки. Причиной могут быть неверное время, proxy, устаревший сертификат или неправильный ключ.

Автоматические security-обновления полезны, если организация отслеживает результат и учитывает перезапуски. Настройка unattended-upgrades должна соответствовать окну обслуживания и выбранным источникам. Для критичного сервиса определите, кто получает уведомление об ошибке и кто принимает решение о reboot. Пакеты, удерживаемые на старой версии, должны иметь причину и дату пересмотра.

• Используется поддерживаемый релиз Ubuntu.
• Каждый сторонний репозиторий имеет владельца и обоснование.
• Ошибки автоматического обновления попадают в мониторинг.
• После обновления проверяются службы и само приложение.

sudo apt update
apt list --upgradable
sudo apt upgrade
test -f /var/run/reboot-required && cat /var/run/reboot-required.pkgs
grep -R --no-filename '^deb ' /etc/apt/sources.list /etc/apt/sources.list.d/*.list 2>/dev/null

Разделите учётные записи и сократите привилегии

Для повседневного администрирования создайте отдельную именную учётную запись и выдайте sudo только тем, кому это необходимо. Общий логин не позволяет связать действие с человеком и усложняет отзыв доступа. Прямой удалённый вход root обычно не нужен: повышение привилегий через sudo оставляет дополнительный журнал и позволяет ограничивать команды, хотя сложные правила sudo тоже требуют тщательного тестирования.

Добавляя пользователя в группу sudo, убедитесь, что он может войти по ключу и выполнить требуемую команду до закрытия исходной сессии. Не копируйте приватные ключи между администраторами. Публичные ключи должны соответствовать конкретным людям или автоматизированным системам; устаревшие ключи удаляют по процессу offboarding. Для сервисов используйте отдельные системные учётные записи без интерактивного shell, если приложению он не нужен.

Проверьте права на домашние каталоги, конфигурацию и секреты. Рекурсивный chmod 777 не является исправлением доступа: он открывает запись всем локальным пользователям и процессам. Владельца, группу и минимальные разрешения выбирают по модели работы приложения. Секреты не следует хранить в shell history, unit-файлах с широким чтением или репозитории.

1. Создать именную учётную запись и задать только необходимые атрибуты.
2. Добавить проверенный публичный ключ в ~/.ssh/authorized_keys.
3. Выдать sudo через группу или отдельный файл в /etc/sudoers.d.
4. Проверить синтаксис visudo и вход во второй SSH-сессии.
5. Задокументировать владельца ключа и процедуру отзыва.

sudo adduser adminname
sudo usermod -aG sudo adminname
sudo -u adminname chmod 700 /home/adminname/.ssh
sudo -u adminname chmod 600 /home/adminname/.ssh/authorized_keys
sudo visudo -c

Укрепите SSH без самоблокировки

Сначала добейтесь стабильного входа по ключу, затем отключайте парольную аутентификацию. Настройки могут находиться не только в /etc/ssh/sshd_config, но и во включаемых файлах sshd_config.d; фактическую конфигурацию смотрите через sshd -T. Если используются Match-блоки, результат зависит от пользователя, адреса и других условий, поэтому проверяйте реальный сценарий входа.

Обычно baseline включает запрет прямого входа root, отключение пустых паролей и ограничение разрешённых пользователей или групп. Смена стандартного порта уменьшает фоновый шум в журналах, но не заменяет ключи, firewall и мониторинг. Не включайте устаревшие алгоритмы ради старого клиента без отдельного анализа: безопаснее обновить клиент или организовать контролируемый промежуточный доступ.

После редактирования выполните синтаксическую проверку. Reload предпочтительнее restart, когда достаточно перечитать конфигурацию, но даже корректный синтаксис не гарантирует, что выбранный ключ и сетевой путь работают. Откройте вторую сессию, выполните sudo и только после этого закрывайте исходную. При централизованной аутентификации отдельно проверьте локальную аварийную учётную запись.

sudo sshd -t
sudo sshd -T | grep -E 'passwordauthentication|permitrootlogin|pubkeyauthentication'
sudo systemctl reload ssh
sudo journalctl -u ssh --since '30 minutes ago'

Не вставляйте готовый sshd_config целиком: опции зависят от версии OpenSSH, облачного образа и механизма управления конфигурацией.

Ограничьте сеть и удалите ненужную поверхность

Перед включением firewall получите фактический список слушающих сокетов и сопоставьте каждый процесс с назначением сервера. Привязка к 127.0.0.1 или Unix socket предпочтительнее публикации административного интерфейса во внешнюю сеть, если приложение это поддерживает. Не забывайте IPv6: отключение или фильтрация только IPv4 может оставить неожиданный доступ по другому стеку.

UFW удобен как интерфейс к netfilter, но правила должны быть конкретными. Сначала разрешите SSH с административной сети, затем порты приложения и только после этого включайте firewall. Для облачного узла согласуйте host firewall с security group или сетевым ACL: два уровня фильтрации полезны, однако при расхождении правил усложняют диагностику.

Остановите и отключите службы, которые действительно не используются, а ненужные пакеты удалите после анализа зависимостей. Не следует механически отключать systemd-resolved, cloud-init, snapd или IPv6 по универсальному чек-листу: на конкретной платформе они могут обеспечивать DNS, первичную конфигурацию, обновление приложения или сетевую доступность. Решение фиксируют в baseline вместе с причиной.

• Каждый слушающий порт связан с известным сервисом.
• Административные интерфейсы ограничены доверенными адресами.
• Правила проверены и для IPv4, и для IPv6.
• Отключённые службы внесены в документацию конфигурации.

sudo ss -lntup
sudo ufw default deny incoming
sudo ufw default allow outgoing
sudo ufw allow from 192.0.2.0/24 to any port 22 proto tcp
sudo ufw enable
sudo ufw status verbose

Используйте AppArmor, безопасные параметры и журналирование

Ubuntu поставляет AppArmor для дополнительного ограничения процессов. Проверьте, что сервис активен, а профили критичных приложений находятся в enforce, если они совместимы с рабочей нагрузкой. Перевод профиля из complain в enforce выполняйте после наблюдения за легитимными операциями; слепое подавление deny-событий широкими правилами разрушает смысл контроля.

Параметры sysctl применяйте по модели угроз и сетевой роли. Универсальный файл из интернета может отключить маршрутизацию, нарушить контейнерную сеть или изменить поведение приложения. Для обычного узла разумно проверить source routing, redirects и форвардинг, но каждое значение сопоставляют с официальной документацией и тестируют. То же относится к параметрам монтирования noexec, nosuid и nodev: они полезны на подходящих файловых системах, но способны сломать установщик или сервис.

Журналы должны переживать локальный инцидент и попадать в мониторинг. Настройте контроль места, ротацию и, при необходимости, отправку на отдельный сервер. Проверяйте события SSH, sudo, systemd, AppArmor и unattended-upgrades. Fail2ban может временно блокировать источники повторных неудачных входов, но не заменяет отказ от паролей и сетевое ограничение; перед включением задайте исключения для доверенных систем и способ аварийной разблокировки.

sudo systemctl status apparmor --no-pager
sudo aa-status
sudo sysctl --system
sudo journalctl -p warning --since today
sudo journalctl --disk-usage

Проверьте результат и управляйте отклонениями

После изменений повторите проверку снаружи и изнутри. Из новой SSH-сессии подтвердите вход ключом, sudo и доступ к журналам. С разрешённых и запрещённых адресов проверьте сетевые порты, затем выполните функциональный smoke-тест приложения. Просмотрите failed units, последние ошибки ядра и сервисов, состояние firewall, AppArmor и обновлений. Перезагрузку, если она допустима, рассматривайте как отдельный тест сохранения конфигурации.

Сохраните baseline в системе управления конфигурацией или хотя бы в версионируемом документе без секретов. Ручная настройка постепенно расходится между серверами. Ansible, cloud-init или другой управляемый механизм делает изменения воспроизводимыми, но код автоматизации тоже тестируют на staging и проверяют на идемпотентность. Локальные исключения должны иметь владельца, обоснование и дату пересмотра.

Периодически сравнивайте систему с baseline: новые порты, пользователи, ключи, репозитории и отключённые защитные механизмы важнее разового отчёта после установки. Для формальной проверки можно адаптировать Ubuntu Security Guide или профиль CIS, но уровень соответствия не равен фактической безопасности. Контроль должен учитывать назначение узла и не превращаться в набор настроек, которые никто не способен поддерживать.

1. Проверить второй вход по SSH и повышение привилегий.
2. Сопоставить слушающие порты с разрешённым перечнем.
3. Запустить smoke-тест приложения и зависимостей.
4. Проверить failed units, журналы, AppArmor и обновления.
5. Зафиксировать baseline, исключения и ответственных.
6. Настроить регулярную проверку дрейфа конфигурации.