Skip to main content

NFQUEUE drop UDP packets

Introduction

此篇文章用來記錄最近遇到的一個問題,在一個執行 NFQUEUE 的系統上,當一個尚未被 conntrack 紀錄的連續 UDP 封包經過系統且都經過 NFQUEUE 處理後,第二個 UDP 封包都會遺失的問題。

NFQUEUE

  • 一種 Queue,由 netfilter (ipables) 所提供的一種 target,能夠將封包內容藉由 netlink/nmap 送到 user-space 去,大部分的 IPS/IDS 都會藉由此方式來分析封包,如 suricata。
  • User space 有對應的 library 可以用來接收此封包,參考此link
  • 相關的 tutorial 可參考

系統資訊

  • Linux kernel 3.6

Problem

  • 系統在 filter chain 的 forward table 中加入一條 iptables 將封包導向 NFQUEUE。
  • User space 可參考此project,使用一個最簡易的 sample,將封包收到後就送回 kernel
  • 系統運行 NAT
  • 當有連續 UDP 封包經由系統往外送出時,可觀察到第二個 UDP (可能更多)都會遺失
    • 此連續 UDP 封包必須還沒有被 kernel 的 conntrack 給紀錄
  • 若系統沒有運行 NFQUEU ,則此問題不存在

問題觀察

#若沒有運行 NFQUEUE,為什麼封包正常

  • 請參考此流程圖

  • 第一個封包進入到系統時,於1處時,會判斷該封包是第一次建立 connection,所以是 unconfirm 的狀態,於3的狀態時,會去將該 connection 給 confirm,並且將該資訊給存入 kernel 的 hash 之中。

  • 第二個封包進入時,於1處時去判斷,就會知道該 connection 已經建立了,所以就不會進入到3,後續封包都按照此流程傳送。

#若運行 NFQUEUE,為什麼封包會丟棄

  • 請參考此流程圖

  • 第一個封包進入到系統時,於1處時,會判斷該封包是第一次建立 connection,所以是 unconfirm 的狀態,接下來就透過 netlink 要送到 user space 去。

  • 第二個封包進入到系統時,由於第一個封包還沒有被 kernel 內的 nf_conntrack_confirm 處理完畢(可能封包還在 user space),所以於1處時,也會判斷封包是第一次建立 connection,是 unconfirm 的狀態。

  • 當 user space 將封包打回 kernel 後,會於3/4開始處理,會從先前的 queue 將 skb 所記錄 conntrack 的資訊給取出,所以這兩個封包都會認為自己是 unconfirm 的狀態

  • 第一個封包接下來會走完全部的路途,並且送出去

  • 第二個封包當走到 nf_conntrack_confirm 時,會因為覺得自己是 unconfirm 的,所以呼叫 __nf_conntrack_confirm 去處理。 code: ref

  • 當第二個封包跑到 __nf_conntrack_confirm 時,會嘗試將自己的 conntrack 給加入到 kernel hash中,但是第一個封包已經加入過了,所以 kernel 會覺得你有病,就將該封包給丟棄了。

#結論

  • 此問題發生的根本在於 conntrack 的衝突,當 conntrack 的結果已經被 kernel 紀錄的情況下,有第二個封包嘗試將 conntrack 再次存到 kernel 中,此封包就會被丟棄 code: ref
  • 看過 linux 4.4 的程式碼,在 netlink 接收也沒有針對收到的封包去重新處理 conntrack 的問題,我想是 UDP 掉封包是合理的,而 TCP 會自己重傳,所以上層的應用程式不會有感覺。