Snort的告警规则：

　　监管层面不同，如果面对同样的攻击，比如SQL注入，它们都是可以防护的，但防护的原理有区别，IPS基本是依靠静态的签名进行识别，也就是攻击特征，这只是一种被动安全模型。如下是一个Snort的告警规则：

　　alert tcp $EXTERNAL_NET any -> $HTTP_SERVERS $HTTP_PORTS

　　(msg:“SQL Injection - Paranoid”; flow:to_server,

　　established;uricontent:“.asp”;pcre:“/

　　(\%27)|(\‘)|(\-\-)|(%23)|(#)/i”;

　　classtype:Web-application-attack; sid:9099; rev:5;)

　　这里主要是检查在SQL注入中提交的元字符，包括单引号( ' )和双横( -- )，从而避免注入'1 or 1=1— 之类的攻击发生，但同时又要考虑这些元字符转换成Hex值来逃脱过滤检查，于是又在规则里增加了其对应的十六进制编码后的字符串。

　　当然，要从签名特征来识别攻击要考虑的东西还很多，不仅元字符还有SQL关键字，包括：select insert update等，以及这些关键字的大小写变形和拼接，利用注释逃脱过滤，如下所示例：

　　使用大小写混杂的字符 ：SeLecT fRom“

　　把空格符替换为TAB符或回车符 ：select[TAB]from

　　关键词之间使用多个空格 ：select from

　　字符串的数值编码 ：0x414141414141 或 0x41004100410041004100

　　插入被数据库忽略的注释串 ：sel/**/ect fr/**/om select/**/ from

　　使用数据库支持的一些字符串转换功能 ：char(65) 或 chr(65)

　　使用数据支持的字符串拼接操作 ：'sel'+'ect '+'fr'+'om’” 、“‘sel'||'ect '||'fr'||'om'可以设想一下，如果要检测以上的变形字符后的攻击则需要增加相应的签名特征，但更重要的是要充分考虑转换编码的种类，上面示例的snort的规则把可疑字符以及其转换后的Hex值放入同一条规则里检查，如果对于变形后繁多的攻击种类，这是滞后的并且会造成签名臃肿。

　　对于比较粗浅的攻击方式两者都能防护，但市面上大多数IPS是无法对报文编码做多重转换的，所以这将导致攻击者只需构建诸如转换编码、拼接攻击语句、大小写变换等数据包就可绕过输入检查而直接提交给应用程序。

　　而这恰恰又是WAF的优势，能对不同的编码方式做强制多重转换还原成攻击明文，把变形后的字符组合后在分析。那为什么IPS不能做到这个程度?同样还有对于HTTPS的加密和解密，这些我们在下节的产品架构中会解释。