What data is collected

The complete list – and what NODE64 explicitly does not send.

A monitoring program on your own server is a question of trust. So here is the complete list of what the agent collects – and what it does not.

Check it yourself. node64-agent show prints what would be uploaded on the next run. Not a summary, but the data. The agent is open source; anyone can read the collection code.

What is collected #

System Operating system and version, kernel, architecture, hostname, uptime, timezone, virtualisation (container, VM, bare metal), hardware model and memory.

Packages and updates Name and version of every installed package, plus available updates and whether they are marked as security updates. Supported: dpkg/apt, rpm/dnf, apk, pacman and opkg.

Services Which services are configured, which are running, which start at boot.

Open ports Every listening socket with port, protocol, bind address and the owning process. The bind address is the decisive part: 127.0.0.1:3306 is a completely different thing from 0.0.0.0:3306.

Accounts Local users, whether they can log in, who may use sudo, and the fingerprints of stored SSH keys. The keys themselves are not transmitted.

Outbound connections The relation process → target network:port with a counter – not the individual connection, not the timestamp, not the peer as a full address. For IPv4 the /24 counts, for IPv6 the /48: coarse enough for a provider to stay stable, fine enough for a foreign data centre to stand out.

Data volume per relation Only if your kernel counts it (net.netfilter.nf_conntrack_acct=1) – it is off by default, and then it says "not measurable" instead of showing a zero. NODE64 does not switch it on.

Deviations from the shipped state For the monitored paths and every setuid/setgid program, the checksum from your own package manager is compared. What is transmitted is the number of deviations and the paths of the deviating files – never a file's contents. Configuration files do not count; they are allowed to change.

Gaps in the reporting chain If the connection was away longer than the queue holds, the agent reports on the next run how many states were lost and over what period. Without that information the series would look gapless afterwards, and it is not.

Containers Running containers with image, digest, status and ports – and whether they run privileged.

Network position Interfaces and their addresses, default route, whether the system is behind NAT, and the public address as the server sees it.

Firewall Whether a rule set is active (nftables, iptables, ufw, firewalld) and how many rules it has.

File integrity SHA-256 checksums, permissions, owner and modification time of a fixed set of important files – for example /etc/passwd, /etc/shadow, /etc/ssh/sshd_config, /etc/sudoers, cron directories. Checksums, not contents.

Filesystems, kernel parameters, storage pools Every mounted filesystem with size, usage and type – one entry per device, not per mount point. Plus around twenty kernel settings from /proc/sys (memory protection, network behaviour, swappiness) and, where present, storage arrays – ZFS, software RAID and btrfs – with state, usage, error counters and the age of the last scrub.

Disk health (SMART) Per physical drive: model, bus type, size, whether it spins, the drive's own self-assessment (passed/failed) and the counters that announce a failure – reallocated sectors, pending sectors, uncorrectable read errors, transmission errors, used-up flash lifetime, power-on hours, temperature and the age of the last self-test. The serial number is not transmitted. If smartctl or the permission is missing, only the list of drives arrives – and the area is explicitly reported as limited.

Filesystems Per mount point: type, device, mount options and whether it is read-only. For ext2/3/4 additionally the superblock state, the error counter and the share reserved for root; for btrfs the data and metadata profiles, the unallocated raw space and when it was last scrubbed.

Platform facts Individual facts about the platform, each a number or yes/no – no configuration content: failed services (count and the names of the first five), whether the clock is synchronised, whether the journal has a size cap, whether swap sits on a ZFS volume or an SD card. On Proxmox VE additionally: number of configured backup jobs, whether the enterprise repository is active without a subscription, number of cluster nodes and whether a QDevice exists, whether the firewall is enabled, thin pool usage. On Proxmox Backup Server: number of datastores and how many run without garbage collection, without a retention policy, without a verify or sync job. On the Raspberry Pi: the processor's throttling bits (undervoltage, temperature limit) – now and since boot.

Network and ban service Per interface the kernel counters: errors, dropped packets, link drops. And whether fail2ban is installed, running and has jails loaded – with the number of banned addresses, not the addresses.

