Laurent Joncheray E-mail: lpj@merit.edu
★ 这篇文章和yuri volobuev的<<利用ARP和SQL数据库的一些攻击整理的关于网络欺骗攻击的内容 Nessus安全测试插件编写教程110个针对分布式拒绝服务攻击有关的快速补救措施常见IP碎片攻击详解tcp/ip基础知识IP欺骗的原理一个多功能linux 后门的源代码 攻击CISCO路由器简评黑客的终极武器-DDoS相关链接共 44 篇','相关的链接')" href="http://www.safechina.net/article/showarticle.php?id=1004154014#"ICMP玩重定向的游戏>>
都是很早的文章了，前面在本版贴过上篇的翻译，这次贴这篇。
文章虽然早，可我仅仅是出于计算机普及的微小抱负给那些懒得
看米国文字的朋友们一个机会。什么时候我们后面的那些少年
能自己写出这样的文章探索这样的技术，那我就不用再来做计算
机普及啦，学风不正也许是我们的通病，以致小弟才疏学浅，连
翻译都是牛头不对马嘴，永远的遗憾吧
1. 介绍
被动攻击使用简述Sniffer Nmap网络安全扫描器说明(1)网络安全方面的专业词汇嗅探原理与反嗅探技术详解 Windows快捷方式可能导致本地拒绝服务和用户口令散列值泄漏以及执行恶意程序 简单的针对TCP的主动攻击(转载)整理的关于网络欺骗攻击的内容 深入探索MS SQL Server 2000网络连接的安全问题 Sniffit 0.3.7 FOR NT的安装和示例Passive Analysis of SSH (Secure Shell) Traffic相关链接共 38 篇','相关的链接')" href="http://www.safechina.net/article/showarticle.php?id=1004154014#"sniffer，现在越来越普遍。然而人们盲目地认为主动攻击相当困难，
以至于很少有人使用。下面我们描述一次非常简单的主动攻击，它成功地被用做入侵
UNIX主机，它也可以和被动攻击sniffing一起使用。读者可以和1985年R. Morris提供的
IP Spooffing做个比较。
2. ESTABLISHED状态
2.1 TCP协议
关于TCP协议的细节请参看RFC793。
SVR_SEQ: sequence number of the next byte to be sent by the server;
SVR_ACK: next byte to be received by the server
(the sequence number of the last byte received plus one);
SVR_WIND: server"s receive window;
CLT_SEQ: sequence number of the next byte to be sent by the client;
CLT_ACK: next byte to be received by the client;
CLT_WIND: client"s receive window;
开始没有数据交换，
SVR_SEQ = CLT_ACK and CLT_SEQ = SVR_ACK.
这个个关系一直有效，只要连接的双方都不发送数据。
一旦开始发送数据，
CLT_ACK <= SVR_SEQ <= CLT_ACK + CLT_WIND
SVR_ACK <= CLT_SEQ <= SVR_ACK + SVR_WIND
TCP报文头部有如下内容：
源端口、目标端口、序列号、应答序列号、数据区偏移，控制位：
URG: Urgent Pointer;
ACK: Acknowledgment;
PSH: Push Function;
RST: Reset the connection;
SYN: Synchronize sequence numbers;
FIN: No more data from sender;
发送方窗口尺寸、TCP报文校验和(头部和数据区都包括)、TCP紧急指针，以及TCP选项。
SEG_SEQ will refer to the packet sequence number (as seen in the header).
SEG_ACK will refer to the packet acknowledgment number.
SEG_FLAG will refer to the control bits.
在一次典型的客户端发送包中(不是重发)，SEG_SEQ被设置成CLT_SEQ, SEG_ACK被设置成
CLT
ACK.
TCP使用三次握手机制建立连接，
客户端处在 CLOSED 状态，应用软件黑客入侵大揭秘关于NT LOG记录 Hacking CGI帐号安全12个有关建立防火墙的建议反NIDS技术介绍学习Linux网络编程(4)常见拒绝服务攻击类型（Dos attack）极其原理肆虐全球的尼姆达五个变种之比较Libnids-API（中文版）相关链接共 262 篇','相关的链接')" href="http://www.safechina.net/article/showarticle.php?id=1004154014#"服务器端处在 LISTEN 状态，客户端首先发送初始序列号IS
N，?
设置
SYN位：
SEG_SEQ = CLT_SEQ_0,
SEG_FLAG = SYN
客户端状态转换到 SYN-SENT
服务器端收到这个包后应答客户端，送出服务器端的初始序列号ISN，并设置SYN位：
SEG_SEQ = SVR_SEQ_0,
SEQ_ACK = CLT_SEQ_0+1,
SEG_FLAG = SYN
SVR_ACK = CLT_SEQ_0+1
服务器端状态转换到 SYN-RECEIVED
scz注：SYN flooding 攻击正是导致被攻击主机 SYN-RECEIVED 状态大量出现，
netstat -na │ grep SYN可以看到，值得注意的是这种攻击因为并不要求建
立
完整的TCP连接，所以源IP是完全可以伪造，以至于在 netstat 命令的显示
中
看到的源IP根本就不可信。TCP SYN半开扫描中如果扫描程序编写不当，也
会
短暂留下这个状态。
客户端收到这个包后应答服务器端，
SEG_SEQ = CLT_SEQ_0+1,
SEQ_ACK = SVR_SEQ_0+1
并设置
CLT_ACK = SVR_SEQ_0+1
客户端状态转换到 ESTABLISHED
服务器端收到这个包后进入 ESTABLISHED 状态。
现在有：
CLT_SEQ = CLT_SEQ_0+1
CLT_ACK = SVR_SEQ_0+1
SVR_SEQ = SVR_SEQ_0+1
SVR_ACK = CLT_SEQ_0+1
Server Client
LISTEN CLOSED
<- SYN,
CLT_SEQ_0
LISTEN SYN-SENT
SYN/ACK, ->
SVR_SEQ_0,
CLT_SEQ_0+1
SYN-RECEIVED ESTABLISHED
CLT_SEQ = CLT_SEQ_0 + 1
CLT_ACK = SVR_SEQ_0 + 1
<- ACK,
CLT_SEQ_0 + 1
SVR_SEQ_0+1
ESTABLISHED
SVR_SEQ = SVR_SEQ_0 + 1
SVR_ACK = CLT_SEQ_0 + 1
关闭一个连接可以用 FIN 标志或者 RST 标志，如果主机收到 RST，将进入 CLOSED 状
态，
释放一切与这个连接有关的资源，不会产生应答包。此后从这天连接到达的包将被丢弃
。
如果主机接收到 FIN，将进入 CLOSE-WAIT 状态，开始文明关闭连接。
请参看W. Richard Stevens的 <>。
在前面的讨论中我们特意省略了一些无关的细节，诸如带外数据、超时重传、丢包、并
发打
?
等等，这些完全可以在一次简单研究性质的攻击中被忽略。
在 ESTABLISHED 状态下，对于服务器，如果一个包的序列号位于
[SVR_ACK, SVR_ACK + SVR_WIND] 之间，对于客户端，位于 [CLT_ACK, CLT_ACK + CLT
_WIN
]
之间，则这个包可以被接受。如果序列号超出了范围，这个包将被丢弃，同时会发送一
鲇?
?
包，指明期待的序列号，例如：
SEG_SEQ = 200,
SVR_ACK = 100,
SVR_WIND = 50
这样 SEG_SEQ > SVR_ACK + SVR_WIND，于是服务器端发送一个应答包：
SEG_SEQ = SVR_SEQ
SEG_ACK = SVR_ACK
2.2 desynchronized 状态
术语 desynchronized state 指连接双方都处在 ESTABLISHED 状态，但没有数据传送，
并?
SVR_SEQ != CLT_ACK
CLT_SEQ != SVR_ACK
只要没有数据传送，这个状态是稳定的，假如开始发送数据，有两种情形：
如果 CLT_SEQ < SVR_ACK + SVR_WIND 并且 CLT_SEQ > SVR_ACK ，则这个包被接受，包
含?
数据
将被存储起来以备后用(依赖与具体实现)，但不会被交给用户进程，因为流的开始部分
尚未
酱?
根据SVR_ACK判断)
如果 CLT_SEQ > SVR_ACK + SVR_WIND 或者 CLT_SEQ < SVR_ACK ，这个包将被丢弃。数
据?
失。
这两种情况下都不会发生数据交换。
2.3 攻击
攻击首先在TCP连接两端建立 desynchronized 状态，使之不能交换数据。第三方主机模
拟?
成一
些对TCP连接两端来说可接受的包。
假设一个TCP会话处在 desynchronized 状态，客户端发送一个包：
SEG_SEQ = CLT_SEQ
SEG_ACK = CLT_ACK
既然 CLT_SEQ != SVR_ACK ，数据不会被接受，包被丢弃。第三方发送同样的包，但是
改变
?
SEG_SEQ 和 SEG_ACK (以及校验和)：
SEG_SEQ = SVR_ACK,
SEG_ACK = SVR_SEQ
这个包被服务器端接受，数据被服务器端用户进程处理。
我们用 CLT_TO_SVR_OFFSET 表示 SVR_ACK - CLT_SEQ ，用 SVR_TO_CLT_OFFSET 表示
CLT_ACK - SVR_SEQ，攻击的第一步是生成一个从客户端到服务器端的TCP报文：
SEG_SEQ <- SEG_SEQ + CLT_TO_SVR_OFFSET
SEG_ACK <- SEG_ACK - SVR_TO_CLT_OFFSET
考虑攻击者可以监听到连接，能够伪造任意的IP报文(于是可以伪装成客户端以及服务器
端)
?
这样可以增加删除任意数据到TCP流里。比如连接是利用telnet进行远程登录，攻击者
能够
插入任意命令，echo + + > ~/.rhosts，并过滤掉那些不期望回显的信息，于是用户根
本
意识不到入侵。当然此时 CLT_TO_SVR_OFFSET 和 SVR_TO_CLT_OFFSET必须改变，新值留
给
读者做练习。
可以在telnet连接中关闭回显，以减少过滤输出的负担。我们做的实验中暴露出一个当
前
telnet实现的bug，也许是telnet协议本身的bug。如果一个TCP报文含有如下内容，
IAC DONT ECHO 和 IAC DO ECHO，一端将回答
IAC WONT ECHO 和 IAC WILL ECHO，另一端将回答
IAC DONT ECHO 和 IAC DO ECHO 等等，产生一个无限循环
2.4 TCP Ack 风暴
攻击者产生大量的TCP ACK报文，主机接收到一个不可接受的包时将回送一个包指明期待
中
的序列号(通过应答序列号)，同时使用自己的序列号。这个回送的包本身也是不可接受
的，
于是导致无限循环。
既然这些包没有携带数据，所以当他们丢失后不会被重传，意味着这些包中的某一个丢
失，
无限循环就终止。每次客户端或服务器端发送数据，循环将产生。没有数据发送也就没
有
循环出现。如果数据被发送，同时没有攻击者在半路上应答，则这些数据被重传，产生
重
传风暴，最后连接崩溃，因为没有应答ACK。如果攻击者应答了，仅仅产生一次风暴。在
练习中，攻击者经常因为网络负载而丢失数据包，应答的是第一次重传。
攻击者用2.2中描述的第二种情形的报文。第一种情形数据被接收者存储留做后用，我们
没
有检验这种情形。此时的好处是不用产生ACK风暴，但另一方面也许这种情形更危险，假
如
这些数据确实被处理了。另外对于小窗口连接，第一种情形很难实现。
3. 会话建立
这里提供了两种方法 desynchronizing a TCP connection。
还有一些可以想象，不过没有在这里描述。我们假设攻击者可以监听过路的报文。
3.1 Early desynchronization
攻击者监听从server到client的SYN/ACK包，即三次握手中的第二阶段，
侦测到这个包后攻击者给server一个RST，接着给一个SYN，用同样的TCP PORT，
||||||但用不同的序列号(参看ATK_SEQ_0)
server接收到RST先关闭第一个连接，接着在同样的端口上重开一个新的连接，但
序列号不同(SVR_SEQ_0")，然后server回送一个SYN/ACK给client。
攻击者侦测到这个包，给server一个ACK，server进入 ESTABLISHED 状态。
client早就进入 ESTABLISHED 状态，当它接收到来自server的第一个SYN/ACK。
Server Client
LISTEN CLOSED
<- SYN,
CLT_SEQ_0
SYN-RECEIVED SYN-SENT
SYN/ACK, ->
SVR_SEQ_0,
CLT_SEQ_0+1
ESTABLISHED
CLT_SEQ = CLT_SEQ_0 + 1
CLT_ACK = SVR_SEQ_0 + 1
<= RST,
CLT_SEQ_0 + 1
CLOSED
<= SYN,
ATK_SEQ_0
SYN/ACK, ->
SVR_SEQ_0",
ATK_SEQ_0 + 1
SYN-RECEIVED
<= SYN,
ATK_SEQ_0 + 1,
SVR_SEQ_0" + 1
ESTABLISHED
SVR_SEQ = SVR_SEQ_0" + 1
SVR_ACK = ATK_SEQ_0 + 1
现在两端处在 desynchronized ESTABLISHED 状态
根据定义
CLT_TO_SVR_OFFSET = SVR_ACK - CLT_SEQ
SVR_TO_CLT_OFFSET = CLT_ACK - SVR_SEQ
现在
CLT_TO_SVR_OFFSET = ATK_SEQ_0 - CLT_SEQ_0 (被攻击者)
SVR_TO_CLT_OFFSET = SVR_SEQ_0 - SVR_SEQ_0" (被server)
攻击的成功依赖于正确地选择 CLT_TO_SVR_OFFSET 的值。错误的值也许使得client
的包是可接受的，产生不期待的结果。
3.2 Null data desynchronization
下列方案可以用于一次telnet会话：
攻击者监视一次会话，不要介入。
适当的时候，攻击者发送大量的null data到server。null data意指那些不影响server
的任意数据，除了改变TCP应答序列号。比如，在一个telnet会话中，攻击者发送
ATK_SVR_OFFSET 这么多字节，包含序列 IAC NOP IAC NOP...
每两个字节 IAC NOP 将被telnet daemon解释，从数据流中移走，不做任何其他事情。
现在server有
SVR_ACK = CLT_SEQ + ATK_SVR_OFFSET
这当然是 desynchronized 。
攻击者对client做同样的事情。
如果会话可以携带null data，这种方法非常有用。但是攻击者开始发送数据的时间非常
难以确定，也许引发一些不可预知的影响。
4. 例子
下面的系统管理员如何防范黑客攻击如何阅读源代码NT/2000下删日志的方法SQL Server 2000的安全配置什么是入侵检测Win NT/2000的安全隐患Nimda/尼姆达蠕虫报告_updateUnix黑客初学者指导一个2000的日志清除器是怎么练成的Linux下的代理服务器设置相关链接共 81 篇','相关的链接')" href="http://www.safechina.net/article/showarticle.php?id=1004154014#"日志由tcpdump提供，该tcpdump位于client所在局域网中，注释由##起头。
第一个例子是35.42.1.56(client)到198.108.3.13(server)之间的一个普通telnet会话
：
## The client sends a SYN packet, 1496960000 is ISN
35.42.1.56.1374 > 198.108.3.13.23: S 1496960000:1496960000(0)
win 4096
## The server answers with its ISN and the SYN flag
198.108.3.13.23 > 35.42.1.56.1374: S 1402880000:1402880000(0)
ack 1496960001 win 4096
## The client acknowledges the SYN packet
35.42.1.56.1374 > 198.108.3.13.23: . 1496960001:1496960001(0)
ack 1402880001 win 4096
## Now the two end points are in the ESTABLISHED state.
## The client sends 6 bytes of data.
35.42.1.56.1374 > 198.108.3.13.23: P 1496960001:1496960007(6)
ack 1402880001 win 4096 255 253 /C 255 251 /X
... ...
## 这是文明关闭连接的日志
198.108.3.13.23 > 35.42.1.56.1374: F 1402880059:1402880059(0)
ack 1496960025 win 4096
35.42.1.56.1374 > 198.108.3.13.23: . 1496960025:1496960025(0)
ack 1402880060 win 4096
35.42.1.56.1374 > 198.108.3.13.23: F 1496960025:1496960025(0)
ack 1402880060 win 4096
198.108.3.13.23 > 35.42.1.56.1374: . 1402880060:1402880060(0)
ack 1496960026 win 4095
下面的例子是同样的会话，只是攻击者已经开始实施入侵。
desynchronized状态按照3.1中所讲述的办法建立，攻击者将加入命令"ls;"到
TCP数据流中，从用户这边看象下面这个样子：
telnet 198.108.3.13
Trying 198.108.3.13 ...
Connected to 198.108.3.13.
Escape character is "^".
SunOS UNIX (_host)
login: lpj
s/key 70 cn33287
(s/key required)
Password:
Last login: Wed Nov 30 11:28:21 from homefries.merit.edu
SunOS Release 4.1.3_U1 (GENERIC) #2: Thu Jan 20 15:58:03 PST 1994
(lpj@_host: 1) pwd
Mail/ mbox src/
elm* resize* traceroute*
/usr/users/lpj
(lpj@_host: 2) history
1 13:18 ls ; pwd
2 13:18 history
(lpj@_host: 3) logoutConnection closed by foreign host.
用户仅仅用了pwd和history两条命令，history表明ls已经被执行了，这里ls的输出
没有被过滤。下面的日志显示了client和server之间的数据交换。不幸的是，日志中
一些包丢失了，被sniffer的以太网接口驱动程序丢弃了。攻击者的窗口尺寸被设置成
一个不寻常的值(400, 500, 1000)，为的是便于分辨这些包。攻击者在35.42.1.146，
与server隔了3跳，在从client到server的路上。
## The client sends a SYN packet, 896896000 is its ISN
35.42.1.146.1098 > 198.108.3.13.23: S 896896000:896896000(0) win 4096
## The server answers with its ISN (1544576000) and the SYN flag.
198.108.3.13.23 > 35.42.1.146.1098: S 1544576000:1544576000(0)
ack 896896001 win 4096
## The client acknowledges the SYN packet. It is in the ESTABLISHED stat
e no
.
35.42.1.146.1098 > 198.108.3.13.23: . 896896001:896896001(0)
ack 1544576001 win 4096
## The client sends some data
35.42.1.146.1098 > 198.108.3.13.23: P 896896001:896896007(6)
ack 1544576001 win 4096 255 253 /C 255 251 /X
## The attacker resets the connection on the server side
35.42.1.146.1098 > 198.108.3.13.23: R 896896101:896896101(0) win 0
## The attacker reopens the connection with an ISN of 601928704
35.42.1.146.1098 > 198.108.3.13.23: S 601928704:601928704(0) win 500
## The server answers with a new ISN (1544640000) and the SYN flag.
198.108.3.13.23 > 35.42.1.146.1098: S 1544640000:1544640000(0)
ack 601928705 win 4096
## Since the last packet is unacceptable for the client, it acknowledges
it
## with the expected sequence number (1544576001)
35.42.1.146.1098 > 198.108.3.13.23: . 896896007:896896007(0)
ack 1544576001 win 4096
## Retransmission to the SYN packet triggered by the unacceptable last p
acke
198.108.3.13.23 > 35.42.1.146.1098: S 1544640000:1544640000(0)
ack 601928705 win 4096
## The ACK storm loop
35.42.1.146.1098 > 198.108.3.13.23: . 896896007:896896007(0)
ack 1544576001 win 4096
198.108.3.13.23 > 35.42.1.146.1098: S 1544640000:1544640000(0)
ack 601928705 win 4096
35.42.1.146.1098 > 198.108.3.13.23: . 896896007:896896007(0)
ack 1544576001 win 4096
... ...
198.108.3.13.23 > 35.42.1.146.1098: S 1544640000:1544640000(0)
ack 601928705 win 4096
35.42.1.146.1098 > 198.108.3.13.23: . 896896007:896896007(0)
ack 1544576001 win 4096
198.108.3.13.23 > 35.42.1.146.1098: S 1544640000:1544640000(0)
ack 601928705 win 4096
35.42.1.146.1098 > 198.108.3.13.23: . 896896007:896896007(0)
ack 1544576001 win 4096
## Eventually the attacker acknowledges the server SYN packet with the a
ttac
er"s new
## sequence number (601928705). The data in this packet is the one previ
ousl
## sent by the client but never received.
35.42.1.146.1098 > 198.108.3.13.23: . 601928705:601928711(6)
ack 1544640001 win 400 255 253 /C 255 251 /X
## Some ACK storm
198.108.3.13.23 > 35.42.1.146.1098: . 1544640001:1544640001(0)
ack 601928711 win 4090
35.42.1.146.1098 > 198.108.3.13.23: . 896896007:896896007(0)
ack 1544576001 win 4096
198.108.3.13.23 > 35.42.1.146.1098: . 1544640001:1544640001(0)
ack 601928711 win 4090
35.42.1.146.1098 > 198.108.3.13.23: . 896896007:896896007(0)
ack 1544576001 win 4096
... ...
35.42.1.146.1098 > 198.108.3.13.23: . 601928728:601928728(0)
ack 1544640056 win 1000
## A retransmission by the client
35.42.1.146.1098 > 198.108.3.13.23: P 896896018:896896024(6)
ack 1544576056 win 4096 255 253 /A 255 252 /A
198.108.3.13.23 > 35.42.1.146.1098: . 1544640059:1544640059(0)
ack 601928728 win 4096
... ...
35.42.1.146.1098 > 198.108.3.13.23: . 896896025:896896025(0)
ack 1544576059 win 4096
198.108.3.13.23 > 35.42.1.146.1098: . 1544640059:1544640059(0)
ack 601928728 win 4096
## The user ID second character.
35.42.1.146.1098 > 198.108.3.13.23: P 896896025:896896026(1)
ack 1544576059 win 4096 p
198.108.3.13.23 > 35.42.1.146.1098: . 1544640059:1544640059(0)
ack 601928728 win 4096
... ...
35.42.1.146.1098 > 198.108.3.13.23: . 6019
