精华内容
下载资源
问答
  • 应用级防火墙WAF解析
    千次阅读
    2020-04-04 20:33:53

             ~~~~~~~~         因为想要面对一个新的开始,一个人必须有梦想、有希望、有对未来的憧憬。如果没有这些,就不叫新的开始,而叫逃亡。 ​​​​
                                                                                                    ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~                                                                                                 ————玛丽亚·杜埃尼亚斯

    前言

    传统的防火墙通常工作在OSI模型中的传输层或者网络层,用来有效的阻断一些数据包。而随着web应用功能的越发丰富,web服务器也因为其强大的计算能力,处理性能,蕴含较高的价值而成为主要的被攻击目标(应用层)。sql注入、网页篡改、网页挂马等安全事件频繁发生。时事造英雄,在传统防火墙无能为力的背景下,WAF强势来袭!

    WAF是什么

    waf被称为web应用级防火墙,是通过执行一系列针对http,https的安全策略,来专门对web应用提供保护的一款产品。它与传统的防火墙不同,WAF工作在应用层,因此对应用层防护具有先天的技术优势。基于对web应用业务和逻辑的深刻理解,WAF对来自web应用程序客户端的各类请求进行内容检测和验证,确保其安全性与合法性,对非法的请求予以实时阻断,从而对各类网站站点进行有效的防护。

    WAF的功能

    审计设备

    • 管理员登录后进行的操作行为
    • 对安全策略进行的添加、修改、删除等操作行为
    • 对管理角色进行增加、删除和属性修改等操作
    • 对其他安全功能配置参数的设置或更新等行为

    访问控制设备
    用来控制对web应用的访问,既包括主动安全模式也包括被动安全模式
    架构/网络设计工具
    当运行在反向代理模式,他们被用来分配职能,集中控制,虚拟基础结构等
    web应用加固工具
    增强被保护web应用的安全性,它不仅能够屏蔽web应用固有弱点,而且能够保护web应用编程错误导致的安全隐患。

    以上是WAF具备的功能,但并非所有WAF都同时具备这些功能。

    WAF的工作原理

    目前市面上大多数的WAF都是基于规则的WAF,即WAF对接收到的数据包进行正则匹配过滤,如果匹配到与现有知识库的攻击代码相同或类似,则认为这是个恶意代码并进行阻断。因此,知识库就显得尤为重要,需要每天及时的更新知识库。
    一般工作流程
    在这里插入图片描述

    1. 解析http请求:协议解析模块
    2. 知识库匹配:规则检测模块,根据知识库进行匹配
    3. 防御动作:return 403 或者跳转到自定义界面,或者不返回任何数据,或者拉黑IP
    4. 日志记录:将行为记录到日志中

    安全模式
    WAF可以采用白名单和黑名单两种安全模式,可以单用也可以两者相结合。
    白名单中所有不在表中的请求类型全部拒绝,而黑名单则只会拒绝表中的请求类型,其他放行。

    WAF的部署模式

    透明代理
    WAF代理了web客户端和服务端之间的会话,并对客户端和服务端都保持透明。从web客户端的角度看,web客户端仍然是直接访问的服务器,感觉不到WAF的存在。
    优点:对网络改动最小,通过WAF的硬件Bypass功能在设备出现故障或者掉电时可以不影响原有网络流量,只是WAF自身功能失效。
    缺点:网络的所有流量都经过WAF,对WAF的处理性能要求高。无法实现负载均衡
    反向代理
    反向代理模式是指将真实服务器的地址映射到反向代理服务器上,此时代理服务器就表现为一个真实的服务器。当代理服务器收到HTTP的请求报文后,将该请求转发给其对应的真实服务器。后台服务器接收到请求后将响应先发送给WAF设备,由WAF设备再将应答发送给客户端。
    优点:可以在WAF上做负载均衡。
    缺点:对网络进行改动、配置相对复杂。需要配置映射关系。
    路由代理
    它与网桥透明代理的唯一区别就是该代理工作在路由转发模式而非网桥模式,其它工作原理都一样。由于工作在路由(网关)模式因此需要为WAF的转发接口配置IP地址以及路由。
    优点:网络改动简单,可直接作为web服务器网关
    缺点:存在单点故障问题,不支持负载均衡

    WAF的测试

    针对WAF的实施需要进行一个严格的测试流程,这样我们才能知道WAF能够有效的防止哪些真实攻击,漏掉了哪些,同时也要知道哪些有效的访问也被拦截了。
    测试流程框架

    1. 测试在没有部署WAF的情况下web应用的表现
    2. 测试再WAF启用默认配置的情况下,攻击是否成功
    3. 修改WAF相关配置,看能否拦截上面的攻击

    WAF的局限

    通过以上分析可以发现,WAF的主要难点是对入侵的检测能力,尤其是对web服务入侵的检测,WAF最大的挑战是识别率的问题。对于已知的攻击方式,可以提高识别率,但是对于未知的攻击手段,WAF是检测不到的。

    更多相关内容
  • WAF原理

    2021-07-20 21:26:01
    一.WAF原理 WAF是Web应用防火墙(Web Application Firewall)的简称,对来自Web应用程序客户端的各类请求进行内容检测和验证,确保其安全性与合法性,对非法的请求予以实时阻断,为Web应用提供防护,也称作应用...

    一.WAF的原理
    WAF是Web应用防火墙(Web Application Firewall)的简称,对来自Web应用程序客户端的各类请求进行内容检测和验证,确保其安全性与合法性,对非法的请求予以实时阻断,为Web应用提供防护,也称作应用防火墙,是网络安全纵深防御体系里重要的一环。WAF属于检测型及纠正型防御控制措施。WAF分为硬件WAF、软件WAF(ModSecurity)和代码级WAF。

    WAF对请求的内容进行规则匹配、行为分析等识别出恶意行为,并执行相关动作,这些动作包括阻断、记录、告警等。

    WAF工作在web服务器之前,对基于HTTP协议的通信进行检测和识别。通俗的说,WAF类似于地铁站的安检,对于HTTP请求进行快速安全检查,通过解析HTTP数据,在不同的字段分别在特征、规则等维度进行判断,判断的结果作为是否拦截的依据从而决定是否放行。

    ############################################################

    waf测试

    文章来源:https://blog.csdn.net/coolgw2015/article/details/79715494

    背景:

              对于现在的互联网,网络攻击每天都在发生,很多攻击是在七层,也就是OSI七层模型中的应用层。因此,Web应用防火墙(Web Application Firewall,简称WAF)愈发显得重要

    SQL注入攻击(SQL Injection)

             简称注入攻击,是Web开发中最常见的一种安全漏洞。可以用它来从数据库获取敏感信息,或者利用数据库的特性执行添加用户,导出文件等一系列恶意操作,甚至有可能获取数据库乃至系统用户最高权限。

            如何预防SQL注入
           也许你会说攻击者要知道数据库结构的信息才能实施SQL注入攻击。确实如此,但没人能保证攻击者一定拿不到这些信息,一旦他们拿到了,数据库就存在泄露的危险。如果你在用开放源代码的软件包来访问数据库,比如论坛程序,攻击者就很容易得到相关的代码。如果这些代码设计不良的话,风险就更大了。目前Discuz、phpwind、phpcms等这些流行的开源程序都有被SQL注入攻击的先例。
            这些攻击总是发生在安全性不高的代码上。所以,永远不要信任外界输入的数据,特别是来自于用户的数据,包括选择框、表单隐藏域和 cookie。就如上面的第一个例子那样,就算是正常的查询也有可能造成灾难。
            SQL注入攻击的危害这么大,那么该如何来防治呢?下面这些建议或许对防治SQL注入有一定的帮助。
             1、严格限制Web应用的数据库的操作权限,给此用户提供仅仅能够满足其工作的最低权限,从而最大限度的减少注入攻击对数据库的危害。
             2、检查输入的数据是否具有所期望的数据格式,严格限制变量的类型,例如使用regexp包进行一些匹配处理,或者使用strconv包对字符串转化成其他基本类型的数据进行判断。
             3、对进入数据库的特殊字符('"\尖括号&*;等)进行转义处理,或编码转换。Go 的text/template包里面的HTMLEscapeString函数可以对字符串进行转义处理。
             4、所有的查询语句建议使用数据库提供的参数化查询接口,参数化的语句使用参数而不是将用户输入变量嵌入到SQL语句中,即不要直接拼接SQL语句。例如使用database/sql里面的查询函数Prepare和Query,或者Exec(query string, args ...interface{})。
             5、在应用发布之前建议使用专业的SQL注入检测工具进行检测,以及时修补被发现的SQL注入漏洞。网上有很多这方面的开源工具,例如sqlmap、SQLninja等。
    避免网站打印出SQL错误信息,比如类型错误、字段不匹配等,把代码里的SQL语句暴露出来,以防止攻击者利用这些错误信息进行SQL注入。

        XSS攻击

             XSS又称CSS,全称Cross SiteScript,跨站脚本攻击,是Web程序中常见的漏洞,XSS属于被动式且用于客户端的攻击方式,所以容易被忽略其危害性。其原理是攻击者向有XSS漏洞的网站中输入(传入)恶意的HTML代码,当其它用户浏览该网站时,这段HTML代码会自动执行,从而达到攻击的目的。如,盗取用户Cookie、破坏页面结构、重定向到其它网站等。

             防御:完善的过滤体系
             永远不相信用户的输入。需要对用户的输入进行处理,只允许输入合法的值,其它值一概过滤掉。

              点击打开链接http://blog.csdn.net/ghsau/article/details/17027893

        CSRF攻击

              CSRF 的全称是“跨站请求伪造”,而 XSS 的全称是“跨站脚本”。看起来有点相似,它们都是属于跨站攻击——不攻击服务器端而攻击正常访问网站的用户,但前面说了,它们的攻击类型是不同维度上的分类。CSRF 顾名思义,是伪造请求,冒充用户在站内的正常操作。我们知道,绝大多数网站是通过 cookie 等方式辨识用户身份(包括使用服务器端 Session 的网站,因为 Session ID 也是大多保存在 cookie 里面的),再予以授权的。所以要伪造用户的正常操作,最好的方法是通过 XSS 或链接欺骗等途径,让用户在本机(即拥有身份 cookie 的浏览器端)发起用户所不知道的请求。
       严格意义上来说,CSRF 不能分类为注入攻击,因为 CSRF 的实现途径远远不止 XSS 注入这一条。通过 XSS 来实现 CSRF 易如反掌,但对于设计不佳的网站,一条正常的链接都能造成 CSRF。

     http://www.cnblogs.com/hyddd/archive/2009/04/09/1432744.html?login=1

    恶意爬虫

        网络爬虫(Web Crawler),又称网络蜘蛛(Web Spider)或网络机器人(Web Robot),是一种按照一定的规则自动抓取万维网资源的程序或者脚本,已被广泛应用于互联网领域。搜索引擎使用网络爬虫抓取Web网页、文档甚至图片、音频、视频等资源,通过相应的索引技术组织这些信息,提供给搜索用户进行查询。随着网络的迅速发展,万维网成为大量信息的载体,如何有效地提取并利用这些信息成为一个巨大的挑战。不断优化的网络爬虫技术正在有效地应对这种挑战,为高效搜索用户关注的特定领域与主题提供了有力支撑。网络爬虫也为中小站点的推广提供了有效的途径,网站针对搜索引擎爬虫的优化曾风靡一时。
        传统网络爬虫从一个或若干个初始网页的URL(Universal Resource Locator统一资源定位符)开始,获得初始网页上的URL,在抓取网页的过程中,不断从当前页面上抽取新的URL放入队列,直到满足系统的一定条件停止抓取。现阶段网络爬虫已发展为涵盖网页数据抽取、机器学习、数据挖掘、语义理解等多种方法综合应用的智能工具。

    网络爬虫的安全性问题
    1)搜索目录列表
    2)搜索测试页面、手册文档、样本程序及可能存在的缺陷程序
    3)搜索管理员登录页面
    4)搜索互联网用户的个人资料

    点击打开链接http://www.h3c.com.cn/About_H3C/Company_Publication/IP_Lh/2012/02/Home/Catalog/201204/741991_30008_0.htm

    点击打开链接http://www.jianshu.com/p/a61f6f78f3b6

    扫描器

       扫描器是一类自动检测本地或远程主机安全弱点的程序,它能够快速的准确的发现扫描目标存在的漏洞并提供给使用者扫描结果。工作原理是扫描器向目标计算机发送数据包,然后根据对方反馈的信息来判断对方的操作系统类型、开发端口、提供的服务等敏感信息。

       扫描是攻击的前奏,通过扫描,搜集目标主机的相关信息,以期寻找主机的漏洞。常见的扫描工具有X-scan、superscan、流光、X-port等。

    远程文件包含

       远程文件包含攻击Remote File Include,它也属于是“代码注入”的一种,其原理就是注入一段用户能控制的脚本或代码,并让服务端执行。
    文件包含漏洞可能出现在JSP、PHP、ASP等语言中,原理都是一样的

     点击打开链接 http://yttitan.blog.51cto.com/70821/1574385

    DDoS攻击与CC攻击的区别

    什么是CC攻击?
    1.CC攻击来的IP都是真实的,分散的;
    2.CC攻击的数据包都是正常的数据包;
    3.CC攻击的请求,全都是有效的请求,无法拒绝的请求;
    4.因为cc攻击的是网页,服务器什么都可以连接,ping也没问题,但是网页就是访问不了;
    5.但是iis一开服务器一会就死,而且被攻击后就老丢包。不知道是不是cc攻击,syn 攻击频率才78ack攻击频率663.

    两者区别:

    DDoS是针对IP的攻击,而CC攻击的是网页。
    防范措施:
       目前网络安全界对于DDoS的防范还是没有什么好办法的,主要靠平时维护和扫描来对抗。简单的通过软件防范的效果非常不明显,在所有的防御措施中硬件安防设施(硬件防火墙)是最有效的,但是硬件防火墙也不是说能杜绝一切攻击,也仅仅能起到降低攻击级别的效果,DDoS攻击只能被减弱,无法被彻底消除。
       CC不像DDoS可以用硬件防火墙来过滤攻击,CC攻击本身的请求就是正常的请求,硬件防火墙对他起不到很好的防御效果。如果容易被CC攻击,建议提前安装软防。

    一、    Web防护

    1.1   网络层防护

    1)DDOS攻击

    2)Syn Flood

    3)Ack Flood

    4)Http/HttpS Flood(CC攻击)

    5)慢速攻击

    1.2   应用层防护和功能

    1)URL黑白名单

    2)HTTP协议规范(包括特殊字符过滤、请求方式、内容传输方式,例如:multipart/form-data,text/xml,application/x-www-form-urlencoded)

    3)注入攻击(form和URL参数,post和get)

    l  SQL注入防御

    l  LDAP注入防御

    l  命令注入防护(OS命令,webshell等)

    l  XPath注入

    l  Xml/Json注入

    4)XSS攻击(form和URL参数,post和get,现阶段分为三类攻击:存储式(危害大,也是一种流行方式),反射式、基于Dom的XSS)

    5)目录遍历(Path Traversal)

    6) form表单数据验证和表单篡改和注入(表单验证银行卡、数据、日期等)

    7)认证管理和会话劫持(cookie加密:防护会话劫持,包括cookie超时)。

    8)内容过滤(这儿强调上传内容过滤post form和get 参数,主要应用论坛)

    9)Web服务器漏洞探测(apache版本等隐藏,站点隐藏)

    10)爬虫防护(基于SRC IP,周期判断访问数,爬虫白名单除外)

    11)CSRF(Cross-site request forgery)(WAF采用token方式处理能够解决)

    12)篡改(包括盗链)(WAF周期爬服务器网页,进行对比验证,如果篡改发现篡改,Client访问WAF网页)

    13)Web服务器漏洞扫描(模拟攻击,判断缺陷,自动配置对应规则)

    14)cache加速(静态页面优化,PDF,图片等,需要周期映像)

    16)错误码过滤(探测服务,及其目录结构)

    17)站点转换(URL rewrite)

    18)发现攻击锁定(发现攻击,锁定用户)

    19)查杀毒

    20)加密传输(http -> https转化,即client-waf之间通过https,waf与server之间http)。

    21)URL ACL(URL匹配一些规则)。

     

    展开全文
  • waf应用防火墙详解

    万次阅读 2019-06-24 14:26:49
    还是直接加防火墙吗?这些都是防御手段。不过本文将要介绍的是直接通过nginx的普通模块和配置文件的组合来达到一定的防御效果。 0x01 验证浏览器行为 简易版 我们先来做个比喻。 社区在搞福利,在广场...

    通过nginx配置文件抵御攻击
     

    0x00 前言


    Nginx是一款轻量级Web 服务器/反向代理服务器及电子邮件(IMAP/POP3)代理服务器,在BSD-like 协议下发行。其特点是占有内存少,并发能力强,事实上nginx的并发能力确实在同类型的网页服务器中表现较好,中国大陆使用nginx网站用户有:百度、京东新浪、网易、腾讯淘宝等。

    大家好,我们是OpenCDN团队的Twwy。这次我们来讲讲如何通过简单的配置文件来实现nginx防御攻击的效果。

    其实很多时候,各种防攻击的思路我们都明白,比如限制IP啊,过滤攻击字符串啊,识别攻击指纹啦。可是要如何去实现它呢?用守护脚本吗?用PHP在外面包一层过滤?还是直接加防火墙吗?这些都是防御手段。不过本文将要介绍的是直接通过nginx的普通模块和配置文件的组合来达到一定的防御效果。

    0x01 验证浏览器行为


    简易版

    我们先来做个比喻。

    社区在搞福利,在广场上给大家派发红包。而坏人派了一批人形的机器人(没有语言模块)来冒领红包,聪明工作人员需要想出办法来防止红包被冒领。

    于是工作人员在发红包之前,会给领取者一张纸,上面写着“红包拿来”,如果那人能念出纸上的字,那么就是人,给红包,如果你不能念出来,那么请自觉。于是机器人便被识破,灰溜溜地回来了。

    是的,在这个比喻中,人就是浏览器,机器人就是攻击器,我们可以通过鉴别cookie功能(念纸上的字)的方式来鉴别他们。下面就是nginx的配置文件写法。

    1

    2

    3

    4

    if ($cookie_say != "hbnl"){

        add_header Set-Cookie "say=hbnl";

        rewrite .* "$scheme://$host$uri" redirect;

    }

    让我们看下这几行的意思,当cookie中say为空时,给一个设置cookie say为hbnl的302重定向包,如果访问者能够在第二个包中携带上cookie值,那么就能正常访问网站了,如果不能的话,那他永远活在了302中。你也可以测试一下,用CC攻击器或者webbench或者直接curl发包做测试,他们都活在了302世界中。

    当然,这么简单就能防住了?当然没有那么简单。

    增强版

    仔细的你一定会发现配置文件这样写还是有缺陷。如果攻击者设置cookie为say=hbnl(CC攻击器上就可以这么设置),那么这个防御就形同虚设了。我们继续拿刚刚那个比喻来说明问题。

    坏人发现这个规律后,给每个机器人安上了扬声器,一直重复着“红包拿来,红包拿来”,浩浩荡荡地又来领红包了。

    这时,工作人员的对策是这样做的,要求领取者出示有自己名字的户口本,并且念出自己的名字,“我是xxx,红包拿来”。于是一群只会嗡嗡叫着“红包拿来”的机器人又被撵回去了。

    当然,为了配合说明问题,每个机器人是有户口本的,被赶回去的原因是不会念自己的名字,虽然这个有点荒诞,唉。

    然后,我们来看下这种方式的配置文件写法

    1

    2

    3

    4

    if ($cookie_say != "hbnl$remote_addr"){

        add_header Set-Cookie "say=hbnl$remote_addr";

        rewrite .* "$scheme://$host$uri" redirect;

    }

    这样的写法和前面的区别是,不同IP的请求cookie值是不一样的,比如IP是1.2.3.4,那么需要设置的cookie是say=hbnl1.2.3.4。于是攻击者便无法通过设置一样的cookie(比如CC攻击器)来绕过这种限制。你可以继续用CC攻击器来测试下,你会发现CC攻击器打出的流量已经全部进入302世界中。

    不过大家也能感觉到,这似乎也不是一个万全之计,因为攻击者如果研究了网站的机制之后,总有办法测出并预先伪造cookie值的设置方法。因为我们做差异化的数据源正是他们本身的一些信息(IP、user agent等)。攻击者花点时间也是可以做出专门针对网站的攻击脚本的。

    完美版

    那么要如何根据他们自身的信息得出他们又得出他们算不出的数值?

    我想,聪明的你一定已经猜到了,用salt加散列。比如md5("opencdn$remote_addr"),虽然攻击者知道可以自己IP,但是他无法得知如何用他的IP来计算出这个散列,因为他是逆不出这个散列的。当然,如果你不放心的话,怕cmd5.com万一能查出来的话,可以加一些特殊字符,然后多散几次。

    很可惜,nginx默认是无法进行字符串散列的,于是我们借助nginx_lua模块来进行实现。

    1

    2

    3

    4

    5

    6

    7

    rewrite_by_lua '

        local say = ngx.md5("opencdn" .. ngx.var.remote_addr)

        if (ngx.var.cookie_say ~= say) then

            ngx.header["Set-Cookie"] = "say=" .. say

            return ngx.redirect(ngx.var.scheme .. "://" .. ngx.var.host .. ngx.var.uri)

        end

    ';

    通过这样的配置,攻击者便无法事先计算这个cookie中的say值,于是攻击流量(代理型CC和低级发包型CC)便在302地狱无法自拔了。

    大家可以看到,除了借用了md5这个函数外,其他的逻辑和上面的写法是一模一样的。因此如果可以的话,你完全可以安装一个nginx的计算散列的第三方模块来完成,可能效率会更高一些。

    这段配置是可以被放在任意的location里面,如果你的网站有对外提供API功能的话,建议API一定不能加入这段,因为API的调用也是没有浏览器行为的,会被当做攻击流量处理。并且,有些弱一点爬虫也会陷在302之中,这个需要注意。

    同时,如果你觉得set-cookie这个动作似乎攻击者也有可能通过解析字符串模拟出来的话,你可以把上述的通过header来设置cookie的操作,变成通过高端大气的js完成,发回一个含有doument.cookie=...的文本即可。

    那么,攻击是不是完全被挡住了呢?只能说那些低级的攻击已经被挡住而来,如果攻击者必须花很大代价给每个攻击器加上webkit模块来解析js和执行set-cookie才行,那么他也是可以逃脱302地狱的,在nginx看来,确实攻击流量和普通浏览流量是一样的。那么如何防御呢?下节会告诉你答案。

    0x02 请求频率限制


    不得不说,很多防CC的措施是直接在请求频率上做限制来实现的,但是,很多都存在着一定的问题。

    那么是哪些问题呢?

    首先,如果通过IP来限制请求频率,容易导致一些误杀,比如我一个地方出口IP就那么几个,而访问者一多的话,请求频率很容易到上限,那么那个地方的用户就都访问不了你的网站了。

    于是你会说,我用SESSION来限制就有这个问题了。嗯,你的SESSION为攻击者敞开了一道大门。为什么呢?看了上文的你可能已经大致知道了,因为就像那个“红包拿来”的扬声器一样,很多语言或者框架中的SESSION是能够伪造的。以PHP为例,你可以在浏览器中的cookie看到PHPSESSIONID,这个ID不同的话,session也就不同了,然后如果你杜撰一个PHPSESSIONID过去的话,你会发现,服务器也认可了这个ID,为这个ID初始化了一个会话。那么,攻击者只需要每次发完包就构造一个新的SESSIONID就可以很轻松地躲过这种在session上的请求次数限制。

    那么我们要如何来做这个请求频率的限制呢?

    首先,我们先要一个攻击者无法杜撰的sessionID,一种方式是用个池子记录下每次给出的ID,然后在请求来的时候进行查询,如果没有的话,就拒绝请求。这种方式我们不推荐,首先一个网站已经有了session池,这样再做个无疑有些浪费,而且还需要进行池中的遍历比较查询,太消耗性能。我们希望的是一种可以无状态性的sessionID,可以吗?可以的。

    1

    2

    3

    4

    5

    6

    7

    8

    9

    10

    11

    12

    13

    14

    15

    rewrite_by_lua '

     

        local random = ngx.var.cookie_random

     

        if(random == nil) then

            random = math.random(999999)

        end

     

        local token = ngx.md5("opencdn" .. ngx.var.remote_addr .. random)

        if (ngx.var.cookie_token ~= token) then

            ngx.header["Set-Cookie"] = {"token=" .. token, "random=" .. random}

            return ngx.redirect(ngx.var.scheme .. "://" .. ngx.var.host .. ngx.var.uri)

        end

     

    ';

    大家是不是觉得好像有些眼熟?是的,这个就是上节的完美版的配置再加个随机数,为的是让同一个IP的用户也能有不同的token。同样的,只要有nginx的第三方模块提供散列和随机数功能,这个配置也可以不用lua直接用纯配置文件完成。

    有了这个token之后,相当于每个访客有一个无法伪造的并且独一无二的token,这种情况下,进行请求限制才有意义。

    由于有了token做铺垫,我们可以不做什么白名单、黑名单,直接通过limit模块来完成。

    1

    2

    3

    4

    http{

        ...

        limit_req_zone $cookie_token zone=session_limit:3m rate=1r/s;

    }

    然后我们只需要在上面的token配置后面中加入

    1

    limit_req zone=session_limit burst=5;

    于是,又是两行配置便让nginx在session层解决了请求频率的限制。不过似乎还是有缺陷,因为攻击者可以通过一直获取token来突破请求频率限制,如果能限制一个IP获取token的频率就更完美了。可以做到吗?可以。

    1

    2

    3

    4

    5

    http{

        ...

        limit_req_zone $cookie_token zone=session_limit:3m rate=1r/s;

        limit_req_zone $binary_remote_addr $uri zone=auth_limit:3m rate=1r/m;

    }

     

    1

    2

    3

    4

    5

    6

    7

    8

    9

    10

    11

    12

    13

    14

    15

    16

    17

    18

    19

    20

    21

    22

    23

    24

    25

    26

    27

    28

    29

    30

    31

    32

    33

    location /{

     

        limit_req zone=session_limit burst=5;

     

        rewrite_by_lua '

            local random = ngx.var.cookie_random

            if (random == nil) then

                return ngx.redirect("/auth?url=" .. ngx.var.request_uri)

            end

            local token = ngx.md5("opencdn" .. ngx.var.remote_addr .. random)

            if (ngx.var.cookie_token ~= token) then

                return ngx.redirect("/auth?url=".. ngx.var.request_uri)

            end

        ';

     

    }

     

    location /auth {

            limit_req zone=auth_limit burst=1;

     

            if ($arg_url = "") {

                return 403;

            }

     

            access_by_lua '

                local random = math.random(9999)

                local token = ngx.md5("opencdn" .. ngx.var.remote_addr .. random)

                if (ngx.var.cookie_token ~= token) then

                    ngx.header["Set-Cookie"] = {"token=" .. token, "random=" .. random}

                    return ngx.redirect(ngx.var.arg_url)

                end

            ';

    }

    我想大家也应该已经猜到,这段配置文件的原理就是:把本来的发token的功能分离到一个auth页面,然后用limit对这个auth页面进行频率限制即可。这边的频率是1个IP每分钟授权1个token。当然,这个数量可以根据业务需要进行调整。

    需要注意的是,这个auth部分我lua采用的是access_by_lua,原因在于limit模块是在rewrite阶段后执行的,如果在rewrite阶段302的话,limit将会失效。因此,这段lua配置我不能保证可以用原生的配置文件实现,因为不知道如何用配置文件在rewrite阶段后进行302跳转,也求大牛能够指点一下啊。

    当然,你如果还不满足于这种限制的话,想要做到某个IP如果一天到达上限超过几次之后就直接封IP的话,也是可以的,你可以用类似的思路再做个错误页面,然后到达上限之后不返回503而是跳转到那个错误页面,然后错误页面也做个请求次数限制,比如每天只能访问100次,那么当超过报错超过100次(请求错误页面100次)之后,那天这个IP就不能再访问这个网站了。

    于是,通过这些配置我们便实现了一个网站访问频率限制。不过,这样的配置也不是说可以完全防止了攻击,只能说让攻击者的成本变高,让网站的扛攻击能力变强,当然,前提是nginx能够扛得住这些流量,然后带宽不被堵死。如果你家门被堵了,你还想开门营业,那真心没有办法了。

    然后,做完流量上的防护,让我们来看看对于扫描器之类的攻击的防御。

    0x03 防扫描


    ngx_lua_waf模块

    这个是一个不错的waf模块,这块我们也就不再重复造轮子了。可以直接用这个模块来做防护,当然也完全可以再配合limit模块,用上文的思路来做到一个封IP或者封session的效果。

    0x04 总结


    本文旨在达到抛砖引玉的作用,我们并不希望你直接单纯的复制我们的这些例子中的配置,而是希望根据你的自身业务需要,写出适合自身站点的配置文件。

     

     

    文章来源:http://drops.wooyun.org/tips/734


     

     

     

    如何打造一款可靠的WAF(Web应用防火墙)


     

     

     

    之前写了一篇《WAF防御能力评测及工具》,是站在安全运维人员选型WAF产品的角度来考虑的(优先从测试角度考虑是前职业病,毕竟当过3年游戏测试?!)。本篇文章从WAF产品研发的角度来YY如何实现一款可靠的WAF,灵感来自ModSecurity等,感谢开源。

    本片文章包括三个主题

     
    1. (1) WAF实现

    2. WAF包括哪些组件,这些组件如何交互来实现WAF防御功能

    3. (2)WAF规则(策略)维护

    4. 规则(策略)如何维护,包括获取渠道,规则测试方法以及上线效果评测

    5. (3) WAF支撑

    6. WAF产品的完善需要哪些信息库的支撑

    一、WAF实现

    WAF一句话描述,就是解析HTTP请求(协议解析模块),规则检测(规则模块),做不同的防御动作(动作模块),并将防御过程(日志模块)记录下来。不管硬件款,软件款,云款,核心都是这个,而接下来围绕这句话来YY WAF的实现。WAF的实现由五个模块(配置模块、协议解析模块、规则模块、动作模块、错误处理模块)组成

    1. 配置模块

    设置WAF的检测粒度,按需开启,如图所示

    WAF的实现 - 碳基体 - 碳基体

    2. 协议解析模块(重点)

    协议解析的输出就是下一个模块规则检测时的操作对象,解析的粒度直接影响WAF防御效果。对于将WAF模块寄生于web 服务器的云WAF模式,一般依赖于web 服务器的解析能力。

    WAF的实现 - 碳基体 - 碳基体

    3. 规则模块(重点)

    重点来了,这块是WAF的核心,我将这块又细分为三个子模块。

    (1) 规则配置模块

    IP黑白名单配置、 URL黑白名单配置、以及挑选合适的规则套餐。

    WAF的实现 - 碳基体 - 碳基体

    (2)规则解析模块

    主要作用是解析具体的规则文件,规则最好采用统一的规则描述语言,便于提供给第三方定制规则,ModSecurity这方面做得非常优秀。

    规则文件由四部分组成,分为变量部分、操作符部分,事务函数部分与动作部分。

    WAF的实现 - 碳基体 - 碳基体

    WAF的实现 - 碳基体 - 碳基体

    (3)规则检测模块

    上一步我们设置了各种变量,接下来就是按照一定的逻辑来做加减乘除了。

    WAF的实现 - 碳基体 - 碳基体

    4. 动作模块(重点)

    通过规则检测模块,我们识别了请求的好恶,接下来就是做出响应,量刑处理,不仅仅是拦截。

    WAF的实现 - 碳基体 - 碳基体

    5. 日志模块(重点)

    日志处理,非常重要,也非常火热,内容丰富到完全可以从WAF独立出来形成单独的安全产品(e.g.日志宝)而采用提供接口的方式来支撑WAF。对于数据量巨大的云WAF,都会有单独的大数据团队来支撑架构这一块,包括数据存储(e.g. hdfs) ,数据传输(kafka),数据离线分析(hadoop/spark),数据实时分析(storm),数据关联分析(elasticsearch)等等,以后另开一篇单独说明。

    WAF的实现 - 碳基体 - 碳基体

    6. 错误处理模块

    以上模块运行错误时的异常处理

    二、WAF规则(策略)维护

    WAF需要修炼一图以蔽之

    WAF的实现 - 碳基体 - 碳基体

    三、WAF支撑信息库

    WAF需要修炼一图以蔽之

    WAF的实现 - 碳基体 - 碳基体

    以上支撑库几乎所有的安全人员都在重复地做,而资源没有共享的原因,一是内部不可说;二是没有采取统一的描述语言无法汇合,唉,安全从业人员的巴别塔。

    四、补充知识(包括文章与代码)

    想想写了这么多文章,自我感觉萌萌哒!

    WAF相关

     

    WAF防御能力评测及工具

    ssdeep检测webshell

    ModSecurity相关文章(我就是ModSecurity的死忠粉)

    [科普文]ubuntu上安装Apache2+ModSecurity及自定义WAF规则

    ModSecurity SecRule cheatsheets

    ModSecurity CRS 笔记、WAF防御checklist,及WAF架构的一些想法

    ModSecurity 晋级-如何调用lua脚本进行防御快速入门

    ModSecurity 白名单设置

    指纹识别

     

    Web应用指纹识别

    FingerPrint

    IP相关

     

    使用免费的本地IP地理库来定位IP地理位置-GeoIP lookup

    获得IP的地理位置信IP Geolocation及IP位置可视化

    IP地理信息离线获取脚本

    IP地理信息在线获取脚本

    识别搜索引擎脚本

    判断使用哪家CDN脚本

    代理类型判断脚本 Proxy探测脚本与HTTP基本认证暴力破解脚本

    CDN架构

     

    网站负载均衡技术读书笔记与站长产品的一点想法

    正则优化

     

    NFA引擎正则优化TIPS、Perl正则技巧及正则性能评测方法

    HTTP发包工具

     

    HTTP.pl——通过HTTP发包工具了解HTTP协议

    HTTP发包工具 -HTTPie

    WAF实现的思维导图

    参考:

    ModSecurity  Handbook

    第八、九、十,十一我是反复看,每次都有新的灵感,第14、15章是当成新华字典看的,以免遗忘。

    Web Application Defenders Cookbook Battling Hackers and Protecting Users》 (红宝书,还在看)

     

     

    来源:http://www.freebuf.com/sectool/54221.html

     

     

     

     

     

     

     

    基于ngx_lua模块的waf开发实践

     

     

     

    zhangsan · 2015/03/06 9:15

     

    0x00 常见WAF简单分析


    WAF主要分为硬件WAF和软件防火墙,硬件WAF如绿盟的NSFOCUS Web Application Firewall,软件防火墙比较有名的是ModSecurity,再就是代码级别的ngx_lua_waf。下面谈谈个人对几款防火墙的理解:

    硬件WAF个人觉得只适合在那种访问量较少的网站,比如政府网站,公司的介绍网站等等。硬件WAF的的优势在于规则有专门的安全公司维护,管理方便,但也存在一个致命的弱点,使用传统的方式来解包到应用层对性能的需求较高,而且当访问量很大的时候延时比较大,这样在高并发访问的情况下要使用硬件WAF就只能使用很多台WAF了,这样成本就非常高了;还有一个在接触过程中发现的问题,就是硬件WAF的规则虽然多而且有人维护,但是一般公司很难敢直接开启阻难,很多都是只记录,并不能阻难,这样WAF的意义就变得小多了。

    ModSecurity在网上的评价都是很高的,性能高,规则全。最开始我研究的也是这款WAF,但是在实际使用过程中发现问题,就是在高并发的情况下,运行一段时间,会出现内存飙升,而且不下来的问题。这个问题再ModSecurity的讨论论坛上面也发现了有人提出这样的问题,但一直未解决(https://github.com/SpiderLabs/ModSecurity/issues/785)。针对于规则全的优势,一般使用者也不敢直接开启所有的规则拦截,毕竟每个公司的业务不同,规则也不可能直接套用。

    基于高性能,低成本的想法,发现了@loveshell开发的ngx_lua_waf,经过实际使用下来,确实性能极好,由于LUA语言的性能是接近于C的,而且ngx_lua_module本身就是基于为nginx开发的高性能的模块。安全宝的云 WAF,以及cloudflare的新waf也是基于此模块使用LUA开发的。结合ModSecurity的思路,参考@loveshell的ngx_lua_waf来开发适合自己用的WAF,其中使用了很多@loveshell的函数,再此也表示感谢。

    0x01 WAF框架设计


    WAF开发过程中的主要方向为:

    • 主引擎的开发,主要关注主引擎的性能和容错能力
    • 规则的开发,主要关注规则的全面可靠,防勿拦截以及防绕过
    • 整体方案能够适应多站点,高可用性的环境

    WAF的主要功能为:

    • ip黑白名单
    • url黑白名单
    • useragent黑白名单
    • referer黑白名单
    • 常见web漏洞防护,如xss,sql注入等
    • cc攻击防护
    • 扫描器简单防护
    • 其他你想要的功能

    WAF的总体检测思路:

    • 当用户访问到nginx时,waf首先获取用户的ip,uri,referer,useragent,,cookie,args,post,method,header信息。
    • 将获取到的信息依次传给上述功能的函数,如ip规则,在ip规则中,循环到所有的ip规则,如果匹配到ip则根据规则的处理方式来进行处理,匹配到之后不继续匹配后续规则。
    • 需要开启的功能依次在主函数中调用即可,顺序也可根据实际场景来确定最合适的顺序。

    图示如下:

    enter image description here

    0x02 规则格式分析


    规则说明:

    比如规则:{"rule00001","rules","args|post|cookie",[[../]],"deny","logon"},

    rule00001:规则编号,随意写

    rules:规则名称,如xssrules,随意写

    args|post|cookie|header:检测位置,|表示或,args,post,cookie,header可多选

    ../:匹配的正则表达式,标准PCRE正则

    deny:处理方式,可选deny ,allow

    logon:日志记录与否,可选logon,logoff

    0x03 cc攻击防护代码示例


    1

    2

    3

    4

    5

    6

    7

    8

    9

    10

    11

    12

    13

    14

    15

    16

    17

    18

    19

    20

    21

    22

    23

    24

    25

    26

    27

    28

    29

    30

    31

    32

    33

    34

    35

    36

    37

    38

    39

    40

    41

    42

    43

    44

    45

    46

    47

    48

    49

    50

    51

    52

    53

    54

    55

    --在nginx.conf的HTTP中加入

    --lua_shared_dict limit 50m; 根据主机内存调合适的值

    --lua_shared_dict iplimit 20m;

    --lua_shared_dict blockiplimit 5m;

    -------------------------------------------------------------

    CCDeny="on"   --cc攻击开关

    CCrate="60/60"--基于url的计数 次/秒

    ipCCrate="600/60"--基于ip的计数 次/秒

    -------------------------------------------------

    ccdenyrules={"ccdeny1","ccdeny","","","","logon"}

    function gethost()

        host = ngx.var.host

        if host == nil or type(host) ~= "string" then

            math.randomseed(os.time())

            host = "nohost"..math.random()

        end

        return host

    end

     

    function denycc(clientdata)

        if CCDeny=="on" then

            local uri=clientdata[2]

            local host = gethost()

            CCcount=tonumber(string.match(CCrate,'(.*)/'))

            CCseconds=tonumber(string.match(CCrate,'/(.*)'))

            ipCCcount=tonumber(string.match(ipCCrate,'(.*)/'))

            ipCCseconds=tonumber(string.match(ipCCrate,'/(.*)'))

            local token = clientdata[1]..host..uri

            local clientip = clientdata[1]..host

            local limit = ngx.shared.limit

            local iplimit = ngx.shared.iplimit

            local blockiplimit = ngx.shared.blockiplimit

            local req,_=limit:get(token)

            local ipreq,_=iplimit:get(clientip)

            local blockipreq,_=blockiplimit:get(clientip)

            if blockipreq or ipreq then

                if blockipreq or req then

                    if blockipreq or req >= CCcount or ipreq >= ipCCcount  then

                        log(ccdenyrules,clientdata)

                        blockiplimit:set(clientip,1,300)

                        ngx.exit(403)

                        return true

                    else

                        limit:incr(token,1)

                        iplimit:incr(clientip,1)

                    end

                else

                    limit:set(token,1,CCseconds)

                end

            else

                iplimit:set(clientip,1,ipCCseconds)

            end

        end

        return false

    end

    0x04 优势举例


    可以很灵活的实现复杂的控制

    比如我在我的个人网站上面就使用了这样一个功能,后台页面需要特定useragent才能访问。

    代码如下:

    1

    2

    3

    4

    5

    6

    7

    8

    9

    10

    11

    12

    13

    --特定页面容许特定useragent可访问

    function houtai(clientdata)

        if stringmatch(clientdata[2],"wp-admin") then

            if stringmatch(clientdata[4],"hahahaha") then

                return

            else

                ngx.exit(403)

                return

            end

        else

            return

        end

    end

    可以测试http://www.zhangsan.me/wp-admin/

    只有在特定的useragent才可以访问此页面,否则报403错误。

    0x05 源码下载及使用


    源码下载地址为:http://pan.baidu.com/s/18QQya

    环境搭建就参考:http://wiki.nginx.org/HttpLuaModule#Installation

    waf使用主要就是配置config.lua

    SecRuleEngine = "on" attacklog = "on" logpath = "/home/waflog/"

    分别为引擎是否开启 是否记录日志 日志的存储路径 日志的存储路径需要给予nginx运行用户的读写权限

    0x06 后续研究方向


    • 1.根据ModSecurity规则提取一份较适应自己用的规则
    • 2.根据最新出现的漏洞维护规则
    • 3.在多个站点的情况下,如果在站点变动,规则变动的时候,不影响其他站点,实现高可用性。

    写的很简单,大牛勿喷,希望大家多提建议。

    0x07 参考资料


    1. https://github.com/loveshell/ngx_lua_waf
    2. http://wiki.nginx.org/HttpLuaModule
    3. http://www.freebuf.com/tools/54221.html
    ……

     

     

    文章来源:http://drops.wooyun.org/tips/5136

     

     

     

     

     

     

     

     

     

    ngx_lua_waf - 一个基于 lua-nginx-module 的 Web 应用防火墙

     

     

     

     

    ngx_lua_waf

     

    ngx_lua_waf是我刚入职趣游时候开发的一个基于ngx_lua的web应用防火墙。

    代码很简单,开发初衷主要是使用简单,高性能和轻量级。

    现在开源出来,遵从MIT许可协议。其中包含我们的过滤规则。如果大家有什么建议和想fa,欢迎和我一起完善。

    用途:

     
    1. 防止sql注入,本地包含,部分溢出,fuzzing测试,xss,SSRF等web攻击

    2. 防止svn/备份之类文件泄漏

    3. 防止ApacheBench之类压力测试工具的攻击

    4. 屏蔽常见的扫描黑客工具,扫描器

    5. 屏蔽异常的网络请求

    6. 屏蔽图片附件类目录php执行权限

    7. 防止webshell上传

    推荐安装:

    推荐使用lujit2.1做lua支持

    ngx_lua如果是0.9.2以上版本,建议正则过滤函数改为ngx.re.find,匹配效率会提高三倍左右。

    使用说明:

    nginx安装路径假设为:/usr/local/nginx/conf/

    把ngx_lua_waf下载到conf目录下,解压命名为waf

    在nginx.conf的http段添加

     
    1. lua_package_path "/usr/local/nginx/conf/waf/?.lua";

    2. lua_shared_dict limit 10m;

    3. init_by_lua_file /usr/local/nginx/conf/waf/init.lua;

    4. access_by_lua_file /usr/local/nginx/conf/waf/waf.lua;

    配置config.lua里的waf规则目录(一般在waf/conf/目录下)

        RulePath = "/usr/local/nginx/conf/waf/wafconf/"
    

    绝对路径如有变动,需对应修改

    然后重启nginx即可

    配置文件详细说明:

     
    1. RulePath = "/usr/local/nginx/conf/waf/wafconf/"

    2. --规则存放目录

    3. attacklog = "off"

    4. --是否开启攻击信息记录,需要配置logdir

    5. logdir = "/usr/local/nginx/logs/hack/"

    6. --log存储目录,该目录需要用户自己新建,切需要nginx用户的可写权限

    7. UrlDeny="on"

    8. --是否拦截url访问

    9. Redirect="on"

    10. --是否拦截后重定向

    11. CookieMatch = "on"

    12. --是否拦截cookie攻击

    13. postMatch = "on"

    14. --是否拦截post攻击

    15. whiteModule = "on"

    16. --是否开启URL白名单

    17. black_fileExt={"php","jsp"}

    18. --填写不允许上传文件后缀类型

    19. ipWhitelist={"127.0.0.1"}

    20. --ip白名单,多个ip用逗号分隔

    21. ipBlocklist={"1.0.0.1"}

    22. --ip黑名单,多个ip用逗号分隔

    23. CCDeny="on"

    24. --是否开启拦截cc攻击(需要nginx.conf的http段增加lua_shared_dict limit 10m;)

    25. CCrate = "100/60"

    26. --设置cc攻击频率,单位为秒.

    27. --默认1分钟同一个IP只能请求同一个地址100次

    28. html=[[Please go away~~]]

    29. --警告内容,可在中括号内自定义

    30. 备注:不要乱动双引号,区分大小写

    检查规则是否生效

    部署完毕可以尝试如下命令:

     
    1. curl http://xxxx/test.php?id=../etc/passwd

    2. 返回"Please go away~~"字样,说明规则生效。

    注意:默认,本机在白名单不过滤,可自行调整config.lua配置

    效果图如下:

    sec

    sec

    规则更新:

    考虑到正则的缓存问题,动态规则会影响性能,所以暂没用共享内存字典和redis之类东西做动态管理。

    规则更新可以把规则文件放置到其他服务器,通过crontab任务定时下载来更新规则,nginx reload即可生效。以保障ngx lua waf的高性能。

    只记录过滤日志,不开启过滤,在代码里在check前面加上--注释即可,如果需要过滤,反之

    一些说明:

     
    1. 过滤规则在wafconf下,可根据需求自行调整,每条规则需换行,或者用|分割

    2.  
    3. args里面的规则get参数进行过滤的

    4. url是只在get请求url过滤的规则

    5. post是只在post请求过滤的规则

    6. whitelist是白名单,里面的url匹配到不做过滤

    7. user-agent是对user-agent的过滤规则

    8.  
    9.  
    10. 默认开启了get和post过滤,需要开启cookie过滤的,编辑waf.lua取消部分--注释即可

    11.  
    12. 日志文件名称格式如下:虚拟主机名_sec.log

    Copyright

    Weibo神奇的魔法师
    Forumhttp://bbs.linuxtone.org/
    CopyrightCopyright (c) 2013- loveshell
    LicenseMIT License

    感谢ngx_lua模块的开发者@agentzh,春哥是我所接触过开源精神最好的人

     

    1.  

     

    来源:https://github.com/loveshell/ngx_lua_waf

     

     

     

     

     

    ngx_lua_waf针对性改写
     

     

     

     

    当初选择ngx_lua_waf作为自己的WAF,主要原因就是因为其可扩展性与性能上有一个很好的平衡。

        lua语言的灵活性与效率是很多脚本层WAF无可匹及的。
        ngx_lua_waf自身是比较简单的,而且存在很多误报、漏报、绕过的现象,我整理如下,来改进自己的waf。

    1.debug函数
        预备一个debug函数,方便以后调试。因为waf运行在后台,所以看不到输出,最好以日志的形式写到文件中。

    1function debug(info)
    2    local file = io.open("/tmp/debug.log","a")
    3    file:write(info.."\n")
    4    file:close()
    5end


    2.waf可以用hpp进行绕过
        作为作者一处笔误(我认为的),我提交到乌云了:http://wooyun.org/bugs/wooyun-2010-0104525
        等公开了,可以用里面的方法修改。

    3.利用白名单绕过
        wafconf/whiteurl中,白名单URL直接是/123/
        然后在函数whiteurl中

    01function whiteurl()
    02   if WhiteCheck then
    03       if wturlrules ~=nil then
    04           for _,rule in pairs(wturlrules) do
    05               if ngxmatch(ngx.var.request_uri,rule,"ijom") then
    06                   return true
    07                end
    08           end
    09       end
    10   end
    11   return false
    12end

        用的是ngx.var.request_uri和这个"/123/"进行比较,只要uri中存在/123/就作为白名单不进行检测,这样我们可以通过/waf.php?a=/123/&b=../etc/passwd 绕过防御规则。
        所以,将/123/改成^/123/
        这样只有以/123/开头的uri才能进入白名单。

    4.正则是m还是s
        WAF绕的多的人一定知道正则里“.”代表什么意义。
        正常情况下,.匹配的是“不含换行”的所有字符。所以有些WAF用这样的正则:

         union.*select

        来拦截注入。我们就可以通过union%0aselect,中间一个换行来绕过。
        所以,现在一般的WAF都会用s来修饰正则。s的意思就是single,也就是单行模式。
        说白了,加了s修饰,则“.”就会匹配换行了。

        而我们的ngx_lua_waf中,所有的正则都用的m来修饰的,m的意思是multiple,多行的意思,也就是默认的.不匹配换行。 (注:这样理解是错的,详见评论。)

        而我们的ngx_lua_waf中,并没有使用i修饰正则,所以默认.是匹配多行的,也就是默认的.不匹配换行。

        比如对GET变量的拦截:

    01function args()
    02    for _,rule in pairs(argsrules) do
    03        local args = ngx.req.get_uri_args()
    04        for key, val in pairs(args) do
    05            if type(val)=='table' then
    06                if val == false then
    07                    data=table.concat(val, " ")
    08                end
    09            else
    10                data=val
    11            end
    12            if data and type(data) ~= "boolean" and rule ~="" and ngxmatch(unescape(data),rule,"imjo") then
    13                log('GET',ngx.var.request_uri,"-",rule)
    14                say_html()
    15                return true
    16            end
    17        end
    18    end
    19    return false
    20end

        可见ngxmatch(unescape(data),rule,"imjo"),用的是imjo来修饰。我们用union%0aselect就能绕过WAF:

        QQ20150329-5@2x.png


    5.误杀误杀!上传文件的误杀。
        对HTTP协议了解的同学一定心里清楚,POST的类型是分两种的:application/x-www-form-urlencoded和multipart/form-data
        前一种是默认POST数据的时候使用的,服务器获取了数据后会进行url解码。后一种一般是上传的时候才会使用,服务器获取数据后不会进行url解码,所以我们能直接上传二进制文件。
        php在上传过程中,上传文件的表单会放进$_FILES变量,其他POST表单会放进$_POST变量,和直接application/x-www-form-urlencoded的效果一样。
        这部分POST变量在lua中需要特殊处理,原ngx_lua_waf的作者也考虑了,具体拦截代码可见waf.lua。
        但作者处理的太草率,直接把整个数据包,一点一点丢进body函数里检测。这样造成了两个问题:

         ①. 数据包一部分一部分发过来,他就一部分一部分丢进body里检测。那么如果union、select两个连在一起的关键词正好从中间某位置分开,比如"unio"和"n select",这两个包分别检测都是正常的。但实际发送到php里的时候是连在一起的,导致绕过WAF。
         ②. 文件里的特殊字符也被拦截了,所谓的误杀。有时候我们要上传一些文件,文件里可能会有html标签,或SQL语句,这里他将上传表单的内容也放入body检测了,导致很多文件上传不了。

        我对上述问题做了修改与处理,不过代码太多我就不写在文章里了。思路就是这样:
        首先将完整的数据包获取下来,并用boundary将他们分割成数组。遍历数组,只对进入POST变量的值进行拦截,不拦截FILE内容。但需要拦截FILE表单中的"filename=xxx"的部分。

    6.人性化提示信息
        虽然我的WAF拦截的80%是攻击者,但也可能有正常访客。这时候我就需要告诉访客,你输入了哪些东西不合理被我拦截(误杀)了,你可以换个方式输入或通知我。
        我在init.lua靠前的位置加入如下代码:

    1local fd = io.open(file403,"r")
    2if fd == nil then
    3    html = [[403 error!!]]
    4else
    5    html = fd:read("*a")
    6    fd:close()
    7end

    file403是我自己写的403页面,读取之。并将say_html函数改成这个:

    01function say_html(reason)
    02    if Redirect then
    03        local nowhtml = html
    04        ngx.header.content_type = "text/html"
    05        nowhtml = string.gsub(nowhtml, "{ip}", ngx.var.remote_addr)
    06        nowhtml = string.gsub(nowhtml, "{host}", ngx.var.host)
    07        nowhtml = string.gsub(nowhtml, "{reason}", reason)
    08        ngx.say(nowhtml)
    09        ngx.exit(200)
    10    end
    11end

        将html里的{ip}、{host}、{reason}改成具体的信息。即可在用户被拦截后发出提示:

        QQ20150406-1@2x.png

        如果需要优化SEO,我将ngx.exit(200)改成403,避免搜索引擎收录这个页面。但后来发现status code并没有改变。
        研究了一会,发现如果在ngx.exit之前输出了内容,则这个exit里的参数403就会失效。需要在exit前,先用ngx.status = ngx.HTTP_FORBIDDEN,将status设置成ngx.HTTP_FORBIDDEN,也就是403才可。

    7.利用lua_ngx_waf防御盗链
        以前防盗链都是用nginx自己的模块进行配置,但有时候灵活性不高。
    有了lua waf,就可以灵活地防御盗链了。
        我大概写了个简陋的雏形,需要更精细化的配置,就得各位日后再慢慢修改了。

    01function check_referer()
    02    local referer = ngx.var.valid_referers
    03    local ua = string.lower(ngx.var.http_user_agent)
    04    local exts = [[\.(gif|jpg|jpeg|png|bmp|js|css|swf)$]]
    05    local http = "http"
    06    if ngx.var.https == "on" then http = "https" end
    07    local white_referer = {[0] = [[^]]..http..[[://[^/]*]]..ngx.var.host..[[[^/]*/.*]], [1] = [[^https?://[^/]*google\.com[^/]*/.*]], [2] = [[^https?://[^/]*baidu\.com[^/]*/.*]]}
    08    local white_ua = {[0] = "googlebot", [1] = "spider"}
    09    if referer ~= nil and ngxmatch(ngx.var.request_filename, exts,"ijos") then
    10        for rex in white_referer do
    11            if ngxmatch(referer, rex, "ijos") then return true end
    12        end
    13        for rex in white_ua do
    14            if ngxmatch(ua, rex, "ijos") then return true end
    15        end
    16        ngx.exit(403)
    17    end
    18end


    尾声
        通过这几日对ngx_lua_waf的研究,WAF这块的攻击与防御,我也初步接触到了。我也知道有时候我们研究者说绕过WAF,似乎总在指责WAF的开发者,某某没考虑到,某某可以绕过了。实际上做WAF也不容易,往往是因为要考虑到业务效率、兼容性等各种原因,写出来的代码才被绕过去。
        安全有时候不得不为业务让道,有时候明知这么写是不安全的,但某些用户就需要这样的数据包,我们不能抛弃这部分用户,那么只能尽全力改变这些用户的习惯,写出兼容性更好的代码。
        我希望的是,通过自己的研究,让更多人知道WAF都是怎么做出来的,会遇到哪些问题,有哪些绕过方法。

        攻防,也不过就是那句老话:知己知彼,百战不殆。

     

        整理了这几日写的我从配置安装lua waf,到最后自定义脚本的三篇日记,希望能给同样学习的人帮助:

        http://mp.weixin.qq.com/s?__biz=MzA4MDU0NzY4Ng==&mid=207159087&idx=1&sn=eb914d63344f5cfb4ca1f05049ddb9a3#rd

        http://mp.weixin.qq.com/s?__biz=MzA4MDU0NzY4Ng==&mid=207219219&idx=1&sn=e2183ae2db2ca496bddee4ff8a4ea4bd#rd

        http://mp.weixin.qq.com/s?__biz=MzA4MDU0NzY4Ng==&mid=207396212&idx=1&sn=44d649db48c4f33b2e5f33e4d74bde5b#rd

        也欢迎关注微信公众号《白帽札记》。睡前值得一看的安全笔记。

     

     

     

    来源:http://www.leavesongs.com/OTHERLAN/diy-my-nginx-lua-waf.html

    展开全文
  • 利用国际上公认的一种说法:Web应用 防火墙 是通过执行一系列针对HTTP/HTTPS的 安全策略 来专门为Web应用提供保护的一款产品。1.2 WAF的功能支持IP白名单和黑名单功能,直接将黑名单的IP访问拒绝。支持URL白名单,将...

    一、了解WAF

    1.1 什么是WAF

    Web应用防护系统(也称:网站应用级入侵防御系统 。英文:Web Application Firewall,简称: WAF)。利用国际上公认的一种说法:Web应用 防火墙 是通过执行一系列针对HTTP/HTTPS的 安全策略 来专门为Web应用提供保护的一款产品。

    1.2 WAF的功能

    支持IP白名单和黑名单功能,直接将黑名单的IP访问拒绝。

    支持URL白名单,将不需要过滤的URL进行定义。

    支持User-Agent的过滤,匹配自定义规则中的条目,然后进行处理(返回403)。

    支持CC攻击防护,单个URL指定时间的访问次数,超过设定值,直接返回403。

    支持Cookie过滤,匹配自定义规则中的条目,然后进行处理(返回403)。

    支持URL过滤,匹配自定义规则中的条目,如果用户请求的URL包含这些,返回403。

    支持URL参数过滤,原理同上。

    支持日志记录,将所有拒绝的操作,记录到日志中去

    1.3 WAF的特点

    异常检测协议

    Web应用防火墙会对HTTP的请求进行异常检测,拒绝不符合HTTP标准的请求。并且,它也可以只允许HTTP协议的部分选项通过,从而减少攻击的影响范围。甚至,一些Web应用防火墙还可以严格限定HTTP协议中那些过于松散或未被完全制定的选项。

    2027ac4333f2

    增强的输入验证

    增强输入验证,可以有效防止网页篡改、信息泄露、木马植入等恶意网络入侵行为。从而减小Web服务器被攻击的可能性。

    及时补丁

    修补Web安全漏洞,是Web应用开发者最头痛的问题,没人会知道下一秒有什么样的漏洞出现,会为Web应用带来什么样的危害。WAF可以为我们做这项工作了——只要有全面的漏洞信息WAF能在不到一个小时的时间内屏蔽掉这个漏洞。当然,这种屏蔽掉漏洞的方式不是非常完美的,并且没有安装对应的补丁本身就是一种安全威胁,但我们在没有选择的情况下,任何保护措施都比没有保护措施更好。

    基于规则的保护和基于异常的保护

    基于规则的保护可以提供各种Web应用的安全规则,WAF生产商会维护这个规则库,并时时为其更新。用户可以按照这些规则对应用进行全方面检测。还有的产品可以基于合法应用数据建立模型,并以此为依据判断应用数据的异常。但这需要对用户企业的应用具有十分透彻的了解才可能做到,可现实中这是十分困难的一件事情。

    状态管理

    WAF能够判断用户是否是第一次访问并且将请求重定向到默认登录页面并且记录事件。通过检测用户的整个操作行为我们可以更容易识别攻击。状态管理模式还能检测出异常事件(比如登陆失败),并且在达到极限值时进行处理。这对暴力攻击的识别和响应是十分有利的。

    其他防护技术

    WAF还有一些安全增强的功能,可以用来解决WEB程序员过分信任输入数据带来的问题。比如:隐藏表单域保护、抗入侵规避技术、响应监视和信息泄露保护。

    1.3WAF与网络防火墙的区别

    网络防火墙作为访问控制设备,主要工作在OSI模型三、四层,基于IP报文进行检测。只是对端口做限制,对TCP协议做封堵。其产品设计无需理解HTTP会话,也就决定了无法理解Web应用程序语言如HTML、SQL语言。因此,它不可能对HTTP通讯进行输入验证或攻击规则分析。针对Web网站的恶意攻击绝大部分都将封装为HTTP请求,从80或443端口顺利通过防火墙检测。

    一些定位比较综合、提供丰富功能的防火墙,也具备一定程度的应用层防御能力,如能根据TCP会话异常性及攻击特征阻止网络层的攻击,通过IP分拆和组合也能判断是否有攻击隐藏在多个数据包中,但从根本上说他仍然无法理解HTTP会话,难以应对如SQL注入、跨站脚本、cookie窃取、网页篡改等应用层攻击。

    web应用防火墙能在应用层理解分析HTTP会话,因此能有效的防止各类应用层攻击,同时他向下兼容,具备网络防火墙的功能。

    OpenResty由Nginx核心加很多第三方模块组成,默认集成了Lua开发环境,使得Nginx可以作为一个Web Server使用。

    借助于Nginx的事件驱动模型和非阻塞IO,可以实现高性能的Web应用程序。

    而且OpenResty提供了大量组件如Mysql、Redis、Memcached等等,使在Nginx上开发Web应用更方便更简单。

    以下是整理的Nginx+Lua架构思维导图:

    2027ac4333f2

    二、使用openResty配置waf防火墙,不需要编译nginx

    ①安装依赖包和创建nginx运行的普通用户

    [root@linux-node1 ~]# yum install -y readline-devel pcre-devel openssl-devel

    [root@linux-node1 src]# useradd -s /sbin/nologin -M www

    ②下载当前最新的luajit,并编译

    [root@linux-node1 ~]# cd /usr/local/src/[root@linux-node1 src]#wget http://luajit.org/download/LuaJIT-2.1.0-beta3

    [root@linux-node1 src]# tar -xzf LuaJIT-2.1.0-beta3

    [root@linux-node1 src]# cd LuaJIT-2.1.0-beta3

    [root@linux-node1 LuaJIT-2.1.0-beta3]# make && make install

    [root@linux-node1 LuaJIT-2.1.0-beta3]# export LUAJIT_LIB=/usr/local/lib

    [root@linux-node1 LuaJIT-2.1.0-beta3]# export LUAJIT_INC=/usr/local/include/luajit-2.1

    [root@linux-node1 ~]# ln -s /usr/local/lib/libluajit-5.1.so.2 /lib64/libluajit-5.1.so.2

    #一定创建此软连接,否则会报错如果不创建符号链接,可能出现以下异常: errorwhileloading shared libraries: libluajit-5.1.so.2: cannotopenshared object file: No such fileordirectory

    ③下载并编译安装openresty

    [root@linux-node1 ~]#cd /usr/local/src

    [root@linux-node1 src]# wget https://openresty.org/download/openresty-1.13.6.2.tar.gz

    [root@linux-node1 src]#tar -zxf openresty-1.13.6.2.tar.gz

    [root@linux-node1 src]#cd openresty-1.13.6.2

    [root@linux-node1 openresty-1.13.6.2]# ./configure --prefix=/usr/local/openresty \--user=www \--group=www \--with-luajit \--with-http_v2_module \--with-http_stub_status_module \--with-http_ssl_module \--with-http_gzip_static_module \--with-ipv6 --with-http_sub_module \--with-pcre \--with-pcre-jit \--with-file-aio \--with-http_dav_module

    [root@linux-node1 openresty-1.13.6.2]#gmake && gmake install

    ④测试openresty安装

    [root@linux-node1 ~]#vim /usr/local/openresty/nginx/conf/nginx.confserver

    {    location /hello

    { default_type text/html;

    content_by_lua_block {

    ngx.say("HelloWorld")

    }

    }

    }

    ⑤测试并启动nginx

    [root@linux-node1 ~]#/usr/local/openresty/nginx/sbin/nginx -t

    [root@linux-node1 ~]#/usr/local/openresty/nginx/sbin/nginx

    3、WAF部署

    ①在github上克隆下代码

    [root@linux-node1 ~]#git clone https://github.com/unixhot/waf.git[root@linux-node1 ~]#cp -a ./waf/waf /usr/local/openresty/nginx/conf/

    ②修改Nginx的配置文件,加入(http字段)以下配置。注意路径,同时WAF日志默认存放在/tmp/日期_waf.log

    [root@linux-node1 ~]# cd /usr/local/openresty/nginx/conf

    [root@linux-node1 conf]# vim nginx.conf

    #WAFlua_shared_dict limit50m;

    #防cc使用字典,大小50

    Mlua_package_path"/usr/local/openresty/nginx/conf/waf/?.lua";    init_by_lua_file"/usr/local/openresty/nginx/conf/waf/init.lua";    access_by_lua_file"/usr/local/openresty/nginx/conf/waf/access.lua";

    [root@linux-node1 ~]# /usr/local/openresty/nginx/sbin/nginx –t

    [root@linux-node1 ~]# /usr/local/openresty/nginx/sbin/nginx -s reload

    ③根据日志记录位置,创建日志目录

    [root@linux-node1 ~]#mkdir /tmp/waf_logs[root@linux-node1 ~]#chown nginx.nginx /tmp/waf_logs

    备注:

    我已经将我们生产环境中的nginx+waf的配置文件上次上去,下载链接http://download.csdn.net/detail/m0_37886429/9869230

    4、waf的模块

    ①配置模块

    waf安装好以后,不要直接上生产,而是先记录日志,不做任何动作。确定wafF不产生误杀

    config.lua配置模块

    [root@linux-node1 waf]# pwd/usr/local/openresty/nginx/conf/waf

    [root@linux-node2 waf]# cat config.lua--WAF config file,enable = "on",disable = "off" --waf status    config_waf_enable ="on"

    #是否开启配置--log dir config_log_dir ="/tmp/waf_logs"

    #日志记录地址--rule setting config_rule_dir ="/usr/local/nginx/conf/waf/rule-config"

    #匹配规则缩放地址--enable/disable white url config_white_url_check ="on"

    #是否开启url检测--enable/disable white ip config_white_ip_check ="on"

    #是否开启IP白名单检测--enable/disable block ip config_black_ip_check ="on"

    #是否开启ip黑名单检测--enable/disable url filtering config_url_check ="on"

    #是否开启url过滤--enalbe/disable url args filtering config_url_args_check ="on"

    #是否开启参数检测--enable/disable user agent filtering config_user_agent_check ="on"

    #是否开启ua检测--enable/disable cookie deny filtering config_cookie_check ="on"

    #是否开启cookie检测--enable/disable cc filtering config_cc_check ="on"

    #是否开启防cc攻击--cc rate the xxx of xxx seconds config_cc_rate ="10/60"

    #允许一个ip60秒内只能访问10次--enable/disable post filtering config_post_check ="on"

    #是否开启post检测--config waf output redirect/html config_waf_output ="html"

    #action一个html页面,也可以选择跳转--if config_waf_output ,setting url config_waf_redirect_url ="http://www.baidu.com"config_output_html=[[#下面是html的内容 请安全上网,注意操作规范。 ]]

    备注:”请安全上网,注意操作规范” 这个字段可以随意更改,安装自己的需求来。

    ②access.lua 规则模块

    [root@linux-node1 waf]# pwd/usr/local/openresty/nginx/conf/waf

    [root@linux-node2 waf]# cat access.luarequire'init'functionwaf_main()

    if white_ip_check()

    then else if black_ip_check()

    then else if user_agent_attack_check()

    then else if cc_attack_check()

    then else if cookie_attack_check()

    then else if white_url_check()

    then else if url_attack_check()

    then else if url_args_attack_check()

    then--elseif post_attack_check()

    then else returnendendwaf_main()

    检测顺序:先检查白名单,通过即不检测;再检查黑名单,不通过即拒绝,检查UA,UA不通过即拒绝;检查cookie;URL检查;URL参数检查,post检查;

    启用waf并测试,模拟sql注入即url攻击,显示效果如下 ()

    日志显示如下,记录了UA,匹配规则,URL,客户端类型,攻击的类型,请求的数据

    ④使用ab压测工具模拟防cc攻击

    [root@linux-node3 ~]# ab -c 100 -n 100 http://192.168.88.133/index.php

    ⑤ 模拟ip黑名单

    将请求ip放入ip黑名单中[root@linux-node1 rule-config]# echo “192.168.88.1” >>/usr/local/openresty/nginx/conf/waf/rule-config/blackip.rule

    显示结果如下

    ⑥模拟ip白名单

    将请求ip放入ip白名单中,此时将不对此ip进行任何防护措施,所以sql注入时应该返回404

    [root@linux-node2 rule-config]# echo “192.168.88.1” >>/usr/local/openresty/nginx/conf/waf/rule-config/whiteip.rule

    显示结果如下

    ⑦模拟URL参数检测

    浏览器输入192.168.88.133/?a=select * from table

    显示结果如下

    详细规定在arg.rule中有规定,对请求进行了规范

    bash[root@linux-node1 rule-config]#/usr/local/openresty/nginx/conf/waf/rule-config/cat args.rule\.\./\:\$\$\{select.+(from|limit)(?:(union(.*?)select))having|rongjitestsleep\((\s*)(\d*)(\s*)\)benchmark\((.*)\,(.*)\)base64_decode\((?:from\W+information_schema\W)(?:(?:current_)user|database|schema|connection_id)\s*\((?:etc\/\W*passwd)into(\s+)+(?:dump|out)file\s*group\s+by.+\(xwork.MethodAccessor(?:define|eval|file_get_contents|include|require|require_once|shell_exec|phpinfo|system|passthru|preg_\w+|execute|echo|print|print_r|var_dump|(fp)open|alert|showmodaldialog)\(xwork\.MethodAccessor(gopher|doc|php|glob|file|phar|zlib|ftp|ldap|dict|ogg|data)\:\/java\.lang\$_(GET|post|cookie|files|session|env|phplib|GLOBALS|SERVER)\[\

    参考:

    1.openresty :

    https://github.com/openresty/lua-nginx-module#lualuajit-bytecode-support

    2.安装 :

    https://blog.csdn.net/m0_37886429/article/details/73178889

    https://blog.csdn.net/m0_37886429/article/details/73178889

    3.luajit:

    http://luajit.org/download.html

    4.策略:

    https://github.com/unixhot/waf

    展开全文
  • Web防火墙,主要是对Web特有入侵方式的加强防护,如DDOS防护、SQL注入、XML注入、XSS等。由于是应用层而非网络层的入侵,从技术角度都应该称为Web IPS,而不是Web防火墙。这里之所以叫做Web防火墙,是因为大家比较好...
  • WAF应用防火墙

    千次阅读 2019-06-03 17:02:47
    WAF学习笔记: 技术攻击: (OWASP Top-10) SQL Injection 参考http://www.cnblogs.com/rush/archive/2011/12/31/2309203.html 什么时候可能发生SQL Injection:假设我们在浏览器中输入URLwww.sample.com,...
  • WAF基本原理与部署方式

    万次阅读 多人点赞 2020-06-14 10:34:16
    WAF的全称是(Web Application Firewall)即Web应用防火墙,简称WAF。 国际上公认的一种说法是:Web应用防火墙是通过执行一系列针对HTTP/HTTPS的安全策略来专门为Web应用提供保护的一款产品。 WAF常见的部署方式: ...
  • 很多用户都不懂什么是waf防火墙,也不懂waf防火墙具体的作用有什么,今天小编就来介绍一下waf防火墙的含义以及具有什么作用。  waf防火墙是什么意思  waf防火墙其实就是Web Application Firewall,是一个web...
  • 这篇文章内容关键详细介绍WAF的一些基本概念。WAF是专业为维护根据Web程序运行而设计的,我们科学研究WAF绕开的目地一是协助安服工作人员掌握渗透检测中的检测方法,二是可以对安全机器设备...
  • WAF防火墙、IDS、IPS的介绍和区别

    千次阅读 2021-10-07 10:39:19
    一、WAF 1.WAF是什么 个人理解WAF是一个应用级别的防护软件,主要是针对HTTP/HTTPS的防护,网站应用级别的防护,通过一系列的黑白名单等操作对于诸如SQL注入,XSS,CSRF等攻击进行防护 2.WAF的功能 2.1审计 1.审计的...
  • Azure WAF工作原理分析和配置向导 本文博客地址为:http://www.cnblogs.com/taosha/p/6716434.html ,转载请保留出处,多谢! 本地数据中心往云端迁移的的趋势越来越明显,安全始终是最热门的话题之一。 本文...
  • IDS\IPS\WAF\防火墙

    2020-11-12 11:19:58
    WAF防火墙是对运营Web应用的具备一定防护能力的网络环境的Web攻击防护能力的必要增强。IPS和IDS是该网络环境必备的基础设备。 Web防火墙,主要是对Web特有入侵方式的加强防护,如DDOS防护、SQL注入、XML注入、XSS等...
  • ‍‍XSS:alert(1)出现原因:在waf里,使用的正则不完善或者是没有用大小写转换函数二:干扰字符污染法:空字符、空格、TAB换行、注释、特殊的函数等等都可以。比如下面的:SQL:sEleCt+1-1+vERsIoN /*!*/ ();`...
  • 绕过WAF防火墙

    2021-07-09 14:26:03
    现实中的Web服务,可能潜伏各种Bug漏洞,即便积极的定期进行Web扫描,也不保证万无一失,基于这种原因,应运而生了Web防火墙WAF,最常见的是在基于代理模式的Web网关系统,加入威胁检测功能。 代理模式,原理是将...
  • IPS与IDS,防火墙WAF之间的比较和差异

    千次阅读 多人点赞 2020-08-18 13:13:53
    在本文中,我将尽力比较并分解IPS,IDS,防火墙WAF之间的差异,因为它们是用于网络安全保护的网络中非常流行的解决方案。 首先让我们看一下每个缩写的含义: IPS=入侵防御系统 IDS=入侵检测系统 WAF= Web应用...
  • 部署WAF安全应用防火墙(openresty部署)

    千次阅读 2020-06-21 15:23:46
    利用国际上公认的一种说法:Web应用 防火墙 是通过执行一系列针对http/https的 安全策略 来专门为Web应用提供保护的一款产品。 WAF的功能 支持IP白名单和黑名单功能,直接将黑名单的IP访问拒绝。 支持User-Agent的...
  • 定义:web应用防火墙(Web Application Firewall),通过执行一系列针对HTTP/HTTPS的安全策略来防御对web应用的攻击。 WAF的种类: 源码防护: 程序员在开发时使用过滤函数对恶意代码进行过滤。对于这类的绕过...
  • WAF安全应用防火墙(openresty部署)

    万次阅读 2017-06-13 14:48:55
    利用国际上公认的一种说法:Web应用 防火墙 是通过执行一系列针对http/https的 安全策略 来专门为Web应用提供保护的一款产品。2、WAF的功能 支持IP白名单和黑名单功能,直接将黑名单的IP访问拒绝。 支持URL白名单...
  • WAF绕过

    2022-02-19 11:09:58
    WAF (Web Application Firewall)的中文名称叫做"Web应用防火墙",通过检查HTTP的流量,它可以防御Web应用安全漏洞,如阻止SQL注入,跨站脚本(XSS)、文件包含和安全配置错误等漏洞引发的攻击。 作为攻击者来说,常见的绕...
  • WAF的技术原理

    万次阅读 2018-03-29 16:51:59
    WAF => Web Application Firewall ,可以用来屏蔽常见的网站漏洞攻击,如SQL注入,XML注入、XSS等。一般针对的是应用层而非网络层的入侵,从技术角度应该称之为Web IPS。其防护重点是SQL注入。Web防火墙产品...
  • 支持URL参数过滤,原理同上 支持日志记录,将所有拒绝的操作,记录到日志中去 新增支持拉黑缓存(默认600秒) nginx waf防护顺序: 先检查白名单,通过即不检测;再检查黑名单,不通过即拒绝,检查UA,UA不...
  • 不会吧,不会吧,不会还有人没听过防火墙吧? ~~听过是一回事,但了不了解又是另外一会事了,在我小时候,家里电脑刚买,对电脑那是相当的’爱护‘,每次开机都得克制我玩游戏的强烈欲望,先用对电脑进行杀毒,那...
  • 一、WAF产生的背景 ...传统防火墙无法解析HTTP应用层的细节,防火墙只是在第三层(网络层),对规则的过滤过于死板,无法为WEB应用提供足够的防护(纵深防御)。于是WAF诞生了。 WAF(Web Application Fir...
  • 11.WAF绕过原理

    2020-08-27 11:26:52
    title: 11.WAF绕过原理 date: 2020-08-24 20:09:00 categories: 4.网络安全 1.Web安全 1.SQL注入 tags: 1.Web安全 2.SQL注入 现如今,应该是市面上所有的网站都会有着WAF的存在 Web应用防护系统(也称为:网站...
  • 细说——WAF

    千次阅读 2021-10-11 18:57:17
    WAF的分类软件型WAF硬件型WAF基于云WAF开源型WAF网站内置的WAFIPS与IDS,防火墙WAF之间的比较和差异防火墙功能IPS入侵防御系统IDS入侵检测系统WAF对比IPS与IDS防火墙与IPS / IDSWAF与IPS / IDSWAF检测手工检测工具...
  • 文章来源:美创科技 一、概述 数据库防火墙仿佛是近几年来出现的一款新的安全...由于数据库防火墙这个词通俗易懂,和防火墙、Web防火墙、下一代防火墙等主流安全产品一脉相承,很多公司也就把自己的数据(库)安全产...
  • web防火墙原理

    2019-09-14 04:48:16
    Web应用防火墙主要是对web特有入侵方式的加强防护,重点是放SQL注入,也有人称为SQL防火墙。 Web防火墙的主要技术的对入侵的检测能力,尤其是对Web服务入侵的检测,不同的厂家技术差别很大,不能以厂家特征库大小来...
  • WAF简介

    千次阅读 2021-02-01 17:49:58
    本文将对Web应用防火墙WAF)做一个简单介绍,主要分为以下几个方面: WAF的概念 WAF预防的攻击类型 WAF硬件的部署方式 WAF安全模式 开放Web应用安全项目(OWASP) WAF和传统防火墙的区别 WAF的主流厂商 1. 什么...
  • 之前写了一篇《WAF防御能力评测及工具》,是站在安全运维人员选型WAF产品的角度来考虑的(优先从测试角度考虑是前职业病,毕竟当过3年游戏测试?!)。本篇文章从WAF产品研发的角度来YY如何实现一款可靠的WAF,灵感...

空空如也

空空如也

1 2 3 4 5 ... 20
收藏数 2,146
精华内容 858
关键字:

waf防火墙原理