WireShark的過濾規則
伯克利包過濾(BPF)(應用在wireshark的捕獲過濾器上)
伯克利包過濾中的限定符有下面的三種:
Type:這種限定符表示指代的對象,例如IP地址,子網或者端口等。常見的有host(用來表示主機名和IP地址),net(用來表示子網),port(用來表示端口)。如果沒有指定的話,默認爲host
Dir:這種限定符表示數據包傳輸的方向,常見的有src(源地址)和dst(目的地址)。如果沒有指定的話,默認爲” src or dst”。例如“192168.1”就表示無論源地址或者目的地址爲192.168.1.1
的都使得這個語句爲真。
Proto:這種限定符表示與數據包匹配的協議類型,常見的就是ether、ip、tcp、arp這些協議。
下面給出了一些常見的原語實例:
host 192.168.1.1 當數據包的目標地址或者源地址爲192.168.1.1時,過濾語句爲真
dst host 192.168.1.1 當數據包的目標地址爲192.168.1.1時,過濾語句爲真。
src host 192.168.1.1 當數據包的源地址爲192.168.1.1時,過濾語句爲真
ether host 11:22:33:44:55:56 當數據包的以太網源地址或者目的地址爲11:22:3:44:55:66時,過濾語句爲真。
ether dst 11:22:33:44:55:66 當數據包的以太網目的地址爲11:22:33:44:55:66過濾語句爲真。
ether src 11:22:33:44:55:66 當數據包的以太網源地址爲11:22:33:44:55:66濾語句爲真。
dst net192.168.1.0/24 當數據包的IP4/6的目的地址的網絡號爲192.168.1.0/24時,過濾語句爲真
src net192.168.1.0/24 當數據包的IPv4/6的源地址的網絡號爲192.168.1.0/24時,過濾語句爲真。
net 192.168.1.0/24 當數據包的IPv4/6的源地址或目的地址的網絡號爲192.168.1.0/24時,過濾語句爲真
dst port 8080 當數據包是tcp或者udp數據包且目的端口號爲8080時,過濾語句爲真。
src port 8080 當數據包是tcp或者udp數據包且源端口號爲8080時,過濾語句爲真。
port 8080 當數據包的源端口或者目的端口爲8080時,過濾命令爲真。
所有的port前面都可以加上關鍵字tcp或者udp
伯克利包過濾也支持到位的操作。具體的語法爲 proto[expr: size],這裏面的proto指代協議,expr表示相對給出協議層的字節偏移量,size表示要操作的字節數。其中sie的值是可選的,可以是124中的一個,默認值爲1
地址192.168.1.1轉換爲16進製爲“0xc0a80101”,最後就可以寫成:ip[12:4]=0xc0a80101
WireShark中的捕獲過濾器
Wireshark中提供了兩種不同的過濾器:捕獲過濾器和顯示過濾器。其中捕獲過濾器是在 WireShark捕獲過程的同時進行工作的,這意味着如果你使用了捕獲過濾器,那麼 WireShark就不會捕獲不符合規則的數據包。而顯示過濾器則不同,它是在 Wire Shark捕獲的過程後進行工作的,這表示即使你使用了顯示過濾器, Wire Shark仍然會捕獲不符合規則的數據包,但是並不會將它們顯示在數據包面板上。
捕獲過濾器的配置必須要在使用 WireShark進行捕獲數據包之前進行,配置過程的步驟如下所示:
首先依次選擇菜單欄上的“捕獲”->”選項”按鈕。
在“所選擇接口的捕獲過濾器”後面的文本框中填寫字符串形式的過濾器。
捕獲過濾器遵循了伯克利包過濾的語法,所以我可以使用上一節中介紹的各種命令來完成各種過濾任務。例如下面給出了一些常見的過濾器:
tcp dst port 80,只保留目標端口爲80的TCP數據包
ip src host 192.168.1.1,只保留源地址爲192.168.1.1的數據包
src portrange 2000-2500,只保留源端口在2000-2500之間的UDP和TCP數據包
not icmp,保留除了icmp以外的數據包
WireShark中的顯示過濾器
WireShark的顯示過濾器與捕獲過濾器有兩點明顯的不同,一是顯示過濾器可以在WireShark捕獲數據之後再使用,二是顯示過濾器的語法與捕獲過濾器語法並不相同。在 WireShark中有多種創建顯示過濾器的方法。
使用過濾器輸入框創建顯示過濾器
使用過濾器表達式創建顯示過濾器
我也可以使用 WireShark過濾器輸入框右側的”表達式”按鈕,單擊這個按鈕之後就可以查看到 WireShark過濾器表達式對話窗口。
在數據包細節面板中創建顯示過濾器
在數據包詳細列表處的中某一行單擊,例如我在 Source:116.211.186.209 這一行單擊鼠標右鍵的話,就會彈出一個菜單,這個菜單中選中“作爲過濾器應用“會彈出一個新的菜單。
使用WireShark分析鏈路層攻擊
據統計,目前網絡安全的問題有80%來自於“內部網絡”,很多黑客也將攻擊目標從單純的計算機轉到了網絡結構和網絡設計上來。因爲鏈路層是內部網絡通信最爲重要的協議,而交換機正是這一層的典型設備,所以我以交換機爲例。但是相比起其他網絡設備來說,交換機的防護措施往往也是最差的,因此也經常成爲黑客攻擊的目標
MAC地址欺騙攻擊
每個數據包 都包含了 源mac地址（發送者的mac地址） ，目標mac地址（對方的mac地址）
交換機是通過cam表裏mac地址和交換機端口的對應關係來傳遞網絡數據的
如果我改變mac地址和交換機端口的對應關係 那麼就能達到我的目的了
MAC地址泛洪攻擊
簡單而言，MAC地址泛洪攻擊就是黑客利用軟件在短時間內向交換機發送大量的數據包，導致交換機的cam表空間已滿，這個時候如果交換機再收到數據包就不再進行轉發了，而是退化成集線器，進行廣播，導致網絡資源緩慢甚至網絡癱瘓。
MAC地址泛洪攻擊的主要特徵爲：網速十分緩慢或網絡癱瘓，但是檢查硬件設施沒有問題。
接下來我通過wireshark查看數據包來分析一下MAC地址泛洪攻擊：
打開數據包後，我發現了大量的來歷不明的數據包，然後通過wireshark的統計功能我發現，這個數據包內大量的都是單純的ip數據包，而我知道，一個正常的網絡通信中，最多的應該是TCP或UDP數據包，這就說明這些數據包存在問題，很有可能是僞造的數據包。我繼續往下看。
我通過wireshark的會話功能發現，這些來歷不明的ip數據包的大小完全一致，並且交換機的通訊不再進行轉發，而變成了廣播。這個時候我基本可以斷定，交換機遭受了MAC地址泛洪攻擊，而那些來歷不明的數據包應該是使用同一個軟件僞造而來的。
特點：大量來歷不明的數據包，數據包大小都一樣，交換機不再進行轉發而變成廣播。
使用Wireshark分析中間人攻擊（MITM）
中間人攻擊的相關理論
中間人攻擊的目標並不是交換機，而是終端設備（例如計算機、手機等）。在每一臺終端設備中都有一個ARP緩存表，這個表中保存了一些P地址和MAC地址之間的對應關係。
通常應用程序只能通過P地址進行通信，但是在內部網絡中使用的交換機卻不能識別P地址。因此每一臺終端設備在發送應用程序產生的數據包時，必須在它裏面添加上一個MAC地址。而這個MAC地址是哪裏來的呢？
ARP協議的相關理論
數據包在局域網內部是無法使用P地址進行通信的，因爲局域網中的連接設備只能識別MAC（硬件）。但是應用程序發出的數據包中往往只包含了目標的P地址，此時就需要由ARP程序來找到數據包目的P地址對應的MAC地址。
在每一臺計算機中都存在有一個ARP緩存表，這個表動態地保存了一些地址和MAC地址的對應關係。當計算機接收到一個數據包之後，就會通過ARP程序在這個表中查找包中P地址所對應的表項，然後根據這個表項在數據包中再添加MAC地址
如果沒有在緩存表中找到對應的表項，ARP程序就會在局域網中進行廣播，詢問網絡中是否存在這樣一個P地址。如果局域網中有計算機使用了這個P地址，那麼它就會迴應一個包含了自己MAC地址的信息，這樣計算機就可以將這個信息添加到自己的ARP緩存中，並將這個數據包填寫好目的MAC地址發送輸出。
使用Wireshark的專家系統分析中間人攻擊
首先我對正常的本機進行抓包，分析ARP協議。我發現正常的arp協議只需要兩條數據，一條爲“請求”，一條爲“應答”。（Opcode爲1則爲請求，爲2則爲應答）
在我知道了正常的arp協議的工作模式後，我查看事先準備好的經過中間人攻擊後的數據包，進行分析。
我發現數據包充斥大量的arp協議數據，但是我知道，一個正常的數據包存在最多的應爲tcp和udp協議的數據，這個時候，我基本可以得出結論，終端遭受了中間人攻擊，或者是計算機感染了arp病毒、或是有攻擊者在進行arp掃描，在實際工作環境中，如果我的用戶名密碼遭遇泄露的情況，就基本可以斷定爲遭受了中間人攻擊。
然而這些只是我根據實際經驗得出的結論，人腦當然沒有計算機轉得快，在我費盡心思想這些東西的時候，wireshark的專家系統已經爲我分析好了。wireshark的專家系統在左下角的那個小點那裏，藍色爲會話，黃色爲警告，紅色爲錯誤。這裏我看到了警告級別的專家系統判斷。點擊小黃點，進入專家系統，查看警告的詳細信息。我發現同一個ip地址對應了兩個硬件地址，回到數據包中查看，發現192.168.169.2的地址對應着同一個重複大量的mac硬件地址，我可以判斷是使用軟件進行了中間人攻擊。因爲正常的arp工作只有一個請求和一個應答，這裏重複大量的mac地址肯定是僞造的。
使用WireShark分析淚滴攻擊
淚滴攻擊的相關理論（TearDrop）
針對P協議的攻擊方法，主要有僞造IP地址和發送畸形數據包兩種方式。我在這一章中選擇的淚滴攻擊就屬於發送畸形數據包這種方式，它的設計思路巧妙地利用了P協議裏面的缺陷，因此成爲了網絡安全裏面的一個經典案例。
這種攻擊的實現原理是向目標主機發送異常的數據包碎片，使得IP數據包碎片在重組的過程中有重合的部分，從而導致目標系統無法對其進行重組，進一步導致系統崩潰而停止服務的惡性攻擊。
考慮到這種攻擊是建立在P協議上，我先來簡單地瞭解一下P協議的幾個重要內容，包括P協議數據包的格式、分片方式以及存活時間（TTL）。
IP分片
片偏移就是用來實現對數據包進行分片，可是爲什麼數據包要分片呢，把所有信息放在一個數據包中不是更方便？這其實是和一個名爲MTU（最大傳輸單元）的值有關。我知道數據包的最外面要添加一個以太網的幀頭，幷包裝成一個數據幀之後才能傳輸。由於以太網傳輸電氣方面的限制，以太網幀的大小都有限制每個以太網幀最小也要64Bytes4，最大不能超過1518bytes去以太網幀的幀頭（MAC目的地址MAC48bit=6Bytes+SMAC，源MAC地址48bit=6Bytes+type域2bytes）14Bytes和幀尾C校驗部分4Bytes（這個部分有時候也被稱作FCS），那麼剩下承載上層協議的地方也就是Data域最大就只能有1500Bytes，這個值我就把它稱之爲MTU。這也就是我幾乎所有設備的MTU值都爲1500的原因
我分析一下這個數據包，發現第八條和第九條數據的標識符是一樣的，這說明這兩條數據是同一個數據包，只是在傳輸過程中被拆開了。然後我看一下第八條數據的分片，發現第三位爲1，這說明它是一個分片並且不是最後一個。（第四位表示相對於原始數據報的偏移，單位爲8字節）
淚滴攻擊
淚滴（teardrop）攻擊是基於數據分片傳送進行的攻擊手段。在P報頭中有一個偏移字段和一個分片標誌（MF），如果MF標誌設置爲1，則表明這個P包是一個大P包的片斷，其中偏移字段指出了這個片斷在整個P包中的位置。例如，對一個4200 Bytes的ip包進行分片（MTU爲1480），則3個片斷中偏移字段的值依次爲:01480、2960這樣接收端就可以根據這些信息成功的組裝該P包。而如果一個攻擊者打破這種正常情況，把偏移字段設置成不正確的值，即可能出現重合或斷開的情況，就可能導致目標操作系統崩潰。比如，把上述偏移設置爲0、1000、2000
圖中陰影部分的就是兩個數據包有重合的地方，目標設備在接收到這種分片之後就無法重新組合成一個數據包，這就是所謂的淚滴攻擊。這種攻擊方式在以前曾經給計算機用戶帶來了很大的困擾，但是對如今的操作系統基本無效，只是有時攻擊者會將其與泛洪相結合來作爲一種攻擊手段。
使用WireShark分析SYN Flooding攻擊
拒絕服務攻擊的相關理論
服務器所面臨的最大威脅當數拒絕服務攻擊,拒絕服務攻擊其實是一類攻擊的合稱。所有這種類型的攻擊的目的都是相同的,那就是要是使受攻擊的服務器系統癱瘓或服務失效,從而使合法用戶無法得到相應的資源。雖然服務器的功能多種多樣,但是這些差異都是表現在應用層,無論它們使用的是什麼應用程序,但是最終都會使用到傳輸層的協議。而傳輸層常用的協議只有TCP和UDP兩種。因此攻擊者只需要研究這兩個協議的缺陷，就幾乎可以實現對所有類型服務器的攻擊。
目前已經出現了很多種類型的拒絕服務攻擊方式,我只挑選其中最爲典型的兩種SYN flooding攻擊和UDP flooding攻擊進行講解。其中SYN flooding攻擊是針對TCP協議的,它的主要目的是佔用目標上所有可用的連接請求。而UDP flooding攻擊則是針對UDP協議的,主要目的是耗盡目標所在網絡的帶寬
TCP連接的建立方式
TCP協議在進行通信之前需要先建立連接,例如一個客戶機和一個服務器之間在發送實際的數據之前,會互相向對方發送控制數據包。這個過程使得客戶機和服務器都進入連接狀態,然後就可以進行數據交換了,我稱其爲3次握手。握手過程一旦完成,客戶機和服務器之間就建立好了一個連接,因此我在描述TCP協議時會說這是一個面向連接的協議。
SYN Flooding攻擊
這種攻擊最早出現於1996年,當時大量的網站服務器都遭受到了這種 SYN flooding攻擊。這種攻擊利用了TCP連接的3次握手,但是這個握手過程是建立在理想狀態而在實際狀態下當服務器收到了來自客戶端發送的SYN請求之後,會發出一個SYN-ACK迴應,是連接進入到了半開狀態,但是這個迴應很有可能會因爲網絡問題無法達到客戶端。所以此時需要給這個半開的連接設置一個計時器,如果計時完成了還沒有收到客戶端的Ack迴應,就會重新發送SYN-ACK消息,直到超過一定次數之後纔會釋放連接。服務器需要爲每一個半開連接分配一定的系統資源,所以當出現數量衆多的半開連接時,服務器就會因爲資源耗盡,進而停止對所有連接請求的響應。
使用HPing3發起攻擊
這次我採用 Kali Linux2中自帶的 hping3來進行一次拒絕服務攻擊。這是一款用於生成和解析TCP/P協議數據包的開源工具之前推出過 hping和hing2兩個版本,目前最新的版本是 hping3。利用這款工具我可以快速定製數據包的各個部分, hping3也是一個命令式的工具,其中的各種功能要依靠設置參數來實現。啓動 hping3的方式就是在 Kali Linux2 hping2中啓動一個終端,然後輸入hping3即可:
root@kali: ~ hping3
hping3>好了,現在我就利用剛剛介紹過的 hping3參數來構造一次基於TCP協議的拒絕服務攻擊。在 Kali Linux2中打開一個終端,然後在終端中輸入:
hping -q -n --rand-source3 -S-p 80 --flood 目標IP這時攻擊就開始了,在這個過程中你可以隨時使用Ctrl+C組合鍵來結束這次攻擊。
可以看到在短時間內生成了大量的數據包
使用WireShark的流量圖功能分析
在wireshark的統計菜單中我可以找到流量圖的功能，如下圖所示。
我查看一下剛剛抓取到的模擬SYN Flooding攻擊的數據包的流量圖，發現大量的源地址都是隻向目的地址發送了SYN請求，而並沒有做出應答，這個時候我基本可以確定遭受了SYN Flooding攻擊。
SYN Flooding攻擊的解決方案
丟棄第一個SYN數據包
反向探測
代理模式
使用WireShark分析UDP Flooding攻擊
雖然與TCP一樣位於傳輸層,UDP協議卻不需要建立連接就可以傳輸數據,而且少了很多的控制機制,因而傳輸速度高於TCP協議,所以也得到了廣泛的使用。
不過,UDP協議也面臨着一個和TCP協議一樣的威脅,那就是泛洪攻擊。
不過不同於TCP協議佔用服務器連接數的方式,UDP協議因爲不需要建立連接,所以攻擊者將目標轉向了帶寬,他們構造大量體積巨大的UDP數據包併發往目標,從而導致目標網絡的癱瘓。
由於依賴UDP的應用層協議五花八門,差異極大,因此針對UDP Flooding的防護非常困難
UDP Flooding的相關理論
UDP是一個無連接的傳輸層協議,所以在數據傳輸過程,不需要建立連接和進行認證。攻擊者只需要向目標發送大量巨大的UDP數據包,就會使目標所在的網絡資源被耗盡。UDP Flooding是一種傳統的攻擊方式,近年來黑客經過精心設計,又創造了新的攻擊方法。
攻擊者使用源P欺騙的方法向有漏洞的UDP服務器發送僞造請求，UDP服務器不知道請求是僞造的,於是禮貌地準備響應。當成千上萬的響應被傳遞給一個不知情的目標主機時,這個攻擊問題就會發生。
模擬UDP Flooding攻擊
這次我採用 Kali Linux2中自帶的 Hping3來進行一次拒絕服務攻擊。在第12章中我對這個工具的簡單
用法進行了講解。現在我就利用剛剛介紹過的ping3參數來構造一次基於UDP協議的拒絕服務攻擊,在
Kali Linux2中打開一個終端,然後在終端中輸入:
hping3 -q -n -a 10.0.0.1 --udp -s 53 -p 68 --flood 目標lP -d 1000現在攻擊就開始了,在這個過程中可以隨時使用trl+C組合鍵來結束,在攻擊的同時我使用 Wireshark捕獲這個過程產生的數據包。
我發現有大量的由1.1.1.1發往192.168.1.102的數據包，至此，模擬UDP Flooding攻擊完成。接下來我使用wireshark對捕獲到的數據包進行分析。
使用WireShark的繪圖功能分析
現在我使用 Wireshark中提供的繪圖功能來直觀地查看這些數據包對網絡造成了什麼影響。Wireshark中提供的繪圖功能可以用更直觀的形式展示數據包的數量。我利用菜單欄上的”統計(statistics)”→”IO圖表( graph)”選項來生成一個圖表,打開的”IO圖表”對話框.
通過IO圖表我發現在11-12秒的時候，開始出現UDP數據包，並在之後的一秒內產生了大量的UDP數據包。這樣就導致網絡設備沒有能力處理其他流量，最終導致網絡癱瘓。
解決方案
基於目的IP地址的限流
基於目的安全區域的限流
基於會話的限流
除了這種簡單粗暴的限流機制之外,在華爲公司編寫的《華爲防火牆技術漫談》中還提到了另一種更有建設性的思路:指紋學習。
指紋學習是通過分析UDP報文中的數據內容來判斷它是否異常。
防火牆首先會對發往某個服務器的UDP報文進行統計,當達到指定閾值時,就會開始進行指紋學習。
如果這些報文攜帶的數據具有相同特徵,就會被學習成指紋。
後續的報文如果具有與此指紋相匹配的特徵就會被當成攻擊報文而丟棄。
使用wireshark分析緩衝區溢出漏洞
緩衝區溢出漏洞的相關理論
緩衝區溢岀是一種非常普遍、非常危險的漏洞,在各種操作系統、應用軟件中廣泛存在。
利用緩衝區溢出進行攻擊,可以導致程序運行失敗、系統宕機、重新啓動等後果。
更爲嚴重的是,攻擊者可以利用它執行非授權指令,甚至可以取得系統特權,進而執行各種操作。
考慮到目前大量的應用程序都使用了B/S結構,這種結構正是使用HTTP協議進行通信的。
使用wireshark分析
在用戶和服務器經過三次握手成功建立連接後，我發現用戶向服務器請求了一個特別大的數據包，因爲數據報太大了導致被截斷分成了4個數據包分別請求。而正常的數據包是不可能有這麼長的長度的，只有攻擊者在進行緩衝區溢出攻擊的時候纔會有可能出現這種數據包。
接下來，我打開這個數據包，先查看一下這個緩衝區的大小是多少。中間的這些字符都是用於緩衝區溢出攻擊所用的大量無用字符，一共4061個字符。
然後我就可以分析一下緩衝區溢出攻擊的特徵，並將其特徵寫到入侵檢測系統中，經過查看，我發現這個數據包的特徵爲：
請求方法爲GET請求
中間的無用字符一共有4061個
最後以HTTP /1.0結尾
然後我繼續向下分析，發現服務器主動向客戶端發送了請求並完成了三次握手建立連接的過程，這當然是不正常的。
經過分析，這種情況是由於服務器感染了“反向木馬”，纔會導致服務器主動發起連接請求。然後我追蹤一下這個請求的TCP流，發現了一個PE文件。這樣基本可以百分之百確定感染了木馬。
使用wireshark分析HTTPS
HTTPS （全稱：Hyper Text Transfer Protocol over SecureSocket Layer），是以安全爲目標的 HTTP 通道，在HTTP的基礎上通過傳輸加密和身份認證保證了傳輸過程的安全性。HTTPS 在HTTP 的基礎下加入SSL層，HTTPS 的安全基礎是 SSL，因此加密的詳細內容就需要 SSL。HTTPS 存在不同於 HTTP 的默認端口及一個加密/身份驗證層（在 HTTP與TCP之間）。這個系統提供了身份驗證與加密通訊方法。現在它被廣泛用於互聯網上安全敏感的通訊，例如交易支付等方面。
當我抓取到https協議的數據包時，wireshark中顯示的是TLS協議，是經過加密的，然後我查看數據包也是一堆亂碼，什麼也看不出來
然後我導入密鑰，將TLS 進行解密，就可以查看了
使用wireshark分析USB通信
進行對usb抓包，然後按下鍵盤查看數據包。當我按下鍵盤時，usb向電腦發送了一段8個字節的信息，然後我查看usb標準進行對照，可以很快地查看出我按下的是“A”鍵
在wireshark中添加新協議
foo.lua
local foo=Proto("foo","foo Protocol")
Trans_ID=ProtoField.unit16("foo.ID","ID")
Msg_Type=ProtoField.unit16("foo.Type","Type")
Msg_Data=ProtoField.unit32("foo.Data","Data")
foo.fields={Trans_ID,Msg_Type,Msg_Data}
function foo.dissector(tvb,pinfo,tree)
pinfo.cols.protocol="foo"
local subtree=tree.add(foo,tvb(0))
subtree.add(Trans_ID,tvb(0,2))
subtree.add(Msg_Type,tvb(2,2))
subtree.add(Msg_Data,tvb(4,4))
end
DissectorTable.get(""tcp.port):add(10005,foo)