Henry's Blog
  • CobaltStrike系列
    • CobaltStrike的基本操作
    • CobaltStrike会话管理
    • CobaltStrike重定向服务
    • CobaltStrike钓鱼攻击
    • 凭据导出与存储
    • Beacon的常用操作
    • DnsBeacon详解
    • 权限提升
    • 简单的内网信息收集
    • Cross2生成LinuxShell
    • CNA插件开发
    • Profile编写规则
    • BOF开发
    • execute-assembly原理
    • Vps搭建可能遇到的问题
  • OPSEC(免杀)
    • BypassPPL
    • Certutil绕过技巧
    • DLL劫持技术(白+黑)
    • PEB伪装
    • PpidSpoofing
    • Python反序列化免杀
    • WebShell绕过技巧
    • mimikatz免杀
    • 利用CobaltStrikeProfile实现免杀
    • 利用Windows异常机制实现Bypass
    • 削弱WindowsDefender
    • 模拟Powershell实现Bypass
    • 浅谈CobaltStrikeUDRL
    • 添加用户和计划任务(Bypass)
    • 移除NtDll的hook
    • 定位修改MsfShellcode特征码实现免杀
    • 利用COM接口实现进程断链执行.md
    • 免杀工具篇
      • Invoke-Obfuscation
      • Shellter
    • 流量检测逃避
      • CobaltStrike流量逃避.md
      • MSF流量加密.md
      • NC反弹Shell流量加密.md
  • Shellcode加密
    • 前置知识
    • XOR加密
    • AES加密
  • Shellcode加载器
    • 常见的加载方式
    • 分离加载
    • 创建纤程加载
    • 动态调用API加载
    • 基于APC注入加载
    • 基于反调试加载
    • 基于回调函数加载
    • 基于线程池加载
    • 模块踩踏
    • 进程镂空注入(傀儡进程)
    • 反射dll注入(内嵌式)
  • Web渗透
    • 信息收集
    • 各类Webshell
    • 基本漏洞利用
    • 远程命令执行漏洞
    • sql注入
    • sqlmap的使用方法
  • 内网渗透
    • 内网渗透前置知识
    • BadUsb制作
    • Linux反弹Shell总结
    • 内网渗透技术总结
    • 横向移动
      • GoToHttp
      • MS14-068
      • PassTheHash
      • PassTheTicket
      • Psexec
      • RustDesk
      • SMB横移
      • WMI横移
      • 用户枚举与爆破
    • 流量加密
      • CobaltStrike流量加密
      • MsfShell流量加密
      • OpenSSL加密反弹shell
  • 协议分析
    • TCP_IP协议
  • 权限提升
    • 土豆提权原理
    • UAC提权
  • 蓝队技术
    • 应急响应流程总结
  • 进程注入
    • Conhost注入
    • session0注入
    • 内核回调表注入
    • 剪切板注入
  • 逆向技术
    • HOOK技术
    • IDA遇到的坑
    • Shellcode的原理与编写
    • Windbg的使用
    • 使用Stardust框架编写Shellcode
    • PeToShellcode
    • 破解系列
      • PUSH窗体大法
      • VM绕过技巧(易语言)
      • Crackme_1
      • 反破解技术
      • 按钮事件特征码
      • 逆向调试符号
      • 破解实例
        • IDA逆向注册码算法
  • 钓鱼技术
    • Flash网页钓鱼
    • LNK钓鱼
    • 自解压程序加载木马
  • 隧道应用
    • 隧道应用前置知识
    • BurpSuite上游代理
    • DNS隧道传输
    • EarthWorm内网穿透
    • Frp内网穿透
    • ICMP隧道传输
    • MsfPortfwd端口转发
    • Neo-reGeorg内网穿透
    • NetCat工具使用
    • Netsh端口转发
    • SSH端口转发
    • 正向连接与反向连接
  • 基础学习
    • C和C++
      • C++编程
      • C程序设计
    • Linux学习
      • Linux Shell编程
      • linux基础
    • Python基础
      • python之Socket编程
      • python之多线程操作
      • python基础
      • python算法技巧
    • Qt基础
      • Qt笔记
    • 逆向基础
      • PE结构
      • Win32
      • 汇编语言
  • 漏洞复现
    • Web漏洞
      • ApacheShiro反序列化漏洞
    • 系统漏洞
      • Linux漏洞
        • ShellShock(CVE-2014-6271)
  • 靶场系列
    • Web靶场
      • pikachu靶场
      • sqli-labs
      • upload-labs
    • 内网靶场
      • Jarbas靶场
      • SickOS靶场
      • W1R3S靶场
      • prime靶场
      • vulnstack靶场系列一
      • vulnstack靶场系列二
      • vulnstack靶场系列四
  • 代码审计
    • PHP代码审计基础
  • 一些杂七杂八的
    • 开发工具与环境
      • Github的使用
      • JSP环境搭建
      • Pycharm设置代码片段
      • VS2017安装番茄助手(破解版)
      • VisualStudio项目模板的使用
      • WindowsServer搭建IIS环境
      • 安装Scoop
      • c++安装vcpkg
      • dotnet-cnblog的安装与使用
      • gitbook使用教程
      • kali安装burpsuite
      • 配置win2012域服务器
      • VSCode配置MinGW
    • 踩坑记录
      • BurpSuite导入证书
      • Powershell禁止执行脚本
      • centos7没有显示ip
      • kali安装pip2
      • oracle12没有scott用户
