从实用角度谈谈（微）分段

在介绍最佳实践和策略之前，我们首先需要明确网络分段的定义。网络分段是将网络“拆分”成多个部分（区段），并定义各个区段的访问权限和访问方式（例如，Web 服务器只能通过 HTTP/S 访问）。

在传统上，使用 VLAN 和物理防火墙就可以达到这个目的，但最近已经出现越来越多基于软件的防火墙策略和分段策略（例如Akamai Guardicore Segmentation）。我们不会推荐其中的任何一种策略，因为两种策略各有利弊。我们要推荐的是不受供应商限制、适用范围广泛的策略。

从使用 VLAN、访问控制列表 (ACL) 和 IP 范围控制流量，转为使用不受供应商限制的自定义标签，便意味着您进入到了微分段的领域。 本文中的所有策略都假设我们使用的是微分段。

这些策略和原则也许可以经过调整，运用于不需要分段的环境，但是要定义所有 VLAN、ACL 和 IP 列表并进行维护，可能不太现实，因为这很快就会让所有网络管理员和工程师变得精疲力竭。（试试定义所有财务服务器的 IP 范围/组。这也许可行，但您能够长期准确维护这个列表吗？这还只是一个服务器组；在企业网络中，您会拥有更多服务器组，包括最终用户、域控制器、域管理员、打印机等等。）

在讨论如何进行分段之前，我们需要讨论分段的一个重要先决条件：监测能力。微分段并不是一个孤立的概念。我们无法保护看不见的资产。 好的分段策略只有与网络监测（整理和汇总流量）相结合才能发挥成效。网络流量通常很大，我们无法用肉眼直接分析所有原始数据。

在介绍具体的分段策略之前，我们先讨论一些（我们认为）对于良好的分段至关重要的原则或准则。

通常来讲，具有大量入站流量的服务器更多是负责处理请求，Web 服务器或文件服务器就是如此（甚至域控制器也属于这一类）。所以，这类服务器不应该有过多的出站流量，或者至少应该严格限制出站流量。

此外，如果对输出和输入限制很少，可能会导致服务器被攻击者利用，因为这些服务器对于攻击者来说更容易访问，他们可以借此来访问网络上的更多区域。

对于有些设备，我们不得不采取宽松的策略，因为从这些设备发出的流量变化太大；因此，我们必须规定很多例外情况。

以跳板机服务器为例，不同的用户使用这类设备通过不同的协议连接到不同服务器。要想覆盖所有应用场景，难免会缺乏严密性（这违背了分段的整个宗旨）。

在这种情况下，我们认为最好采用其他 防御机制 ，并设置更严格的规则（例如对跳板机采取更强的用户访问控制，或者降低监控服务的告警阈值）。

在开始分段时某些流量链路可能已经存在，但并不代表应该允许它们存在。若您认为应用程序或服务器产生的流量并无必要，您可能得修改这些应用程序或服务器的现有配置。有时，为了弄清楚某些流量为什么会存在，您可能还得检查现有配置。

在这种情况下，分段就像传统的防火墙一样，可以阻止网络外部的非必要入站流量。这些流量通常来自互联网，但也可能来自连接到公司网络的第三方网络。 

所以，我们建议封锁暴露的安全外壳 (SSH) 端口或远程桌面协议 (RDP) 端口（或者 横向移动 部分的几乎所有端口）。实际上， 更好的做法是使用白名单而非黑名单 来处理从网络外部进入的流量，尤其是来自互联网的流量（比如，想想看在任何给定时刻有多少网络扫描器处于活跃状态）。

当然，分段与任何其他安全工具和实践（或策略）一样，并不能阻止所有威胁。在这种情况下，分段无法覆盖所有初始访问媒介，如果只依靠分段，会让网络面临风险。很多入侵都是始于网络钓鱼电子邮件或链接，或者其他形式的社会工程。

有些应该允许的协议中若存在漏洞，或者合法连接到互联网的服务（例如 VPN 服务器）如果使用薄弱的凭证，也会成为攻击的突破口。鉴于此，我们不建议只依靠分段来防止初始访问。除了分段之外，还应该采用安全解决方案来对主机和电子邮件进行保护。

执行横向移动的方式有很多种，我们在本文中只介绍其中几种。具体来讲，我们的重点是防止设备上已经存在的合法进程中会产生的横向移动，其执行方式包括使用 RDP 或 SSH 等协议、服务管理器或任务调度器等基于 RPC 的服务、PowerShell 或 WMI 等管理工具，或者 Linux 中可用的一些协议和工具（详见另一篇 文章）。

