1. 它解决的痛点为什么说一份完整的网站情报不该靠二十个工具拼做网站运营、搞安全巡检、或者单纯想弄明白竞争友商的站是用什么技术搭的你都得干同一类事情——把目标站点的技术栈、DNS、证书、响应头、端口开放情况、SEO配置全部摸一遍。我早些年干这个靠的是浏览器开七八个标签页线上工具换了一个又一个数据还不能批量导出后来干脆自己写脚本调API。麻烦不说每次换一个域名整套流程就得重新来一遍。Web-Check就是冲着这个痛点来的。它是一个开源的一站式网站侦查/体检工具输入一个域名几分钟后给你一份相当完整的分析报告。它把网站信息收集中最常用的一二十项检测整合到了同一个页面里DNS记录、SSL证书、HTTP响应头、安全头、技术栈识别、WHOIS、服务器地理位置、端口扫描、子域名枚举、SEO配置等等基本覆盖了一个网站从外层到内层的所有可见信息维度。项目作者是lissy93代码托管在GitHub上Star涨得很快社区活跃度也高发布以来迭代频率一直没降过几乎每个月都有新检测模块加进来。它支持三种用法直接用官方部署好的在线实例、自己部署到服务器上、以及把它暴露出来的API接进自己的自动化流程里。对谁最有用我总结下来是三类人第一类是管站站长定期给自家站点做安全体检和SEO健康检查第二类是安全从业人员在授权范围内做初步信息收集和暴露面梳理第三类是前端和运维工程师想快速摸清一个陌生站点的技术构成或者排查自己和第三方服务的交互关系。先给一个边界声明Web-Check做的是被动信息收集加基础主动探测定位是侦查工具不是漏洞扫描器。它能告诉你目标有哪些暴露面但不会告诉你某个漏洞能不能打进去、怎么打。做安全测试的时候它通常当第一站用后面还要接专门的漏洞检测工具。另外所有探测动作都必须在授权范围内进行这个原则后面我会专门再强调一次。2. 本地部署实录从clone到跑起来会遇到的那些事2.1 环境要求与版本选择Web-Check是基于Node.js的全栈应用前端用React后端是Express本地部署的整体思路很简单拉代码、装依赖、起服务。官方的部署要求是Node.js 18以上npm配套。我建议直接用LTS版本因为项目依赖更新频繁太旧的Node运行时会在安装依赖的时候报语法错误排查起来挺浪费时间。如果你是第一次用推荐直接走官方Docker方案这是我认为最省事的一条路径docker pull lissy93/web-check docker run -d -p 3000:3000 --name web-check lissy93/web-check跑起来之后浏览器访问http://localhost:3000就能看到输入框。这种方式干净利落本地验证功能适不适用两分钟就能出结果。但如果你有二次开发、接API key、或者要改检测逻辑的需求我建议还是用源码方式部署我下面详细说源码部署的完整过程。2.2 源码部署的完整步骤git clone https://github.com/lissy93/web-check.git cd web-check npm installnpm install这一步在部分网络环境下可能比较慢项目依赖里有不少前端构建相关的包挂代理或者换npm镜像源都可以解决。装完之后直接启动npm run build npm start默认监听3000端口。启动日志里会打印出监听地址看到Server running at http://localhost:3000就算成功了。这里有个小细节值得注意npm start之前一定要先执行npm run build因为前端资源需要先编译到静态目录跳过这步直接start页面会白屏或者报静态资源404。我第一次部署就吃亏在这个顺序上以为start会自动构建结果页面出来是个空壳。如果你不想每次手动build项目也提供了开发模式npm run dev前后端带热更新适合改代码的场景。我个人的经验是线上用生产模式本地调试用dev模式两套流程分开走比较舒服。2.3 可选的环境变量与外部API配置Web-Check默认不配置任何外部API也能跑通大部分检测但有几个模块的准确度和覆盖范围高度依赖外部数据源。官方预留了这些环境变量入口我实际配置过的几个SHODAN_API_KEY你的key VT_API_KEY你的key C99_API_KEY你的key GOOGLE_SAFE_BROWSING_KEY你的key配置方法是在项目根目录新建一个.env文件填上对应的key然后重启服务。Shodan的key可以让端口扫描模块的数据更全VirusTotal的key能让域名信誉检测生效。不配也能跑但相关模块会显示数据不可用或者结果非常粗体验差一截。不需要为了齐全把所有key都配齐按需来就行。我实际用下来Shodan和Google Safe Browsing这两个比较值得配前者补强端口数据后者补强域名安全信誉其他几个看需求再说。2.4 Docker部署的补充细节Docker方式部署时如果想要配置环境变量用-e参数传进去docker run -d -p 3000:3000 \ -e SHODAN_API_KEYyour_key \ --name web-check lissy93/web-check镜像更新的频率也挺快的建议定期docker pull lissy93/web-check更新到最新版。有一次我跑了一个多月没更新新出的DNS安全扩展检测和证书透明度日志查询模块在老版本里完全没有更新之后功能列表直接多了一截。3. 检测模块逐个拆解每个功能背后的原理和读法3.1 DNS记录与子域名枚举域名层面能暴露的信息打开Web-Check输入一个域名第一个出结果的就是DNS记录区。这里会列出A、AAAA、MX、NS、TXT、CNAME、CAA等常见记录类型。每条记录的读法各有门道A/AAAA记录告诉你域名解析到了哪台服务器MX记录暴露了邮件服务商是谁TXT记录里通常藏着SPF验证串、域名所有权验证串这些都能反映站点背后的基础设施选型。子域名枚举是Web-Check里比较有特色的一块它内置了一份常见子域名字典通过批量DNS查询的方式探测mail.、ftp.、api.、dev.、admin.这类前缀是否存在解析记录。这个功能的实用价值在于很多运维会把内部系统放在不容易被发现的子域名上主站防护严密子站却可能暴露在公网。当年我帮一个朋友排查他家站点的信息泄露问题时就是靠子域名枚举找到了一台未做访问控制的测试环境服务器。3.2 HTTP头与安全头分析一眼看出站点防护水平HTTP响应头这一块Web-Check会把服务器返回的所有响应头字段列出来同时专门高亮安全相关的头。重点看这几个Strict-Transport-SecurityHSTS有没有强制HTTPS值有没有设合理Content-Security-PolicyCSP有没有限制资源加载来源X-Frame-Options有没有防点击劫持X-Content-Type-Options有没有防止MIME类型嗅探Referrer-Policy有没有控制Referrer泄露我给过一个判断经验只配了X-Frame-Options和X-Content-Type-Options的站点属于基本防御加上HSTS和CSP的属于认真做过安全如果再配上Certificate Transparency策略和CAA记录说明站点对证书体系的管理已经比较成熟了。这套观察方法在Web-Check的一个页面上就能快速完成比手动curl然后一条条查省太多时间。3.3 SSL/TLS证书链检查证书层面翻出全部细节证书检测模块会展示完整的证书链信息证书签发者Issuer、有效期、SANSubject Alternative Name里包含的所有域名、证书指纹、使用的签名算法以及TLS协议的最低/最高版本。最有用的场景是排查证书覆盖遗漏——有些站点主域名证书正常但某个子域名证书过期了肉眼访问主站根本看不出来Web-Check会把你输入域名关联的证书信息全列出来哪些子域共用证书、哪些是单独的证书一目了然。还有一个我经常用的点通过证书透明日志Certificate Transparency区可以看到这个域名历史上被签发过多少证书。如果某天你的域名突然多了一堆来路不明的证书签发记录那大概率是域名控制权出问题了这是个很重要的预警信号。3.4 技术栈识别知道你面前站点是用什么搭的技术栈检测模块会尽力识别站点的编程语言、Web服务器、前端框架、分析工具、广告系统、CDN服务商等信息。原理是分析响应头、HTML源码特征词、JS文件路径模式、Cookie名称等指纹。识别结果会按类别标签展示比如NGINX、React、Cloudflare、Google Analytics这样。这个模块对前端和运维工程师特别有用。排查线上问题和第三方脚本冲突的时候先跑一次Web-Check确认对方的部署形态比自己瞎猜省事得多。比如看到CDN标签你就知道网络层面的问题得先从CDN节点排查而不是傻乎乎地盯着源站。3.5 端口扫描与服务器定位了解暴露面大小端口扫描模块会探测一批常用端口如21、22、25、53、80、443、445、3306、3389、5900、8080等是否有响应输出结果能快速判断服务器的暴露面大小。比如一个站点如果22、3306、3389全开着那运维的网络安全意识就需要打个问号了。服务器定位模块则通过IP地理位置数据库显示服务器所在国家和城市配合WHOIS信息基本能拼出一个站点的托管网络和大致物理位置。这里有个经验要分享端口扫描的结果受网络环境影响很大如果你和目标服务器之间有防火墙策略扫出来的可能是全关或者部分关这不是工具不准而是路径被过滤了。看到异常结果先换个网络环境复测一遍再下结论。3.6 SEO与巡检相关项robots.txt、sitemap、重定向链Web-Check还包含了robots.txt分析、sitemap检测、页面重定向链追踪这些偏SEO侧的检查。重定向链一定要重点看有些网站在一个URL上做了三四次302跳转才到最终页面不仅拖慢访问速度对搜索引擎的爬取也不够友好。Web-Check会把完整的跳转链路画出来每一跳的中间URL和响应码都看得清清楚楚。4. 案例演示实测一个技术博客的完整输出为了让你对这份报告的完整程度有个直观认识我拿自己部署实例实测了一个小型技术博客域名。输入域名点击Recon按钮大约15秒后各个模块分批返回结果。以下是我看报告时的关注点记录。DNS记录区显示该域名的A记录指向某云厂商的IPMX记录指向企业邮服务商TXT里有SPF和验证串。WHOIS信息显示注册商和创建时间是2019年。SSL证书显示是Lets Encrypt签发的90天证书SAN里有根域名和www子域名说明证书是定期自动续期的。HTTP头分析里安全头中HSTS已启用但max-age只有一个月CSP缺失。技术栈识别出Ghost框架、NGINX反向代理、CDN加速。端口扫描显示80、443开放22也开着但返回的是ban信号判断为云厂商默认安全组策略。robots.txt中屏蔽了部分后台路径sitemap正常生成重定向链从http到https一跳完成。整个分析过程大概十来分钟我把关键发现总结成一张表存档检测模块实际结果判断TLS证书Lets Encrypt剩余有效期充足正常自动续期HSTS已启用max-age较短建议加长CSP缺失有安全隐患技术栈Ghost NGINX CDN信息完整端口80/443/2222被过滤正常范围重定向链1跳健康这张表的产出过程如果不用Web-Check我得开五六个工具页面才能拼齐而现在一次搞定。对管站的人来说这就是一份随时可以存档和对比的体检单。5. 架构与API接口把它接进自己的自动化体系Web-Check做完端到端页面展示之后其实每个检测项后端都对应一个独立的API端点。这意味着你完全不必依赖它的前端页面可以直接把API接进自己的脚本或者监控平台里。我实际用过的几个接口路径大致如下服务起来之后可以通过HTTP GET请求直接调用# 获取DNS记录 curl http://localhost:3000/api/dns?hostexample.com # 获取HTTP头 curl http://localhost:3000/api/http-headers?urlhttps://example.com # 获取TLS证书 curl http://localhost:3000/api/ssl?hostexample.com # 获取端口扫描结果 curl http://localhost:3000/api/ports?hostexample.com # 获取技术栈 curl http://localhost:3000/api/tech-stack?urlhttps://example.com把Web-Check的API接进定时任务就能实现一个轻量的站点巡检系统。我自己写过一个小脚本每周末跑一次公司几个重点站点的DNS、证书、端口、安全头四个模块结果和上周对比有变化就推送通知到企业群里。证书快过期、安全头被意外改动、新增异常端口开放这些都是高频触发项。这套小系统上线之后避免过一次因为证书忘记续期导致的线上告警事故价值立刻回本。接API的时候注意频次控制Web-Check部署实例没有内置太复杂的限流机制如果你是单机自用无所谓但如果开放给团队用一定要在外面套一层Nginx限流不然有人写个for循环批量扫域名后端资源很容易被打满。这算是我踩过一次的坑。另外就是它支持把多个检测模块的结果汇总成JSON输出方便二次处理。对熟悉脚本处理的同学来说这是比网页报告更好用的交互形态。6. 实际使用中那些坑我的排除经验汇总6.1 端口扫描结果的误判Web-Check的端口扫描用的是TCP连接探测目标服务器如果部署了防火墙或者IDS可能会主动丢弃探测包或者返回伪造的关闭信号。我第一次用的时候扫一个内网穿透服务端口明明在跑工具却显示关闭排查了半天才发现是中间设备拦截了非标准端口的连接请求。遇到异常结果先用在线端口检测站点交叉验证再判断是自己误读还是目标确实有变化。6.2 外部API的配额限制配置了Shodan或VirusTotal的key之后检测速度和结果完整度确实有明显提升但免费方案都有每日查询量上限。一旦配额耗尽对应模块会静默降级不会报错表现就是某天突然结果变少了。如果依赖它做定期巡检建议记录每天查询量或者直接用付费方案免得到期了还以为是工具故障。6.3 子域名枚举的噪音数据子域名枚举基于词典爆破结果里会有一些能解析但没有实际服务的域名记录。有些是泛解析造成的——目标DNS把所有不存在的子域都解析到同一个IP上这种情况下枚举报告会显得特别丰满但实际没有意义。判断方法也简单如果几十条子域结果全都指向同一IP基本就是泛解析筛选掉只看真正有不同解析目标的记录就行。6.4 部署环境的时区与日志自部署之后日志默认按服务器本地时区输出。如果你和我一样习惯用UTC8时间看问题记得部署时就把系统时区设置好不然后续排查问题对时间线会非常痛苦。虽然是个不起眼的小事但运维层面很影响效率。还有一点想特别提醒Web-Check这类工具能力很强单输入一个域名就能翻出大量信息。用在自己授权的站点上那叫巡查和管理用在别人没授权的目标上性质就完全不同了。我自己的原则是只对自有资产、客户明确授权范围内的资产、以及公开信息研究场景使用绝不拿它去对无关目标做批量探测。工具本身是中性的怎么用取决于使用者。7. 自建还是用现成我的最终建议最后说下使用形态的取舍思路。如果你只是偶尔分析一两个域名直接用官方线上实例就够了省去部署和维护成本。如果分析频次高、涉及敏感站点信息不想经过第三方在线服务或者想把结果接进自己的自动化体系那就老老实实自己部署一份。Docker方案全流程下来不到十分钟维护成本也不高定期拉新镜像就行。从性价比角度看我认为自部署是更值得推荐的路径原因不仅是数据隐私更在于你能通过二次开发给Web-Check加上自己的检测逻辑。我自己就在它的后端基础上加过一个自定义的关键资源变更监控接口专门盯自己站点的几个关键JS文件名是否变化——这个需求官方版本没有但因为它架构清晰、模块解耦扩展起来并不困难。开源工具的价值不只是开箱即用更是给你一个可以自由裁剪的底座这是商业SaaS给不了的东西。如果你打算正式把它用起来我的建议就一句话先跑一遍官方实例摸清每个模块输出什么结果再自部署一份配好环境和必要API最后按自己的巡检场景接进脚本或告警系统。走完这三步你手里就有一套完全属于自己、可以持续积累数据资产的信息收集基础设施了。
开源网站侦查工具Web-Check：一站式信息收集与自部署实战
1. 它解决的痛点为什么说一份完整的网站情报不该靠二十个工具拼做网站运营、搞安全巡检、或者单纯想弄明白竞争友商的站是用什么技术搭的你都得干同一类事情——把目标站点的技术栈、DNS、证书、响应头、端口开放情况、SEO配置全部摸一遍。我早些年干这个靠的是浏览器开七八个标签页线上工具换了一个又一个数据还不能批量导出后来干脆自己写脚本调API。麻烦不说每次换一个域名整套流程就得重新来一遍。Web-Check就是冲着这个痛点来的。它是一个开源的一站式网站侦查/体检工具输入一个域名几分钟后给你一份相当完整的分析报告。它把网站信息收集中最常用的一二十项检测整合到了同一个页面里DNS记录、SSL证书、HTTP响应头、安全头、技术栈识别、WHOIS、服务器地理位置、端口扫描、子域名枚举、SEO配置等等基本覆盖了一个网站从外层到内层的所有可见信息维度。项目作者是lissy93代码托管在GitHub上Star涨得很快社区活跃度也高发布以来迭代频率一直没降过几乎每个月都有新检测模块加进来。它支持三种用法直接用官方部署好的在线实例、自己部署到服务器上、以及把它暴露出来的API接进自己的自动化流程里。对谁最有用我总结下来是三类人第一类是管站站长定期给自家站点做安全体检和SEO健康检查第二类是安全从业人员在授权范围内做初步信息收集和暴露面梳理第三类是前端和运维工程师想快速摸清一个陌生站点的技术构成或者排查自己和第三方服务的交互关系。先给一个边界声明Web-Check做的是被动信息收集加基础主动探测定位是侦查工具不是漏洞扫描器。它能告诉你目标有哪些暴露面但不会告诉你某个漏洞能不能打进去、怎么打。做安全测试的时候它通常当第一站用后面还要接专门的漏洞检测工具。另外所有探测动作都必须在授权范围内进行这个原则后面我会专门再强调一次。2. 本地部署实录从clone到跑起来会遇到的那些事2.1 环境要求与版本选择Web-Check是基于Node.js的全栈应用前端用React后端是Express本地部署的整体思路很简单拉代码、装依赖、起服务。官方的部署要求是Node.js 18以上npm配套。我建议直接用LTS版本因为项目依赖更新频繁太旧的Node运行时会在安装依赖的时候报语法错误排查起来挺浪费时间。如果你是第一次用推荐直接走官方Docker方案这是我认为最省事的一条路径docker pull lissy93/web-check docker run -d -p 3000:3000 --name web-check lissy93/web-check跑起来之后浏览器访问http://localhost:3000就能看到输入框。这种方式干净利落本地验证功能适不适用两分钟就能出结果。但如果你有二次开发、接API key、或者要改检测逻辑的需求我建议还是用源码方式部署我下面详细说源码部署的完整过程。2.2 源码部署的完整步骤git clone https://github.com/lissy93/web-check.git cd web-check npm installnpm install这一步在部分网络环境下可能比较慢项目依赖里有不少前端构建相关的包挂代理或者换npm镜像源都可以解决。装完之后直接启动npm run build npm start默认监听3000端口。启动日志里会打印出监听地址看到Server running at http://localhost:3000就算成功了。这里有个小细节值得注意npm start之前一定要先执行npm run build因为前端资源需要先编译到静态目录跳过这步直接start页面会白屏或者报静态资源404。我第一次部署就吃亏在这个顺序上以为start会自动构建结果页面出来是个空壳。如果你不想每次手动build项目也提供了开发模式npm run dev前后端带热更新适合改代码的场景。我个人的经验是线上用生产模式本地调试用dev模式两套流程分开走比较舒服。2.3 可选的环境变量与外部API配置Web-Check默认不配置任何外部API也能跑通大部分检测但有几个模块的准确度和覆盖范围高度依赖外部数据源。官方预留了这些环境变量入口我实际配置过的几个SHODAN_API_KEY你的key VT_API_KEY你的key C99_API_KEY你的key GOOGLE_SAFE_BROWSING_KEY你的key配置方法是在项目根目录新建一个.env文件填上对应的key然后重启服务。Shodan的key可以让端口扫描模块的数据更全VirusTotal的key能让域名信誉检测生效。不配也能跑但相关模块会显示数据不可用或者结果非常粗体验差一截。不需要为了齐全把所有key都配齐按需来就行。我实际用下来Shodan和Google Safe Browsing这两个比较值得配前者补强端口数据后者补强域名安全信誉其他几个看需求再说。2.4 Docker部署的补充细节Docker方式部署时如果想要配置环境变量用-e参数传进去docker run -d -p 3000:3000 \ -e SHODAN_API_KEYyour_key \ --name web-check lissy93/web-check镜像更新的频率也挺快的建议定期docker pull lissy93/web-check更新到最新版。有一次我跑了一个多月没更新新出的DNS安全扩展检测和证书透明度日志查询模块在老版本里完全没有更新之后功能列表直接多了一截。3. 检测模块逐个拆解每个功能背后的原理和读法3.1 DNS记录与子域名枚举域名层面能暴露的信息打开Web-Check输入一个域名第一个出结果的就是DNS记录区。这里会列出A、AAAA、MX、NS、TXT、CNAME、CAA等常见记录类型。每条记录的读法各有门道A/AAAA记录告诉你域名解析到了哪台服务器MX记录暴露了邮件服务商是谁TXT记录里通常藏着SPF验证串、域名所有权验证串这些都能反映站点背后的基础设施选型。子域名枚举是Web-Check里比较有特色的一块它内置了一份常见子域名字典通过批量DNS查询的方式探测mail.、ftp.、api.、dev.、admin.这类前缀是否存在解析记录。这个功能的实用价值在于很多运维会把内部系统放在不容易被发现的子域名上主站防护严密子站却可能暴露在公网。当年我帮一个朋友排查他家站点的信息泄露问题时就是靠子域名枚举找到了一台未做访问控制的测试环境服务器。3.2 HTTP头与安全头分析一眼看出站点防护水平HTTP响应头这一块Web-Check会把服务器返回的所有响应头字段列出来同时专门高亮安全相关的头。重点看这几个Strict-Transport-SecurityHSTS有没有强制HTTPS值有没有设合理Content-Security-PolicyCSP有没有限制资源加载来源X-Frame-Options有没有防点击劫持X-Content-Type-Options有没有防止MIME类型嗅探Referrer-Policy有没有控制Referrer泄露我给过一个判断经验只配了X-Frame-Options和X-Content-Type-Options的站点属于基本防御加上HSTS和CSP的属于认真做过安全如果再配上Certificate Transparency策略和CAA记录说明站点对证书体系的管理已经比较成熟了。这套观察方法在Web-Check的一个页面上就能快速完成比手动curl然后一条条查省太多时间。3.3 SSL/TLS证书链检查证书层面翻出全部细节证书检测模块会展示完整的证书链信息证书签发者Issuer、有效期、SANSubject Alternative Name里包含的所有域名、证书指纹、使用的签名算法以及TLS协议的最低/最高版本。最有用的场景是排查证书覆盖遗漏——有些站点主域名证书正常但某个子域名证书过期了肉眼访问主站根本看不出来Web-Check会把你输入域名关联的证书信息全列出来哪些子域共用证书、哪些是单独的证书一目了然。还有一个我经常用的点通过证书透明日志Certificate Transparency区可以看到这个域名历史上被签发过多少证书。如果某天你的域名突然多了一堆来路不明的证书签发记录那大概率是域名控制权出问题了这是个很重要的预警信号。3.4 技术栈识别知道你面前站点是用什么搭的技术栈检测模块会尽力识别站点的编程语言、Web服务器、前端框架、分析工具、广告系统、CDN服务商等信息。原理是分析响应头、HTML源码特征词、JS文件路径模式、Cookie名称等指纹。识别结果会按类别标签展示比如NGINX、React、Cloudflare、Google Analytics这样。这个模块对前端和运维工程师特别有用。排查线上问题和第三方脚本冲突的时候先跑一次Web-Check确认对方的部署形态比自己瞎猜省事得多。比如看到CDN标签你就知道网络层面的问题得先从CDN节点排查而不是傻乎乎地盯着源站。3.5 端口扫描与服务器定位了解暴露面大小端口扫描模块会探测一批常用端口如21、22、25、53、80、443、445、3306、3389、5900、8080等是否有响应输出结果能快速判断服务器的暴露面大小。比如一个站点如果22、3306、3389全开着那运维的网络安全意识就需要打个问号了。服务器定位模块则通过IP地理位置数据库显示服务器所在国家和城市配合WHOIS信息基本能拼出一个站点的托管网络和大致物理位置。这里有个经验要分享端口扫描的结果受网络环境影响很大如果你和目标服务器之间有防火墙策略扫出来的可能是全关或者部分关这不是工具不准而是路径被过滤了。看到异常结果先换个网络环境复测一遍再下结论。3.6 SEO与巡检相关项robots.txt、sitemap、重定向链Web-Check还包含了robots.txt分析、sitemap检测、页面重定向链追踪这些偏SEO侧的检查。重定向链一定要重点看有些网站在一个URL上做了三四次302跳转才到最终页面不仅拖慢访问速度对搜索引擎的爬取也不够友好。Web-Check会把完整的跳转链路画出来每一跳的中间URL和响应码都看得清清楚楚。4. 案例演示实测一个技术博客的完整输出为了让你对这份报告的完整程度有个直观认识我拿自己部署实例实测了一个小型技术博客域名。输入域名点击Recon按钮大约15秒后各个模块分批返回结果。以下是我看报告时的关注点记录。DNS记录区显示该域名的A记录指向某云厂商的IPMX记录指向企业邮服务商TXT里有SPF和验证串。WHOIS信息显示注册商和创建时间是2019年。SSL证书显示是Lets Encrypt签发的90天证书SAN里有根域名和www子域名说明证书是定期自动续期的。HTTP头分析里安全头中HSTS已启用但max-age只有一个月CSP缺失。技术栈识别出Ghost框架、NGINX反向代理、CDN加速。端口扫描显示80、443开放22也开着但返回的是ban信号判断为云厂商默认安全组策略。robots.txt中屏蔽了部分后台路径sitemap正常生成重定向链从http到https一跳完成。整个分析过程大概十来分钟我把关键发现总结成一张表存档检测模块实际结果判断TLS证书Lets Encrypt剩余有效期充足正常自动续期HSTS已启用max-age较短建议加长CSP缺失有安全隐患技术栈Ghost NGINX CDN信息完整端口80/443/2222被过滤正常范围重定向链1跳健康这张表的产出过程如果不用Web-Check我得开五六个工具页面才能拼齐而现在一次搞定。对管站的人来说这就是一份随时可以存档和对比的体检单。5. 架构与API接口把它接进自己的自动化体系Web-Check做完端到端页面展示之后其实每个检测项后端都对应一个独立的API端点。这意味着你完全不必依赖它的前端页面可以直接把API接进自己的脚本或者监控平台里。我实际用过的几个接口路径大致如下服务起来之后可以通过HTTP GET请求直接调用# 获取DNS记录 curl http://localhost:3000/api/dns?hostexample.com # 获取HTTP头 curl http://localhost:3000/api/http-headers?urlhttps://example.com # 获取TLS证书 curl http://localhost:3000/api/ssl?hostexample.com # 获取端口扫描结果 curl http://localhost:3000/api/ports?hostexample.com # 获取技术栈 curl http://localhost:3000/api/tech-stack?urlhttps://example.com把Web-Check的API接进定时任务就能实现一个轻量的站点巡检系统。我自己写过一个小脚本每周末跑一次公司几个重点站点的DNS、证书、端口、安全头四个模块结果和上周对比有变化就推送通知到企业群里。证书快过期、安全头被意外改动、新增异常端口开放这些都是高频触发项。这套小系统上线之后避免过一次因为证书忘记续期导致的线上告警事故价值立刻回本。接API的时候注意频次控制Web-Check部署实例没有内置太复杂的限流机制如果你是单机自用无所谓但如果开放给团队用一定要在外面套一层Nginx限流不然有人写个for循环批量扫域名后端资源很容易被打满。这算是我踩过一次的坑。另外就是它支持把多个检测模块的结果汇总成JSON输出方便二次处理。对熟悉脚本处理的同学来说这是比网页报告更好用的交互形态。6. 实际使用中那些坑我的排除经验汇总6.1 端口扫描结果的误判Web-Check的端口扫描用的是TCP连接探测目标服务器如果部署了防火墙或者IDS可能会主动丢弃探测包或者返回伪造的关闭信号。我第一次用的时候扫一个内网穿透服务端口明明在跑工具却显示关闭排查了半天才发现是中间设备拦截了非标准端口的连接请求。遇到异常结果先用在线端口检测站点交叉验证再判断是自己误读还是目标确实有变化。6.2 外部API的配额限制配置了Shodan或VirusTotal的key之后检测速度和结果完整度确实有明显提升但免费方案都有每日查询量上限。一旦配额耗尽对应模块会静默降级不会报错表现就是某天突然结果变少了。如果依赖它做定期巡检建议记录每天查询量或者直接用付费方案免得到期了还以为是工具故障。6.3 子域名枚举的噪音数据子域名枚举基于词典爆破结果里会有一些能解析但没有实际服务的域名记录。有些是泛解析造成的——目标DNS把所有不存在的子域都解析到同一个IP上这种情况下枚举报告会显得特别丰满但实际没有意义。判断方法也简单如果几十条子域结果全都指向同一IP基本就是泛解析筛选掉只看真正有不同解析目标的记录就行。6.4 部署环境的时区与日志自部署之后日志默认按服务器本地时区输出。如果你和我一样习惯用UTC8时间看问题记得部署时就把系统时区设置好不然后续排查问题对时间线会非常痛苦。虽然是个不起眼的小事但运维层面很影响效率。还有一点想特别提醒Web-Check这类工具能力很强单输入一个域名就能翻出大量信息。用在自己授权的站点上那叫巡查和管理用在别人没授权的目标上性质就完全不同了。我自己的原则是只对自有资产、客户明确授权范围内的资产、以及公开信息研究场景使用绝不拿它去对无关目标做批量探测。工具本身是中性的怎么用取决于使用者。7. 自建还是用现成我的最终建议最后说下使用形态的取舍思路。如果你只是偶尔分析一两个域名直接用官方线上实例就够了省去部署和维护成本。如果分析频次高、涉及敏感站点信息不想经过第三方在线服务或者想把结果接进自己的自动化体系那就老老实实自己部署一份。Docker方案全流程下来不到十分钟维护成本也不高定期拉新镜像就行。从性价比角度看我认为自部署是更值得推荐的路径原因不仅是数据隐私更在于你能通过二次开发给Web-Check加上自己的检测逻辑。我自己就在它的后端基础上加过一个自定义的关键资源变更监控接口专门盯自己站点的几个关键JS文件名是否变化——这个需求官方版本没有但因为它架构清晰、模块解耦扩展起来并不困难。开源工具的价值不只是开箱即用更是给你一个可以自由裁剪的底座这是商业SaaS给不了的东西。如果你打算正式把它用起来我的建议就一句话先跑一遍官方实例摸清每个模块输出什么结果再自部署一份配好环境和必要API最后按自己的巡检场景接进脚本或告警系统。走完这三步你手里就有一套完全属于自己、可以持续积累数据资产的信息收集基础设施了。
