WireShark抓包原理解析及抓包实战教程
1、WireShark快速分析數(shù)據(jù)包技巧
(1)確定 Wireshark的物理位置。如果沒有一個正確的位置,啟動 Wireshark后會花費很長時問捕獲一些與自己無關(guān)的數(shù)據(jù)。“
(2)選擇捕獲接口。一般都是選擇連接到Internet網(wǎng)絡的接口，這樣才可以捕獲到與網(wǎng)絡相關(guān)的數(shù)據(jù)。否則，捕獲到的其它數(shù)據(jù)對自己也沒有任何幫助。
(3)使用捕獲過濾器。通過設置捕獲過濾器，可以避免產(chǎn)生過大的捕獲數(shù)據(jù)。這樣用戶在分析數(shù)據(jù)時，也不會受其它數(shù)據(jù)干擾。而且，還可以為用戶節(jié)約大量的時間。”
(4)使用顯示過濾器。通常使用捕獲過濾器過濾后的數(shù)據(jù)，往往還是很復雜。為了使過濾的數(shù)據(jù)包再更細致，此時使用顯示過濾器進行過濾。“
(5)使用著色規(guī)則。通常使用顯示過濾器過濾后的數(shù)據(jù)，都是有用的數(shù)據(jù)包。如果想更加突出的顯示某個會話，可以使用著色規(guī)則高亮顯示。
(6)構(gòu)建圖表。如果用戶想要更明顯的看出一個網(wǎng)絡中數(shù)據(jù)的變化情況，使用圖表的形式可以很方便的展現(xiàn)數(shù)據(jù)分布情況。“
(7)重組數(shù)據(jù)。當傳輸較大的圖片或文件時，需要將信息分布在多個數(shù)據(jù)包中。這時候就需要使用重組數(shù)據(jù)的方法來抓取完整的數(shù)據(jù)。Wireshark的重組功能，可以重組一個會話中不同數(shù)據(jù)包的信息，或者是重組一個完整的圖片或文件。
2、實戰(zhàn)：WireShark抓包及快速定位數(shù)據(jù)包技巧
2.1常見協(xié)議包
ARP協(xié)議
ICMP協(xié)議
TCP協(xié)議
UDP協(xié)議
DNS協(xié)議
HTTP協(xié)議
2.2使用 WireShark 進行抓包
啟動WireSharke
2.3 混雜模式介紹
1）混雜模式概述：混雜模式就是接收所有經(jīng)過網(wǎng)卡的數(shù)據(jù)包，包括不是發(fā)給本機的包，即不驗證MAC地址。普通模式下網(wǎng)卡只接收發(fā)給本機的包(包括廣播包)傳遞給上層程序，其它的包一律丟棄
一般來說，混雜模式不會影響網(wǎng)卡的正常工作，多在網(wǎng)絡監(jiān)聽工具上使用。
2）關(guān)閉和開啟混雜模式方法
打開wireshark，點擊capture（捕獲）——Options（選項）
勾選箭頭，Enable promiscuous mde on all interfaces（在所有接口上使用混雜模式），這樣就開啟混雜模式，取消勾選，就變?yōu)槠胀Ｊ?/strong>
2.4 WireShark的過濾使用
開啟混雜模式，在捕獲過濾器處輸入如下指令
1）host 172.16.12.15 捕獲該IP相關(guān)的數(shù)據(jù)包
2）src 172.16.12.15 捕獲該IP發(fā)出去的數(shù)據(jù)包
3）dst 172.16.12.15 捕獲所有發(fā)給該IP的數(shù)據(jù)包
4）port 80 捕獲和80端口有關(guān)的數(shù)據(jù)包
5）ether host [MAC地址] 捕獲該MAC地址相關(guān)的數(shù)據(jù)包
在顯示過濾器下面輸入如下指令
1、tcp/arp/udp/http/dns等 捕獲所有tcp數(shù)據(jù)包
2、ip.src_host == 172.16.12.15 or ip. dst_host ==172.16.12.2 捕獲源地址是15或者目標地址是2的ip
3、ip.src_host == 172.16.12.15 and ip.dst_host ==172.16.12.2 捕獲源地址是15且目標地址是2的ip and可以用&&表示
4、ip.addr == == 172.16.12.15 and ip.addr ==172.16.12.2
3 、實戰(zhàn)：使用 WireShark 對常用協(xié)議抓包并分析原理
協(xié)議分析的時候我們關(guān)閉混淆模式，避免一些干擾的數(shù)據(jù)包存在。
3.1常用協(xié)議分析-ARP協(xié)議
地址解析協(xié)議(英語：Address Resolution Protocol，縮寫：ARP)是一個通過解析網(wǎng)絡層地址來找尋數(shù)據(jù)鏈路層地址的網(wǎng)絡傳輸協(xié)議，它在 IPv4 中極其重要。ARP是通過網(wǎng)絡地址來定位 MAC 地址。
關(guān)閉混雜模式，顯示過濾器輸入arp
Address Resolution Protocol (reply) #ARP 地址解析協(xié)議 reply 表示回復包
Hardware type: Ethernet (1) #硬件類型
Protocol type: IPv4 (0x0800 ) #協(xié)議類型~
Hardware size: 6 #硬件地址
Protocol size: 4 #協(xié)議長度
Opcode: reply(2) #操作碼，該值為2 表示ARP回復包 1表示request請求包
Sender MAC address: XXXXXXXXXXXX(9c:61：21:75:55:50) #源MAC地址Sender IP address: 192.168.1.1 #源IP地址
Target MAC address: VMware_f1:35:ee (00:0c:29:f1:35:ee) #目標MAC地址Target IP address: 192.168.1.53 #目標 IP地址
總結(jié)：我們可以看到到應答包補全了自己的 MAC 地址，目的地址和源地址做了替換我們再來看兩個數(shù)據(jù)包的請求和過程
Who has 192.168.1.1? Tell 192.168.1.53
192.168.1.1 is at 9c:61:21:75:55:50
192.168.1.53 廣播：誰有192.168.1.1的MAC地址?
192.168.1.1 應答：192.168.1.1的MAC地址是XXXXXXXXXXX
3.2常用協(xié)議分析-ICMP協(xié)議
ICMP請求包
Internet Control Message Protocol
Type:8 (Echo (ping) request)
Code:0 #type0 協(xié)議類型8 code 0 代碼0 表示請求報文
Checksum:Oxfd1c [correct] #校驗和，用戶檢查錯誤的數(shù)據(jù)
[Checksum Status:Good] #校驗狀態(tài)：good
Identifier (BE):63126（Oxf696)
Identifier (LE):38646（0x96f6） #ID值，在應答包中返回該字段
Sequence Number (BE):1 (0x0001) #序列號依舊在應答包中返回該字段
Sequence Number (LE):256 (0x0100)
[Response frame:654] 響應幀的序列號：654
Timestamp from icmpdata:Sep 8，202108:54:30.000000000 EDT [Timestamp from icmp data(relative)：0.746635014 seconds] Data (48 bytes)
ICMP響應包
Internet Control Message Protocol
Type:0(Echo (ping) reply)
Code:0 #type0 協(xié)議類型0 code 0 代碼0 表示回顯應答報文
Checksum:0x051d [correct] #校驗和
「Checksum Status:Goodl
Identifier (BE):63126（Oxf696）
Identifier (LE):38646（0x96f6)
Sequence Number (BE):1 (0×0001)
Sequence Number (LE):256 (0x0100) #這里的ID和序列號和請求包一樣
[Request frame:653] #請求幀的序列號
[Response time:60.003 ms] #響應時間
Timestamp from icmp data: Sep 8,2021 08:54:30.000000000 EDT [Timestamp from icmp data(relative):0.806637645seconds]Data (48 bytes) #填充數(shù)據(jù)，共48字節(jié)
本機發(fā)送一個ICMP Echo Request的包
接收方返回一個ICMP Echo Reply，包含了接受到數(shù)據(jù)拷貝和一些其他命令
3.3 常用協(xié)議分析-TCP協(xié)議
三次握手
三次握手統(tǒng)計圖
到這里三次握手就結(jié)束了，下面是三次握手統(tǒng)計圖
四次揮手
我們分析一下過程，我們在終端輸入 EXIT 實際上是在我們Kali上執(zhí)行的命令，表示我們SSHD的Server 端向客戶端發(fā)起關(guān)閉鏈接請求。“
第一次揮手：服務端發(fā)送一個[FIN+ACK]，表示自己沒有數(shù)據(jù)要發(fā)送了，想斷開連接，并進入FIN WAIT 1狀態(tài)
第二次揮手：客戶端收到 FIN 后，知道不會再有數(shù)據(jù)從服務端傳來，發(fā)送 ACK 進行確認，確認序號為收到序號+1(與SYN相同，一個 FIN占用一個序號)，客戶端進入CLOSE_WAIT狀態(tài)。
第三次揮手：客戶端發(fā)送[FIN+ACK]給對方，表示自己沒有數(shù)據(jù)要發(fā)送了，客戶端進入LAST_ACK 狀態(tài)，然后直接斷開TCP會話的連接，釋放相應的資源。+
第四次揮手：服務戶端收到了客戶端的 FIN 信令后，進入TIMED_WAIT狀態(tài)，并發(fā)送ACK確認消息。服務端在TIMED_WAIT狀態(tài)下，等待一段時間，沒有數(shù)據(jù)到來，就認為對面已經(jīng)收到了自己發(fā)送的ACK 并正確關(guān)閉了進入CLOSE 狀態(tài)，自己也斷開了TCP連接，釋放所有資源。當客戶端收到服務端的ACK回應后，會進入CLOSE狀態(tài)并關(guān)閉本端的會話接口，釋放相應資源。
3.4 常用協(xié)議分析-GTTP協(xié)議
┌──(root💀kali)-[~]
└─# curl -I baidu.com 請求百度頭部字段
HTTP/1.1 200 OK
Date: Thu, 09 Sep 2021 11:53:50 GMT
Server: Apache
Last-Modified: Tue, 12 Jan 2010 13:48:00 GMT
ETag: "51-47cf7e6ee8400"
Accept-Ranges: bytes
Content-Length: 81
Cache-Control: max-age=86400
Expires: Fri, 10 Sep 2021 11:53:50 GMT
Connection: Keep-Alive
Content-Type: text/html
第一步：我們我們發(fā)送了一個HTTP的HEAD請求
第二步：服務器收到我們的請求返回了一個Seq/ACK進行確認
第三步：服務器將 HTTP的頭部信息返回給我們客戶端 狀態(tài)碼為200 表示頁面正常
第四步：客戶端收到服務器返回的頭部信息向服務器發(fā)送Seq/ACK進行確認
發(fā)送完成之后客戶端就會發(fā)送FIN/ACK來進行關(guān)閉鏈接的請求。
4、實戰(zhàn)：WireShark抓包解決服務器被黑上不了網(wǎng)
場景：服務器被黑上不了網(wǎng)，可以ping通網(wǎng)關(guān)，但是不能上網(wǎng)。
模擬場景
修改主機TTL值為1，下面的方式是我們臨時修改內(nèi)核參數(shù)。
┌──(root💀kali)-[~]
└─# cat /proc/sys/net/ipv4/ip_default_ttl
64
┌──(root💀kali)-[~]
└─# echo "1" > /proc/sys/net/ipv4/ip_default_ttl
┌──(root💀kali)-[~]
└─# cat /proc/sys/net/ipv4/ip_default_ttl
1
TTL（time to live）： 數(shù)據(jù)報文的生存周期。每過一個網(wǎng)絡設備，TTL值-1
默認 linux 操作系統(tǒng)值：64，每經(jīng)過一個路由節(jié)點，TTL值減1。TTL值為0時，說明目標地址不可達并返回：Time to live exceeded
作用：防止數(shù)據(jù)包，無限制在公網(wǎng)中轉(zhuǎn)發(fā)。我們測試結(jié)果
┌──(root💀kali)-[~]
└─# ping 192.168.0.1
PING 192.168.0.1 (192.168.0.1) 56(84) bytes of data.
From 192.168.0.36 icmp_seq=1 Time to live exceeded
64 bytes from 192.168.0.1: icmp_seq=1 ttl=64 time=1.99 ms #網(wǎng)關(guān)可以ping通
┌──(root💀kali)-[~]
└─# ping baidu.com -c1
PING baidu.com (220.181.38.148) 56(84) bytes of data.
From localhost (192.168.0.1) icmp_seq=1 Time to live exceeded
#出了網(wǎng)關(guān)，TTL為0，數(shù)據(jù)包丟棄，百度ping不通
我們可以看到提示我們 Time to live exceeded 這表示超過生存時間，
我們判斷和目標之間經(jīng)過多少個網(wǎng)絡設備是根據(jù)目標返回給我們的 TTL 值來判斷的，因為我們發(fā)送的數(shù)據(jù)包是看不到的。
開啟抓包，過濾ICMP，然后ping百度，抓包結(jié)果如下
我們可以看到第一個包是發(fā)送了一個ping 請求包ttl=1
然后呢我們收到了網(wǎng)關(guān) 192.168.1.1 返回給我們的數(shù)據(jù)包告訴我們超過數(shù)據(jù)包生存時間，數(shù)據(jù)包被丟棄。
那我們把 TTL值修改成2會有什么效果呢？
┌──(root💀kali)-[~]
└─# echo "2" > /proc/sys/net/ipv4/ip_default_ttl
──(root💀kali)-[~]
└─# ping baidu.com -c1 1 ?
PING baidu.com (220.181.38.251) 56(84) bytes of data.
From localhost (192.168.1.1) icmp_seq=1 Time to live exceeded
我們對比數(shù)據(jù)包發(fā)現(xiàn)返回我們數(shù)據(jù)包被丟棄的源地址變成了220.181.38.251，這證明了數(shù)據(jù)包在網(wǎng)絡中已經(jīng)到達了下一個網(wǎng)絡設備才被丟棄，由此我們還判斷出我們的運營商網(wǎng)關(guān)地址為 220.181.38.251，但是我們并沒有到達目標主機。
那TTL恢復成正常的64，結(jié)果如何？
┌──(root💀kali)-[~]
└─# echo "64" > /proc/sys/net/ipv4/ip_default_ttl
┌──(root💀kali)-[~]
└─# ping baidu.com -c1
PING baidu.com (220.181.38.148) 56(84) bytes of data.
64 bytes from 220.181.38.148 (220.181.38.148): icmp_seq=1 ttl=50 time=16.9 ms
目標返回給我們的TTL值為50，這表示我們的TTL值需要大于64-50=14才可以訪問百度
下載mtr 路由跟蹤工具進行查看
┌──(root💀kali)-[~/Desktop]
└─# apt install mtr --fix-missing
檢測到達www.baidu.com的所有節(jié)點的通信質(zhì)量
┌──(root💀kali)-[~/Desktop]
└─# mtr www.baidu.com
如圖，主機連接到百度需要經(jīng)過13個設備（13跳），100%表示丟包嚴重，可能是被防火墻過濾、
總結(jié)
以上是生活随笔為你收集整理的WireShark抓包原理解析及抓包实战教程的全部內(nèi)容，希望文章能夠幫你解決所遇到的問題。
- 上一篇： php 顺序结构,顺序存储结构php实现
- 下一篇： 操作高通QXDM5，点击重置按钮出现报错