几天前，我的同事Marek发送了一封电子邮件，内容是针对我们的一个DNS服务器的DDoS攻击，我们使用BPF规则阻止了该攻击。他注意到IP报头中的TTL字段和IPv4源地址之间似乎有一种奇怪的关联。2.0图片由杰里米·基思提供源地址像往常一样被欺骗了，显然是随机选择的，但是发生了其他事情。他给第一个想出满意解决办法的人一瓶苏格兰威士忌。以下是一些数据包的样子：$tcpdump-ni eth0-c 10"ip[8]=40和udp和端口53"1.181.207.7.46337>x.x.x.53:65098+1.178.97.141.45569>x.x.x.53:65101+1.248.136.142.63489>x.x.x.53:65031+1.207.241.195.52993>x.x.x.53:65072+$tcpdump-ni eth0-c 10"ip[8]=41和udp和端口53"2.10.30.2.2562>x.x.x.53:65013+2.4.9.36.1026>x.x.x.53:65019+2.98.1.99.25090>x.x.x.53:64925+2.109.69.229.27906>x.x.x.53:64914+$tcpdump-ni eth0-c 10"ip[8]=42和udp和端口53"4.72.42.184.18436>x.x.x.53:64439+4.240.78.0.61444>x.x.x.53:64271+5.73.44.84.18693>x.x.x.53:64182+4.69.99.10.17668>x.x.x.53:64442+我删除了目标IP地址，但留下了DNS ID号（后面带加号的数字）、伪造的源IP和端口。有三种不同的TTL通过ip过滤表示（40、41和42）[8]。如果你想自己去想办法的话，别在这里读了。变成六边形我无法抗拒马雷克的挑战，所以我做了我一直在做的事情：我直接去了妖术。因为Marek没有给我pcap，所以我手动将前几个转换成hex。hex之所以有用是因为字节、单词、dword和qword是计算的真正内容，而查看十进制数据会使数据变得模糊。取前三个（每个TTL一个），我看到了这个模式：1.181.207.7.463372.10.30.2.25624.72.42.184.18436它们被转换成十六进制01.b5.cf.07.b50102.0a.1e.02.0a0204.48.2a.b8.4804很明显，"random"源端口是随机IP源地址倒转的前两个字节：01.b5.cf.07有源端口b501。稍加修改就发现了TTL和IP地址的第一个字节之间的关系。TTL=第一个字节>>1+40后来的一个包证实了这种关系，该包的TTL为150，源IP为220.255.141.181。右移还解释了为什么在第一个字节相差1时使用相同的TTL（参见上面的第三组示例：4.x.x.x和5.x.x.x具有相同的TTL）。然后我发现DNS ID字段也与IP地址相关。1.181.207.7.46337>x.x.x.53:65098+转换为十六进制：01.b5.cf.07.b501>x.x.x.35:fe4a+乍一看可能并不明显（除非你是一个十六进制级别的黑客），但fe4a是01b5的一个补充。所以dnsid字段只是源IP前两个字节的1的补码。最后，马雷克给了我一个pcap，我还有一段感情要找。IPv4头中的ID值也与随机源IP地址有关实际上，它只是IP地址的前两个字节。神秘还有一个谜团（还有一件CloudFlare T恤是为最有说服力的人设计的）：随机源IP是如何生成的？答案可能很无聊（也就是说，它可能只是从/dev/random读取字节），但是考虑到作者对字段之间关系的热爱，也许还有其他事情要做。我们已经看到IP地址被重用，这让我们认为这里有些东西需要发现。以下是实际源IP的序列：218.254.187.1518.187.160.236123.73.134.18668.133.199.20205.26.91.155169.235.56.12096.160.119.22144.226.72.236205.26.91.155140.206.27.9270.62.151.0161.98.197.249我们不能保证攻击者是按照这个顺序生成它们的，但是也许有一种有趣的方式来生成它们。如果你能找到答案，请在评论中给出答案！