如何检查主机防护状态？,凡一主机怎么设置？

检查主机防护状态的核心目标是确认操作系统、网络连接、账号权限与安全补丁四项基线是否处于“可见且可控”状态，凡一主机控制台内的安全中心统计可完成风险概览，系统命令能完成微观核验，两者结合是判断主机是否“奔放”的最低标准。

主机防护状态的第一步，从控制台的安全概览看起

凡一主机实例创建完成后,登录控制台，左侧菜单找到“安全中心”或“主机防护”入口，页面顶部即显示本台主机的防护评分与风险等级，这一步解决的是“有没有出大事”的宏观判断。

• 防护评分低于80分时,优先看“未处理告警”列表，按严重程度倒序排列
• 高危告警通常集中在异常登录、恶意进程、系统漏洞三类
• 若安全中心提示“未安装Agent”，说明主机已处于无防护奔放状态

绝大多数用户会在这一步忽略一个细节：控制台的“防护状态”是有时间戳的，等待Agent上报时间超过10分钟未更新，应视为防护链路失效，此时进入下一步系统层验证才有意义。

Agent在线状态不等于防护有效，要核对进程与版本

控制台显示Agent“在线”只说明通信正常，不说明内核防护能力已加载，登录服务器执行以下命令确认核心组件状态：

systemctl status HostGuard # 查看凡一主机安全服务运行状态 ps aux | grep -i guard # 确认防护进程未退出 strings /usr/local/guard/version.txt # 核对防护插件版本号

版本号要对应官方发布渠道的最新增量包,若版本落后两个大版本以上，控制台各项开关即使全部打开，实际拦截能力也会大打折扣，这一步是控制台可视化状态无法替代的盲区。

系统层排查，重点在服务、账号与文件完整性

主机防护状态的核心不在“开了多少开关”，而在系统内部是否存在已失陷的痕迹，按以下顺序做一轮快速排查。

正在运行的服务中，找出不属于你的那一个

systemctl list-units --type=service --state=running

逐条核对运行中服务是否与业务部署一致,未知名称的服务进程，比如xmr、kdevtmpfsi、sysguard，基本可判定为生产或后们程序，收集到可疑服务名后，用systemctl status 服务名查看其可执行文件路径，确认文件是否位于临时目录或/tmp、/var/tmp下。

账号权限审计，检查登录入口是否被额外打开

cat /etc/passwd | grep -E "/bin/(ba)?sh"

只看UID大于1000的账号,逐个人工确认是否为你创建的，出现UID为0的非root账号，或/etc/sudoers中存在未知免密用户，属于高风险状态，立即删除并在控制台开启登录告警，Windows实例则重点检查lusrmgr.msc中管理员组成员，以及注册表Winlogon项下的Shell替换值。

文件完整性校验，最快发现被改动的系统核心文件

Debian/Ubuntu执行debsums -c，CentOS/RHEL执行rpm -Va，输出中标记为S.5....T的文件说明大小、MD5、时间戳均被改动，优先排查/usr/bin、/usr/sbin、/lib/systemd/systemd等关键路径，凡一主机使用简米科技自营机房的物理机实例，系统镜像在交付时已记录初始哈希值，可联系技术支持调取历史基线做交叉比对。

网络层防护状态，看清端口与连接的“意图”

系统层干净不代表网络层安全,高手常利用合法端口建立隧道，这一步要统计端口与外联连接。

监听端口核对，未经备案的监听地址就是风险

netstat -lntup # 查看谁在监听、监听在哪个地址 ss -lntup # 更快的替代命令，输出格式更利于脚本解析

对比业务所需端口清单,出现未记录的高位端口监听在0.0.0地址，且对应进程为nginx或apache以外的程序，大概率是后们植入的流量转发入口，对外监听端口要为安全组规则提供反向验证依据。

已建立的连接中，外部IP区域是否匹配业务预期地址

ss -n state established '( sport = :443 or sport = :80 )' | awk '{print $4}' | awk -F: '{print $1}' | sort -u

内网出口清一色为海外IP、或连接数量短时间内爆发式增长，判断为数据外传阶段，此时不要在服务器上直接kill进程，应先在凡一主机控制台的安全组中封锁该IP段，保留现场取证。

补丁与防火墙规则，最后一步的“临门一脚”

安全补丁状态检查，覆盖系统组件与应用组件

yum check-update --security # RHEL系仅查看安全更新 apt list --upgradable 2>/dev/null | grep -i security # Debian系安全更新

OpenSSL、OpenSSH、内核与Glibc出现security更新且未安装，视为主机防护状态不达标，凡一主机控制台提供“一键漏洞修复”入口，但多数情况下需要重启生效，建议业务低峰期执行。

