4. Common Issues (常见问题)

尽管每个系统的安全需求各不相同, 若干常见需求会出现在许多协议中. 往往, 当朴素协议设计者面对这些需求时, 会选择明显但不安全的方案, 尽管存在更好的解决办法. 本节描述许多协议中可见的若干问题以及可能有助于处理它们的常见安全技术片段.

4.1. User Authentication (用户认证)

本质上, 每个希望控制对其资源访问的系统都需要某种认证用户的方式. 为此目的设计的机制几乎数不胜数. 接下来几节描述其中一些技术.

4.1.1. Username/Password (用户名/口令)

最常见的访问控制机制是简单的 Username/Password (用户名/口令). 用户向其希望使用的主机提供用户名与可重用的口令. 该系统易受简单被动攻击: 攻击者从线路上嗅探口令, 然后发起新会话并出示该口令. 可以通过在诸如 TLS 或 IPSEC 的加密连接上承载协议来缓解此威胁. 未受保护的 (明文) 用户名/口令系统在 IETF 标准中是不可接受的.

4.1.2. Challenge Response and One Time Passwords (质询-响应与一次性口令)

希望比 Username/Password 更安全的系统常常采用 One Time Password (一次性口令) [OTP] 方案或 Challenge-Response (质询-响应). 在一次性口令方案中, 向用户提供一串口令, 必须按顺序每次使用一个. (常常这些口令由某个密钥生成, 用户因而可以简单地计算序列中的下一个口令.) SecureID 与 DES Gold 是此类方案的变体. 在质询-响应方案中, 主机与用户共享某个秘密 (常常表现为口令). 为认证用户, 主机向用户提供一个 (随机生成的) 质询. 用户基于质询与秘密计算某个函数并将结果提供给主机, 由主机验证. 常常此计算在手持设备中执行, 例如 DES Gold 卡.

两类方案都提供对重放攻击的防护, 但仍常常易受 Offline Keysearch Attack (离线密钥搜索攻击) (被动攻击的一种): 如前所述, 常常一次性口令或响应由共享秘密计算. 若攻击者知道所用函数, 他可以尝试所有可能的共享秘密直到找到能产生正确输出的一个. 若共享秘密是口令, 这会更容易, 此时他可以发起 Dictionary Attack (字典攻击), 即尝试常见词 (或字符串) 列表而非随机字符串.

这些系统也常常易受主动攻击. 除非为整个会话提供通信安全, 否则攻击者可以等到认证完成后劫持连接.

4.1.3. Shared Keys (共享密钥)

质询-响应类系统可以通过使用随机生成的共享密钥而非用户生成的口令来抵御字典攻击. 若密钥足够大, 密钥搜索攻击将不切实际. 当密钥配置在端节点中而非由用户记忆并键入时, 此方法效果最佳, 因为用户难以记住足够长的密钥.

与基于口令的系统一样, 共享密钥系统也存在管理问题. 每一对通信方都必须有各自商定的密钥, 从而导致密钥数量很多.

4.1.4. Key Distribution Centers (密钥分发中心)

解决密钥数量过大问题的一种途径是使用在线 "可信第三方" 在认证方之间斡旋. 该可信第三方 (通常称为 Key Distribution Center (密钥分发中心, KDC)) 与系统中每一方共享对称密钥或口令. 各方会首先联系 KDC, KDC 向其提供一张 Ticket (票据), 其中包含用双方密钥加密的随机生成的对称密钥. 由于只有正确的对等方才能解密对称密钥, 票据可用于建立可信关联. 迄今为止最流行的 KDC 系统是 Kerberos [KERBEROS].

4.1.5. Certificates (证书)

一种简单做法是让所有用户持有 Certificate (证书) [PKIX], 然后以某种协议特定方式用于认证, 如 [TLS] 或 [S/MIME]. 证书是将实体身份与其公钥绑定的签名凭证. 证书的签名者是 Certificate Authority (证书颁发机构, CA), 其证书本身可能由上级 CA 签名. 为使该系统工作, 必须以一种带外方式建立对一个或多个 CA 的信任. 此类 CA 称为 Trusted Roots (可信根) 或 Root CAs (根 CA). 在客户端-服务器型系统中, 此方法的主要障碍是要求客户端持有证书, 这可能带来部署问题.

4.1.6. Some Uncommon Systems (若干不常见系统)

