信安Note_day14

TCP协议

TCP四次挥手

参考博客： TCP四次挥手详解‍oOoOoOooOO的博客-CSDN博客tcp四次挥手https://blog.csdn.net/LOOKTOMMER/article/details/121307137#TCP%E5%9B%9B%E6%AC%A1%E6%8C%A5%E6%89%8B%E8%BF%87%E7%A8%8B%E5%92%8C%E7%8A%B6%E6%80%81%E5%8F%98%E8%BF%81

执行过程

在断开连接之前客户端和服务器都处于ESTABLISHED状态，双方都可以主动断开连接，以客户端主动断开连接为优。

第一次挥手：客户端打算断开连接，向服务器发送FIN报文(FIN标记位被设置为1，1表示为FIN，0表示不是)，FIN报文中会指定一个序列号，之后客户端进入FIN_WAIT_1状态。

也就是客户端发出连接释放报文段(FIN报文)，指定序列号seq = u，主动关闭TCP连接，等待服务器的确认。

第二次挥手：服务器收到连接释放报文段(FIN报文)后，就向客户端发送ACK应答报文，以客户端的FIN报文的序列号 seq+1 作为ACK应答报文段的确认序列号ack = seq+1 = u + 1。

接着服务器进入CLOSE_WAIT(等待关闭)状态，此时的TCP处于半关闭状态(下面会说什么是半关闭状态)，客户端到服务器的连接释放。客户端收到来自服务器的ACK应答报文段后，进入FIN_WAIT_2状态。

第三次握手：服务器也打算断开连接，向客户端发送连接释放(FIN)报文段，之后服务器进入LASK_ACK(最后确认)状态，等待客户端的确认。

服务器的连接释放(FIN)报文段的FIN=1，ACK=1，序列号seq=m，确认序列号ack=u+1。

第四次握手：客户端收到来自服务器的连接释放(FIN)报文段后，会向服务器发送一个ACK应答报文段，以连接释放(FIN)报文段的确认序号 ack 作为ACK应答报文段的序列号 seq，以连接释放(FIN)报文段的序列号 seq+1作为确认序号ack。

之后客户端进入TIME_WAIT(时间等待)状态，服务器收到ACK应答报文段后，服务器就进入CLOSE(关闭)状态，到此服务器的连接已经完成关闭。

客户端处于TIME_WAIT状态时，此时的TCP还未释放掉，需要等待2MSL后，客户端才进入CLOSE状态。

为什么挥手需要四次？

这是由于TCP的半关闭(half-close)造成的。半关闭是指：TCP提供了连接的一方在结束它的发送后还能接受来自另一端数据的能力。通俗来说，就是不能发送数据，但是还可以接受数据。

TCP不允许连接处于半打开状态时，就单向传输数据，因此完成三次握手后才可以传输数据(第三握手可以携带数据)。

当连接处于半关闭状态时，TCP是允许单向传输数据的，也就是说服务器此时仍然可以向客户端发送数据，等服务器不再发送数据时，才会发送FIN报文段，同意现在关闭连接。

这一特性是由于TCP双向通道互相独立所导致的，也使得关闭连接必须经过四次握手。

TIME_WAIT状态过多有什么危害？

只有主动发起断开请求的一方才会进入TIME_WAIT状态！

1. 占用系统资源

2. socket的TIME_WAIT状态结束之前，该socket占用的端口号将一直无法释放。如果服务器TIME_WAIT状态过多，占满了所有端口资源，则会导致无法创建新的连接。

如何解决TIME_WAIT状态过多？

最好的办法是尽量让客户端主动断开连接，除非遇到一些异常情况，如客户端协议错误、客户端超时等。

UDP协议

协议特点

• 无连接、不可靠的传输协议

• 花费的开销小、效率高

UDP在局域网中使用较多。由于局域网中网络连接被影响的可能性小于广域网，所以UDP在局域网中“不可靠”缺点的影响被减小。

当应用程序对传输的可靠性要求不高，但是对传输速度和延迟要求较高时，可以用UDP协议来替代TCP协议在传输层控制数据的转发。UDP将数据从源端发送到目的端时，无需事先建立连接。UDP采用了简单、易操作的机制在应用程序间传输数据，没有使用TCP中的确认技术或滑动窗口机制，因此UDP不能保证数据传输的可靠性，也无法避免接收到重复数据的情况。

UDP首部报文

UDP报文的首部格式：

• 源端口号（16）

• 目标端口号（16）

• UDP长度（16）

  用来指出UDP的总长度，为首部加上数据

• UDP校验和（16）

  用来完成对UDP数据的差错检验，它是UDP协议提供的唯一的可靠机制。

