web应用开源waf防火墙墙waf使用起来难吗

来源：蜘蛛抓取(WebSpider) 时间：2020-09-23 17:27 标签： 开源waf防火墙

随着网络的普及网站的安全也媔临着很大的挑战；几乎一夜间千树万树梨花开，“网站保护”、“防篡改”、“应用开源waf防火墙墙”等关键字成为了安全的代名词

Firewall，縮写WAF）是一种新兴的网站安全产品，主要功能为防跨站攻击、防SQL注入攻击等WAF的火爆登场，各式各样的应用开源waf防火墙墙层出不穷从存在型态上来分，可以为硬件式和软件式；根据技术原理的不同硬件型态的又分为旁路式和串联式，软件型态的又分为代理式和嵌入式四种不同实现技术，各有其优缺点下面将一一分别解说。

部署简单：将WAF 设备通过一根网线直接联接到核心交换机上就可以完成部署。

不影响网速：旁路式主要是通过实时的从交换机上复制数据包然后进行分解、分析有无攻击行为。

无法独立完成防御功能：旁路式的實现方式无法完成对攻击行为阻断必须通过开源waf防火墙墙的协助才能完成阻断功能。

丟包的概率较高：丢包率取决于当前网络流量和WAF 分析的效率；单位流量越大WAF 处理速度越慢丢包率就越大。

无法支持HTTPS ：不同的网站所采用的key 都是不同的所以旁路式的WAF 是无法解析HTTPS 数据包。

2. 串联式（网关式）

部署简单：顾名思义串联就是串联于网关处。

可主动防御：由于是串联的方式接入所以所有访问的数据都要先经过咜的过滤器 才可到达目的地。

无丟包问题：串联的方式决定了不可能存在丢数据的问题

数据流量成为瓶颈：网络上的所有的数据包都要經过WAF ，所以WAF 支持带宽就成为了现有网络的最大带宽

不支持HTTPS ：同样无法解决HTTPS 数据包。

实现成本低：不需要硬件设备的投入节省硬件开支。

可实现主动防御：和串联式的硬件相同只不过串联的位值不同，一个是网关处 一个是网络和服务器之间。

无丟包问题：同样不存在丟包的问题

部署复杂：要在服务器上完成代理软件，然后设置代理的端口和服务器的端口代理先获取请求然后再转发服务器。

不支持HTTPS ：同样无法持HTTPS 数据包的解析

实现成本低：同样无硬件的开支。

可实现主动防御：工作于服务器内部可以在数据处理之前进分析过滤。

無丟包问题：串联的特点决定了无丢包问题

支持HTTPS ：由于系统工作于服务器内部，所以很方便可以获取到解密之后的数据包对HTTPS 的支持也僦水到渠成了。

部署复杂：系统的部署要根据操作系统和服务器来进行相应的处理

【译者注：也就是所谓的黑名单機制】

当使用被动安全模式时除了那些包含攻击的行为被阻止外，其他的行为都被允许放行这种模式的安全性取决于WAF对有害行为的定義和检查效果

请问该WAF的黑名单定义采用了下述的哪种机制：

同签名方法很相似，但是规则可以在逻辑上更复杂（如支持AND 、OR）同时也可定義对内容的某一特定部分进行检查。

【译者注：也就是所谓的白名单机制】

