在国产化替代的推进过程中我最近把一批业务从 x86 迁到了 arm64 的银河麒麟 V10 服务器上系统层面倒还好最头疼的是 Web 安全防护一直没落位。以前惯用的商业 WAF 授权贵不说对新架构的适配也磨磨蹭蹭。后来调研了一圈发现长亭的雷池 WAF 社区版值得一试——免费、支持 arm64 镜像、部署走 docker-compose跟现有运维方式能无缝衔接。这篇就把我在麒麟 V10 arm64 上从零安装、初始化、接入防护站点的完整过程写出来尤其是离线环境的处理和各种容易踩的坑给同样要在信创环境里做 Web 防护的同学当个参考。1. 为什么会在 arm64 麒麟上选雷池 WAF1.1 雷池 WAF 到底解决什么问题雷池 WAFSafeLine是一款开源的 Web 应用防火墙核心作用是把真实的 Web 业务隐藏在后面所有外部请求先经过它识别一遍再把干净流量转给后端。它对常见的 Web 攻击有现成的拦截规则比如 SQL 注入、XSS 跨站脚本、命令注入、路径穿越、恶意文件上传这些基本覆盖了 OWASP Top 10 里的大部分场景。我比较看重的是它的检测方式。传统 WAF 靠正则匹配规则写得好不好直接影响效果误报和漏报很难平衡。雷池社区版的检测引擎会对请求做语义层面的解析再结合模式匹配同一个攻击特征被编码、分块、变形之后仍然能识别误报率比纯正则方案低不少。这个特性在实际运维里很重要不然上线第一天就被各种业务误报轰炸早晚得拆掉。雷池社区版对个人和中小团队免费商用要另外谈授权但社区版的功能已经覆盖了日常防护的大部分需求。1.2 arm64 和 amd64 在软件部署上差在哪先解释一个最基础的概念arm64 和 amd64 是两种 CPU 指令集架构amd64 是 Intel/AMD 阵营的 64 位架构arm64 是 ARM 阵营的 64 位架构指令集完全不兼容。这意味着在 x86 上编译好的二进制程序不能直接在 arm64 上运行必须拿对应架构的版本。放到 Docker 场景里镜像也是区分架构的同一个镜像仓库下通常会有 linux/amd64 和 linux/arm64 等多个平台的 tag。Docker 默认会拉取与当前宿主架构匹配的镜像但如果镜像仓库没有发布 arm64 版本安装过程就会报no matching manifest for linux/arm64之类的错误。这也是很多流行软件在国产化 arm64 环境里装不上的根本原因不是系统不行是软件没有适配。所以评估雷池 WAF 能不能在麒麟 V10 上用第一件事就是确认它的官方 Docker 镜像是否发布了 arm64 版本。我实测下来雷池社区版目前的镜像已经做了 arm64 适配在线和离线两种安装方式都能在 arm64 环境跑通。1.3 方案选型时我对比过哪些替代品在确定雷池之前我把市面上常见的几个开源 WAF 都过了一遍大致情况是这样ModSecurity 配合 Nginx老牌方案规则库庞大但纯正则匹配为主性能开销大配置复杂对新手不友好而且 arm64 下编译要自己折腾依赖。CorazaGo 实现的 WAF 引擎部署轻量但生态相对小图形化管理界面基本没有落地全靠写配置。雷池 WAF 社区版自带管理后台图形化添加站点、配置证书、查看日志Docker 一键部署arm64 镜像齐全检测能力也不错。对运维团队来说一个能可视化管理的 WAF 太重要了。纯命令行配置 WAF 不是不能用但遇到问题排查起来效率太低。雷池的社区版恰好补齐了这个短板这也是我最后选它的直接原因。2. 麒麟 V10 环境准备与 Docker 安装2.1 先确认系统版本和 CPU 架构别急着动手不管装什么软件第一步永远是确认环境。麒麟 V10 这个产品线比较复杂有服务器版、桌面版底层有的基于 RPM 体系有的基于 DEB 体系不同小版本之间的命令和软件源差异比较大。我这次用的是银河麒麟高级服务器操作系统 V10 SP3属于 RPM 体系默认走 yum/dnf 包管理。执行下面三条命令先把底摸清楚cat /etc/os-release uname -m lscpu | grep Architecture如果输出里看到aarch64说明 CPU 架构就是 arm64后续所有镜像和安装包都要按 arm64 来选。如果看到x86_64那就是 amd64 环境。我遇到过有人拿 x86 的镜像包硬往 arm64 上装折腾半天都是白费功夫。另外建议一并用df -h看下磁盘空间因为 Docker 镜像和日志都比较占空间建议给/var/lib/docker所在的目录预留至少 20GB 以上余量。2.2 在线安装 Docker 的操作步骤麒麟 V10 服务器版可以直接添加 Docker 官方 CentOS 源来安装但因为系统标识是 Kylinyum 可能会把 releasever 识别成奇奇怪怪的版本号。比较省事的做法是直接配置阿里云的 docker-ce 镜像源然后固定用--releasever8参数来装具体命令如下sudo yum install -y yum-utils sudo yum-config-manager --add-repo https://mirrors.aliyun.com/docker-ce/linux/centos/docker-ce.repo sudo yum makecache --releasever8 sudo yum install -y docker-ce docker-ce-cli containerd.io --releasever8装完之后依次启动 Docker 并验证sudo systemctl enable docker sudo systemctl start docker docker version执行docker version能看到 Client 和 Server 两段信息如果 Server 段也正常输出说明 Docker 守护进程已经在跑了。这里有个容易忽略的细节很多人只看到 Client 信息就以为成功了其实 Server 没起来后面所有容器都跑不了务必确认两段都有输出。我还建议顺手配置一个 Docker 镜像加速器不然拉镜像的时候可能会很慢。麒麟机器如果在内网一般会有自己的镜像仓库配置方式就是修改/etc/docker/daemon.json把 registry-mirrors 指向内部地址然后重启 Docker。2.3 没外网环境怎么办离线安装 Docker 的完整姿势很多生产麒麟机器是隔离网环境不能直接访问外网源这时候需要离线安装。我的做法是在一台能联网的同架构机器上把 Docker 的 RPM 包全部下载下来再拷到目标服务器安装。先在有网机器上执行sudo yum install -y yum-utils sudo mkdir -p /tmp/docker-rpm sudo yumdownloader --resolve --destdir/tmp/docker-rpm docker-ce docker-ce-cli containerd.io --releasever8然后把这个目录打包传进麒麟服务器在目标机器上执行sudo yum localinstall -y /tmp/docker-rpm/*.rpm用yum localinstall而不是rpm -ivh是因为它能自动解析本地 RPM 包之间的依赖关系。如果依赖还缺会提示缺少哪些包再单独补就行。离线环境最怕的就是缺依赖时来回拷贝建议打包时把docker-compose-plugin也一起拉下来雷池的 compose 功能要用到它sudo yumdownloader --resolve --destdir/tmp/docker-rpm docker-compose-plugin --releasever8装完同样用docker version验证。3. 雷池 WAF 的两种安装实操3.1 在线一键安装实测跑通的完整流程雷池社区版官方提供了一键安装脚本理论上执行一条命令就能完成安装但我在麒麟环境上还是花了一点时间因为脚本会先检测 Docker 和 docker-compose 插件是否可用。完整命令是bash -c $(curl -fsSLk https://waf.chaitin.com/release/latest/setup.sh)这个脚本执行后会做几件事检查系统架构、检查 Docker 环境、生成默认的安装目录/data/safeline然后拉取所需的 Docker 镜像并用 docker-compose 把它们编排起来。我在 arm64 麒麟上执行时脚本顺利识别到了架构没有出现架构不匹配的报错。如果需要指定安装目录可以用环境变量方式传参比如export SAFELINE_DIR/data/safeline bash -c $(curl -fsSLk https://waf.chaitin.com/release/latest/setup.sh)整个拉镜像过程耗时取决于网络情况我这边大概几分钟。如果长时间卡在某一个镜像上不动多半是网络到 Docker Hub 不通畅可以给 Docker 配好镜像加速器后重新执行脚本。脚本执行到最后会打印管理后台地址、默认端口和初始账号信息一定要保存好。3.2 离线包安装适配隔离网环境的正确姿势对不能访问外网的机器雷池官方也提供离线安装包这点在选型时很加分。离线包需要提前在能联网的机器上下载而且必须选对架构——arm64 的机器要下载 arm64 版本的离线包x86 的下载 amd64 版本两者不能混用。我这次是在有网的同架构测试机上从雷池官网下载中心把离线包safeline-offline-xxx-arm64.tar.gz拉下来然后上传到麒麟服务器上。安装步骤tar -xzf safeline-offline-xxx-arm64.tar.gz cd safeline-offline sudo bash setup.sh脚本会把离线包里的镜像 load 进 Docker再生成 compose 文件并启动服务。整个过程不需要访问外网只要镜像文件完整就能装。相比在线安装离线包的好处是版本固定、可重复部署适合多台机器批量交付缺点是需要手动关注版本更新升级时要重新下载新的离线包。3.3 安装完成后的验证命令与关键检查项安装脚本跑完不等于安装成功一定要自己动手验证一遍。先用命令查看容器是否全部处于运行状态docker compose -f /data/safeline/docker-compose.yml ps正常情况下你会看到 safeline-tengine、safeline-detector、safeline-mgt-api、safeline-mario 以及配套的 postgres、redis 等容器状态都是 Up。核心的是前三个tengine 负责流量入口detector 做检测mgt-api 是管理后端。另外建议检查一下镜像架构是否真的匹配docker inspect --format {{.Architecture}} 容器镜像名或ID输出应该是arm64。这一步很多人跳过但在 arm64 环境里非常关键如果不匹配运行时会频繁报异常甚至在 qemu 模拟层下跑得奇慢无比。管理页面默认通过 HTTPS 的 9443 端口访问所以还要确认安全组和防火墙有没有放行。4. 初始化配置与防护规则落地4.1 首次登录管理后台并完成基础设置安装完成后浏览器访问https://服务器IP:9443。因为用的是自签名证书浏览器会有安全提示点击继续访问即可。首次打开会进入初始化页面需要创建一个管理员账号设置登录密码。这里要提醒一句密码强度一定要够因为管理后台是安全产品的核心一旦被攻破整个防护体系就形同虚设了。登录进去之后我建议先做三件事一是到系统设置里把管理后台的会话超时时间调短一点降低管理端暴露的风险二是确认服务时间和系统时间一致日志时间错乱会让后续排查非常痛苦三是浏览一下仪表盘确认 WAF 状态显示正常、检测引擎已启用。雷池的管理界面整体设计得比较直观左侧菜单包含站点管理、证书管理、黑白名单、日志中心、系统设置等模块基本不需要看文档就能上手。4.2 把第一个 Web 站点接入 WAF雷池接入站点的方式和 Nginx 反代很像本质就是把流量先引到 WAF再由 WAF 转发给后端源站。在管理后台的“站点管理”里点击添加站点需要填写几个关键参数域名或 IP、源站地址和端口、WAF 监听端口。我这次测试时域名填了test.local源站指向本机 19090 端口的一个 Nginx 测试服务WAF 会自动分配一个监听端口也可以手动指定 80。为了测试方便我在/etc/hosts里加了一条解析echo 127.0.0.1 test.local /etc/hosts如果你在公网环境接入真实业务需要把域名的 DNS 解析切换到 WAF 所在的服务器 IP而不是直接解析到源站。这一步很关键如果 DNS 还指向源站请求根本不会经过 WAF防护规则再强也白搭。关于证书雷池可以在证书管理里上传已有的 SSL 证书也可以在站点的 HTTPS 配置里选择现有证书。如果暂时没有证书可以先以 HTTP 形式接入测试后续配上证书后直接在站点设置里切换即可不需要重建站点。4.3 怎么确认防护规则真的生效了接入完成后如果不验证一下防护效果心里始终没底。我很推荐用下面这个思路做一轮功能测试先在源站起一个临时测试服务确保它能正常访问然后通过 WAF 访问同一个服务确认流量正常转发最后发送几个常见的攻击特征字符串观察是否被拦截。先起一个测试站点docker run -d --name web-test -p 19090:80 nginx:alpine在管理后台把站点test.local的源站配置指到127.0.0.1:19090然后分别执行几个测试请求# 正常请求应该能正常返回 200 curl -k -H Host: test.local http://127.0.0.1/ # 路径穿越特征测试应该被 WAF 拦截 curl -k -H Host: test.local http://127.0.0.1/?file../../etc/passwd # XSS 特征测试同样期望被拦截 curl -k -H Host: test.local http://127.0.0.1/?qscriptalert(1)/script如果 WAF 拦截生效后面两个请求的返回码不是 200而是 403 或者雷池自带的拦截提示页面。再去日志中心的“拦截日志”里看能看到对应的命中记录包括请求时间、来源 IP、攻击类型、命中的规则 ID。5. 常见问题与排查实录5.1 arm64 环境下的几个特有坑arm64 架构在国内还处于快速发展期软件生态整体没有 x86 成熟雷池安装过程中最容易遇到的就是架构不匹配的问题。第一个坑是拉取镜像时报no matching manifest for linux/arm64。出现这个问题要么是某个镜像没有发布 arm64 版本要么是你的 Docker 没有正确识别宿主架构。排查方式是先确认uname -m确实是 aarch64再检查是否设置了DOCKER_DEFAULT_PLATFORM环境变量导致 Docker 一直尝试拉取别的架构。第二个坑是镜像能启动但性能极差。有时候 Docker 会默认尝试拉取 amd64 镜像并通过 qemu 模拟层在 arm64 宿主上运行。这种方式能做功能验证但性能完全不能用于生产。判断方法就是前面提到的docker inspect --format {{.Architecture}}看到amd64就要警惕了。第三个坑是有人喜欢在 x86 开发机上用 qemu 模拟 arm64 环境提前做验证结果模拟环境里跑得好好的部署到真机却出问题。这通常是因为模拟环境和真机的内核版本、系统库版本有差异。我的建议是尽量在真实 arm64 硬件上做预演或者至少保证系统的内核和 Docker 版本一致。5.2 安装脚本和端口冲突的处理雷池默认使用 80 端口作为流量入口、9443 端口作为管理入口。如果服务器上已经装了 Nginx、Apache 或者其他软件占用了 80 端口安装脚本虽然不会报错但后续流量转发会出问题。我的解决思路是如果业务本身依赖 Nginx可以调整雷池 compose 文件里的端口映射把 WAF 的流量入口改成非 80 端口然后在 Nginx 里反代到这个端口。但这样多了一层转发增加了部署复杂度。更推荐的做法是把原 Nginx 作为源站接在雷池后面让雷池直接监听 80/443整体链路更干净。如果只是临时测试把原来的服务停掉最省事。安装过程卡在拉镜像也经常遇到。在麒麟上如果配置了内部镜像仓库可以先把雷池的镜像导出再导入绕开网络问题# 在有网环境拉取镜像后导出 docker save -o safeline-images.tar 镜像列表 # 在离线环境导入 docker load -i safeline-images.tar5.3 麒麟系统层面的一些注意事项麒麟 V10 默认开启了 firewalld如果管理后台一直访问不了多半是防火墙没放行 9443 端口。执行sudo firewall-cmd --permanent --add-port9443/tcp sudo firewall-cmd --permanent --add-servicehttp sudo firewall-cmd --permanent --add-servicehttps sudo firewall-cmd --reload还有磁盘空间问题雷池运行一段时间之后日志和审计数据会持续增长如果磁盘比较小建议定期清理。日志中心里可以设置保留时间也可以直接在系统层面做日志目录的定时清理。系统内核参数如果被优化过也可能影响 Docker 网络。比如net.bridge.bridge-nf-call-iptables如果被关闭容器之间的网络通信会异常。稳妥的做法是不要随意调整运行代理类容器的主机网络参数如果一定要调先确认sysctl net.bridge.bridge-nf-call-iptables的值是 1。提示凡是修改了系统层配置都建议重启 Docker 服务后重新验证容器状态不要直接沿用旧的状态判断。6. 日常使用中我比较推荐的几个运维习惯6.1 备份和恢复的思路雷池的配置都存在/data/safeline目录下包括站点配置、证书、黑白名单、检测日志等。我建议对/data/safeline/resources下的配置目录做定期备份最简单的方式就是打包拷贝到远程存储tar -czf safeline-backup-$(date %F).tar.gz /data/safeline/resources恢复的时候在新的雷池环境上把备份包解压回去再重启容器即可。不过要注意备份和恢复的雷池版本尽量保持一致跨大版本恢复配置可能会出现兼容问题。6.2 规则库和版本更新的节奏雷池社区版会定期发布新版本包含检测引擎的增强和规则库的更新。我建议不要一有新版本就立即升级先看官方更新日志在测试环境验证一轮再上生产。升级方式相对简单管理员可以通过 Web 控制台的可视化操作完成检测引擎升级也可以在/data/safeline目录下执行升级脚本完成版本更新。需要特别注意的是升级前一定要备份数据并且避开业务高峰时段。WAF 升级需要重启所有容器虽然时间很短但对实时流量会有影响最好在维护窗口期操作。6.3 日志和监控的日常关注点雷池的拦截日志是最有价值的安全数据来源我习惯每周看一次日志中心重点关注的几个维度攻击来源 IP 的分布、被攻击最多的业务站点、经常命中的攻击类型。这些信息能帮助判断哪些业务是攻击者重点关注对象也可以反推源站是否有潜在弱点。此外容器资源占用也值得关注。雷池的检测引擎在请求量大的时候会消耗不少 CPU建议用docker stats定期观察资源使用情况。如果在 arm64 机器上发现 CPU 占用持续偏高先确认容器镜像架构是否是 arm64排除 qemu 模拟层的性能损耗再考虑调整检测引擎的并发参数。我在实际使用中还有一个体会WAF 不是装了就能一劳永逸它需要结合实际业务持续调优。比如某些业务场景下正常的 URL 参数里可能会包含类似 SQL 关键字的内容导致 WAF 误报。雷池的日志中心能清楚地看到每一次拦截的完整请求遇到误报时可以通过加白名单、调整规则优先级来处理而不是直接关掉防护。每个部署环境都有自己的特殊性多花一点时间观察日志、适配策略WAF 才能真正发挥价值而不是变成一台只会 403 的拦截机器。