常用UDP端口号

69：TFTP协议（简单文件传输协议）

111：RPC协议（远程过程调用）

123：NTP协议（网络时间协议）

162、161：SNMP协议（简单网络管理协议）服务器用的162，客户端用的161。

67、68：DHCP协议（动态主机配置协议）服务器用的67，客户端用的68。

53：DNS协议（域名解析服务）

UDP传输过程

使用UDP传输数据时，由应用程序根据需要提供报文到达确认、排序、流量控制等功能。

主机A发送数据包时，这些数据包是以有序的方式发送到网络中的，每个数据包独立地在网络中被发送，所以不同的数据包可能会通过不同的网络路径到达主机B。这样的情况下，先发送的数据包不一定先到达主机B。

因为UDP数据包没有序号，主机B将无法通过UDP协议将数据包按照原来的顺序重新组合，所以此时需要应用程序提供报文的到达确认、排序和流量控制等功能。通常情况下，UDP采用实时传输机制和时间戳来传输语音和视频数据。

UDP适合传输对时延敏感的流量，如语音和视频。

UDP相较于TCP的优势

在使用TCP协议传输数据时，如果一个数据段丢失或者接收端对某个数据段没有确认，发送端会重新发送该数据段。

TCP重新发送数据会带来传输延迟和重复数据，降低了用户的体验。对于时延敏感的应用，少量的数据丢失一般可以被忽略，这时使用UDP传输将能够提升用户的体验。

DHCP协议原理

参考博客：DHCP和IP地址冲突 - 若晨辰 - 博客园 (cnblogs.com)

配置过程

DHCP运行分为四个基本过程，分别为发现阶段、提供IP、选择IP租约和确认IP租约。

发现阶段：DHCP客户机寻找DHCP服务器的阶段

当DHCP客户机第一次登录网络的时候（也就是客户机上没有任何IP地址数据时），它会通过UDP 67端口向网络上发出一个DHCPDISCOVER数据包（包中包含客户机的MAC地址和计算机名等信息）。因为客户机还不知道自己属于哪一个网络，所以封包的源地址为0.0.0.0，目标地址为255.255.255.255，然后再附上DHCP discover的信息，向网络进行广播，网络上每一台安装了TCP/IP协议的主机都会接收到这种广播信息，但只有DHCP服务器才会做出响应。

提供IP地址租用：DHCP服务器提供IP地址的阶段

在网络中接收到DHCPdiscover发现信息的DHCP服务器都会做出响应，它从尚未出租的IP地址中挑选一个分配给DHCP客户机，DHCP为客户保留一个IP地址，然后通过网络广播一个DHCPOFFER消息给客户。该消息包含客户的MAC地址、服务器提供的IP地址、子网掩码、租期以及提供IP的DHCP服务器的IP。此时还是使用广播进行通讯，源IP地址为DHCP Server的IP地址，目标地址为255.255.255.255。同时，DHCP Server为此客户保留它提供的IP地址，从而不会为其他DHCP客户分配此IP地址。

由于客户机在开始的时候还没有IP地址，所以在其DHCP discover封包内会带有其MAC地址信息，并且有一个XID编号来辨别该封包，DHCP Server响应的DHCP OFFER封包则会根据这些资料传递给要求租约的客户。

选择阶段：即DHCP客户机选择某台DHCP服务器提供的IP地址的阶段

如果客户机收到网络上多台DHCP服务器的响应，只会挑选其中一个DHCP OFFER（一般是最先到达的那个），并且会向网络发送一个DHCP REQUEST广播数据包（包中包含客户端的MAC地址、接受的租约中的IP地址、提供此租约的DHCP服务器地址等），告诉所有DHCP Server它将接受哪一台服务器提供的IP地址，所有其他的DHCP服务器撤销它们的提供以便将IP地址提供给下一次IP租用请求。此时，由于还没有得到DHCP Server的最后确认，客户端仍然使用0.0.0.0为源IP地址，255.255.255.255为目标地址进行广播。

租约确认阶段：即DHCP服务器确认所提供的IP地址的阶段

当DHCP Server接收到客户机的DHCP REQUEST之后，会广播返回给客户机一个DHCP ACK消息包，表明已经接受客户机的选择，并将这一IP地址的合法租用以及其他的配置信息都放入该广播包发给客户机。

客户机在接收到DHCP ACK广播后，会向网络发送三个针对此IP地址的ARP解析请求以执行冲突检测，查询网络上有没有其它机器使用该IP地址；如果发现该IP地址已经被使用，客户机会发出一个DHCP DECLINE数据包给DHCP Server，拒绝此IP地址租约，并重新发送DHCP discover信息。此时，在DHCP服务器管理控制台中，会显示此IP地址为BAD_ADDRESS。