由 GitBook 提供支持
在本页
  • TCP网络分层
  • 架构图
  • 分层结构
  • 分层的好处
  • TCP报文的组成
  • 序号(Seq)
  • 确认序号(Ack)
  • 标志位
  • TCP三次握手
  • 流程图
  • 连接状态变化
  • 三次握手过程
  • 为何要三次握手
  • TCP四次挥手
  • 流程图
  • 挥手过程
  • 为何要四次挥手
  • 为何客户端在第四次挥手后还会等待2MSL
  • TCP快速打开(TFO)
  • 原理
  • 两个阶段
  • TFO的优势
  1. 协议分析

TCP_IP协议

上一页协议分析下一页权限提升

最后更新于1年前

TCP网络分层

架构图

分层结构

应用层

应⽤程序之间如何相互传递报⽂,⽐如HTTP协议, RIP协议

传输层

传输层的作⽤是为两台主机之间的“应⽤进程”提供端到端的逻辑通信,⽐如TCP协议

网络互连层

⽹络互连层提供了主机到主机的通信,将传输层产⽣的的数据包封装成分组数据包发送到⽬标主机,并提供路由选择的能⼒。

IP协议是⽹络层的主要协议,TCP 和 UDP 都是⽤ IP 协议作为⽹络层协议。这⼀层的主要作⽤是给包加上源地址和⽬标地址,将数据包传送到⽬标地址

网络访问层

⽹络访问层也有说法叫做⽹络接⼝层,以太⽹、Wifi、蓝⽛⼯作在这⼀层,⽹络访问层提供了主机连接到物理⽹络需要的硬件和相关的协议

分层的好处

  • 各层独立: 限制了依赖关系的范围,各层之间使⽤标准化的接⼝,各层不需要知道上下层是如何⼯作的,增加或者修改⼀个应⽤层协议不会影响传输层协议

  • 灵活性更好: 比如路由器不需要应⽤层和传输层,分层以后路由器就可以只⽤加载更少的⼏个协议 层

  • 易于测试和维护: 提⾼了可测试性,可以独⽴的测试特定层,某⼀层有了更好的实现可以整体替换掉

  • 能促进标准化: 每⼀层职责清楚,⽅便进⾏标准化

TCP报文的组成

序号(Seq)

序号占32位, 用来标识从TCP源端向目的端发送的字节流, 由数据的发起方进行标记

确认序号(Ack)

确认序号占32位, 只有当ACK标志位为1时, 确认序号字段才有效

标志位

