Auf dem Server, auf dem ich dieses Blog hoste, ist auch ein Minecraftserver. Tatsächlich war der Minecraftserver zuerst da. Es lief zwar auch standardmäßig ein Webserver (Apache), aber den habe ich kaum genutzt. Nun ist Minecraft in erster Linie ein Spiel, und Computerspielentwickler sind nicht unbedingt bekannt dafür, einen security-first-Ansatz zu verfolgen. Kann jemand meinen Minecraft-Server als Einfallstor für meinen Server nutzen?
Nun, Minecraft ist ein sehr verbreitetes Spiel. Es bietet daher ein lohnendes Ziel für weit verbreitete, automatische Angriffe. Bei der Größe und Popularität kann man aber auch erwarten, dass ein bisschen mehr Wert auf Security gelegt wird. Und es steht ein Milliardenschwerer Konzern hinter Minecraft.
Dummerweise ist dieser Konzern Microsoft, und selbst wenn die Entwickler alles richtig machen, kann immer noch eine weit verbreitete Bibliothek wie log4j mit einer Sicherheitslücke allem einen Strich durch die Rechnung machen. Es ist schon einmal passiert, es kann wieder passieren. Ein paar zusätzliche Sicherheitsvorkehrungen wären nicht schlecht.
Bei solchem „Security-Hardening“ geht man ungefähr so vor, wie ein CDU-Politiker, wenn es um Sicherheit geht: Möglichst viele Rechte einschränken. Wenn es dann eine Sicherheitslücke in einem Programm gibt, dann hat der Angreifer wesentlich weniger Optionen, Schaden anzurichten. Grundlegende Maßnahmen in der Richtung habe ich schon getroffen (z.B. läuft der Server mit einem eigenen User), aber da geht noch mehr. Viel mehr.
Auf diesem (Debian-)System läuft SystemD als init-Prozess und bei allem Negativen, was man über Systemd sagen könnte: Selber einen Daemon zu konfigurieren ist ziemlich einfach. Und Systemd bietet einen Haufen Optionen, Rechte von Daemonen einzuschränken. Für den Anfang habe ich mich mal an diesen Post zu SystemD Service Hardening gehalten. Das ist eine schöne Einführung, in denen auch die Flags erklärt werden. Außerdem habe ich diesen speziellen Post für eine Minecraft-Systemd-Konfiguration angeschaut, damit ich weniger herumexperimentieren musste, was Minecraft braucht und was nicht.
Hier ist der Ausschnitt aus meiner minecraft_otherland.service-Datei, der die Rechte einschränkt:
ProtectHome=yes
ProtectSystem=strict
PrivateTmp=yes
PrivateDevices=yes
ReadWritePaths=/var/minecraft_otherland
NoExecPaths=/
ExecPaths=/usr/bin -/usr/lib -/usr/lib64 -/usr/libexec
ProtectKernelLogs=yes
ProtectKernelModules=yes
ProtectSystem=full
ProtectClock=yes
ProtectHostname=yes
ProtectKernelTunables=yes
RestrictSUIDSGID=yes
UMask=0077
LockPersonality=yes
RestrictRealtime=yes
RestrictAddressFamilies=AF_INET AF_INET6 AF_UNIX
RestrictIPC=yes
RestrictNamespaces=yes
CapabilityBoundingSet=~CAP_SETUID CAP_SETPCAP
SystemCallArchitectures=native
NoNewPrivileges=yes
ProtectProc=invisible
PrivateUsers=yes
PrivateMounts=yes
SystemCallFilter=@system-service
CapabilityBoundingSet=
Ich gehe da jetzt nicht im Detail drüber, lest die Artikel bzw. sucht im Netz nach den einzelnen Optionen. Nur so viel: Der Daemon darf praktisch nur nach /var/minecraft_otherland schreiben (wobei die server.jar root gehört und nicht beschrieben werden darf). Er hat einen Haufen Einschränkungen und Abschottungen zu anderen Prozessen. Und ich war erfreut zu sehen, dass ich ohne spezielle Capabilities ausgekommen bin, daher CapabilityBoundingSet=. Einziges Problem: MemoryDenyWriteExecute=yes konnte ich nicht setzen, weil Minecraft in Java geschrieben ist und anscheinend irgendwelche JIT-Sachen macht oder so.
Ich habe das auch soweit getestet: Server gestartet, mich mit einem Client eingelogged, ein paar Sachen verändert, überprüft, dass alles lief. Das ging soweit gut. Gründlich getestet habe ich das aber bisher nicht.
Was steht als nächstes an? Nginx sollte sicher genug sein, aber man weiß ja nie. Nur muss ich hier aufpassen, denn nginx hat vielleicht noch einen ganzen Haufen anderer Rechte, die es benötigt, also muss ich vorsichtig sein. Und natürlich Nextcloud. Nextcloud läuft in irgendeinem PHP-Daemon, der vermutlich separat konfiguriert ist. Meiner groben Einschätzung nach ist Nextcloud vermutlich neben Minecraft das wahrscheinlichste Einfallstor. Nextcloud nutzt außerdem eine Datenbank, wenn Nextcloud übernommen wurde, sollte die Datenbank nicht der Weg zum Rest des Systems sein. Also die Datenbank auch absichern.
Und natürlich SSH. Aber da muss ich wirklich, wirklich vorsichtig sein, sonst sperre ich mich aus meinem eigenen Server aus und muss bei meinem Hoster anfragen, um wieder Zugriff zu bekommen (was vermutlich Geld kostet).
Bis jetzt bin ich froh, dass ich zumindes den Minecraft-Server endlich abgesichert habe. Ich hatte das schon länger vor, bin aber jetzt erst dazu gekommen, das mal durchzuziehen.