存在比上述方案做得更好的途径, 但除非采用通信安全 (至少消息完整性) 来保护连接, 否则它们通常不会增加太多安全性, 因为否则攻击者可以在认证完成后仅仅劫持连接. 若干协议 ([EKE], [SPEKE], [SRP]) 允许将用户口令安全引导成可用作密码协议输入的共享密钥. 部署这些协议的一大障碍是其知识产权状况极不明朗. 同样, 用户可以使用公钥证书认证 (例如 S-HTTP 客户端认证). 通常这些方法作为更完整安全协议的一部分使用.

4.1.7. Host Authentication (主机认证)

主机认证带来特殊问题. 相当常见的是, 服务地址以 DNS 主机名呈现, 例如作为 URL [URL]. 请求此类服务时, 必须确保与之通信的实体不仅持有证书, 且该证书与服务器预期身份对应. 重要的是在证书与预期主机名之间建立安全绑定.

例如, 若请求针对给定主机名, 通常不能接受证书仅以 IP 地址形式包含身份. 这不能提供端到端安全, 因为除非使用安全名称解析 [DNSSEC], 否则主机名到 IP 的映射并不安全. 当主机名在应用层呈现而认证在较低层执行时, 这是特别的问题.

4.2. Generic Security Frameworks (通用安全框架)

在协议中提供安全功能可能很困难. 除了选择认证与密钥建立机制的问题外, 还需要将其集成到协议中. 对此问题的一种回应 (体现在 IPsec 与 TLS 中) 是创建较低层的安全协议, 然后坚持新协议在该协议之上运行. 近来流行的另一种方法是设计通用的应用层安全框架. 其思路是设计一种允许以可插拔方式协商各种安全机制的协议. 应用协议设计者随后安排在其应用协议中承载安全协议 PDU. 此类框架的示例包括 GSS-API [GSS] 与 SASL [SASL].

通用框架方法存在若干问题. 首先, 它极易遭受 Downgrade Attack (降级攻击). 在降级攻击中, 主动攻击者篡改协商, 迫使双方协商出弱于本可协商到的保护. 可以在协商与密钥建立都完成后包含完整性检查, 但该完整性检查的强度必然限于最弱的共同算法. 此问题存在于任何协商方法, 但通用框架加剧了它, 因为它鼓励应用协议作者只规定框架而不深入思考合适的底层机制, 尤其因为机制所能提供的安全程度差异很大.

另一个问题是并不总是显而易见框架中的各种安全功能如何与应用层协议交互. 例如, SASL 可以仅用作认证框架, 此时发生 SASL 交换但连接的其余部分不受保护, 也可以协商流量保护, 例如通过将 GSS 作为机制. 要知道在什么情况下流量保护是可选的, 在什么情况下是必需的, 需要思考威胁模型.

一般而言, 认证框架在向具有预先存在的遗留认证系统的系统添加新协议时最有用. 框架允许新部署提供更好的认证, 同时不强迫现有站点完全重做其遗留认证系统. 当系统的安全需求可以明确识别且仅使用少数几种认证形式时, 选择单一安全机制会带来更简单与更可预测的行为. 若必须使用框架, 设计者应该仔细审查框架的选项, 并仅规定适合其特定威胁模型的机制. 若需要框架, 设计者应该选择已建立的框架之一, 而非自行设计.

4.3. Non-repudiation (不可否认性)

对不可否认性的朴素做法是对内容使用公钥数字签名. 希望受约束的一方 (Signing Party, 签名方) 对有关消息进行数字签名. 对方 (Relying Party, 依赖方) 随后可以指向数字签名作为签名方一度同意争议内容的证明. 遗憾的是, 此方法并不充分.

签名方否认消息的最简单途径是声称其私钥已泄露, 某个攻击者 (未必是依赖方) 签署了争议消息. 为防御此攻击, 依赖方需要证明签名方的密钥在签名时并未泄露. 这需要大量基础设施, 包括证书撤销信息的归档存储以及时间戳服务器以确立消息签署时间.

此外, 依赖方可能试图诱骗签名方签署一条消息却以为在签署另一条. 当依赖方控制签名方用于签署的基础设施时, 此问题尤其严重, 例如自助服务终端场景. 许多此类场景中签名方的密钥保存在智能卡上, 但要签署的消息由依赖方显示.

