Waf

原文地址： 雷池WAF入门教学-配置HTTP80跳转HTTPS443 部署图先决条件 自备SSL证书,收费申请集体域名SSL证书步骤省略，请自行百度收费证书申请 一个crt文件，一个key文件参考配置我的WAF和web站点在同一台服务器下面 1. 批改利用本身nginx的端口为其余端口因为WAF和本人的web网站利用在同一台服务器上，会存在端口抵触，所以要先批改利用本身nginx端口为非80和443端口的其余端口，我的是8000，本人依据本人状况批改为其余端口，只有和服务器已有端口不抵触即可。 查看服务器已存在端口命令 netstat -an|grep LISTEN|grep -v unix批改nginx 监听80批改为其余端口从新加载nginx配置nginx -t nginx -s reload2、雷池WAF增加防护站点增加http站点端口：80 因为我的WAf和站点在同台服务器上，所以上游服务器写的是127.0.0.1:8000，依据本人状况批改。 增加https站点 端口：443勾选SSL，上传证书文件，依据本人状况批改。上游服务器都指向同一个网站利用地址提交3、批改雷池WAF的nginx转发配置默认雷池nginx代理配置文件门路下 /data/safeline/resources/nginx/sites-enabled批改80端口对应的站点配置文件，设置80跳转443 # 在server节点中减少rewrite ^(.*)$ https://$host$1 permanent; 从新加载雷池nginx配置# 测试nginx配置是否正确docker exec -it safeline-tengine /usr/sbin/nginx -t# 从新加载配置docker exec -it safeline-tengine /usr/sbin/nginx -s reload4、浏览器测试拜访http://站点 查看申请重定向到https://站点 主动重定向到https

WAF 简介WAF 即 Web 利用防火墙（Web Application Firewall）的简称，其作用是通过一系列安全策略来为 Web 利用提供平安防护。WAF 专门针对 Web 利用而设计，可能无效地避免诸如 SQL 注入、XSS 攻打等常见 Web 攻打。 WAF 常见的产品状态有三种模式：软件 WAF、硬件 WAF、云 WAF。其中硬件 WAF 是最传统惯例的产品状态，本文内容也重点波及硬件 WAF。 部署模式硬件 WAF 的部署模式次要有：反向代理、通明代理、通明桥、流量镜像等。 反向代理反向代理（Reverse Proxy）是一种网关技术，它旨在服务器和客户端间建设一个代理关系，使得客户端能够通过反向代理网关变相地与实在服务器进行通信。反向代理的 WAF 不扭转客户端的实在申请内容，而是将申请转发到后盾的实在服务器，而后将服务器的响应返回给客户端。反向代理 WAF 的工作口具备本人的 IP 地址，客户端理论是与 WAF 建设 TCP 连贯，再由 WAF 应用本人的 IP 与服务器建设申请关系。典型的部署架构如下： 其特点是实在的服务器暗藏在 WAF 前面，客户端对服务器的拜访强依赖 WAF 的代理。这样的架构能够使 WAF 作为中间人很容易地进行 HTTP 及 HTTPS 防护。 通明代理通明代理（Transparent Proxy）也是一种代理技术，其不具备本人的 IP，客户端发动申请的目标 IP 就是服务器 IP。通明代理 WAF 个别串联在客户端与服务器之间，别离用服务器 IP 与客户端建设连贯，用客户端 IP 与服务器连贯，以达到“中间骗”的目标。一种常见部署模式如下图： 其中实线代表着实在的 TCP 连贯，虚线代表着从客户端和服务器的角度看到的网络连接。因为它是一种劫持代理技术，所以这种部署形式从物理拓扑上要求代理网关会接管到客户端与服务器通信的所有内容，否则会呈现一端 TCP 收包不全而产生连贯超时景象。 这种模式的特点是对网络逻辑拓扑侵入性小，不须要为 WAF 布局 IP 资源，其作为中间人也能够同时防护 HTTP 和 HTTPS。 通明桥通明代理 WAF 是会与客户端服务器中间都建设实在的连贯，那咱们可不可以实现真通明，劫持连贯来做防护呢？答案就是应用通明桥。 通明桥（Transparent Bridge）部署的拓扑地位与通明代理相似，也是串联在客户端与服务器的必经之路上。但其不参加到 TCP 连贯中，它不会扭转数据包的任何一个字段，只是在串联的链路防护，平安的数据包就会放过 WAF 达到目的地。能够参考上面的示意图： 这种模式的特点与通明代理一样，不会对网络拓扑有逻辑入侵。因为不侵入 TCP 层，它能够随上随下且不会造成断流，如果两头有数据包因为选路起因没有通过 WAF，也不会影响连贯。是一种更为便捷的部署模式。 流量镜像下面几种模式都是串联在网络中，但某些网络不容许串联除失常网络设备之外的其余网关，同时也有平安防护的需要，那有没有什么方法满足呢？答案是有。这时流量镜像模式就能够派上用场了。 流量镜像（Traffic Mirroring）模式如上图所示，客户端与服务器间会通过交换机，这时能够应用交换机的端口镜像性能，将 Web 申请流量的原始帧镜像给 WAF，WAF 将数据帧还原成原始申请就能够对流量进行剖析。 这个模式的特点是：对网络没有任何侵入性，可靠性更高。 各模式比照部署模式部署地位是否检测 HTTPS通过 WAF 后是否会扭转数据包WAF 的部署会否影响原链路反向代理串联能是是通明代理串联能是轻微影响通明桥串联否否不影响流量镜像旁路否-不影响收费靠谱WAF举荐自己次要是用的收费WAF为长亭科技推出的雷池社区版。雷池的部署状态上能够反对硬件、软件、云等场景，硬件版雷池对以上提到的部署模式均有反对。 附上雷池社区版官网链接，感兴趣的敌人们能够看看～waf-ce.chaitin.cn/

