分类目录归档：SiteLog

QUIC 存在 UDP 反射 DDoS 攻击漏洞吗？

发表于由
回复

今年年初，360信息安全部发布了一篇关于利用 UDP 反射 DDoS 的分析报告：Memcache UDP反射放大攻击技术分析。报告一出，引起了业界的普遍关注。根据文中所述，光是Qrator Labs 在 medium.com 上 批露的一次DDoS攻击看，其攻击流量峰值达到 480Gbps。而360信息安全团队本身也监测和确认有更大的攻击已经实际发生，只是未被公开报道。

而就在这个这个事件纰漏没多久，我把博客升级为支持基于 UDP 的 QUIC 协议来改善小站的访问体验：本站开启支持 QUIC 的方法与配置。本着小站没几人访问的蜜汁自信，当时也没太纠结 QUIC 是否也存在 UDP 反射漏洞。前几天，看到著名博主，阮一峰同学网站被 DDoS 攻击，心里咯噔一下：出来混迟早是要还的，还是填坑为安吧。

什么是 UDP 反射 DDoS 攻击

简单讲，就是攻击者利用IP网络不做真实源地址检查的“设计缺陷“，向提供基于 UDP 服务的服务器发送伪造源地址（一般为被攻击者的主机IP）的 UDP 报文请求，使得这些 UDP 报文的响应数据都会发送给被攻击者主机，这种攻击我们称之为 UDP 反射 DDoS 攻击。

之所以要通过被利用的服务器反射流量到被攻击的服务器，是因为被利用的服务器一般存在流量放大效应。即一个伪造IP的 UDP 请求发送到到被利用服务器后，被利用服务器会发送比请求更多的数据到被攻击者服务器。

被利用服务器输出流量与输入流量的比值我们称之为放大系数。这个系数与被利用服务器所提供的 UDP 服务有关。之前提到的利用 Memcache 漏洞的 DRDoS 攻击，可以获得稳定的 60000 倍放大系数。而我们日常使用的 DNS 则可以轻松的获得 50 倍的放大系数。

由放大系数反推，我们可以知道，如果一个 UDP 服务被利用以后，放大系数小于等于1的话，则不存在利用价值，因为这个时候，只从带宽流量方面考虑的话，还不如直接利用攻击主机对被攻击服务器进行攻击效率高。

QUIC 存在 UDP 反射攻击漏洞吗

按照蛤乎惯例，照顾猴急的同学，先给结论：可以。

QUIC 主要通过以下机制来解决该问题：

  1. 对于首次发起建立 QUIC 连接的客户端，服务端要求其初始化的 hello 数据包必须完全填充。这个包在 IPv4 下一般是 1370 字节，在 IPv6 下是 1350 字节。在 QUIC 协议中，服务器和客户端数据交互的基本单位是就是 UDP 数据包，而一个全填充的数据包已经达到了数据包大小的上限，因此服务器的响应数据包一定是小于等于这个 hello 数据包的。显然，放大系数小于等于1. 因此，新连接的建立没有反射利用的价值。
  2. 建立 QUIC 连接后，客户端发出的数据包就不会全填充了。这个时候，如果被 UDP 反射利用，放大系数是大于1的。因此, QUIC 引入了源地址token (source address token)：在成功建立 QUIC 连接后，服务器会用发放一个源地址token给客户端，并要求客户端在后续的数据包中带上这个token；服务器只对源地址token有效的数据包进行处理。源地址token中一般包含客户端的源地址和服务器的时间。因此这是一个客户端证明其IP所有权的凭证。
  3. 由于源地址token可能会被网络中的攻击者嗅探收集，因此 QUIC 设计了一套源地址token的过期和刷新机制。另一方面，每次客户端发送的数据包如果都带上源地址token的话，不仅客户端流量大，服务器验证token也是额外的开销，使得协议延迟变高。因此 QUIC 协议允许客户端按照一个动态策略选择是否在数据包中夹带源地址token：服务器端收集和统计源地址的数据包，当统计到源地址数据包交互响应异常的数量超过阈值时，要求该源地址的客户端必须夹带源地址token, 对于无法提供合法源地址的token的请求进行 reject 处理。

扩展阅读

魔鬼在细节中：Base64 你可能不知道的几个细节

发表于由
回复

Base64 是我们常用的编码方式，广泛用于邮件编码、数据签名/数据校验编码以及HTML/XML复杂数据编码。这本来是一个花两分钟了解一下就无需关注的技术，但是最近线上遇到一个相关问题。于是重新梳理了一下 Base64, 发现了一些以前未曾注意到的细节，记录如下，希望对你也有帮助。