所有这些复杂性使不可否认性在实践中成为难以部署的服务.

4.4. Authorization vs. Authentication (授权与认证)

Authorization (授权) 是确定已认证方是否有权访问特定资源或服务的过程. 尽管紧密相关, 务必认识到认证与授权是两个独立机制. 或许正因为这种紧密耦合, 有时错误地认为认证蕴含授权. 认证仅标识一方, 授权界定其是否可以执行某项动作.

授权必然依赖认证, 但仅有认证并不蕴含授权. 相反, 在授予执行某动作的许可之前, 必须咨询授权机制以确定该动作是否被允许.

4.4.1. Access Control Lists (访问控制列表)

一种常见的授权机制是 Access Control List (访问控制列表, ACL), 列出获准访问某资源的用户. 由于为每个资源单独指定授权权限很繁琐, 资源常常分层排列, 使父资源的 ACL 被子资源继承. 这允许管理员设置顶层策略并在必要时覆盖.

4.4.2. Certificate Based Systems (基于证书的系统)

在使用用户名与口令等简单认证机制时, 认证与授权的区别很直观 (即人人都理解管理员账户与普通用户账户的区别), 但在更复杂的认证机制下, 这一区别有时会模糊.

例如对于证书, 出示有效签名并不意味着授权. 签名必须由包含可信根的证书链支持, 且该根必须在给定上下文中受信任. 例如, 持有 Acme MIS CA 所签发证书的用户可能拥有与持有 Acme Accounting CA 所签发证书的用户不同的 Web 访问权限, 即便这两个 CA 都被 Acme Web 服务器 "信任".

强制这些更复杂属性的机制尚未被完全探索. 一种做法是将策略附加到 ACL, 描述信任哪些类型的证书. 另一种做法是将该信息与证书一并携带, 作为证书扩展/属性 [PKIX, SPKI] 或单独的 "Attribute Certificate (属性证书)".

4.5. Providing Traffic Security (提供流量安全)

设计良好的协议应提供某种机制来保护 (指完整性保护, 认证以及可能的加密) 所有敏感流量. 一种做法是保护协议本身, 如 [DNSSEC], [S/MIME] 或 [S-HTTP]. 尽管这提供最贴合协议的安全, 也需要大量努力才能做好.

许多协议可以使用现有信道安全系统得到充分保护. 我们将讨论两种最常见的: IPsec [AH, ESP] 与 [TLS].

4.5.1. IPsec

IPsec 协议 (具体为 AH 与 ESP) 可以为两台主机之间的所有流量提供传输安全. IPsec 协议支持不同粒度的用户标识, 例如 "IP Subnet (IP 子网)", "IP Address (IP 地址)", "Fully Qualified Domain Name (完全限定域名)" 以及单个用户 ("Mailbox name (邮箱名)"). 这些不同级别的标识用作 IPsec 内在访问控制设施的输入. 然而, 给定 IPsec 实现可能不支持所有身份类型. 特别地, 安全网关可能不提供 user-to-user (用户到用户) 认证, 或没有机制向应用提供该认证信息.

当使用 AH 或 ESP 时, 应用程序员可能无需做任何事 (若已在系统范围启用 AH 或 ESP), 也可能需要做特定软件更改 (例如添加特定的 setsockopt() 调用), 取决于正在使用的 AH 或 ESP 实现. 遗憾的是, 控制 IPsec 实现的 API 尚未标准化.

使用 IPsec 保护其他协议的主要障碍是部署. 目前 IPsec 的主要用途是 VPN 应用, 尤其是远程网络访问. 若安全管理员与应用开发者之间没有极其紧密的协调, VPN 用法不太适合为单个应用提供安全服务, 因为此类应用难以确定事实上提供了哪些安全服务.

在 host-to-host (主机到主机) 环境中 IPsec 部署缓慢. 与 TLS 等应用安全系统不同, 向非 IPsec 系统添加 IPsec 通常涉及更改操作系统, 要么修改内核要么安装新驱动. 这比仅仅安装新应用要大得多. 然而, 近来多种商品化操作系统的版本包含 IPsec 栈, 因此部署正在变得更容易.