一共有六个标志位, 分别是URG、ACK、PSH、RST、SYN、FIN

  • URG: 紧急指针(urgent pointer)

  • ACK: 确认序号,用于确认接收到消息

  • PSH: 接收方应该尽快将这个报文交给应用层

  • RST: 重置连接。

  • SYN: 发起一个新连接。

  • FIN: 释放一个连接

TCP三次握手

流程图

TCP连接的建立即所谓的三次握手, 此连接必须是一方主动打开, 另一方被动打开, 通常为客户端主动连接, 服务端被动连接

​

连接状态变化

客户端

  • SYN_SENT状态: 当要访问计算机的服务时, 首先会发送同步信号给该端口, 此时的状态为SYN_SENT(请求连接状态)。

  • ESTABLISHED状态: 若请求连接成功, 连接状态就变成了ESTABLISHED, 也就是说SYN_SENT状态是十分短暂的

服务端

  • LISTENING状态: State显示是LISTENING时表示处于监听状态, 也就是说该端口是开放的, 等待被客户端连接

  • SYN_RCVD状态: 收到和发送一个连接请求后等待对方对连接请求进行确认。当服务器收到客户端发送的同步信号时, 将标志位ACK和SYN置1发送给客户端, 此时服务器端处于SYN_RCVD状态

  • ESTABLISHED状态: 若对方确认了连接请求, 连接状态就变成了ESTABLISHED, 也就是说SYN_RCVD状态也是十分短暂的, 若发现SYN_RCVD状态也就存在很多, 那么你的机器很可能被SYN Flood的Dos(拒绝服务)攻击了

三次握手过程

1.客户端向服务端发送TCP报文

标记位是SYN,表示"请求建立新连接"

序号(数据包序号)是Seq=X, X通常表示为1

随后客户端进入SYN-SENT状态

2.服务端收到报文后结束LISTEN状态, 并返回报文

标志位是SYN和ACK, 表示"服务端确认客户端发送的报文序号有效, 能够正常接收客户端发送的数据, 并同意创建新连接"。 简单来说就是服务器告诉客户端, 我收到了你发来的数据

序号是Seq=y, 表示服务端给收到的数据包标序号为y, 并返回给客户端

确认号为ACK=x+1, 表示服务端将收到的报文序号Seq并将其值加1作为自己报文的确认号ACK的值, 随后服务端进入SYN-RCVD状态

3.客户端接收到服务端发来的报文,明确了之前发的报文是正常的, 随后结束SYN_SENT状态, 并返回一段TCP报文给服务端

标志位是ACK, 表示确认收到服务端发来同意连接的信号

序号是Seq=x+1, 表示收到服务端发来确认号ACK, 并将其值作为自己的序号值

确认号是Ack=y+1, 表示收到服务端发来的序号Seq, 并将其值加1作为自己的确认号Ack的值, 随后客户端进入ESTABLISHED状态

为何要三次握手

1.防止服务端开启一些无效的连接,以此增加自身负载

第一次握手客户端发送的TCP报文,服务端成功接收;然后第二次握手,服务端返回一个确认收到消息的TCP报文,但这个报文因为某些原因丢失了,那么客户端就一直收不到这个TCP报文的,客户端设置了一个超时时间,超过了就重新发送一个TCP连接请求,那么如果没有第三次握手的话,服务端是不知道客户端是否收到服务返回的信息的,这样没有给服务器端一个创建还是关闭连接端口的请求,服务器端的端口就一直开着,等到客户端因超时重新发出请求时,服务器就会重新开启一个端口连接。那么服务器端上没有接收到请求数据的上一个端口就一直开着,长此以往,这样的端口多了,就会造成服务器端开销的严重浪费

2.防止已失效的连接请求报文突然传到服务端,因而产生错误

已经失效的客户端发出的请求信息,由于某种原因传输到了服务器端,服务器端以为是客户端发出的有效请求,接收后产生错误

TCP四次挥手

流程图

挥手过程

所谓的四次挥手即TCP连接的释放。连接的释放必须是一方主动释放,另一方被动释放。