Base64 是什么？

Base64 是一种将二进制数据表示为可打印字符的编码方法。基本操作是将3个字节编码为4个 Base64 单元：3 * 8 bit = 4 * 6 bit. 这种编码方法常用于处理文本数据的场合，例如在 HTML/XML 中表示、传输、存储一些二进制数据（如数据签名、数据校验等）。Base64 编码后数据增长为原来的 4/3 ≈ 1.33 倍。相较于将二进制数据按照十六进制输出数据增长为原来2倍，Base64 更加节省空间。Base64 的标准是 RFC 4648，如果你不想直接阅读这个拗口啰嗦的RFC，可以继续往下看。

Base64 不是什么？

Base64 不是一种加密方式，因此它不提供任何安全特性。我们在论坛、个人博客中发现很多人使用 Base64 编码显示自己邮箱主要是避免被搜索引擎及其他批量化工具发现和索引。

Base64 编码结果是唯一的吗？

不是的。Base64 根据编码字典表不同以及是否 padding (使用=作为 padding 字符)，对同一数据的编码结果可能不同。使用最多的字典表有两个：

                      Table 1: The Base 64 Alphabet

     Value Encoding  Value Encoding  Value Encoding  Value Encoding
         0 A            17 R            34 i            51 z
         1 B            18 S            35 j            52 0
         2 C            19 T            36 k            53 1
         3 D            20 U            37 l            54 2
         4 E            21 V            38 m            55 3
         5 F            22 W            39 n            56 4
         6 G            23 X            40 o            57 5
         7 H            24 Y            41 p            58 6
         8 I            25 Z            42 q            59 7
         9 J            26 a            43 r            60 8
        10 K            27 b            44 s            61 9
        11 L            28 c            45 t            62 +
        12 M            29 d            46 u            63 /
        13 N            30 e            47 v
        14 O            31 f            48 w         (pad) =
        15 P            32 g            49 x
        16 Q            33 h            50 y


         Table 2: The "URL and Filename safe" Base 64 Alphabet

     Value Encoding  Value Encoding  Value Encoding  Value Encoding
         0 A            17 R            34 i            51 z
         1 B            18 S            35 j            52 0
         2 C            19 T            36 k            53 1
         3 D            20 U            37 l            54 2
         4 E            21 V            38 m            55 3
         5 F            22 W            39 n            56 4
         6 G            23 X            40 o            57 5
         7 H            24 Y            41 p            58 6
         8 I            25 Z            42 q            59 7
         9 J            26 a            43 r            60 8
        10 K            27 b            44 s            61 9
        11 L            28 c            45 t            62 - (minus)
        12 M            29 d            46 u            63 _
        13 N            30 e            47 v           (underline)
        14 O            31 f            48 w
        15 P            32 g            49 x
        16 Q            33 h            50 y         (pad) =

这两个字典表的区别主要是 62 和 63 使用的字符不同（我们将这两个字符称为特殊字符）。因此，对于同一数据最多可能有 2 * 2 = 4 种编码结果。以 0x0F0xF1(2 bytes)为例，有以下4种编码结果：

  • 字典表1 + padding: D/E=
  • 字典表1 + nopadding: D/E
  • 字典表2 + padding: D_E=
  • 字典表2 + nopadding: D_E

这种一个数据有多个编码结果的情况，往往会给我们解码带来困扰。因此，在使用 Base64 的场景中，务必在文档中注明你是使用的哪一个字典表以及是否需要 padding. 当然，国内环境对文档普遍不够重视，在这么小的技术点上写如此细致是不敢奢望的，有一条有用的经验是：在没有特殊说明的情况下，技术文档中的 Base64 一般是指 字典表1 + padding.

Base64 是 url/filename safe 的吗？

如上所诉，我们默认的 Base64 编码使用的是字典表1，而这个字典表中的字符 + 和 / 无论是在url还是文件系统中都是特殊字符。因此，基于字典表1的Base64编码不是 url/filename safe 的，不能将该 Base64 编码直接与url拼接或用来命名文件。基于字典表2的 Base64 编码是 url/filename safe 的。但它不是我们大部分编程语言的默认字典，因此，你如果选择这个字典进行 Base64 编码，在解码时也选择该字典。否则你有很大概率会遇到部分数据能解码，部分数据不能解码的问题。

Base64 可以自定义特殊字符吗？

