入侵容忍体系架构：概念与设计

最新推荐文章于 2024-11-06 17:55:14 发布

bingoxp

最新推荐文章于 2024-11-06 17:55:14 发布

阅读量2.5k

点赞数

分类专栏：入侵容忍文章标签：安全相关 security internet 服务器通讯 avi

本文链接：https://blog.csdn.net/bingoxp/article/details/196158

版权

本文探讨了入侵容忍（IT）的概念，它处理包括恶意错误在内的错误集合，以防止这些错误导致系统故障。IT与传统错误容忍和安全领域的联系被详细分析，强调了在面对恶意错误时，传统方法的局限性和新策略的需求。文章介绍了构建IT系统的主要策略和机制，并通过OASIS和MAFTIA项目展示了分布式IT系统的最新进展。

摘要由CSDN通过智能技术生成

入侵容忍体系架构：概念与设计

摘要

在差错容忍和安全领域内，对分布式计算体系架构，方法学及算法有着重要的研究部分。虽然过去它们都有不同的研究方法，但是要解决的问题有着相似性。在传统的可靠性研究中，差错容忍已成为许多解决方案的重要部分。而在传统安全相关的研究工作中，几乎毫无例外的都是以入侵检测为重点。在过去的十几年里，入侵容忍 (IT) 是一种慢慢形成的新方法，并在最近有了突破性的进展。允许入侵，但容忍这种入侵，而不是千方百计的阻止每一次入侵：系统触发了一系列机制，这些机制预防了入侵所产生的系统安全失败。本文描述了入侵容忍的基本概念，考察它们和传统错误容忍以及安全的联系。我们讨论了构建入侵容忍系统的主要策略和机制，并且对分布式入侵容忍系统最新研究进展有所介绍。

翻译：程晓松华东理工大学计算机应用技术

1 简介…………………………………………………………………………………………………..……3

2 入侵容忍案例 3

2.1 传统差错容忍和安全概要…………………………………………………………….. . . . . . . . . . . . . 4

2.2 作为通用框架的可靠性……………………………………………………….... . . . . . . . . . . . . . . . . . 4

2.3 待解决问题…………………………………………………….. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5

3 入侵容忍的概念 7

3.1 AVI复合差错模型…………………………………………………….... . . . . . . . . . . . . . . . . . . . . . . . . 7

3.2 信任和可信任性…………………………………………………….. . . . . . . . . . . . . . . . . . . . . . . . . ... 8

3.3 关注点的覆盖范围和分离………………………………………………… . . . . . . . . . . . . . . . . . . . . 10

4 IT框架和机制 11

4.1 安全和错误容忍通讯. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .. 11

4.2 基于软件的入侵容忍. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . ……….. . . . . . . . . . . . . . . . . . . . . 11

4.3 基于硬件的入侵容忍……………………………………………………….. . . . . . . . . . . . . . . . . . . . 12

4.4 审计与入侵检测………………………………………………………… . . . . . . . . . . . . . . . . . . . . . . 12

4.5 入侵容忍的观点下的一些安全框架………...…………………………………. . . . . . . . . . . . . . . . . 13

4.6 处理源于入侵的误差…………………………………………………………….. . . . . . . . . . . . . . . . 15

4.7 入侵检测机制…………………………………………………………… . . . . . . . . . . . . . . . . . . . . . . 15

5 入侵容忍策略 16

5.1 差错避免和差错容忍. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .. . 16

5.2 机密操作. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .. . . . 17

5.3 完善非停顿操作. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .. . . . . . 17

5.4 可重新配置操作. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .. . . . . . . . . . . . . . 17

5.5 可恢复性操作 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .. . . . . . . . . . . . 18

5.6 故障安全. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . ……….. . . . . . . . . . 18

6 对恶意错误建模 18

6.1 任意故障假设. . . . . . . . . . . . . . . . . . . . . . ………………………………………………………….. . 19

6.2 考虑为有用的混合故障假设. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . ………….. . . . . . . . . 19

7 构建入侵容忍系统 20

7.1 (几乎)没有假设. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . …. . . . . . . . . . . . . . . . . . . . . . . . . . . 20

7.2 未经证明的假设，或者信念的力量. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . ………. . . . . . . . . . . . . . 21

7.3 架构混合体. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .. . . . . . . . . . . . . . . . . . . . . . . . . 22

7.4 预防，容忍，有一些刺激. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .. . . . . . . . . . . . . . . . . . . 22

7.5 使用信任组件. . . . . . . . . . . . . . . . ……. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .. . . . . . . 23

8 系统实例 24

