Heartbleed风险排查关键在于验证Nginx加载的OpenSSL库版本是否为1.0.1a–1.0.1f且未修复，需通过ldd查实际so路径、version命令确认编译时间与版本，并用nmap或openssl工具主动探测；修复后必须彻底重启Nginx并轮换密钥。
排查 Nginx 服务是否存在 Heartbleed（CVE-2014-0160）历史遗留风险，核心不是查 Nginx 本身，而是查它所链接的 OpenSSL 库版本是否在漏洞影响范围内。Nginx 自身不实现 TLS 心跳逻辑，完全依赖底层 OpenSSL 动态库。只要 OpenSSL 是 1.0.1a 到 1.0.1f 之间的任意版本，且未打补丁或重编译，就存在风险。
确认当前 OpenSSL 实际运行版本
不能只看系统包管理器显示的版本号，必须检查 Nginx 进程实际加载的 OpenSSL 库：
- 先查 Nginx 主进程 PID：ps aux | grep nginx | grep master
- 再用 ldd 查其依赖的 libssl.so 路径：ldd $(which nginx) | grep ssl
- 最后读取该 so 文件的编译信息：/path/to/libssl.so.1.0.0 version -a（注意路径要替换成上一步结果）
- 重点关注输出中的 built on 和 OpenSSL version 字段；若显示为 1.0.1f 或更早、且 built on 日期早于 2014年4月7日，则极可能未修复
使用主动探测工具验证服务端响应
即使 OpenSSL 版本看起来已更新，也可能因静态编译、多版本共存或容器镜像固化导致实际服务仍带毒。需对监听 HTTPS 的端口做协议级探测：
- 用 nmap 执行标准脚本：nmap -sV -p 443 --script ssl-heartbleed example.com
- 用 openssl 命令行手工触发心跳（需支持 heartbeat 的客户端）：openssl s_client -connect example.com:443 -tlsextdebug 2>&1 | grep -i "heartbeat"，再配合自定义 payload 工具（如 testssl.sh）进一步验证
- 避免依赖在线检测网站，因其无法反映内网或非公网暴露服务的真实状态
检查构建环境与部署包来源
很多历史遗留风险藏在不可见的构建环节：
- 查看 CI/CD 流水线中是否固定了旧版 OpenSSL Docker 镜像（例如 nginx:1.10-alpine 默认含 OpenSSL 1.0.1r）
- 检查 RPM/DEB 包的 changelog：rpm -q --changelog openssl | head -20，确认是否包含 CVE-2014-0160 修复记录
- 若使用自编译 Nginx，核实 configure 时是否指定 --with-openssl= 路径，该路径下的源码是否已更新到 1.0.1g 或更高
修复后必须验证内存是否清零
Heartbleed 不仅是远程代码执行类漏洞，更是内存泄露型漏洞。即使升级完成，若未重启服务，旧进程仍可能持有含私钥、会话令牌的内存页：
- 执行 nginx -s reload 不足以清除漏洞影响，必须 kill -TERM `cat /var/run/nginx.pid` && nginx 彻底重启主进程
- 建议同步轮换所有可能已泄露的密钥：SSL 私钥、JWT 签名密钥、数据库连接密码、API Token
- 检查日志中是否有异常大量 TLS 握手失败或心跳请求激增——这可能是攻击者已在持续扫描的迹象
