一 : TCP三次握手及会话劫持原理与实例05
TCP三次握手及会话劫持原理与实例
首先详细了解一下TCP三次握手的过程
三次握手Three-way Handshake
一个虚拟连接的建立是通过三次握手来实现的
1. (B) --> [SYN] --> (A)
假如服务器A和客户机B通讯. 当A要和B通信时，B首先向A发一个SYN (Synchronize) 标记的包，告诉A请求建立连接.
注意: 一个 SYN包就是仅SYN标记设为1的TCP包(参见TCP包头Resources). 认识到这点很重要，只有当A受到B发来的SYN包，才可建立连接，除此之外别无他法。因此，如果你的防火墙丢弃所有的发往外网接口的SYN包，那么你将不 能让外部任何主机主动建立连接。
2. (B) <-- [SYN/ACK] <--(A)
接着，A收到后会发一个对SYN包的确认包(SYN/ACK)回去，表示对第一个SYN包的确认，并继续握手操作.
注意: SYN/ACK包是仅SYN 和 ACK 标记为1的包.
3. (B) --> [ACK] --> (A)
B收到SYN/ACK 包,B发一个确认包(ACK)，通知A连接已建立。至此，三次握手完成，一个TCP连接完成
Note: ACK包就是仅ACK 标记设为1的TCP包. 需要注意的是当三此握手完成、连接建立以后，TCP连接的每个包都会设置ACK位
这就是为何连接跟踪很重要的原因了. 没有连接跟踪,防火墙将无法判断收到的ACK包是否属于一个已经建立的连接.一般的包过滤(Ipchains)收到ACK包时,会让它通过(这绝对不是个 好主意). 而当状态型防火墙收到此种包时，它会先在连接表中查找是否属于哪个已建连接，否则丢弃该包
四次握手Four-way Handshake
四次握手用来关闭已建立的TCP连接
1. (B) --> ACK/FIN --> (A)
2. (B) <-- ACK <-- (A)
3. (B) <-- ACK/FIN <-- (A)
4. (B) --> ACK --> (A)
注意: 由于TCP连接是双向连接, 因此关闭连接需要在两个方向上做。ACK/FIN 包(ACK 和FIN 标记设为1)通常被认为是FIN(终结)包.然而, 由于连接还没有关闭, FIN包总是打上ACK标记. 没有ACK标记而仅有FIN标记的包不是合法的包，并且通常被认为是恶意的
连接复位Resetting a connection
四次握手不是关闭TCP连接的唯一方法. 有时,如果主机需要尽快关闭连接(或连接超时,端口或主机不可达),RST (Reset)包将被发送. 注意在，由于RST包不是TCP连接中的必须部分, 可以只发送RST包(即不带ACK标记). 但在正常的TCP连接中RST包可以带ACK确认标记
请注意RST包是可以不要收到方确认的
无效的TCP标记Invalid TCP Flags
到目前为止，你已经看到了 SYN, ACK, FIN, 和RST 标记. 另外，还有PSH (Push) 和URG (Urgent)标记.
最常见的非法组合是SYN/FIN 包. 注意:由于 SYN包是用来初始化连接的, 它不可能和 FIN和RST标记一起出现. 这也是一个恶意攻击.
由于现在大多数防火墙已知 SYN/FIN 包, 别的一些组合,例如SYN/FIN/PSH, SYN/FIN/RST, SYN/FIN/RST/PSH。很明显，当网络中出现这种包时，很你的网络肯定受到攻击了。
别的已知的非法包有FIN (无ACK标记)和"NULL"包。如同早先讨论的，由于ACK/FIN包的出现是为了关闭一个TCP连接，那么正常的FIN包总是带有 ACK 标记。"NULL"包就是没有任何TCP标记的包(URG,ACK,PSH,RST,SYN,FIN都为0)。
到目前为止，正常的网络活动下，TCP协议栈不可能产生带有上面提到的任何一种标记组合的TCP包。当你发现这些不正常的包时，肯定有人对你的网络不怀好意。
UDP (用户数据包协议User Datagram Protocol)
TCP是面向连接的，而UDP是非连接的协议。UDP没有对接受进行确认的标记和确认机制。对丢包的处理是在应用层来完成的。(or accidental arrival).
此处需要重点注意的事情是：在正常情况下，当UDP包到达一个关闭的端口时，会返回一个UDP复位包。由于UDP是非面向连接的, 因此没有任何确认信息来确认包是否正确到达目的地。因此如果你的防火墙丢弃UDP包，它会开放所有的UDP端口(?)。
由于Internet上正常情况下一些包将被丢弃，甚至某些发往已关闭端口(非防火墙的)的UDP包将不会到达目的，它们将返回一个复位UDP包。
因为这个原因，UDP端口扫描总是不精确、不可靠的。
看起来大UDP包的碎片是常见的DOS (Denial of Service)攻击的常见形式 (这里有个DOS攻击的例子， ).
ICMP (网间控制消息协议Internet Control Message Protocol)
如 同名字一样， ICMP用来在主机/路由器之间传递控制信息的协议。 ICMP包可以包含诊断信息(ping, traceroute - 注意目前unix系统中的traceroute用UDP包而不是ICMP)，错误信息(网络/主机/端口 不可达 network/host/port unreachable), 信息(时间戳timestamp, 地址掩码address mask request, etc.)，或控制信息 (source quench, redirect, etc.) 。
你可以在http://www.iana.org/assignments/icmp-parameters中找到ICMP包的类型。
尽管ICMP通常是无害的，还是有些类型的ICMP信息需要丢弃。
Redirect (5), Alternate Host Address (6), Router Advertisement (9) 能用来转发通讯。
Echo (8), Timestamp (13) and Address Mask Request (17) 能用来分别判断主机是否起来，本地时间 和地址掩码。注意它们是和返回的信息类别有关的。它们自己本身是不能被利用的，但它们泄露出的信息对攻击者是有用的。
ICMP消息有时也被用来作为DOS攻击的一部分(例如：洪水ping flood ping,死 ping ?呵呵，有趣 ping of death)?/p>
包碎片注意A Note About Packet Fragmentation
如果一个包的大小超过了TCP的最大段长度MSS (Maximum Segment Size) 或MTU (Maximum Transmission Unit)，能够把此包发往目的的唯一方法是把此包分片。由于包分片是正常的，它可以被利用来做恶意的攻击。
因为分片的包的第一个分片包含一个包头，若没有包分片的重组功能，包过滤器不可能检测附加的包分片。典型的攻击Typical attacks involve in
overlapping the packet data in which packet header is 典型的攻击Typical attacks involve in overlapping the packet data in which packet header isnormal until is it overwritten with different destination IP (or port) thereby bypassing firewall rules。包分片能作为 DOS 攻击的一部分，它可以crash older IP stacks 或涨死CPU连接能力。
Netfilter/Iptables中的连接跟踪代码能自动做分片重组。它仍有弱点，可能受到饱和连接攻击，可以把CPU资源耗光。
握手阶段：
序号 方向 seq ack
1 A->B 10000 0
2 B->A 20000 10000+1=10001
3 A->B 10001 20000+1=20001
解释：
1：A向B发起连接请求，以一个随机数初始化A的seq,这里假设为10000，此时ACK＝0
2：B收到A的连接请求后，也以一个随机数初始化B的seq，这里假设为20000，意思是：你的请求我已收到，我这方的数据流就从这个数开始。B的ACK是A的seq加1，即10000＋1＝10001
3：A收到B的回复后，它的seq是它的上个请求的seq加1，即10000＋1＝10001，意思也是：你的回复我收到了，我这方的数据流就从这个数开始。A此时的ACK是B的seq加1，即20000+1=20001
数据传输阶段：
序号 方向 seq ack size
23 A->B 40000 70000 1514
24 B->A 70000 40000+1514-54=41460 54
25 A->B 41460 70000+54-54=70000 1514
26 B->A 70000 41460+1514-54=42920 54
解释：
23:B接收到A发来的seq=40000,ack=70000,size=1514的数据包
24:于是B向A也发一个数据包，告诉B，你的上个包我收到了。B的seq就以它收到的数据包的ACK填充，ACK是它收到的数据包的SEQ加上数据包的大小(不包括以太网协议头，IP头，TCP头)，以证实B发过来的数据全收到了。
25:A在收到B发过来的ack为41460的数据包时，一看到41460，正好是它的上个数据包的seq加上包的大小，就明白，上次发送的数据包已安全 到达。于是
它再发一个数据包给B。这个正在发送的数据包的seq也以它收到的数据包的ACK填充，ACK就以它收到的数据包的seq(70000)加上包 的size(54)填充,即ack=70000+54-54(全是头长，没数据项)。
其实在握手和结束时确认号应该是对方序列号加1,传输数据时则是对方序列号加上对方携带应用层数据的长度.如果从以太网包返回来计算所加的长度,就嫌走弯路了.
另外,如果对方没有数据过来,则自己的确认号不变,序列号为上次的序列号加上本次应用层数据发送长度.
通常，大家所说的入侵，都是针对一台主机，在获得管理员权限后，就很是得意；其实，真正的入侵是占领整个内部网络。 针对内部网络的攻击方法比较多，但比较有效的方法非ARP欺骗、DNS欺骗莫属了。但是，不管使用什么技术，无非都是抓取目标的数据包，然后分析出敏感数 据。如果目标内部采用的是共享式网络（采用HUB集线器连网），那只需要把网卡设置为“混杂模式”，挂上嗅探器（Sniffer），就能简听到你想得到的 数据。如果是交换式网络（采用交换机连网），这样方法就行不通了，因为对于嗅探器，有三种网络环境是无法跨越的：“网桥”、“交换机”、“路由器”。可 惜，对于ARP欺骗，交换式网络还是无能为力，如果我们借助ARP欺骗，在实现更高一层的“入侵手段”，从而真正的控制内部网络。这也就是本文要叙述的会 话劫持攻击。
一、会话劫持原理
1、什么是会话劫持
在现实生活中，比如你去市场买菜，在交完钱后你要求先去干一些别的事情，稍候再来拿菜；如果这个时候某个陌生人要求把菜拿走，卖菜的人会把菜给 陌生人吗？！当然，这只是一个比喻，但这恰恰就是会话劫持的喻意。所谓会话，就是两台主机之间的一次通讯。例如你Telnet到某台主机，这就是一次 Telnet会话；你浏览某个网站，这就是一次HTTP会话。而会话劫持（Session Hijack），就是结合了嗅探以及欺骗技术在内的攻击手段。例如，在一次正常的会话过程当中，攻击者作为第三方参与到其中，他可以在正常数据包中插入恶 意数据，也可以在双方的会话当中进行监听，甚至可以是代替某一方主机接管会话。我们可以把会话劫持攻击分为两种类型：1）中间人攻击(Man In The Middle，简称MITM)，
2）注射式攻击（Injection）；并且还可以把会话劫持攻击分为两种形式：1）被动劫持，2）主动劫持；被动劫持实 际上就是在后台监视双方会话的数据流，丛中获得敏感数据；而主动劫持则是将会话当中的某一台主机“踢”下线，然后由攻击者取代并接管会话，这种攻击方法危害非常大，攻击者可以做很多事情，比如“cat etc/master.passwd”（FreeBSD下的Shadow文件）。
MITM攻击简介
TCP三次握手及会话劫持原理与实例05_tcp三次握手
这也就是我们常说的“中间人攻击”，在网上讨论比较多的就是SMB会话劫持，这也是一个典型的中间人攻击。要想正确的实施中间人攻击，攻击者首 先需要使用ARP欺骗或DNS欺骗，将会话双方的通讯流暗中改变，而这种改变对于会话双方来说是完全透明的。关于ARP欺骗黑客防线介绍的比较多，网上的 资料也比较多，我就不在多说了，我只简单谈谈DNS欺骗。DNS（Domain Name System），即域名服务器， 我们几乎天天都要用到。对于正常的DNS请求，例如在浏览器输入www.hacker.com.cn，然后系统先查看Hosts文件，如果有相对应的 IP，就使用这个IP地址访问网站（其实，利用Hosts文件就可以实现DNS欺骗）；如果没有，才去请求DNS服务器；DNS服务器在接收到请求之后， 解析出其对应的IP地址，返回给我本地，最后你就可以登陆到黑客防线的网站。而DNS欺骗则是，目标将其DNS请求发送到攻击者这里，然后攻击者伪造 DNS响应，将正确的IP地址替换为其他IP，之后你就登陆了这个攻击者指定的IP，而攻击者早就在这个IP中安排好了恶意网页，可你却在不知不觉中已经 被攻击者下了“套”??DNS欺骗也可以在广域网中进行，比较常见的有“Web服务器重定向”、“邮件服务器重定向”等等。但不管是ARP欺骗，还是 DNS欺骗，中间人攻击都改变正常的通讯流，它就相当于会话双方之间的一个透明代理，可以得到一切想知道的信息，甚至是利用一些有缺陷的加密协议来实现。 注射式攻击简介
这种方式的会话劫持比中间人攻击实现起来简单一些，它不会改变会话双方的通讯流，而是在双方正常的通讯流插入恶意数据。在注射式攻击中，需要实 现两种技术：1）IP欺骗，2）预测TCP序列号。如果是UDP协议，只需伪造IP地址，然后发送过去就可以了，因为UDP没有所谓的TCP三次握手，但 基于UDP的应用协议有流控机制，所以也要做一些额外的工作。对于IP欺骗，有两种情况需要用到：1）隐藏自己的IP地址；2）利用两台机器之间的信任关 系实施入侵。在Unix/Linux平台上，可以直接使用Socket构造IP包，在IP头中填上虚假的IP地址，但需要root权限；在Windows 平台上，不能使用Winsock，需要使用Winpacp（也可以使用Libnet）。例如在Linux系统，首先打开一个Raw Socket（原始套接字），然后自己编写IP头及其他数据。可以参考下面的实例代码： sockfd = socket(AF_INET, SOCK_RAW, 255)；
setsockopt(sockfd, IPPROTO_IP, IP_HDRINCL, &on, sizeof(on))； struct ip *ip；
struct tcphdr *tcp；
struct pseudohdr pseudoheader；
ip-＞ip_src.s_addr = xxx；
pseudoheader.saddr.s_addr = ip-＞ip_src.s_addr；
tcp-＞check = tcpchksum((u_short *)&pseudoheader,12+sizeof(struct tcphdr))；
sendto(sockfd, buf, len, 0, (const sockaddr *)addr, sizeof(struct sockaddr_in))；
对于基于TCP协议的注射式会话劫持，攻击者应先采用嗅探技术对目标进行简听，然后从简听到的信息中构造出正确的序列号，如果不这样，你就必须先猜测目标的ISN（初始序列号），这样无形中对会话劫持加大了难度。那为什么要猜测会话双方的序列号呢？请继续往下看。
2、TCP会话劫持
本文主要叙述基于TCP协议的会话劫持。如果劫持一些不可靠的协议，那将轻而易举，因为它们没有提供一些认证措施；而TCP协议被欲为是可靠的传输协议，所以要重点讨论它。
根据TCP/IP中的规定，使用TCP协议进行通讯需要提供两段序列号，TCP协议使用这两段序列号确保连接同步以及安全通讯，系统的 TCP/IP协议栈依据时间或线性的产生这些值。在通讯过程中，双方的序列号是相互依赖的，这也就是为什么称TCP协议是可靠的传输协议（具体可参见 RFC 793）。如果攻击者在这个时候进行会话劫持，结果肯定是失败，因为会话双方“不认识”攻击者，攻击者不能提供合法的序列号；所以，会话劫持的关键是预测 正确的序列号，攻击者可以采取嗅探技术获得这些信息。
TCP协议的序列号
现在来讨论一下有关TCP协议的序列号的相关问题。在每一个数据包中，都有两段序列号，它们分别为：
SEQ：当前数据包中的第一个字节的序号
ACK：期望收到对方数据包中第一个字节的序号
假设双方现在需要进行一次连接：
S_SEQ：将要发送的下一个字节的序号
S_ACK：将要接收的下一个字节的序号
S_WIND：接收窗口
//以上为服务器（Server）
C_SEQ：将要发送的下一个字节的序号
C_ACK：将要接收的下一个字节的序号
C_WIND：接收窗口
//以上为客户端（Client）
它们之间必须符合下面的逻辑关系，否则该数据包会被丢弃，并且返回一个ACK包（包含期望的序列号）。
C_ACK <= C_SEQ <= C_ACK + C_WIND
S_ACK <= S_SEQ <= S_ACK + S_WIND
如果不符合上边的逻辑关系，就会引申出一个“致命弱点”，具体请接着往下看。
致命弱点
这个致命的弱点就是ACK风暴(Storm)。当会话双方接收到一个不期望的数据包后，就会用自己期望的序列号返回ACK包；而在另一端，这个 数据包也不是所期望的，就会再次以自己期望的序列号返回ACK包??于是，就这样来回往返，形成了恶性循环，最终导致ACK风暴。比较好的解决办法是先进 行ARP欺骗，使双方的数据包“正常”的发送到攻击者这里，然后设置包转发，最后就可以进行会话劫持了，而且不必担心会有ACK风暴出现。当然，并不是所 有系统都会出现ACK风暴。比如Linux系统的TCP/IP协议栈就与RFC中的描述略有不同。注意，ACK风暴仅存在于注射式会话劫持。
TCP会话劫持过程
假设现在主机A和主机B进行一次TCP会话，C为攻击者，劫持过程如下： A向B发送一个数据包
SEQ (hex): X ACK (hex): Y
FLAGS: -AP--- Window: ZZZZ，包大小为:60
B回应A一个数据包
SEQ (hex): Y ACK (hex): X+60
FLAGS: -AP--- Window: ZZZZ，包大小为:50
A向B回应一个数据包
SEQ (hex): X+60 ACK (hex): Y+50
FLAGS: -AP--- Window: ZZZZ，包大小为:40
B向A回应一个数据包
SEQ (hex): Y+50 ACK (hex): X+100
FLAGS: -AP--- Window: ZZZZ，包大小为:30
攻击者C冒充主机A给主机B发送一个数据包
SEQ (hex): X+100 ACK (hex): Y+80
FLAGS: -AP--- Window: ZZZZ，包大小为:20
B向A回应一个数据包
SEQ (hex): Y+80 ACK (hex): X+120
FLAGS: -AP--- Window: ZZZZ，包大小为:10
现在，主机B执行了攻击者C冒充主机A发送过来的命令，并且返回给主机A一个数据包；但是，主机A并不能识别主机B发送过来的数据包，所以主机A会以期望的序列号返回给主机B一个数据包，随即形成ACK风暴。如果成功的解决了ACK风暴（例如前边提到的ARP欺骗），就可以成功进行会话劫持了。 关于理论知识就说到这里，下面我以具体的实例演示一次会话劫持。
二、会话劫持实践
1、唠叨几句
可以进行会话劫持的工具很多，比较常用有Juggernaut，它可以进行TCP会话劫持的网络Sniffer程序；TTY Watcher，而它是针对单一主机上的连接进行会话劫持。还有如Dsniff这样的工具包也可以实现会话劫持，只是看你会不会使用了。但，能将会话劫持 发挥得淋漓尽致的，还要算Hunt这个工具了。它的作者是Pavel Krauz，可以工作在Linux和一些Unix平台下。它的功能非常强大，首先，无论是在共享式网络还是交换式网络，它都可以正常工作；其次，可以进行 中间人攻击和注射式攻击。还可以进行嗅探、查看会话、监视会话、重置会话。通过前面的叙述，我们知道在注射式攻击中，容易出现ACK风暴，解决办法是先进 行ARP欺骗；而使用Hunt进行注射式攻击时，它并不进行ARP欺骗，而是在会话劫持之后，向会话双方发送带RST标志位的TCP包以中断会话，避免 ACK风暴继续下去。而中间人攻击是先进行ARP欺骗，然后进行会话劫持。Hunt目前最新版本是1.5，可以到Pavel Krauz网站下载源代码包和二进制文件：http://lin.fsid.cvut.cz/~kra/#hunt。
现在来看看如果使用Hunt，首先是下载并编译源代码：
[root@dahubaobao hunt]#wget http://www.ringz.org/hunt-1.5.tgz
[root@dahubaobao hunt]#tar zxvf hunt-1.5.tgz
[root@dahubaobao hunt]#cd hunt-1.5
[root@dahubaobao hunt-1.5]#make
[root@dahubaobao hunt-1.5]#./hunt
//Hunt是完全交互试的操作
解释一下各个选项的含义
l/w/r) list/watch/reset connections
//l（字母l）为查看当前网络上的会话；w为监视当前网络上的某个会话；r为重置当前网络上的某个会话。
a) arp/simple hijack (avoids ack storm if arp used)
//中间人攻击（会话劫持），Hunt先进行ARP欺骗，然后进行会话劫持。使用此方法可以避免出现ACK风暴。
s) simple hijack
//简单的会话劫持，也就是注射式攻击。会出现ACK风暴。
d) daemons rst/arp/sniff/mac
//该选项共实现四个功能，分别为：终止会话，自动发送带RST标志位的TCP包；ARP欺骗后进行数据包转发；不用说了，嗅探功能；在当前网络上收集MAC地址。
其他的选项很简单，不在多说了。还是来看看具体的例子吧，我想大家都等不及了！^_^
2、应用实例
测试环境：
攻击者：Red Hat Linux 9.0 IP：192.168.0.10
主机A：Windows Advanced Server IP：192.168.0.1
主机B：FreeBSD 4.9 STABLE IP：192.168.0.20
[root@dahubaobao hunt-1.5]#./hunt
/*
* hunt 1.5
* multipurpose connection intruder / sniffer for Linux
* (c) 1998-2000 by kra
*/
starting hunt
--- Main Menu --- rcvpkt 0, free/alloc 63/64 ------
l/w/r) list/watch/reset connections
u) host up tests
a) arp/simple hijack (avoids ack storm if arp used)
s) simple hijack
d) daemons rst/arp/sniff/mac
o) options
x) exit
*＞ l //查看当前网络上的会话
0）192.168.0.1 [3465] ?192.168.0.20 [23]
//主机A正在Telnet到主机B
--- Main Menu --- rcvpkt 0, free/alloc 63/64 ------
l/w/r) list/watch/reset connections
u) host up tests
a) arp/simple hijack (avoids ack storm if arp used)
s) simple hijack
d) daemons rst/arp/sniff/mac
o) options
x) exit
*＞ w //监视当前网络上的会话
0）192.168.0.1 [3465] ?192.168.0.20 [23]
Choose conn＞0 //选择打算监视的会话。由于我的条件有限，不能模拟多个会话，请多见量。
Dump [s]rc/[d]st/[b]oth [b]＞ //回车
Print sec/dst same charactes y/n [n]＞ //回车 现在就可以监视会话了。主机A输入的一切内容，我们都可以看到。主机A在Telnet并登陆之后，直接su root，password：后边的就是root的密码。现在这个系统已经完全由你所控制了，自由发挥吧！
--- Main Menu --- rcvpkt 0, free/alloc 63/64 ------
l/w/r) list/watch/reset connections
u) host up tests
a) arp/simple hijack (avoids ack storm if arp used)
TCP三次握手及会话劫持原理与实例05_tcp三次握手
s) simple hijack
d) daemons rst/arp/sniff/mac
o) options
x) exit
*＞ s //进行注射式会话劫持
0）192.168.0.1 [3465] ?192.168.0.20 [23]
choose conn＞ 0
dump connection y/n [n]＞
Enter the command string you wish executed or [cr]＞ cat /etc/passwd 攻击者的意图是获取主机B的passwd文件的内容，但由于注射式会话劫持缺陷，导致了ACK风暴，所以Hunt向会话双方发送了一个带RST标志位的TCP包来阻止ACK风暴。
--- Main Menu --- rcvpkt 0, free/alloc 63/64 ------
l/w/r) list/watch/reset connections
u) host up tests
a) arp/simple hijack (avoids ack storm if arp used)
s) simple hijack
d) daemons rst/arp/sniff/mac
o) options
x) exit
*＞ a //进行中间人会话劫持
0）192.168.0.1 [3862] ?192.168.0.20 [23]
choose conn＞ 0
arp spoof src in dst y/n [y]＞
src MAC [XX:XX:XX:XX:XX:XX]＞
arp spoof dst in src y/n [y]＞
dst MAC [XX:XX:XX:XX:XX:XX]＞
input mode [r]aw, [l]ine+echo+\r, line+[e]cho [r]＞
dump connectin y/n [y]＞ n
press key to take voer of connection
ARP spoof of 192.168.0.20 with fake mac XX:XX:XX:XX:XX:XX in host 192.168.0.1 FA
ILED
do you want to force arp spoof nutil successed y/n [y]＞
CTRL-C to break
CTRL+C //手工输入CTRL+C中断，不需等待
-- operation canceled - press any key＞
ARP spoof failed
ARP spoof of 192.168.0.20 in host 192.168.0.1 FAILED
you took over the connection
CTRL-] to break
-bash-2.05b$id
....................
现在，攻击者已经成功的劫持了主机A和B之间的Telnet会话。主机A输入的一切命令攻击者都可以看到，并且攻击者也可以自行插入命令。正如 前边所说的，这种会话劫持方式先进行ARP欺骗，然后才劫持，所以，ACK风暴是不会出现的；而且，这种方式要比注射式会话劫持危害更大，从上文中我想就 能看出来，我就不必在多说什么了。还有一些如Sniffer等功能，都很简单，由于已不在本文范畴，故不在多说。
三、会话劫持防范
防范会话劫持是一个比较大的工程。首先应该使用交换式网络替代共享式网络，虽然像Hunt这样的工具可以在交换环境中实现会话劫持，但还是应该 使用交换式网络替代共享式网络，因为这样可以防范最基本的嗅探攻击。然而，最根本的解决办法是采用加密通讯，使用SSH代替Telnet、使用SSL代替 HTTP，或者干脆使用IPSec/VPN，这样会话劫持就无用武之地了。其次，监视网络流量，如发现网络中出现大量的ACK包，则有可能已被进行了会话 劫持攻击。
还有一点是比较重要的，就是防范ARP欺骗。实现中间人攻击的前提是ARP欺骗，如能阻止攻击者进行ARP欺骗，中间人攻击还怎样进行？！如何防范ARP欺骗，黑客防线有过详细的介绍，可以参考2003年第9期杂志。
总结
对于渗透内部网络，会话劫持确实是一种比较有效的方法，我们应该掌握。本文的实践性很强，请大家务必动手试试，并希望能掌握此技术。Hunt这个强悍的工具使用方法很简单，但却可以把会话劫持发挥淋漓尽致，真佩服作者的编程功底。
二 : TCP/IP三次握手详解
在TCP/IP协议中，TCP协议提供可靠的连接服务，采用三次握手建立1个连接。
第一次握手：建立连接时，客户端发送syn包(syn=j)到服务器，并进入SYN_SEND状态，等待服务器确认；
第二次握手：服务器收到syn包，必须确认客户的SYN（ack=j+1），同时自己也发送1个SYN包（syn=k），即SYN+ACK包，此时服务器进入SYN_RECV状态；
第三次握手：客户端收到服务器的SYN＋ACK包，向服务器发送确认包ACK(ack=k+1)，此包发送完毕，客户端和服务器进入ESTABLISHED状态，完成三次握手。
完成三次握手，客户端与服务器开始传送数据，在上述过程中，还有一些重要的概念：
未连接队列：在三次握手协议中，服务器维护1个未连接队列，该队列为每个客户端的SYN包（syn=j）开设1个条目，该条目表明服务器已收到SYN包，并向客户发出确认，正在等待客户的确认包。这些条目所标识的连接在服务器处于Syn_RECV状态，当服务器收到客户的确认包时，删除该条目，服务器进入ESTABLISHED状态。
Backlog参数：表示未连接队列的最大容纳数目。
SYN-ACK重传次数 服务器发送完SYN－ACK包，如果未收到客户确认包，服务器进行首次重传，等待一段时间仍未收到客户确认包，进行第二次重传，如果重传次数超过系统规定的最大重传次数，系统将该连接信息从半连接队列中删除。注意，每次重传等待的时间不一定相同。
半连接存活时间：是指半连接队列的条目存活的最长时间，也即服务从收到SYN包到确认这个报文无效的最长时间，该时间值是所有重传请求包的最长等待时间总和。有时我们也称半连接存活时间为Timeout时间、SYN_RECV存活时间。
====================================================================
现在，我们来看1个完整的流程，在1个TCPsocket上系统调用connect究竟是如何建立起1个到对端的连接的。我们还是以实验环境172.16.48.2向172.16.48.1的端口5002发起连接请求为例。
第1步，172.16.48.2向172.16.48.1发起连接请求，发送1个SYN段，指明目的端口5002，通告自己的初始序号（ISN，由协议栈随机产生的1个32位数），设置确认序号为0(因为还没有收到过对端的数据)，通告自己的滑动窗口大小为5840(对端是5792，这似乎有问题，有待进1步细查)，窗口扩大因子为2(在首部选项中)，通告最大报文段长度为1460(本地局域网)，下面是数据内容(已剥去链路层的以太网首部和网络层的IP首部)：
数据内容含义
基本首部
800e源端口(32782)
138a目的端口(5002)
00 00 07bc初始序号ISN
00 00 0000确认序号
a首部长度
002标志位，SYN=1
16d0滑动窗口大小(5840)
649e校验和
0000紧急指针
TCP选项
02 04 05b4最大报文段长度(1460)
0402允许SACK
08 0a 00 0a 79 14 00 00 0000时间戳(0x000a7914)，回显时间戳(0)
01占位。
03 0302窗口扩大因子(2)
第二步，172.16.48.1收到请求包，检查标志位，发现SYN=1，认为这是1个初始化连接的请求，回应这个SYN，同时也发送自己的SYN段(即ACK,SYN同时置位)。因为SYN本身要占用1个序号（还有标志FIN也要占用1个序号）。所以，确认序号设置为172.（www.61k.com）16.48.2的ISN加1(即172.16.48.1期望收到来自172.16.48.2的下1个包的第1个序号为0x07bd。同时也要通告自己的初始序号，滑动窗口大小，窗口扩大因子，最大报文段长度等，下面是数据内容：
数据内容含义
基本TCP首部
138a源端口(5002)
800e目的端口(32782)
98 8e 4091初始序号ISN
00 00 07bd确认序号(对端ISN+1)
a首部长度
012标志位，ACK=1, SYN=1
16a0滑动窗口大小
65d7校验和
0000紧急指针
TCP选项
02 04 05b4最大报文段长度(1460)
0402允许SACK
08 0a 00 3c 25 8a 00 0a 7914时间戳(0x003c258a)，回显时间戳(000a7914)
01占位
03 0302窗口扩大因子(2)
第3步，172.16.48.2对来自172.16.48.1的SYN段进行确认，至此，TCP三次握手协议完成，连接建立，在172.16.48.2收到SYN段时，将自己对应的socket的状态由TCP_SYN_SENT改为TCP_ESTABLISHED，进入连接建立状态，下面是数据内容：
数据内容含义
800e源端口(32782)
138a目的端口(5002)
00 00 07bd序号(已不是ISN了)
98 8e 4092确认序号（对端ISN+1)
8首部长度(8*4=32,有12字节的选项)
010标志，ACK=1
05b4滑动窗口大小(1460，有问题？待确认)
a58a校验和
0000紧急指针
01占位
01占位
08 0a 00 0a 79 14 00 3c 258a时间戳(0x0a007914), 回显时间戳(0x003c258a)
=====================================================================
7、简述TCP三次握手过程，并说明为什么要3次握手
TCP 三次握手
TCP 连接是通过三次握手进行初始化的。三次握手的目的是同步连接双方的序列号和确认号并交换 TCP窗口大小信息。以下步骤概述了通常情况下客户端计算机联系服务器计算机的过程：
1.客户端向服务器发送1个SYN置位的TCP报文，其中包含连接的初始序列号x和1个窗口大小（表示客户端上用来存储从服务器发送来的传入段的缓冲区的大小）。
2.服务器收到客户端发送过来的SYN报文后，向客户端发送1个SYN和ACK都置位的TCP报文，其中包含它选择的初始序列号y、对客户端的序列号的确认x+1和1个窗口大小（表示服务器上用来存储从客户端发送来的传入段的缓冲区的大小）。
3..客户端接收到服务器端返回的SYN+ACK报文后，向服务器端返回1个确认号y+1和序号x+1的ACK报文，1个标准的TCP连接完成。
TCP 使用类似的握手过程来结束连接。这可确保2个主机均能完成传输并确保所有的数据均得以接收
TCP Client Flags TCP Server
1 Send SYN (seq=x) ----SYN---> SYNReceived
2 SYN/ACK Received <---SYN/ACK----Send SYN (seq=y)， ACK(x+1)
3 Send ACK (y+1) ----ACK---> ACK Received，Connection Established
w: ISN (Initial Sequence Number) of theClient
x: ISN of the Server
==========================================================
TCP 三次握手的意义在哪里？
最好详细点，考虑全面。
我能想到的：
1.用较短的SYN包来探测目的主机端口及中间网络是否工作
2.初始化序列号
问题：TCP为什么要使用随机初始序列号？
我看过解释是防止连接失效后SOCKET被重用使得以前残留的包被错误的接受。但是现在主机刚刚释放的SOCKET不都是不可马上使用的么？
3.同步MSS
请各位补充。
1.我认为你说对了一方面，，，还有一方面就是，，，让server为client预留一部分服务器资源，，，需要注意的是，，，正是因为这样，，，就有了大家都知道的Dos（Denialof service）以及衍生出来的DDos（DistributedDos），，，后者更为可怕和难易分析监测，，，其原理就是，，，向server发出syn，，，然后呢，，，又不跟server进行进1步的通信，，，这样，，，就导致server为它白白的分配了很多资源，，，我们可以想想的是，，，当这种syn达到一定数量以后，，，server肯定会爆掉，，，这种攻击相当之恐怖，，，传说累计有几百亿美元的损失了吧，，，同时，，，这也是当今网络安全研究的1个热点，，，
2.首先，我觉得你思考倒要用随机序列号这个问题很厉害，，，
应该是这样的，，，这个是处于网络安全的角度来做的，，，如果没有随机生成tcp的序列号的话，，，hacker们即可轻易的采取某些手段猜测到你和别人通信的tcp序列号，，，并且制造tcp序列号攻击，，，这已经是当今网络上1种常见的攻击，，，tcp当时的设计者并没有考虑到这些，，，即便是这样，，，tcp序列号攻击也是有办法进行的，，，就为了防止这种攻击，，，已经有很多tcp序列号的生成算法被提出和改进，，，你可以倒ieee上面去搜下，，，较多，，，据我所知，，，unix这方面做的比windows好
三 : wireshark抓包图解 TCP三次握手/四次挥手详解
一.TCP/IP协议族
四 : TCP三次握手&四次挥手(示意图)
经典的三次握手示意图：（#add，“握手”即图中左边到右边的连线）
经典的四次握手关闭图：
TCP是主机对主机层的传输控制协议，提供可靠的连接服务，采用三次握手确认建立一个连接:
位码即tcp标志位,有6种标示:
SYN(synchronous建立联机)
ACK(acknowledgement 确认)
PSH(push传送)
FIN(finish结束)
RST(reset重置)
URG(urgent紧急)
Sequence number(顺序号码)
Acknowledge number(确认号码)
第一次握手：主机A发送位码为syn＝1,随机产生seqnumber=1234567的数据包到服务器，主机B由SYN=1知道，A要求建立联机；
第二次握手：主机B收到请求后要确认联机信息，向A发送ack number=(主机A的seq+1),syn=1,ack=1,随机产生seq=7654321的包
第三次握手：主机A收到后检查ack number是否正确，即第一次发送的seq number+1,以及位码ack是否为1，若正确，主机A会再发送ack number=(主机B的seq+1),ack=1，主机B收到后确认seq值与ack=1则连接建立成功。
完成三次握手，主机A与主机B开始传送数据。
在TCP/IP协议中，TCP协议提供可靠的连接服务，采用三次握手建立一个连接。
第一次握手：建立连接时，客户端发送syn包(syn=j)到服务器，并进入SYN_SEND状态，等待服务器确认；
第二次握手：服务器收到syn包，必须确认客户的SYN（ack=j+1），同时自己也发送一个SYN包（syn=k），即SYN+ACK包，此时服务器 进入SYN_RECV状态；
第三次握手：客户端收到服务器的SYN＋ACK包，向服务器发送确认包ACK(ack=k+1)，此包发送完毕，客户端和服务器进入 ESTABLISHED状态，完成三次握手。 完成三次握手，客户端与服务器开始传送数据.
实例:
IP 192.168.1.116.3337 > 192.168.1.123.7788: S3626544836:3626544836
IP 192.168.1.123.7788 > 192.168.1.116.3337: S 1739326486:1739326486 ack3626544837
IP 192.168.1.116.3337 > 192.168.1.123.7788: ack 1739326487,ack 1
第一次握手：192.168.1.116发送位码syn＝1,随机产生seqnumber=3626544836的数据包到192.168.1.123,192.168.1.123由SYN=1知道192.168.1.116要求建立联机;
第二次握手：192.168.1.123收到请求后要确认联机信息，向192.168.1.116发送acknumber=3626544837,syn=1,ack=1,随机产生seq=1739326486的包;
第 三次握手：192.168.1.116收到后检查ack number是否正确，即第一次发送的seq number+1,以及位码ack是否为1，若正确，192.168.1.116会再发送ack number=1739326487,ack=1，192.168.1.123收到后确认seq=seq+1,ack=1则连接建立成功。
图解：
一个三次握手的过程（图1，图2）
（图1）
（图2）
第一次握手的标志位（图3）
我们可以看到标志位里面只有一个同步位，也就是在做请求(SYN)
（图3）
第二次握手的标志位（图4）
我们可以看到标志位里面有两个确认位和同步位，也就是在做应答(SYN + ACK)
（图4）
第三次握手的标志位（图5）
我们可以看到标志位里面只有一个确认位，也就是再做再次确认(ACK)
（图5）
一个完整的三次握手也就是 请求---应答---再次确认
四次分手：
由于TCP连接是全双工的，因此每个方向都必须单独进行关闭。这个原则是当一方完成它的数据发送任务后就能发送一个FIN来终止这个方向的连接。收到一个 FIN只意味着这一方向上没有数据流动，一个TCP连接在收到一个FIN后仍能发送数据。首先进行关闭的一方将执行主动关闭，而另一方执行被动关闭。
（1）客户端A发送一个FIN，用来关闭客户A到服务器B的数据传送（报文段4）。
（2）服务器B收到这个FIN，它发回一个ACK，确认序号为收到的序号加1（报文段5）。和SYN一样，一个FIN将占用一个序号。
（3）服务器B关闭与客户端A的连接，发送一个FIN给客户端A（报文段6）。
（4）客户端A发回ACK报文确认，并将确认序号设置为收到序号加1（报文段7）。
1．为什么建立连接协议是三次握手，而关闭连接却是四次握手呢？
这是因为服务端的LISTEN状态下的SOCKET当收到SYN报文的建连请求后，它可以把ACK和SYN（ACK起应答作用，而SYN起同步作用）放在一个报文里来发送。但关闭连接时，当收到对方的FIN报文通知时，它仅仅表示对方没有数据发送给你了；但未必你所有的数据都全部发送给对方了，所以你不可以马上关闭SOCKET,也即你可能还需要发送一些数据给对方之后，再发送FIN报文给对方来表示你同意现在可以关闭连接了，所以它这里的ACK报文和FIN报文多数情况下都是分开发送的。
2．为什么TIME_WAIT状态还需要等2MSL后才能返回到CLOSED状态？
这是因为虽然双方都同意关闭连接了，而且握手的4个报文也都协调和发送完毕，按理可以直接回到CLOSED状态（就好比从SYN_SEND状态到ESTABLISH状态那样）；但是因为我们必须要假想网络是不可靠的，你无法保证你最后发送的ACK报文会一定被对方收到，因此对方处于LAST_ACK状态下的SOCKET可能会因为超时未收到ACK报文，而重发FIN报文，所以这个TIME_WAIT状态的作用就是用来重发可能丢失的ACK报文。
扩展：三次握手协议 / 三次握手 / tcp三次握手详细过程
扩展：三次握手协议 / 三次握手 / tcp三次握手详细过程
五 : 怎样生动描述 TCP 的「三次握手」？
网友舒自均对[tcp三次握手]怎样生动描述 TCP 的「三次握手」？给出的答复：
“我能给你讲个关于tcp的笑话吗?”
“行,给我讲个tcp笑话.”
“好吧那我就给你讲个tcp笑话.”
网友苏莉安对[tcp三次握手]怎样生动描述 TCP 的「三次握手」？给出的答复：
「你瞅啥？」
「瞅你咋地？」
「来咱俩唠唠。」
然后就唠上了。
网友蒙面大侠对[tcp三次握手]怎样生动描述 TCP 的「三次握手」？给出的答复：
how are you ?
fine.And you?
Fine.
俩人见面，客套完确认对方正常以后，就开始工作了。
网友张磊对[tcp三次握手]怎样生动描述 TCP 的「三次握手」？给出的答复：
不要抖机灵，三次握手即是在最快最省力的情况下做出的选择
比如在红军时代，A连和B连分在左右翼，约定在几时几分一同发起打击。这个几时几分的信息就需要人工通过通讯员来走路传递。所以A连指挥官派出通讯员。
这是第一次。
假设通讯员到达了B连，并且告知了B连指挥官几时几分，B连指挥官一定会让通讯员再回去通知A连指挥官，可怜的通讯员只能冒着危险返回A连，因为A连指挥官看不到通讯员返回的话，不知道几时几分这个信息到底传达到了B连没有。
这是第二次。
现在B连指挥官开始担心通讯员是否回到了A连，如果没回到，B连指挥官会设身处地的想一想A连指挥官见不到返回的通讯员，肯定是不敢打的，所以B连指挥官最盼望的是再次看到通讯员出现在B连，所以A连指挥官会让通讯员再回B连一次。
这是第三次。
这就是三次握手
网友匿名用户对[tcp三次握手]怎样生动描述 TCP 的「三次握手」？给出的答复：
「喂喂喂，能听到我吗？」
「没问题。能听到我说一声。」
「没问题。」
网友徐二飞对[tcp三次握手]怎样生动描述 TCP 的「三次握手」？给出的答复：
这问题答案很容易通过搜索引擎获得。
三次握手是为了确认客户端跟服务器都能接受到对方的信息。
第一次握手，客户端给服务器发包。 此时服务器确认自己可以接收客户端的包，客户端不确认服务器是否接收到了自己发的包。
第二次握手，服务器端回复客户端。 此时客户端确认自己发的包被服务器收到，也确认自己可以正常接收服务器包，客户端对此次通信没有疑问了。服务器可以确认自己能接收到客户端的包，但不能确认客户端能否接收自己发的包。
第三次握手，客户端回复服务器。 客户端已经没有疑问了，服务器也确认刚刚客户端收到了自己的包。两边都没有问题，开始通信。
针对评论里为什么是三次而不是两次四次的回答。
网友蒙面大侠对[tcp三次握手]怎样生动描述 TCP 的「三次握手」？给出的答复：
“报告大王！” （SYN）
“不要叫我大王，要叫我女王大人！” （SYN-ACK）
“好的大王！” （ACK）
“报告大王！那老汉家就在前方！” （DATA）
网友洛基克对[tcp三次握手]怎样生动描述 TCP 的「三次握手」？给出的答复：
##都在抖激灵，没一个好好回答的。真想理解的话看这里啦喂～
1、唐王欲和如来建立外交，取大乘佛法普渡亡灵。便派出唐僧西去，九九八十一难还没走完，唐王知去路艰辛，不知御弟能不能无恙抵达。
2、唐僧历尽磨难终于抵达雷音寺，如来甚是高兴，同时也明白了，大唐到我西天的来路，通了。但他却担心着来容易，想回万难的情况。于是带上真经，又让唐僧回大唐去了。一路腾云驾雾，师徒几人好不快活。
3、转眼已到大唐境内，按下祥云，直扑唐王怀中哭诉心酸去了。唐王嘴上安慰，心里乐道：有这真经为凭，说明我大唐到那西天，去得，也回得。少卿御弟泪止，于是大小法事，普渡亡灵。唐王甚欢，正愁如何封赏，却得知玄奘已成正果，回西天去了。
4、如来正值焦急之际，见金蝉子转回，随即眉开眼笑，心里好不自在：我这西天到那大唐，来得，也回得。这中土的香火，再不是那道家独吃咯。
自此，西天与大唐互通有无，佛教也在中原有了立足之地，皆大欢喜。也再无人问津唐僧师徒，跑的那三趟腿。
网友蒙面大侠对[tcp三次握手]怎样生动描述 TCP 的「三次握手」？给出的答复：
1.约吗
2.约
3.我出发了
网友吴小龙对[tcp三次握手]怎样生动描述 TCP 的「三次握手」？给出的答复：
我只是出来反对最高票的答案的，他的描述明显是不正确的。而且是严重误导的。
TCP的握手，首先要明确的是必然有发起方（A）和接收方（B）。
第一次握手，必然是A向B发起的。即A向B发送了一个SYN包。如果套用高票的情境，可以理解为："我想瞅瞅你，在吗？"。
第二次握手，B发现有一个人试图连接自己，那么就回复一个ACK包表示接收连接。即"在的，你瞅吧"。
第三次握手，是A在知道B同意让自己连接后，也向B发一个ACK包表示我已经就位。即"嗯，我已经看到你了。（隐含着意思：我接下来要一直瞅你，如果两个都没说走，谁也不能走。）"
我看到好多答主在看到几个回答后瞬间就进入抖机灵模式，而且完全不管主被动的关系，也不管合理性，最后发展成看谁写的三行短小说最好看了。
ps:高票的回答如果一定要三次握手的话，我觉得是这样：
「 。。。」 --------------------漏了第一次握手
「你瞅啥？」 --------------------第二次握手
「瞅你咋地？」 --------------------第三次握手
「来咱俩唠唠。」 -------------------多余的交互
TCP是一个丧心病狂的追求效率的协议，除非必要，绝不会有多余的报文。
网友蒙面大侠对[tcp三次握手]怎样生动描述 TCP 的「三次握手」？给出的答复：
A: 在吗？
B: 在，你还在吗？
A: 在！，那个啥啥啥啥。。。。
B: 那个啥啥啥啥。
。。。。
网友匿名用户对[tcp三次握手]怎样生动描述 TCP 的「三次握手」？给出的答复：
我：喵。
猫：喵。
我：喵。
猫: HTTP /1.1 200 OK
网友蒙面大侠对[tcp三次握手]怎样生动描述 TCP 的「三次握手」？给出的答复：
连接：
「嘿？」
「嘿！嘿？」
「嘿嘿」
断开：
「哦！」
「哦？」
「哦！」
「哦哦」
THE END
网友匿名用户对[tcp三次握手]怎样生动描述 TCP 的「三次握手」？给出的答复：
约？
约！
啪啪啪~
网友蔡希瑀对[tcp三次握手]怎样生动描述 TCP 的「三次握手」？给出的答复：
Hey, I want to hear a TCP joke.
Would you like a TCP joke?
Yes, I want to hear a TCP joke.
OK, I will tell you a TCP joke. The joke starts at 0 and it lengths 10 words.
I'm ready to hear the TCP joke which starts at 0 and lengths 10 words.
...
Sorry, connection timed out. Hey, I want to hear a TCP joke.
之前在G+看见的段子，时间久了点可能有些部分记错了。
网友周龙对[tcp三次握手]怎样生动描述 TCP 的「三次握手」？给出的答复：
1 下课了,走吧.
2 嗯,走.
3 走
网友星四对[tcp三次握手]怎样生动描述 TCP 的「三次握手」？给出的答复：
约么？
约。
好，去宾馆。
网友蒙面大侠对[tcp三次握手]怎样生动描述 TCP 的「三次握手」？给出的答复：
喂！
干啥？
我们聊天吧，从前有座山……
网友匿名用户对[tcp三次握手]怎样生动描述 TCP 的「三次握手」？给出的答复：
场景1:
A：老外，最近可好啊？
B：。。。WTF？
A：。。。
------------------
场景2:
A：老外，最近身体可好啊？
B：（浓重的老外口音）Fine.Can you speak English？（内心独白：我能听懂你说的，不过我不会说中文啊。）
A：。。。你说啥。
----------------
场景3:
A：老外，最近可好啊？
B：很好啊，你咋样？
A：挺好的。
网友匿名用户对[tcp三次握手]怎样生动描述 TCP 的「三次握手」？给出的答复：
听得见吗
听得见，你呢
嗯听见，那开始吧
。。。。
61阅读| 精彩专题| 最新文章| 热门文章| 苏ICP备13036349号-1