学习笔记:WEB安全防护

WEB基础

• Internet采用超文本和超媒体的组合方式,将信息的链接扩展至整个Internet上。Web就是一种超文本信息系统,它使得文本不再固定在某一个位置,而是可以从一个位置跳转到另外的位置,正是这种多链接性,才把它称为Web。

• WEB攻击来源
客户端:网站木马;钓鱼欺骗;活动内容攻击
服务端:web服务器的漏洞;授权、认证攻击;跨站脚本攻击;SQL注入
通信通道:DoS、CC攻击;窃听;SSL重定向

HTTP工作流程:

1、客户机(浏览器)主动向服务器(web server)发出连接请求。
2、服务器接受连接请求并建立起连接。(1,2步即我们所熟知的TCP三次握手)
3、客户机通过此连接向服务器发出GET等http命令(HTTP请求报文)。
4、服务器接到命令并根据命令向客户机传送相应的数据(HTTP响应报文),有些内容需要认证(用户名密码)。
5、客户机接收从服务器送过来的数据。
6、服务器发送完数据后,主动关闭此次连接(TCP四次分手)

HTTP报文请求

在这里插入图片描述
• 请求行由请求方法字段、URL字段和HTTP协议版本字段3个字段组成,它们用空格分隔。 例如,GET /index.html HTTP/1.1。
HTTP协议的请求方法有GET、POST、HEAD、PUT、DELETE、OPTIONS、TRACE、CONNECT。
o GET:读取由URL所标识的信息。
o OPTION:请求一些选项的信息,返回服务器针对特定资源所支持的HTTP请求方法,也可以利用向web服务器发送‘*’的请求来测试服务器的功能性。
o HEAD:请求读取URL所标识信息的首部。类似于 GET 请求,只不过返回的响应中没有具体的内容,用于获取报头
o POST:给服务器添加信息。 向指定资源提交数据进行处理请求(例如提交表单或者上传文件)。数据被包含在请求体中。
o PUT:在指明的URL下存储一个文档。
o DELETE:删除指明的URL所标志的资源。
o TRACE:用来进行环回测试的请求报文。
o CONNECTHTTP:用于代理服务器。
• 通过GET提交数据,用户名和密码将明文出现在URL上,而登录页面有可能被浏览器缓存, 其他人也可以查看浏览器的历史纪录,那么别人就可以拿到你的账号和密码了。

• HTTP请求头部由关键字/值对组成,每行一对,关键字和值用英文冒号“:”分隔。请求头部通知服务器有关于客户端请求的信息,典型的请求头有:
• User-Agent:产生请求的浏览器类型。
• Accept:请求报头域用于指定客户端接受哪些类型的信息。
• Referer:上一个资源的URL。
• Connection:当值为Close时,告诉服务器发送响应的文件后关闭连接,为Keep-Alive时,告诉服务器在完成本次请求的响应后,保持连接。
• Host:主要用于指定被请求资源的Internet主机和端口号,它通常从URL中提取出来的,eg: www.google.cn 。此处使用缺省端口号80,若指定了端口号,则变成:Host: www.google.cn:指定端口号。

• 最后一个请求头之后是一个空行,发送回车符和换行符,通知服务器以下不再有请求头。
• 请求数据不在GET方法中使用,而是在POST方法中使用。POST方法适用于需要客户填写表单的场合。与请求数据相关的最常使用的请求头是Content-Type(客户端告诉服务器实际发送的数据类型)和Content-Length(HTTP消息实体的传输长度)。

HTTP响应报文

在这里插入图片描述
• 所有 HTTP 响应的第一行都是状态行,依次是当前HTTP版本号,3位数字组成的状态代码,以及描述状态的短语,彼此由空格分隔。格式为:HTTP-Version Status-Code Reason-Phrase CRLF。
例如:HTTP/1.1 200 OK 。其中HTTP-Version表示服务器HTTP协议的版本;Status-Code表示服务器发回的响应状态代码;

