网络安全中tcp抓包分析

⑴ iOS App的tcp、udp数据包抓取与分析教程

在对app进行安全分析时，有时需要检查app的网络接口请求是否安全，网络协议交互是否可被恶意利用。因此就需要运行app并捕获其与服务端交互的网络数据进行分析。前面文章已介绍过http、https数据包的捕获，该篇文章主要介绍捕获app的tcp、udp流量数据。我们将 使用tcpmp捕获tcp、udp流量 ，再 通过wireshark过滤、分析app的tcp、udp流量 。

一、tcpmp捕获app流量

在运行app后，不要马上关掉app进程，我们要找出与app通信的 服务端ip 或者 端口 以及 网络协议（tcp、udp） ，方便后续wireshark过滤

新开一个终端，ssh再连接一次ios设备，查看app的进程pid（比如该app的进程pid为11524），如下所示

找到app的进程pid后，查看app的网络交互情况，我们使用 lsof ，它可查看系统中的文件使用情况，广义上网络套接字也属于文件描述符，因此可以通过lsof查看，如下所示

lsof -i -a -p <pid> #我们上面查看到的进程pid

-i 表示 列出所有网络连接

-a 表示 指定当前用户

-p 表示 某个进程（pid）

我们即可看到该app网络交互的 网络协议 、 ip 、 端口 等

最后停止tcpmp捕获app网络数据，结束抓包

二、wireshark过滤分析app流量

参考链接：

https://linux.die.net/man/8/lsof

⑵ TCP协议详解及实战解析【精心整理收藏】

TCP协议是在TCP/IP协议模型中的运输层中很重要的一个协议、负责处理主机端口层面之间的数据传输。主要有以下特点：

1.TCP是面向链接的协议，在数据传输之前需要通过三次握手建立TCP链接，当数据传递完成之后，需要通过四次挥手进行连接释放。

2.每一条TCP通信都是两台主机和主机之间的，是点对点传输的协议。

3.TCP提供可靠的、无差错、不丢失、不重复，按序到达的服务。

4.TCP的通信双方在连接建立的任何时候都可以发送数据。TCP连接的两端都设有发送缓存和接收缓存，用来临时存放双向通信的数据。

5.面向字节流。在数据传输的过程中如果报文比较长的话TCP会进行数据分段传输，每一条分段的TCP传输信息都带有分段的序号，每一段都包含一部分字节流。接收方根据每段携带的的序号信息进行数据拼接，最终拼接出来初始的传输数据。但是在整个传输的过程中每一段TCP携带的都是被切割的字节流数据。所以说TCP是面向字节流的。

a.TCP和UDP在发送报文时所采用的方式完全不同。TCP并不关心应用程序一次把多长的报文发送到TCP缓存中，而是根据对方给出的窗口值和当前网络拥塞的程度来决定一个报文段应包含多少个字节（UDP发送的报文长度是应用程序给出的）。
b.如果应用程序传送到TCP缓存的数据块太大，TCP就可以把它划分短一些再传。TCP也可以等待积累有足够多的字节后再构建成报文段发送出去。

各字段含义：

源端口：发送端的端口号

目的端口：接收端的端口号

序号：TCP将发送报文分段传输的时候会给每一段加上序号，接收端也可以根据这个序号来判断数据拼接的顺序，主要用来解决网络报乱序的问题

确认号：确认号为接收端收到数据之后进行排序确认以及发送下一次期待接收到的序号，数值 = 接收到的发送号 + 1

数据偏移：占4比特，表示数据开始的地方离TCP段的起始处有多远。实际上就是TCP段首部的长度。由于首部长度不固定，因此数据偏移字段是必要的。数据偏移以32位为长度单位，因此TCP首部的最大长度是60（15*4）个字节。

控制位：

URG：此标志表示TCP包的紧急指针域有效，用来保证TCP连接不被中断，并且督促 中间层设备要尽快处理这些数据;

ACK：此标志表示应答域有效，就是说前面所说的TCP应答号将会包含在TCP数据包中;有两个取值：0和1， 为1的时候表示应答域有效，反之为0;

PSH：这个标志位表示Push操作。所谓Push操作就是指在数据包到达接收端以后，立即传送给应用程序， 而不是在缓冲区中排队;

RST：这个标志表示连接复位请求。用来复位那些产生错误的连接，也被用来拒绝错误和非法的数据包;

SYN：表示同步序号，用来建立连接。SYN标志位和ACK标志位搭配使用，当连接请求的时候，SYN=1， ACK=0;连接被响应的时候，SYN=1，ACK=1;这个标志的数据包经常被用来进行端口扫描。扫描者发送 一个只有SYN的数据包，如果对方主机响应了一个数据包回来 ，就表明这台主机存在这个端口;但是由于这 种扫描方式只是进行TCP三次握手的第一次握手，因此这种扫描的成功表示被扫描的机器不很安全，一台安全 的主机将会强制要求一个连接严格的进行TCP的三次握手;

