waf防火墙想必大家都很熟悉，那么具体是什么，作用又是什么？应该有不少人还不是很了解，那么今天就来好好介绍一下。

waf防火墙是什么意思

　　waf防火墙其实就是Web Application Firewall，是一个web应用防护系统，业内比较知名的有网站安全狗。waf一般就是作为企业网络安全保障的第一道防线。日益严重的网络威胁，Waf对比传统的防火墙有更有效的网站防护。

　　waf防火墙有什么作用

　　1、网站安全防护的主要功能：

　　漏洞攻击防护：网站安全防护目前可拦截常见的web漏洞攻击，例如SQL注入、XSS跨站、获取敏感信息、利用开源组件漏洞的攻击等常见的攻击行为。

　　虚拟补丁：网站安全防护可提供0Day，NDay漏洞防护。当发现有未公开的0Day漏洞，或者刚公开但未修复的NDay漏洞被利用时，WAF可以在发现漏洞到用户修复漏洞这段空档期对漏洞增加虚拟补丁，抵挡黑客的攻击，防护网站安全。

　　2、网站安全防护系统特点：

　　实时防护：网站安全防护可以实时阻断黑客通过web漏洞试图入侵服务器、危害用户等恶意行为;可以实时屏蔽恶意扫描程序爬虫，为您的系统节省带宽和资源。

　　3、网站安全防护的用途：

　　提供安全保护：网站安全防护(WAF) 专门保护网站免受黑客攻击，能有效阻挡黑客拖库、恶意扫描等行为;同时在0 day漏洞爆发时，可以快速响应，拦截针对此类漏洞的攻击请求。

　　防护漏洞攻击：网站安全防护(WAF)目前可拦截常见的web漏洞攻击，例如SQL注入，XSS跨站、获取敏感信息、利用开源组件漏洞的攻击等常见的攻击行为。

　　4、网站安全防护的工作原理：

　　网站安全防护(WAF)基于对http请求的分析，如果检测到请求是攻击行为，则会对请求进行阻断，不会让请求到业务的机器上去，提高业务的安全性，为web应用提供实时的防护。

通过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的检测粒度，按需开启,如图所示

2. 协议解析模块（重点）

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

3. 规则模块（重点）

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

(1) 规则配置模块

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

(2)规则解析模块

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

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

(3)规则检测模块

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

4. 动作模块（重点）

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

5. 日志模块（重点）

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

6. 错误处理模块

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

二、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则根据规则的处理方式来进行处理，匹配到之后不继续匹配后续规则。
• 需要开启的功能依次在主函数中调用即可，顺序也可根据实际场景来确定最合适的顺序。

图示如下：

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配置

效果图如下：

规则更新：

考虑到正则的缓存问题，动态规则会影响性能，所以暂没用共享内存字典和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	神奇的魔法师
Forum	http://bbs.linuxtone.org/
Copyright	Copyright (c) 2013- loveshell
License	MIT 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运行在后台，所以看不到输出，最好以日志的形式写到文件中。

1	function debug(info)

2	local file = io.open("/tmp/debug.log","a")

3	file:write(info.."\n")

4	file:close()

5

end

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

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

01	function 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

12

end

    用的是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变量的拦截：

01	function 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

20

end

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

    

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靠前的位置加入如下代码：

1	local fd = io.open(file403,"r")

2	if fd == nil then

3	html = [[403 error!!]]

4

else

5	html = fd:read("*a")

6	fd:close()

7

end

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

01	function 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

11

end

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

    

    如果需要优化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，就可以灵活地防御盗链了。
    我大概写了个简陋的雏形，需要更精细化的配置，就得各位日后再慢慢修改了。

01	function 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

18

end

尾声
    通过这几日对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

一、WAF

1.WAF是什么

个人理解WAF是一个应用级别的防护软件，主要是针对HTTP/HTTPS的防护，网站应用级别的防护，通过一系列的黑白名单等操作对于诸如SQL注入，XSS，CSRF等攻击进行防护

2.WAF的功能

2.1审计

1.审计的作用是对网站人员的操作登录等进行记录
2.对于安全策略的增加和修改
3.对于用户的属性和权限进行修改和操作

2.2访问控制设备

分为主动控制和被动控制

2.3Web应用加固

针对有弱点的Web的应用进行安全策略的加固等操作，比如从网络入侵检测的角度来看可以把WAF看成运行在HTTP层上的IDS设备;从防火墙角度来看，WAF是一种防火墙的功能模块;还有人把WAF看作"深度检测防火墙"的增强。

3.WAF的检测特点