Reason-Phrase表示状态代码的描述。状态代码由三位数字组成,第一个数字定义了响应的类别,且有五种可能取值。
• 1xx:信息–表示请求已接收,继续处理。
• 2xx:成功–表示请求已被成功接收、理解、接受。如:200 OK,请求成功。
• 3xx:重定向–要完成请求必须进行更进一步的操作。
• 4xx:请求错误–请求有语法错误或请求无法实现。如:400 Bad Request,客户端请求有语法错误,不能被服务所理解;403 Forbidden,服务器收到请求,但是拒绝提供服务;404 Not Found,请求资源不存在。
• 5xx:服务器端错误–服务器未能实现合法的请求。如:503 Server Unavailable,服务器当前不能处理客户端的请求。

• 首部行由关键字/值对组成,每行一对,关键字和值用英文冒号“:”分隔,每一行结束的地方都要有CRLF。包含了服务器和报文主题的信息。例如:
• Server:告诉浏览器服务器的名称和版本号。如:Apache/2.2.10。
• Content-Type:实体报头域用语指明发送给接收者的消息主体的媒体类型。如:Content-Type:text/html。

• 最后一个请求头之后是一个空行,发送回车符和换行符,通知客服端以下是报文实体。
• HTTP响应报文实例:
HTTP/1.1 200 OK\r\n {状态行,表示请求成功,信息可以读取,包含在响应的报文中}
Date: Fri, 11 Sep 2009 05:58:46 GMT\r\n {发送该响应报文的日期和时间}
Server: Apache\r\n {报文是由一个Apache的服务器产的 }
Content-Length: 570 {表明实体的长度}
Connection: Keep-Alive\r\n {告诉客户端在报文发送后仍然保持连接}
Content-Type: application/x-javascript\r\n {说明实体中的对象类型}
\r\n {CRLF}

Cookie和Session

• Cookie是一种在客户端保持HTTP状态信息的技术,由Web服务器在HTTP响应消息头中附带传送给浏览器的一片数据,web服务器传送给各个客户端浏览器的数据是可以各不相同的。浏览器可以决定是否保存这片数据,一旦Web浏览器保存了这片数据,那么它在以后每次访问该Web服务器时,都应在HTTP请求头中将这片数据回传给Web服务器。
• 会话cookie:不设置过期时间,则表示这个cookie生命周期为浏览器会话期间,只要关闭浏览器窗口,cookie就消失了。这种生命期为浏览会话期的cookie被称为会话cookie。会话cookie一般不保存在硬盘上而是保存在内存里。
• 永久cookie:设置了过期时间,浏览器就会把cookie保存到硬盘上,关闭后再次打开浏览器,这些cookie依然有效直到超过设定的过期时间。存储在硬盘上的cookie可以在不同的浏览器进程间共享,比如两个IE窗口。而对于保存在内存的cookie,不同的浏览器有不同的处理方式。

• Session在网络应用中称为会话,它是由应用服务器维持的一个服务器端的存储空间,用户在连接服务器时,会由服务器生成一个唯一的SessionID,用该SessionID为标识符来存取服务器端的Session存储空间。
在这里插入图片描述
• 用户请求使用Session页面时,Web服务器产生Session和一个Session-id并返回临时Cookie(Key=sessionid),用户第二次请求Session页面会自动带上Cookie信息,Web服务器接收请求并通过Sessionid读取Session,把信息返回用户。SessionID是保存到客户端,用Cookie保存的,用户提交页面时,会将这一SessionID提交到服务器端,来存取Session数据。一旦客户端禁用Cookie,那么Session也会失效。
• Cookie是保存在客户端的,这导致了Cookie的不可靠性。而Session虽然保存在服务器端,但由于用户会获得Session的一个标记,称为Sessionid,这个id是用Cookie保存的,这导致了Session的不安全性。同时通过一些抓包工具也可以达到盗用Session的目的。为了提高Session的安全性和Cookie的可靠性,我们可以对给它们设置过期,增加签名内容,同时也可以限制用户IP。

WEB攻击浅析