FIN： 表示发送端已经达到数据末尾，也就是说双方的数据传送完成，没有数据可以传送了，发送FIN标志 位的TCP数据包后，连接将被断开。这个标志的数据包也经常被用于进行端口扫描。

窗口：TCP里很重要的一个机制，占2字节，表示报文段发送方期望接收的字节数，可接收的序号范围是从接收方的确认号开始到确认号加上窗口大小之间的数据。后面会有实例讲解。

校验和：校验和包含了伪首部、TCP首部和数据，校验和是TCP强制要求的，由发送方计算，接收方验证

紧急指针：URG标志为1时，紧急指针有效，表示数据需要优先处理。紧急指针指出在TCP段中的紧急数据的最后一个字节的序号，使接收方可以知道紧急数据共有多长。

选项：最常用的选项是最大段大小（Maximum Segment Size，MSS），向对方通知本机可以接收的最大TCP段长度。MSS选项只在建立连接的请求中发送。

放在以太网帧里看TCP的位置

TCP 数据包在 IP 数据包的负载里面。它的头信息最少也需要20字节，因此 TCP 数据包的最大负载是 1480 - 20 = 1460 字节。由于 IP 和 TCP 协议往往有额外的头信息，所以 TCP 负载实际为1400字节左右。

因此，一条1500字节的信息需要两个 TCP 数据包。HTTP/2 协议的一大改进， 就是压缩 HTTP 协议的头信息，使得一个 HTTP 请求可以放在一个 TCP 数据包里面，而不是分成多个，这样就提高了速度。

以太网数据包的负载是1500字节，TCP 数据包的负载在1400字节左右

一个包1400字节，那么一次性发送大量数据，就必须分成多个包。比如，一个 10MB 的文件，需要发送7100多个包。

发送的时候，TCP 协议为每个包编号（sequence number，简称 SEQ），以便接收的一方按照顺序还原。万一发生丢包，也可以知道丢失的是哪一个包。

第一个包的编号是一个随机数。为了便于理解，这里就把它称为1号包。假定这个包的负载长度是100字节，那么可以推算出下一个包的编号应该是101。这就是说，每个数据包都可以得到两个编号：自身的编号，以及下一个包的编号。接收方由此知道，应该按照什么顺序将它们还原成原始文件。

收到 TCP 数据包以后，组装还原是操作系统完成的。应用程序不会直接处理 TCP 数据包。

对于应用程序来说，不用关心数据通信的细节。除非线路异常，否则收到的总是完整的数据。应用程序需要的数据放在 TCP 数据包里面，有自己的格式（比如 HTTP 协议）。

TCP 并没有提供任何机制，表示原始文件的大小，这由应用层的协议来规定。比如，HTTP 协议就有一个头信息Content-Length，表示信息体的大小。对于操作系统来说，就是持续地接收 TCP 数据包，将它们按照顺序组装好，一个包都不少。

操作系统不会去处理 TCP 数据包里面的数据。一旦组装好 TCP 数据包，就把它们转交给应用程序。TCP 数据包里面有一个端口（port）参数，就是用来指定转交给监听该端口的应用程序。

应用程序收到组装好的原始数据，以浏览器为例，就会根据 HTTP 协议的Content-Length字段正确读出一段段的数据。这也意味着，一次 TCP 通信可以包括多个 HTTP 通信。

服务器发送数据包，当然越快越好，最好一次性全发出去。但是，发得太快，就有可能丢包。带宽小、路由器过热、缓存溢出等许多因素都会导致丢包。线路不好的话，发得越快，丢得越多。

最理想的状态是，在线路允许的情况下，达到最高速率。但是我们怎么知道，对方线路的理想速率是多少呢？答案就是慢慢试。

TCP 协议为了做到效率与可靠性的统一，设计了一个慢启动（slow start）机制。开始的时候，发送得较慢，然后根据丢包的情况，调整速率：如果不丢包，就加快发送速度；如果丢包，就降低发送速度。

Linux 内核里面 设定 了（常量TCP_INIT_CWND），刚开始通信的时候，发送方一次性发送10个数据包，即"发送窗口"的大小为10。然后停下来，等待接收方的确认，再继续发送。

默认情况下，接收方每收到 两个 TCP 数据包，就要 发送 一个确认消息。"确认"的英语是 acknowledgement，所以这个确认消息就简称 ACK。

ACK 携带两个信息。