我们不打算讨论“一日漏洞”或“零日漏洞”，因为它们可能存在于任何产品中，执行方式也各不相同，要制定适用于所有这些漏洞的通用策略并不现实。但我们可以推荐的方法就是分段，因为无法访问的资产对攻击者而言更难以利用。

在深入探讨各种协议的不同注意事项之前，我们先看看这两条适用于所有协议的准则。

用户实际上并不需要访问其他用户的设备，尤其是通过网络去访问。除了 IT 工作人员以外，其他用户没有什么理由远程连接到别人的设备。因此，在不对网络可操作性产生太大影响的情况下限制用户设备之间的流量应该是非常可行的。

此外，本部分提到的协议由于可能被用于远程控制或执行，因此也可能被用作初始访问媒介。所以，我们再次重申要限制通过这些协议进行的任意互联网访问。

这些服务是交互式和图形化的，它们的自动化使用非常有限。因此，服务器之间使用这些协议的情况并不常见（只是“不常见”，如果情况相反，那就是时候调查原因了）。

同样的道理也适用于用户设备之间的连接——用户设备不需要相互连接。这些假设也有例外，例如跳板机和终端服务器允许用户切换到不同环境或者访问不同的服务器、IT 人员连接到用户设备、应用程序所有者连接到应用程序服务器。

要处理这些例外，应该创建合适的分段策略。除此之外，还应该使用适当的身份访问管理 (IAM) 解决方案作为补充。

SSH 尽管在概念上类似于 RDP，但它的情况要复杂得多。由于 SSH 是基于终端（文本）来操作的，所以使用它与软件交互要容易得多，而且有些程序和脚本也使用 SSH。除此之外，SSH 还被用于封装安全性较低的协议，比如 SFTP，也就是文件传输协议的 SSH 封装。

鉴于以上原因，SSH 相比其他 RDP 而言需要采取更精细的方法。如果无法充分监测网络流量，就很难在不影响最终用户或网络可操作性的情况下对 SSH 进行合理分段。

MS-RPC 和 SMB 都不会立即允许横向移动，但建立在这两者之上的其他协议却会这样（图 4）。SMB 用于文件传输和通信，而 RPC 用于从定义的接口调用远程函数。RPC 有时也通过 SMB 进行通信，所以两者是紧密结合的。这两种协议也很难进行合理的分段，这是众所周知的，因为它们已嵌入到 Windows 域系统中。

例如，域认证是在基于 RPC 的 Netlogon协议中实施的。域组策略和登录脚本存储在域控制器上名为 SYSVOL的共享文件夹中，而加入域的设备通过 SMB 访问这些数据。

要想在不破坏整个域的情况下阻止 SMB 和 RPC，几乎是不可能的。那您能做什么呢？对于 SMB，您可以根据逻辑单元创建策略——大多数服务器和设备不应通过 SMB 相互通信，除非目的地是文件服务器。因此，适当的隔离分段应该有助于降低 SMB 的风险。

对于 RPC 也可以采用类似的方法，但可以更加严格，因为和 SMB 不同，我们不需要允许 RPC 流量传输到文件服务器。此外，由于 RPC 是在用户模式下操作的，所以可根据目标服务或进程来创建分段策略，您只需要处理可能被滥用于横向移动的 RPC 接口（而且前提是您的分段代理可以处理基于进程或基于服务的规则）。

下表显示为了防止横向移动而应该进行管理的 RPC 接口。

并非所有通过这些 RPC 接口进行的操作都是恶意的（例如，某些监控解决方案和监视程序会与服务管理器远程交互，以检查服务运行状况），所以我们建议检查现有的 RPC 通信。如果一般情况下不会远程访问这些接口（或者如果可以缩小源列表的范围），那么我们建议围绕这些接口创建分段策略，以提高安全性。

PowerShell 和 WMI 都能够与远程设备交互，这种交互由 Windows 远程管理 (WinRM)“提供支持”。由于合法用途通常是远程管理或监控（对于 WMI），所以企业网络中应该鲜少使用。您可以创建分段策略来限制任意使用，并且只允许来自监控服务器或 IT 设备的通信。

当然，也可能存在例外情况，我们已经看到有开发人员为了方便而广泛使用远程 PowerShell；所以，您可能需要根据实际情况做出决定。

只依靠分段就想阻止攻击期间的数据外泄不太现实，除非您想用原始的极端办法控制所有出站流量。互联网非常庞大，我们无法准确判断网络上用户所访问的每个网站和服务器。因此，攻击者可以轻松将窃取数据的行为伪装在所有其他出站流量中。

比起控制出站流量，控制敏感数据的访问权限更为可行。要想限制出站流量，唯一可能的地方就是网络中的服务器；与用户设备不同，服务器的出站目的地应该不会有太多变化。

