Welche Daten gesammelt werden

Die vollständige Liste – und was NODE64 ausdrücklich nicht sendet.

Ein Überwachungsprogramm auf dem eigenen Server ist eine Vertrauensfrage. Deshalb steht hier vollständig, was der Agent erhebt – und was nicht.

Prüf es selbst. node64-agent show gibt aus, was beim nächsten Lauf hochgeladen würde. Nicht eine Zusammenfassung, sondern die Daten. Der Agent ist quelloffen; wer will, liest den Sammelcode nach.

Was erhoben wird #

System Betriebssystem und Version, Kernel, Architektur, Hostname, Laufzeit seit dem letzten Start, Zeitzone, Virtualisierung (Container, VM, Blech), Hardware-Modell und Arbeitsspeicher.

Pakete und Updates Name und Version jedes installierten Pakets, dazu die verfügbaren Aktualisierungen und ob sie als Sicherheitsupdate gekennzeichnet sind. Unterstützt werden dpkg/apt, rpm/dnf, apk, pacman und opkg.

Dienste Welche Dienste eingerichtet sind, welche laufen, welche beim Start mitkommen.

Offene Ports Jeder lauschende Socket mit Port, Protokoll, Bind-Adresse und dem zugehörigen Prozess. Die Bind-Adresse ist der entscheidende Teil: 127.0.0.1:3306 ist etwas völlig anderes als 0.0.0.0:3306.

Konten Lokale Benutzer, ob sie sich anmelden können, wer sudo darf, und die Fingerabdrücke hinterlegter SSH-Schlüssel. Die Schlüssel selbst werden nicht übertragen.

Ausgehende Verbindungen Die Beziehung Prozess → Zielnetz:Port mit Zähler – nicht die einzelne Verbindung, nicht der Zeitpunkt, nicht die Gegenstelle als volle Adresse. Bei IPv4 zählt das /24, bei IPv6 das /48: grob genug, dass ein Anbieter stabil bleibt, fein genug, dass ein fremdes Rechenzentrum auffällt.

Datenvolumen je Beziehung Nur, wenn dein Kernel es zählt (net.netfilter.nf_conntrack_acct=1) – ab Werk ist das aus, und dann steht „nicht messbar" statt einer Null. NODE64 schaltet es nicht ein.

Abweichungen vom Auslieferungszustand Für die überwachten Pfade und alle setuid/setgid-Programme wird die Prüfsumme deiner eigenen Paketverwaltung verglichen. Übertragen wird die Zahl der Abweichungen und die Pfade der abweichenden Dateien – nie ein Dateiinhalt. Konfigurationsdateien zählen nicht mit; sie dürfen sich ändern.

Lücken in der Meldekette War die Verbindung länger weg, als die Warteschlange hält, meldet der Agent beim nächsten Bericht, wie viele Stände verlorengegangen sind und in welchem Zeitraum. Ohne diese Auskunft sähe die Messreihe danach lückenlos aus, und sie ist es nicht.

Container Laufende Container mit Image, Digest, Status und Ports – und ob sie privilegiert laufen.

Netzposition Schnittstellen und ihre Adressen, Standard-Route, ob das System hinter NAT steht, und die öffentliche Adresse, wie der Server sie sieht.

Firewall Ob ein Regelwerk aktiv ist (nftables, iptables, ufw, firewalld) und wie viele Regeln es hat.

Dateiintegrität SHA-256-Prüfsummen, Rechte, Eigentümer und Änderungszeit eines festen Satzes wichtiger Dateien – etwa /etc/passwd, /etc/shadow, /etc/ssh/sshd_config, /etc/sudoers, Cron-Verzeichnisse. Prüfsummen, keine Inhalte.

Datenträger, Kernel-Parameter, Speicherpools Jeder eingehängte Datenträger mit Grösse, Belegung und Dateisystem – ein Eintrag je Datenträger, nicht je Einhängepunkt. Dazu rund zwanzig Kernel-Einstellungen aus /proc/sys (Speicherschutz, Netzverhalten, Auslagerungsneigung) und, falls vorhanden, Speicherverbunde – ZFS, Software-RAID und btrfs – mit Zustand, Füllstand, Fehlerzählern und dem Alter des letzten Scrubs.