发送方有了这两个信息，再加上自己已经发出的数据包的最新编号，就会推测出接收方大概的接收速度，从而降低或增加发送速率。这被称为"发送窗口"，这个窗口的大小是可变的。

注意，由于 TCP 通信是双向的，所以双方都需要发送 ACK。两方的窗口大小，很可能是不一样的。而且 ACK 只是很简单的几个字段，通常与数据合并在一个数据包里面发送。

即使对于带宽很大、线路很好的连接，TCP 也总是从10个数据包开始慢慢试，过了一段时间以后，才达到最高的传输速率。这就是 TCP 的慢启动。

TCP 协议可以保证数据通信的完整性，这是怎么做到的？

前面说过，每一个数据包都带有下一个数据包的编号。如果下一个数据包没有收到，那么 ACK 的编号就不会发生变化。

举例来说，现在收到了4号包，但是没有收到5号包。ACK 就会记录，期待收到5号包。过了一段时间，5号包收到了，那么下一轮 ACK 会更新编号。如果5号包还是没收到，但是收到了6号包或7号包，那么 ACK 里面的编号不会变化，总是显示5号包。这会导致大量重复内容的 ACK。

如果发送方发现收到 三个 连续的重复 ACK，或者超时了还没有收到任何 ACK，就会确认丢包，即5号包遗失了，从而再次发送这个包。通过这种机制，TCP 保证了不会有数据包丢失。

TCP是一个滑动窗口协议，即一个TCP连接的发送端在某个时刻能发多少数据是由滑动窗口控制的，而滑动窗口的大小实际上是由两个窗口共同决定的，一个是接收端的通告窗口，这个窗口值在TCP协议头部信息中有，会随着数据的ACK包发送给发送端，这个值表示的是在接收端的TCP协议缓存中还有多少剩余空间，发送端必须保证发送的数据不超过这个剩余空间以免造成缓冲区溢出，这个窗口是接收端用来进行流量限制的，在传输过程中，通告窗口大小与接收端的进程取出数据的快慢有关。另一个窗口是发送端的拥塞窗口(Congestion window)，由发送端维护这个值，在协议头部信息中没有，滑动窗口的大小就是通告窗口和拥塞窗口的较小值，所以拥塞窗口也看做是发送端用来进行流量控制的窗口。滑动窗口的左边沿向右移动称为窗口合拢，发生在发送的数据被确认时（此时，表明数据已被接收端收到，不会再被需要重传，可以从发送端的发送缓存中清除了），滑动窗口的右边沿向右移动称为窗口张开，发生在接收进程从接收端协议缓存中取出数据时。随着发送端不断收到的被发送数据的ACK包，根据ACK包中的确认序号和通告窗口大小使滑动窗口得以不断的合拢和张开，形成滑动窗口的向前滑动。如果接收进程一直不取数据，则会出现0窗口现象，即滑动窗口左边沿与右边沿重合，此时窗口大小为0，就无法再发送数据。

在TCP里，接收端(B)会给发送端(A)报一个窗口的大小，叫Advertised window。

1.在没有收到B的确认情况下，A可以连续把窗口内的数据都发送出去。凡是已经发送过的数据，在

未收到确认之前都必须暂时保留，以便在超时重传时使用。

2.发送窗口里面的序号表示允许发送的序号。显然，窗口越大，发送方就可以在收到对方确认之前连续

发送更多数据，因而可能获得更高的传输效率。但接收方必须来得及处理这些收到的数据。

3.发送窗口后沿的后面部分表示已发送且已收到确认。这些数据显然不需要再保留了。

4.发送窗口前沿的前面部分表示不允许发送的，应为接收方都没有为这部分数据保留临时存放的缓存空间。

5.发送窗口后沿的变化情况有两种：不动（没有收到新的确认）和前移（收到了新的确认）

6.发送窗口前沿的变化情况有两种：不断向前移或可能不动（没收到新的确认）

TCP的发送方在规定时间内没有收到确认就要重传已发送的报文段。这种重传的概念很简单，但重传时间的选择确是TCP最复杂的问题之一。TCP采用了一种自适应算法，它记录一个报文段发出的时间，以及收到响应的确认的时间

这两个时间之差就是报文段的往返时间RTT。TCP保留了RTT的一个加权平均往返时间。超时重传时间RTO略大于加权平均往返时间

RTT：
即Round Trip Time，表示从发送端到接收端的一去一回需要的时间，tcp在数据传输过程中会对RTT进行采样（即对发送的数据包及其ACK的时间差进行测量，并根据测量值更新RTT值，具体的算法TCPIP详解里面有），TCP根据得到的RTT值更新RTO值，即Retransmission TimeOut，就是重传间隔，发送端对每个发出的数据包进行计时，如果在RTO时间内没有收到所发出的数据包的对应ACK，则任务数据包丢失，将重传数据。一般RTO值都比采样得到的RTT值要大。