在确信 IPsec 可用的环境中, 它是保护应用通信流量的可行选项. 若要保护的流量是 UDP, IPsec 与特定于应用的对象安全是唯一选项. 然而, 设计者绝对不能假定 IPsec 可用. 通用应用层协议的安全策略不应该仅仅声明必须使用 IPsec, 除非有理由相信 IPsec 在预期部署环境中可用. 在 IPsec 可能不可用且流量仅为 TCP 的环境中, TLS 是首选方法, 因为应用开发者可以通过在其软件包中包含 TLS 实现来轻易确保其存在.

在 IPv6 的特殊情况下, AH 与 ESP 均为必须实现 (mandatory to implement). 因此, 对仅 IPv6 协议或仅 IPv6 部署, 有理由假定 AH/ESP 已可用. 然而, 自动密钥管理 (IKE) 并不要求实现, 因此协议设计者不应该假定其存在. [USEIPSEC] 对何时选择 IPsec 提供了大量指导.

4.5.2. SSL/TLS

目前最常见的方法是使用 SSL 或其继任者 TLS. 它们在应用层为 TCP 连接提供信道安全. 也就是说, 它们在 TCP 之上运行. SSL 实现通常提供类似 Berkeley Sockets 的接口以便于编程. 围绕 TLS 设计协议解决方案时的主要问题是要区分使用 TLS 保护的连接与未保护的连接.

使用的两种主要方法是: 为 TLS 连接使用单独的 well-known port (知名端口) (例如 HTTP over TLS 的端口为 443) [HTTPTLS], 或具备从基础协议向上协商到 TLS 的机制, 如 [UPGRADE] 或 [STARTTLS]. 使用向上协商策略时, 必须小心确保攻击者无法在双方都希望使用 TLS 时强迫使用明文连接.

注意, TLS 依赖诸如 TCP 或 SCTP 等可靠协议. 这带来两个显著困难. 首先, 它不能用于保护使用 UDP 的数据报协议. 其次, TLS 易受 IP 层攻击, 而 IPsec 则不然. 通常, 这些攻击采取拒绝服务或连接终止的形式. 例如, 攻击者可能伪造 TCP RST 以关闭 SSL 连接. TLS 具有检测截断攻击的机制, 但这些机制仅允许受害者知道正遭受攻击, 并不能在此类攻击面前维持连接存活. 相比之下, 若使用 IPsec, 此类伪造 RST 可以在不影响 TCP 连接的情况下被拒绝. 若伪造 RST 或对 TCP 连接的其他此类攻击令人担忧, 则 AH/ESP 或 TCP MD5 选项 [TCPMD5] 是首选.

4.5.2.1. Virtual Hosts (虚拟主机)

若对 TLS 采用 "单独端口" 方法, 则在发送任何应用层流量之前就会协商 TLS. 这可能给使用 virtual hosts (虚拟主机) 的协议 (如 [HTTP]) 带来问题, 因为服务器在 TLS 握手期间不知道应向客户端提供哪张证书. TLS hostname extension (主机名扩展) [TLSEXT] 可用于解决此问题, 尽管它太新, 尚未广泛部署.

4.5.2.2. Remote Authentication and TLS (远程认证与 TLS)

使用 TLS 的一个困难是服务器通过证书认证. 在以前仅客户端与服务器之间共享口令作为认证形式的环境中, 这可能不便. 很容易想用未认证服务器的 TLS (即匿名 DH 或自签名 RSA 证书), 然后通过 SASL 与 CRAM-MD5 等质询-响应机制认证.

遗憾的是, SASL 与 TLS 的这种组合比人们预期的要弱. 主动攻击者很容易劫持此连接. 客户端对 SSL 连接实施中间人攻击 (记住我们没有认证服务器, 而通常正是这一点阻止该攻击), 然后简单地代理 SASL 握手. 从那时起, 至少就攻击者而言, 连接如同明文. 为防止此攻击, 客户端需要验证服务器的证书.

然而, 若服务器已认证, 质询-响应就不那么理想. 若你已有加固信道, 简单口令就很好. 事实上, 可以说它们优于质询-响应, 因为不要求在服务器上以明文存储口令. 因此, 质询-响应系统的密钥文件泄露比使用简单口令更严重.

注意, 若客户端有证书, 则可以使用基于 SSL 的客户端认证. 为简化此过程, SASL 提供 EXTERNAL 机制, SASL 客户端可以告诉服务器 "检查外层信道以获取我的身份". 显然, 这不受上述分层攻击影响.