Datenträger-Gesundheit (SMART) Je physischem Laufwerk: Modell, Anschlussart, Grösse, ob es dreht, die Selbsteinschätzung des Laufwerks (bestanden/durchgefallen) und die Zähler, die einen Ausfall ankündigen – umgelagerte Sektoren, schwebende Sektoren, nicht korrigierbare Lesefehler, Übertragungsfehler, verbrauchte Lebensdauer bei Flash-Speicher, Betriebsstunden, Temperatur und das Alter des letzten Selbsttests. Die Seriennummer wird nicht übertragen. Fehlt smartctl oder das Recht, kommt nur die Liste der Laufwerke an – und der Bereich wird ausdrücklich als eingeschränkt gemeldet.

Dateisysteme Je Einhängepunkt: Typ, Gerät, Einhänge-Optionen und ob es schreibgeschützt ist. Bei ext2/3/4 zusätzlich der Superblock-Zustand, der Fehlerzähler und der für root reservierte Anteil; bei btrfs die Profile für Daten und Metadaten, der nicht zugeteilte Rohplatz und wann zuletzt gescrubbt wurde.

Plattform-Merkmale Einzelne Tatsachen über die Plattform, jeweils als Zahl oder Ja/Nein – keine Konfigurationsinhalte: fehlgeschlagene Dienste (Anzahl und Name der ersten fünf), ob die Uhr synchronisiert ist, ob das Journal eine Obergrenze hat, ob die Auslagerung auf einem ZFS-Volume oder einer SD-Karte liegt. Auf Proxmox VE dazu: Anzahl eingerichteter Sicherungsaufträge, ob die Enterprise-Quelle ohne Abo aktiv ist, Anzahl der Verbundknoten und ob ein QDevice existiert, ob die Firewall eingeschaltet ist, Belegung der Thin-Pools. Auf Proxmox Backup Server: Anzahl der Datastores und wie viele davon ohne Bereinigung, ohne Aufbewahrungsregel, ohne Prüf- oder Sync-Auftrag laufen. Auf dem Raspberry Pi: die Drosselungs-Bits des Prozessors (Unterspannung, Temperaturgrenze) – jetzt und seit dem Start.

Netz und Sperrdienst Je Schnittstelle die Zähler des Kernels: Fehler, verworfene Pakete, Verbindungsabrisse. Und ob fail2ban installiert ist, läuft und Regeln geladen hat – mit der Anzahl gesperrter Adressen, nicht den Adressen.

Server-Dienste: Webserver, Container-Laufzeiten, FTP Hier gilt eine besondere Regel: Die Konfiguration wird lokal gelesen und lokal ausgewertet – übertragen werden nur die Antworten. Die Konfiguration eines Webservers ist der Ort, an dem Passwörter, interne Hostnamen, Kundenpfade und Zertifikatsangaben stehen; wer sie überträgt, überträgt all das mit. Der Agent liest sie deshalb auf dem Gerät und schickt eine Handvoll Ja/Nein-Antworten:

nginx: ob die Versionsnummer im Header steht, ob veraltete TLS-Versionen erlaubt sind, ob TLS 1.3 an ist, ob überhaupt ein Zertifikat eingerichtet ist, ob Verzeichnislisten ausgeliefert werden, ob HSTS gesetzt ist.
Apache: die Stufe von ServerTokens, ob die Kennung unter Fehlerseiten steht, ob TRACE beantwortet wird, ob Verzeichnislisten erlaubt sind, ob mod_status, mod_info oder mod_autoindex geladen sind.
Docker: ob die API auf dem Netz lauscht, ob Container-Logs einen Deckel haben, ob live-restore, no-new-privileges und der Benutzer-Namensraum eingeschaltet sind, ob Container am Standard-Netz miteinander reden dürfen.
Podman: ob der System-Socket läuft und ob Kennungsbereiche für den wurzellosen Betrieb vergeben sind.
FTP: welcher Dienst es ist, ob anonymer Zugang erlaubt ist, ob es einen Käfig gibt, ob TLS eingeschaltet und ob es erzwungen ist.

Was nicht ankommt: keine Servernamen, keine virtuellen Hosts, keine Pfade, keine Zertifikate, keine Nutzerlisten, keine Container-Namen aus der Konfiguration – und kein Stück der Konfigurationsdatei selbst.

Grundsatz-Härtung: Konten, Rechte, Freigaben, Sicherungen Ebenfalls lokal ausgewertet, übertragen werden nur Zahlen und Ja/Nein:

Konten: wie viele Einträge in /etc/passwd die Kennung 0 tragen, die Einstellungen PASS_MAX_DAYS und UMASK aus /etc/login.defs. /etc/shadow wird nicht gelesen – Passwort-Hashes haben auf einem Server nichts zu suchen.
sudo: wie viele Regeln NOPASSWD verwenden und wie viele davon für beliebige Befehle gelten. Keine Namen, keine Befehle, keine Regeln im Wortlaut.
Zwangszugriffskontrolle: ob AppArmor oder SELinux läuft und in welchem Modus, dazu die Anzahl erzwingender und beobachtender Profile.
Freigaben: ob NFS-Exporte existieren, wie viele davon für alle Adressen offen sind und wie viele no_root_squash verwenden – nicht welche Verzeichnisse. Bei Samba, ob Gastzugriff erlaubt ist und ob alte Protokollversionen zugelassen sind.
Einzeldienste: bei Redis, ob ein Passwort gesetzt und ob die Bindung offen ist; bei SNMP, ob die Voreinstellung public verwendet wird; bei Postfix, ob mynetworks das ganze Internet umfasst.
Sicherungen: wie viele bekannte Sicherungswerkzeuge installiert sind und wie viele Zeitpläne nach einer Sicherung aussehen. Keine Pfade, keine Ziele, keine Zugangsdaten.
Rechte: wie viele SUID-Programme an ungewöhnlichen Orten liegen und wie viele Verzeichnisse für alle beschreibbar sind, ohne Klebebit – gesucht wird zwei Ebenen tief unter /tmp, /var/tmp, /dev/shm, /home, /srv und /opt, nicht im ganzen Dateisystem. Übertragen werden die Anzahlen, nicht die Pfade.
Automatische Updates: ob unattended-upgrades nicht nur installiert, sondern auch eingeschaltet ist.

Datenspeicher, Netzdienste und Zertifikate Wieder lokal ausgewertet, übertragen werden nur Antworten:

Datenbanken: bei MySQL/MariaDB, ob die Bindung offen ist und ob local-infile an ist; bei PostgreSQL, ob listen_addresses offen steht und wie viele trust-Regeln es gibt – getrennt nach lokal und aus dem Netz; bei MongoDB, ob eine Anmeldung verlangt wird; bei Elasticsearch, ob die Sicherheitsschicht an ist. Keine Datenbanknamen, keine Nutzer, keine Regeln im Wortlaut.
Netzdienste: bei Memcached, ob UDP an ist und wie gebunden wird; beim DNS-Dienst, welche Software es ist und ob rekursive Anfragen unbeschränkt beantwortet werden. Keine Zonen, keine Weiterleitungsziele, keine Sperrlisten.
Zertifikate: wie viele lokale Zertifikate es gibt, wie viele abgelaufen sind und wie viele Tage das nächste noch hat. Nur der öffentliche Teil wird gelesen, und übertragen werden ausschliesslich diese drei Zahlen – kein Name, kein Aussteller, kein Pfad. Private Schlüssel werden nicht angefasst, der CA-Speicher des Systems bleibt aussen vor.
Verschlüsselung ruhender Daten: ob überhaupt ein verschlüsselter Datenträger eingerichtet ist – eine Ja/Nein-Frage, keine Namen, keine Schlüssel.

Angebundener Speicher und Netzlaufwerke Auch hier gilt: lokal ausgewertet, übertragen werden Zahlen und Ja/Nein.

Netzlaufwerke (NFS, CIFS/SMB): Einhängepunkt, Typ und die Einhänge-Optionen – also ob nosuid, nodev und _netdev gesetzt sind, welche SMB-Version verwendet wird und ob NFS hard oder soft eingehängt ist. Nicht übertragen werden Servername und Freigabepfad.
Aus /etc/fstab: wie viele Netzlaufwerke es gibt, in wie vielen ein Passwort im Klartext steht und wie viele Zugangsdaten-Dateien für andere lesbar sind. Das Passwort selbst wird nicht gelesen – geprüft wird nur, dass eines dasteht, und bei einer credentials-Datei nur deren Rechte.
LVM: Anzahl der Thin-Pools und Schnappschüsse, deren höchster Füllstand (Daten und Metadaten getrennt) und wie viele Datenträger einer Volume-Gruppe fehlen. Keine Namen von Gruppen oder Datenträgern.
Multipath, iSCSI, Fibre Channel: Anzahl der Verbunde, Pfade und ausgefallenen Pfade; bei iSCSI, ob CHAP eingerichtet ist und wie viele Sitzungen bestehen; bei FC, wie viele Anschlüsse nicht online sind. Keine Ziel-Kennungen, keine Adressen, keine Zugangsdaten.
Container: zusätzlich zu Name, Abbild und Zustand, ob ein Container im Netz des Wirts läuft und ob er den Container-Socket eingebunden hat.
Pi-hole und Ubuntu Pro: ob ein Passwort für die Oberfläche gesetzt ist bzw. ob das System an Ubuntu Pro angebunden ist. Keine Sperrlisten, keine Abfragen, kein Abonnement-Schlüssel.