8.1 OASIS . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 24

8.2 MAFTIA . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 25

8.2.1 实践中的混合架构体系. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 26

8.2.2 虫孔感知协议. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .. . . . . . . . . . . . . . . . . . . .. 27

9 结论 29

1 简介

在可靠性及差错容忍，安全及信息保障领域内，对分布式计算体系架构，方法学及算法有着重要的研究部分。在大多数情况下，这些研究部分通常在许多领域得到应用，例如：信息基础架构；基于web的商业站点，嵌入式系统。它们的操作已经成为了需要考虑的因素，目前也就是检测设备的使用，压缩的设计周期和开放性。虽然它们有着不同的研究方法，直到最近这种情况才有所改变，但是要解决的问题都有相似属性：尽管我们通常所谓的错误（意外或者恶意攻击）等发生，仍然要保持系统正确运转；确保当系统失败时（原因依然是意外或者恶意错误），它们并不产生危害。传统的可靠性，主要在分布式设置中，差错相容在很多年前就已经成为许多已知解决方案的重要部分。传统的安全相关的工作则少有例外的有着另一方面的侧重点，即不包含处理入侵征兆的系统性形式的入侵预防或入侵检测。

在过去的十年里，一种新的研究方法慢慢形成，并且在最近获得了令人瞩目的发展势头：入侵容忍（IT）即对包括有意图的和恶意错误在内的一系列错误的集合 (我们可以统称它们为入侵)- 反应, 阻碍, 恢复, 掩饰-的处理概念，如果不对这些入侵对系统状态的影响加以考虑，那么它们将有可能导致系统安全属性方面出现问题。简而言之，我们不是设法阻止每一次入侵，取而代之的是在允许这些入侵的基础上对其容忍：系统有特殊方法触发一种机制来防止入侵导致的系统故障。

分布和错误容忍有着密切关系：一方面用来实现对通用模式错误的适应，且/或一方面在分布式系统中嵌入错误容忍来减少由分布所产生的更大的错误概率。与一些错误的概念相反，安全和分布同样也有着密切关系：一个将信息和处理过程在地理上分离和分隔，使得攻击者更难得逞。这暗示着（分布式）恶意错误容忍，a.k.a(分布式)入侵容忍对于实现安全处理是一个显而易见的方法。如果这是如此显而易见，为什么它不早点发生呢？

事实上，“入侵容忍”这个词在论文[19]中第一次被使用，随后在DELTA-4项目中开发了一个特殊的系统。随后的几年中，在IT这个概念下，主要是在协议方面，进行了许多独立的研究工作[10, 34, 23, 2, 27, 4, 22]，但是直到最近，这个领域才取得了爆发式的进展。在大西洋两岸，两个主要的项目，OASIS和MAFTLA在概念，机制，和架构上对IT进行了研究。一个主要的原因就是恶意错误的出现使得分布式系统出现了基本性的问题。另一方面，传统的差错容忍遵循着一个构架，这种构架并不能完全适用于有意图的和恶意的错误这个方面。下文将讨论这些问题。

本文的目的在于尝试着系统化这些新概念和设计原理。论文阐述了入侵容忍（IT）的基本概念，考察它们和传统错误容忍以及安全的联系，并在指出了IT发展过程中的主要问题。我们讨论构建IT系统的主要策略和机制，并介绍分布式IT系统架构的最新进展。为了不引起混淆，我们假定一个“体系架构”是通过组件的组合来具体化。组件有功能性和非功能性的属性，以及一个接口，这些属性就是通过这个接口来表现。组件位于一个给定的体系架构的拓扑结构中，并通过算法进行交互（一般而言），全局系统属性从而在这些交互作用中产生。

2 入侵容忍案例

可靠性已经定义为一台计算机系统的特性，因此可以很有理由的将信任设置在系统所提供的服务中。正如系统对于它的用户是可见的一样，系统所提供的服务就是它的行为；用户则是另一个系统（人类的或者物理上的），它和前者进行交互。

可靠性是研究的主要部分，它包括一系列范例，在这些范例中错误被容忍，并且它少有例外的都是在偶然错误这一框架下产生的[19，17]，但是我们将以连贯的方式揭示可以应用于恶意错误的本质概念。

2.1 传统错误容忍及安全概要

