Пост канала
- фото
Как защитить 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
Открыть в MAX- Просмотры
- 419
- ER
- 0,2%
- Реакции
- 1