Kernel- und Boot-Härtung Aus /proc und /sys: ob CPU-Schutzmaßnahmen auf der Kernel-Kommandozeile abgeschaltet sind, ob ein unsigniertes Kernel-Modul geladen ist, der Lockdown-Modus, der Secure-Boot-Zustand, wie viele Hardware-Lücken der Kernel als offen meldet, und ob /etc/ld.so.preload einen Eintrag hat. Alles als Zahl oder Ja/Nein — keine Modulnamen, keine Pfade.

Zugriffsrechte, SUID und Capabilities Gezielt, ohne Durchlauf des ganzen Dateisystems: ob ein gefährliches SUID-Programm (GTFObins) oder eine gefährliche Datei-Capability existiert, ob Kern-Kontodateien oder Cron-Skripte für andere beschreibbar sind, ob SSH-Schlüssel falsche Rechte haben, ob es doppelte Kennungen oder Dienstkonten mit Login-Shell gibt, und ob Passwort-Komplexität und su-Beschränkung eingerichtet sind. Übertragen werden Zahlen und Ja/Nein — keine Dateiinhalte.

Webserver-Sicherheitsheader, PHP und Webroot Ergänzend zur Server-Konfiguration: ob die grundlegenden HTTP-Sicherheitsheader gesetzt sind, ob WebDAV aktiv ist, wichtige PHP-Einstellungen (expose_php, display_errors, allow_url_include/fopen — als Ja/Nein), und ob im ausgelieferten Webroot ein .git-Verzeichnis oder eine .env-Datei liegt (Anzahl, keine Inhalte). Zusätzlich zu den Zertifikats-Ablaufdaten jetzt auch: selbstsigniert, schwacher Schlüssel, veraltete Signatur, überlange Laufzeit — je als Anzahl. Bei PostgreSQL, ob SSL eingeschaltet ist.

Container-Laufzeit-Härtung Je Container zusätzlich: ob er als root läuft, ob er einen sensiblen Wirt-Pfad (/, /etc, /root, /var/run) eingebunden hat, ob ihm eine gefährliche Capability hinzugefügt wurde, ob das Sandbox-Profil (seccomp/apparmor) abgeschaltet ist und ob Ressourcengrenzen fehlen. Dazu, ob eine Docker-Registry ohne TLS eingetragen ist. Jeweils Ja/Nein — keine Kommandozeilen, keine Umgebungsvariablen.

Netz-Überlagerung (VLANs, VXLAN, Bridges) Aus /proc/net und /sys/class/net: die Anzahl der VLANs, VXLAN-Overlays und Bridges, ob ein VXLAN im Multicast-Modus läuft, ob unter einem VXLAN-Overlay Verschlüsselung (WireGuard/IPsec) liegt, und ob eine Bridge mit VLANs ohne VLAN-Filtering läuft. Alles als Zahl oder Ja/Nein — keine VNIs, keine Ziel-Adressen, keine Schnittstellennamen.

Prozesse, Persistenz und Audit Gezielt und präzise: die Anzahl laufender Programme, deren Binary in einem temporären Verzeichnis liegt, systemd-Units mit verdächtigem ExecStart, Cron-Aufträge, die Fremdcode nachladen, ob auditd Regeln geladen hat und ob die zentralen Protokolle rotiert werden. Zahlen und Ja/Nein — keine Prozess-Kommandozeilen, keine Log-Inhalte.

Paketquellen, Cloud-Zugangsdaten, Sicherungs-Rechte Ob eine APT-Quelle die Signaturprüfung abschaltet, ob Cloud-Zugangsdaten (AWS/GCP/Azure/OpenStack) für andere lesbar sind, ob ein Datenbank-Dump in einem Sicherungsverzeichnis offene Leserechte hat, und — auf Proxmox — ob der root-Zugang Zwei-Faktor nutzt. Zahlen und Ja/Nein, keine Schlüssel, keine Dateiinhalte.