Server services: web servers, container runtimes, FTP A special rule applies here: the configuration is read and evaluated locally – only the answers are transmitted. A web server's configuration is where passwords, internal hostnames, customer paths and certificate details live; transmitting it transmits all of that. The agent therefore reads it on the device and sends a handful of yes/no answers:

nginx: whether the version appears in the header, whether obsolete TLS versions are allowed, whether TLS 1.3 is on, whether a certificate is configured at all, whether directory listings are served, whether HSTS is set.
Apache: the ServerTokens level, whether the signature appears under error pages, whether TRACE is answered, whether directory listings are allowed, whether mod_status, mod_info or mod_autoindex are loaded.
Docker: whether the API listens on the network, whether container logs have a cap, whether live-restore, no-new-privileges and the user namespace are enabled, whether containers on the default network may talk to each other.
Podman: whether the system socket runs and whether ID ranges for rootless operation are assigned.
FTP: which service it is, whether anonymous access is allowed, whether there is a jail, whether TLS is enabled and whether it is enforced.

What does not arrive: no server names, no virtual hosts, no paths, no certificates, no user lists, no container names from the configuration – and not one piece of the configuration file itself.

Baseline hardening: accounts, permissions, shares, backups Also evaluated locally; only numbers and yes/no are transmitted:

Accounts: how many entries in /etc/passwd carry UID 0, and the PASS_MAX_DAYS and UMASK settings from /etc/login.defs. /etc/shadow is not read – password hashes have no business on a server.
sudo: how many rules use NOPASSWD and how many of those apply to arbitrary commands. No names, no commands, no rules verbatim.
Mandatory access control: whether AppArmor or SELinux is running and in which mode, plus the number of enforcing and complaining profiles.
Shares: whether NFS exports exist, how many are open to every address and how many use no_root_squash – not which directories. For Samba, whether guest access is allowed and whether legacy protocol versions are permitted.
Individual services: for Redis, whether a password is set and whether the binding is open; for SNMP, whether the public default is in use; for Postfix, whether mynetworks covers the entire internet.
Backups: how many known backup tools are installed and how many schedules look like a backup. No paths, no destinations, no credentials.
Permissions: how many SUID programs sit in unusual places and how many directories are world-writable without a sticky bit – searched two levels deep under /tmp, /var/tmp, /dev/shm, /home, /srv and /opt, not across the whole filesystem. The counts are transmitted, not the paths.
Automatic updates: whether unattended-upgrades is not only installed but actually switched on.

Data stores, network services and certificates Again evaluated locally; only answers are transmitted:

Databases: for MySQL/MariaDB, whether the binding is open and whether local-infile is on; for PostgreSQL, whether listen_addresses is open and how many trust rules exist – separated into local and from the network; for MongoDB, whether authentication is required; for Elasticsearch, whether the security layer is on. No database names, no users, no rules verbatim.
Network services: for Memcached, whether UDP is on and how it binds; for the DNS service, which software it is and whether recursive queries are answered without restriction. No zones, no forwarders, no blocklists.
Certificates: how many local certificates exist, how many have expired and how many days the next one has left. Only the public part is read, and only those three numbers are transmitted – no name, no issuer, no path. Private keys are never touched, and the system's CA store stays out of it.
Encryption at rest: whether any encrypted volume is configured at all – a yes/no question, no names, no keys.

Attached storage and network mounts Here too: evaluated locally, only numbers and yes/no are transmitted.

Network mounts (NFS, CIFS/SMB): mount point, type and the mount options - whether nosuid, nodev and _netdev are set, which SMB version is used and whether NFS is mounted hard or soft. Server name and share path are not transmitted.
From /etc/fstab: how many network mounts exist, how many carry a clear-text password and how many credentials files are readable by others. The password itself is not read - only that one is there, and for a credentials file only its permissions.
LVM: number of thin pools and snapshots, their highest fill level (data and metadata separately) and how many physical volumes a volume group is missing. No names of groups or volumes.
Multipath, iSCSI, Fibre Channel: number of maps, paths and failed paths; for iSCSI, whether CHAP is configured and how many sessions exist; for FC, how many ports are not online. No target identifiers, no addresses, no credentials.
Containers: in addition to name, image and state, whether a container runs in the host's network and whether it has the container socket mounted.
Pi-hole and Ubuntu Pro: whether a password is set for the interface and whether the system is attached to Ubuntu Pro. No blocklists, no queries, no subscription token.