如果收到的报文段无差错，只是未按序号，中间还缺少一些序号的数据，那么能否设法只传送缺少的数据而不重传已经正确到达接收方的数据？

答案是可以的，选择确认就是一种可行的处理方法。

如果要使用选项确认SACK，那么在建立TCP连接时，就要在TCP首部的选项中加上“允许SACK”的选项，而双方必须都事先商定好。如果使用选择确认，

那么原来首部中的“确认号字段”的用法仍然不变。SACK文档并没有明确发送方应当怎么响应SACK.因此大多数的实现还是重传所有未被确认的数据块。

一般说来，我们总是希望数据传输的更快一些，但如果发送方把数据发送的过快，接收方就可能来不及接收，这会造成数据的丢失。所谓流量控制就是让发送方的发送速率不要太快，要让接收方来得及接收。

在计算机网络中的链路容量，交换节点中的缓存和处理机等，都是网络的资源。在某段时间，若对网络中某一资源的需求超过了该资源所能提供的可用部分，网络的性能就要变坏。这种情况就叫做拥塞。

拥塞控制方法：

1.慢开始和拥塞避免

2.快重传和快恢复

3.随机早期检测

1.一开始，客户端和服务端都处于CLOSED状态

2.先是服务端主动监听某个端口，处于LISTEN状态（比如服务端启动，开始监听）。

3.客户端主动发起连接SYN，之后处于SYN-SENT状态（第一次握手，发送 SYN = 1 ACK = 0 seq = x ack = 0）。

4.服务端收到发起的连接，返回SYN，并且ACK客户端的SYN，之后处于SYN-RCVD状态（第二次握手，发送 SYN = 1 ACK = 1 seq = y ack = x + 1）。

5.客户端收到服务端发送的SYN和ACK之后，发送ACK的ACK，之后处于ESTABLISHED状态（第三次握手，发送 SYN = 0 ACK = 1 seq = x + 1 ack = y + 1）。

6.服务端收到客户端的ACK之后，处于ESTABLISHED状态。

（需要注意的是，有可能X和Y是相等的，可能都是0，因为他们代表了各自发送报文段的序号。）

TCP连接释放四次挥手

1.当前A和B都处于ESTAB-LISHED状态。

2.A的应用进程先向其TCP发出连接释放报文段，并停止再发送数据，主动关闭TCP连接。

3.B收到连接释放报文段后即发出确认，然后B进入CLOSE-WAIT(关闭等待)状态。TCP服务器进程这时应通知高层应用进程，因而从A到B这个方向的连接就释放了，这时TCP连接处于半关闭状态，即A已经没有数据发送了。

从B到A这个方向的连接并未关闭，这个状态可能会持续一些时间。

4.A收到来自B的确认后，就进入FIN-WAIT-2(终止等待2)状态，等待B发出的连接释放报文端。

5.若B已经没有向A发送的数据，B发出连接释放信号，这时B进入LAST-ACK(最后确认)状态等待A的确认。

6.A再收到B的连接释放消息后，必须对此发出确认，然后进入TIME-WAIT（时间等待）状态。请注意，现在TCP连接还没有释放掉，必须经过时间等待计时器（TIME－WAIT timer）设置的时间2MSL后，A才进入CLOSED状态。

7。B收到A发出的确认消息后，进入CLOSED状态。

以请求网络为例，看一下三次握手真实数据的TCP连接建立过程

我们再来看四次挥手。TCP断开连接时，会有四次挥手过程，标志位是FIN，我们在封包列表中找到对应位置，理论上应该找到4个数据包，但我试了好几次，实际只抓到3个数据包。查了相关资料，说是因为服务器端在给客户端传回的过程中，将两个连续发送的包进行了合并。因此下面会按照合并后的三次挥手解释，若有错误之处请指出。

第一步，当主机A的应用程序通知TCP数据已经发送完毕时，TCP向主机B发送一个带有FIN附加标记的报文段（FIN表示英文finish）。

第二步，主机B收到这个FIN报文段之后，并不立即用FIN报文段回复主机A，而是先向主机A发送一个确认序号ACK，同时通知自己相应的应用程序：对方要求关闭连接（先发送ACK的目的是为了防止在这段时间内，对方重传FIN报文段）。

第三步，主机B的应用程序告诉TCP：我要彻底的关闭连接，TCP向主机A送一个FIN报文段。

第四步，主机A收到这个FIN报文段后，向主机B发送一个ACK表示连接彻底释放。