OWASP Top 10 应用安全风险–2017
A1 –注入
A2 –失效的身份认证和会话管理
A3 –跨站脚本(XSS)
A4 –失效的访问控制
A5 –安全配置错误
A6 –敏感信息泄露
A7 –攻击检测与防护不足
A8 –跨站请求伪造(CSRF)
A9 –使用含有已知漏洞的组件
A10 –未受有效保护的API
• WEB风险大部分是由于加密、防护不足以及访问控制薄弱所引起的。注入、跨站脚本以及跨站请求伪造作为Web攻击中常见的方式。
• 开源Web应用安全项目(OWASP,Open Web Application Security Project)是一个开放的社区,致力于帮助各企业组织开发、购买和维护可信任的应用程序。Top 10项目的目标,是通过识别出企业组织所面对最严重的风险来提高人们对应用程序安全的意识。
• 在最新的2017版本中,相较于2013版本,OWASP首次添加了两类新的风险:(1)“攻击检测与防护不足”;(2)“未受有效保护的API”。应用程序和API的威胁情况不断变化。这一演变的关键因素是新技术(包括云、容器和API)的快速采用、软件开发过程(如敏捷软件开发和DevOps)的加速和自动化、第三方库和框架的爆炸式增长,以及攻击者在攻击方面取得的进展。这些因素常常导致应用程序和API更加难以分析,而且也会显著改变威胁环境。

• A1 –注入
注入攻击漏洞,例如SQL,OS以及LDAP注入。这些攻击发生在当不可信的数据作为命令或者查询语句的一部分,被发送给解释器的时候。攻击者发送的恶意数据可以欺骗解释器,以执行计划外的命令或者在未被恰当授权时访问数据。

• A2 –失效的身份认证和会话管理
与身份认证和会话管理相关的应用程序功能往往得不到正确的实现,这就导致了攻击者破坏密码、密钥、会话令牌或攻击其他的漏洞去冒充其他用户的身份(暂时或永久的)。

• A3 –跨站脚本(XSS)
当应用程序收到含有不可信的数据,在没有进行适当的验证和转义的情况下,就将它发送给一个网页浏览器,或者使用可以创建javaScript脚本的浏览器API利用用户提供的数据更新现有网页,这就会产生跨站脚本攻击。XSS允许攻击者在受害者的浏览器上执行脚本,从而劫持用户会话、危害网站或者将用户重定向到恶意网站。

• A4 –失效的访问控制
对于通过认证的用户所能够执行的操作,缺乏有效的限制。攻击者就可以利用这些缺陷来访问未经授权的功能和/或数据,例如访问其他用户的账户,查看敏感文件,修改其他用户的数据,更改访问权限等。

• A5 –安全配置错误
好的安全需要对应用程序、框架、应用程序服务器、web服务器、数据库服务器和平台定义和执行安全配置。由于许多设置的默认值并不是安全的,因此,必须定义、实施和维护这些设置。此外,所有的软件应该保持及时更新。

• A6 –敏感信息泄露
许多web应用程序和API没有正确保护敏感数据,如财务、医疗保健和PII。攻击者可能会窃取或篡改此类弱保护的数据,进行信用卡欺骗、身份窃取或其他犯罪行为。敏感数据应该具有额外的保护,例如在存放或在传输过程中的加密,以及与浏览器交换时进行特殊的预防措施。

• A7 –攻击检测与防护不足
大多数应用和API缺乏检测、预防和响应手动或自动化阻断攻击的能力。攻击保护措施不限于基本输入验证,还应具备自动检测、记录和响应,甚至阻止攻击的能力。应用所有者还应能够快速部署安全补丁以防御攻击。

• A8 –跨站请求伪造(CSRF)
一个跨站请求伪造攻击迫使登录用户的浏览器将伪造的HTTP请求,包括受害者的会话cookie和所有其他自动填充的身份认证信息,发送到一个存在漏洞的web应用程序。这种攻击允许攻击迫使受害者的浏览器生成让存在漏洞的应用程序认为是受害者的合法请求的请求。挟制用户在当前已登录的Web应用程序上执行非本意的操作的攻击方法。

• A9 –使用含有已知漏洞的组件
组件,比如:库文件、框架和其他软件模块,具有与应用程序相同的权限。如果一个带有漏洞的组件被利用,这种攻击可以促成严重的数据丢失或服务器接管。应用程序和API使用带有已知漏洞的组件可能会破坏应用程序的防御系统,并使一系列可能的攻击和影响成为可能。挟制用户在当前已登录的Web应用程序上执行非本意的操作的攻击方法

