1. 项目概述为什么选择Tsunami作为你的第一把安全“扫帚”如果你刚踏入网络安全领域或者是一名运维、开发人员想为自己的服务做一次靠谱的“体检”面对市面上琳琅满目的扫描工具可能会感到无从下手。Nessus太贵OpenVAS配置复杂Nmap结果又太“原始”。这时候Google开源的Tsunami安全扫描器就像一把设计精良的“扫帚”它不追求大而全而是专注于高可信度、可大规模部署的漏洞检测特别适合作为你安全工具库中的第一件趁手兵器。我最初接触Tsunami是在一个需要快速为上百台云服务器做基线安全检查的场景。传统的扫描器要么误报率高得吓人需要大量人工复核要么扫描速度慢资源占用大。Tsunami的设计哲学打动了我它采用插件化架构核心引擎只负责端口扫描和服务识别具体的漏洞检测逻辑全部由独立的、经过严格验证的检测插件Detector完成。这意味着它的误报率理论上可以做到极低因为每个插件都是针对一个特定漏洞的“专家”。对于新手而言你不需要理解所有漏洞的复杂原理就能通过它快速发现那些真正高危的、已被广泛利用的漏洞比如Log4Shell、Spring4Shell等。简单来说Tsunami能帮你解决几个核心痛点第一快速定位高风险目标它通过端口扫描识别开放服务如SSH, Hadoop, Jenkins第二执行高可信度漏洞验证针对识别出的服务调用对应的插件进行深度检测而非简单的版本比对第三结果清晰可操作报告会明确指出存在问题的IP、端口、漏洞名称、风险等级以及修复建议。它非常适合个人学习者搭建实验环境、中小企业进行定期的安全自查以及大型企业作为自动化安全流水线中的一环。接下来我将带你从零开始完整走一遍部署、配置、扫描和结果分析的实战流程并分享我踩过的坑和总结的技巧。2. 环境准备与Tsunami部署详解工欲善其事必先利其器。Tsunami的运行依赖于一个简单的“服务端-客户端”架构但它的部署比想象中要灵活。官方推荐使用Docker这能避免复杂的依赖环境问题也是我们首选的方案。2.1 系统与依赖要求Tsunami本身是用Java编写的但其核心扫描能力依赖于一个强大的“侦察兵”——Nmap。因此基础环境需要满足以下条件一台Linux主机作为扫描服务器。Ubuntu 20.04/22.04 LTS或CentOS 7/8是经过充分测试的选择。我个人的实验环境是Ubuntu 22.04。Docker与Docker Compose这是运行Tsunami最简洁的方式。确保你的系统已经安装了Docker Engine和Docker Compose V2。你可以通过docker --version和docker compose version来验证。网络权限运行Tsunami的主机需要能够通过网络访问到目标主机。这意味着你可能需要配置防火墙规则允许扫描主机向目标发起TCP/UDP连接。重要提示仅在你有明确授权的网络和目标上进行扫描。未经授权的扫描可能违反法律或公司政策。注意虽然Tsunami可以通过Java直接运行但Docker方式封装了所有依赖包括特定版本的Nmap能保证环境一致性极大减少“在我机器上好好的”这类问题。2.2 一步步部署Tsunami服务端我们将采用Docker Compose方式来部署这是管理Tsunami及其相关组件如用于存储扫描结果的Elasticsearch和用于展示的Kibana的最佳实践。首先创建一个项目目录并编写docker-compose.yml文件mkdir tsunami-security-scanner cd tsunami-security-scanner# docker-compose.yml version: 3.8 services: tsunami: image: ghcr.io/google/tsunami-security-scanner:latest container_name: tsunami-scanner network_mode: host # 使用主机网络模式使容器能直接使用主机的网络接口进行扫描 volumes: - ./tsunami-config:/tsunami-config - ./scan-results:/scan-results command: [--ip-v4-target127.0.0.1, --config-path/tsunami-config/tsunami.yaml] # 初始命令后续我们会覆盖 restart: no elasticsearch: image: docker.elastic.co/elasticsearch/elasticsearch:8.10.0 container_name: tsunami-elasticsearch environment: - discovery.typesingle-node - xpack.security.enabledfalse # 为简化实验禁用安全认证 - ES_JAVA_OPTS-Xms512m -Xmx512m ports: - 9200:9200 volumes: - es-data:/usr/share/elasticsearch/data kibana: image: docker.elastic.co/kibana/kibana:8.10.0 container_name: tsunami-kibana environment: - ELASTICSEARCH_HOSTShttp://elasticsearch:9200 ports: - 5601:5601 depends_on: - elasticsearch volumes: es-data:这个配置定义了三个服务tsunami扫描器本体使用host网络模式至关重要这样容器内的Nmap才能正确执行主机发现和端口扫描。elasticsearch用于存储结构化的扫描结果。kibana用于可视化展示扫描结果报告。接下来我们需要准备Tsunami的核心配置文件tsunami.yaml。在项目目录下创建tsunami-config文件夹并在其中创建该文件mkdir -p tsunami-config# tsunami-config/tsunami.yaml scan: # 目标发现设置这里我们手动指定目标暂不使用自动发现 target: network_endpoints: - type: IP_V4_ADDRESS ip_address: 127.0.0.1 # 默认占位符实际扫描时通过命令行参数覆盖 # 端口扫描设置 port_scanner: name: NmapPortScanner plugin_specific_config: # 指定Nmap的扫描参数-sS是TCP SYN扫描半开扫描速度快且隐蔽 nmap_args: -sS -Pn --min-rate1000 --max-retries2 # 要扫描的端口范围这里是一个常用端口列表 target_ports: - 20-23,53,80,443,445,8080,8443,22,21,25,110,143,3389,5900,6379,27017 # 服务指纹识别设置 service_discovery: - name: NmapServiceDetector plugin_specific_config: # 服务识别强度推荐使用--version-intensity 5以获得更准确的服务版本信息 nmap_args: -sV --version-intensity 5 # 漏洞检测插件设置 vulnerability_detection: plugins: - name: ApacheStrutsRCE - name: ExposedHadoopYarn - name: ExposedJenkins - name: ExposedWordpress - name: CVE202144228Log4Shell - name: CVE202222965SpringShell - name: ExposedDockerRegistry - name: WeakCredential plugin_specific_config: # 弱口令检测的目标服务及字典配置 target_services: [SSH, FTP, MYSQL] # 你可以指定自定义的用户名/密码字典文件路径 # username_wordlist_path: /tsunami-config/username.list # password_wordlist_path: /tsunami-config/password.list # 输出插件设置 output: plugins: - name: ConsoleOutput - name: ElasticsearchOutput plugin_specific_config: # 指向我们Docker Compose中启动的Elasticsearch地址 elasticsearch_address: http://localhost:9200 index_name: tsunami-scan-results # 是否使用SSL和认证我们已禁用 use_ssl: false verify_ssl_certificate: false这个配置文件定义了扫描的完整流程先进行端口扫描然后识别服务接着调用一系列漏洞检测插件最后将结果输出到控制台和Elasticsearch。现在启动整个栈docker compose up -d等待片刻使用docker compose ps查看所有容器状态是否为 “Up”。你可以访问http://你的服务器IP:5601来打开Kibana界面首次可能需要稍等一分钟初始化。2.3 插件管理与更新Tsunami的能力边界由其插件决定。默认镜像已经包含了一批Google官方维护的高质量插件如上面配置中列出的。但社区也在不断贡献新的检测插件。要管理插件你需要理解Tsunami的插件清单文件。插件清单通常是一个plugins.zip文件其中包含了所有插件的JAR包和一个描述文件。在Docker部署中官方镜像已经内置了插件。如果你想使用自定义或更新的插件需要将其挂载到容器的/tsunami-plugins目录并在配置文件中通过plugin_resolution部分指定清单文件路径。对于初学者使用默认插件已足够应对大多数常见高危漏洞。3. 核心扫描流程与实战操作环境就绪后我们就可以开始第一次实战扫描了。我们将目标从默认的127.0.0.1换成我们真正想检查的目标。3.1 定义扫描目标与策略假设我们要扫描内网中IP为192.168.1.100的一台测试服务器。首先你需要明确扫描边界和策略目标范围是单个IP还是一个CIDR网段如192.168.1.0/24Tsunami支持两者。扫描强度在tsunami.yaml中我们通过nmap_args控制了端口扫描和版本探测的强度。-sS -Pn --min-rate1000是一种较快但可能不够隐蔽的扫描方式。在对生产环境进行扫描时你可能需要降低速率如--min-rate200以避免触发安全设备的告警。插件选择不是所有插件都适合你的环境。如果你环境里没有WordPress那么ExposedWordpress插件只会增加不必要的扫描时间。你应该根据tsunami.yaml中vulnerability_detection.plugins列表按需启用或禁用插件。3.2 执行你的第一次扫描我们通过覆盖Docker容器的启动命令来执行一次扫描。首先停止之前为测试启动的默认容器如果还在运行docker compose stop tsunami然后使用以下命令启动一次针对192.168.1.100的扫描docker compose run --rm tsunami \ --ip-v4-target192.168.1.100 \ --config-path/tsunami-config/tsunami.yaml \ --scan-results-local-output-formatJSON \ --scan-results-local-output-filename/scan-results/scan_$(date %Y%m%d_%H%M%S).json让我们拆解这个命令docker compose run --rm tsunami启动一个一次性--rm表示运行后自动删除容器的tsunami服务容器。--ip-v4-target192.168.1.100指定扫描目标。你也可以用--ip-v4-target-range192.168.1.0/24扫描整个网段。--config-path指定配置文件路径即我们之前挂载的tsunami.yaml。--scan-results-local-output-formatJSON让Tsunami将结果以JSON格式输出到本地文件。--scan-results-local-output-filename指定JSON输出文件的路径和名称。这里我们使用了带时间戳的文件名方便归档。执行命令后你会在终端看到实时的扫描日志输出。Tsunami会按顺序执行网络探测、端口扫描、服务识别、漏洞检测。整个过程耗时取决于目标开放端口的数量和服务识别的复杂度通常对单个主机在几分钟内完成。3.3 扫描过程深度解析与监控当扫描运行时理解其输出日志能帮你判断进度和潜在问题。INFO: Port scan phase starting. INFO: Found 3 open ports on target 192.168.1.100: [22/tcp, 80/tcp, 8080/tcp] INFO: Service discovery phase starting. INFO: Identified service ssh on 192.168.1.100:22/tcp (software: OpenSSH 8.2p1). INFO: Identified service http on 192.168.1.100:80/tcp (software: nginx 1.18.0). INFO: Identified service http on 192.168.1.100:8080/tcp (software: Jenkins 2.346.2). INFO: Vulnerability detection phase starting. INFO: Running detector ExposedJenkins on target 192.168.1.100:8080/tcp. WARNING: Detector ExposedJenkins found a finding: Exposed Jenkins instance. INFO: Running detector WeakCredential on target 192.168.1.100:22/tcp. INFO: Detector WeakCredential completed with no findings. INFO: Scan completed successfully.从日志中我们可以清晰地看到端口扫描阶段发现了3个开放端口22 80 8080。服务识别阶段成功识别出服务及版本OpenSSH 8.2p1 nginx 1.18.0 Jenkins 2.346.2。版本信息对于漏洞匹配至关重要。漏洞检测阶段针对识别出的服务按顺序运行相应的检测插件。例如发现Jenkins后运行了ExposedJenkins插件并产生了一条警告Finding。而针对SSH服务运行的弱口令检测插件则未发现异常。如果某个插件运行失败或出错日志中会显示ERROR信息这通常需要你检查插件配置或网络连通性。4. 扫描结果分析与报告解读扫描结束后结果会以两种形式呈现一是命令行终端的JSON输出我们已保存到文件二是写入Elasticsearch并通过Kibana展示。后者提供了更强大的查询和可视化能力。4.1 解析JSON格式的扫描报告打开在./scan-results/目录下生成的JSON文件其结构是标准化的。一个典型的漏洞发现Finding条目如下{ target: { networkEndpoint: { type: IP_V4_ADDRESS, ipAddress: 192.168.1.100, port: { portNumber: 8080, protocol: TCP } }, software: { name: Jenkins, version: 2.346.2 } }, vulnerability: { mainId: EXPOSED_JENKINS_INSTANCE, severity: HIGH, title: Exposed Jenkins Instance, description: An unauthenticated Jenkins instance is exposed to the network. This can allow attackers to..., recommendation: 1. Place Jenkins behind a reverse proxy with authentication. 2. Restrict network access using firewall rules. 3. Enable Jenkins built-in security realm., additionalDetails: { detector_name: ExposedJenkins, cves: [], cvss_score: 7.5 } } }这个结构非常清晰target精确指出了存在问题的目标IP:Port以及上面运行的软件。vulnerabilitymainId和title漏洞的唯一标识和名称。severity风险等级CRITICAL, HIGH, MEDIUM, LOW。这是基于漏洞的CVSS分数和潜在影响由插件定义的。description详细描述了漏洞的成因和潜在风险。recommendation这是最有价值的部分提供了具体的修复步骤。对于暴露的Jenkins建议包括设置反向代理、配置防火墙和启用认证。additionalDetails包含检测器名称、相关的CVE编号和CVSS分数。你需要重点关注HIGH和CRITICAL级别的发现。对于每个发现遵循recommendation进行修复是首要任务。4.2 使用Kibana进行可视化分析与历史管理将结果存入Elasticsearch后我们可以在Kibana中创建仪表板这对于长期跟踪和批量扫描结果分析尤其有用。首先需要在Kibana中创建索引模式登录Kibana (http://your-server:5601)。侧边栏进入Management Stack Management。在Kibana部分点击Index Patterns然后点击Create index pattern。在索引模式名称中输入tsunami-scan-results*与我们配置中的index_name匹配点击Next step。选择时间字段如果有如timestamp然后点击Create index pattern。创建完成后你可以进入Analytics Discover选择tsunami-scan-results*索引模式查看所有扫描结果。使用KQLKibana Query Language进行过滤例如vulnerability.severity: HIGH来筛选所有高危漏洞。进入Analytics Dashboard创建自定义仪表板。例如可以添加“漏洞严重程度分布饼图”、“Top 10受影响IP地址条形图”、“随时间变化的漏洞发现趋势图”等。这种可视化方式能让安全状态一目了然特别适合在周期性的扫描任务后向团队或管理层汇报整体安全态势。5. 高级配置与定制化扫描策略掌握了基础扫描后你可以通过调整配置来让Tsunami更贴合你的实际需求。5.1 性能调优与大规模扫描当需要扫描数百甚至上千台主机时默认配置可能效率不高。你可以从以下几个方面优化并行扫描Tsunami本身是单线程按顺序扫描目标的。要实现并行化你需要借助外部工具例如使用xargs或编写一个简单的Shell/Python脚本将IP列表分片同时启动多个Tsunami容器实例。务必注意控制并发数避免对网络和目标系统造成过大压力。# 示例使用GNU parallel并行扫描一个IP列表文件 cat target_ips.txt | parallel -j 4 docker compose run --rm tsunami --ip-v4-target{} --config-path/tsunami-config/tsunami.yaml这个命令会以最多4个并发任务的方式扫描target_ips.txt中的所有IP。-j 4表示并发数请根据扫描主机的CPU和网络带宽调整。Nmap参数优化在tsunami.yaml的port_scanner部分调整nmap_args可以显著影响速度和隐蔽性。提高速度--min-rate1000每秒最少发送1000个包--max-retries1减少重试。增加隐蔽性-T2Polite模式速度慢但更安静-f分片数据包--data-length附加随机数据。调整端口范围只扫描业务相关的端口而不是全端口能极大缩短时间。插件选择策略在配置文件中只启用与目标环境相关的插件。例如如果环境中没有数据库就禁用ExposedMongoDB,ExposedRedis等插件。这能减少不必要的探测流量和扫描时间。5.2 编写自定义检测插件进阶Tsunami的强大之处在于其可扩展的插件体系。如果你有一个内部使用的、具有特定指纹的服务或一个公开漏洞的POC可以将其封装成Tsunami插件。一个最简单的检测插件通常包含以下几个Java类Detector类核心检测逻辑。实现VulnerabilityDetector接口在detect方法中编写检测代码。BootstrapModule类使用Google Guice进行依赖注入的配置模块。PluginDefinition类定义插件元数据如名称、版本、描述、支持的服务类型等。官方提供了详细的 插件开发示例 。开发完成后将编译好的JAR包放入插件目录并在配置文件中引用插件名即可。这允许你将内部的安全检查流程标准化并自动化。6. 实战避坑指南与常见问题排查在实际使用中你肯定会遇到各种问题。以下是我总结的一些典型“坑”及其解决方案。6.1 扫描失败或结果为空问题现象扫描很快结束日志显示“0 open ports”或漏洞检测阶段直接跳过。可能原因与排查网络不通这是最常见的原因。确保扫描主机能ping通目标IP。如果目标有主机防火墙如firewalld, iptables需要临时放行扫描源IP或使用更隐蔽的扫描模式如-sS可能被拦截可尝试-sT全连接扫描但不够隐蔽。Nmap参数问题配置文件中的-Pn参数是“无ping扫描”即假设主机存活。如果目标禁用了ICMP回应这是正确的。但如果网络本身有隔离扫描器可能无法到达目标。可以尝试去掉-Pn让Nmap先进行主机发现。目标端口未在列表中检查target_ports配置是否包含了目标实际开放的业务端口。可以先用手动执行nmap -sS -p- 192.168.1.100来确认目标开放了哪些端口。6.2 服务识别不准确或失败问题现象日志显示开放了80端口但服务识别为unknown或版本号识别错误。可能原因与排查服务指纹干扰目标服务可能修改了默认的Banner信息。Nmap的版本探测-sV依赖于Banner。此时需要更深入的探测可能需要调整--version-intensity级别最高为9但会大幅增加扫描时间。服务需要交互有些服务如某些FTP、Telnet在建立连接后需要一定的交互才能返回Banner。标准的Nmap版本探测可能无法处理。这种情况通常需要专门的手动测试或编写自定义插件。TLS/SSL加密对于HTTPS服务443端口Nmap需要能够协商TLS。如果目标使用自签名证书或不支持的加密套件可能导致识别失败。可以尝试在nmap_args中添加--script ssl-enum-ciphers来获取更多TLS信息。6.3 插件误报与漏报问题现象插件报告了一个漏洞但手动验证发现不存在误报或者手动验证存在的漏洞Tsunami没有报告漏报。可能原因与排查误报通常发生在基于版本号比对的插件上。插件发现服务版本在受影响范围内就报告但目标可能已经打了补丁只是未更新Banner。任何自动化工具的发现都必须经过人工验证对于Tsunami的报告你应该根据它提供的IP、端口和漏洞信息使用专门的概念验证PoC工具或手动步骤进行二次确认。漏报插件未启用检查配置文件中是否启用了对应的检测插件。服务识别偏差如果服务识别错误例如将Tomcat识别为普通HTTP服务那么针对Tomcat的漏洞插件就不会被触发。漏洞检测逻辑限制有些插件的检测逻辑可能不够全面或者漏洞利用条件非常特殊。自动化工具无法覆盖100%的漏洞。网络限制某些漏洞检测需要发送特定的探测Payload如果中间有WAF或IPS设备可能会被拦截导致检测失败。6.4 性能问题与资源占用问题现象扫描速度极慢或者Docker容器占用大量CPU/内存。可能原因与排查目标过多或端口范围过大这是最主要的原因。将大范围扫描拆分成多个小任务并行执行。Nmap参数过于激进过高的--min-rate可能导致网络拥堵或目标丢包反而需要重传降低效率。适当调低速率。插件执行耗时一些插件特别是弱口令检测插件WeakCredential如果使用了大型字典会进行大量的网络登录尝试极其耗时。建议在针对大量目标扫描时暂时禁用此类插件或使用精心裁剪的小字典。容器资源限制可以为Docker容器设置CPU和内存限制防止单个扫描任务耗尽主机资源。7. 将Tsunami集成到自动化工作流Tsunami的真正威力在于其可编程性和可集成性。你可以将它作为CI/CD流水线中的一个环节或者作为一个定期的自动化安全巡检任务。7.1 与CI/CD工具集成例如Jenkins你可以在Jenkins Pipeline中增加一个安全扫描阶段pipeline { agent any stages { stage(Build) { steps { // 你的构建步骤 } } stage(Security Scan with Tsunami) { steps { script { // 假设你的应用部署到了某个测试环境IP def targetIp 10.0.1.50 sh docker run --rm --networkhost \ -v \$(pwd)/tsunami-config:/tsunami-config \ -v \$(pwd)/scan-results:/scan-results \ ghcr.io/google/tsunami-security-scanner:latest \ --ip-v4-target${targetIp} \ --config-path/tsunami-config/tsunami.yaml \ --scan-results-local-output-formatJSON \ --scan-results-local-output-filename/scan-results/latest_scan.json // 解析扫描结果如果发现CRITICAL或HIGH级别的漏洞则令构建失败 def scanResults readJSON file: scan-results/latest_scan.json def highOrCriticalFindings scanResults.findAll { it.vulnerability.severity in [CRITICAL, HIGH] } if (!highOrCriticalFindings.isEmpty()) { error 安全扫描发现 ${highOrCriticalFindings.size()} 个高危漏洞构建失败。请查看详细报告。 } } } } stage(Deploy) { steps { // 只有安全扫描通过才进行部署 } } } post { always { // 总是将扫描结果归档 archiveArtifacts artifacts: scan-results/latest_scan.json, fingerprint: true } } }这个流水线会在构建后对测试环境进行安全扫描如果发现高危漏洞则自动失败阻止有已知高危漏洞的版本被部署。7.2 定期自动化扫描与告警使用Linux的cron或更现代的调度系统如Apache Airflow可以定期执行Tsunami扫描。结合Elasticsearch和Kibana的告警功能Elastic Alerting可以实现自动告警。例如你可以设置一个Kibana告警规则条件当tsunami-scan-results*索引中在最近1小时内新出现的文档中vulnerability.severity字段为CRITICAL。动作发送邮件到安全团队邮箱或通过Webhook触发一个Slack/钉钉消息。这样一旦扫描发现新的严重漏洞安全团队就能在几分钟内得到通知迅速启动应急响应流程。我个人在多个项目中实践了这套流程最大的体会是自动化是安全运营的基石。将Tsunami这样的工具从“偶尔手动运行一下”变成“流水线中不可或缺的一环”才能真正实现安全左移让漏洞在造成实际影响前就被发现和修复。刚开始集成时可能会遇到不少适配问题比如网络权限、扫描时机、结果解析等但一旦跑通它带来的安全能见度和效率提升是巨大的。最后一个小建议定期比如每季度回顾和更新你的tsunami.yaml配置文件尤其是插件列表和Nmap参数以适应不断变化的网络环境和新的威胁情报。
Tsunami安全扫描器实战：从部署到自动化漏洞检测
1. 项目概述为什么选择Tsunami作为你的第一把安全“扫帚”如果你刚踏入网络安全领域或者是一名运维、开发人员想为自己的服务做一次靠谱的“体检”面对市面上琳琅满目的扫描工具可能会感到无从下手。Nessus太贵OpenVAS配置复杂Nmap结果又太“原始”。这时候Google开源的Tsunami安全扫描器就像一把设计精良的“扫帚”它不追求大而全而是专注于高可信度、可大规模部署的漏洞检测特别适合作为你安全工具库中的第一件趁手兵器。我最初接触Tsunami是在一个需要快速为上百台云服务器做基线安全检查的场景。传统的扫描器要么误报率高得吓人需要大量人工复核要么扫描速度慢资源占用大。Tsunami的设计哲学打动了我它采用插件化架构核心引擎只负责端口扫描和服务识别具体的漏洞检测逻辑全部由独立的、经过严格验证的检测插件Detector完成。这意味着它的误报率理论上可以做到极低因为每个插件都是针对一个特定漏洞的“专家”。对于新手而言你不需要理解所有漏洞的复杂原理就能通过它快速发现那些真正高危的、已被广泛利用的漏洞比如Log4Shell、Spring4Shell等。简单来说Tsunami能帮你解决几个核心痛点第一快速定位高风险目标它通过端口扫描识别开放服务如SSH, Hadoop, Jenkins第二执行高可信度漏洞验证针对识别出的服务调用对应的插件进行深度检测而非简单的版本比对第三结果清晰可操作报告会明确指出存在问题的IP、端口、漏洞名称、风险等级以及修复建议。它非常适合个人学习者搭建实验环境、中小企业进行定期的安全自查以及大型企业作为自动化安全流水线中的一环。接下来我将带你从零开始完整走一遍部署、配置、扫描和结果分析的实战流程并分享我踩过的坑和总结的技巧。2. 环境准备与Tsunami部署详解工欲善其事必先利其器。Tsunami的运行依赖于一个简单的“服务端-客户端”架构但它的部署比想象中要灵活。官方推荐使用Docker这能避免复杂的依赖环境问题也是我们首选的方案。2.1 系统与依赖要求Tsunami本身是用Java编写的但其核心扫描能力依赖于一个强大的“侦察兵”——Nmap。因此基础环境需要满足以下条件一台Linux主机作为扫描服务器。Ubuntu 20.04/22.04 LTS或CentOS 7/8是经过充分测试的选择。我个人的实验环境是Ubuntu 22.04。Docker与Docker Compose这是运行Tsunami最简洁的方式。确保你的系统已经安装了Docker Engine和Docker Compose V2。你可以通过docker --version和docker compose version来验证。网络权限运行Tsunami的主机需要能够通过网络访问到目标主机。这意味着你可能需要配置防火墙规则允许扫描主机向目标发起TCP/UDP连接。重要提示仅在你有明确授权的网络和目标上进行扫描。未经授权的扫描可能违反法律或公司政策。注意虽然Tsunami可以通过Java直接运行但Docker方式封装了所有依赖包括特定版本的Nmap能保证环境一致性极大减少“在我机器上好好的”这类问题。2.2 一步步部署Tsunami服务端我们将采用Docker Compose方式来部署这是管理Tsunami及其相关组件如用于存储扫描结果的Elasticsearch和用于展示的Kibana的最佳实践。首先创建一个项目目录并编写docker-compose.yml文件mkdir tsunami-security-scanner cd tsunami-security-scanner# docker-compose.yml version: 3.8 services: tsunami: image: ghcr.io/google/tsunami-security-scanner:latest container_name: tsunami-scanner network_mode: host # 使用主机网络模式使容器能直接使用主机的网络接口进行扫描 volumes: - ./tsunami-config:/tsunami-config - ./scan-results:/scan-results command: [--ip-v4-target127.0.0.1, --config-path/tsunami-config/tsunami.yaml] # 初始命令后续我们会覆盖 restart: no elasticsearch: image: docker.elastic.co/elasticsearch/elasticsearch:8.10.0 container_name: tsunami-elasticsearch environment: - discovery.typesingle-node - xpack.security.enabledfalse # 为简化实验禁用安全认证 - ES_JAVA_OPTS-Xms512m -Xmx512m ports: - 9200:9200 volumes: - es-data:/usr/share/elasticsearch/data kibana: image: docker.elastic.co/kibana/kibana:8.10.0 container_name: tsunami-kibana environment: - ELASTICSEARCH_HOSTShttp://elasticsearch:9200 ports: - 5601:5601 depends_on: - elasticsearch volumes: es-data:这个配置定义了三个服务tsunami扫描器本体使用host网络模式至关重要这样容器内的Nmap才能正确执行主机发现和端口扫描。elasticsearch用于存储结构化的扫描结果。kibana用于可视化展示扫描结果报告。接下来我们需要准备Tsunami的核心配置文件tsunami.yaml。在项目目录下创建tsunami-config文件夹并在其中创建该文件mkdir -p tsunami-config# tsunami-config/tsunami.yaml scan: # 目标发现设置这里我们手动指定目标暂不使用自动发现 target: network_endpoints: - type: IP_V4_ADDRESS ip_address: 127.0.0.1 # 默认占位符实际扫描时通过命令行参数覆盖 # 端口扫描设置 port_scanner: name: NmapPortScanner plugin_specific_config: # 指定Nmap的扫描参数-sS是TCP SYN扫描半开扫描速度快且隐蔽 nmap_args: -sS -Pn --min-rate1000 --max-retries2 # 要扫描的端口范围这里是一个常用端口列表 target_ports: - 20-23,53,80,443,445,8080,8443,22,21,25,110,143,3389,5900,6379,27017 # 服务指纹识别设置 service_discovery: - name: NmapServiceDetector plugin_specific_config: # 服务识别强度推荐使用--version-intensity 5以获得更准确的服务版本信息 nmap_args: -sV --version-intensity 5 # 漏洞检测插件设置 vulnerability_detection: plugins: - name: ApacheStrutsRCE - name: ExposedHadoopYarn - name: ExposedJenkins - name: ExposedWordpress - name: CVE202144228Log4Shell - name: CVE202222965SpringShell - name: ExposedDockerRegistry - name: WeakCredential plugin_specific_config: # 弱口令检测的目标服务及字典配置 target_services: [SSH, FTP, MYSQL] # 你可以指定自定义的用户名/密码字典文件路径 # username_wordlist_path: /tsunami-config/username.list # password_wordlist_path: /tsunami-config/password.list # 输出插件设置 output: plugins: - name: ConsoleOutput - name: ElasticsearchOutput plugin_specific_config: # 指向我们Docker Compose中启动的Elasticsearch地址 elasticsearch_address: http://localhost:9200 index_name: tsunami-scan-results # 是否使用SSL和认证我们已禁用 use_ssl: false verify_ssl_certificate: false这个配置文件定义了扫描的完整流程先进行端口扫描然后识别服务接着调用一系列漏洞检测插件最后将结果输出到控制台和Elasticsearch。现在启动整个栈docker compose up -d等待片刻使用docker compose ps查看所有容器状态是否为 “Up”。你可以访问http://你的服务器IP:5601来打开Kibana界面首次可能需要稍等一分钟初始化。2.3 插件管理与更新Tsunami的能力边界由其插件决定。默认镜像已经包含了一批Google官方维护的高质量插件如上面配置中列出的。但社区也在不断贡献新的检测插件。要管理插件你需要理解Tsunami的插件清单文件。插件清单通常是一个plugins.zip文件其中包含了所有插件的JAR包和一个描述文件。在Docker部署中官方镜像已经内置了插件。如果你想使用自定义或更新的插件需要将其挂载到容器的/tsunami-plugins目录并在配置文件中通过plugin_resolution部分指定清单文件路径。对于初学者使用默认插件已足够应对大多数常见高危漏洞。3. 核心扫描流程与实战操作环境就绪后我们就可以开始第一次实战扫描了。我们将目标从默认的127.0.0.1换成我们真正想检查的目标。3.1 定义扫描目标与策略假设我们要扫描内网中IP为192.168.1.100的一台测试服务器。首先你需要明确扫描边界和策略目标范围是单个IP还是一个CIDR网段如192.168.1.0/24Tsunami支持两者。扫描强度在tsunami.yaml中我们通过nmap_args控制了端口扫描和版本探测的强度。-sS -Pn --min-rate1000是一种较快但可能不够隐蔽的扫描方式。在对生产环境进行扫描时你可能需要降低速率如--min-rate200以避免触发安全设备的告警。插件选择不是所有插件都适合你的环境。如果你环境里没有WordPress那么ExposedWordpress插件只会增加不必要的扫描时间。你应该根据tsunami.yaml中vulnerability_detection.plugins列表按需启用或禁用插件。3.2 执行你的第一次扫描我们通过覆盖Docker容器的启动命令来执行一次扫描。首先停止之前为测试启动的默认容器如果还在运行docker compose stop tsunami然后使用以下命令启动一次针对192.168.1.100的扫描docker compose run --rm tsunami \ --ip-v4-target192.168.1.100 \ --config-path/tsunami-config/tsunami.yaml \ --scan-results-local-output-formatJSON \ --scan-results-local-output-filename/scan-results/scan_$(date %Y%m%d_%H%M%S).json让我们拆解这个命令docker compose run --rm tsunami启动一个一次性--rm表示运行后自动删除容器的tsunami服务容器。--ip-v4-target192.168.1.100指定扫描目标。你也可以用--ip-v4-target-range192.168.1.0/24扫描整个网段。--config-path指定配置文件路径即我们之前挂载的tsunami.yaml。--scan-results-local-output-formatJSON让Tsunami将结果以JSON格式输出到本地文件。--scan-results-local-output-filename指定JSON输出文件的路径和名称。这里我们使用了带时间戳的文件名方便归档。执行命令后你会在终端看到实时的扫描日志输出。Tsunami会按顺序执行网络探测、端口扫描、服务识别、漏洞检测。整个过程耗时取决于目标开放端口的数量和服务识别的复杂度通常对单个主机在几分钟内完成。3.3 扫描过程深度解析与监控当扫描运行时理解其输出日志能帮你判断进度和潜在问题。INFO: Port scan phase starting. INFO: Found 3 open ports on target 192.168.1.100: [22/tcp, 80/tcp, 8080/tcp] INFO: Service discovery phase starting. INFO: Identified service ssh on 192.168.1.100:22/tcp (software: OpenSSH 8.2p1). INFO: Identified service http on 192.168.1.100:80/tcp (software: nginx 1.18.0). INFO: Identified service http on 192.168.1.100:8080/tcp (software: Jenkins 2.346.2). INFO: Vulnerability detection phase starting. INFO: Running detector ExposedJenkins on target 192.168.1.100:8080/tcp. WARNING: Detector ExposedJenkins found a finding: Exposed Jenkins instance. INFO: Running detector WeakCredential on target 192.168.1.100:22/tcp. INFO: Detector WeakCredential completed with no findings. INFO: Scan completed successfully.从日志中我们可以清晰地看到端口扫描阶段发现了3个开放端口22 80 8080。服务识别阶段成功识别出服务及版本OpenSSH 8.2p1 nginx 1.18.0 Jenkins 2.346.2。版本信息对于漏洞匹配至关重要。漏洞检测阶段针对识别出的服务按顺序运行相应的检测插件。例如发现Jenkins后运行了ExposedJenkins插件并产生了一条警告Finding。而针对SSH服务运行的弱口令检测插件则未发现异常。如果某个插件运行失败或出错日志中会显示ERROR信息这通常需要你检查插件配置或网络连通性。4. 扫描结果分析与报告解读扫描结束后结果会以两种形式呈现一是命令行终端的JSON输出我们已保存到文件二是写入Elasticsearch并通过Kibana展示。后者提供了更强大的查询和可视化能力。4.1 解析JSON格式的扫描报告打开在./scan-results/目录下生成的JSON文件其结构是标准化的。一个典型的漏洞发现Finding条目如下{ target: { networkEndpoint: { type: IP_V4_ADDRESS, ipAddress: 192.168.1.100, port: { portNumber: 8080, protocol: TCP } }, software: { name: Jenkins, version: 2.346.2 } }, vulnerability: { mainId: EXPOSED_JENKINS_INSTANCE, severity: HIGH, title: Exposed Jenkins Instance, description: An unauthenticated Jenkins instance is exposed to the network. This can allow attackers to..., recommendation: 1. Place Jenkins behind a reverse proxy with authentication. 2. Restrict network access using firewall rules. 3. Enable Jenkins built-in security realm., additionalDetails: { detector_name: ExposedJenkins, cves: [], cvss_score: 7.5 } } }这个结构非常清晰target精确指出了存在问题的目标IP:Port以及上面运行的软件。vulnerabilitymainId和title漏洞的唯一标识和名称。severity风险等级CRITICAL, HIGH, MEDIUM, LOW。这是基于漏洞的CVSS分数和潜在影响由插件定义的。description详细描述了漏洞的成因和潜在风险。recommendation这是最有价值的部分提供了具体的修复步骤。对于暴露的Jenkins建议包括设置反向代理、配置防火墙和启用认证。additionalDetails包含检测器名称、相关的CVE编号和CVSS分数。你需要重点关注HIGH和CRITICAL级别的发现。对于每个发现遵循recommendation进行修复是首要任务。4.2 使用Kibana进行可视化分析与历史管理将结果存入Elasticsearch后我们可以在Kibana中创建仪表板这对于长期跟踪和批量扫描结果分析尤其有用。首先需要在Kibana中创建索引模式登录Kibana (http://your-server:5601)。侧边栏进入Management Stack Management。在Kibana部分点击Index Patterns然后点击Create index pattern。在索引模式名称中输入tsunami-scan-results*与我们配置中的index_name匹配点击Next step。选择时间字段如果有如timestamp然后点击Create index pattern。创建完成后你可以进入Analytics Discover选择tsunami-scan-results*索引模式查看所有扫描结果。使用KQLKibana Query Language进行过滤例如vulnerability.severity: HIGH来筛选所有高危漏洞。进入Analytics Dashboard创建自定义仪表板。例如可以添加“漏洞严重程度分布饼图”、“Top 10受影响IP地址条形图”、“随时间变化的漏洞发现趋势图”等。这种可视化方式能让安全状态一目了然特别适合在周期性的扫描任务后向团队或管理层汇报整体安全态势。5. 高级配置与定制化扫描策略掌握了基础扫描后你可以通过调整配置来让Tsunami更贴合你的实际需求。5.1 性能调优与大规模扫描当需要扫描数百甚至上千台主机时默认配置可能效率不高。你可以从以下几个方面优化并行扫描Tsunami本身是单线程按顺序扫描目标的。要实现并行化你需要借助外部工具例如使用xargs或编写一个简单的Shell/Python脚本将IP列表分片同时启动多个Tsunami容器实例。务必注意控制并发数避免对网络和目标系统造成过大压力。# 示例使用GNU parallel并行扫描一个IP列表文件 cat target_ips.txt | parallel -j 4 docker compose run --rm tsunami --ip-v4-target{} --config-path/tsunami-config/tsunami.yaml这个命令会以最多4个并发任务的方式扫描target_ips.txt中的所有IP。-j 4表示并发数请根据扫描主机的CPU和网络带宽调整。Nmap参数优化在tsunami.yaml的port_scanner部分调整nmap_args可以显著影响速度和隐蔽性。提高速度--min-rate1000每秒最少发送1000个包--max-retries1减少重试。增加隐蔽性-T2Polite模式速度慢但更安静-f分片数据包--data-length附加随机数据。调整端口范围只扫描业务相关的端口而不是全端口能极大缩短时间。插件选择策略在配置文件中只启用与目标环境相关的插件。例如如果环境中没有数据库就禁用ExposedMongoDB,ExposedRedis等插件。这能减少不必要的探测流量和扫描时间。5.2 编写自定义检测插件进阶Tsunami的强大之处在于其可扩展的插件体系。如果你有一个内部使用的、具有特定指纹的服务或一个公开漏洞的POC可以将其封装成Tsunami插件。一个最简单的检测插件通常包含以下几个Java类Detector类核心检测逻辑。实现VulnerabilityDetector接口在detect方法中编写检测代码。BootstrapModule类使用Google Guice进行依赖注入的配置模块。PluginDefinition类定义插件元数据如名称、版本、描述、支持的服务类型等。官方提供了详细的 插件开发示例 。开发完成后将编译好的JAR包放入插件目录并在配置文件中引用插件名即可。这允许你将内部的安全检查流程标准化并自动化。6. 实战避坑指南与常见问题排查在实际使用中你肯定会遇到各种问题。以下是我总结的一些典型“坑”及其解决方案。6.1 扫描失败或结果为空问题现象扫描很快结束日志显示“0 open ports”或漏洞检测阶段直接跳过。可能原因与排查网络不通这是最常见的原因。确保扫描主机能ping通目标IP。如果目标有主机防火墙如firewalld, iptables需要临时放行扫描源IP或使用更隐蔽的扫描模式如-sS可能被拦截可尝试-sT全连接扫描但不够隐蔽。Nmap参数问题配置文件中的-Pn参数是“无ping扫描”即假设主机存活。如果目标禁用了ICMP回应这是正确的。但如果网络本身有隔离扫描器可能无法到达目标。可以尝试去掉-Pn让Nmap先进行主机发现。目标端口未在列表中检查target_ports配置是否包含了目标实际开放的业务端口。可以先用手动执行nmap -sS -p- 192.168.1.100来确认目标开放了哪些端口。6.2 服务识别不准确或失败问题现象日志显示开放了80端口但服务识别为unknown或版本号识别错误。可能原因与排查服务指纹干扰目标服务可能修改了默认的Banner信息。Nmap的版本探测-sV依赖于Banner。此时需要更深入的探测可能需要调整--version-intensity级别最高为9但会大幅增加扫描时间。服务需要交互有些服务如某些FTP、Telnet在建立连接后需要一定的交互才能返回Banner。标准的Nmap版本探测可能无法处理。这种情况通常需要专门的手动测试或编写自定义插件。TLS/SSL加密对于HTTPS服务443端口Nmap需要能够协商TLS。如果目标使用自签名证书或不支持的加密套件可能导致识别失败。可以尝试在nmap_args中添加--script ssl-enum-ciphers来获取更多TLS信息。6.3 插件误报与漏报问题现象插件报告了一个漏洞但手动验证发现不存在误报或者手动验证存在的漏洞Tsunami没有报告漏报。可能原因与排查误报通常发生在基于版本号比对的插件上。插件发现服务版本在受影响范围内就报告但目标可能已经打了补丁只是未更新Banner。任何自动化工具的发现都必须经过人工验证对于Tsunami的报告你应该根据它提供的IP、端口和漏洞信息使用专门的概念验证PoC工具或手动步骤进行二次确认。漏报插件未启用检查配置文件中是否启用了对应的检测插件。服务识别偏差如果服务识别错误例如将Tomcat识别为普通HTTP服务那么针对Tomcat的漏洞插件就不会被触发。漏洞检测逻辑限制有些插件的检测逻辑可能不够全面或者漏洞利用条件非常特殊。自动化工具无法覆盖100%的漏洞。网络限制某些漏洞检测需要发送特定的探测Payload如果中间有WAF或IPS设备可能会被拦截导致检测失败。6.4 性能问题与资源占用问题现象扫描速度极慢或者Docker容器占用大量CPU/内存。可能原因与排查目标过多或端口范围过大这是最主要的原因。将大范围扫描拆分成多个小任务并行执行。Nmap参数过于激进过高的--min-rate可能导致网络拥堵或目标丢包反而需要重传降低效率。适当调低速率。插件执行耗时一些插件特别是弱口令检测插件WeakCredential如果使用了大型字典会进行大量的网络登录尝试极其耗时。建议在针对大量目标扫描时暂时禁用此类插件或使用精心裁剪的小字典。容器资源限制可以为Docker容器设置CPU和内存限制防止单个扫描任务耗尽主机资源。7. 将Tsunami集成到自动化工作流Tsunami的真正威力在于其可编程性和可集成性。你可以将它作为CI/CD流水线中的一个环节或者作为一个定期的自动化安全巡检任务。7.1 与CI/CD工具集成例如Jenkins你可以在Jenkins Pipeline中增加一个安全扫描阶段pipeline { agent any stages { stage(Build) { steps { // 你的构建步骤 } } stage(Security Scan with Tsunami) { steps { script { // 假设你的应用部署到了某个测试环境IP def targetIp 10.0.1.50 sh docker run --rm --networkhost \ -v \$(pwd)/tsunami-config:/tsunami-config \ -v \$(pwd)/scan-results:/scan-results \ ghcr.io/google/tsunami-security-scanner:latest \ --ip-v4-target${targetIp} \ --config-path/tsunami-config/tsunami.yaml \ --scan-results-local-output-formatJSON \ --scan-results-local-output-filename/scan-results/latest_scan.json // 解析扫描结果如果发现CRITICAL或HIGH级别的漏洞则令构建失败 def scanResults readJSON file: scan-results/latest_scan.json def highOrCriticalFindings scanResults.findAll { it.vulnerability.severity in [CRITICAL, HIGH] } if (!highOrCriticalFindings.isEmpty()) { error 安全扫描发现 ${highOrCriticalFindings.size()} 个高危漏洞构建失败。请查看详细报告。 } } } } stage(Deploy) { steps { // 只有安全扫描通过才进行部署 } } } post { always { // 总是将扫描结果归档 archiveArtifacts artifacts: scan-results/latest_scan.json, fingerprint: true } } }这个流水线会在构建后对测试环境进行安全扫描如果发现高危漏洞则自动失败阻止有已知高危漏洞的版本被部署。7.2 定期自动化扫描与告警使用Linux的cron或更现代的调度系统如Apache Airflow可以定期执行Tsunami扫描。结合Elasticsearch和Kibana的告警功能Elastic Alerting可以实现自动告警。例如你可以设置一个Kibana告警规则条件当tsunami-scan-results*索引中在最近1小时内新出现的文档中vulnerability.severity字段为CRITICAL。动作发送邮件到安全团队邮箱或通过Webhook触发一个Slack/钉钉消息。这样一旦扫描发现新的严重漏洞安全团队就能在几分钟内得到通知迅速启动应急响应流程。我个人在多个项目中实践了这套流程最大的体会是自动化是安全运营的基石。将Tsunami这样的工具从“偶尔手动运行一下”变成“流水线中不可或缺的一环”才能真正实现安全左移让漏洞在造成实际影响前就被发现和修复。刚开始集成时可能会遇到不少适配问题比如网络权限、扫描时机、结果解析等但一旦跑通它带来的安全能见度和效率提升是巨大的。最后一个小建议定期比如每季度回顾和更新你的tsunami.yaml配置文件尤其是插件列表和Nmap参数以适应不断变化的网络环境和新的威胁情报。