这个部分的总体原则是“存在并不代表合理。”在对网络的一部分进行分段时，无论这个部分是业务关键型应用程序（如 SWIFT）、操作单元（如域控制器）还是环境（如生产服务器），首要任务都是调查现有流量（图 5）。

分析现有流量后，您可以创建适用的策略，以允许相关流量并限制其余流量（在此过程中，您还可以找出那些应该由应用程序所有者处理而不是通过分段进行处理的不当配置）。

我们建议不要立即实施阻止策略，而是按只发出告警的模式运行一段时间。只有在您认为策略的运行符合预期，并且违规告警的数量处于可控的最低范围时，才应该转为限制策略。

区分当前环境（开始分段之前存在的环境）和未来环境（实施分段策略之后的环境）也很重要。第一次实施分段时，应该保持谨慎，认真分析网络，避免造成破坏性后果。

然而，在考虑现有分段策略的同时，还应该添加更新的产品版本。为了保持正常操作，可以根据需要规定策略的例外情况，但不要因为扩展网络而不顾现有策略。

对于隔离，我们最关心的是所分隔的区段与网络其余部分及整个互联网的接口。我们应该控制要分隔的区段的进出流量，而不考虑该区段内的活动。

我们可以让隔离策略再进一步，根据设备的不同用途运用不同的策略。例如，如果服务器只是充当数据库，则只应该通过数据库端口进行访问；Web 服务器则只应通过 Web 端口访问。

当然，事情没这么简单。因为通常会有更多服务需要访问这些服务器，例如监视程序、性能监控程序和 IT 支持。通常来讲，这些访问端口是围绕某种远程控制设置的，所以它们看起来也和横向移动技术非常相似。（例如，远程监视程序查询服务管理器的方式就与 PsExec 横向移动技术很类似。要想区分这两种调用方式，唯一的方法是深度数据包检查，但该方法通常无法使用。）

为了解决这个难题，除了应该已经访问服务的流量之外，如果还需要允许额外的流量，我们建议将允许的来源限制在应该进行监控的区段。

此外，我们可以限制用户访问他们不需要访问的敏感位置。如果数据库仅服务于内部应用程序，则没有理由允许任意用户进行查询。我们认为，阻止任意用户访问是最重要的安全步骤，因为很多攻击都是从受感染的用户开始的。

借助 微分段，我们能够对分段策略实施进一步的细化——根据区段内设备的角色或敏感性对它们进行分隔。我们可以将它视为应用程序隔离与常规隔离的结合。 微分段与隔离的主要区别在于，我们也控制区段内的流量，不会自动信任邻近的来源。

这里的原则是，我们不应该只因为处于同一区段内，就信任来自邻近设备的流量。攻击者为了攻破整个网络，会利用任何可以利用的连接，而不会在意区段。

所以，区段中即使有相同类型的应用程序服务器，这些服务器之间也没有理由通过每个端口和协议进行通信。微分段意味着对各种类型的流量（甚至网段内部和具有相同角色的设备之间）运用策略规则。

当然，同一区段内的设备之间通常结合得更紧密，所以要想在添加策略的同时避免过度宽松会更困难。

应用程序隔离原则通常也可以作为微分段原则进行运用，具体取决于您如何定义网络中的各个区段。例如，如果我们将网络分为用户区段、数据库区段和 Web 服务器区段，那么 应用程序隔离 中定义的原则也适用于微分段。唯一要增加的是在每个应用程序区段内和不同设备之间运用这些原则。

但是，如果我们将网络分为财务区段、销售区段和 IT 区段，而且每个区段都既有服务器又有用户设备，那我们就需要更有创造性。在将常规隔离策略运用于各个区段之后，我们必须接着在各个区段之间和各个区段内部创建策略。我们可以将每个区段视为一个微型网络；然后再将每个区段进一步分为不同的应用程序和设备类型。（例如，对于销售区段，我们可能有文件服务器、数据库和用户设备。）我们可以将每种设备视为一个新的区段，然后再次按照隔离原则或应用程序隔离原则进行分段。

图 6 总结了各种分段策略之间的关系。

网络分段不仅是一种提高网络安全性和应对网络威胁的实用技术，也是一种可以提供即时安全价值的方法，因为您不需要从漫长或艰巨的分段项目开始，而是可以将需要完成的工作分成多个子项目，利用每个子项目逐步改善网络的安全状况。

在本文中我们介绍了各种分段策略的指导原则，可以帮助网络管理员完成这些工作。希望这些建议能够发挥实际作用，帮助企业保持更高的安全性。

Akamai 安全情报组将继续监控和钻研各类安全主题，并公布相关的研究成果。如需获取实时更新和了解重大研究成果， 请关注我们的微信公众号！