1
0
Fork 0
articles/article.md

4.1 KiB

hardening of systemd services in NixOS

introduction, threat landscape and risks

Protection against outside threats: potential vulnerabilities and unauthorized access.
Generally it's better to implement as many layers of security as possible. Although, there is no way to make server 100% bullet proof - it's a huge endless topic, we can implement some feasible essential things that gives us a layer or protection.

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

Take advantage of monitoring tools. Have a rescue plan to mitigate the impact of incidents. This might include restoring system from backups, keys and passwords reset. Business continuity plan.

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).

In order for the actions (measures?) taken not to be ad-hoc, but rather systematic.

overview of systemd integration within NixOS

- 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

list of systemd options and their implications

cgroups

cgroup - control group. Docker's isolation implementation is also based on cgroups.

Enabling netdata service in NixOS enables systemd.enableCgroupAccounting, which in turn enables these options in systemd.conf:

DefaultCPUAccounting=yes
DefaultIOAccounting=yes
DefaultBlockIOAccounting=yes
DefaultIPAccounting=yes

hardening in available services provided by NixOS upstream

NixOS already provides more or less isolation for many services, which are available as services.NAME_OF_SERVICE options.

hardening in your own systemd services

blocking outgoing internet connections

The idea is to keep responding to incoming requests to some service, but forbid any outgoing connections, initiated by itself.

When it comes to a more sophisticated firewall, unfortunatelly systemd is not capable of such granular control. So, iptables configuration will be:

networking.firewall = {
  extraCommands = ''
    iptables -t filter -I OUTPUT 1 -m owner --uid-owner ${user} -m state --state NEW -j REJECT
  '';
  extraStopCommands = ''
    iptables -t filter -D OUTPUT 1 -m owner --uid-owner ${user} -m state --state NEW
  '';
};

testing

example-systemd-service.nix features a way to run a shell inside a systemd service in order to test our isolation in practice. You can just add path to the file to the imports list in configuration.nix and execute nixos-rebuild switch or nixos-rebuild test (if you don't want new configuration to be permanent; however, it creates ./result symbolic link in current directory).

unsolved problems

confinement.enable is not compatible with systemd's ProtectSystem.