在生产服务器上运行安全吗?
在生产服务器上运行安全吗?
安全。代理只读取本地指标与自身的认证日志,并通过 TLS 出站连接。它不开放任何入站端口,也没有任何进攻能力。
为 Windows 与 Linux 混合服务器群而生
等仪表盘刷新时,事件已经过去一小时。Servers Sentinel 弥合这个缺口。
一台主机停止上报,直到用户发现才有人察觉。覆盖不该取决于谁在盯着屏幕。
每个工具都有自己的收件箱。信号散落在邮件、聊天和 Webhook 里,最后全被忽略。
RDP 和 SSH 的密码猜测会跑上数小时,才在日志审查里露头。它应当在数秒内浮现。
按服务器设置的阈值会随时间失同步。默认值应当级联下发,主机在其上按需覆盖。
Servers Sentinel 在本地采集指标,通过双向 TLS 上报,并凝练为一个健康分数和一条清晰告警。全局模板级联到每台服务器;任何主机都可覆盖某个键而不破坏默认值。
无需编译,无需开放入站端口。一切都通过 TLS 出站运行。
在面板中注册主机,获得一行安装命令和一个短时效的注册令牌。
脚本检测操作系统与架构,将代理安装为服务,并通过 mTLS 注册。
CPU、内存、磁盘与网络按节奏进来。每台主机获得实时健康分数。
规则触发到邮件、Telegram、Slack 或 Webhook。暴力破解在代理上检测并即时标记。
今日即有核心闭环,安全、磁盘与数据库以可插拔模块的方式设计其中。
每台主机的 CPU、内存、磁盘与网络,作为时间序列存储,画成一眼可读的迷你曲线。
全局模板设定默认值;每台服务器只覆盖需要的键。覆盖是级联,绝不分叉。
每个代理持有客户端证书。接入经双向认证,单凭泄露的令牌打不开任何东西。
代理在本地监视 RDP 与 SSH 认证,报告活跃攻击及其主要来源 IP。
每台主机浓缩为一个 0-100 分数,数百台的服务器群会按需关注自动排序。
邮件、Telegram、Slack 与 Webhook。添加渠道、发送测试,并把规则路由过去。
用户、团队与角色(查看者、操作员、管理员)把每位客户的服务器群隔离在同一登录之后。
同一协议驱动 Linux 上的 systemd 单元与 Windows 服务,覆盖 amd64、arm64 与 386。
在一台服务器上免费开始。按主机数量付费,可选月付或年付。
注册后即可监控全部服务器:指标历史、可用性与 API 检查、Telegram 通知和报告。到期不会扣费--账户回到 Free,单台服务器监控继续运行。
十五种情形:在这些情形下,不知道一台服务器正在做什么,不再是一个可以接受的风险。如果其中任何一种与您的机器群相符,那个缺口已经存在了--只是它还没让您付出代价。
第一组关乎那些没被看见的事。这些情形都不是失职:一旦机器的数量超过一个人能在脑子里记住的数量--对多数团队来说大约是四台--它们就会发生。
一台机器停止了上报。它可能被宿主机重启了,可能丢了路由,可能耗尽了内存,也可能只是被某个整理机柜的人关掉了电源。没有任何东西会宣布这件事:一台缺席的服务器不会产生错误,而沉默恰恰也是一台健康服务器所产生的东西。
全部问题就在故障与那通电话之间的空档里。它通常以小时计,发现它的永远是最不该发现它的人,而到那时问题已经不是什么坏了,而是为什么没有人知道。
磁盘写满是所有故障里最可预测的一种。日志在长,备份被写了两遍,临时表从来没被清理,而剩余空间的曲线已经指向同一个日期两个星期了。
它同时也是恢复代价最高的一种故障,因为一个在写入途中耗尽空间的数据库,并不会礼貌地停下来。80% 告警和 100% 呼叫之间的差别,就是两分钟清理和从昨晚备份恢复之间的差别。
内存泄漏、连接池耗尽、一天比一天排得更慢的队列、还有一个月到期的证书--这些都不是事件。它们是斜率,而斜率对一个只看当前数值的人来说是不可见的。
没有历史就没有可比对的东西。“这台主机内存 70% 算正常吗”这个问题根本无法回答,除非有什么东西记录过正常是什么样子--而且那份记录必须在有人想到要问之前就已经在跑了。
多数真实环境都是混合的:几台 Windows 服务器跑着账务系统和文件共享,几台 Linux 机器跑着网站和数据库,远端站点或许还有一台 ARM 的什么东西。每个平台都有自己的原生工具,而它们彼此不说话。
于是全局图景是手工拼出来的,拼在当班那个人的脑子里,材料是一个服务控制台、一个 SSH 会话和主机商的面板。而且只有当有人跑去看的时候才会拼--也就是在事情已经出问题之后。
办公室一台,主机商那儿两台,一朵云上三台,另一朵云上还有一台--因为一次没人做完的迁移,还有分支机构里一台在现任团队到岗之前就装好的机器。每一台都有自己的地址空间、自己的接入路径和自己的负责人。
没有哪一个控制台能覆盖它们全部,因为它们从来不是作为一个整体买回来的。需要的是一个地方,无论每台机器物理上在哪儿,都把它们当成一个整体来对待。
第二组关乎“它是可以被发现的”和“真的有人采取了行动”之间的距离。大多数造成损失的事件,其实自始至终都在日志里可见;失败发生在最后几米,在机器和活人之间。
一个系统发邮件,另一个往聊天频道里发消息,第三个触发 Webhook,主机商发短信,而备份软件把报告放进一个自配置之后就再没人打开过的目录。
什么都关联不起来。同一起事件在四个地方产生了四条名字各异的通知,而意识到它们其实是同一起事件的这份工作,落在了恰好正盯着正确窗口的那个人身上。
一套没有调过的监控会持续不断地告警--夜间任务期间的 CPU 尖峰、一块每周都会越过同一条阈值线的磁盘、一个按设计重启的服务。人们很快就学会这些可以忽略,而且他们是对的--直到那一天他们不再是对的为止。
一旦某个通道已经教会读它的人跳过它,再加告警只会更糟而不是更好。有用的度量不是发现了多少,而是有多少抵达了某个随后真的动手的人。
中小团队不排值班表。懂这些系统的人在睡觉、在飞机上或者在休假,而事件并不在乎这些。因此一切都必须让真正能联系上的人看得懂--包括一个什么都没参与建设的人。
这就对告警必须写清什么提出了硬性要求。凌晨三点,“db-01 CPU 96%”对一个从没登录过 db-01 的人毫无意义;它和什么一起发生、正常又长什么样,才是能修好和打一圈电话之间的区别。
每台服务器都是手工配置的,在不同的时间、由不同的人、带着关于“什么才值得把人叫醒”的不同理解。两年之后没有任何两台机器是一致的,没人记得为什么这台是 85% 而那台是 95%,而要全改一遍就意味着要全跑一遍。
一批机器需要的是另一种东西:一个能层层下发到各处的默认值,加上以“覆盖”形式清楚可见的按主机例外--这样偏差就是一个有人可以复核的有意决定,而不是历史的偶然。
一个暴露在外的 RDP 或 SSH 端口一直在被攻击,而一次猜中的密码,在日志里看起来几乎和一次正常登录一模一样。证据是有的--失败次数上升、陌生的来源、来自新国家的史上第一次成功登录--但它们只是某个没人每天读的文件里的几行。
所以检测必须是机器在做的事,而不是人一个季度做一次的事。真正要紧的窗口是第一次尝试到第一次成功之间的那段时间,而它通常以小时计。
第三组关乎技术团队之外的某个人需要一个答案的时刻。可用率、事件历史和“确实有人在看着”的证据,要么以记录的形式存在,要么根本就不存在--事后是没法凭记忆重建的。
一旦可用率被写进协议,它就不再是一种感觉,而成了一个必须按月拿出来、有争议时要能站得住、并且每次都要用同一种方法计算的数字。“据我们所知它一直在跑”不是测量。
记录也在反方向保护您。多数可用率争议争的是一次故障该算谁的,而一条显示主机健康、同时客户自己的链路却断着的时间线,比任何辩解都更快地结束对话。
网络安全保险的投保申请、供应商安全审查,以及关于支付数据和个人数据的监管框架,问的都是同一件事的不同版本:您凭什么知道系统正按预期运行,而当它们不再如此时,您又会怎么知道。
对方要的不是一个工具的名字,而是证据:在受审期间监管是连续的,告警去到了有人会读的地方,事件被记录下来而不是被记在脑子里。
托管服务商、自由系统管理员和小型 IT 公司,手里握着分布在不同企业、不同服务商、不同网络结构中的数十台机器。每个客户都有自己的营业时间、自己对停机的容忍度,以及自己关于什么算紧急的理解。
一台台手工配置扩展不了,等客户打电话来才发现问题同样扩展不了。这样一批机器需要的是一套到处适用的统一基线、在客户确实特殊之处按客户设置的例外,以及一面能一眼看全的墙。
哪台机器要紧、它上面的正常负载长什么样、哪条告警可以放心忽略、那条阈值为什么在三月被调高--这些都没有写在任何地方。它们由把这一切搭起来的那个人携带着,并随着那个人一起离开。
交接于是变成一场考古,新手接手后的头几个月都花在重新发现一年前本来清清楚楚的事情上。存在于人之外的历史与配置,是对此唯一的防御。
监管本身并非没有风险。任何能从您每一台机器上读取指标的东西,按定义就在您每一台机器上都有一个立足点--而且它可以从外部被访问,因为那正是它存在的意义。
所以“这批机器是怎么被看守的”这个问题,同时也是关于那条通道的问题:谁可以和它对话、双方各自证明什么身份、传输中的数据会发生什么,以及一个被攻陷的控制台会不会把整批机器拱手让人。在任何东西被装到任何地方之前问清楚,是合情合理的。
安全。代理只读取本地指标与自身的认证日志,并通过 TLS 出站连接。它不开放任何入站端口,也没有任何进攻能力。
支持。同一协议驱动 Linux 上的 systemd 单元与 Windows 服务,覆盖 amd64、arm64 与 386。安装脚本会为你检测平台。
每个代理以客户端证书注册,并通过双向 TLS 传输。被盗的注册令牌是短时效的,无法冒充已注册的主机。
全局模板只设一次。每台服务器覆盖单个键;覆盖是叠加在默认值之上而非替换,因此模板变更仍会触达每台主机。
可以。面板以 docker-compose 栈交付,置于 Traefik 之后,搭配 Postgres(TimescaleDB 可选)。参见仓库中的部署指南。
代理在本地监视 RDP 与 SSH 认证,因此能在数秒内标记出活跃攻击及其主要来源 IP,甚至早于面板刷新。
使用Servers Sentinel,我将代理安装为系统单元或 Windows 服务,将其与 mTLS 出站通道连接,并查看最新的遥测和主机运行状况评分。我为缺失数据设置规则,向邮件、Telegram、Slack 或 webhook 发送通知,并检查测试差距;我可以将一台服务器保留为带有电子邮件通知的免费套餐。
免费,无需Servers Sentinel 我运行 blackbox_exporter/Prometheus 或从另一个站点进行 ping/TCP cron 检查,存储 last_seen 并通过 Alertmanager 发送警报。我使用外部安全开关单独检查监控本身,设置正常重新启动的延迟并记录主机的所有者;否则,监控系统丢失显示为绿色状态。
使用Servers Sentinel,我将每个文件系统的已用空间和可用空间收集为时间序列,为特定卷设置一般阈值和单独的覆盖,并在临界值之前发送通知。我查看当前百分比旁边的增长率,检查 Linux 上的 inode,并为 WAL/log 和紧急操作留出足够的余量。
我使用 Prometheus 和 Alertmanager 免费安装 node_exporter/windows_exporter 或通过 cron/Task Scheduler 运行 df/Get-Volume。我同时按百分比和绝对千兆字节发出警告,添加 24-72 小时范围内的速率/预测线性,配置 logrotate/retention 并通过人为填充非关键卷来测试警报。
通过Servers Sentinel,我存储一系列 CPU、内存、磁盘和网络,将主机与其自身的历史记录进行比较,并将当前状态汇总为 0-100 分数。我设置了条件的持续时间,以免对一分钟的峰值做出反应,并在证书持续时间或应用程序响应很重要的情况下创建单独的正常运行时间/TLS/API 检查。
我免费部署 Prometheus、exporters 和 Grafana,设置基线记录规则和可持续增长警报,并使用 blackbox_exporter 检查证书。我存储至少几周的数据,在图表上标记部署/维护,并仅针对相关指标使用率/派生;我支持TSDB并自己规则。
通过Servers Sentinel,我在 amd64、arm64 和 386 上使用 Windows 服务和 systemd 代理的一种协议,获得相同的基本指标和相同的运行状况评分。我在覆盖中保留平台差异,但按风险对整个队列进行排序,并将遥测数据传递给 mTLS,而无需打开代理的入站端口。
我免费将 windows_exporter 和 node_exporter 组合在一个 Prometheus 中,标准化主机/客户端/操作系统标签并构建一个通用的 Grafana 仪表板。我按 UTC 映射 Windows 事件转发和 syslog/Loki,将操作系统的不同阈值描述为代码,并检查更新导出器是否不会在不迁移规则的情况下更改指标名称。
对于Servers Sentinel,我在每台主机上安装一个代理;它自行发起传出连接并由 mTLS 客户端证书进行身份验证。我分配站点和所有者标签,在一个控制台中查看所有主机,并通过逐点覆盖全局设置规则,而无需构建到每台计算机的传入路由。
我免费使用中央 Prometheus 连接 WireGuard 站点和轮询导出器,或使用从外部发送指标的 Remote_write/agents。我将 ACL 仅限制为收集器地址,使用 TLS 证书进行保护,在损坏时缓冲数据,并监控 VPN 本身;我自己负责网络设计和密钥轮换。
借助Servers Sentinel,我可以在一个控制台中创建电子邮件、Telegram、Slack 或 Webhook 通道,发送测试并根据所需的主机向它们发送规则。我使用单个名称和主机上下文,以便操作员看到指标、阈值和时间,而不是从四个独立的字母收集事件。
我免费将 Prometheus Alertmanager 路由到一个通知网关,设置 group_by、group_wait、repeat_interval 和抑制,并为源留下指向一个 Runbook 的链接。我对标签严重性/服务/所有者进行标准化,并使用测试警报检查路线;即使使用免费软件,短信和外部提供商仍可能需要付费。
使用Servers Sentinel,我为标准不同的主机设置全局阈值、条件持续时间和点例外,然后将严重性级别路由到不同的通道。我使用运行状况评分来确定优先级、测试规则并查看尚未采取行动的警报。
我免费维护一个由所有者和运行手册组成的警报目录,在 Prometheus 中使用,在 Alertmanager 中进行分组和抑制,并通过自动完成以静默方式关闭预定工作。我测量通知、确认和重试的数量,删除不可操作的信号,并且不通过简单地提高所有阈值来掩盖噪音。
使用Servers Sentinel,我将严重性和通道分开,将角色/客户端附加到主机名,并且仅在持续违规后配置规则。我通过测试检查消息,在收件人 Webhook 中留下运行手册的链接,并使用指标图/运行状况评估,以便值班人员可以区分一次性峰值和降级。
我免费构建一个 Alertmanager 路由计划,通过可用网关将关键事件发送到呼叫/聊天,并将其余事件发送到每日队列。我编写了包含三个操作、所有者和升级标准的操作手册,添加仪表板链接并定期发出培训警报;免费通话渠道取决于所选服务。
通过Servers Sentinel,我设置了一个全局配置模板,并且在特定服务器上我仅覆盖所需的密钥;覆盖级联在默认值之上,而不是复制整个配置。我将偏差视为例外,更改总体阈值一次并检查哪些主机故意保持不同的值。
我免费将 Prometheus 规则和库存参数存储在 Git 中,生成 Jsonnet/Ansible 规则,并要求进行审查,并说明异常的原因和截止日期。我运行 CI 语法检查、部署配置的差异以及覆盖报告;如果没有这样的纪律,即使是自由堆栈也会很快恢复为手动漂移。
通过Servers Sentinel,我启用本地身份验证检测:Windows 或 Linux 上的代理读取 RDP/SSH 事件并使用顶级 IP 源传输主动攻击。我将规则路由到直播频道并在主机之间匹配一个源;符合条件的付费或试用计划提供检测功能。
我免费收集 Wazuh/Elastic 或 Loki 中的 Windows 4625 和 sshd 失败密码,通过 source_ip 创建滑动窗口的关联,并为后续成功的 4624/Accepted 创建警报。我通过 NTP 同步时间、标准化 IPv4/IPv6 并排除测试扫描仪;自由路径需要单独的收集器和规则支持。
通过Servers Sentinel,我从外部点创建 TCP/TLS/API 检查,存储结果历史记录,并将应用程序不可用与缺少代理遥测分开。我设置 SLO,记录维护并生成有时间限制的定期报告;签字前与客户约定检查间隔、检查区域及排除规则。
我免费在受控站点之外部署 blackbox_exporter 和 Prometheus,将可用性视为成功探测/预期探测并存储 Alertmanager 事件。我在单独的日志中记录维护,同步 UTC 并生成 Grafana 报告;一个验证点并不能证明全局可用性,因此如有必要,我会添加一个独立的探测器。
通过Servers Sentinel,我可以保存指标、正常运行时间检查、规则设置、通道和事件的历史记录,并使用审核日志来查看适当计划上的所有者和策略更改。我上传准确时间段的报告,附上交付测试并解释代理的 mTLS 身份;我注意到数据的缺乏是观察中的一个空白,而不是常态。
我将 Prometheus/Loki/Wazuh 免费存储在安全服务器上,并在 Git 中进行备份、配置和批准,并将事件存储在票证系统中。我每月记录覆盖范围、差距、警报测试和例外情况列表,签署报告并限制访问;没有关闭程序的工具本身并不是控制的证据。
借助Servers Sentinel,我按团队/租户拆分机群,分配查看者、操作员和管理员角色,并应用基本模板(客户端例外)。我按健康评分对所有主机进行排序,向所有者发送通知,并在需要隔离和无限机队的情况下使用业务/自托管选项。
我免费部署单独的 Prometheus 租户/实例,或者在 Grafana 中使用严格的标签和 ACL 隔离数据,将客户端机密存储在不同的保管库中。我从清单生成配置,按租户/所有者路由 Alertmanager,并测试阻止交叉访问;安全多租户比一个共享仪表板需要更多的工作。
使用Servers Sentinel,我可以按角色和所有者对主机进行签名,存储指标系列、全局模板和显式覆盖,并将通道与所有者相关联。我使用历史记录作为基线,在变更流程旁边记录非标准阈值的原因,并在转移权限之前为新操作员授予仅查看角色。
我免费在 Git 中维护清单和操作手册,为每个覆盖添加仪表板链接、所有者、依赖项和理由,并通过拉取请求接受更改。我将 Grafana/Prometheus 配置存储为代码,标记部署/维护,并将事件转移给另一名员工,每季度一次;如果没有组织实践,图形本身就无法保留知识。
对于Servers Sentinel,我使用双向 TLS 出站连接:每个代理都会收到客户端证书,并且短期连接令牌不会替换已颁发的身份。我检查服务权限、收集的指标和日志列表,禁用不必要的操作,在一台主机上部署试点,并在删除服务器时控制证书的吊销。
免费地,我在单独的非特权帐户下安装node_exporter/windows_exporter,仅监听localhost/VPN并限制收集器集。我使用 TLS/mTLS 或网络 ACL 保护抓取、签署数据包、提交版本、扫描更新,并且不启用从不受信任的来源写入的文本文件脚本;我将配置管理与监控分开。
在生产服务器群中以管理员权限部署任何东西之前,这三个问题值得先有答案。
Servers Sentinel 由 Recovery Toolbox 首席服务器安全专家 Victor G. Bobrov 编写:20 多年系统开发与安全经验,持有 Microsoft MCSD/MCDBA 认证。健康评分、告警规则以及本站的文档都是他的工作,以本人署名发布,而不是匿名品牌。 文档 →
供应商是在保加利亚(欧盟)注册的 File Master LLC:Bulstat/VAT 180842207,办公室位于瓦尔纳,可通过电话与邮件联系。付款由 PayPro Global 作为登记商户处理;服务条款、隐私政策和数据处理协议均全文公开,而非概要。 服务条款 · 隐私 · DPA
代理程序读取本地指标和所在主机自己的认证日志,并通过双向 TLS 向外发送。它不开放任何入站端口,也没有远程命令通道:外部无法指使它在你的服务器上执行任何东西。每个代理都用客户端证书注册,注册令牌是短期的 —— 即使被窃取,也无法冒充已注册的主机。面板本身以 docker-compose 栈的形式提供,可以运行在你自己的硬件上。 安装代理 →
服务器群监控并不是一个独立话题:它处在所监控的平台、先于它存在的工具,以及衡量服务器的标准之间。以下是定义它们各自的来源。
链接指向来源本身:实体有标识符时指向 Wikidata,没有时指向一手资料。
Recovery Toolbox 与 File Master LLC 的联系方式,以及公司首席安全专家 Victor G. Bobrov 的简介。
File Master LLC 是 Recovery Toolbox 在线服务和软件产品背后的法律实体。
File Master LLC 开发并维护 Recovery Toolbox 的在线服务和软件产品,用于修复损坏的文件、数据库和邮件存储格式。公司专注于为需要恢复损坏数据访问权限的用户、IT 专业人员和企业提供实用的恢复工具。
欢迎您的意见和建议。请通过电子邮件向我们发送对网站的反馈: webmaster@recoverytoolbox.com

服务器安全专家 · 20 多年系统开发与安全经验
Victor G. Bobrov 在 File Master LLC / Recovery Toolbox 负责安全研发。他定义了 Servers Sentinel 在服务器群中监视的内容:由主机指标得出的健康评分、认证日志中的暴力破解活动、相对 CIS 基线的配置漂移,以及必须在管理员察觉异常之前触发的告警。
Microsoft Certified Solutions Developer - MCSD。Microsoft Certified Database Administrator - MCDBA。