Linux härten: ntp sicher konfigurieren auf MX Linux 23.2

Betriebssysteme
1

Hallo zusammen,

(Tut mir leid wenn mein Deutsch ein wenig seltsam wirkt, Ich bin kein Deutscher.)

Vielleicht eine dumme Frage, aber wie kann Ich NTP so konfigurieren, damit sie nur auf dem localhost bzw. der IP-Adresse 127.0.0.1 lauscht? und für andere Rechner im gleichen Netzwerk somit nicht erreichbar sind. Linux Härten teil 2

Terminal wenn Ich $ ss -tulpn | grep :123 eingebe:

udp   UNCONN 0      0          127.0.0.1:123        0.0.0.0:*          
udp   UNCONN 0      0            0.0.0.0:123        0.0.0.0:*          
udp   UNCONN 0      0              [::1]:123           [::]:*          
udp   UNCONN 0      0               [::]:123           [::]:*

ntp.conf:

# /etc/ntpsec/ntp.conf, configuration for ntpd; see ntp.conf(5) for help

driftfile /var/lib/ntpsec/ntp.drift
leapfile /usr/share/zoneinfo/leap-seconds.list

# To enable Network Time Security support as a server, obtain a certificate
# (e.g. with Let's Encrypt), configure the paths below, and uncomment:
# nts cert CERT_FILE
# nts key KEY_FILE
# nts enable

# You must create /var/log/ntpsec (owned by ntpsec:ntpsec) to enable logging.
#statsdir /var/log/ntpsec/
#statistics loopstats peerstats clockstats
#filegen loopstats file loopstats type day enable
#filegen peerstats file peerstats type day enable
#filegen clockstats file clockstats type day enable

# This should be maxclock 7, but the pool entries count towards maxclock.
tos maxclock 11

# Comment this out if you have a refclock and want it to be able to discipline
# the clock by itself (e.g. if the system is not connected to the network).
tos minclock 4 minsane 3

# Specify one or more NTP servers.

# Public NTP servers supporting Network Time Security:
# server time.cloudflare.com nts

# pool.ntp.org maps to about 1000 low-stratum NTP servers.  Your server will
# pick a different set every time it starts up.  Please consider joining the
# pool: <https://www.pool.ntp.org/join.html>
pool 0.debian.pool.ntp.org iburst
pool 1.debian.pool.ntp.org iburst
pool 2.debian.pool.ntp.org iburst
pool 3.debian.pool.ntp.org iburst

# Access control configuration; see /usr/share/doc/ntpsec-doc/html/accopt.html
# for details.
#
# Note that "restrict" applies to both servers and clients, so a configuration
# that might be intended to block requests from certain clients could also end
# up blocking replies from your own upstream servers.

# By default, exchange time with everybody, but don't allow configuration.
restrict default kod nomodify nopeer noquery limited

# Local users may interrogate the ntp server more closely.
restrict 127.0.0.1
restrict ::1

Danke!

2

Mithilfe der manpage konnte Ich nur die Option interface finden:

interface [listen | ignore | drop] [all | ipv4 | ipv6 | wildcard | name | address[/prefixlen]]
This command controls which network addresses ntpd opens, and whether the input is dropped without processing. The first parameter determines the
action on addresses which match the second parameter. That parameter specifies a class of addresses, or a specific interface name, or an address. In
the address case, prefixlen determines how many bits must match for this rule to apply. ignore prevents opening matching addresses, drop causes ntpd to
open the address and drop all received packets without examination. Multiple interface commands can be used. The last rule which matches a particular
address determines the action for it. interface commands are disabled if any of the -I, --interface,-L, or --novirtualips command-line options are
used. If none of those options are used, and no interface actions are specified in the >configuration file, all available network addresses are opened.
The nic command is an alias for interface.

Das klingt erstmal nach einer Lösung für dein Problem, aber:
trotz der folgenden Option öffnete ntp(sec) weiterhin den Port 123 auf localhost (127.0.0.1 & [::1]) und „allem“ (0.0.0.0 & [::]). Ich schätze, das ist fest eingebaut.

interface ignore all

Das ist aber kein Problem, da du am Log (nach dem journalctl Befehl im Beispiel gleich) erkennen solltest, wenn diese Option gesetzt ist, dass die Pakete unter der Wildcard (0.0.0.0 & [::]) dort sofort verworfen werden (Listen and drop).

Ohne Option:

$ ss -nlup | grep :123
udp   UNCONN 0      0         192.168.152.1:123        0.0.0.0:*    users:(("ntpd",pid=3707,fd=20))       
udp   UNCONN 0      0      192.168.178.15:123        0.0.0.0:*    users:(("ntpd",pid=3707,fd=19))       
udp   UNCONN 0      0           127.0.0.1:123        0.0.0.0:*    users:(("ntpd",pid=3707,fd=18))       
udp   UNCONN 0      0             0.0.0.0:123        0.0.0.0:*    users:(("ntpd",pid=3707,fd=17))       
udp   UNCONN 0      0               [::1]:123           [::]:*    users:(("ntpd",pid=3707,fd=21))       
udp   UNCONN 0      0                [::]:123           [::]:*    users:(("ntpd",pid=3707,fd=16))

$ journalctl -xe | grep -i ntp.*listen
Apr 03 00:25:21 host ntpd[3707]: IO: Listen and drop on 0 v6wildcard [::]:123
Apr 03 00:25:21 host ntpd[3707]: IO: Listen and drop on 1 v4wildcard 0.0.0.0:123
Apr 03 00:25:21 host ntpd[3707]: IO: Listen normally on 2 lo 127.0.0.1:123
Apr 03 00:25:21 host ntpd[3707]: IO: Listen normally on 3 enp2s0 192.168.178.15:123
Apr 03 00:25:21 host ntpd[3707]: IO: Listen normally on 4 wg0 192.168.152.1:123
Apr 03 00:25:21 host ntpd[3707]: IO: Listen normally on 5 lo [::1]:123
Apr 03 00:25:21 host ntpd[3707]: IO: Listening on routing socket on fd #22 for interface updates

Mit Option:

$ ss -nlup | grep :123
UNCONN 0      0           127.0.0.1:123        0.0.0.0:*    users:(("ntpd",pid=3800,fd=18))   
UNCONN 0      0             0.0.0.0:123        0.0.0.0:*    users:(("ntpd",pid=3800,fd=17))   
UNCONN 0      0               [::1]:123           [::]:*    users:(("ntpd",pid=3800,fd=19))   
UNCONN 0      0                [::]:123           [::]:*    users:(("ntpd",pid=3800,fd=16))

$ journalctl -xe | grep -i ntp.*listen
Apr 03 00:30:33 host ntpd[3800]: IO: Listen and drop on 0 v6wildcard [::]:123
Apr 03 00:30:33 host ntpd[3800]: IO: Listen and drop on 1 v4wildcard 0.0.0.0:123
Apr 03 00:30:33 host ntpd[3800]: IO: Listen normally on 2 lo 127.0.0.1:123
Apr 03 00:30:33 host ntpd[3800]: IO: Listen normally on 3 lo [::1]:123
Apr 03 00:30:33 host ntpd[3800]: IO: Listening on routing socket on fd #20 for interface updates
3

Danke. Wenn Ich

journalctl -xe | grep -i ntp.*listen

eingebe, bekomme Ich den Fehler: No journal files found. Ich muss erst weiter recherchieren wie Ich das lösen kann.

4

Um nochmal auf das Thema zurückzukommen:
Ich fürchte, mein Konfigurationsvorschlag macht die Zeitsynchronisation mit anderen NTP-Servern kaputt.

Wenn man interface ignore all verwendet, müsste man ebenfalls einstellen, dass auf der Netzschnittstelle/IP, über die eine Verbindung in das Internet hergestellt wird, gelauscht wird, um die NTP Pakete auf Port 123 von den Servern zurück zu bekommen.
Das ginge zum Beispiel dann über ein nachfolgendes interface listen 192.168.178.2/32, wo der Teil vor dem /32 die eigene IP-Adresse ist. Falls das aber die einzige Netzwerkschnittstelle des Gerätes ist, kann man beides gleich weglassen.
Eigentlich offensichtlich, da es UDP ist, ist mir zum Zeitpunkt des Beitrages aber entfallen.

Schlussfolgernd wird ntp(sec) bei dir immer lauschen, wenn Zeitserver im Internet verwendet werden sollen. Wenn das unerwünscht ist, wären deine Optionen andere Software zur Zeitsynchronisation (systemd-timesyncd, eventuell „chrony“) zu verwenden, oder diese über sntp (falls kein NTS (Wikipedia: EN - DE) erwünscht ist) innerhalb eines cron-Skriptes zu machen, und den NTP-Daemon ganz abzuschalten.