这是因为服务端在LISTEN状态下，收到建立连接请求的SYN报文后，把ACK和SYN放在一个报文里发送给客户端。而关闭连接时，当收到对方的FIN报文时，仅仅表示对方不再发送数据了但是还能接收数据，己方也未必全部数据都发送给对方了，所以己方可以立即close，也可以发送一些数据给对方后，再发送FIN报文给对方来表示同意现在关闭连接，因此，己方ACK和FIN一般都会分开发送。

原因有二：
一、保证TCP协议的全双工连接能够可靠关闭
二、保证这次连接的重复数据段从网络中消失

先说第一点，如果Client直接CLOSED了，那么由于IP协议的不可靠性或者是其它网络原因，导致Server没有收到Client最后回复的ACK。那么Server就会在超时之后继续发送FIN，此时由于Client已经CLOSED了，就找不到与重发的FIN对应的连接，最后Server就会收到RST而不是ACK，Server就会以为是连接错误把问题报告给高层。这样的情况虽然不会造成数据丢失，但是却导致TCP协议不符合可靠连接的要求。所以，Client不是直接进入CLOSED，而是要保持TIME_WAIT，当再次收到FIN的时候，能够保证对方收到ACK，最后正确的关闭连接。

再说第二点，如果Client直接CLOSED，然后又再向Server发起一个新连接，我们不能保证这个新连接与刚关闭的连接的端口号是不同的。也就是说有可能新连接和老连接的端口号是相同的。一般来说不会发生什么问题，但是还是有特殊情况出现：假设新连接和已经关闭的老连接端口号是一样的，如果前一次连接的某些数据仍然滞留在网络中，这些延迟数据在建立新连接之后才到达Server，由于新连接和老连接的端口号是一样的，又因为TCP协议判断不同连接的依据是socket pair，于是，TCP协议就认为那个延迟的数据是属于新连接的，这样就和真正的新连接的数据包发生混淆了。所以TCP连接还要在TIME_WAIT状态等待2倍MSL，这样可以保证本次连接的所有数据都从网络中消失。

硬件速度
网络和服务器的负载
请求和响应报文的尺寸
客户端和服务器之间的距离
TCP 协议的技术复杂性

TCP 连接建立握手；
TCP 慢启动拥塞控制；
数据聚集的 Nagle 算法；
用于捎带确认的 TCP 延迟确认算法；
TIME_WAIT 时延和端口耗尽。

介绍完毕，就这？
是的，就这。

补充：

大部分内容为网络整理，方便自己学习回顾，参考文章：
TCP 协议简介
TCP协议图文详解
什么是TCP协议？
wireshark抓包分析——TCP/IP协议
TCP协议的三次握手和四次挥手
TCP协议详解
TCP带宽和时延的研究(1)

⑶ 求大神解答 TCP过程分析 Wireshark 抓包分析

（1）TCPClient向TCPServer发送连接请求SYN
（2）TCPServer收到连接请求后反馈SYN+ACK
（3）TCPClient收到SYN+ACK后反馈ACK，三次握手完成，连接建立
（4）TCPClient向TCPServer发送100字节的数据
（5）TCPServer收到（4）后确认并发送78字节的数据，即捎带确认
（6）TCPClient收到（5）后，发送ACK进行确认
（7）TCPClient发送100字节的数据
（8）TCPClient发送RST报文，终止连接

⑷ 【性能】怎么使用 tcpmp 抓包分析

tcpmp是一个用于截取网络分组，并输出分组内容的工具。

凭借强大的功能和灵活的截取策略，使其成为类UNIX系统下用于网络分析和问题排查的首选工具。

tcpmp 支持针对网络层、协议、主机、网络或端口的过滤，并提供and、or、not等逻辑语句来帮助你去掉无用的信息。

时间戳 协议 源地址. 源端口 > 目的地址. 目的端口 网络包详细信息

为了帮你更快上手 tcpmp 的使用，我在这里也帮你整理了一些最常见的用法，并且绘制成了表格，你可以参考使用。

首先，来看一下常用的几个选项。在上面的 ping 案例中，我们用过  -nn  选项，表示不用对 IP 地址和端口号进行名称解析。

我们再来看常用的过滤表达式。刚刚用过的是 udp port 53 or host 35.190.27.188 ，表示抓取 DNS 协议的请求和响应包，以及源地址或目的地址为 35.190.27.188 的包。

什么是 PCAP 文件扩展名？

https://www.filedesc.com/zh/file/pcap

https://www.solvusoft.com/zh-cn/file-extensions/file-extension-pcap

tcpmp(8) - Linux man page

https://linux.die.net/man/8/tcpmp

A tcpmp Tutorial with Examples — 50 Ways to Isolate Traffic

