自动化脚本生成等保三级端口与服务合规报告需覆盖网络架构安全、访问控制、入侵防范三类测评项，精准映射GB/T 22239-2019条款8.1.3.1、8.1.3.2、8.1.4.2，输出含原始证据与整改路径的结构化JSON及监管认可PDF报告。
直接用自动化脚本生成等保三级端口与服务合规报告，关键在于覆盖“网络架构安全”“访问控制”“入侵防范”三类测评项，精准映射到《GB/T 22239-2019》条款8.1.3.1、8.1.3.2、8.1.4.2，并输出可验证的原始证据和整改路径，而非仅罗列开放端口。
明确等保三级对端口与服务的核心要求
脚本需逐项验证以下条款，不能只做“端口扫描”，而要结合策略意图判断是否合规：
- 8.1.3.1 网络架构安全：关键业务系统应部署在独立网段，边界设备（如防火墙、WAF）须实施访问控制策略，禁止非必要端口暴露于互联网；
- 8.1.3.2 访问控制：服务器自身应限制服务监听范围（如绑定127.0.0.1而非0.0.0.0），且仅启用必需服务（如禁用telnet、rlogin、rpcbind）；
- 8.1.4.2 入侵防范：高危端口（如21/FTP、23/Telnet、139/SMBv1、445/SMB）若存在，必须有明确业务依据、访问白名单及日志审计支撑。
设计能落地的端口与服务巡检逻辑
脚本需分层采集、交叉验证，避免单点误判。例如仅用ss -tuln看到22端口开着，不等于SSH配置合规——还要查/etc/ssh/sshd_config是否禁用密码登录、是否限制IP。
- Linux环境：用
ss -tuln获取监听端口及绑定地址，结合ps aux --forest匹配进程名与服务版本；调用systemctl list-unit-files --state=enabled识别开机自启服务；对SSH、Nginx、MySQL等关键服务，单独检查其配置文件中监听地址、认证方式、TLS版本等细节； - Windows环境：用
Get-NetTCPConnection -State Listen获取端口，配合Get-Service | Where-Object {$_.StartType -eq 'Automatic'}识别高危自启服务（如PrintSpooler、Server）；对IIS站点，调用Get-IISSiteBinding确认HTTPS是否启用且TLS 1.2+； - 统一输出结构化JSON，每项含：
port（端口号）、protocol（tcp/udp）、bind_addr（监听地址）、service_name（服务名及版本）、status（pass/fail/warn）、evidence（命令+原始输出片段）、clause（对应等保条款，如“8.1.3.2”）。
生成监管认可的正式报告
报告不是截图合集，而是具备审计追溯能力的交付物，必须包含以下要素：
- 封面页注明系统名称、资产IP、扫描时间、脚本版本（如
port-audit-v3.2.1）及运行环境（CentOS 7.9 / Windows Server 2019）； - 主报告按等保条款分节，每项用三栏表格呈现：“检查项（含条款编号）”“实际结果（附命令与截取输出）”“判定依据（引用标准原文或等保实施指南）”；
- 失败项单独汇总为“整改建议表”，明确写出修复动作，例如：“端口21（FTP）开放 → 建议停用vsftpd服务：systemctl stop vsftpd && systemctl disable vsftpd；若确需使用，应迁移至SFTP并配置IP白名单”；
- 附件包含原始端口清单（CSV）、服务进程树（TXT）、关键配置文件关键行（如
/etc/ssh/sshd_config中ListenAddress和PasswordAuthentication行）、以及近7天相关服务的审计日志抽样（带时间戳与事件ID）。
让报告真正驱动整改闭环
一份好报告要能被运维快速执行、被审计方快速采信：
- 所有修复命令标注适用环境（如“仅适用于RHEL/CentOS 7+”），并附上回滚方式（如“执行前已自动备份/etc/vsftpd/vsftpd.conf至/etc/vsftpd/vsftpd.conf.bak.1745834220”）；
- 对“需人工确认”的项（如某端口是否属历史遗留系统），脚本输出
status: pending并提示“请业务负责人签字确认该端口用途及替代计划”； - 支持定时执行（crontab每日凌晨触发），失败项自动推送企业微信消息，含跳转链接直达对应报告章节；
- 报告PDF文件末页嵌入SHA256哈希值，便于后期司法存证时校验完整性。