Ansich ist der NTP-Daemon aber bereits durch deine gepostete Konfiguration „abgesichert“: Durch die „Access control configuration“. Mehr geht mit der Software alleine nicht.

Eventuell verwendet MX Linux einen anderen Syslog-Daemon, dann wird journalctl nicht funktionieren.
Systemd’s journald könnte aber eventuell auch von dir oder MX so konfiguriert worden sein, dass es keine Logdateien anlegt?
Die Einstellungen dafür - falls der Prozess systemd-journald läuft - befinden sich in der Datei /etc/systemd/journald.conf oder in einer Datei mit der Endung .conf im Verzeichnis /etc/systemd/journald.conf.d, und lässt sich mit folgender Option einstellen:

[Journal]
#Storage=auto

Falls die Logs nur während der Laufzeit des Systems im Arbeitsspeicher gespeichert werden sollen, kannst du dort Storage=volatile eintragen, ohne führende #:

[Journal]
Storage=volatile

Am besten in einer Datei mit der Endung .conf im journald.conf.d Verzeichnis.

5

Danke. Bei MX Linux gibt es etc/systemd journald.conf und auch timesyncd.conf

Journald.conf ab jetzt, aber macht kein Unteschied, auch wenn Ich #Storage=auto auskommentiere:

#  This file is part of systemd.
#
#  systemd is free software; you can redistribute it and/or modify it
#  under the terms of the GNU Lesser General Public License as published by
#  the Free Software Foundation; either version 2.1 of the License, or
#  (at your option) any later version.
#
# Entries in this file show the compile time defaults.
# You can change settings by editing this file.
# Defaults can be restored by simply deleting this file.
#
# See journald.conf(5) for details.

[Journal]
#Storage=auto
Storage=volatile
#Compress=yes
#Seal=yes
#SplitMode=uid
#SyncIntervalSec=5m
#RateLimitIntervalSec=30s
#RateLimitBurst=10000
#SystemMaxUse=
#SystemKeepFree=
#SystemMaxFileSize=
#SystemMaxFiles=100
#RuntimeMaxUse=
#RuntimeKeepFree=
#RuntimeMaxFileSize=
#RuntimeMaxFiles=100
#MaxRetentionSec=
#MaxFileSec=1month
#ForwardToSyslog=yes
#ForwardToKMsg=no
#ForwardToConsole=no
#ForwardToWall=yes
#TTYPath=/dev/console
#MaxLevelStore=debug
#MaxLevelSyslog=debug
#MaxLevelKMsg=notice
#MaxLevelConsole=info
#MaxLevelWall=emerg
#LineMax=48K
#ReadKMsg=yes

Timesyncd:

#  This file is part of systemd.
#
#  systemd is free software; you can redistribute it and/or modify it
#  under the terms of the GNU Lesser General Public License as published by
#  the Free Software Foundation; either version 2.1 of the License, or
#  (at your option) any later version.
#
# Entries in this file show the compile time defaults.
# You can change settings by editing this file.
# Defaults can be restored by simply deleting this file.
#
# See timesyncd.conf(5) for details.

[Time]
#NTP=
#FallbackNTP=0.debian.pool.ntp.org 1.debian.pool.ntp.org 2.debian.pool.ntp.org 3.debian.pool.ntp.org
#RootDistanceMaxSec=5
#PollIntervalMinSec=32
#PollIntervalMaxSec=2048

Und /usr/share/doc/ntpsec-doc/html/accopt.html gibt es nicht.

6

Nach der Änderung sollte nach einen Neustart des systemd-journald Dienstes die Konfiguration neu geladen werden:
systemctl restart systemd-journald
Falls das Journal nun angelegt wird (journalctl -xe liefert eine Ausgabe), würden neue Log-Einträge von NTP darin landen.

