Безопасность сервера с Ubuntu 24.04: доступ, аудит и контроль

Содержание

Завершаем цикл статей по безопасности Ubuntu 24.04. В финальной части — контроль прав доступа к критическим файлам, настройка двухфакторной аутентификации, системный аудит, ротация логов, резервное копирование и мониторинг состояния системы. Эти шаги помогут предотвратить утечки данных и обеспечить стабильную работу инфраструктуры.

Введение

Продолжаем наш чек-лист безопасности сервера на Ubuntu 24.04. В последней части — проверка прав на важные файлы и каталоги, настройка 2FA, аудит действий, логирование, резервное копирование и мониторинг.

Аренда VPS/VDS — от ₽219/месяц

Почему выбирают VPS от AdminVPS:

✓ Дешевле физического сервера

✓ Более гибкий и мощный, чем обычный хостинг

✓ Бесплатная защита от DDoS и техподдержка 24/7

✓ Масштабируется под любые задачи

Виртуальный сервер VPS/VDS — ваш личный сервер для сайтов, магазинов, ботов и других проектов.

Проверьте права на важные файлы

Файлы конфигурации, связанные с безопасностью и аутентификацией, должны иметь строгие права доступа. Иначе злоумышленник, получивший доступ к системе или уязвимому контейнеру, может использовать их для обхода защиты. Поэтому регулярно проверяйте права и владельцев ключевых системных файлов и при необходимости приводите их в порядок.

Начнём с одного из самых критичных файлов /etc/shadow. В нём хранятся зашифрованные пароли пользователей и информация о политике безопасности, касающейся паролей и учётных записей (сроки смены пароля, отключения учётной записи, если пароль недействителен и т. п.):

ls -l /etc/shadow

Ожидаемый результат:

-r-------- 1 root shadow ... /etc/shadow

Из-за своего содержимого файл должен быть доступен только root. Если у него выставлены более широкие права — это серьёзная уязвимость.

Для исправления прав:

sudo chown root:shadow /etc/shadow
sudo chmod 640 /etc/shadow

В некоторых системах используется более строгий вариант — но он подходит, только когда все процессы, которым нужно читать этот файл, работают от root:

sudo chmod 000 /etc/shadow

Далее проверьте права на ключи SSH. Каждый пользователь, использующий SSH-ключи, должен убедиться, что его .ssh/authorized_keys закрыт от посторонних:

ls -l ~/.ssh/authorized_keys

Правильные значения:

владелец — пользователь;
права — 600 (только для чтения и записи владельцем).

Если нужно исправить:

chmod 600 ~/.ssh/authorized_keys
chown $USER:$USER ~/.ssh/authorized_keys

Дополнительно проверьте права на сам каталог .ssh:

ls -ld ~/.ssh

Он должен принадлежать пользователю и иметь права 700.

Если вы управляете несколькими пользователями, проверьте права на домашние каталоги. Они не должны быть доступны другим пользователям:

ls -ld /home/*

Допустимые права — 750 или 700.

Выполните проверку и для следующих файлов:

/etc/passwd — должен быть доступен для чтения всеми (иначе сломается login, ls, who и т. п.), но только root может его изменять (644, владелец root);
/etc/ssh/sshd_config — 644, владелец root;
/var/log/auth.log — только для root (обычно 640, владелец root:adm).

Настройте двухфакторную аутентификацию (2FA) для SSH

В Ubuntu для настройки 2FA с одноразовым паролем (TOTP) можно использовать PAM-модуль libpam-google-authenticator. Он работает локально, не требует внешнего сервиса и совместим с любыми приложениями TOTP (например, Google Authenticator, FreeOTP, Authy, Aegis).

Когда нужна 2FA:

Сервер доступен из Интернета по SSH.
К серверу получают доступ несколько человек.
Требуются повышенные меры безопасности (например, есть доступ к базам данных, конфиденциальной информации).
Используются пароли для входа по SSH (даже при наличии ключей).
Были утеряны SSH-ключи или учётные данные.

Если сервер работает внутри изолированной инфраструктуры или доступ к нему ограничен VPN или jump-сервером, необходимость в 2FA ниже, но не исключена.

Убедитесь, что у вас есть альтернативный проверенный метод доступа и только после этого приступайте к настройке 2FA. Установите PAM-модуль:

sudo apt install libpam-google-authenticator

Затем от имени каждого пользователя, для которого вы хотите включить 2FA, выполните:

google-authenticator

Система задаст вопросы для настройки, рекомендуется:

разрешить создание TOTP-токенов;
отключить повторное использование токенов;
установить ограничение по времени (rate-limiting).

Вы получите QR-код, который нужно отсканировать в мобильном приложении.

Далее отредактируйте PAM-конфигурацию для SSH:

sudo nano /etc/pam.d/sshd

Добавьте (или раскомментируйте) строку:

auth required pam_google_authenticator.so

Включите 2FA в конфигурации SSH — в /etc/ssh/sshd_config должны быть заданы следующие параметры:

ChallengeResponseAuthentication yes
UsePAM yes

Если вы используете SSH-ключи и хотите использовать и ключ, и TOTP-код добавьте:

AuthenticationMethods publickey,keyboard-interactive

Перезапустите SSH:

sudo systemctl restart ssh

Теперь при подключении к серверу SSH сначала проверит ключ (или пароль), а затем запросит одноразовый код.

Важно
Заранее подготовьте альтернативный метод доступа, на случай если вы потеряете доступ к приложению — генератору кодов.

Включите аудит действий и настройте логи

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

Для аудита системных событий в Ubuntu используется демон auditd. Он записывает действия пользователей и процессов в лог-файл и позволяет настраивать подробные правила слежения за файлами, вызовами системных функций и изменениями настроек.

Установите его:

sudo apt install auditd

После установки служба стартует автоматически. Проверьте статус:

sudo systemctl status auditd

Основной конфигурационный файл для правил аудита — /etc/audit/audit.rules. В него можно добавить инструкции, какие действия логировать.

Примеры полезных правил логирования:

-w /etc/shadow -p wa -k shadow-watch   # доступ к /etc/shadow
-w /usr/bin/sudo -p x -k sudo-usage   # запуск команды sudo
-w /etc/passwd -p wa -k passwd-changes    # изменения в /etc/passwd
-w /etc/ssh/sshd_config -p wa -k ssh-config    # доступ к SSH-конфигурации

Расшифровка опций:

-w — путь к файлу или директории, за которыми нужно следить;
-p — действия:
- r — чтение,
- w — запись,
- a — добавление,
- x — выполнение;
-k — метка (ключ), по которой потом удобно фильтровать записи в журнале.

После внесения изменений примените правила:

sudo augenrules --load

Просмотреть логи можно по метке:

sudo ausearch -k shadow-watch

Или по дате:

sudo ausearch --start today --end now

Логи на сервере нужно не только собирать, но и вовремя архивировать и удалять — иначе они займут всё дисковое пространство. В Ubuntu для этого по умолчанию используются два механизма:

logrotate — для файлов в /var/log;
systemd-journald — для системного журнала.

Общие настройки logrotate хранится в /etc/logrotate.conf, а отдельные правила для пакетов — в /etc/logrotate.d/.

Пример настройки ротации логов auditd (обычно находится в /etc/logrotate.d/audit):

/var/log/audit/audit.log {
    daily
    rotate 7
    compress
    missingok
    notifempty
    create 0600 root root
    postrotate
        systemctl reload auditd > /dev/null
    endscript
}

Эти настройки:

создают новые файлы каждый день (daily);
хранят 7 архивных копий (rotate 7);
сжимают старые логи (compress);
пропускают пустые файлы (notifempty);
перезапускают auditd после ротации (postrotate).

Также настройте journald. Откройте файл:

/etc/systemd/journald.conf

Задайте ограничения по размеру, например:

SystemMaxUse=500M
SystemKeepFree=100M
SystemMaxFileSize=50M
MaxRetentionSec=1month

После изменения перезапустите journald.

Настройте резервное копирование и мониторинг

Чтобы избежать потери данных и быстро восстановить работоспособность системы в непредвиденной ситуации, нужно заранее подготовиться — настроить резервное копирование и мониторинг.

Резервное копирование

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

Рекомендуется:

Хранить резервные копии вне сервера, например в облаке или на отдельной машине.
Настроить автоматизацию, чтобы не зависеть от ручного запуска.
Защищать архивы с помощью шифрования.

Минимум, что нужно бекапить:

/etc/ — все системные конфигурации;
/home/ — пользовательские данные и SSH-ключи;
/var/www/ — сайты и приложения (если используются);
/var/lib/ — база данных и состояния сервисов (если нужно);
скрипты и инфраструктурные файлы (/opt, /usr/local/bin и т. д.).

Простой пример создания архива конфигураций:

sudo tar czf /root/backup-etc-$(date +%F).tar.gz -C / etc/

Для автоматизации можно использовать cron:

sudo crontab -e

Добавьте:

0 3 tar czf /root/backup-etc-$(date +\%F).tar.gz -C / etc/

Также можно использовать специализированные инструменты — BorgBackup, Restic, Duplicity, а для облачного хранения — скрипты с rclone, aws s3 или gdrive.

Мониторинг

Чтобы не узнавать о проблемах от пользователей, нужно заранее отслеживать метрики и события. Мониторинг может быть разного уровня: от простых графиков и алертов до полноценного анализа состояния системы.

Варианты инструментов:

Netdata — лёгкий агент с web-интерфейсом, даёт подробную визуализацию в реальном времени. Для его установки:

bash <(curl -Ss https://my-netdata.io/kickstart.sh)

Netdata автоматически собирает данные о CPU, памяти, сетевом трафике, логах, подключениях и многом другом.

Prometheus + Grafana — подходит для продакшен-инфраструктуры. В этой связке Prometheus собирает метрики, а Grafana отображает их на дашбордах. Установка и настройка требуют больше времени, но вы получите полноценную систему мониторинга с большим количеством функций.
Внешние сервисы:
- UptimeRobot — проверка доступности и алерты;
- Better Stack — логирование и мониторинг в одном;
- Pingdom, Datadog, Zabbix — для крупных систем с высокой нагрузкой.

Что обязательно нужно мониторить:

загрузку CPU, память и диск;
сетевые соединения и трафик;
статус сервисов (systemctl status);
попытки входа и неудачные логины (/var/log/auth.log);
обновления и перезапуски;
работоспособность ключевых API и веб-приложений.

Также стоит настроить оповещения — хотя бы через e-mail или Telegram-бота — чтобы не пропустить проблему.

Все три части чек-листа по безопасности сервера с Ubuntu 24.04 доступны по ссылкам:
Часть 1. Обновление системы, настройка доступа, SSH и UFW
Часть 2. Fail2ban, nftables и управление службами
Часть 3. Проверка прав, 2FA, аудит, логирование, бекап и мониторинг (данный материал)

Читайте в блоге:

Безопасность сервера с Ubuntu 24.04: проверка прав, 2FA, аудит, логирование, бекап и мониторинг