Kernel and boot hardening From /proc and /sys: whether CPU mitigations are disabled on the kernel command line, whether an unsigned kernel module is loaded, the lockdown mode, the Secure Boot state, how many hardware flaws the kernel reports as open, and whether /etc/ld.so.preload has an entry. All as a number or yes/no — no module names, no paths.

Access rights, SUID and capabilities Targeted, without scanning the whole filesystem: whether a dangerous SUID program (GTFObins) or a dangerous file capability exists, whether core account files or cron scripts are writable by others, whether SSH keys have wrong permissions, whether there are duplicate UIDs or service accounts with a login shell, and whether password complexity and su restriction are in place. Numbers and yes/no are transmitted — no file contents.

Web server security headers, PHP and web root Supplementing the server configuration: whether the basic HTTP security headers are set, whether WebDAV is active, key PHP settings (expose_php, display_errors, allow_url_include/fopen — as yes/no), and whether the delivered web root holds a .git directory or a .env file (count, no contents). In addition to certificate expiry now also: self-signed, weak key, obsolete signature, over-long lifetime — each as a count. For PostgreSQL, whether SSL is enabled.

Container runtime hardening Per container additionally: whether it runs as root, whether it mounts a sensitive host path (/, /etc, /root, /var/run), whether a dangerous capability was added, whether the sandbox profile (seccomp/apparmor) is disabled and whether resource limits are missing. Plus whether a Docker registry without TLS is configured. Each yes/no — no command lines, no environment variables.

Network overlays (VLANs, VXLAN, bridges) From /proc/net and /sys/class/net: the number of VLANs, VXLAN overlays and bridges, whether a VXLAN runs in multicast mode, whether encryption (WireGuard/IPsec) sits under a VXLAN overlay, and whether a bridge carrying VLANs runs without VLAN filtering. All as a number or yes/no — no VNIs, no target addresses, no interface names.

Processes, persistence and audit Targeted and precise: the number of running programs whose binary lives in a temporary directory, systemd units with a suspicious ExecStart, cron jobs that download foreign code, whether auditd has rules loaded and whether the core logs are rotated. Numbers and yes/no — no process command lines, no log contents.

Package sources, cloud credentials, backup permissions Whether an APT source disables the signature check, whether cloud credentials (AWS/GCP/Azure/OpenStack) are readable by others, whether a database dump in a backup directory has open read permissions, and — on Proxmox — whether the root access uses two-factor. Numbers and yes/no, no keys, no file contents.

Triggered persistence Whether a trigger directory starts a suspicious program: udev rules (device event), pam_exec (login), MOTD/NetworkManager/generator scripts (login, network change, boot) and APT hooks (package action). Only the suspicious marker is detected — starting from a temporary directory or downloading from the network — counted as a number. No script contents.

Firewall default policy, mail server, further hardening Whether an active firewall has its input chain set to accept (without blocking rules), whether Postfix answers VRFY, whether Dovecot allows cleartext login, whether prelink or a NIS/YP service is present, and the password expiry setting. Yes/no and numbers, no rule contents.

Malware hygiene and ransomware indicators Whether an installed virus scanner (ClamAV) has current signatures and whether rkhunter runs regularly — checking the effectiveness of existing protection tools, not a scanner of its own. Plus two file-based ransomware traces in the data directories: the number of ransom notes found and the number of files with a known ransomware extension. Numbers only — no file contents, no signature matching.

Telemetry Load, memory and disk usage, temperature where measurable.

Log signals – counted, not read The agent scans the system's error logs and transmits counts only: which pattern occurred how often in the last 24 hours, when first and last, plus a few short identifiers (sda, nginx.service, mysqld) and the number of distinct source networks for login attempts.