Ausgelöste Persistenz Ob ein Auslöser-Verzeichnis ein verdächtiges Programm startet: udev-Regeln (Geräte-Ereignis), pam_exec (Anmeldung), MOTD-/NetworkManager-/Generator-Skripte (Anmeldung, Netzwechsel, Start) und APT-Hooks (Paketaktion). Erkannt wird nur das verdächtige Merkmal — Start aus einem temporären Verzeichnis oder Nachladen aus dem Netz —, gezählt als Anzahl. Keine Skript-Inhalte.

Firewall-Standardpolitik, Mail-Server, weitere Härtung Ob eine aktive Firewall ihre Eingangskette auf durchlassen stehen hat (ohne Sperrregeln), ob Postfix VRFY beantwortet, ob Dovecot Klartext-Anmeldung erlaubt, ob prelink oder ein NIS/YP-Dienst vorhanden ist, und die Passwort-Ablauf-Einstellung. Ja/Nein und Zahlen, keine Regelinhalte.

Malware-Hygiene und Ransomware-Indikatoren Ob ein vorhandener Virenscanner (ClamAV) aktuelle Signaturen hat und ob rkhunter regelmäßig läuft — Prüfung der Wirksamkeit vorhandener Schutzwerkzeuge, kein eigener Scanner. Dazu zwei dateibasierte Ransomware-Spuren in den Datenverzeichnissen: die Anzahl gefundener Erpressernotizen und die Anzahl Dateien mit bekannter Ransomware-Endung. Nur Zahlen — keine Dateiinhalte, keine Signaturprüfung.

Telemetrie Auslastung, Speicher- und Plattenbelegung, Temperatur, wenn messbar.

Log-Signale – gezählt, nicht gelesen Der Agent sieht die Fehlerlogs des Systems durch und überträgt nur Zählungen: welches Muster wie oft in den letzten 24 Stunden vorkam, wann zuerst und zuletzt, dazu ein paar knappe Bezeichner (sda, nginx.service, mysqld) und die Anzahl unterschiedlicher Herkunftsnetze bei Anmeldeversuchen.

Ein Beispiel dessen, was ankommt:

ssh_failed_password: 412   (aus 3 Netzen, zuletzt 09:58)
oom_killer:            2   (mysqld)
io_error:              7   (sda)
service_crash_loop:    1   (nginx.service)

Was nicht ankommt: die Zeilen selbst. Keine Nachrichten, keine Benutzernamen, keine IP-Adressen, kein Fliesstext. Zwei Filter stehen davor – einer über den erlaubten Zeichenvorrat, einer über die Form: Ein Prozessname ist höchstens 15 Zeichen lang, ein Blockgerät heisst sda oder nvme0n1, ein Dienst endet auf .service. Was diese Form nicht hat, wird weggelassen statt gekürzt.

Und wenn du die Zeilen doch sehen willst. Aus „412 fehlgeschlagene SSH-Anmeldungen" folgt unweigerlich die Frage „von wem?". Der Server kann sie nicht beantworten – er hat die Zeilen nie bekommen. Beantworten lässt sie sich dort, wo die Zeilen liegen:

node64-agent logs --muster ssh_failed_password
node64-agent logs --liste          # alle bekannten Muster

Die Ausgabe bleibt auf der Maschine. Sie wird nicht übertragen und nicht gespeichert.

Was jedes Muster bedeutet, welche Ursachen typisch sind und was zu tun ist, steht im Dashboard hinter dem Fragezeichen neben dem Signal – einschliesslich einer beispielhaften Logzeile. Die stammt von uns, nicht aus deinem System.

Ausgewählte Konfigurations-Ausgaben Einzelne, vom Server ausdrücklich angeforderte Ausgaben – zum Beispiel sshd -T für die effektive SSH-Konfiguration. Welche das sind, steht in der Antwort des Servers und ist im show-Befehl sichtbar.

Was den Server verlässt #

Bis auf eine Ausnahme verlässt nichts von deinen Daten diesen Server. Die Ausnahme ist die Registry-Prüfung für Container:

Läuft bei dir ein Container mit nginx:1.25, fragt NODE64 bei der Registry nach, auf welches Image dieses Tag heute zeigt. Dabei geht nur der Image-Name hinaus — also library/nginx und 1.25. Nicht mit: dein Name, dein Konto, die Kennung des Geräts, der Inhalt des Containers oder irgendetwas sonst. Die Registry erfährt, dass irgendwer nach nginx:1.25 gefragt hat — was sie ohnehin bei jedem docker pull erfährt.

