Как защитить Linux-сервис от чтения чужих файлов через systemd

👋 Приветствую в мире цифровой безопасности!

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

⏺Если в приложении найдут RCE, этим доступом смогут воспользоваться. У systemd есть встроенные механизмы, позволяющие сильно ограничить файловую систему для конкретного сервиса.

⏺Для начала посмотрим, насколько защищён сервис. У systemd есть собственный анализатор настроек безопасности:

systemd-analyze security nginx.service

Он покажет список ограничений и оценку доступных процессу возможностей. Чем выше exposure score, тем больше потенциальная поверхность атаки. Но это оценка конфигурации, а не проверка реальных уязвимостей.

⏺Закроем доступ к домашним каталогам. В конфигурации сервиса можно добавить:

[Service]
ProtectHome=true
ProtectSystem=strict
PrivateTmp=true

ProtectHome скрывает /home, /root и /run/user, ProtectSystem делает почти всю файловую систему доступной только для чтения, а PrivateTmp выделяет процессу отдельные временные каталоги.

⏺А куда тогда записывать данные? Вместо открытия доступа ко всей файловой системе разрешим только нужный каталог:

[Service]
StateDirectory=myapp
RuntimeDirectory=myapp

systemd создаст /var/lib/myapp и /run/myapp и обеспечит сервису возможность записи в них даже при ProtectSystem=strict.

⏺Ограничим доступ к устройствам и ядру. Большинству обычных веб-приложений не нужны управление модулями ядра, изменение системных параметров и прямой доступ к оборудованию:

[Service]
PrivateDevices=true
ProtectKernelTunables=true
ProtectKernelModules=true
ProtectControlGroups=true
NoNewPrivileges=true

Эти настройки сокращают возможности процесса, если атакующему удастся выполнить в нём свой код.

⏺Применяем настройки через override, не редактируя исходный unit-файл:

sudo systemctl edit myapp.service

Добавляем параметры в секцию [Service], затем проверяем и перезапускаем:

sudo systemctl daemon-reload
sudo systemctl restart myapp.service
sudo systemctl status myapp.service

Если приложение перестало работать, смотрим ошибки:

journalctl -u myapp.service -n 50

И повторно проверяем ограничения:

systemd-analyze security myapp.service

Такая изоляция не заменяет контейнеры и исправление уязвимостей, зато позволяет ограничить последствия компрометации обычного Linux-сервиса без Docker и дополнительных инструментов.

🤖Бесплатный ChatGPT