網絡接口層安全

網絡接口層,通常也稱為數據鏈路層或數據鏈路,是TCP/IP模型的最底層。這一特定的層次有多個特有的能被黑客發掘利用的安全漏洞。

網絡接口層 編輯

網絡接口層,通常也稱為資料連結層,是在主機系統和網絡硬件之間的物理接口。它定義了數據包如何被格式化之後進行發送和路由。一些常見的數據鏈路層協議包括IEEE802.2X.25[1] 數據鏈路層以及與這一層相關的的協議管理着電腦主機和網絡硬件之間的硬件物理接口。這一層的工作目的是給連接在網絡中的主機之間提供可靠的通信。一些由這一網絡協議棧提供的服務包括。[2]

  • 數據幀 - 將數據流分解為獨立的幀或包。
  • 校驗和 - 為每一幀數據發送校驗和數據,以便讓接受數據的節點確定接收到的數據是否是沒有錯誤的。
  • 確認信號 - 從接收方向發送方發送一個正面的(數據正在被接受)或者負面的(數據沒有接受到但是希望接受)的確認信號以便確保數據傳輸的可靠性。
  • 流控制 - 緩衝發送數據以確保一個快速的發送方不會壓制一個較慢的接收方。

脆弱性和防守策略 編輯

有線網絡 編輯

內容地址內存(CAM)表耗盡攻擊 編輯

數據鏈路層基於目標硬件的物理媒體訪問控制(MAC)地址給每個數據包添加地址。網絡中的交換機維護着映射了交換機端口到特定MAC地址的CAM表。這些表讓交換機能夠將數據包只分發到他們各自指向的物理地址。用交換機來連接那些正在通信的系統比像網絡集線器那樣直接將所有的流量廣播到所有端口要更加安全,[3] 後者會讓竊聽者能夠攔截和監視所有的網絡流量。一個CAM表耗盡攻擊基本做的就是把一個交換機變成一個集線器。[4] 攻擊者們用大量新的MAC-到-端口的映射覆蓋CAM表一直到表的固定大小的內存分配被用光。在這個時刻,交換機將不再知道如何分發那些基於MAC-到-端口映射的流量,只能默認地將流量廣播到所有端口。一個敵人接下來就可以截獲和監視所有通過交換機的流量,這些流量包括密碼,郵件,即時消息等等。[5] CAM表溢出攻擊可以通過配置交換機上面的端口安全設置來預防。這一選項要麼規定了交換機上特定端口的MAC地址,要麼規定了一個交換機端口可以記住的MAC地址數量。當一個無效的MAC地址被從一個端口檢測到,那麼交換機可以封鎖這個惡意的MAC地址或者關閉該端口[6]

地址路由協議(ARP)欺騙 編輯

在數據鏈路層一個被網絡層指定的邏輯IP地址被轉譯成一個物理MAC地址。為了確保可靠的數據通信,所有的網絡中的交換機必須維護一個最新的映射了ip邏輯地址到MAC物理地址的表格。如果一個客戶端或者交換機不確定一個它接受到的數據包的IP到MAC的映射,它將會發送一個ARP請求信息給最近的交換機查詢與這個特定IP相關聯的MAC地址。當完成這個過程後,客戶端或者交換機會更新他的表格以反映最新的映射。在一個ARP欺騙攻擊中,攻擊者會廣播他要攻擊的機器的IP地址和他自己的MAC地址。所有的附近的交換機接下來會更新他們的映射表並且開始將發送數據的目的地址設置為攻擊者系統的IP地址對應的MAC地址。[4] 這種攻擊通常被稱為「中間人」攻擊。 防禦ARP欺騙通常依靠一些形式的證書或者ARP回應的交叉對比。沒有認證的ARP回應會被封鎖。這些技術可能被集成到動態主機配置協議(DHCP)服務中,所以動態和靜態IP都會被認證。這一能力也會被在一些獨立的主機上被實現或者集成到以太網交換機或其他網絡設備上。[7]

動態主機配置協議(DHCP)耗竭攻擊 編輯

當一個沒有IP地址的客戶端系統進入網絡時他會從常駐的DHCP服務器那裡索求一個IP地址。DHCP服務器會保留一個IP地址(所以任何其他人索要IP地址時將不會被授予這個IP地址),然後他會發送IP地址以及該IP地址最長有效租期給那些需要IP地址的設備。通常來說,從這一刻開始,設備會通過確認IP地址與DHCP服務器進行響應,並且DHCP服務器也會最終回復一個確認響應。

在一個DHCP耗竭攻擊中,一旦攻擊者從DHCP服務器那裡接收到了IP地址和租賃期,攻擊者不會回復確認信號。取而代之的是攻擊者會讓DHCP服務器充斥着IP地址請求,直到服務器內所有的地址空間都被分配(耗竭)掉。在這時,任何其他想要加入網絡的主機都會被拒絕接入,從而導致拒絕服務。攻擊者接下來可以設置一個流氓DHCP服務器,所以客戶端會接收到不正確的網絡設置並且導致數據被發送到攻擊者的機器上。[8]