如果网络上没有其它主机使用此IP地址，则客户机的TCP/IP使用租约中提供的IP地址完成初始化，便将收到的IP地址与客户端的网卡绑定。从而可以和其他网络中的主机进行通讯。

DHCP客户机租期续约

IP租期

因为客户机申请的IP地址是有一定的时间限制的，DHCP服务器向DHCP客户端分配IP地址称为出租，通常都设置有租借期限,所以在地址到期之前客户机还会向DHCP服务器发送一个续约的请求.

客户机会在租期过去50%的时候，直接向为其提供IP地址的DHCP Server发送DHCP REQUEST消息包。如果客户机接收到该服务器回应的DHCP ACK消息包，客户机就根据包中所提供的新的租期以及其它已经更新的TCP/IP参数，更新自己的配置，IP租用更新完成。如果没有收到该服务器的回复，则客户机继续使用现有的IP地址，因为当前租期还有50%。

如果在租期过去50%的时候没有更新，则客户机将在租期过去87.5%的时候再次向为其提供IP地址的DHCP联系。如果还不成功，到租约的100%时候，客户机必须放弃这个IP地址，重新申请。

续约过程

通过第1次分配IP地址之后，DHCP客户端每次重新登录网络时，就不需要再次发送DHCP discover广播信息了，因为这时已经知道内网中有一个DHCP服务器的IP地址了，所以就直接发送包含前一次所分配的IP地址的DHCP request信息。当DHCP服务器收到该信息后，会尝试让DHCP客户端继续使用原来的IP地址，并回答一个DHCP ACK信息。若该IP地址已被使用，则DHCP服务器将发送一个DHCP NACK信息给客户端，客户端收到该信息后，将重新发送DHCP discover信息来请求新的IP地址。如果客户端已知的DHCP服务器IP地址无效，就只有重新发送广播信息，查找新的DHCP服务器了。

DHCP中继

中继原理

1. 当dhcp client 启动并进行dhcp 初始化时，它会在本地网络广播配置请求报文。

2. 如果本地网络存在dhcp server，则可以直接进行dhcp 配置，不需要dhcp relay。

3. 如果本地网络没有dhcp server，则与本地网络相连的具有dhcprelay 功能的网络设备收到该广播报文后，将进行适当处理并转发给指定的其它网络上的dhcp server。

4. dhcp server 根据dhcp client 提供的信息进行相应的配置，并通过dhcp relay 将配置信息发送给dhcp client，完成对dhcp client 的动态配置。

事实上，从开始到最终完成配置，需要多个这样的交互过程。

• dhcp relay设备修改dhcp消息中的相应字段，把dhcp的广播包改成单播包，并负责在服务器与客户机之间转换。

• 路由器可以作为dhcp relay 代理。

DHCP面临的安全威胁

DHCP饿死攻击

攻击原理：攻击者持续大量地向DHCP Server申请IP地址，直到耗尽DHCP Server地址池中的IP地址，导致DHCP Server不能给正常的用户进行分配。

漏洞分析：DHCP Server向申请者分配IP地址时，无法区分正常的申请者与恶意的申请者。

仿冒DHCP Server攻击

攻击原理：攻击者仿冒DHCP Server，向客户端分配错误的IP地址及提供错误的网关地址等参数，导致客户端无法正常访问网络。

漏洞分析：DHCP客户端接收到来自DHCP Server的DHCP消息后，无法区分这些DHCP消息是来自仿冒的DHCP Server，还是来自合法的DHCP Server。

DHCP中间人攻击

攻击原理：攻击者利用ARP机制，让PC-A学习到IP-S与MAC-B的映射关系，又让Server学习到IP-A与MAC-B的映射关系。如此一来，PC-A与Server之间交互的IP报文都会经过攻击者中转。

漏洞分析：从本质上讲，中间人攻击是一种Spoofing IP/MAC攻击，中间人利用了虚假的IP地址与MAC地址之间的映射关系来同时欺骗DHCP的客户端和服务器。

DHCP Snooping

为了增强网络安全，防止DHCP受到攻击，一种称为DHCP Snooping的技术应运而生。DHCP Snooping不是一种标准技术，尚未有统一的标准规范，不同的网络设备制造商在DHCP Snooping的实现上也不尽相同。

DHCP Snooping部署在交换机上，其作用类似于在DHCP客户端与DHCP服务器端之间构筑了一道虚拟的防火墙。