本穷鬼始终在找好用且收费的WAF，偶尔关注到长亭科技4月份公布了免费版WAF-“雷池社区版”，该产品主打的是外围检测能力由智能语义剖析算法驱动。 自己通过一段时间的水群和体验产品后，发现产品迭代十分快，且社群气氛也十分不错（产品团队给的技术支持十分给力，回复很及时且小白的问题也能失去回复；除此之外，也能够间接在群里或github里提冀望的需要）。趁着雷池社区明天公布2.0版本，在这也做个小小分享。 雷池社区版 1.x 系列个人感觉雷池社区版1.x版本次要是满足根底防护需要，目前具备的性能次要有： 语义剖析驱动的 Web 攻打防护可视化 Dashboard 与流量统计分析自定义防护模式、黑白名单、IP 库网站一键关停雷池社区版 2.0而后再说说明天公布的雷池社区版2.0版本。感觉2.x版本应该会减少更多高级防护能力，全新版本推出“人机验证”能力还是蛮惊艳的。 “Bot 治理”、“流量建模”、”网站监控“、“API 治理”、“限频限流”、“拟态防护” 等性能也在产品团队的布局中（有雷同需要的小伙伴请速来github仓库的issue点星星，据说产品团队会依据社区的呼声动静调整优先级）。 雷池 “ 人机验证 ” 能力Bot 利用自动化程序对网站进行探测，其通过非法无效的拜访实现自动化攻打，以达到获取外围零碎权限、窃取敏感信息、植入恶意软件、发动 DDoS 攻打等目标。 雷池的 “人机验证” 能力是专为社区用户提供的收费防 Bot 解决方案，无需开发，只有通过界面简略配置规定即可失效，感觉还是比拟小白敌对且比拟实用的性能了。 配置实现后，符合条件的申请在拜访时就会看到雷池的人机验证页面。 雷池会应用客户端指纹、JS 挑战、交互行为辨认、浏览器反调试、IP 画像等形式综合验证环境的安全性，辨认有歹意偏向的 Bot 客户端并施行阻断。 综上所述，感觉雷池社区版还是一个比拟好用的收费WAF。有相干需要的小伙伴们能够尝试一下。最初挂个官网链接https://waf-ce.chaitin.cn/