某些特殊情况下可能值得在应用中直接提供信道级安全, 而非使用 IPSEC 或 SSL/TLS. 远程终端安全即为一例. 字符通常一次一个地从客户端送到服务器. 由于 SSL/TLS 与 AH/ESP 对每个分组都进行认证与加密, 这可能意味着数据膨胀约 20 倍. telnet encryption option (加密选项) [ENCOPT] 通过放弃消息完整性来避免这种膨胀.

使用远程终端服务时, 常常希望安全地执行其他通信服务. 除提供远程登录外, SSH [SSH] 还为任意 TCP 端口提供安全端口转发, 从而允许用户在 SSH 信道之上运行任意基于 TCP 的应用. 注意, 若不当使用 SSH 端口转发以绕过防火墙并将不安全的内部应用不当暴露给外界, 可能成为安全问题.

4.6. Denial of Service Attacks and Countermeasures (拒绝服务攻击与对策)

拒绝服务攻击太常被当作生活现实. 一个问题是攻击者常常可以从许多种拒绝服务攻击中选择一种对受害者下手, 而由于大多数此类攻击无法挫败, 常见智慧往往认为, 既然还有许多其他可能的拒绝服务攻击无法预防, 就没有必要防护某一种拒绝服务攻击.

然而, 并非所有拒绝服务攻击都同等重要, 更重要的是, 可以设计协议使拒绝服务攻击变得更困难, 若非不切实际. 近期的 SYN flood 攻击 [TCPSYN] 同时体现了这两点: SYN flood 攻击如此简单, 匿名且有效, 以致比其他攻击更吸引攻击者, 也因为 TCP 的设计而得以实施.

由于完整的 DoS 防护非常困难, 对 DoS 的安全必须务实处理. 特别地, 某些希望防护的攻击可能无法经济地防护. 目标应是通过防护那些攻击严重性与防护成本之比足够高的攻击来管理风险. 攻击的严重性与防护成本都会随技术变化, 因此应当防护的攻击集合也随之变化.

互联网标准的作者必须描述其协议易受哪些拒绝服务攻击. 该描述必须包含未能尝试避免这些拒绝服务攻击是因为不合理还是超出范围的原因.

Blind (盲) 拒绝服务攻击尤其险恶. 在盲攻击中, 攻击者拥有显著优势. 若攻击者必须能够接收来自受害者的流量, 则他必须要么破坏路由结构要么使用自己的 IP 地址. 两者都给受害者提供追踪攻击者和/或过滤其流量的机会. 在盲攻击中, 攻击者可以使用伪造 IP 地址, 使受害者极难过滤其分组. TCP SYN flood 攻击是盲攻击的示例. 设计者应尽一切可能防止盲拒绝服务攻击.

4.6.2. Distributed Denial of Service (分布式拒绝服务)

更危险的是 Distributed (分布式) 拒绝服务攻击 (DDoS) [DDOS]. 在 DDoS 中, 攻击者安排多台机器同时攻击目标机器. 通常通过感染大量机器使其运行允许远程发起攻击的程序来完成. 实际执行攻击的机器称为 Zombie (僵尸机), 很可能属于毫不知情的第三方, 且与真实攻击者地理位置完全不同. DDoS 攻击可能很难对抗, 因为僵尸机表面上像是在发起合法的协议请求,

只是将真实用户排挤出去. DDoS 攻击可能难以阻止, 但协议设计者在设计协议时预期应意识到这些攻击形式.

4.6.3. Avoiding Denial of Service (避免拒绝服务)

使拒绝服务攻击更困难的两种常见途径是:

4.6.3.1. Make your attacker do more work than you do (让攻击者比你做更多工作)

若攻击者在发起攻击时消耗的资源比你更多, 资源少于你的攻击者将无法发起有效攻击. 一种常见技术是要求攻击者执行耗时操作, 例如密码学操作. 注意, 若攻击者能集结明显更多的 CPU 能力, 仍可能发起拒绝服务攻击. 例如, 此技术无法阻止 [TCPSYN] 中描述的分布式攻击.

4.6.3.2. Make your attacker prove they can receive data from you (让攻击者证明能收到你的数据)