3.1异常协议检测

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

3.2增强的输入验证

对于诸如XSS、CSRF、SQL注入这种会因为人为的输入信息导致漏洞爆发

3.3及时补丁

3.4规则保护

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

3.5状态监测

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

二、防火墙

1.什么是防火墙

所谓防火墙指的是一个由软件和硬件设备组合而成、在内部网和外部网之间、专用网与公共网之间的界面上构造的保护屏障.是一种获取安全性方法的形象说法，它是一种计算机硬件和软件的结合，使Internet与Intranet之间建立起一个安全网关（Security Gateway），从而保护内部网免受非法用户的侵入，防火墙主要由服务访问规则、验证工具、包过滤和应用网关4个部分组成，防火墙就是一个位于计算机和它所连接的网络之间的软件或硬件。该计算机流入流出的所有网络通信和数据包均要经过此防火墙。

2.防火墙的发展

防火墙分为：
第一代：包过滤防火墙，仅能实现简单的访问控制。

第二代：代理防火墙，在应用层代理内部网络和外部网络之间的通信。代理防火墙的安全较高，但是处理速度较慢，而且对每一个应用都要开发一个代理服务很难做到，因此只能对少量的应用提供代理支持。

第三代：状态监测防火墙（发展史上的里程碑），就是看通过防火墙的数据包是否符合HTTP协议的端口号和报文信息，如果不符合就拦截。在状态检测防火墙出现之前，包过滤防火墙只会根据设定好的静态规则为判断是否允许报文通过，它认为报文都是无状态的孤立个体，不关注报文产生的前因后果，这就要求包过滤防火墙都必须针对每一个方向的报文都配置一条规则，转发效率低而且容易带来安全风险。

第四代：统一威胁管理（简称UTM）统一威胁管理防火墙的确实现了对网络全方位的保护，但是由于其多个防护功能一起运行，导致效率不高，而且统一威胁管理防火墙并没有集成深度报文检测功能，所以对数据包深度检测不足，于是又发展出了第五代防火墙：下一代防火墙。下一代防火墙就是目前最常见的防火墙，下一代防火墙解决了统一威胁管理防火墙效率不足和报文深度检测能力不足的弱点。

第五代：下一代防火墙（简称NG）

三、IDS

1.什么是IDS

IDS是英文"Intrusion Detection Systems"的缩写，中文意思是"入侵检测系统"。专业上讲就是依照一定的安全策略，通过软、硬件，对网络、系统的运行状况进行监视，尽可能发现各种攻击企图、攻击行为或者攻击结果，以保证网络系统资源的机密性、完整性和可用性。做一个形象的比喻:假如防火墙是一幢大楼的门锁，那么IDS就是这幢大楼里的监视系统。一旦小偷爬窗进入大楼，或内部人员有越界行为，只有实时监视系统才能发现情况并发出警告。

2.IDS类别

IDS扫描当前网络的活动，监视和记录网络的流量，根据定义好的规则来过滤从主机网卡到网线上的流量，提供实时报警。网络扫描器检测主机上先前设置的漏洞，而 IDS 监视和记录网络流量。如果在同一台主机上运行IDS和扫描器的话，配置合理的IDS会发出许多报警。
1.基于主机的IDS监测（HIDS）
主机型入侵检测系统往往以系统日志、应用程序日志等作为数据源，当然也可以通过其他手段（如监督系统调用）从所在的主机收集信息进行分析。主机型入侵检测系统保护的一般是所在的系统。
2.基于网络的IDS监测（NIDS）
网络型入侵检测系统的数据源则是网络上的数据分组。往往将一台机子的网卡设于混杂模式（Promisc Mode），监听所有本网段内的数据分组并进行判断。一般网络型入侵检测系统担负着保护整个网段的任务。
具体说来，入侵检测系统的主要有以下功能。

（1）监测并分析用户和系统的活动。

（2）核查系统配置和漏洞。

（3）评估系统关键资源和数据文件的完整性。

（4）识别已知的攻击行为。

（5）统计分析异常行为。

（6）操作系统日志管理，并识别违反安全策略的用户活动。

3.IDS工作原理