字典表2使用了不一样的 62 和 63 特殊字符以实现 url/filename safe. 但这可能无法满足所有应用场景。因此根据 RFC, 你是可以自定义这两个特殊字符建立自己的字典表的。有一点需要注意，如果你使用了自定义字典表，那么请确保自己编码和解码使用的字典表是一致的。

Base64 编码结果中的等号（=）可以省略吗？是多余的设计吗？

可以省略，但不是多余的设计。

我们先看为何可以省略：

对于数据 A, 如果我们省略padding的等号，解码的时候我们从QQ是可以推断出来，原始数据长度必然是1 byte, 因此可以可以正确解码。数据 BC 同理。

既然 padding 的等号完全不影响解码，是否可以取消这个设计呢？答案是否定的。对于一些将多个Base64编码拼接在一起的场景，padding的等号可以标记一个 Base64 编码单元的边界，使得拼接后的 Base64 编码整体是可以无歧义正确解码的。如果省略等号，则无法保证无歧义性。我们看一个例子：

  • I Base64编码为 SQ (SQ== with padding)
  • AM Base64编码为 QU0 (QU0= with padding)
  • Daniel Base64编码为 RGFuaWVs (RGFuaWVs with padding)

如果使用省略等号的方式，拼接后的Base64编码是 SQQU0RGFuaWVs, 因为我们无法区分边界，我们只能对整个字符串进行解码，显然解码结果是不正确的。如果我们不省略等号，则拼接后的编码 SQ==QU0=RGFuaWVs 可以根据等号区分边界，然后分块正确解码。

扩展阅读

What a May Day

发表于由
回复

周四晚上跟生日的父母吃过晚饭后，傻乎乎的带着小梦梦在孩子王逛，一点没有意识到已经是五月的最后一天。有时候，记录的习惯更多的就是提醒自己，时间的昼夜不舍。

这个月有意识的接触了挺多人，对于鄙人这种社交贫瘠的人来说，这个月花在这方面的时间算是奢侈的了。有老友也有新朋友。一次跟新朋友印象深刻的夜谈。已经很久没有跟新认识的人如此没有负担的沟通和交流了。对了，上一次有意思的聊天也是去年的这个时候。初夏，真是一个神奇的时节，一切都开始要变得明亮而耀眼。

五月在做和要做的事情越来越多，一种此情无计可消除，才下眉头，却上心头之感。一部分算是甜蜜的负担，而立之年，一些事情逐渐跟自己是否准备好已经没有必然关系，而是直接去解决它就对了。一部分是多过去时光的辜负，亡羊补牢，希望犹未晚矣。前天看韩老师的5X兴趣社区，看到李伟龙一个视频的幕后花絮，对话挺走心的：时间只会让你老去，其他什么都不会带来；只有你想改变的时候，你才能改变。

神奇的五月，居然达成了跑渣的第一次5公里（一个都不好意思提的配速）。从去年4月份参加跑团开始跑步，到现在已经一年多了，跑步成绩上没有任何提升，也是我预料之中的。对于这件事，我其实想得很明白：我一点都不喜欢运动，但是要支撑我的情怀和要做的事情，我必须要有这个练习和准备。显然，如果保持当前的做事的节奏，也许一周一次的跑步很快就无法支撑自己在做的事情，但是只要保持这件事情的惯性，我相信这股力量不会让自己失望。

这个月最喜欢的书是吴军老师的《智能时代》。因为一直在订阅吴军老师在得到的专栏，因此书中的很多内容其实都在专栏中听过了（如此说来，维护专栏及时高产如母猪，也是需要有存货当备份的?）。有两点体会最深：

  1. 人类文明发展是一个不短加速的过程，每一次加速都会让已有产业与新结束结合形成形成新的产业，赶上这个浪潮的会以数量级的优势领先，赶不上或者不愿拥抱变革的则会被无情的淘汰。
  2. 大数据和AI是当前最有可能成为下一个时代的蒸汽机和电。超越时代是困难的，但是从思维方式上则是可以刻意练习大数据和AI思维的。对于程序员而言，这尤为重要——有很大可能性，这决定了当前的你是成为为工业时代的码农，还是智能时代的工程师。

六月会迎来自己在两个月前设定的一个deadline, 从目前看来，不容乐观。可能当时在设定这个目标的时候，其实内心的真实独白就已经是法乎其中则得其下，法乎其上则得其中。但是，总的来说，过去的两个月无论是还在发生还是已经发生的事，多少带来了一丝丝改变。

期待六月，不负好时光。