1.客户端想要释放连接, 向服务端发送TCP报文

  • 标记位是FIN, 表示"请求释放连接"

  • 序号为Seq=U

随后客户端进入FIN-WAIT-1阶段,即半关闭阶段。并且停止在客户端到服务器端方向上发送数据,但是客户端仍然能接收从服务器端传输过来的数据。

注意:这里不发送的是正常连接时传输的数据(非确认报文),而不是一切数据,所以客户端仍然能发送ACK确认报文

2.服务端接收报文后, 确定了客户端想要释放连接, 随后结束ESTABLISHED状态, 进入CLOSE-WAIT(半关闭)状态, 并返回TCP报文

  • 标记位是ACK, 表示"接收到客户端发送的释放连接的请求"

  • 序号是Seq=V

  • 确认号是ACK=U+1, 即将客户端发送的报文的序号值加1作为确认号ACK的值

随后服务器端开始准备释放服务器端到客户端方向上的连接。客户端收到从服务器端发出的TCP报文之后,确认了服务器收到了客户端发出的释放连接请求,随后客户端结束FIN-WAIT-1阶段,进入FIN-WAIT-2阶段

前"两次挥手"既让服务器端知道了客户端想要释放连接,也让客户端知道了服务器端了解了自己想要释放连接的请求, 因此可关闭客户端到服务器端方向上的连接了

3.服务端自从发出ACK确认报文之后,经过CLOSED-WAIT阶段,做好了释放服务器端到客户端方向上的连接准备,再次向客户端发出一段TCP报文

之所以要进行三次握手, 是因为服务端还有些数据要进行处理, 不能立刻断开连接

  • 标记位是FIN, ACK, 表示"已经准备好释放连接了"

  • 序号Seq=W

  • 确认号Ack=U+1, 在收到客户端报文的基础上,将其序号Seq值加1作为本段报文确认号Ack的值

随后服务端结束CLOSE-WAIT阶段, 进入LAST-ACK阶段, 并停止往客户端发送数据, 但是依然能够接收客户端发来的数据

4.客户端收到服务端发来的报文后, 确认了服务端已准备好释放连接, 于是结束FIN-WAIT-2阶段, 进入TIME-WAIT阶段, 并向服务端发送报文

  • 标记位是ACK,表示“接收到服务器准备好释放连接的信号”

  • 序号是Seq=U+1, 表示将服务端发来报文的确认号值Ack作为自己报文的序号值

  • 确认号是Ack=W+1, 表示将服务端发来报文的序号值Seq加1作为自己报文的确认号值

为何要四次挥手

三次握手是为了建立可靠的数据传输通道,四次挥手是为了保证等数据传输完再关闭连接,保证双方都达到关闭连接的条件才能断开

为何客户端在第四次挥手后还会等待2MSL

等待2MSL是因为保证服务端接收到了ACK报文,因为网络是复杂的,ACk报文可能会丢失,如果服务端没接收到ACK报文的话,会重新发送FIN报文,只有当客户端等待了2MSL都没有收到重新发送的FIN报文时,才表示服务端是正常接收到了ACK报文,这个时候客户端就能关闭了

TCP快速打开(TFO)

原理

TCP快速打开, 又称TFO(TCP Fast Open)

TFO 是在原来 TCP 协议上的扩展协议,它的主要原理就在发送第⼀个 SYN 包的时候就开始传数据了, 不过它要求当前客户端之前已经完成过正常的三次握⼿。

两个阶段

TCP快速打开分两个阶段:

  • Fast Open Cookie: 请求

  • TCP Fast Open: 真正开始

Fast Open Cookie

TCP Fast Open

TFO的优势

⼀个最显著的优点是可以利⽤握⼿去除⼀个往返RTT, 可以有效防⽌SYN-Flood攻击之类的

​

image-20221018115113552
image-20221018160033721
image-20221018164025405
image-20221018173119719
image-20221101173207820
image-20221101173251684
image-20221101173357733