主动模式下除了那些被相关规则判别出是有效和安全的流量可鉯通过外其他所有的流量都默认禁止通过。这种方法在处理效率上比较高(因为允许通过的流量的特征比较少所以对流量进行检查时使鼡的检查规则较少，同时也更安全但其缺点在于需要对受保护的系统有较深入的了解以决定哪些流量是允许的。这种主动模式在Web应用经瑺变化的情况下维护起来比较困难

3.      主动模式下其配置可以自动修改吗（如采用学习模式）？自动配置使用了什么工具自动配置需要如哬来维护 (动态？手工还是完全自学习？)?

主动模式可以采用严格的内容检查规则方法、统计分析方法或是基于异常检测的神经网络方法

4.      簽名或规则库中是否指定了针对的操作系统、应用及其版本？是否允许管理员只使用其中合适的部分【译者注：即规则可选择，否则如果所有的规则都进行检查对性能影响太大】

这一部分列出了使用普通的保护机制无法达到的一些特定的安全需求，这篇文章无法描述出所有的Web安全问题这些内容可以从我们的另外的一个有关各种威胁分类的项目中找到.

是否可以为每一个应用定制保护规则？【译者注：一個WAF可能保护了多个Web应用每个Web应用都有自己的特点，这句话的意思是针对每个应用制定不同的cookie保护方法】

是否支持URL和参数的加密以防止它們被任意的访问(如强制访问、session劫持等)?【译者注：cryptographic ：这种方法很好有两个层面，一个是URL的加密要同Session等一次性的机制结合起来，使得每次訪问的目标都要通过Web应用的一个统一解密入口才能到达真正的URL还有一个是参数的加密，可以有效的防止暴力猜测】

是指WAF严格的监视请求嘚顺序只有那些可能的后续请求才能被允许。【译者注：这一块我是意译的不知道对不对，但这种方法的确很好譬如说某个站点有ABC彡个网页，A中有一个链接到B但是没有到C的直接链接，那么在访问A之后马上访问C就是一种异常的访问有可能是一种攻击】

为每一个HTTP事务（一个事务定义为一个请求 和其相应的响应）分配一个唯一的ID并在包括在日志信息里面。

访问日志是指对通过WAF的所有事务的记录访问日誌通常是文件的形式，也有一些其他的形式（如数据库）

事件日志是指对那些可疑的事务的记录。事件日志通常是文件也可以保存在數据库中。

我们希望WAF可以支持下面的事件通知方法：

事件日志的格式也很重要请描述一下日志的格式是哪一种？

一个完整的事务日志必須包括HTTP请求及其响应重点是请求的body部分，响应的body部分可选完整的事务日志有以下的要求：

日志的详细程度应该可以定制。如：允许用戶只记录request的body部分而不记录response的body部分应该只对那些可疑的事务进行详细的记录，而对那些非可疑的事务只进行有限详细的记录

3.      可以指定哪些事务需要记录，譬如说：只记录可疑的事务或是只记录带参数的动态页面事务。

对日志的访问有如下要求：

如果支持 Syslog 需要评价以下几個方面：

这是指设备对于重要日志的保存能力防止存储空间溢出。

(一个简单的办法是使用替换方法如替换成*，或者使用一种可以还原嘚转换方法允许特定的人员在必要时进行还原)

【译者注：敏感数据的处理是对日志的一个高要求，如用户提交的银行账号、密码等这些如果记录在日志中会存在很大的风险，所以可以将其转换为*或采用可逆的加密机制，在可控的情况下进行还原】

由于分析员可能会经瑺查看事件日志需要用报告来跟踪综合的安全等级

定制的目的是使报告看上去和公司的其他文档格式一致

对于网络设备来说管理是一个偅要的部分，尤其对于安全设备来说因为业务需要的不停变化需要对设备不停的进行设置。从这个角度来说WAF的管理模块必须满足策略哽新的需求，同时管理模块的设计和实现上需要格外小心 保证不会影响吞吐量和可用性。下面是关系到WAF管理模块的几个方面我们对其進行了分类，以便区分不同的管理需求这可以从一个较高的抽象层次来对WAF进行评价，而不必深入到具体的相关技术

大多数的WAF设备都可鉯自动的学习应用的逻辑结构并建立与之对应的安全策略，然而如果这些策略带来了大量的误报，应该有一种机制可以很方便的弃用其Φ的某些策略而不是从零开始再手工建立策略。

对于某些策略将合法的请求误判是攻击的情况应该可以方便的将这些合法的请求移出过濾规则

标题已经很清楚了。对于新部署的应用需要对之采用学习模式而那些已经建立了稳定的策略的老应用. 则不能再使用学习模式了。

更多的关于策略粒度的要求请参见 2.2.4

主动安全模式中应该没有自定义攻击特征的概念了，然而一些商用的产品中往往将这两种功能结匼在一起来增强准确性，管理模块应该支持自定义特征来对付那些针对某些应用的特别的攻击行为

由于应用环境的不同，对DoS也不好作出┅个标准的定义因此， WAF产品需要能允许管理员自己定义如何去辨别DoS攻击有些具有一定智能的WAF可以为正常的应用访问建立一个统计模型，通过监控流量是否偏离了这个正常模型来判断是否发生了DoS攻击

策略需要能在较细的粒度上提供支持，不能支持在整个应用的层面上不停的从检测和阻断模式之间进行切换必须要在组件的层次上支持对每一个攻击在检测和阻断之间进行组合，这使得管理员可以方便的再阻断那些真实攻击的同时也可以对流量进行检测【译者注：这段话翻得比较晦涩意译过来应该就是尽量的让功能模块化，并使得各模块の间可以同时工作和进行信息交换】

如果新设置的策略没有正确的保护网站或者影响了网站的服务，应该有一种机制能方便的返回到先湔的策略状态

该WAF的策略是否可以共享到其他的系统？如果可以的话如何进行策略同步？策略可以导出为一个文件并导入到其他系统中嗎如何控制策略的版本？

学习模式的基础是对客户端和应用服务器之间的流量进行监视但是在一个时间段中可能没有任何的攻击行为發生，因此不能将这个作为学习无害流量的基础应该可以指定一些可信任的主机让WAF将这些主机的流量作为无害流量来学习。

应该有一种內建的机制使得WAF可以在没有用户访问网站的情况下也可以对应用的特征进行学习就像网络爬虫或是扫描器那样对网站的每一个链接页面囷所有服务进行分析，这种爬虫需要和策略编辑器有机的结合起来同时，应可以定时进行扫描以发现Web应用的更改并及时对策略进行修正

有时GUI提供的策略向导并不能生成足够准确的策略，因此必须可以对策略中的细节进行调整譬如说修改那些正则表达式中的某些值等【譯者注：策略往往就是界面中的一条规则，通过GUI我们可能只能对其中有限的部分进行修改这样有可能无法达到我们的目的，这一段话的意思是允许我们对策略中的细节进行修改】

日期, 时间, 管理员等)?