盲攻击可以通过强迫攻击者证明其能接收来自受害者的数据来化解. 常见技术是要求攻击者使用在消息交换更早阶段获得的信息进行回复. 若使用此对策, 攻击者要么使用自己的地址 (使其易于追踪), 要么伪造一个会沿经过攻击发起主机的路径路由回来的地址.

小子网上的主机因此对攻击者无用 (至少在欺骗攻击的语境下), 因为攻击可以追溯到一个子网 (应足以定位攻击者), 从而可以采取反制措施 (例如, 边界路由器可以配置为丢弃来自该子网的所有流量). 常见技术是要求攻击者使用在消息交换更早阶段获得的信息进行回复.

4.6.4. Example: TCP SYN Floods (示例: TCP SYN 洪泛)

TCP/IP 易受 SYN flood 攻击 (见第 3.3.2 节), 原因在于三次握手的设计. 首先, 攻击者可以通过发送单个分组迫使受害者消耗大量资源 (此处为内存). 其次, 因为攻击者无需从受害者接收数据即可执行此动作, 攻击可以匿名进行 (因此可使用大量伪造源地址).

4.6.5. Example: Photuris (示例: Photuris)

[PHOTURIS] 规定了一种 anti-clogging (防拥塞) 机制, 防止类似 SYN flood 的攻击针对 Photuris. Photuris 使用时间变化的秘密生成 "cookie (饼干)", 返回给攻击者. 该 cookie 必须在后续消息中返回, 交换才能继续. 有趣之处在于, 该 cookie 可以在交换稍后由受害者重新生成, 因此在攻击者证明其能接收来自受害者的分组之前, 受害者无需保留状态.

4.7. Object vs. Channel Security (对象安全与信道安全)

在概念上区分 object security (对象安全) 与 channel security (信道安全) 很有用. 对象安全指适用于整个数据对象的安全措施. 信道安全措施提供安全信道, 对象可以在其上透明承载, 但信道对对象边界没有特殊了解.

考虑电子邮件消息的情形. 当它在 IPSEC 或 TLS 保护的连接上传输时, 消息在传输过程中受保护. 然而, 它在接收者的邮箱中以及沿途中间 spool (假脱机) 文件中不受保护. 此外, 由于邮件服务器通常以守护进程而非用户身份运行, 对消息的认证一般仅意味着对守护进程而非用户的认证. 最后, 由于邮件传输是逐跳 (hop-by-hop) 的, 即使用户向第一跳中继认证, 接收者也无法安全地验证该认证.

相比之下, 当电子邮件用 S/MIME 或 OpenPGP 保护时, 整条消息被加密并受完整性保护, 直到接收者检查并解密. 它还提供对实际发送方 (而非消息来自的机器) 的强认证. 这是对象安全. 此外, 接收者可以向第三方证明签名消息的真实性.

注意, 对象安全与信道安全的区别取决于视角. 协议栈某一层的对象安全在上一层看来常常像信道安全. 因此, 从 IP 层视角, 每个分组像是单独保护的对象. 但从 Web 客户端视角, IPSEC 只是提供安全信道.

区别并不总是泾渭分明. 例如, S-HTTP 为单个 HTTP 事务提供对象级安全, 但 Web 页面通常由多个 HTTP 事务组成 (基础页面与大量内嵌图像). 因此, 从整个 Web 页面视角, 这更像信道安全. Web 页面的对象安全将是对页面及其所有嵌入内容作为单一单元的传递闭包提供安全.

4.8. Firewalls and Network Topology (防火墙与网络拓扑)

在现代网络中, 常见安全做法是用防火墙将网络划分为外部与内部网络. 随后假定内部网络是安全的, 仅在那里使用有限的安全措施. 此类网络的内部部分常称为 Walled Garden (围墙花园).

互联网协议设计者不能安全地假定其协议将部署在此类环境中, 原因有三. 首先, 原本设计用于封闭环境的协议后来常常在公网上部署, 从而产生严重漏洞.

第二, 看似在拓扑上隔离的网络未必如此. 一个原因可能是网络已重新配置以允许外界访问. 此外, 防火墙越来越多地放行通用应用层协议, 如 [SOAP] 或 [HTTP]. 基于这些通用协议的网络协议一般不能假定防火墙会保护它们. 最后, 对系统最严重的安全威胁之一来自内部人员而非外部人员. 由于内部人员按定义可以访问内部网络, 防火墙等拓扑防护无法防护他们.