https://danielmiessler.com/study/tcpmp

⑸ 网络抓包怎么分析

关于网络抓包的问题，可以使用 ethereal 软件进行网络上各种信息包的抓取。
但是至于说对抓取到的各种信息包进行详细的分析，这个必须要精通 TCP/IP 协议族才能够做到（例如：精通 TCP、IP、UDP、ICMP等协议的帧格式、以及即使在同一个字段中，不同的数字也代表不同的具体含义，等等）。
否则的话，即使获取到了各种十六进制的信息包，阅读这些信息包的感觉就和看天书一样，无法分析这些信息包的详细含义。

⑹ 网络安全-TCP-IP攻击

概述

1. SYN-Flooding攻击效果,受害者系统卡死.

2. TCP-RST攻击实现已经建立的TCP连接断开.

3. TCP会话劫持,劫持TCP会话,并实现反向Shell.

实验环境

1. 三台Linux系统主机,一台作为攻击者,一台作为受害者,一台作为观察者.

2. 为了简化TCP序列号和源端口号的“猜测”,实验处于同一局域网内,你可以使用嗅探器来获取受害者信息.

SYN-Flooding攻击

1. SYN-Flooding攻击原理

SYN-Flooding是DoS攻击的一种，攻击者向受害者的TCP端口发送很多SYN请求，但攻击者无意完成三次握手过程.

攻击者要么使用欺骗性的假的IP地址，要么不要继续完成整个三次握手过程.

通过这种攻击，攻击者可以淹没用于半连接的受害者队列，即已完成SYN，SYN-ACK但尚未得到最终ACK的连接.

当这个队列已满时，受害者不能再进行任何连接.

正常三次握手过程:

在Linux中，我们可以使用以下命令检查

我们可以使用命令“netstat -na”来检查队列的使用情况，即与监听端口相关联的半连接的数量.

这种半连接的状态是SYN-RECV。如果三次握手完成，则连接的状态将为ESTABLISHED.

在这个任务中，你需要演示SYN-Flooding攻击:

您可以使用Netwox来执行攻击，然后使用嗅探器捕获攻击性数据包.

在攻击发生时，在受害机器上运行“netstat -na”命令，并将结果与攻击前的结果进行比较.

2. Netwox 76简介

3. SYN Cookie防御机制

如果你的攻击看起来不成功，你可以检查是否启用了SYN cookie机制.

SYN cookie是抵抗SYN-Flooding的防御机制.

防御原理简介:

在TCP服务器收到TCP SYN包并返回TCP SYN+ACK包时，不分配一个专门的数据区，

而是根据这个SYN包计算出一个cookie值.

在收到TCP ACK包时，TCP服务器在根据那个cookie值检查这个TCP ACK包的合法性.

如果合法，再分配专门的数据区进行处理未来的TCP连接.

你可以使用sysctl命令打开/关闭SYN cookie机制：

4. 实验结果分析

比较 netstat -na 前后状态如下:

产生大量的TCP半连接,阻塞了队列,导致后续正常TCP连接无法建立!!

TCP-RST攻击

1. FTP协议

2. TELNET协议

3. SSH协议

4. Newox 78简介

5. 实验结果分析

-** FTP**

FTP服务器地址: 192.168.59.146/24

FTP客户端地址: 192.168.59.144/24

攻击者地址: 192.168.59.1/24

攻击者终端对受害者进行TCP-RST打击:

结果显示:已经建立的TCP连接断开.

Telnet服务器地址: 192.168.59.146/24

Telnet客户端地址: 192.168.59.144/24

攻击者地址: 192.168.59.1/24

攻击者终端对受害者进行TCP-RST打击:

结果显示:已经建立的TCP连接断开.

SSH服务器地址: 192.168.59.146/24

SSH客户端地址: 192.168.59.144/24

攻击者地址: 192.168.59.1/24

攻击者终端对受害者进行TCP-RST打击:

结果显示:已经建立的TCP连接断开.

TCP会话劫持

1. 会话劫持简介

TCP会话劫持攻击的目标是通过向该会话中注入恶意内容来劫持两名受害者之间的现有TCP连接（会话）.

如果这个连接是一个telnet会话,攻击者可以在这个会话中注入恶意命令(例如删除重要文件),导致受害者执行恶意命令.

2. Wireshark简介

如果您使用Wireshark观察网络流量,当Wireshark显示TCP序列号时,

默认情况下会显示相对序列号,它等于实际序列号减去初始序列号.

如果想查看包中的实际序列号,则需要右键单击Wireshark输出的TCP部分,

然后选择"Protocol Preference". 在弹出窗口中，取消选"Relative Sequence Number"选项.