防禦這種攻擊的一種方法是使用許多網絡交換機上具備的IP源防護功能。IP源仿佛功能一開始會封鎖除了DHCP包外的其他所有流量。當一個客戶端從一個DHCP服務器那裡接收到了一個有效的IP地址,IP地址和交換機端口的關係會綁定到訪問控制表(ACL)中。ACL會接下來會將流量限制到那些只有被配置綁定了的IP地址中。[9]

無線網絡 編輯

隱藏節點攻擊 編輯

在一個無線網絡中,許多主機和節點共用一個共同的媒介。如果節點A和B都是無線筆記本電腦,他們在同一個辦公室環境下通信,他們的通信因為物理上的分隔從而需要通過一個無線接入點進行中轉。但是為了避免數據包碰撞,一個時刻只可以有一個設備可以發送數據。在發送數據前,節點A發送一個準備好發送(RTS)信號,如果無線接入點不在接受其他任何數據流量,他將會通過網絡逛過一個可以發送(CTS)信號。節點A會接下來開始發送數據而節點B會知道要暫時停止發送他的數據。即使它不能直接和節點A通信,也就是說節點A是隱藏起來的,通過和AP通信,他知道要等待A的發送完成。一個攻擊者可以利用這一功能大量發送帶有CTS的信息來泛濫攻擊整個網絡。然後每個節點會假定有一個隱藏的節點在嘗試發送數據所以他們會停止他們自己的發送,從而導致拒絕服務發生。[10]

阻止隱藏網絡攻擊需要一個類似於NetEqualizer的網絡工具。[10] 這樣的工具監視着AP的流量並且會開發一個流量的基線。所有CTS/RTS信號的峰值會被假定為一個隱藏節點攻擊並且將被封鎖掉。

Deauth(去認證)攻擊 編輯

任何客戶端進入一個無線網絡前必須先獲得一個AP接入點的認證,在這之後跟這個AP相關聯。當一個客戶端離開時,他會發送一個去除認證信息去不再和AP進行關聯。攻擊者可以向綁定到客戶端IP地址的接入點發送去除認證消息,從而使用戶離線並且需要重新認證,從而讓攻擊者可以觀察到重新認證握手時候的有價值的信息。[11]

為了防禦這種攻擊,可以設置接入點延遲解除認證或者解除關聯請求(比如這樣的請求需要排隊等待5到10秒),從而給接入點機會來觀測客戶端後續發送過來的數據包。如果一個數據包在一個解除認證或者解除關聯請求被放入等待隊列之後到達,那麼該請求會被丟棄,因為合法客戶端將不會以該順序生成數據包。 [12]

參考資料 編輯

  1. ^ The TCP/IP Protocol Framework. [8 February 2013]. (原始內容存檔於2021-02-27). 
  2. ^ Data Link Layer. [8 February 2013]. (原始內容存檔於2021-02-27). 
  3. ^ CAM Table & STP Attacks (PDF). Polytechnic Institute of New York University. [8 February 2013]. (原始內容存檔 (PDF)於2010-06-13). 
  4. ^ 4.0 4.1 O'Connor, Terrence. Detecting and Responding to Data Link Layer Attacks. SANS Institute. [8 February 2013]. (原始內容存檔於2013-03-22). 
  5. ^ Akeung, Darryl. Switch Security – DHCP Starvation and Flooding CAM Tables (Fail Open) Part 1. [8 February 2013]. (原始內容存檔於2013年2月2日). 
  6. ^ Network Security at the Data Link Layer (Layer 2) of LAN. Javvin Network Management & Security. [14 February 2013]. (原始內容存檔於2013年4月11日). 
  7. ^ Gmoskov. ARP Spoofing Attack and Defense. [14 February 2013]. (原始內容存檔於2018-08-16). 
  8. ^ Dmitry, Davletbaev. Dhcpstarv - DHCP Starvation Utility. SourceForge.net. [14 February 2013]. (原始內容存檔於2021-04-14). 
  9. ^ Mitigating Layer 2 Attacks (PDF). [14 February 2013]. [永久失效連結]
  10. ^ 10.0 10.1 NetEqualizer Lite and Hidden Nodes: A Real Solution to a Virtual Problem. NetEqualizer. [14 February 2013]. (原始內容存檔於2020-08-15). 
  11. ^ Deauthentication. Aircrack-ng. [14 February 2013]. (原始內容存檔於2021-05-02). 
  12. ^ Bellado, John. Deauthentication Attack. Proceedings of the USENIX Security Symposium, Aug 2003. [14 February 2013]. (原始內容存檔於2017-12-14).