前言最近有WAF bypass的需要，学习了下分块传输的办法，网上也有burp插件，须要应用python实现一下，在应用requests实现时遇到了一些坑，记录下。 requests块编码申请https://docs.python-requests.... 申请参数data提供一个生成器即可 首次引入分块传输： https://github.com/psf/reques... 应用burp代理分块传输不失效为了能够精确的看到代码是否失效，我给requests配上了burp代理，然而在看burp捕捉的报文中发现分块传输并未失效 论断并不是应用了burp代理后requests分块传输不失效，而是分块传输产生在Client与代理Server之间，burp申请转发并没有应用分块传输，所以在burp上的抓包状况看没有应用分块传输。 抓包验证本地抓包 (Client与代理Server) POST http://xxcdd.for.test.com/vulnerabilities/exec/ HTTP/1.1Host: xxcdd.for.test.comConnection: closeAccept-Encoding: gzip, deflateAccept: */*User-Agent: Mozilla/4.0 (compatible; MSIE 7.0; Windows NT 5.1; The World)Accept-Language: zh-cn,en-us;q=0.7,en;q=0.3Content-Type: application/x-www-form-urlencodedCookie: security=low; PHPSESSID=f49c32abdce4380305503cde9e522e67Transfer-Encoding: chunked2ip3=12173.0.30.11&1S2ub3mit3=Su2bm2it0HTTP/1.1 200 OKDate: Sat, 08 May 2021 08:31:10 GMTServer: Apache/2.4.39 (Unix) OpenSSL/1.0.2s PHP/7.3.7 mod_perl/2.0.8-dev Perl/v5.16.3X-Powered-By: PHP/7.3.7Expires: Tue, 23 Jun 2009 12:00:00 GMTCache-Control: no-cache, must-revalidatePragma: no-cacheContent-Length: 4489Connection: closeContent-Type: text/html;charset=utf-8<!DOCTYPE html>burp申请转发 POST /vulnerabilities/exec/ HTTP/1.1Host: xxcdd.for.test.comConnection: closeAccept-Encoding: gzip, deflateAccept: */*User-Agent: Mozilla/4.0 (compatible; MSIE 7.0; Windows NT 5.1; The World)Accept-Language: zh-cn,en-us;q=0.7,en;q=0.3Content-Type: application/x-www-form-urlencodedCookie: security=low; PHPSESSID=f49c32abdce4380305503cde9e522e67Content-Length: 26ip=127.0.0.1&Submit=SubmitHTTP/1.1 200 OKDate: Sat, 08 May 2021 08:34:44 GMTServer: Apache/2.4.39 (Unix) OpenSSL/1.0.2s PHP/7.3.7 mod_perl/2.0.8-dev Perl/v5.16.3X-Powered-By: PHP/7.3.7Expires: Tue, 23 Jun 2009 12:00:00 GMTCache-Control: no-cache, must-revalidatePragma: no-cacheContent-Length: 4489Connection: closeContent-Type: text/html;charset=utf-8<!DOCTYPE html>Debug requests的分块传输过程确定断点requests源代码全局搜寻chunked，确定断点 ...

