Checkmk monitors hosts, services, networks, and distributed sites. The public web interface is only one part of the trust model. Agents register with a site, distributed monitoring connects central and remote sites, and internal protocols exchange monitoring data. An inventory of Checkmk deployments should include those relationships.
A count-only ZoomEye query on 2026-11-02 returned 2,373 assets for title="Checkmk". The query used sub_type=all, page 1, and page size 1. A title match may include documentation, custom portals, or stale deployments. The count describes matching assets, not confirmed vulnerable instances.
The ZoomEye query provides a population for an ownership review. Match candidates to DNS, certificates, and known monitoring records before testing.
Make registration a controlled identity
Checkmk's monitoring-agent documentation describes registration between the Agent Controller and the site's Agent Receiver. Registration establishes a trust relationship, and later communication uses TLS. Registration is therefore an identity-provisioning action, not a routine health check.
Review which accounts or automation can register agents. Checkmk documents a registration role for automated host creation and TLS registration. Keep that role separate from general monitoring administration. Log registration attempts, successful enrollments, and certificate changes. Remove an agent identity when the host is retired.
Use the certificate overview to inspect site and remote-site certificates. The documentation describes certificates for distributed monitoring and mutual TLS. Record certificate fingerprints, validity, and assigned sites. A self-signed or manually copied certificate can be valid for a lab but needs an explicit trust decision in production.
Protect the distributed monitoring links
Distributed monitoring connects a central site with remote sites. The documentation recommends TLS for encrypted synchronization and notes that Livestatus is not intrinsically secure and should be kept on a secure network or VPN. A public web interface may sit beside an internal management path that must not be exposed.
Review firewall rules between sites. Permit only the documented ports and addresses, and prefer TLS. Do not expose the remote site's management API directly to the internet. If a site is in a different network zone, place the connection behind a controlled VPN or private link and monitor certificate failures.
Separate central and remote administrative roles. A remote-site operator should not automatically become a central-site administrator. Review LDAP or Active Directory mappings, if used, and test the group synchronization result. A directory group that grants access to every site should have a clear owner.
Inventory the public surface
For each candidate host, capture the hostname, certificate, address, product evidence, first-seen time, and organization. Determine whether the endpoint is a production site, a demo, or a documentation page. Check TLS and authentication settings through authorized observation. Do not attempt default credentials or unauthorized changes.
Compare public DNS and certificate names with the configured site URL. Check for old monitoring hosts, agent download endpoints, and remote-site names that were not retired. A host that no longer appears in the central inventory can still hold monitoring data or credentials.
Review access to the monitoring data itself. Metrics and inventory can reveal hostnames, software versions, network topology, and service ownership. Restrict dashboards and API access by role. Use an audit trail for configuration changes and logins. Alert on new administrator accounts, certificate changes, and registration bursts.
Test containment
Disable a registered agent and verify that it cannot continue sending accepted data. Remove a remote-site certificate and confirm that the central site rejects the connection. Test an unauthorized registration attempt and inspect whether the failure is logged with enough context to identify the source.
Checkmk gives an organization a detailed view of its infrastructure. That makes the monitoring platform a sensitive system in its own right. Treat agent registration, distributed-site trust, web access, and internal monitoring protocols as one security boundary. The ZoomEye count only identifies candidates; the internal certificate and role inventory determines what the trust relationships actually mean.