Gefragt werden ausschliesslich öffentliche Registries: Docker Hub, ghcr.io, quay.io, lscr.io, registry.k8s.io, gcr.io und public.ecr.aws. Eine eigene Registry wie registry.deinefirma.de wird gar nicht erst angefragt — der Name eines privaten Images soll nicht bei einem fremden Dienst landen, nur um herauszufinden, dass er dort nicht bekannt ist. Solche Images stehen in der Anzeige als „nicht prüfbar".

Abschalten lässt sich das in den Kontoeinstellungen unter Sicherheit. Wer es abschaltet, verliert genau einen Befund: den Hinweis, dass ein Image der Registry hinterherhinkt.

Was nicht erhoben wird #

Keine Dateiinhalte. Ausser den oben genannten, ausdrücklich angeforderten Konfigurations-Ausgaben.
Keine Passwörter, keine Hashes aus /etc/shadow. Vom Schatten-File wird nur geprüft, ob die Rechte stimmen.
Keine privaten Schlüssel. SSH-Schlüssel nur als Fingerabdruck.
Keine Logzeilen. Fehlerlogs werden gelesen und gezählt (siehe oben) – die Zeilen selbst verlassen das Gerät nicht. Kein Live-Streaming, keine Nachrichtentexte, keine Adressen aus dem Log.
Keine Nutzdaten. Keine Datenbankinhalte, keine Webinhalte, keine E-Mails.
Keine Tastatureingaben, keine Prozessargumente mit Geheimnissen.

Wie die Daten reisen #

Der Agent packt alles in ein ZIP-Archiv und lädt es per HTTPS hoch. Ein typischer Upload ist 15 bis 30 Kilobyte – kleiner als ein Foto. Kommt der Server nicht ans Netz, wandert der Upload in eine lokale Warteschlange und geht später raus.

Die Verbindung baut immer der Agent auf. Es gibt keinen Weg von aussen auf dein Gerät.

Was auf dem Server damit passiert #

Das hochgeladene ZIP durchläuft immer denselben Weg:

Geprüft, bevor irgendetwas passiert. Der Server prüft Grösse und Aufbau gegen Zip-Bomben – Obergrenzen für die Zahl der enthaltenen Dateien und für die entpackte Gesamtgrösse. Die Daten werden dabei im Arbeitsspeicher gelesen, nie auf die Platte entpackt; ein manipuliertes Archiv kann so keine Dateien an unerwartete Orte schreiben. Ein ungültiges oder zu grosses Archiv wird abgewiesen und die Zwischendatei sofort gelöscht.
Abgelegt, ausserhalb des Web-Bereichs. Das Original-Archiv wird unverändert gespeichert – sortiert nach Monat, Konto und Gerät, mit engen Dateirechten und an einem Ort, der über die Website nicht erreichbar ist. Ein doppelt gesendeter Upload wird erkannt und nicht zweimal verarbeitet.
Ausgewertet. Der Inhalt wandert in die Datenbank – Pakete, Ports, Dienste, Befunde, Verlaufswerte –, und darauf laufen der CVE-Abgleich und die Härtungsprüfung. Das ist alles, was mit den Daten geschieht: auswerten und anzeigen. Keine Weitergabe, keine Analyse-Dienste, kein zweiter Zweck.
Gelöscht nach Frist. Ein täglicher Aufräumlauf entfernt Datenbank-Einträge und Archive, sobald die Aufbewahrungsfrist deines Tarifs abgelaufen ist (7, 90 oder 365 Tage). Verwaiste Archive ohne Protokolleintrag räumt derselbe Lauf mit weg.

Der Server wertet aus – er greift nicht zurück. Aus einem Upload entsteht ein Befund und eine Empfehlung als Text, nie ein Befehl an dein Gerät. Es gibt keinen Weg von der Plattform zurück auf dein System.

Wo die Daten liegen #

Auf einem Server in Deutschland. Ausschliesslich. Kein Cloud-Anbieter ausserhalb, keine Weitergabe an Dritte, keine Analyse-Dienste. Wie lange die Daten aufbewahrt werden, hängt vom Tarif ab – siehe Tarife und Grenzen.

Was du damit tun kannst #

Ansehen: node64-agent show vor jedem Upload.
Exportieren: Im Dashboard unter Einstellungen bekommst du alle Daten deines Kontos als Archiv.
Löschen: Ein Gerät löschen entfernt seine Daten. Ein Konto löschen entfernt alles.