[硬件故障] HTTP分析器 浏览器, content, 检测

从性能、效率、检测率、误报率等各方面看，使用协议分析的入侵检测系统比起使用简单模式匹配的入侵检测系统有着较大的优势。下面我们就以HTTP协议为例，结合KIDS（金诺网安入侵检测系统）中使用的HTTP分析器，对这两种方法进行比较说明。 GET /scripts/..%c1%1c../winnt/system32/cmd.exe?/c+dir HTTP/1.0 一个针对IIS的Unicode攻击的第一步一般是通过浏览器送出类似下面这样一个HTTP请求： TCP dport:80; content:“%c1%1c”/i; alert:“IIS Unicode Directory Traversal” TCP dport:80; content:“cmd.exe”/i; alert:“Attempt to execute cmd” 使用模式匹配的入侵检测系统会使用类似于下面的规则进行检测： 第一条规则表示，如果检测到一个TCP包发向80端口，并且其中含有字符串“%c1%1c”，系统就发出报警“IIS Unicode Traversal”；第二条规则表示，如果检测到一个TCP包发向80端口，并且其中含有字符串“cmd.exe”（忽略大小写），系统就发出报警“Attempt to execute cmd”。 抛开实现上的优化等问题，这样一个系统有着下面两个严重缺陷： ● 误报　这个方法不考虑TCP连接是否已建立，也不考虑匹配字串会不会可能是合法数据的一部分。特别是后一情况尤为严重。拿换码序列“%c1%1c”来说，它完全可以是Cookie或GET/POST数据中的合法成员。 ● 漏报　这一检测方法要求匹配字串出现在同一数据包中，攻击者完全可以使用多个数据包来实施这一攻击。使用Telnet 目标主机80，然后直接在命令行上输入上面的HTTP请求并加上两个回车，就可以发出攻击，而这样的攻击可能使用了多至64个数据包。攻击者也可以对“cmd.exe”进行换码处理——如使用“%63md.exe”，上面的第二条检测规则就完全没用了。 KIDS中的HTTP分析器恰恰是针对这两个缺陷设计的。它具有以下特点： ● 使用插件方式运行时动态载入　如果不需要对HTTP进行监测，可以不加载HTTP分析器以节省网络传感器的内存开销。 ● KIDS引擎的TCP流重组能力：可对分散在多个数据包中的HTTP请求进行分析处理。 ● 完整获取整个HTTP请求：可对请求超长（可能为缓冲区溢出攻击）进行判断，即使一个HTTP请求跨越了多个TCP包。 ● 完整分析HTTP 0.9、HTTP 1.0和HTTP 1.1协议：可对一个HTTP连接中的多个HTTP请求分别进行分析处理。 ● 可对向代理服务器发出的HTTP请求进行分析处理。 ● 把HTTP请求分解为方法、主机、路径、查询字串等部分分别进行分析处理。对路径部分会进行解码处理，并对解码前后的路径分别进行检验。 HTTP分析器里的规则是以XML的方式分层进行组织。我们主要关心的HTTP方法是“GET”、“HEAD”和“POST”，所以我们在Method中对此进行了规定；这意味着，我们只对这三种类型之一的完整HTTP请求进行分析处理。HTTP及其代理的常用端口80、3128和8080在network部分用port标签进行了规定。rules部分中的host可规定禁止访问的网站（以域名形式）。path部分规定了如何对解码前的路径进行检验，而path_decoded部分规定了如何对解码后的路径进行检验。对于包含“%63md.exe”的路径，HTTP分析器解码后会先得到“cmd.exe”，然后很容易就能在规则中匹配到，并产生编号为1056的事件。HTTP分析器会把事件号和相关信息以统一的格式递交给响应模块做下一步处理。 综上所述，KIDS中的HTTP分析器以独立的检测器模块方式工作，对HTTP请求进行分析处理，能够更可靠、更有效地对通过HTTP协议发起的攻击进行检测。显然，以模块化的方式对高层协议进行分析处理，将是未来入侵检测的方向。

偶终于知道了，此番人世，得此一贴

哈哈,有意思。