An example of what arrives:

ssh_failed_password: 412   (from 3 networks, last 09:58)
oom_killer:            2   (mysqld)
io_error:              7   (sda)
service_crash_loop:    1   (nginx.service)

What does not arrive: the lines themselves. No messages, no usernames, no IP addresses, no free text. Two filters sit in front – one on the allowed character set, one on the shape: a process name is at most 15 characters, a block device is called sda or nvme0n1, a service ends in .service. Anything not matching that shape is dropped rather than trimmed.

And if you do want to see the lines. "412 failed SSH logins" inevitably raises the question "from whom?". The server cannot answer it – it never received the lines. It can be answered where the lines actually are:

node64-agent logs --pattern ssh_failed_password
node64-agent logs --liste          # all known patterns

The output stays on the machine. It is neither transmitted nor stored.

What each pattern means, which causes are typical and what to do about it is in the dashboard behind the question mark next to the signal – including an example log line. That example is ours, not from your system.

Selected configuration outputs Individual outputs explicitly requested by the server – for example sshd -T for the effective SSH configuration. Which ones these are is part of the server's response and visible in the show command.

What leaves the server #

With one exception, nothing of your data leaves this server. The exception is the registry check for containers:

If you run a container with nginx:1.25, NODE64 asks the registry which image that tag points at today. Only the image name goes out — that is library/nginx and 1.25. Not included: your name, your account, the device identifier, the container's contents or anything else. The registry learns that someone asked for nginx:1.25 — which it learns from every docker pull anyway.

Only public registries are asked: Docker Hub, ghcr.io, quay.io, lscr.io, registry.k8s.io, gcr.io and public.ecr.aws. A private registry such as registry.yourcompany.com is not asked at all — the name of a private image should not end up at a third-party service just to find out that it is unknown there. Such images show as "not verifiable".

It can be switched off in the account settings under Security. Switching it off costs exactly one finding: the hint that an image lags behind the registry.

What is not collected #

No file contents. Except for the explicitly requested configuration outputs above.
No passwords, no hashes from /etc/shadow. Of the shadow file only the permissions are checked.
No private keys. SSH keys as fingerprints only.
No log lines. Error logs are read and counted (see above) – the lines themselves never leave the device. No live streaming, no message text, no addresses from the log.
No payload data. No database contents, no web content, no email.
No keystrokes, no process arguments containing secrets.

How the data travels #

The agent packs everything into a ZIP archive and uploads it over HTTPS. A typical upload is 15 to 30 kilobytes – smaller than a photo. If the server cannot be reached, the upload goes into a local queue and leaves later.

The agent always opens the connection. There is no path from outside onto your device.

What happens with it on the server #

Every uploaded ZIP takes the same path:

Checked before anything happens. The server checks size and structure against zip bombs – limits on the number of files inside and on the total unpacked size. The data is read in memory, never unpacked to disk; a tampered archive therefore cannot write files to unexpected places. An invalid or oversized archive is rejected and the temporary file deleted at once.
Stored outside the web area. The original archive is kept unchanged – sorted by month, account and device, with tight file permissions, in a location not reachable over the website. A resent upload is recognised and not processed twice.
Analysed. The content moves into the database – packages, ports, services, findings, history values – and the CVE comparison and hardening check run on it. That is all that happens with the data: analyse and display. No sharing, no analytics services, no second purpose.
Deleted after the retention period. A daily cleanup run removes database entries and archives once your plan's retention period has passed (7, 90 or 365 days). Orphaned archives without a log entry are cleared by the same run.

The server analyses – it does not reach back. An upload turns into a finding and a recommendation as text, never a command to your device. There is no path from the platform back onto your system.

Where the data lives #

On a server in Germany. Exclusively. No cloud provider elsewhere, no sharing with third parties, no analytics services. How long data is kept depends on your plan – see Plans and limits.

What you can do with it #

Look at it: node64-agent show before every upload.
Export it: the settings area gives you all data of your account as an archive.
Delete it: deleting a device removes its data. Deleting an account removes everything.