最近一些项目的站点经常发告警短信，提示网站无法访问。通过排查，发现后端数据库资源都被耗尽（连接数上千，正常情况是小于100），负载也高得吓人，如下图所示。
“load average”数值最高的时候，能超过1000。再排查访问异常站点的Web日志，大致判断是被人盯上了。为了解决这个问题，在不能增加任何投入的情况下，决定部署一套开源的WAF。通过综合评估，最终选择雷池作为安全防范工具，部署在网络的边界处。由于项目涉及的项目很多，重新解析域名会带来麻烦，因此我决定将负载均衡的公网VIP迁移到WAF网关，而负载均衡器的VIP设置成内网地址。这样一来，后端的网络结构一概不用改变，大大降低了操作风险。下图为添加WAF前与添加WAF的结构对比。
因为没有经费支持，只好找了一个有公网地址的Proxmox VE单节点系统，创建好虚拟机并安装好操作系统Centos 7,系统能正常远程正常访问后，以网络方式安装好WAF平台雷池。这个WAF雷池安装非常简单，就一条指令“bash -c “$(curl -fsSLk https://waf-ce.chaitin.cn/release/latest/setup.sh)“”解决问题（如下图所示）。
指令正常执行完毕以后，用浏览器访问WAF的公网IP并加默认端口号“9433”进入管理后台登录界面（如下图所示）。
设置好站点防护以后，确实起到了很大的作用，数据库并发连接数恢复到几十个，而数据库所在系统的“load average”保持在3以下，即便各种非正常访问请求任然猖獗（如下图所示）。
所有项目的网站在WAF的保护下运行平稳，大家以为可以稍微松一口气了，突然，相关人员接到IDC机房打来的电话，告知提供网关服务的WAF所使用的公网地址，同时被解析到不相干的域名，需要立即处理，不然就要封IP，而且给出了时限（限定一个小时内处理）。再半小时内，接连来了好几个电话。经运营人员排查，是某个注册用户，错误地将他个人域名解析到WAF所绑定的公网地址。运行人员根据平台上的注册信息，多次联系该用户，无果。IDC机房的人给了一个折中的方案，当访问这个被错误解析过来的域名，返回错误代码“403”就可以应付过去。
登录WAF Web管理后天，防护站点添加错误解析过来的域名“secooler.cn”，端口号“80”，并随意填写一个上游服务器的内网地址，如下图所示。
提交这个设置，然后以SSH客户端登录到WAF所在的宿主系统。进入WAF后台Web工具Nginx相关的配置目录，此目录默认的安装位置为“/data/safeline/resources/nginx”，在这个目录里，有Nginx的主配置文件“nginx.conf”,这个文件的最后几行，以包含方式将我们从WAF管理后台添加的“防护站点”作为分支配置，如下图所示。
因为WAF是在Docker下管理和运行Nginx服务的，所以配置文件的目录实际为“/data/safeline/resources/nginx/sites-enabled”等。进入这个目录，以关键字“secooler”在此目录检索，看其具体存在于哪个文件，方便做进一步的定位，如下图所示。
根据输出，手动从WAF Web管理后天添加的这个被错误解析过来的域名，存在于文件“IF_backend_20”。打开文本文件“IF_backed_20”，大概在这个文件的第45行，有一个http跳转，如下图所示。
乘热打铁，切换到目录“/data/safeline/resources/nginx/custom_params”，找到文件backend_20(这个文件也是在WAF Web添加域名后，自动生成的)，默认情况下，它是个空文件。编辑这个文件，插入文本行“return 403;”如下图所示。
保存修改，执行命令“docker exec -it safeline-tengine nginx -t”进行Nginx的语法检查，无误后继续执行命令“docker exec -it safeline-tengine nginx –s reload”重启Nginx服务。
用浏览器或者命令行访问www.secooler.cn,返回http状态码403，IDC机房那边来消息说可以了，问题解决。
