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

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

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

Введение

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

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

Преимущества VPS в AdminVPS:

✓ Бесплатное администрирование

✓ Только быстрые NVMe-диски

✓ Защита от DDoS-атак

✓ Быстрая техподдержка

Аренда VPS/VDS виртуального сервера от AdminVPS — это прозрачная и честная услуга с доступной ценой

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

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

Начнём с одного из самых критичных файлов /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 доступны по ссылкам:

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

Loading spinner
0 Комментарий
Старые
Новые Популярные
Межтекстовые Отзывы
Посмотреть все комментарии

VPN на VPS-сервере

Узнайте, как создать собственный VPN на VPS-сервере для защиты ваших конфиденциальных данных!

Что будем искать? Например,VPS-сервер

Мы в социальных сетях