Gray解释道：“为什么计算机出错，我们能做些什么？”；尽管事实上所有的工作可能出错，但是人们似乎趋向于过高估计他们所依赖的计算系统的质量。对于分布式系统亦是如此。如同Lamport所说的“分布式系统一种有碍你工作的系统，因为这种系统的故障你可能从来没有听说过”。假设机器独立的出现故障，作为初始状态，假设一个系统的可靠性（<1）是每个组件的可靠性的积，则在分布式系统中一些组件出现故障的机会就比单一的系统大很多。如果组件在出现故障时会影响其他组件，那么情况就更糟糕。

恶性破坏使得分布式系统的可靠性问题更加棘手：因为攻击者很可能制造“普通－模式”症状，我们不再能够像对待一个意外的错误那样，独立的考虑所出现的故障；组件间可能通过分布式协议实现串连；由于在错误的时刻，包含伪造的身份或内容的矛盾的输出这种情况的发生，不再能被考虑成“低概率”，因此故障本身就变得更严峻；此外，受高智商对手的意志控制，它们有可能在系统最不适的时刻或位置发生。

这影响了传统错误容忍里被长期坚信的理论：传统错误容忍认为错误类型和分布遵循统计学上可定义的模式。环境可以用随机意义上的术语定义。本质上，你可以依赖：预定义的和静态错误模型及环境假设。
从恶意错误观点来谈论错误容忍（FT）时，第一个问题就是：如何对一个攻击者的思维进行建模？

现在让我们用传统的安全观点来审视一下这个问题。典型的安全属性是：机密性，用此方法保护一个服务或一段信息不被非授权访问；真实性，用此方法保护一个服务或者一段信息是真实的，不是伪造的；完整性，用此方式保护一个服务或一段信息不被私自或者未被侦测到的修改；可用性，用此方法保证一个服务或一段信息不拒绝那些通过验证的访问。一个理想的系统的设计目的在于保证所有或者这些属性当中的一部分。

传统上，安全已经逐渐成为阻止某些确定的攻击，去除初始不健壮软件的易受攻击性，阻止攻击演变为入侵这三个方面的结合。例如，为了保护机密性，让入侵者读取任何机密的数据是不可思议的。那就是说，安全是以阻止预防这种模式为基础的。但是，让我们假设想象一下在安全上的容忍模式[1]。

假定（且认可）系统在某种程度上依然易受攻击；

假定（且认可）对于组件/子系统的攻击可能发生，且有一部分会成功；

确保整个系统依然是可靠的，运转的。

那么可以提出另一个问题：我们怎么使得入侵者读取修改数据的前提下，依然确保机密性和完整性？

2.2 作为一个通用框架的可靠性

我们观察图1中著名的fault-error-failure序列。可靠性的目的在防止系统的故障。这种故障由远程引起，有可能是一个错误（例如程序中的漏洞，或配置错误），如果它被激活（例如程序执行到错误的代码位置），那么在系统状态中将导致一个错误的发生。如果什么都不做，那么在系统运行过程中，我们就会发现这个故障。

因此，实现可靠性意味着各种技术的综合使用，这些技术包括错误阻止，即如何预防错误的发生和引入；错误去除，即如何减少错误的出现（数量，严重程度）；错误预报，即如何评估错误的出现，产生以及结果；最后就是错误容忍，即如何确保在出现错误的情况下继续提供正确的服务。因而，在面对恶意错误（入侵和攻击）时，实现可靠性意味着含有容忍技术的传统预防和去除错误技术的综合使用。

图 1: Fault–> Error–> Failure 序列

接下来我们分析一下标准和分布式错误容忍的基础，来看一下它们在这种新情景下是如何适用的：

拓扑分离，目的在于实现错误的独立及降解。

复制，无论软件或者硬件，作为冗余的形式之一，有着粗或细的力度之分。

可配置性，通过大量的假设错误，大量的复件，复件控制的类型（活动，半活动，被动，联合声明，投票规则）

资源最优化，通过软件到硬件的组件映射及逐渐增加的F/T类别（疏忽的，断定的，任意的）。

从攻击效力来讲，拓扑分离使得入侵者的侵入行为更加困难。例如，可以通过若干个站点机密内容，得到部分机密并不会泄漏整个机密内容。从完整性和可用性来说，复制使得组件对于损害来说有更强的复原性，但是（虽然有违于直觉）也能有益于机密性及真实性，如果我们思考一下经复制的决定的执行（例如，要不要提交一段数据，或者要不要执行验证。举例来说，一个单一的受侵袭的站点将不能决定对一段数据进行访问的验证。对于不同强度和不同种类的入侵的恢复能力，可配置性是实现这种恢复能力的关键（f+1复制来抵挡拒绝服务的攻击， 3f +1可以对Byzantine错误进行恢复，以此类推），同时也是实现不同恢复类型（不仅是最迅速的激活，也包括半活动和被动）的关键。资源最优化降低了实现入侵容忍的代价。

