一周前，我们发表了一篇关于在UDP端口11211上使用memcached协议的新的放大攻击的文章。从那以后发生了一些事情：Github宣布它是1.3Tbps memcached攻击的目标。OVH和Arbor报告了类似的大规模攻击，峰值为1.7Tbps。让我们深呼吸，并讨论为什么在现代互联网上如此大规模的DDoS攻击是可能的。大型攻击使用IP欺骗DaPuglet的CC BY-SA 2.0图像所有巨大的头条新闻攻击都是我们称之为"L3"（第3层OSI[1]）。这种攻击有一个共同的特点，即恶意软件向网络发送尽可能多的数据包。为了获得更快的速度，这些数据包是由攻击者手工制作的——它们不是使用高级、行为良好的库生成的。数据包以一系列字节的形式混合在一起，然后发送到网络上，造成最大的损害。L3攻击可分为两类，具体取决于攻击者将其流量定向到何处：直接：直接针对受害者IP发送流量。SYN flood是这种类型的常见攻击。放大：流量被发送到易受攻击的UDP服务器。他们反过来通过向不知情的受害者发送大量的响应来反映和放大它。这两种类型的攻击都要求攻击者进行IP欺骗[2]。当攻击者使用伪造的源IP地址发送IP包时，会发生IP欺骗。这就像在一封信上伪造一个回信地址，假装是别人。欺骗源IP地址在技术上并不具有挑战性。每台连接到internet的机器都可以传输他们选择的任何字节—包括在源IP地址字段中设置任意值。只不过，当这些数据包被允许进入广域网时，会造成很大的损害。直接攻击在直接攻击中，流量直接发送给受害者。这有一个好的方面-目标可以调查源IP！由于Cloudflare经常是此类攻击的目标，因此我们偶尔会查看数据并获得一些乐趣。为了可视化攻击的源IP，最好使用Hilbert曲线。Randall Munroe在这个著名的XKCD中推广了这项技术。总的想法是很好的-用花哨的数学方法在一张二维地图上画出所有的2**32 IP。CC BY-NC 2.5图像由Randall Munroe提供下面是一些我们在过去看到的IP欺骗的直接攻击。在第一个方案中，攻击者在整个IP空间中不加区别地欺骗，包括多播IP范围、保留块和军用前缀。更有趣的是，攻击者甚至欺骗了127.0.0.0/8范围。事实上，我们可以定期确认可怕的攻击来源——127.0.0.1次攻击。CC BY-NC 2.5图像由Randall Munroe提供这是另一个例子。在此期间，一些IP范围（保留多播和127.0.0.0/8）未被使用：攻击者是否足够聪明，可以跳过保留的源IP？不太可能。一个合理的解释是，流量通过一个路由器过滤这些明显错误的来源。我们也看到过喜欢左派的袭击者：或者在互联网的右边：我们已经看到了许多令人兴奋的欺骗IP源模式。关键是：在直接攻击期间，你不能信任源IP！攻击者可以设置他们选择的值。在缓解中使用源IP可能行不通，在地理地图上绘制它们毫无意义。放大攻击在放大攻击中，攻击者发送的流量具有不同的特点。源IP被欺骗并设置为受害者的IP地址。流量被发送到易受攻击的放大服务器。受害者只能看到易受攻击服务器的IP。最常见的视觉化以某种方式将它们展现在地球仪上。例如，在最近的基于memcached的攻击中，以下是滥用服务器的地图：为什么IP欺骗是一件事？到目前为止讨论的攻击依赖于IP欺骗。但是为什么IP欺骗是可能的呢？这是互联网设计的副作用。因特网有三种特性，使得在接收端验证数据包是否合法是不可能的。首先是"多主页"——一种允许互联网互联的功能。有了多主网络，就可以有不止一个互联网提供商。在接收端，我们不知道发送方有多少提供者，也没有办法确保特定路径是合法的。其次，还有互联网的动态特性。路径会随着时间而改变，这使得部署静态过滤规则变得很脆弱。即使我们知道某些IP范围只能从一条路径到达我们，这也会随着时间的推移而改变。还有路由不对称。"从我到你的最佳路径必须与从你到我的最佳路径"这条天真的规则在第2层和第1层被打破。在现实世界中，两个方向的路径都是不同的，所以我们不能使用最佳路径作为过滤规则的提示。有效的过滤防止IP欺骗只能在网络的边缘-在最后一英里ISP。即使这样做也很难。如果我还没有说服你，这里有一个更具体的例子来说明这个问题。FooCorp示例让我介绍一个示例公司FooCorp，它拥有IP范围：192.0.2.0/24和2001:db8:：/48。这家公司位于犹他州斯诺维尔的一座闪亮的办公楼里，通过一根电缆连接到互联网，由一家名为UtahCom的运营商运营。比如说，我们Cloudflare非常担心这些特定的IP范围，并希望确保除了FooCorp之外，没有人可以欺骗它们。假设我们也直接连接到UtahCom载体。一切都很美好！通过查看图片，我们可以知道192.0.2.0/24和2001:db8:：/48中源IP的所有流量都必须通过UtahCom进行传输。对抗IP欺骗是微不足道的！我们可以很容易地阻止来自任何其他提供商的ipss192.0.2.0/24和2001:db8:：/48源代码，对吗？不幸的是，这不是互联网的工作方式。一天，FooCorp决定从SayIdahocom获得第二个互联网连接。Cloudflare也连接到了IdahoCom和。。。... 现在我们所有的IP欺骗假设都被打破了。来自192.0.2.0/242001:db8:：/48的流量现在可以通过UtahCom或IdahoCom发送！从Cloudflare-the receiver的角度来看，我们现在几乎无法进行任何源IP过滤！此外，即使我们看到了来自FoocorpIPS的数据包，比如印尼电信公司（IndonesiaCom），我们仍然无法真正过滤它们。很有可能FooCorp刚刚获得了更多的互联网连接。。。我猜是卫星连接。。。来自印度尼西亚。听起来不太可能，但这完全是可以想象的。雪上加霜的是，UtahCom的IP过滤逻辑也并非平庸。虽然它绝对不应该允许FooCorp从任意源ip发送流量，但它不能真正过滤来自ips192.0.2.0/242001:db8:：/48来自其他提供者的数据包。例如，如果UtahCom和IdahoCom是互连的，它们之间完全可以交换192.0.2.0/242001:db8:：/48流量！解决问题解决IP欺骗很困难，必须在最后一英里内完成（尽可能靠近通信源）。互联网社区多年前就明白了这一点，并写下了著名的BCP38：https://tools.ietf.org/html/bcp38它深入到我上面解释的内容。只有最后一英里的ISP才能执行源IP过滤和防止IP欺骗。互联网运营商对此无能为力。或者可以吗？互联网运营商事实证明，互联网运营商可以提供帮助。他们可以做两件事。首先，他们可以清理自己的网络，并设置过滤功能。虽然不可能确保没有人欺骗FooCorp的192.0.2.0/242001:db8:：/48范围，但完全可以确保FooCorp不能欺骗其他人！但这不是小事。原则上，FooCorp的IP范围可能会随着时间而变化，但此类事件应要求通知运营商，出示授权书并验证IRR数据库（另请参阅RADb）。其次，虽然大型的1级和2级提供商不能进行源IP过滤，但它们可以帮助进行调查。记住-在大型放大攻击期间，攻击者欺骗受害者的IP范围。在攻击期间，大型运营商应该帮助调试，并能够识别哪些付费客户假装是受害者！为了做到这一点，一些运营商维护内部netflow/IPFIX基础设施。社区应该开始问运营商一些棘手的问题——你知道谁欺骗了流量吗？你在内部做netflow吗？你能有效地使用它吗？我相信Github想知道是谁伪造了他们的源IP，以便产生1.3Tbps的放大。互联网交换机互联网交易所也面临同样的归属问题。当欺骗发生时，通常不可能找出是哪个参与者发起的。互联网交易所应该把工具放在一起，允许参与者追踪伪造流量的始作俑者。一些互联网交易所已经这样做了，但大多数没有。硬件供应商一种阻止IP欺骗的常用技术称为严格的uRPF。虽然它不能用于第1层，但由于它假定了internet路由对称性，uRPF在最后一英里部署中肯定是有用的。供应商应该提供安全的默认硬件。默认情况下，在交换机上应该启用"DHCP侦听"和"IP源验证"，在路由器上应该启用"严格的uRPF"。阅读更多互联网社会的文章。同样，如果您使用Linux进行路由，则可以使用sysctl打开strict uRPF：对于/proc/sys/net/ipv4/conf/*/rp_filter中的fname；do\echo 1 | sudo T恤$fname\完成你呢最后，其他所有人都可以帮助由caida.org网站. "Spoofer"通过在你的笔记本电脑上运行一个代理来评估网络，定期探测网络。用户，尤其是重度旅行者，可能会考虑安装代理软件来帮助Caida更好地覆盖最终用户isp。最后的想法过去，业界一直在努力解决DNS和NTP协议易受放大攻击的问题。这些天我们在战斗