3. Netwox 40简介

4. 实验结果分析

Telnet服务器地址: 192.168.59.148/24

Telnet客户端地址: 192.168.59.146/24

攻击者地址: 192.168.59.1/24

攻击者终端对受害者进行TCP会话劫持:

我们要伪造发下一个包:

所以直接采用nextseq作为下一个包的ack,采用ack作为下一个包的seq.

最后一个Telnet数据包内容如下:

我们伪造向服务器 192.168.59.148 发送 ls 命令,

通过netwox构造我们的攻击指令如下:

在wireshark上显示抓包数据如下:

来创建我们的肉鸡~

现在我们来通过NC反弹一个Shell,来控制我们受害者:

首先是构造NC命令:

实验结果如图:

首先看结果:我们成功拿到了服务器上的用户gu的所有权限!

咱们再来看看抓包数据,通过抓包数据,你可以看到最后一条Telnet的TCP数据,通过这些数据,就可以很方便通过Netwox构造攻击语句了!!

⑺ wireshak tcp 抓包 怎么分析

点击Caputre->Interfaces.. 选择正确的网卡。然后点击"Start"按钮, 开始抓包.

第一次握手数据包

客户端发送一个TCP，标志位为SYN，序列号为0， 代表客户端请求建立连接。

⑻ 应用抓包之tcpmp命令抓包

原料
1.预抓包的App一个（我们以app抓包为例）
2.已配置android sdk
3.分析软件Wireshark（Windows版）
4.抓包命令：tcpmp
5.模拟器或真机（以模拟器为例，真机需root）

首先我们先配置下环境变量
1.先来个ANDROID_HOME:SDK的路径，类似于JAVA_HOME。（一劳永逸，以后安装到别的路径，改变一下HOME路径就行）

2.把sdk路径下的platfrom-tools和tools添加到环境变量

配置好就可以用adb命令了

1.执行tcpmp命令
tcpmp可以将网络中传送的数据包完全截获下来提供分析。

以上命令将截获的数据包保存到sdcard，capture.pcap抓取是数据包，pcap为Wireshark分析文件的后缀。

这时抓包就开始了，在手机上刷新几下要抓取数据的app。
抓完之后按ctrl+c停止抓包

2.将抓取的数据导出到电脑上（从sdcard导出到电脑上分析）
退出android shell环境(命令行输入两次exit)，回到Windows环境。

接着执行

导出刚才抓到的文件到电脑d盘。（如果导出失败，自己手动把抓包数据复制到电脑上）

或者通过DDMS导出到电脑

3.Wireshark打开刚才获取到的.pcap文件
过滤出http

点击某一个抓到的http包，可以查看它的详细信息(自己判断一下可能是哪个域名)

我们可以看到是get请求

复制出来去请求一下（右键->复制->值）

去浏览器中请求

再结合app，看看是哪个界面的内容
4.新建个文本文件，保存抓到的借口。例如：

看看请求出来ip地址，顺着ip找出所有的api借口

54开头的就是我要抓的app。

⑼ TCP网络数据包分析

------------保护自己的领地，保护电脑--------
计算机木马程序已经严重影响到各类计算机使用者的切身利益，当前最重要的是如何有效的防范木马的攻击。
1.使用防火墙阻止木马侵入
防火墙是抵挡木马入侵的第一道门，也是最好的方式。绝大多数木马都是必须采用直接通讯的方式进行连接，防火墙可以阻塞拒绝来源不明的TCP数据包。防火墙的这种阻塞方式还可以阻止UDP，ICMP等其他IP数据包的通讯。防火墙完全可以进行数据包过滤检查，在适当规则的限制下，如对通讯端口进行限制，只允许系统接受限定几个端口的数据请求，这样即使木马植入成功，攻击者也是无法进入到你的系统，因为防火墙把攻击者和木马分隔开来了。
2.避免下载使用免费或盗版软件
电脑上的木马程序，主要来源有两种。第一种是不小心下载运行了包含有木马的程序。绝大多数计算机使用者都习惯于从网上下载一些免费或者盗版的软件使用，这些软件一方面为广大的使用者提供了方便，节省了资金，另一方面也有一些不法分子利用消费者的这种消费心理，在免费、盗版软件中加载木马程序，计算机使用者在不知情的情况下贸然运行这类软件，进而受到木马程序的攻击。还有一种情况是，“网友”上传在网页上的“好玩”的程序。所以，使用者定要小心，要弄清楚了是什么程序再运行。
3、安全设置浏览器
设置安全级别，关掉Cookies。Cookies是在浏览过程中被有些网站往硬盘写入的一些数据，它们记录下用户的特定信息，因而当用户回到这个页面上时，这些信息就可以被重新利用。但是关注Cookies的原因不是因为可以重新利用这些信息，而是关心这些被重新利用信息的来源:硬盘。所以要格外小心，可以关掉这个功能。步骤如下:选择“工具”菜单下的“Internet选项”，选择其中的“安全”标签，就可以为不同区域的Web内容指定安全设置。点击下面的“自定义级别”，可以看到对Cookies和Java等不安全因素的使用限制。
4.加强防毒能力
“常在河边走，哪有不湿脚”，只要你上网就有可能受到木马攻击，但是并不是说没有办法来解决。在计算机上安装杀毒软件就是其中一种方法，有了防毒软件的确会减少受伤的几率。但在防毒软件的使用中，要尽量使用正版，因为很多盗版自身就携带有木马或病毒，且不能升级。新的木马和病毒一出来，唯一能控制它蔓延的就是不断地更新防毒软件中的病毒库。除了防毒软件的保护，还可以多运行一些其他软件。如天网，它可以监控网络之间正常的数据流通和不正常的数据流通，并随时对用户发出相关提示；如果我们怀疑染了木马的时候，还可以从网上下载木马克星来彻底扫描木马，保护系统的安全。........

