作者:田逸
最近一些项目的站点经常发告警短信,提示网站无法访问。通过排查,发现后端数据库资源都被耗尽(连接数上千,正常情况是小于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机房那边来消息说可以了,问题解决。