Die relevanten Einträge sind aber die ab dessen start, entsprechend fehlt, sofern das Journal funktioniert, noch ein Neustart des NTP Dienstes: systemctl restart ntpsec
Aber anhand deiner bisherigen Konfigurationsdatei hätte bereits ein Journal angelegt werden müssen, da die Storage= Option bereits auskommentiert (#) ist, und der Default wert „auto“ eigentlich ein dauerhaftes Journal anlegt - es sei denn, es gibt Dateien im Ordner /etc/systemd/journald.conf.d

Leider habe Ich kein MX Installiert, sondern Debian. Deswegen kann Ich nicht selber nachschauen, wie das System standardmäßig Konfiguriert ist, und ob eventuell entgegen meiner Erwartungen ein anderer Syslog-Daemon verwendet wird, entschuldige.

Die Konfiguration von timesyncd ist Egal, sofern es nicht läuft oder installiert ist, es sei denn, du möchtest ntpsec durch systemds „timesyncd“ ersetzen.

Falls es nicht dein Ziel ist, einen NTP Server in deinen Netzwerk zu haben (mit dem du die Zeit anderer Computer synchronisieren kannst), und / oder die Zeitsynchronisation mithilfe von „NTS“ zu verschlüsseln, und so vor Manipulation zu schützen, wäre ein Wechsel darauf vermutlich eine Option für dich.

Das sollte in etwa so einfach sein wie: apt remove ntpsec und apt install systemd-timesyncd oder systemctl enable timesynd (beide zu verwenden wäre auch okay).
Eigene Server kannst du dort Eintragen indem du vor NTP= die # entfernst, und die eigenen danach einträgst - getrennt durch Leerzeichen. Ansonsten werden die unter FallbackNTP gelisteten standardmäßig verwendet.
Wenn Ich mich recht erinnere, lauscht diese Software nicht dauerhaft auf den UDP Port 123, wobei Ich das Risiko dadurch bei NTPSEC als nicht hoch einschätze.

Bei mir ebenfalls nicht, sie findet sich aber online:
https://docs.ntpsec.org/latest/accopt.html#restrict
Die Dokumentation dieser Option für die aktuellste Version sollte auch für die von MX verwendete Version stimmen.
Hier ist auch das Handbuch, welches darauf verlinkt https://docs.ntpsec.org/latest/access.html

7

Es gibt wieder einen neuen Fehler nach systemctl restart systemd-journald

System has not been booted with systemd as init system (PID 1). Can’t operate. Failed to connect to bus: host is inactive.

Vielleicht ist wie Du schreibst timesyncd eine Möglichkeit. Werde wenn Ich morgen mehr Zeit habe, mal wieder weiter recherchieren. Wenn es jetzt schon so schwierig ist, nur NTP sicher zu konfigurieren, wie lange dauert es dann bis Ich als Laie Linux abgehartet habe? :wink:

8

Okay, MX Linux verwendet nicht Systemd, und höchstwahrscheinlich auch nicht systemds journald. Das ist mir entgangen. Timesyncd erscheint mir dann auch nicht wie die richtige Option zur Zeitsynchronisation. Storage=volatile kannst du also ohne Bedenken wieder entfernen.

In den Fall müsste der Systemlog eigentlich in der Datei /var/log/syslog sein.
Falls das Format der Logeinträge das gleiche ist, würden die relevanten Einträge wohl so ausgelesen werden können:
grep -i "ntp.*listen" /var/log/syslog
(als Root oder mithilfe von Sudo ausgeführt, das habe Ich vorher nicht erwähnt)

Nun zu deinen eigentlichen Problem: Ich habe mir das Softwarepaket jetzt mal im Detail genauer angeschaut.
Ansich ist dein ntp-daemon „sicher“ konfiguriert. Dazu ist er per Apparmor in seinen Möglichkeiten eingeschränkt, wird unter seinen eigenen Benutzer ausgeführt, und ist explizit darauf ausgelegt, Pakete aus dem Internet zu empfangen, und zu verarbeiten.

Du kannst Ihn zwar so konfigurieren, dass er nicht von „außen“, oder dem Heimnetzwerk, aus erreichbar ist, also nicht auf den per ss angezeigten Ports lauscht, aber dann kann er sich nicht mit Zeitservern im Internet synchronisieren.
Das wäre eine erwünschte Konfiguration falls du Lokal einen GPS Empfänger o.Ä. zur Zeitsynchronisation nutzen würdest, welchen du auch in der ntp.conf konfigurieren müsstest, was aber nicht der Fall ist.
Schlussfolgernd würde die Uhrzeit in deinen System immer weiter abweichen, wenn du diese Ports schließt, und das hätte unerwünschte Folgen.

Wenn du keine Software verwenden möchtest, die dauerhaft auf diesen Ports lauscht, wirst du wechseln müssen. Aber eine Anleitung kann Ich dir mangels Testsystem nicht schreiben, da Ich sie erst prüfen wollen würde, um das ganze nicht noch weiter in die Länge zu ziehen.

NTP ist in diesen Fall ein anderes Biest, gerade da auf MX Linux eine Software dafür vorinstalliert ist, die eigentlich als Server gedacht ist, und sich entsprechend so verhält. Wirklich „unsicher“ konfiguriert ist es nicht.

Seit systemd inoffizieller „Standard“ ist, verwenden die meisten Distributionen einfach dessen „timesyncd“.
Minimalisten, die den NTP Daemon nicht verwenden möchten, aber auch kein Systemd, verwenden afaik. meist sntp in einen cron-Skript (Ich glaube, mit den letzten Worten solltest du Anleitungen dafür bereits im Internet finden können, notfalls könnte Ich auch eine schreiben).
sntp lauscht nur während der Abfrage auf den UDP Port für die Antwort des verwendeten Zeitservers. Zugleich kann hier aber nicht NTS verwendet werden, um die Zeitsynchronisation zu verschlüsseln - wobei das in der Standardkonfiguration von deinen NTP Daemon auch nicht verwendet wird.
Sntp hat aber auch nicht die selben Härtungsmaßnahmen wie der NTP Daemon - wie ein AppAmor Profil, oder einen eigenen Benutzer unter dem es ausgeführt wird, und muss als Root-Benutzer ausgeführt werden, um die Uhrzeit zu setzen… das ist aus Sicherheitssicht nicht optimal.

Eigentlich ist Linux auf der Basis von Debian und dessen Derivaten, dazu zählt MX Linux, relativ gut abgehärtet, für Laien. Es gibt einige Schrauben, an denen man drehen kann, aber solange du keinen klaren Plan hast, was genau dein System tun und lassen soll, kann das ganz schnell komplex werden.

Meine persönliche Empfehlung wäre, falls du interface ignore all in der /etc/ntpsec/ntp.conf Datei eingefügt hast, dieses zu entfernen, damit die Zeitsynchronisation klappt, und erstmal alles so zu belassen, wie es ist.
Ich selbst, obwohl Ich schon mit meinen Systemaufbau recht paranoid wirke, hätte wenige Bedenken mit dem NTP-Daemon, in seiner Standardeinstellung.
Wobei Ich NTS eingerichtet habe - mit anderen Servern als Cloudflare.

Andere Rechner im gleichen (Heim)Netzwerk könnten zwar die Zeit mit deinen Server synchronisieren, aber mehr nicht.
Da würde Ich als Lösung eher zwei Firewall-Regeln einrichten, die Zugriffe aus dem entsprechenden (Heim)-Netzwerk "drop"t, mit Ausnahme für die eigene IP-Adresse als auch für die IP-Adresse des Routers.
Das ist viel einfacher nachzuvollziehen als die Konfiguration, fände Ich, und deckt alles ab. Falls du natürlich IoT Geräte im Netz hast, oder mit anderen Geräten Dinge synchronisierst, ist das keine wirkliche Option, außer du schränkst die Regeln zusätzlich auf den Port 123 ein.

9

Vielen Dank für deine Hilfe. Ich muss dazu sagen was für dich vielleicht einfach zu verstehen ist, ist es für mich leider nicht. Ein bisschen Off-Topic, aber ein sicheres und datenschutzfreindliches System ist fast nur für Erfahrenen erreichbar?

Funktioniert. Danke.

Apparmor ist nicht vorinstalliert (MX Linux 23.2 Minimal installiert aber der Standard version hat es auch nicht).

Bei MX Linux Minimal ist NTP nicht vorinstalliert (Aufgepasst: auch kein Firewall! Edit: stimmt nicht, nur UFW ist nicht vorinstalliert). MX-datetime und chrony schon.

Mit Firewall, Rkhunter und Chkrootkit komme Ich zu den Ergebnis von 69% bei einem Lynis audit

1 „Gefällt mir“
10

Gar kein Problem: Nimm dir die Zeit, und stelle Fragen wenn etwas unverständlich ist. Jeder hat irgendwo angefangen. Das wird mit der Zeit meist leichter zu verstehen, gerade wenn du länger mit deinem System arbeitest.

Dein MX Linux ist im Auslieferungszustand, wenn du es aktuell hältst und nicht selbst grobe Fehler begehst (z.B. installieren von möglicherweise schadhafter Software aus Drittquellen, das übliche eben), eigentlich recht sicher, und auch Datenschutzfreundlich - letzteres mache Ich hier jetzt mal an der Empfehlung der Distribution im Blog fest, dass dort nicht einfach ungefragt Daten erhoben und versandt werden.

Natürlich geht es fast immer sicherer, aber das bedeutet meist auch, sich tiefere Systemkenntnisse anzuarbeiten. Das braucht schon etwas Zeit. Für Fragen stehen dir hier denke Ich aber auch alle Ohren offen, wie bisher. :slight_smile:

Lynis und verschiedene andere Tools sind wirklich mehr eine Stütze für erfahrene Nutzer die alle möglichen Bestandteile ihres Systems abhärten möchten. Zugleich sind sie aber nicht perfekt, und nicht alles was von diesen empfohlen wird ist die richtige Einstellung.
Da muss man vergleichsweise viel Zeit und Aufwand für (teilweise) relativ wenig zusätzliche Sicherheit rein stecken. Und sich auch gut auskennen, oder viel in den Dokumentationen der Anwendungen lesen, die man bei den Punkten konfigurieren soll.

100% wirst du vermutlich nicht erreichen. Nicht weil Ich dir das können dazu abspreche, sondern weil es einfach die Umsetzung von ein paar unsinnigen Optionen (soweit Ich mich erinnere gab es Punkte für eine abgeänderte „Message of the day“) erfordert, als auch manche Einstellungen inkompatibel mit deiner Systemkonfiguration oder deinen Anwendungen sein könnten.

Das verwundert mich, wo es doch teils auf Debian aufbaut.
Aber das ist kein Problem, sofern der Kernel nicht ohne Apparmor kompiliert wurde, könnte ein apt install apparmor apparmor-utils apparmor-profiles genügen. Nach einen Systemneustart sollte aa-status (als Root/mit Sudo) eine Liste ausgeben, in der für ntpd ein Profil im „enforced“ Modus aktiv ist.
Dann stimmt alles.

Verstehe. Ich habe leider nie wirklich MX verwendet. Mit ntpsec (dem bei dir momentan installierten ntp-daemon) war Ich als Option zufrieden, deshalb kann Ich wenig zu den vorinstallierten Optionen sagen.
Aus Neugier, warum bist du von diesen weg gewechselt?

Eine Firewall bräuchte es auch nicht unbedingt, es würde aber das Ziel sehr vereinfachen, alles an Traffic aus dem Heimnetzwerk zu blockieren. Wenn aber schlussendlich nur der NTP Daemon auf den Port 123 lauscht, und sonst nichts, halte Ich den Aufwand für zwecklos.

Kleiner (Off-Topic) Einwurf, der auch nicht deine Wahl kritisieren soll:
Ich käme eventuell nicht auf die 69% - vielleicht durch meine sonstige Konfiguration schon - da Ich Rkhunter oder Chkrootkit nicht verwenden würde.
Die erhöhten Berechtigungen die diese Programme brauchen sehe Ich als höheres Risiko, und als Problem gegenüber den möglichen Schutz den sie bieten könnten.
Das wäre z.B. ein Beispiel, wo Empfehlungen von Lynis nicht unbedingt von allen(!) erfahrenen Nutzern geteilt werden.

Also, wenn es Dinge gibt, auf die du eventuell noch eine Antwort möchtest/brauchst, oder es Probleme gibt, Ich bin ganz Ohr.
Mir fällt gerade wenig ein, was Ich jetzt gerade beitragen kann.
Es wäre auch gut, wenn Du dabei erwähnst was du dann genau, oder in etwa, vor hast, falls du das dann bereits weißt - da Ich das Thema meiner Meinung nach etwas durch ein paar Einwürfe entgleist habe. Entschuldige.

11

Danke für deine nette und freundliche Hilfe.

Davon bin Ich mir bewusst. DIe Empfehlungen lese Ich auch nach und einige halte Ich für meine Situation nicht nötig.

Danke. So weit war Ich noch nicht, Ich bin bei NTP abhärten hängen geblieben.

Ntpsec muss mann selber auch wieder installieren (bei die Minimal Version). Vielleicht nicht die richtige Wahl, aber im Anfang habe Ich erst MX Linux 23.2 installiert. Da war dann NTP und/oder ntpsec schon dabei. Später habe Ich dann die Minimal version von MX Linux gefunden, wie Mike schreibst: KISS. Dabei fehlte NTP, und Ich dachte es ist relativ einfach NTP zu härten, und verfolge gründlich seine Anleitung Linux härten Teil 2 Deswegen. :slight_smile: Wenn es mit ntpsec geht, oder NTP mit Apparmor mit Profil, dann bin Ich wo Ich sein möchte.

Kannst Du wenn Du Zeit hast und möchtest, bei MX Linux gibt es ein Live USB zum ausprobieren. :wink: