Защита Linux-сервера: доступ, политики и проверяемые ограничения

Автор: Казачкин Даниил Михайлович · Обновлено 9 октября 2026 г.

Защиту сервера проверяют через доступные операции: кто может войти, какие службы слушают сеть, где лежат секреты и что останется в журнале после изменения. Выполняйте изменения на учебной VM с консолью и снимком. Удалённый SSH-сеанс нельзя считать единственным способом восстановления доступа.

Итоговый SSH-конфиг важнее одного файла

Сначала проверьте вход по ключу обычного администратора в новом сеансе и работу разрешённого sudo. Затем подготовьте ограничения сервера:

PermitRootLogin no
PubkeyAuthentication yes
PasswordAuthentication no
KbdInteractiveAuthentication no

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

sudo sshd -t
sudo sshd -T -C user=deploy,addr=192.0.2.10,host=client.example \
  | grep -E 'passwordauthentication|kbdinteractiveauthentication|permitrootlogin'

192.0.2.10 здесь пример, его заменяют адресом проверяемого клиента. Если PasswordAuthentication остаётся yes, исследуйте порядок Include, Match и конфигурацию запуска службы. В Ubuntu имя службы часто ssh, в других системах sshd; выясните его перед reload. После перечитывания откройте ещё одно соединение. Только успешный новый вход подтверждает сохранённый доступ. Правила sshd_config.

Блокировка перебора и обновления

Для Fail2ban создайте отдельный файл jail.d с секцией sshd, enabled=true, maxretry=5, findtime=10m и bantime=1h. Backend и источник журнала выбирают под дистрибутив: наличие systemd не означает, что подходит любой файл auth.log. fail2ban-client -t проверяет конфигурацию; fail2ban-client status sshd показывает работу jail и список блокировок. После установления причины ошибочный бан снимают fail2ban-client set sshd unbanip 192.0.2.10 на своей VM. Не проверяйте защиту перебором паролей на чужом сервере. Fail2ban дополняет ключи и firewall, но не заменяет их.

В Ubuntu пакет unattended-upgrades выбирает разрешённые источники обновлений. Изучите конфигурацию APT, затем выполните sudo unattended-upgrade --dry-run --debug и проверьте таймеры apt-daily*. Режим dry-run показывает план, но обновления проверяют отдельно в согласованное окно. Автоматический reboot требует отдельного решения: установка исправленного ядра не означает, что оно уже работает. Сопоставьте /var/run/reboot-required, uname -r и установленную версию. Документация Ubuntu.

Когда обычных прав недостаточно

При Permission denied сначала проверьте весь путь через namei -l, группы процесса и опции монтирования. Затем исследуйте обязательные политики. Для SELinux полезны getenforce, ls -Z и ausearch -m AVC -ts recent. Если файл перемещён и получил неверный контекст, настройте постоянное соответствие пути через semanage fcontext и восстановите метку restorecon. Тип выбирают по назначению службы, а не копируют из случайного примера.

В AppArmor aa-status показывает загруженные профили; сообщения DENIED в журнале указывают профиль, операцию и путь. Доступ к /srv/app/data может требовать правила именно в профиле приложения. Переход всех политик в permissive или complain скрывает нарушение и не является исправлением. Проверьте минимальное изменение на одной операции и верните enforcing. AppArmor.

Кто изменил файл

Для отдельного файла учебного приложения можно установить правило auditd:

sudo auditctl -a always,exit -F arch=b64 \
  -F path=/srv/lab/app.conf -F perm=wa -k lab_config
sudo ausearch -k lab_config -i

Файл должен существовать; архитектуру правила выбирают под систему и исполняемые программы. Постоянные правила находятся в audit/rules.d и требуют штатного применения. В событии сопоставьте время, exe, uid и auid: текущий UID процесса и исходная login-идентичность отвечают на разные вопросы. Аудит собирает будущие события, он не восстанавливает историю до установки правила. lynis audit system помогает составить перечень проверок; его рекомендации оценивают в контексте службы, а итоговый балл не доказывает безопасность.

Шифрование и секреты

LUKS защищает данные выключенного или заблокированного тома; после открытия приложения видят обычные файлы. Храните проверенную резервную копию заголовка и ключевого материала отдельно. Потеря ключей не исправляется сменой пароля Linux. Для отдельного учебного файла попробуйте интерактивное gpg --symmetric note.txt, затем gpg --output restored.txt --decrypt note.txt.gpg и cmp note.txt restored.txt. Пароль вводится через pinentry; восстановление проверяется до удаления оригинала.

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

Практическая проверка: сохраните эффективные SSH-настройки, результат нового входа, состояние Fail2ban и один разобранный отказ политики. Объясните, какие наблюдения подтверждают работу каждого ограничения. К настройке сайта переходите в [сценарии сервера](/lessons/without-university/linux-developer-foundations/linux-developer-50).

Случайную строку для учебного примера можно получить через openssl rand -base64 24: это кодировка 24 криптографически случайных байтов, а не обещание выполнить любую политику паролей. Base64 может содержать +, / и завершающий =; требования конкретного сервиса проверяют отдельно. Не используйте вывод демонстрации как опубликованный настоящий секрет и не сохраняйте его в протокол проверки.

Генератор случайных байтов OpenSSL описывает формат и ошибки этой команды.