網路介面層安全

網路介面層,通常也稱為資料連結層或資料鏈路,是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).