WAF的相关知识记录

本文最后更新于2016年12月23日,已超过 1 年没有更新,如果文章内容失效,还请反馈给我,谢谢!

=Start=

缘由:

最近有一些面试的工作,看到有不少候选人都在简历中提到了WAF的相关内容,虽然我没有开发过WAF,但之前多少有一点了解,但现在已经忘的差不多了,所以没办法很好的评价面试者的实际水平,需要恶补一下相关知识,不求做到精通或熟悉,起码做到心里有数。

在此收集一些WAF的相关文章/链接(除了基本的概念、原理之外,攻防两端的内容都会有一些),方便随时查阅。

正文:

参考解答:

WAF一句话描述,就是解析HTTP请求(协议解析模块),根据规则检测(规则模块),做不同的防御动作(动作模块),并将防御过程(日志模块)记录下来。

参考链接:

=END=

声明: 除非注明,ixyzero.com文章均为原创,转载请以链接形式标明本文地址,谢谢!
https://ixyzero.com/blog/archives/3079.html

11 thoughts on “WAF的相关知识记录”

  1. 定制轻量高效的WAF Naxsi [一]
    https://klionsec.github.io/2017/09/18/naxsiwaf/
    `
    0x01 关于naxsi
    同为开源waf,但跟Modsecurity的不同是,它对nginx的兼容性非常好,不依赖拦截规则库[需要经常更新,且容易被绕过,比较被动],安装定制都非常简单方便,占用的系统资源相对较少,对实际业务的适用性更强[方便的白名单设置],有一定的学习能力,暂时只能拦截从get或者post过来的数据
    `

  2. WAF绕过技巧浅谈
    http://www.freebuf.com/articles/web/160175.html
    https://medium.com/secjuice/waf-evasion-techniques-718026d693d8
    https://medium.com/@themiddleblue/web-application-firewall-waf-evasion-techniques-2-125995f3e7b0
    `
    如今市面上的所有WAF几乎都已具备了对RCE攻击的拦截甚至阻断,但当它发生在Linux系统中时,我们已经有了极为巧妙的方法来绕过WAF规则集。作为渗透测试人员我们最大的朋友不是“狗”,而是“通配符”。
    `

  3. Oceanus:美团HTTP流量定制化路由的实践
    https://tech.meituan.com/Oceanus_Custom_Traffic_Routing.html
    `
    Oceanus是美团基础架构部研发的统一HTTP服务治理框架,基于Nginx和ngx_lua扩展,主要提供服务注册与发现、动态负载均衡、可视化管理、定制化路由、安全反扒、session ID复用、熔断降级、一键截流和性能统计等功能。本文主要讲述Oceanus如何通过策略抽象、查询、渲染和分组动态更新,实现HTTP请求的定制化路由。

    无论是Nginx if指令,还是AB框架,要么需要reload重新加载才能生效,要么无法支持某些业务场景下的分流需求,所以都很难作为解决公司级分流框架的有效手段。针对它们所存在的不足,Oceanus开发了一套应用级、高可扩展的动态分流框架,不仅动态支持各种业务场景的分流需求,而且保证了请求转发的性能,下文将阐述我们如何解决分流机制的几个核心问题。
    `

  4. WAF建设运营及AI应用实践
    https://mp.weixin.qq.com/s/fTm1hUfRmm6ujmjvSHRLUA
    `
    WEB应用防火墙(Web Application Firewall,WAF)是当前对Web业务进行防护的一种比较常用且有效的手段之一,目前市场上的WAF产品也相对比较成熟,任何一个小公司或个人都可以借助一些WAF开源项目进行快速部署上线,但是对于大型互联网公司而言,业务众多,网络流量巨大,涉及的域名、服务器资源均属海量,在这个规模下的WAF的设计、研发、运营将会有比较多的现实挑战。

    如一般会面临以下几个主要问题:
    * 业务多且分散,如何降低业务接入成本,快速有效的推动业务覆盖;
    * 作为一个串联系统,如何保证最小程度影响业务性能,保证稳定性需求;
    * 每天需要处理几千亿请求,如何保证检测准确率,降低误报。

    # 后台架构设计要求
    WAF从架构逻辑上来看是串联进业务请求的处理流程中,这就直接对WAF的性能和稳定性提出的更高的要求,一旦本身出现故障将直接影响业务。在满足检测功能性需求,还需要满足后台架构海量服务的要求:

    1.稳定性:防护集群采用set化的服务和资源隔离设计,可对业务流量进行轻重分离,避免某些业务流量的突然暴涨影响其它业务的防护效果。

    2.性能:防护服务采用IO和检测分离的设计方式,并基于共享内存以零拷贝方式进行数据传递,同时,内部对检测引擎进行多方面的优化,基本保证99%的检测请求能在2ms以内返回检测结果。

    3.容灾:一旦后端某些处理server出现故障, 请求可自动切换连接可用的处理server。

    4.高可维护性
    在线部分逻辑足够简单、高效:在线模块与离线模块低耦合分离;维护高效:一键编译、一键运行、一键功能/性能测试、一键发布

    5.高可运营
    统一后台策略管理系统,发布变更便捷、规范、快速,可以实时验证。
    完善的系统监控&告警:门神处理server可用性监控以及异常告警,包括:恶意阻断、非恶意放过、cpu/内存资源监控;业务websrv超时监控和异常告警。

    6.可扩展
    模块化功能支持新增:例如增加CC模块加入到在线自动实时拦截等。

    在后台日志系统中,引入的ELK分布式日志处理分析系统,可以处理大量&多种数据格式(错误信息、监控、告警),统一化的数据分析处理平台、风险感知平台。分析结果直接展示,方便强大的报表功能,方便数据运营人员做数据分析。
    `

发表评论

电子邮件地址不会被公开。 必填项已用*标注