⑽ 网络抓包原理

本文以App作为例子，实际应用不限于App范围。

大部分场合都可以通过程序调试来定位问题，但有些场景使用抓包来定位接口问题更准确、更方便，如以下场景：

要实现对App的网络数据抓包，需要监控App与服务器交互之间的网络节点，监控其中任意一个网络节点（网卡），获取所有经过网卡中的数据，对这些数据按照网络协议进行解析，这就是抓包的基本原理。

但是中间网络节点，不受我们控制，所以基本无法实现抓包的，只能在客户端和服务端进行抓包。

通常我们监控本地网卡数据，如下图：

本地网络 指的是WIFI的路由，如果直接抓路由器的包还是比较麻烦的，因此我们会在 手机 和 本地路由 之间加一层 代理服务 ，这样只要抓代理服务的网络数据即可：

虽然在 手机 侧也可实现抓包，但和 本地路由 一样，抓包比较麻烦，如果不是没有办法，尽量还是不在手机侧抓包。但是有一种情况必须在手机端抓包，那就是在4G网络情况下：

4G网络状态下如何抓包，以及它的劣势，我们后面章节再细讲。

抓包实际上是分析网络协议的一种过程，尽管繁琐的细节劳动都让抓包工具做了，但我们还是需要了解下基础的网络协议，好帮助我们更好的分析问题。

首先需要了解下经典的OSI七层网络模型，以及每层的作用，其次对TCP、HTTP协议简单了解。

HTTPS是基于HTTP协议的一种改进，在 TCP之上 的会话层增加安全处理。对于应用层来说，HTTPS和HTTP没有什么不同，也就是说，HTTPS是保证网络传输的安全性，对业务数据无侵入。

简化理解大概是这个样子：

SSL和TLS是保证安全传输的协议，包括证书认证、加解密和数字签名。

项目中HTTPS的链路：

因此，客户端与后台，编写网络接口时，不需要关心SSL或TLS，按照HTTP协议处理即可。

既然HTTPS在网络传输是经过加密的，那么抓包抓到的数据就是密文，不经过解密是无法看到报文的。针对这个问题，如上图WIFI环境下设置代理的方式可以解决，具体思路是：

所以整个网络链路依然是HTTPS在传输，但代理服务自己可以获取到明文数据。

比较常用的抓包工具大概有4个，主要用作互补，配合使用基本所有平台、所有抓包需求都能满足：

需要说明的是，tcpmp可将数据保存成文件，直接用wireShark打开分析，针对后台或手机抓包使用起来十分方便。

几个工具间的使用关系：

为什么要真机抓包？必定是没有办法设置代理服务了，如4G网络情况下直接和移动基站链接，没法设置代理服务。凡是非4G网络状态下，都不建议真机抓包。

iOS 5后，apple引入了RVI remote virtual interface的特性，它只需要将iOS设备使用USB数据线连接到mac上，然后使用rvictl工具以iOS设备的UDID为参数在Mac中建立一个虚拟网络接口rvi，就可以在mac设备上使用tcpmp，wireshark等工具对创建的接口进行抓包分析。

具体步骤：

android是linux系统，和后台一样可以使用tcpmp命令来抓包，但是需要root权限，因为一般手机系统不带有抓包命令 tcpmp ，需要自行安装。

安装tcpmp：

使用tcpmp：

这是就已经进入抓包状态，手机所有的网络请求都会被捕获，并保存到capture文件中。

导出capture文件：

原文： 网络抓包