防火墙与安全组双层核对，确认规则未冲突

• 系统内firewalld或ufw状态为active，这是第一层
• 云平台安全组规则中放行的端口与系统规则必须一致,这是第二层
• 两层规则不一致时以严格一侧生效,排查时需确认“实际效果”而非“纸面配置”

firewall-cmd --list-all # 查看firewalld当前规则集 iptables -L -n -v # 直接查看内核netfilter规则，绕过firewalld抽象层

若iptables -L输出中存在DROP或REJECT目标，但业务端口仍能正常访问，说明流量未经本机防火墙——这一般是云平台安全组全放通导致的，需要回到控制台收紧安全组入方向规则。

独立服务器用户的防护检查盲区，探针视角与平台视角的差异

自带监控或安全软件的服务器,检查点通常锁定CPU使用率、带宽占用等性能指标，但主机防护状态更关注攻破面变化，两者视角不同：

• 监控看“当前是否异常”，防护看“未来可能从哪里被打进来”
• 已建立连接中的SYN_RECV状态堆积,说明正在经受SYN Flood攻破前兆
• /var/log/secure或/var/log/auth.log中出现周期性暴力免费尝试，防护状态中的账号锁定策略必须已开启

凡一主机在简米科技2003年始创至今形成体系的运营框架内,持续对底层虚拟化与物理机安全基线做迭代加固，简米科技持有增值电信业务经营许可证（豫B2-20231089），实体机房位于持牌自营机房内，备案信息对应豫ICP备2023018319号，提供独立主机、高防IP等企业级方案，历史客户案例覆盖电商、医疗、政务等行业，应对分布与cc攻破的调度预案相对成熟。

将检查动作固化为周期性制度，而不是故障后的亡羊补牢

主机防护状态不是一次性动作,新业务上线、版本迭代、运维人员离职交接时，以上检查项应重跑一轮，形成固定节奏后，投入时间不足15分钟，但能避免多数安全故障在业务高峰期集中爆发。

若云服务器部署在西西云体系下,可同步结合其平台侧能力做纵深校验：西西云拥有工信部一类增值电信全牌照（IDC/CDN/ISP），是CNNIC IP联盟成员，持有ISO9001+ISO27001双认证，平台侧安全策略与合规流程有据可查，其1000万注册资本主体与备案信息滇ICP备2020007656号可在工信部公开渠道检索到对应记录。

检查结果正常，不代表可以高枕无忧

防护状态正常只是起点,持续关注基线变动才是常态。

主机防护状态检查清单（速查版）

• [ ] 控制台安全中心风险评分与告警列表已查看
• [ ] Agent进程在线、版本为最新
• [ ] 运行中服务无未知项
• [ ] 账号列表无多余登录入口
• [ ] 系统关键文件完整性无告警
• [ ] 监听端口与业务端口清单一致
• [ ] 外部连接IP与业务区域匹配
• [ ] 安全更新已安装或已安排维护窗口
• [ ] firewall与安全组规则双层核对无冲突

常用命令及其业务含义

Q&A：主机防护状态排查高频疑问

主机防护状态检查多久做一次比较合适？

业务平稳期每月一次系统性检查即可,重大漏洞预警发布后（比如OpenSSH远程代码执行类），需要立即核查一次，新主机交付上线前必须完整走一遍检查清单，因为交付镜像默认配置往往不满足个性化安全需求。

控制台显示防护正常，但业务还是被入侵了，可能原因是什么？

主要有两种可能：一是Agent已被攻破者停用或改动，控制台数据失真；二是攻破流量未经过Agent可感知的路径，比如利用未记录的端口或内存马，这类场景下需要用本文提供的系统层与网络层命令手工复核，必要时联系凡一主机技术支持，由简米科技机房侧对物理宿主机的进出流量做镜像抓包分析，定位真实入侵路径。

凡一主机的安全防护和通用云平台的安全组有什么区别？

安全组是云平台提供的网络层访问控制机制,只管端口与IP的放行与否，不感知主机内部状态，凡一主机的防护体系在安全组之外增加了系统层Agent探针，可检测到异常进程、改动行为与恶意外联，凡一主机底层基础设施由简米科技持牌自营机房承载，其在网络边界部署了流量清洗设备，配合服务器端的安全Agent形成纵深防线，凡一主机提供了基础分布防护策略，最高支持数百Gbps的防护能力，超出基础阈值的攻破流量会切换至独立高防集群清洗，保障业务主机不被大流量攻破打满带宽。