背景WAF作为根底平安能力建设的必要一步，在为业务提供抵挡Web攻打方面，施展着重要作用，然而不论是公司外部自研WAF还是购买成熟的商业WAF产品，都绕不过一个问题——如何保障WAF不会升高业务的稳定性。举个例子，如果WAF挂了，怎么能保障业务失常运行？旁路部署，就能很好的解决上述问题，既能够测试WAF产品性能和稳定性，也不会影响业务。那旁路部署，如何把流量输入给WAF，就很要害了。是在网络设备上做全流量镜像，还是通过日志复原，又或者是利用业务程序把申请多转发一次？每一种办法施行的老本和对业务稳定性影响各不一样，上面一一阐明。 流量镜像流量镜像分为两个方面：网络设备上做和应用层软件层面做，以下别离阐明这两种形式优缺点： 交换机流量镜像流量镜像应该是旁路部署最罕用也是最适宜的形式了。在网络设备（如交换机）上间接通过一条命令，把指定网络端口流量，齐全镜像到另外一个端口。这种办法的益处是： 业务齐全无感知数据和理论业务收到的数据统一操作简略但毛病也很显著业务流量大的话，对网络设备性能是个考验。如果流量加密的话，是否能解密值得商讨。私有云场景下无奈应用。比方用的是阿里云是否有网络流量汇聚点。能够看出，流量镜像尽管简略，易操作，影响小，但真正想让WAF发挥作用或者测试WAF性能，仍然有很多问题要解决。Nginx流量镜像nginx流量镜像分为三种形式，三种形式操作各不一样 nginx_mirror_moduleNginx1.13.4开始引入了nginx_mirror_module模块，这个模块的作用是把指定的流量转发到指标服务器，但须要留神的是，这个模块会抛弃指标响应，成果和交换机网络流量镜像一样。因为默认该模块不在nginx编译参数中，所以要应用这个模块的话，须要从新编译Nginx并且版本要大于1.13.4。但这个模块有个致命的毛病，复制的镜像申请和原始申请是相关联的，若镜像申请没有解决实现，原始申请就会被阻塞。openresty ngx.location.capture该模块用于发动一个异步非阻塞的子申请到Nginx internal路由，同样，该模块也是疏忽子申请的相应。所以，不会打断业务流程，相似的还有ngx.location.capture_multi模块。但这个模块有两个毛病，毛病一：无奈转发到内部的服务器，必须配合upstream才能够。毛病二：http2反对不齐全，存在bug，目前作者还没有解决。感兴趣的能够关注作者更新。最初，该模块在1.17.8.2之前的版本中存在一个CVE-2020-11724破绽，应用的时候，须要留神。申请转发应用层申请转发最初一种思路，就是在应用层，把web申请相干的数据，解析进去结构新的http申请，转发给WAF。这样做，对应用层来说可控性绝对较高，但相应的，性能耗费也比拟高，如果业务曾经存在相似于APIGateway之类的应用层转发零碎，那么实现起来绝对会容易一些。但应用层转发申请，是无奈把服务器响应的数据发给WAF的，这样，WAF检测只能是单向流量的检测。对于想基于返回数据检测的WAF规定，就生效了。比方返回数据量大小、敏感数据检测等 openresty lua-resty-http 库lua-resty-http是openresty的一个http client库，能够在nginx配置文件中便编写lua代码，解析web申请相干的字段和数据，而后从新结构http申请数据，把用户的申请转发给WAF。尽管这个办法看似比较简单，然而须要肯定的编码，比方转发哪些数据？这些数据都须要调用相应的Nginx moudle去获取，比方Header、url、body，如果是文件的话，还须要解析响应的文件。应用层业务代码相似于Gateway之类的应用层转发控制程序，也是能够把web申请的数据，通过结构新的HTTP申请，转发给WAF，但这样的话，对应用层代码的改变和对应用层转发业务的性能耗费都须要业务方思考。安全部门须要业务部门的配合，才可能施行。技术上难度不大，次要是是否推动业务部门批改。基于日志还原申请最初一种方法，是基于Nginx或者其余相似的web服务器日志，还原HTTP申请。能够通过把申请的相干数据输入到日志文件中，另外安全部门能够开发相应的脚本，依据日志还原流量。然而这个办法在业务流量低的场景实现比拟容易，对于web申请量比拟大的场景，存在两个问题： 日志输入的多影响机器性能打印耗费大量的磁盘IO总结本片文章次要介绍了几种把web申请流量打给WAF的办法，从而可能应用WAF检测Web攻打，辨认以后服务平安危险。各个公司、各个业务对平安的诉求不同，想要达到的成果也不同，因而，安全部门在建设平安能力时，应充沛理解业务的诉求，从而抉择适合的计划，部署WAF。