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

some kind of an introduction

nixos-config-re
Alexander Tomokhov 2023-06-20 23:11:48 +04:00
parent 8e24d268fd
commit 338565a1fa
1 changed files with 29 additions and 8 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

37
article.md
View File

@ -1,20 +1,39 @@
# 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.
## introduction
When it comes to security, we care about limiting access of each entity of a system to as few other entities as possible. Network input, executables and users must be able to reach only those resources, which are necessary to perform the defined server tasks.
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, this article will cover some feasible essential things that give us a layer of protection.
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
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).
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.
## final notes
#Protection against outside threats: potential vulnerabilities and unauthorized access.
Systemd hardening is just a part of measures to be taken to narrow the potential threat landscape and risks.
Ideally, vulnerability scanning, penetration testing 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.
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)
@ -29,7 +48,7 @@ Business continuity plan.
## cgroups
`cgroup` - control group.
[`cgroup`](https://en.wikipedia.org/wiki/Cgroups) - 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`](https://github.com/NixOS/nixpkgs/blob/c223f49e6d4b4684286b8d2f9b2325930a4f62ff/nixos/modules/system/boot/systemd.nix#L493):
@ -51,6 +70,7 @@ NixOS already provides more or less isolation for many services, which are avail
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:
```nix
networking.firewall = {
extraCommands = ''
@ -76,4 +96,5 @@ networking.firewall = {
- [systemd.resource-control man page](https://www.freedesktop.org/software/systemd/man/systemd.resource-control.html)
- [systemd.exec - execution environment configuration](https://www.freedesktop.org/software/systemd/man/systemd.resource-control.html)
- [NixOS systemd hardening wiki page](https://nixos.wiki/wiki/Systemd_Hardening)
- https://nixos.wiki/wiki/Security
- [security in NixOS overview wiki page](https://nixos.wiki/wiki/Security)
- [utility for validating nix store for packages affected by vulnerabilities](https://github.com/nix-community/vulnix)