这个方法看起来是令人信服的，但是在具体的条件下，如何将容忍应用于攻击，缺陷，入侵这样的情景之中呢？

2.3 待解决问题

让我们分析一下一些待解决的问题，这些问题是在一个安全或者错误容忍的背景下对入侵容忍分析时所产生的。

首先，是什么导致了入侵的风险？风险对存在的入侵的概率及它们的严重程度的一种综合的测量方法。换句话说，就是这些入侵引起的错误的影响。前者受两个作用在组合中的因素的影响：对于那些计算或通信已经暴露的系统的威胁级别；它所处理的易受攻击性的程度。对于一个系统潜在的不安全性的程度（换句话说，保证其安全的难度）的测量依赖于：系统缺陷的数量和种类（易受攻击性）；以及这些存在的对于系统的攻击的可能性（威胁）。通俗来说，入侵的概率是由对于系统缺陷敏感的攻击的概率所决定的。后者，错误的影响力，是通过在系统运转中的入侵代价来测量的。这种代价可以用若干形式来换算（经济的，政治的，等等）。

考虑一下下列的两个例子系统：

Vault系统的易受攻击度vvault =0.1，既然它有如此之高的适应力，它的设计者用它来服务Internet上的匿名请求，对访问它的人不进行任何控制，那就是说，它将面临着的威胁级别非常之高，tvault=100。

Sieve系统，正好相反，它是一个易受攻击的系统，vsieve =10，因此它的设计者对它进行了保护处理，将它置于防火墙下，并控制对它的访问，转化成威胁级别的表示就是tsieve=1。

哪一个系统的运行风险更低呢？考虑一下在我们理论例子中威胁度与易受攻击度的乘积：用我们赋予每个系统的假设值进行计算，虽然Sieve系统的易受攻击性是Vault系统的一百倍，但是两个系统却得到了同样的结果（10）。

我们应该竭尽全力将风险降到零嘛？那是否真的可行？这就是传统的对系统所面临的攻击及易受攻击性的数量，能力及严重性进行阻止/去除。问题是没有办法将这些降到任意的低点，因为以下几个原因：花费的代价太大并且/或者过于复杂（例如，过于长的代码，硬件约束）；某些攻击来自于正在被部署的服务的种类（例如，Internet上的公共匿名服务器）；某些易受攻击性是属于系统设计的恰当性（例如，在某些操作系统中机制所导致的竞争）。

就算我们能够将风险降到零，这样做是否值得呢？谈论一下可接受的风险应该是有可能的：所谓可接受的风险就是在给定我们所要保护的服务或者数据的值的前提下，对于我们所能接受的故障概率的值。因为它对于防止/去除错误及容忍系统内的残余错误所应尽的努力，建立了一个标准，因此当我们构建入侵容忍系统时，这将培养我们的推理。如果我们考虑一下黑客或者入侵者他们也有入侵代价，这种代价可以用时间，精力，金钱或者它们的综合来衡量。通过在入侵代价和资产价值方面建立关系，可以很明确的把它看作“可接受的风险”，那么我们可以用更进一步的向导对系统进行假设。

据报道，安全端口层（SSL）可以保证浏览器和WWW服务器之间的安全客户端－服务器交互过程。SSL真的安全吗？用户在并没有量化到底有多安全的情况下，趋向于认可交互是安全的（假设易受攻击度较低）。一些公司已经用SSL建立了他们的商业服务器，有些服务器完成Internet上（高级别的威胁）重要的金融交易。Netscape的SSL被破解，就是因为其中的一个bug允许复制会话密钥，这将破解任何通讯。经过对40位的密钥（根据美国对于加密材料的出口限制，那是所能达到的密码长度）进行暴力法破解，使得修正过的版本至少又被破解了两次。这种初始情形导致了一个高度的风险。

SSL足够安全吗？Netscape发布了一个SSL的修正版本，并报道说要在计算期间破解一个Internet会话需要至少花费10,000美金。相对于系统提供服务的价值，入侵一个系统的代价使得架构师可以做一个风险评估。某人花了10000欧元来破解系统，最终得到100欧元的奖金，是做了一次赔本买卖。这就给可接受的风险下了定义。不幸的是，这些评估可能会失败：在Netscape宣布后不久，一个学生用了一台高性能的桌面图形工作站，仅仅花费了600美元就破解了系统。然而，并不是Netscape的原则和态度出现了问题，而是他们做的过于理想化的风险评估有问题。