通俗的理解分为两种，一种是基于异常的监测机制一种是基于行为的监测机制，
异常是通过捕获网络中的流量对比已知的病毒库，漏洞库等已知的病毒特征MD5码等作出相应的措施，一种是基于行为的，简单说就是构建一个行为模型来预测你的行为特征，例如你每天到达单位是八点，九点整你会习惯性的浏览一个小时的网页，十点你会去喝一杯咖啡，但是突然有一天你晚到了一个小时，然后你没有浏览网页喝咖啡，但是不能说你这个人今天没有来公司。
基于行为的构建模型的话就是看你每天的行为是否符合模型的规范，如果不符合就会报错。很明显两种预测模式都存在明显的不足，一是如果发生了未知的攻击，没有记录在数据库中就无法做出防范报警，第二种则是不好做出准确的模型预判，真实环境中会存在漏报和误报的问题。

4.IDS的局限性

1.布置和绕过
（1）网络拓扑局限

对于一个较复杂的网络而言，通过精心地发包，可以导致NIDS与受保护的主机收到的包的内容或者顺序不一样，从而绕过NIDS的监测。

（2）其他路由

由于一些非技术的因素，可能存在其他路由可以绕过NIDS到达受保护主机（例如某个被忽略的Modem，但Modem旁没有安装NIDS）。如果IP源路由选项允许的话，可以通过精心设计IP路由绕过NIDS。

（3）TTL

如果数据分组到达 NIDS 与受保护的主机的 HOP 数不一样，则可以通过精心设置 TTL值来使某个数据分组只能被NIDS或者只能被受保护的主机收到，从而使NIDS的Sensor与受保护主机收到的数据分组不一样，从而绕过NIDS的监测。

（4）MTU

如果NIDS的MTU与受保护主机的MTU不一致的话（由于受保护的主机各种各样，其MTU设置也不一样），则可以精心设置MTU处于两者之间，并设置此包不可分片，使NIDS的Sensor与受保护主机收到的数据分组不一样，从而绕过NIDS的检测。

（5）TOS

有些网络设备会处理TOS选项，如果NIDS与受保护主机各自连接的网络设备处理不一样的话，通过精心设置TOS选项，将会导致NDIS的Sensor与受保护主机收到的数据分组的顺序不一样，于是有可能导致NIDS重组后的数据分组与被保护主机的数据分组不一致，从而绕过NIDS的监测（尤其在UDP包中）。
2、针对IDS的检测方法局限

NIDS 常用的检测方法有特征检测、异常检测、状态检测、协议分析等。实际中的商用入侵检测系统大都同时采用几种检测方法。

NIDS不能处理加密后的数据，如果数据在传输中被加密，即使只是简单的替换，NIDS也难以处理，如采用SSH、HTTPS、带密码的压缩文件等手段，都可以有效地防止NIDS的检测。

NIDS难以检测重放攻击、中间人攻击、对网络监听也无能为力。

目前的NIDS还难以有效地检测DDoS攻击。

（1）系统实现局限

由于受NIDS保护的主机及其运行的程序各种各样，甚至对同一个协议的实现也不尽相同，入侵者可能利用不同系统的不同实现的差异来进行系统信息收集（如Nmap通过TCP/IP指纹来进行对操作系统的识别）或者进行选择攻击，由于NIDS不大可能通晓这些系统的不同实现，故而可能被入侵者绕过。

（2）异常检测的局限

异常检测通常采用统计方法来进行检测。

统计方法中的阈值难以有效确定，太小的值会产生大量的误报，太大的值会产生大量的漏报，例如系统中配置为200个/秒半开TCP连接为SYN_Flooding，则入侵者每秒建立199个半开连接将不会被视为攻击。

异常检测常用于对端口扫描和 DDoS 攻击的检测。NIDS 存在一个流量日志的上限，如果扫描间隔超过这个上限，NIDS将忽略掉这个扫描。尽管NIDS可以将这个上限配置得很长，但此配置越长，对系统资源要求越多，受到针对NIDS的DDoS攻击的可能性就越大。

（3）特征检测的局限

特征检测主要针对网络上公布的黑客工具或者方法，但对于很多以源代码发布的黑客工具而言，很多入侵者可以对源代码进行简单的修改（如黑客经常修改特洛伊木马的代码），产生攻击方法的变体，就可以绕过NIDS的检测。

3、针对应用协议局限

对于应用层的协议，一般的NIDS只简单地处理了常用的如HTTP、FTP、SMTP等，尚有大量的协议没有处理，也不大可能全部处理，直接针对一些特殊协议或者用户自定义协议的攻击，都能很好地绕过NIDS的检查。
4.针对IDS资源及处理能力局限

（1）大流量冲击

攻击者向被保护网络发送大量的数据，超过NIDS的处理能力有限，将会发生分组的情况，从而可能导致入侵行为漏报。

（2）IP碎片攻击

攻击者向被保护网络发送大量的IP碎片（如TARGA3攻击），超过NIDS能同时进行的IP碎片重组能力，从而导致通过IP分片技术进行的攻击漏报。

