如何在scapy中欺骗TCP握手？

Question

我最近尝试编写一个执行完整TCP握手的Scapy脚本。我的想法是，我使用-net socket用户空间接口（它似乎处理原始IP /以太网正常）连接两个Qemu VM，并指示机器B阻止来自A的所有输入（以防止它发送RST）。然后，我从机器A到B使用telnet到connect()并在机器B上运行以下脚本：

#!/usr/bin/python

import scapy.all as scapy

filter = "port 31337"
iface = "eth0"

def prepare_response(t):
    print("Received: %s" % repr(t))
    t.src, t.dst = t.dst, t.src  # swap ethernet addresses
    ip = t.getlayer("IP")
    ip.src, ip.dst = ip.dst, ip.src
    t.dport, t.sport = t.sport, t.dport
    t.ack = t.seq
    t.ack += 1

syn = scapy.sniff(filter=filter, count=1, iface=iface)[0]
print(syn.sprintf('%TCP.flags%'))

syn_ack = syn
prepare_response(syn_ack)
syn_ack.getlayer("TCP").flags |= 0x10  # set the ACK flag
print(syn_ack.sprintf('%TCP.flags%'))

print("Sending: %s" % repr(syn_ack))
scapy.sendp(syn_ack, iface=iface, verbose=False)

ack = scapy.sniff(filter=filter, count=1, iface=iface)[0]
assert(ack.flags & 0x10)

问题是，我没有收到从A到B的ACK，而是似乎得到了SYN重传，好像没有正确解释SYN + ACK：

机器A上的 tcp确认SYN + ACK已到达机器：

05:47:03.925100 IP 10.0.0.1.39634 > debian.31337: Flags [S], seq 2426802888, win 14600, options [mss 1460,nop,nop,sackOK,nop,wscale 4], length 0
05:47:03.927515 IP debian.31337 > 10.0.0.1.39634: Flags [S.], seq 2426802888, ack 2426802889, win 14600, options [mss 1460,nop,nop,sackOK,nop,wscale 4], length 0

以下是来自机器B的Base64形式的PCAP文件：

  

1MOyoQIABAAAAAAAAAAAAP // AAABAAAAYlilUwieDgARAQAAEQEAAAEAXgAA + 1JUABI0VggARQABA2UUQAD / ESrYCgAAAuAAAPsU6RTpAO / R / QAAAAAAAwAAAAUAAAE2ATUBNAEzATIBMQFlAWYBZgFmATABMAE0ATUBMAE1ATABMAEwATABMAEwATABMAEwATABMAEwATABOAFlAWYDaXA2BGFycGEAAP8AAQtkZWJpYW4tMTA5MwVsb2NhbAAA / wABATIBMAEwAjEwB2luLWFkZHLAUAD / AAHAWgANAAEAAAB4AAsESTY4NgVMSU5VWMBaAAEAAQAAAHgABAoAAALAcQAMAAEAAAB4AALAWsBaABwAAQAAAHgAEP6AAAAAAAAAUFQA // 4SNFbADAAMAAEAAAB4AALAWmJYpVMJoA4AnAAAAJwAAAABAF4AAPtSVAASNFYIAEUAAI4GlEAA / xGJzgoAAAHgAAD7FOkU6QB6hFgAAIQAAAAAAQAAAAABNgE1ATQBMwEyATEBZQFmAWYBZgEwATABNAE1ATABNQEwATABMAEwATABMAEwATABMAEwATABMAEwATgBZQFmA2lwNgRhcnBhAAAMgAEAAAB4ABIKZGViaWFuLTQwNwVsb2NhbABnWKVTvIYIAEIAAABCAAAAUlQAEjRWUlQAEjRWCABFAAA0HdtAAEAGCOcKAAABCgAAAprbemmul / p8AAAAAIACOQhjsAAAAgQFtAEBBAIBAwMEZ1ilU5COCABCAAAAQgAAAFJUABI0VlJUABI0VggARQAANB3bQABABgjnCgAAAgoAAAF6aZrbrpf6fK6X + n2AEjkIY7AAAAIEBbQBAQQCAQMDBGhYpVPTfggAQgAAAEIAAABSVAASNFZSVAASNFYIAEUAADQd3EAAQAYI5goAAAEKAAACmtt6aa6X + nwAAAAAgAI5CGOwAAACBAW0AQEEAgEDAwRqWKVTrI4IAEIAAABCAAAAU lQAEjRWUlQAEjRWCABFAAA0Hd1AAEAGCOUKAAABCgAAAprbemmul / p8AAAAAIACOQhjsAAAAgQFtAEBBAIBAwME

从A到B的角度来看：

  

1MOyoQIABAAAAAAAAAAAAP // AAABAAAAVVilU9NXCABCAAAAQgAAAFJUABI0VlJUABI0VggARQAANB3bQABABgjnCgAAAQoAAAKa23pprpf6fAAAAACAAjkIFCkAAAIEBbQBAQQCAQMDBFVYpVPIYAgAQgAAAEIAAABSVAASNFZSVAASNFYIAEUAADQd20AAQAYI5woAAAIKAAABemma266X +妇女Nyul / p9gBI5CGOwAAACBAW0AQEEAgEDAwRWWKVT008IAEIAAABCAAAAUlQAEjRWUlQAEjRWCABFAAA0HdxAAEAGCOYKAAABCgAAAprbemmul / p8AAAAAIACOQgUKQAAAgQFtAEBBAIBAwMEWFilU4FfCABCAAAAQgAAAFJUABI0VlJUABI0VggARQAANB3dQABABgjlCgAAAQoAAAKa23pprpf6fAAAAACAAjkIFCkAAAIEBbQBAQQCAQMDBA ==

起初我认为这与某些Linux TCP / IP怪癖有某种关系，所以我尝试关闭TCP时间戳和SYN cookie。我也尝试增加IP ID，这也没有帮助。两台机器都在qemu 1.6.2下使用linux-image-3.2.0-4-686-pae运行Debian 7.5。我错过了什么？

Answer 1

那是校验和问题。

在IP层中它恰好是正常的，因为您只是交换源地址和目标地址，但是在TCP层中，当您更改标志值时，原始校验和会出错。

最好的选择是让Scapy为您计算正确的校验和值，方法是在del(t[TCP].chksum)中添加prepare_response()。