網路安全中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文件：

原文： 網路抓包