Security and privacy

SecurityCopy Anchor Link

PanelCopy Anchor Link

• Passwords are stored with PBKDF2-SHA256 (310,000 iterations). After more than 5 failed sign-ins for one user, or 10 from one IP, within 15 minutes, sign-in is locked for a while.
• Session cookies are HttpOnly and SameSite, and Secure over HTTPS. Every change requires a CSRF header, and the panel sends strict security headers (content security policy, no framing, no referrer).
• Share links can only call read-only functions and can hide details; their key doesn't leak through the Referer header.
• Use HTTPS when the panel can be reached from the internet. See HTTPS.

AgentsCopy Anchor Link

• Agents only make outbound connections and listen on no port.
• Each server has its own token. You can regenerate it, or delete the server, in the panel at any time; deleting the server revokes it.
• The agent doesn't run as root (since 1.1.0). It runs as the unprivileged user 3rmonitor-agent: it can't read /etc/shadow or change anything. It reads the system logs through the adm and systemd-journal groups, and the web access logs through a read-only ACL that the installer adds (with setfacl).
• The few things that need root go through a small root helper, 3rmonitor-helper, which only accepts a few fixed requests over a local socket that only root and 3rmonitor-agent can open: the collectors that need root (processes behind ports, certificates, web server checks, Docker), the blocklist firewall, agent updates and AI operations. It fetches AI operations, firewall rules and updates from the master itself, so a compromised agent can't hand it its own.
• The firewall is changed only after you turn the blocklist on for that server, and only in 3R Monitor's own table or chain.
• Agent updates come only from your master, and since 1.1.1 only programs signed by 3R Soft are installed: the list of checksums in the release package is signed with 3R Soft's release key (SHA256SUMS.sig), and the agent checks that signature, for its exact version, and the program's SHA-256 before it runs the new program. So not even a master that was taken over can push a program of its own to your servers, or an older version.
• Country rules and large ranges never block SSH, and a rule that would block almost everyone is refused by the server itself. See So you don't lock yourself out.

MasterCopy Anchor Link

• The master runs as the unprivileged 3rmonitor user, in a strict systemd sandbox (3rmonitor-master.service.d/hardening.conf): it can only write to its data directory, has no access to devices or kernel settings, and can't gain privileges through setuid programs. On systems that don't support it, the installer removes it.
• One-click updates are verified twice, against 3R Soft's Ed25519 signature and SHA-256, before the root update service installs them, and only after an administrator confirms. Only versions published by 3R Soft and newer than the installed one are accepted. The root update service only reads and writes inside its own update folder.

AI operationsCopy Anchor Link

AI analysis is off by default. When the AI on-call runs something on a server:

• The helper is the final check. It fetches the operation from the master itself (the agent only passes on its number), checks it again with the same rules, checks the approval, runs it and sends the result back. It doesn't trust the risk level the master gave.
• Malicious commands are refused however they are written, and high-risk ones are never run: they are only shown to you.
• Every operation is signed by the master, and every repair you approve is signed with your passkey over its exact content. A server only accepts keys that root confirmed on the server, so not even a compromised master can approve, change or add an operation. See Passkeys.
• An approval is used once, within an hour; if anything in the operation changes, the helper refuses it.
• Repairs approved only by the reviewer AI are limited on each server too: the same repair 3 times an hour, 20 in 24 hours.
• Diagnostics that aren't plain read-only commands run in a sandbox: a throwaway unprivileged user, a read-only filesystem, at most 120 s and 256 MB, and only the networks you allow.
• A reviewer AI checks every repair and every sandboxed diagnostic. Text from logs, web pages and command output is treated as data, never as instructions.
• On the server, root has the last word: sudo 3rmonitor ai off (nothing) or ai read (diagnostics only).

PrivacyCopy Anchor Link

3R Monitor runs on your own servers and sends no monitoring data to 3R Soft.

Visitor IPs from the access logs are looked up offline and stored only on the master. The AI API keys and the key used to make the codes are stored only on the master.

Reporting a security problemCopy Anchor Link

If you find a security problem in 3R Monitor, report it privately to security@3rsoft.com.pa, and don't publish it before a fix is available. Include the version (3rmonitor version), whether it affects the master, the agent or the installer, the steps to reproduce it and the impact you expect. Please don't run tests that disrupt servers you don't own or that destroy data.

Only the latest version receives security fixes. Since agents update themselves from the master, upgrading the master is enough.