（3）TCP Connect Flooding

攻击者创建或者模拟出大量的TCP连接（可以通过上面介绍的IP重叠分片方法），超过NIDS同时监控的TCP连接数的上限，从而导致多余的TCP连接不能被监控。

（4）Alert Flooding

攻击者可以参照网络上公布的检测规则，在攻击的同时故意发送大量的将会引起 NIDS报警的数据（例如stick攻击），将可能超过NIDS发送报警的速度，从而产生漏报，并且使网管收到大量的报警，难以分辨出真正的攻击。

（5）Log Flooding

攻击者发送大量的将会引起NIDS报警的数据，最终导致NIDS进行Log的空间被耗尽，从而删除先前的Log记录。

四、IPS

随着电脑的广泛应用和网络的不断普及，来自网络内部和外部的危险和犯罪也日益增多。20年前，电脑病毒主要通过软盘传播。后来，用户打开带有病毒的电子信函附件，就可以触发附件所带的病毒。以前，病毒的扩散比较慢，防毒软体的开发商有足够的时间从容研究病毒，开发防病毒、杀病毒软件。而今天，不仅病毒数量剧增，质量提高，而且通过网络快速传播，在短短的几小时内就能传遍全世界。有的病毒还会在传播过程中改变形态，使防毒软件失效。

目前流行的攻击程序和有害代码如 DoS (Denial of Service 拒绝服务)，DDoS (Distributed DoS 分布式拒绝服务)，暴力猜解(Brut-Force-Attack)，端口扫描(Portscan)，嗅探，病毒，蠕虫，垃圾邮件，木马等等。此外还有利用软件的漏洞和缺陷钻空子、干坏事，让人防不胜防。

网络入侵方式越来越多，有的充分利用防火墙放行许可，有的则使防毒软件失效。比如，在病毒刚进入网路的时候，还没有一个厂家迅速开发出相应的辨认和扑灭程序，于是这种全新的病毒就很快大肆扩散、肆虐于网路、危害单机或网络资源，这就是所谓Zero Day Attack。

防火墙可以根据IP地址(IP-Addresses)或服务端口(Ports)过滤数据包。但是，它对于利用合法IP地址和端口而从事的破坏活动则无能为力。因为,防火墙极少深入数据包检查内容。即使使用了DPI技术 (Deep Packet Inspection 深度包检测技术)，其本身也面临着许多挑战。

每种攻击代码都具有只属于它自己的特征 (signature), 病毒之间通过各自不同的特征互相区别，同时也与正常的应用程序代码相区别。杀毒软件就是通过储存所有已知的病毒特征来辨认病毒的。

在ISO/OSI网络层次模型(见OSI模型) 中，防火墙主要在第二到第四层起作用，它的作用在第四到第七层一般很微弱。而除病毒软件主要在第五到第七层起作用。为了弥补防火墙和除病毒软件二者在第四到第五层之间留下的空档，几年前，工业界已经有入侵侦查系统(IDS: Intrusion Detection System)投入使用。入侵侦查系统在发现异常情况后及时向网路安全管理人员或防火墙系统发出警报。可惜这时灾害往往已经形成。虽然，亡羊补牢，尤未为晚，但是，防卫机制最好应该是在危害形成之前先期起作用。随后应运而生的入侵响应系统(IRS: Intrusion Response Systems) 作为对入侵侦查系统的补充能够在发现入侵时，迅速作出反应，并自动采取阻止措施。而入侵预防系统则作为二者的进一步发展，汲取了二者的长处。

入侵预防系统也像入侵侦查系统一样，专门深入网络数据内部，查找它所认识的攻击代码特征，过滤有害数据流，丢弃有害数据包，并进行记载，以便事后分析。除此之外，更重要的是，大多数入侵预防系统同时结合考虑应用程序或网路传输中的异常情况，来辅助识别入侵和攻击。比如，用户或用户程序违反安全条例、数据包在不应该出现的时段出现、作业系统或应用程序弱点的空子正在被利用等等现象。入侵预防系统虽然也考虑已知病毒特征，但是它并不仅仅依赖于已知病毒特征。

应用入侵预防系统的目的在于及时识别攻击程序或有害代码及其克隆和变种，采取预防措施，先期阻止入侵，防患于未然。或者至少使其危害性充分降低。入侵预防系统一般作为防火墙 和防病毒软件的补充来投入使用。在必要时，它还可以为追究攻击者的刑事责任而提供法律上有效的证据 (forensic)。