alexoundos
/
articles
1
0
Fork 1
Code Issues Pull Requests Packages Projects Releases Wiki Activity

multiple instances of systemd service

nixos-config-re
Alexander Tomokhov 2023-06-21 20:46:57 +04:00
parent b9f083342d
commit 72758cbfab
1 changed files with 48 additions and 25 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

73
article.md
View File

@ -6,37 +6,19 @@ When it comes to security, we care about limiting access of each entity of a sys
Generally, it's better to implement as many layers of security as possible. Although, there is no way to make a server 100% bullet proof - it's a huge endless topic, this article covers some feasible essential `systemd` tunables that give us a layer of protection.
#While there are many areas of server protection, like keeping the running software up to date and respond to CVEs ([deploying software with patches is easy in NixOS](https://nixos.wiki/wiki/Overlays#Adding_patches) in case it hasn't been already patched), we will focus on `systemd` means (and a bit more, where `systemd` is not sophisticated enough).
Systemd is the standard software suite for organizing and running services/daemons in a modern GNU/Linux distribution, including NixOS. Systemd provides means to secure services. And in many ways, the isolation level of a systemd service can be similar to that of containers (by the means of namespaces, cgroups, etc; interestingly, [systemd even allows running](https://www.stevenrombauts.be/2019/01/run-multiple-instances-of-the-same-systemd-unit/) [multiple instances of the same service](https://opensource.com/article/20/12/multiple-service-instances-systemctl)). However, systemd hardening defaults are quite loose (perhaps, not to disturb the operation of newly written services and their administrators in any way).
Systemd is the standard software suite for organizing and running services/daemons in a modern GNU/Linux distribution, including NixOS.
Systemd provides means to secure services. And in many ways, the isolation level of a systemd service can be similar to that of containers (by the means of namespaces, cgroups, etc). However, systemd hardening defaults are quite loose (perhaps, not to disturb the operation of new services and their administrators in any way).
What NixOS does - it generates systemd configuration files in accordance to NixOS configuration given, written in Nix language. To some extent, Nix acts as a macro language and NixOS configuration module system acts as a unified control center, so that you don't bother about location of systemd files, their syntax and common stuff, which NixOS generates for you. Also NixOS manages runtime switching between systemd configurations, conducting services restarts when required and whole system rollbacks from GRUB/systemd-boot/extlinux.
### security principles and strategy
1. define desired security requirements
2. apply systemd hardening options, suggested by `systemd-analyze` (until they harm service functionality)
3. vulnerability scanning, penetration testing, and security audits
4. monitor and respond
## final notes
Systemd hardening is just a part of measures to be taken to narrow the potential threat landscape and risks for a server. Ideally, vulnerabilities scanning, penetration testing, unauthorized access prevention and security audits should be involved. Take advantage of monitoring tools and respond quickly, according to a rescue plan to mitigate the impact of incidents. Keep running software up to date and respond to CVEs ([deploying software with patches is easy in NixOS](https://nixos.wiki/wiki/Overlays#Adding_patches) in case it hasn't been already patched).
Have a rescue plan to mitigate the impact of incidents. This might include restoring system from backups, keys and passwords reset.
Business continuity plan.
In order for the actions (measures?) taken not to be ad-hoc, but rather systematic.
What NixOS does - it generates systemd configuration files in accordance to NixOS configuration given, written in Nix language. To some extent, Nix acts as a macro language and NixOS configuration module system acts as a unified control center, so that you don't bother about location of systemd files, their syntax and common stuff, which NixOS generates for you. Also, NixOS manages runtime switching between systemd configurations, conducting services restarts when required and whole system rollbacks from GRUB/systemd-boot/extlinux.
## overview of systemd integration within NixOS
NixOS features lots of systemd services, which are ready to use (without even knowing what systemd is) just by setting appropriate options in `configuration.nix`. For example, `services.netdata.enable = true`. Documentation for all related options can be found on the [website](https://search.nixos.org/options?channel=unstable&from=0&size=50&sort=relevance&type=packages&query=services.) or in `man configuration.nix` (also in `man home-configuration.nix` for [managing desktop](https://github.com/nix-community/home-manager) user services).
- configuring systemd service units in NixOS step by step (edit, rebuild (maybe in VM), `systemd status`, `systemd restart`, `systemd cat`, `htop` tree)
## resources limits strategy
## existing practices and solutions within NixOS
- https://nixos.wiki/wiki/Systemd_Hardening
- https://github.com/fort-nix/nix-bitcoin#security
- some explanation that there is no universal way: https://github.com/NixOS/nixpkgs/pull/87661#issuecomment-698945283
@ -62,6 +44,31 @@ NixOS already provides more or less isolation for many services, which are avail
## hardening in your own systemd services
You can manually test various systemd options without writing service files using `systemd-run`, for example:
```console
$ ls -l /home
total 0
drwx------ 1 alex users 1126 2023-06-21 19:26 alex
sudo systemd-run -p ProtectHome=yes --shell
Running as unit: run-u2544.service
Press ^] three times within 1s to disconnect TTY.
# ls -l /home
total 0
# exit
Finished with result: success
Main processes terminated with: code=exited/status=0
Service runtime: 2.749s
CPU time consumed: 50ms
IP traffic received: 0B
IP traffic sent: 0B
IO bytes read: 0B
IO bytes written: 0B
```
## blocking outgoing internet connections
The idea is to keep responding to incoming requests to some service, but forbid any outgoing connections, initiated by itself.
@ -87,6 +94,22 @@ networking.firewall = {
`confinement.enable` is not compatible with systemd's `ProtectSystem`.
## final notes
###security principles and strategy
#1. define desired security requirements
#2. apply systemd hardening options, suggested by `systemd-analyze` (until they harm service functionality)
#3. vulnerability scanning, penetration testing, and security audits
#4. monitor and respond
Systemd hardening is just a part of measures to be taken to narrow the potential threat landscape and risks for a server. Ideally, vulnerabilities scanning, penetration testing, unauthorized access prevention and security audits should be involved. Take advantage of monitoring tools and respond quickly, according to a rescue plan to mitigate the impact of incidents. Keep running software up to date and respond to CVEs ([deploying software with patches is easy in NixOS](https://nixos.wiki/wiki/Overlays#Adding_patches) in case it hasn't been already patched).
Have a rescue plan to mitigate the impact of incidents. This might include restoring system from backups, keys and passwords reset.
Business continuity plan.
In order for the actions (measures?) taken not to be ad-hoc, but rather systematic.
## related resources
- [discourse thread about systemd services hardening](https://discourse.nixos.org/t/hardening-systemd-services/17147)