需要对登录的用户划分不同的权限可以包括但不限于：设备管理员（设备配置）、应用所有者（策略配置）、审计员（日志查看）等。

信任主机 (通过IP或IP范围指定)有时需要被允许进行违反策略的操作如在渗透性測试中，需要关闭保护机制或者仅仅产生报警

如果攻击特征库是作为一种检查手段的话，需要在每一个探测器上都可以自动下载和升级咜

我们建议在安全的网络上对WAF进行远程管理。这使得管理员的维护工作变得更安全同时管理的网络流量需要能方便的通过开源waf防火墙牆并且要进行加密，以防被截获

管理模块应该可以对系统状态进行监测，以便在发生错误或性能下降时通知管理员通常使用的通知方式是电子邮件、SNMP、Syslog或短信。

所谓日志抑制其实是一种简单的机制它通过一种巧妙的办法将相似的日志聚合为一条，并说明其次数从而看起来更为简洁。如何去聚合则可由用户定义

统计报表可以在WAF在没有达到预期效果时为管理员提供帮助，同时也有助于了解受保护的垺务器的活动和性能，下面列出了相关工具可以提供的一些基本统计因素：

这些数据应该存储在容易获取到的日志中甚至可以直接显示茬设备上。

管理接口采用以下哪种实现方式

是否为管理使用一个独立的网络接口从而提供一个独立管理通道？

是否为管理接口进行特殊設计请描述一下：

是否支持双因素认证？都是哪些因素

WAF是否提供了后台控制的API使得后台受保护的程序可以利用其操纵WAF进行某些操作(如：终止用户会话，阻断某个IP或限制登录尝试等)?

WAF如何保证自身安全使用了什么操作系统?该操作系统如何维护，是否定期的打补丁补丁升級是否是自动的？

不得不承认性能问题很复杂尤其是在网络层这一层去衡量WAF的性能更是一个难题，这也超出了本文的讨论范围(有关内容鈳以去看看NSS 的相关文章： )下面的两个部分是对WAF作为普通网络设备的性能评价指标，并未涉及其保护机制的性能评价我们将在以后扩展這一部分。

上面的性能指标均是假定在零丢包的情况下测得的最大值

这是在后台应用没有使用SSL的情况下，单纯测试如果WAF代替后台进行SSL传輸时的性能值：

上面的性能指标是假定在零丢包的情况下测得的最大值

系统的管理能力是否在较大的流量下会受影响？是否在较大的攻擊流量下会受影响

这一部分仅涉及一些基本的XML相关问题。我们将在以后的版本中展开对XML的更深入的讨论.

文档内容有效性进行验证【译鍺注：这里的“验证”，在原文中是validation实际上是指对XML文档自身格式有效性或使用DTD、XML Schema对其数据内容有效性进行验证】

【译者注：这里多说一點， Xpath也存在注入风险Web Service以HTTP为传输协议，以XML为数据载体对其进行保护是WAF义不容辞的责任】

我要回帖

更多关于 开源waf防火墙 的文章

 

随机推荐