基于Web的入侵防御系统的设计及实现.docx
- 文档编号:9837409
- 上传时间:2023-02-06
- 格式:DOCX
- 页数:24
- 大小:29.61KB
基于Web的入侵防御系统的设计及实现.docx
《基于Web的入侵防御系统的设计及实现.docx》由会员分享,可在线阅读,更多相关《基于Web的入侵防御系统的设计及实现.docx(24页珍藏版)》请在冰豆网上搜索。
基于Web的入侵防御系统的设计及实现
基于Web的入侵防御系统的设计与实现
摘 要
Web服务器往往得不到传统防御方式的有效保护,使其成为整个网络环境中安全最薄弱的地方。
缓冲区溢出、SQL注入、基于脚本的DDos、盗链和跨站等攻击行为对Web服务器的安全和稳定造成极大的威胁,而目前缺少有效的防御和保护的方式。
本课题中首先调研了当前Web服务器所面对的威胁,然后针对这些安全威胁设计了一套入侵防御系统,并通过ISAPI实现了对Windows平台下的IIS服务器的保护。
在这套入侵防御系统中,可以通过制定策略来检测所有访问Web服务器的行为,可以有效地阻止恶意攻击从而保护Web服务器的安全。
这套入侵防御系统的策略引擎可以加载和调用Lua语言编写的策略脚本,使策略脚本的编写更加简单。
关键词:
入侵防御;网络安全;ISAPI;Lua
DesignandImplementationofWebIntrusionPreventionSystem
Abstract
Webservercannotoftengettheeffectiveprotectionoftraditionaldefensemechanism,makesitbeetheweakestareainthewholenetwork.Theattacks,suchasBufferoverflow,SQLinjection,DDosbasedonscript,ResourcestealandCross-site,causethegreatthreattothesecurityandstabilityofWebserver,andlackeffectivedefenseandprotectionwayatpresent.ThispaperintroducesthedifferentattackwaystoaWebserveratfirst,thendesignsanintrusionpreventionsystemfortheWebserverandimplementstheprotectionofIISserverunderWindowsplatformthroughISAPI.TheintrusionpreventionsystemcanmeasurethebehaviorsofallvisitingWebserversthroughthestrategiesandprotecttheWebServeragainstthemaliciousattacks.ThesecuritystrategiesengineofthesystemcanloadandtransferthestrategyscriptswritteninLualanguage,Itmakestrategyscriptswritingmoresimpler.
Keywords:
Intrusionsprevention;networksecurity;ISAPI;Lua
目 录
论文总页数:
20页
1 引言 1
2 Web服务器所受的威胁及防御 1
2.1 缓冲区溢出 1
2.2 SQL注入攻击 1
2.3 基于脚本的DDos攻击 2
2.4 其他的不安全因素 3
3 Web的入侵防御系统的设计 4
3.1 体系结构 4
3.2 处理流程 5
3.3 对客户端访问的响应 7
3.4 策略引擎的设计 8
3.4.1 策略的属性 8
3.4.2 策略的加载 9
3.4.3 策略的调度 10
3.4.4 策略的接口 10
4 Web的入侵防御系统的实现 11
4.1 基于ISAPI的解析及响应模块的实现 11
4.1.1 使用ISAPIFilter获取Http报文信息 11
4.1.2 使用ISAPI进行Http响应 13
4.1.3 在服务器上的安装配置ISAPIFilter 14
4.2 基于Lua的策略实现 15
4.2.1 对策略的封装 15
4.2.2 Lua策略脚本示例 15
4.3 基于xml的策略管理 16
5 系统运行过程及测试 16
结 论 18
参考文献 18
致 谢 19
声 明 20
1 引言
连接入互联网中的每一台服务器每时每刻都会受到来自病毒蠕虫的侵扰和黑客的入侵。
目前,很多针对Web服务器的攻击都是通过Http协议发起的,所以传统的防火墙对诸如SQL注入这种攻击方式不能提供很好的保护。
在很多网络环境中,正是由于Web服务器同时对内部网络和外部网络提供服务,使其成为整个网络中最常被攻击的目标。
恶意的攻击者往往通过Web服务器上的突破口,来进一步对内部网络进行渗透。
所以,Web服务器的安全显得尤为重要。
本课题的首先对Web服务器所受到的威胁及相应的防御方式做了一些调研,然后针对Web服务器所受的这些威胁设计了一套专门针对Web服务器安全的轻量级的入侵防御系统,并通过ISAPI实现了Windows平台环境下保护IIS服务器的系统。
这套系统通过策略来控制访问Web服务器的行为,它的策略引擎可以加载Lua脚本编写的策略,所以策略的编写十分容易。
通过对这套系统的运行检测可以发现它能有效的保护Web服务器的安全。
2 Web服务器所受的威胁及防御
Web服务器在互联网环境中会遭受格式各样的安全威胁,下面列出的是一些当前主流的针对Web服务器的攻击方式,它们有的会导致服务器被非法控制,有的会使服务器无法提供正常的服务,而有的甚至会对访问者的机器造成破坏。
2.1 缓冲区溢出
缓冲区溢出[1]主要是因为Web服务器程序对客户端提交的数据缺少安全必要的长度检测,服务器程序的堆栈被恶意数据填充,导致服务器程序执行非法的指令或产生拒绝服务。
如曾经造成十分大危害的蠕虫“红色代码(RedCode)”和“尼姆达(Nimda)”都是利用IIS的缓冲区溢出的漏洞而传播的。
目前,缓冲区溢出是很难杜绝的,因为Web服务器程序开发的测试阶段无法对所有客户端可能提交的数据进行测试,所以不能确保Web服务器程序完全没有缓冲区溢出威胁的存在。
因为Web服务器程序提供专有的HTTP服务,所以我们可以通过HTTP协议确定客户端提交数据中每个字段的长度的合理X围,通过对所有用户提交的数据都进行严格的长度检测是对缓冲区溢出攻击的有效防御方式。
2.2 SQL注入攻击
SQL注入攻击[2]是近几年非常流行的攻击方式。
对一个内部网络的渗透往往是从Web服务脚本入手(如ASP,PHP等),而SQL注入漏洞通常是Web服务脚本中最容易找到的。
目前互联网上仍然存在很多有此风险的服务器。
SQL注入同样也是对客户端提交的数据没有进行必要的检测过滤造成的。
构造特殊的数据提交到存在此缺陷的Web服务器上后,可以导致恶意的SQL语句注入到Web脚本的SQL调用中,从而泄露敏感信息或者执行威胁的SQL指令。
无论是何种Web脚本语本语言或何种数据库,如果编码人员缺乏相关的安全意识,都可能会导致此缺陷的存在。
目前对SQL注入攻击提出的防御方案有:
(1) 在服务端正式处理之前对提交数据的合法性进行检查;
(2) 封装客户端提交信息;
(3) 替换或删除敏感字符/字符串;
(4) 屏蔽出错信息。
方案
(1)被公认是最根本的解决方案,在确认客户端的输入合法之前,服务端拒绝进行关键性的处理操作,不过这需要开发者能够以一种安全的方式来构建网络应用程序,虽然已有大量针对在网络应用程序开发中如何安全地访问数据库的文档出版,但仍然有很多开发者缺乏足够的安全意识,造成开发出的产品中依旧存在注入漏洞;方案
(2)的做法需要RDBMS的支持,目前只有Oracle采用该技术;方案(3)则是一种不完全的解决措施,例如,当客户端的输入为“…ccmdmcmdd…”时,在对敏感字符串“cmd”替换删除以后,剩下的字符正好是“…cmd…”;方案(4)是目前最常被采用的方法,很多安全文档都认为SQL注入攻击需要通过错误信息收集信息,有些甚至声称某些特殊的任务若缺乏详细的错误信息则不能完成,这使很多安全专家形成一种观念,即注入攻击在缺乏详细错误的情况下不能实施。
2.3 基于脚本的DDos攻击
当一个入侵者无法找到目标Web服务器的有效渗透方式时,很可能选择DDos这种攻击方式。
传统的DDos攻击方式在一台硬件防火墙面往往失去了它的威力,而基于脚本的DDos攻击在近几年里逐渐成为对Web服务器发起拒绝服务的有效方式。
和传统的DDos攻击针对服务器操作系统本身或网络带宽的消耗而言,基于脚本的攻击方式是针对应用程序的消耗来达到拒绝服务攻击的目的。
对静态网页来说,这种攻击方式往往达不到它的攻击效果,而动态网页中,都会有一些对资源占用比较多的页面,比如包含复杂查询语句的页面,很可能在一次访问过程中会有较长时间访问数据库的行为,通过多线程,分布式的访问这个页面就可以造成拒绝服务的效果。
目前,流行的CC工具就是利用这个原理来实现基于脚本的DDos攻击。
基于脚本的DDos的另一种攻击方法是利用Web系统XX息提交的功能提交垃圾数据。
防御这种攻击方式的方法有以下几种:
(1) 防止客户端的快速刷新,可以通过Cookie或者Session来实现
(2) 对消耗较大的页面进行识别码认证,确保是人而不是恶意的自动化程序在访问这个页面。
(3) 限制每个客户端访问的线程数
2.4 其他的不安全因素
除了上面所列的几种Web服务器常见的攻击威胁外,还存在一些其他的不安全因素。
(1) 缺少经验的系统管理员往往没有正确的设置服务器文件系统的权限
当一个入侵者获得到Web服务器上的较低的权限时,他通常会想方设法的提升自己的权限,而服务器文件系统的权限系统没有正确设置时,可以通过较低的权限下获取到服务器上的敏感信息,为提升权限提供了条件。
(2) 盗链
盗链虽然不是一种攻击手段,但因其消耗了大量的服务器资源和带宽,所以也是对当前Web服务器的稳定影响比较大的因素。
盗链的定义是:
此内容不在自己服务器上,而通过技术手段,绕过别人放广告有利益的最终页,直接在自己的有广告有利益的页面上向最终用户提供此内容。
常常是一些名不见经传的小来盗取一些有实力的大的地址(比如一些音乐、图片、软件的下载地址)然后放置在自己的中,通过这种方法盗取大的空间和流量。
另外一种盗链是像讯雷这样的P2SP的下载软件,可以让客户端以类似BT的方式同时从多台服务器上下载文件。
对盗链的防御往往是通过设定一些访问策略来实现,如检查客户端http报头的refer字段等。
(3) 脚本自身的Bug
Web服务器上所运行的动态脚本(ASP、ASP.NET、JSP和PHP等等)自身所带的Bug也会给Web服务器的安全带来极大的威胁。
例如前面所提的SQL注入也是属于Web脚本的Bug。
恶意的攻击者可能可以利用这些脚本中的Bug轻易的获得Web服务器的权限。
很多Web服务器上采用的是开源的系统,而有的管理员因为设置上的疏忽(例如编辑源码后产生的bak文件,数据库的路径没有保护等等),给攻击者入侵打开了方便之门。
对于这类来自脚本自身的安全威胁,好的防御方式是时常关注源码站点的补丁信息,对Web服务器的环境进行安全配置,防止数据库这样会透露敏感信息的文件被下载等等。
上面所介绍的这些对Web服务器的威胁,虽然只是对Web服务器众多攻击方式中的某几种,但我们可以看出,对Web服务器的攻击行为往往都具有和普通的访问不同的行为。
我们可以通过这些非正常的访问行为鉴别出恶意的攻击访问。
下面将介绍对Web服务器进行入侵防御系统的设计和实现。
3 Web的入侵防御系统的设计
由于系统要对客户端发送的Http报文进行分析,这需要对Http报文进行解析,Http报文解析的方式主要有两种:
(1)自解析:
系统对原始数据报文自行解析;
(2)由Web服务器进行解析,需要时系统通过Web服务器提供的接口查询。
方式
(1)可以提供比方式
(2)更好的移植性,但这种报文解析的方式需要一种截获下层原始报文的能力,这可以通过截获传输层或网际层报文的实现,由于我们将这套系统定位于仅针对Web访问的入侵防御,我们对Http协议外的报文并不关心,所以我们选择方式
(2)作为我们的Http报文解析方案,即通过Web服务器提供的接口仅仅截获应用层的Http报文。
要对客户端发起的请求进行完全的监控光靠检测客户端的行为是不够的,因为这样我们只知道客户端发起什么样的请求但无法知道服务器端是如何对客户端进行响应的。
一次完整的Http会话既然包括客户端发送请求和服务器端对请求的响应,那么只有监控服务器端响应的内容后,才能知道这次Http会话何时结束。
如果Web服务器提供Http报文封装的接口,则在对客户端进行响应时我们也尽量调用Web服务器的这些接口而不是自己组装Http报文。
这样,这套入侵防御系统的核心便是其策略引擎,通过强大而灵活的策略引擎来实现特征检测或者异常检测。
下面将介绍这个Web的入侵防御系统的具体体系结构和处理流程。
3.1 体系结构
通常一个系统会采用多层或者单层的体系结构。
多层的结构将不同功能的模块进行了划分,层与层之间靠定义好的接口进行通信,单层的结构将模块都紧耦合在一起,模块与模块间有交叉调用。
多层的结构比单层的结构具有良好的扩展性,而单层结构可以模块间的交互更加高效。
为了能使系统适合不同的Web服务器平台,综合以上的因素考虑后,本系统采用分层的体系结构。
这个Web的入侵防御系统主要分层了以下三层:
(1) 解析及响应层
这一层为整个防御系统提供对客户端发送的Http报文请求的解析及服务器响应时Http报文封装的接口。
当有客户端访问服务器时,通知策略引擎调度策略检测客户端的访问信息,并为策略引擎提供响应的实现。
按照前面的分析,这一层是由服务器提供的接口封装实现。
(2) 策略引擎
这一层的作用是策略的调度,在策略中通过“解析及响应”层提供的接口获取客户端的信息,具体的响应也交给“解析及响应”层完成。
同时策略引擎还需要调度数据管理层完成策略的加载,以及日志记录的功能。
(3) 数据管理
这一层提供日志记录、配置管理及策略脚本解析的功能。
所以对数据进行处理的过程都是在这一层里完成。
每一层都完成相对独立的功能,当某一层的实现发生变化时,只要提供的接口没有变化,对其他几层就没有影响。
这样整个结构就有很大的扩展性,例如:
我们可以把解析和响应层的具体实现是由调用Web服务器自身接口的方式替换为直接截获传输层网络层封包的方式等等。
下面将介绍具体的处理流程。
3.2 处理流程
WebIPS的具体处理流程如下:
当客户端发送Http请求时,原始的数据报文经Http报文解析模块解析,报文解析模块会通知策略引擎模块对客户端的信息进行检测,策略引擎会依据策略脚本中编写的策略,通知Http响应模块对客户端的行为做出响应,并依据策略脚本中的策略,通知日志记录模块记录相应的日志。
依据WebIPS系统的体系结构及处理流程,系统主要模块和作用如下:
(1) IPS管理模块
负责管理和连接各个模块,管理数据流,读取配置文件后完成整个系统的初始化,对整个系统的状态进行管理:
运行,停止,重新加载。
当Http报文解析模块通知有客户端的访问时,调用策略引擎对客户端的行为及信息进行检测,对策略引擎返回的结果通知Http响应模块进行响应。
(2) 配置文件模块
主要完成配置文件的读取及保存。
提供统一的接口,具体实现可以根据需要而作修改。
(3) Http报文的解析模块
利用Web服务器提供的接口,对客户端访问Web服务器时提交的原始数据进行解析,并通知IPS管理模块收到客户端的访问请求,请求策略引擎检测客户端的访问行为。
Http报文的解析模块中会为每一个客户端生成一个实现了能检测客户端相关信息的接口的对象。
在一般的Web脚本(例如:
ASP、ASP.NET、PHP等等)中也会有这样一种获取客户端信息的接口。
(4) Http响应模块
当需要对客户端的行为进行响应时,在这一模块中对数据报文进行组装。
提供以下几种响应方式:
调用下一条策略、接受请求、断开、发送信息、发送文件和重定向。
除了“调用下一条策略”需要策略引擎继续调用其他策略外,其他的响应结束后都表示客户端的一次请求过程的结束,策略引擎将不会继续调用策略链上的其它策略。
(5) 策略引擎模块
首先策略引擎对策略脚本进行解析,根据策略的属性和优先级组装策略链。
当IPS管理模块通知策略引擎对某一个客户端的信息进行检测时,策略引擎利用Http报文解析模块提供的接口获取所需的客户端得信息,分析客户端得行为,通过依次调度策略来控制客户端的访问。
在策略中,可以检测客户端请求的各个字段,并对客户端的行为进行分析或记录,通过定义好的规则对客户端不同的行为进行响应。
当一个策略中没有对客户端的行为做出响应时,策略引擎调用策略链中的下一条,直到全部调用完。
如果有策略返回响应,则通知Http响应模块完成客户端的响应,并停止调动策略链后面的策略。
如果没有任何策略对客户端的行为做出响应,策略引擎则返回接受请求的响应。
策略引擎需要封装Http报文的解析和响应模块,及日志记录模块,供策略中调用。
(6) 日志模块
日志模块的作用是对系统运行时产生的日志或对入侵防御行为的进行记录。
使用统一的格式将日志信息记录在文本文件中。
由于系统采用分层的体系结构,所以这一模块可以方便的替换成其他格式的日志记录方式。
3.3 对客户端访问的响应
在一个策略中,可以返回对客户端的行为做出的响应,或什么都不返回。
如果返回的是除“调度下一条策略”外的其他响应,则策略引擎停止调动策略链中后面的策略,否则策略引擎依次调度策略链上的策略直到全部策略调度完成。
下面将详细介绍每一种响应方式的效果和作用。
(1) 调度下一条策略
这是策略的默认响应方式,策略引擎将为客户端调度下一条策略。
当一个策略中没有对客户端的行为做出任何响应,则策略引擎认为该客户端调用策略链上的下一条策略。
(2) 接受请求
接受客户端的访问。
策略引擎将不会调用后面的策略。
这种响应方式通常用于白,即对特定的客户端的做出的特别响应处理,由Web服务器处理客户端的访问请求,而不受发出这个响应的策略后面的策略的影响。
(3) 拒绝连接
让WebServer直接断开和客户端的连接,这是一种最严重的响应方式,在客户端所看到的结果就是浏览器报告说找不到服务器。
当策略引擎已经确认客户端的访问是恶意的攻击行为时,可以直接断开和客户端的连接。
由于响应是在Http响应模块中完成,这个模块使用的是Web服务器提供的接口,响应的过程是在策略调度之后,所以客户端再次发送的Http报文请求还是会通过Http报文的解析及策略的调度,如果“拒绝连接”的响应方式是由Web服务器外的方式实现的,比如操作系统的IP访问策略或硬件防火墙等,则客户端再次发送的访问请求不会再被Http报文解析模块接收到,也不会再被引擎策略调度。
(4) 发送信息
直接发送一段文本信息到客户端,通常是一段提示或警告信息。
这是一种比较友好的交互行为,其效果为客户端的浏览器上会显示发送的这段信息。
当策略引擎检测到策略返回的是这种响应方式后会停止调用策略链后面的其他策略。
(5) 发送文件
发送服务器上的一个文件到客户端。
这种响应方式和上一种类式,但通过文件的方式可以发送更多的信息到客户端。
比如在防止图片的盗链的策略中,可以发送一个用来表明图片为盗链的图片文件到客户端。
如果是采用的发送信息的响应方式,则客户端看不到这条信息。
(6) 重定向
让WebServer重定向客户端的访问。
和前两种响应方式类似,区别是客户端会检测到所访问的Url的发生跳转。
跳转即可以是本服务器的地址,也可以是外部服务器的地址。
当策略引擎检测到策略返回的是这种响应方式后也会停止调用策略链后面的其他策略
3.4 策略引擎的设计
策略引擎是整个系统的核心模块,如图3所示为策略引擎的结构。
策略引擎可以加载两种格式的策略,或者说策略可以用两种不同的方式实现,一种是使用C++编码的C++类,一种是使用策略脚本文件。
虽然实现的方式不同,但策略引擎以同样的方式调度。
C++的效率高,而脚本驱动的策略修改和编写都十分方便。
这种体系结构可以方便的把策略不同的实现方式扩充进来。
策略引擎的初始化过程为:
读取策略的属性列表,根据属性列表加载策略。
初始化完成后就可以等待客户端发出访问服务器的请求,为客户端的访问进行策略调度。
下面就将介绍策略的属性及策略的加载和调度的过程。
3.4.1 策略的属性
策略的属性可以帮助策略引擎选择合适的策略加载器加载策略和策略引擎按合适的方式调度策略。
(1) 策略的名称
用来标示不同的策略,在加载过程中,C++加载器通过此名称生成C++策略的对象。
在属性列表中这一条不能省略。
(2) 描述
描述策略的功能。
可以省略。
(3) 类型
按类型可以把策略分为系统策略和用户策略。
系统策略永远都是在用户策略前面调度。
这两种不同类别的策略都可以由C++的类或者以脚本的方式实现。
此属性的作用是在增加策略优先级调度的粒度。
可以在配置文件中设置此值
(4) 加载器
表示策略该有什么样的加载器加载,加载器会将该策略转换成策略引擎能够调度的策略对象。
(5) 开启状态
可以给策略的设置开启状态:
Enable和Disable,当一个策略处于Disable状态时,策略引擎会跳过对其的加载。
(6) 加载状态
策略的加载状态:
Unloaded/Loaded,当策略的加载状态不处于Loaded时,策略引擎不对其进行调度。
这个值不能在配置文件中设置,默认为Unloaded,当策略引擎成功加载此策略时,会将此值设置为Loaded。
(7) 优先级
通过优先级可以控制策略调度的顺序,优先级得X围是:
0-255,值越低的优先级越高。
(8) 路径
记录策略脚本的位置,加载时通过这个属性找到相应的策略文件的路径。
这个属性只对脚本加载器有效。
3.4.2 策略的加载
策略引擎加载策略的步骤如下:
(1) IPS通过配置模块读取出策略属性列表,去掉此列表中策略名称重复的项,然后将此列表作为策略引擎初始化的参数或者作为策略引擎重新加载的参数。
(2) 策略引擎将由此列表中策略类型属性和优先级属性,由系统策略到用户策略,从高优先级策略到低优先级的策略的次序,进行排序。
形成一个新的策略列表。
(3) 按后面的步骤依次加载这个策略列表中的属性。
(4) 如果策略的开启状态属性不为Enable,则跳过该策略,继续加载策略列表中后面的策略。
(5) 如果加载器的属性为C++则交由C++的策略加载器处理,如果是为脚本的就由相应的脚本加载器处理。
如果不能识别则跳过该策略。
C++的加载器为一个策略对象的工厂类,会根据策略的名称生成不同的策略对象,如果找不到为该名称的策略则返回NULL表示加载失败。
脚本加载器会根据属性中的路径字段去读取策略脚本,加载器要完成策略脚本语法检测的步骤,加载成功时也是返回一个策略对象,加载失败返回NULL。
如上所述,加载器会将策略对象的初始化(C++对象是通过调用构造函数来实现)。
所以在策略的调度前不需要再对策略做初始化。
(6) 加载成功后就将该策略的状态属性置为Loaded,如果是加载失败就保持该选项为Unload。
(7) 直到策略列表中的所有项都处理结束后,重新遍历这个列表,把Loaded的项依次提取出来,形成策略调度用的策略列表。
3.4.3
- 配套讲稿:
如PPT文件的首页显示word图标,表示该PPT已包含配套word讲稿。双击word图标可打开word文档。
- 特殊限制:
部分文档作品中含有的国旗、国徽等图片,仅作为作品整体效果示例展示,禁止商用。设计者仅对作品中独创性部分享有著作权。
- 关 键 词:
- 基于 Web 入侵 防御 系统 设计 实现
![提示](https://static.bdocx.com/images/bang_tan.gif)