WAF和RASP技术，RASP与WAF的“相爱相杀”
原创WAF和RASP技术，RASP与WAF的“相爱相杀”
原创
WAF和RASP技术，RASP与WAF的“相爱相杀”
WAF
WAF全称叫Web Application Firewall，也就是web应用防火墙，和传统防火墙的区别是，它是工作在应用层的防火墙，主要针对web请求和响应进行检测和防护。
WAF分为非嵌入型WAF和嵌入型WAF，非嵌入型指的是硬WAF、云WAF、虚拟机WAF之类的；嵌入型指的是web容器模块类型WAF、代码层WAF。
WAF工作原理
WAF工作方式是对接收到的数据包进行正则匹配过滤，如果正则匹配到与现有漏洞知识库的攻击代码相同，则认为这个恶意代码，从而对于进行阻断。所以，对于基于规则匹配的WAF，需要每天都及时更新最新的漏洞库。
WAF工作过程
1. 解析HTTP请求
对接收到数据请求流量时会先判断是否为HTTP/HTTPS请求，之后会查看此URL请求是否在白名单之内，如果该URL请求在白名单列表里，直接交给后端Web服务器进行响应处理，对于不在白名单之内的对数据包解析后进入到规则检测部分。
2. 匹配规则
解析后的数据包会进入到检测体系中进行规则匹配，检查该数据请求是否符合规则，识别出恶意攻击行为。
3. 防御动作
如果符合规则则交给后端Web服务器进行响应处理，对于不符合规则的请求会执行相关的阻断、记录、告警处理。
不同的WAF产品会自定义不同的拦截警告页面，在日常渗透中我们也可以根据不同的拦截页面来辨别出网站使用了哪款WAF产品，从而有目的性的进行WAF绕过。
4. 记录日志
WAF工作模式
由于WAF一般和业务系统是串联的，并且还是部署在业务系统前面。如果采用反向代理部署模式，假设WAF出现故障，那么会导致单个或者多个站点不可用。这意味着WAF的功能必须是随时可以关闭的。一个WAF往往需要同时防护多个站点，如果把整个WAF关闭，是会导致整体业务群都失去保护。所以，WAF的工作模式必须有对站点随时关闭的模式。
当WAF有新功能或者有新策略发布，是不可以立马把新功能或新策略对现有站点进行防护，需要一段时间来进行观察，看功能是否可用或策略的命中率，漏判率和误判率。如果贸然上线的话，很容易背锅走人的。所以，WAF的工作模式必须有监听模式。
关闭模式
先从关闭模式看起，对某个站点使用关闭模式，到这个站点的流量就感受不到WAF的存在。一般的做法，是解绑域名，再到web服务上绑定该域名。
这种模式的优点是
- 由于web服务和WAF完全分享，WAF的故障不会影响到web服务。
- 少了WAF这个中间节点，web服务的响应速度不受影响。
缺点是
- 解绑和重绑，涉及到接入备案过程，流程较长，生效时间较长。
- 原先隐藏在内网的web服务集群对公网开放，除了web应用本身的攻击面，还增加了主机层面的攻击面，增大了整体网络的攻击面。
监听和保护模式
监听模式：既过规则，也会直接传递给web服务。
防护模式：直接过规则，不会直接传递给web服务
这两种方式的优点是
- 不需要进行域名解绑和重绑，生效时间快
- 不会增加整体网络的攻击面
缺点是
- 流量还是要经过WAF，对web服务响应速度还是影响
- 流量要经过WAF，所以WAF的故障也会影响到web服务
由于一个IP可以对应多个域名，一个域名也可以对应多个IP，对针对每个域名来配置工作模式，WAF必须要获取到http请求的URL或头部的host字段。WAF解析完http/https，拿到了请求的域名，再根据域名的配置，决定是否送去过规则还是直接传递给web服务。所以，WAF的http/https模块解析要和规则引擎模块分开，也就是上述流程图的效果。
WAF规则引擎原理
WAF无非就是拦截有害请求和伪装响应，出于性能考虑，拦截有害请求又分为两个层面，由网络层拦截和由应用层拦截，且任何请求应该先在网络层过滤再到应用层过滤。也就是说，规则引擎分为两块，对请求过滤和对响应过滤，而对请求过滤分为两大步，网络层过滤和应用层过滤。
请求部分
网络层
- 白名单：很多时候部署在WAF后面的应用，需要测试接口对非法输入的处理，但又不想关闭对该站点的监控，为了防止WAF对测试活动的影响，对来源IP和目标IP设置白名单，绕过WAF的拦截。从性能角度来考虑，白名单过滤功能是不可能放在其它过滤功能后面，那么它应该是规则引擎在网络层过滤的第一步。
- 黑名单：同样，对于已知有害的来源IP，是越早拦截越好，出于性能考虑，黑名单拦截功能应该在网络层，那么它应该紧跟在白名单后面。
应用层
- https拆解：随着https越来越普及，WAF需要对https请求和响应进行检测和过滤，所以，WAF必须支持使用证书对https内容进行拆解。
- http方法防护：不少http方法是有安全风险的，如果webserver的配置有问题，如果不在这一步拦截掉，而url白名单的来源IP又可能被攻击，那么就可以存在站点沦陷的风险。一般是拦截除了HEAD，GET，POST之外的方法
- url白名单：由于某些接口（如请求某些静态资源）并不会存在漏洞，没必要对这些url进行规则过滤，或者防护站点某些url接口有所更新，需要特定的来源IP进行测试。应当存在url和来源IP对应的白名单
- url黑名单：同样由于某些接口的实现可能会涉及大量运算，可能需要对该url访问进行次数限制，需要存在一个url和次数的黑名单。
- http请求解码：http请求很多时候对头部和内容的数据往往会进行编码，如url编码，html编码，js编码，十六制编码，base64编码，主要是为了传输一些二进制数据，或攻击者用于绕过各种防护设备。只有对数据进行解码，才能够知道它真实的payload。所以需要对http请求进行解码。
- http请求头部过规则：GET，HEAD方法的参数都是紧跟URL，这个阶段就可以进行过滤，而且先对请求头部过滤，也是基于性能考虑。毕竟请求url参数和头部都是key-value方式，解析相对比内容要快。
- http请求内容过规则：POST方法的参数基本都是放在请求内容里。
响应部分
- 响应头部过规则：响应头部有不少字段会泄露背后服务的关键信息，如server会泄露webserver软件及版本，x-powered-by会泄露cgi语言和版本（PHP，Python,Perl,Ruby之类），Via和Max-Forward会泄露WebServer的拓扑。为了避免攻击者利用这些信息攻击，需要对响应头部某些字段进行屏蔽或伪装。
- 响应内容过规则：这一部分也叫做软补丁功能。为什么呢？如果webserver的应用服务抛异常了，并把异常信息显示在页面，这是一种常见的信息泄露。如果需要研发团队来修改和测试，运维团队对该服务进行打补丁上线，整个过程可能持续几周，存在很大的风险窗口。如果在WAF上，对这些信息进行伪装或屏蔽，就可以极大降低安全风险。更加不用那些会泄露用户信息，金融信息等服务。
RASP
什么是RASP
在2014年的时候，Gartner引入了“Runtime application self-protection”一词，简称为RASP。它是一种新型应用安全保护技术，它将保护程序像疫苗一样注入到应用程序中，应用程序融为一体，能实时检测和阻断安全攻击，使应用程序具备自我保护能力，当应用程序遭受到实际攻击伤害，就可以自动对其进行防御，而不需要进行人工干预。
RASP技术可以快速的将安全防御功能整合到正在运行的应用程序中，它拦截从应用程序到系统的所有调用，确保它们是安全的，并直接在应用程序内验证数据请求。Web和非Web应用程序都可以通过RASP进行保护。该技术不会影响应用程序的设计，因为RASP的检测和保护功能是在应用程序运行的系统上运行的。
RASP vs WAF
那么说了这么多，RASP相较于WAF的区别是什么呢？他们之间的优劣势又区分在哪呢？
从原理上来看，RASP是从应用内部对关键函数操作的数据进行分析，即使原始请求经过加密和混淆，但是它在应用内传播到最终的底层函数时将会以明文方式被RASP截获，因此相比WAF能减少大量的误报和漏报问题。基于此特性，RASP还能为安全人员和开发人员提供更为详尽的攻击链路，包括攻击原始 Payload、代码调用堆栈等信息，方便他们进行漏洞定位、复现以及修复。
虽然RASP较为友好地解决了WAF的不足之处，可以截获真正具有风险的操作，但是它由于构建在应用程序内部，并且只对风险操作进行拦截，这样相对 WAF缺失了从宏观上对流量的监控，对于例如CC攻击、爬虫、恶意扫描等攻击行为缺少有效的防御手段。另外，RASP由于和运行时环境耦合，在实际应用时，会更关注性能和兼容性影响：
性能影响：
RASP工作在应用运行时环境，不可避免会占用应用的计算资源。例如对于XSS（跨站脚本攻击）类攻击，需要在用户请求和服务器响应中分析有无恶意脚本，目前业界采用的办法是使用正则表达式进行匹配。然而在一些使用庞大表单的应用中，XSS的正则匹配将会消耗大量的资源。对于这种情况，可以根据业务场景，控制匹配精度（正则匹配范围）来调整检测精度和检测速度。
兼容性影响：
RASP虽然可以关联应用程序上下文，但是对于业务的真实应用场景的理解仍然不能做到精准。例如对于一些有运维属性的应用，需要管理员从Web直接编辑命令进行执行，但是探针并不能理解类似这样的业务场景，导致命令执行被拦截。对于此类情况，可以通过配置白名单等方式来解决。另外一点，由于 RASP 探针需要工作在应用运行时环境，这就对探针的语言支持和框架支持提出了较高要求。
RASP技术的缺陷
- 不同的编程语言可能编译语言和应用程序的版本不一致都导致RASP产品无法通用，甚至导致网站挂掉；
- 如果RASP技术中对底层拦截点不熟悉，可能导致漏掉重要hook点，导致绕过；
- 对于csrf、ssrf、sql语句解析等问题目前还是基于部分正则进行防护(对于sql语句的解析问题可以使用AST语法树进行解析)。
RASP+WAF
RASP与WAF从来就不是取而代之，而是相辅相成，单独使用某一种时，都会因为存在的短板在一些情境下显得力不从心。
WAF的优势
（1）攻击前流量预警：攻击者在实施真正的攻击前，会产生大量的异常流量，这些流量包括推测服务器环境信息、可注入点尝试等。这些流量通常不会直接造成危害，因此RASP可能无法获悉全量的攻击流量（只会处理可能有危害的流量），而WAF可以完整记录异常流量。
（2）对于CC攻击、爬虫、恶意扫描和脚本小子（script kiddie）这些大流量的攻击或者有明显攻击特征的流量，如果让其直接打到装有RASP插桩的应用上，会造成不必要的性能占用；另外由于RASP会占用应用程序的计算资源，因此也不适合进行过于复杂的计算。所以对于此类攻击，最好的办法就是使用WAF从流量侧对其分析和拦截。
RASP的优势
- 拦截混淆和加密的流量：如前文所述，RASP并不需要对流量进行解密，可以根据场景对恶意行为进行分析，有效拦截被精心设计的攻击流量。
- 针对业务场景进行优化：基于RASP函数Hook的特性，不仅可以对通用类、框架类的函数进行插桩，也可以对自研代码部分进行插桩。例如对于应用在交付前来不及修补的漏洞，可以通过函数级别的虚拟补丁提供防护，保证应用按时交付。
- 极低的维护成本：除了根据需要配置虚拟补丁外，由于RASP从底层函数进行保护，所以基本上不需要对RASP的规则做任何调整即可实现应用的安全内建。
- 兼顾东西向流量安全：RASP工作在应用程序内部，不仅可以分析南北向流量的风险，也可以分析企业内部，应用之间东西向流量的风险。例如微服务架构中涉及多个模块间的调用，它们之间通常会使用rpc等非http协议来进行数据交换，传统的 WAF 通常对其无能为力。而 RASP 则可以很好的解决这样的问题。
- 防御0day漏洞：RASP可以保护应用运行时环境中的所有代码，包括自研代码、第三方组件、Web应用容器（Tomcat、Django、Flask等）。
RASP与WAF结合的效果
WAF与RASP组成纵深防御体系：
- WAF提供真实的攻击来源：企业的应用通常都是在网关或者反向代理之后的，当流量进入应用时，RASP探针在大多数情况下其实只能拿到反向代理或者网关的IP地址，这对于分析攻击来源非常不利。可以借助WAF对所有进入的流量添加Headers（例如 X-Forwarded-For），标记真实来源IP，方便对RASP拦截的攻击事件进行溯源。
- 通过RASP拦截信息生成WAF黑名单：攻击者如果能绕过WAF进行攻击，将会给应用带来负担。通过自动化流程将RASP拦截的攻击者来源IP生成WAF IP黑名单，将会大大减慢攻击者的攻击进程，给安全人员争取应急响应的时间。
- 根据RASP拦截信息生成WAF策略：例如RASP将异常的SQL执行上报后，安全人员可以通过分析得出那些敏感参数，并在WAF中进行标记，这既可以大大降低RASP给应用带来的性能消耗，同时也能让WAF警报更加准确。
- WAF与RASP联动，可以扩大应用安全防护范围：近期攻防演练活动中，红方越来越喜欢使用 0day、内存马这样的手段进行攻击，RASP可以有效进行防御。
总结
总的来说，RASP和WAF最大的区别是：WAF的目的是发现可疑的流量，RASP则是发现具有威胁的行为。由于近期几次大的0day漏洞事件，RASP因其特点，在防护未知攻击方面，发挥了重要的作用。但是RASP并不是要取代WAF，两者是完全不同的技术，各有各的优势，也各有各的不足。WAF作为恪尽职守的哨兵，监视来自外部的可疑入侵；RASP则作为应用的贴身保镖，防御来自内部和外部的致命攻击。而德迅蜂巢所带有的 WAF/RASP 安全工具，既可以及时可疑的流量也可以及时发现具有威胁的行为，即监视了外部的可疑入侵，也防御了来自内部与外部的致命攻击。
原创声明：本文系作者授权腾讯云开发者社区发表，未经许可，不得转载。
如有侵权，请联系 cloudcommunity@tencent.com 删除。
原创声明：本文系作者授权腾讯云开发者社区发表，未经许可，不得转载。
如有侵权，请联系 cloudcommunity@tencent.com 删除。