• A10 –未受有效保护的API
现代应用程序通常涉及丰富的客户端应用程序和API(应用程序接口:Application Programming Interface),又称为应用编程接口,是软件系统不同组成部分衔接的约定。由于近年来软件的规模日益庞大,常常需要把复杂的系统划分成小的组成部分,编程接口的设计十分重要。程序设计的实践中,编程接口的设计首先要使软件系统的职责得到合理划分。良好的接口设计可以降低系统各部分的相互依赖,提高组成单元的内聚性,降低组成单元间的耦合程度,从而提高系统的维护性和扩展性。,如:浏览器和移动APP中的JavaScript,其与某类API(SOAP/XML、REST/JSON、RPC、GWT等)连接。这些API通常是不受保护的,并且包含许多漏洞。

sql的防范方法

对于SQL注入的防范,可以采用以下一些加固方法:
• 独立、完整且集中的输入验证;
• 使用安全的API;
• 避免连接字符串最终传递给解释器; 链接字符将两个变量或者字符串连接到一起
• 严格检查用户输入,注意特殊字符:“’”“;”“[”“—”||”“xp_”等;
• 转义用户输入内容;
• 拒绝已经经过转义的输入;
• 使用参数化的查询;
• 使用SQL存储过程;
• 最小化SQL权限(禁用SA帐号);
• 防止错误页面信息泄露;
• 定期检测网站的安全漏洞,及时修复漏洞。

XSS分类

• XSS起初的危害主要是盗取用户的Cookie信息。Cookie信息中包含了浏览者和网站服务器之间的常用记录,包括登录记录、浏览记录等。如果攻击者得到了用户的Cookie信息,可以模仿用户和网站进行交互,得到更多想要的数据。跨站脚本简称为CSS(Cross Site Scripting),因为容易和另一个名词“层叠样式表”(Cascading Style Sheets,CSS)混淆,为了区别,网络安全人士习惯将其简称为XSS攻击。
• 反射型
跨站代码一般存在于链接中,请求这样的链接时,跨站代码经过服务端反射回来,这类跨站的代码一般不存储到服务端。
黑客先将含有XSS代码的恶意链接邮件发送给目标用户,用户打开后,会访问链接对应的服务器,服务器收到链接请求时,会将带有的XSS代码的数据再次发送给用户,此时用户浏览器就会默认执行带有XSS代码的脚本,此时会触发XSS漏洞,不过在这个过程中,黑客先确认发给某个服务器,服务器会给黑客返回发送的数据

• 存储型
这是利用起来最方便的跨站类型,跨站代码存储于服务端(比如数据库中)。
攻击脚本会被永久的保存在目标服务器的数据库或者文件中(黑客会在某论坛进行留言,此时论坛对应的服务器会将黑客的留言保存在服务器,但是留言的内容有XSS恶意代码攻击,当其他用户访问此留言回帖时,浏览器就会执行XSS恶意代码)

跨站脚本攻击的危害:
• 钓鱼欺骗:最典型的就是利用目标网站的反射型跨站脚本漏洞将目标网站重定向到钓鱼网站,或者注入钓鱼JavaScript以监控目标网站的表单输入,甚至发起基于DHTML更高级的钓鱼攻击方式。
• 网站挂马:跨站时利用IFrame嵌入隐藏的恶意网站或者将被攻击者定向到恶意网站上,或者弹出恶意网站窗口等方式都可以进行挂马攻击。
• 身份盗用:Cookie是用户对于特定网站的身份验证标志,XSS可以盗取到用户的Cookie,从而利用该Cookie盗取用户对该网站的操作权限。如果一个网站管理员用户Cookie被窃取,将会对网站引发巨大的危害。
• 盗取网站用户信息:当能够窃取到用户Cookie从而获取到用户身份使,攻击者可以获取到用户对网站的操作权限,从而查看用户隐私信息。
• 垃圾信息发送:比如在SNS社区中,利用XSS漏洞借用被攻击者的身份发送大量的垃圾信息给特定的目标群。
• 劫持用户Web行为:一些高级的XSS攻击甚至可以劫持用户的Web行为,监视用户的浏览历史,发送与接收的数据等等。
• XSS蠕虫:XSS 蠕虫可以用来打广告、刷流量、挂马、恶作剧、破坏网上数据、实施DDoS攻击等。

跨站请求伪造CSRF

• 银行网站A,它以GET请求来完成银行转账的操作,如:http://www.mybank.com/Transfer.php?toBankId=11&money=1000
• 危险网站B,它里面有一段HTML的代码如下:<img src=http://www.mybank.com/Transfer.php?toBankId=11&money=1000>
• 首先,你登录了银行网站A,然后访问危险网站B,这时你会发现你的银行账户少了1000块…
• 银行网站A违反了HTTP规范,使用GET请求更新资源。在访问危险网站B的之前,你已经登录了银行网站A,而B中的以GET的方式请求第三方资源(这里的第三方就是指银行网站了,原本这是一个合法的请求,但这里被不法分子利用了),所以你的浏览器会带上你的银行网站A的Cookie发出Get请求,去获取资源“http://www.mybank.com/Transfer.php?toBankId=11&money=1000”,结果银行网站服务器收到请求后,认为这是一个更新资源操作(转账操作),所以就立刻进行转账操作。

URL过滤

URL格式:protocol://hostname[:port]/path[?query]
• protocol:最常使用的是HTTP协议。对于HTTP协议,一般可不输入;
• hostname:WEB服务器的DNS主机名或IP地址;
• port:可选,通信端口。各种传输协议都有默认的端口号;
• ?query:可选,用于给动态网页传递参数。

网关设备URL过滤的原理:
• 截取用户HTTP连接Get或POST请求,根据用户配置策略判断其合法性;
• 如果URL合法,则该HTTP请求被放行,用户可以浏览网站;
• 如果URL不合法,则对该HTTP连接进行告警页面推送并且阻断。
• 根据自定义分类或者预定义分类,用户可以创建多个URL配置文件。每个URL配置文件定义了分类的处理动作。

URL匹配

在这里插入图片描述
• 管理员可以在白名单、黑名单、自定义分类和预定义分类中配置URL规则和域名规则,其中URL规则的匹配范围是全部URL,域名规则的匹配范围只是域名(或者IP地址)部分。

• URL进行匹配时,不同的匹配方式存在优先级顺序,由高至低为:精确匹配 > 后缀匹配 > 前缀匹配 > 关键字匹配。
• 在同一种匹配方式下,匹配规则越长优先级越高。
• 在同一种匹配方式下,如果匹配规则长度也相同,则最终以配置的动作模式为准。如上图表格所示,两个条目均属于“关键字匹配”方式,且匹配规则长度相同均为4。根据动作模式进行匹配:
当动作模式为“严格模式”时,则最终查询结果以动作最为严格的URL分类为准,本例中为URL分类B,动作为阻断。
当动作模式为“松散模式”时,则最终查询结果以动作最为宽松的URL分类为准,本例中为URL分类A,动作为允许。
在这里插入图片描述

恶意URL检测

• 恶意URL来源
• 沙箱联动场景沙箱检测到恶意URL
• AV检测到的带恶意文件的URL
• 低信誉URL
• 恶意URL检测控制
• URL配置文件的恶意URL检测开关开启时依次检测上述恶意URL。

WEB信誉

• 大型正规网站一般拥有较好的安全意识和优良的网络安全防护能力,所以网站被侵入的可能性较小,网站上也几乎不存在恶意文件,用户访问此类网站时的风险很小。相反,随意搭建的小网站或者恶意网站上充斥着大量的恶意文件,用户访问此类网站时的风险也极大。
• Web信誉用于描述网站的可信程度,信誉度高的网站上文件的安全性也高。URL信誉反映了用户访问的URL是否值得信赖。利用远程查询服务获取URL的信誉值,并对低信誉的URL实施阻断。
• Web信誉功能对网站进行了分类,FW会根据不同分类进行差异化处理。对于信誉度低的网站,FW会提取出网络流量中的文件,然后送往沙箱进行进一步的检测;对于信誉度高的网站,FW不会提取网络流量中的文件,即跳过了沙箱检测的步骤。这样处理可以提高FW的检测效率,在不降低安全性的同时,提升用户的访问体验。

在这里插入图片描述
网站A是信誉高,网站B信誉低。
• FW开启APT防御功能后,如果流量命中了APT防御配置文件中的匹配条件,FW会提取出网络流量中的文件,然后送往沙箱进行进一步的检测。由于FW提取文件会消耗一定的设备性能,且送往沙箱的文件数量过多也会影响沙箱设备的检测性能,所以需要利用Web信誉功能控制对哪些流量进行文件提取。

根据信誉分类

按照不同的信誉度,Web信誉功能将网站分为4类:
• 预定义可信网站
系统默认可信的网站即为预定义可信网站。设备出厂时默认带有一个Web信誉预置库,包含的内容即为预定义可信网站列表。FW仅支持通过Web界面查询某个网站是否为预定义可信网站,且Web信誉预置库中的内容不可更改。

• 自定义可疑网站
当某个网站的信誉度很低时,管理员可以手工将其添加到自定义可疑网站列表中。系统认定自定义可疑网站列表中的网站均为不可信的,所以相应流量命中APT防御配置文件中的匹配条件后,FW会提取出网络流量中的文件,然后送往沙箱进行进一步的检测。

• 自定义可信网站
当某个网站的信誉度很高时,如果它不在预定义可信网站列表中,管理员可以手工将其添加到自定义可信网站列表中。系统认定自定义可信网站列表中的网站均为可信的,即使相应流量命中了APT防御配置文件中的匹配条件,FW也不会提取网络流量中的文件。

• 未知网站
当某个网站不在预定义可信网站、自定义可疑网站或自定义可信网站列表中时,系统认定此网站为未知网站。管理员可以手工将其添加到自定义可疑网站或自定义可信网站列表中。命中配置文件时,会被送往沙箱检测
在这里插入图片描述
• 用户发起URL访问请求后,如果流量命中了APT防御配置文件中的匹配条件,则系统将从流量中提取出域名信息,并开始进行Web信誉处理流程。host字段可以为域名或IP地址形式。
• FW将域名与自定义可疑网站进行匹配。
• 如果匹配自定义可疑网站,则FW会提取出网络流量中的文件,然后送往沙箱进行进一步的检测。

• 如果未匹配自定义可疑网站,则进行下一步检测。
• 当管理员认定某个预定义可信网站实际上为不可信网站时,虽然不能更改Web信誉预置库中的内容,但是可以将此不可信网站添加到自定义可疑网站列表中。由于自定义可疑网站的匹配顺序优先于预定义可信网站,所以最终的匹配结果显示为可疑网站。

• FW将域名与自定义可信网站进行匹配。
• 如果匹配自定义可信网站,则FW不会提取网络流量中的文件,即跳过了沙箱检测的步骤,继续进行其他检测流程。
• 如果未匹配自定义可信网站,则进行下一步检测。

• FW将域名与预定义可信网站进行匹配。
• 如果匹配预定义可信网站,则FW不会提取网络流量中的文件,即跳过了沙箱检测的步骤,继续进行其他检测流程。

• 如果未匹配预定义可信网站,则FW认定该网站为未知网站。FW会提取出网络流量中的文件,然后送往沙箱进行进一步的检测。

WEB应用系统防护

• WAF专门针对Web应用攻击,是通过执行一系列针对HTTP/HTTPS的安全策略来专门为Web应用提供保护的一款产品。WAF可以通过规则对HTTP报文中每一个字段进行过滤。
在这里插入图片描述
• 执行前端是WAF的执行引擎, 主要是根据规则匹配的结果,执行相应的动作。
• 后端中心系统主要是生成规则的逻辑。
• 数据库就是存放规则和一些配置及状态的地方。

处理架构在这里插入图片描述

纵深安全防护

• 细粒度分析,对于HTTP慢攻击或包分片攻击,可对协议完整重组后识别攻击。
在这里插入图片描述
黑名单特征检测
• 黑名单特征检测技术通过特征库匹配技术实现安全防护,首先WAF的双向检测模块对WEB用户提交的请求信息和服务器的响应信息进行解析,如有特殊编码的需要先将编码进行转换,解析完成后对报文匹配特征库,对匹配特征库的报文采用阻断、放行、仅检测、重定向等动作。
协议重组检测
• 在以往IPS设备检测模式下,IPS只对攻击的第一个数据包进行匹配特征库,黑客通常会使用HTTP慢攻击或包分片攻击绕过IPS检测,WAF可将数据包的所有分片进行缓存后再检测。

DDoS/CC防护技术
• CC攻击是指利用大量代理服务器对目标计算机发起大量连接,导致目标服务器资源枯竭造成拒绝服务,是DDos的一种类型,针对WEB服务器。首先攻击者寻找比较耗费服务器资源的页面,然后使用代理将CC攻击转发到服务器,由于服务器接收到大量CC攻击,而造成服务服务器资源枯竭,从而造成拒绝服务。
• CC攻击防护基于用户单位时间内发起请求的页面和请求数进行统计,当WAF发现单个客户端在一定时间内发起非正常页面请求次数,将该客户端锁定至黑名单中一定时间,从而达到CC攻击的防御。

自学习建模及白名单防护技术

• WAF使用黑名单特征库防护攻击时,黑名单相较于攻击手段是落后的,而且在增加特征库后也会带来性能的损耗。自学习建模及白名单防护技术应运而生。
• 策略自学习建模及白名单防护技术通过对访问流量的自学习和概率统计算法实现自动生成策略规则,同时对网站的正常访问行为规律进行分析及总结,生成一套针对网站特性的安全白名单规则,用户访问时WAF对合法输入直接放行,对不合法输入直接拦截,而不需要再匹配多条黑名单特征库,影响检测效率及准确率。

高性能检测技术

• 用户访问WEB应用时会调用大量图片、css样式、js脚本等静态文件,而这部分文件通常不具备攻击条件,WAF具备高性能模块对静态文件进行高速转发,无需通过大量的特征库检测,从而提升了网站访问性能。而文件类型为asp、jsp或php等动态文件则需要规则检测模块进行过滤后再转发到WEB应用服务器。

防篡改技术

• WAF防篡改基于缓存模块,首先启动学习模式对用户访问网站的页面内容进行学习,学习完成后将页面内容存储在缓存中,当服务器页面发生篡改并有用户访问该页面时,WAF首先会获取服务器的页面内容,并和缓存中的页面内容进行水印比对,当发现页面篡改时WAF则使用缓存中的页面返回给客户端,达到视觉防篡改。

自动侦测应用技术

• 通常情况下需要手工指定WAF需要防护哪些WEB应用,当有大量的网站群需要防护时,或者具有复杂的域名对应关系时通常难以手工对服务进行确认。另一方面数据中心的WEB服务可能随着业务的增加而不断有新的服务开启,此时我们的安全管理员可能并未被告知,因此WEB服务的监测与自动发现有助于WEB应用的安全管理。
• 站点自动侦测可对经过WAF的流量自动学习,从混杂流量中学习WEB协议信息,从而获取WEB服务器IP、TCP端口、域名等信息,对需要防护的WEB应用服务器按需添加至WAF的保护站点中。

高速缓存技术

• 用户访问WEB应用时会调用大量图片、css样式、js脚本等静态文件,网站访问流量一般为“二八原则”,动态文件流量为20%,静态文件流量为80%,静态文件通常不会频繁更新。WAF将用户访问过的静态文件(如jpg、gif、html等文件)缓存到物理内存中,当另一用户也访问静态文件时,WAF将直接返回给用户,而无需再转发到服务器,从而可以节省服务器的性能开销。

WAF部署模式

• 透明代理模式是指WAF使用直连部署模式时,无需对现有环境进行改动即可实现部署。
• 反向代理模式是指WAF在旁路模式部署可实现防护功能,部署时只需将网站的域名或抢占服务器IP方式,访问时先访问到WAF,WAF检测后再将流量转发给服务器。
• 网关模式是指WAF可实现对多台服务器流量负载均衡,部署时需要将服务器网关映射到WAF。

在透明代理模式中,客户端不直接与服务器建立连接,可实现对服务器隐藏。不需要网络层、应用层做任何的改变,也不需要在任何设备上做任何的变动并且数据包转发时不改变其内容。几乎适用于所有网站。
在这里插入图片描述
如上图所示的透明代理模式中,当用户访问网站服务器时,WAF协议栈网络层判断目标IP是否为防护服务器IP,再由传输层判断目标端口是否为防护服务器TCP端口,当匹配双因素后,记录该数据包的源IP、源MAC、目标IP、目标MAC等数据链路层信息,并将流量牵引至WAF高性能检测模块,由WAF高性能检测模块过滤静态文件后,再将有风险的文件类型转交给自学习白名单->CC检测->黑名单特征库模块陆续进行规则检测,检测无异常后转交给应用交付模块转发到后端服务器,同理服务器返回的流量也需要经过这一过程

发布了10 篇原创文章 · 获赞 8 · 访问量 1431

猜你喜欢

转载自blog.csdn.net/TKE_yinian/article/details/104807581