pfSense 和 Snort：介面上的意外埠掃描流量
我有一個 pfSense 盒子作為我的面向公眾的路由器和狀態防火牆。
NAT 後面有 1 個 WAN 介面和幾個使用私有 IP 的 LAN 介面。
我希望在 WAN 介面上看到埠掃描或使用 Snort 的各種東西。
我不希望在 LAN 介面之一上看到此 SNORT 警報。
Attempted Information Leak PSNG_UDP_PORTSCAN SRC: 165.98.148.2 (some Nicaraguan IP) DST: 192.168.5.15 (a linux file sever on the LAN)我沒有到 192.168.5.15 的埠轉發。事實上，pfSense 盒子上的任何內容都不應該將任何內容轉發/路由/NATing/PATing 到該內部地址。
我可以理解我的內部機器是否正在與尼加拉瓜 ip 進行通信，但是 UDP 數據報究竟是如何在沒有轉發的情況下從 WAN 介面傳輸到 LAN 介面的呢？
所以這裡發生了一些事情，我認為這會造成混亂。
首先，Snort 的來源和目的地是什麼意思。雖然 Snort 確實有能力為狀態檢查（稱為流位）保留一些狀態資訊，但簽名是針對單個數據包進行處理的。這意味著源和目標不映射到客戶端和伺服器，它們直接映射到 IP 標頭中的源和目標地址欄位。這意味著導致此規則觸發的特定數據包在目標地址中具有 192.168.5.15，在源地址中具有 165.98.148.2。我們在這裡討論的是單個數據包，它與誰發起會話無關。
其次，您的 NAT 設備使用 UDP 做的事情比您想像的要多。TCP 很簡單。這是一個面向連接的協議。整個設計是你協商一個溝通會話，聊一會兒，然後說再見。整個過程非常明確，NAT 設備遵循這些標準。他們看到你的 SYN 出去並在 xlate 表中添加一個條目，然後當 FIN+ACK 返回時，xlate 條目被刪除，或者 FIN+RST 出去，或者足夠的時間過去了。
UDP，是無連接的，只是一勞永逸。整個想法是應用程序要麼實現它自己的握手和/或重傳系統，要麼它不需要它們。所以你會假設防火牆會允許你的 UDP 數據包出去，但任何響應都會被阻止。除非它沒有。您的 NAT 設備知道即使是像 UDP 這樣的無連接協議也經常具有雙向通信。因此，它將像 TCP 一樣為傳出的 UDP 流量插入 xlate 條目。規則有點不同，例如，我希望條目在不同的時間間隔內超時，並且只有在超時時才會被刪除。
第三，此警報可能是由 Snort 的 sfPortscan 預處理器觸發的。在嚴格限制的環境中，我可以看到它非常有用。否則可能會很吵。問題在於它執行的檢測類型
- 一台主機與一台主機通信並訪問多個埠的 TCP/UDP 流量
- 許多主機與一台主機通信並訪問許多埠的 TCP/UDP 流量
- TCP/UDP/ICMP 流量，其中一台主機與單個埠上的多台主機通信
很大程度上由於#3，這個警報幾乎可以被任何實際提供服務的系統觸發。出於某種原因，Windows SMB 文件伺服器似乎是誤報的最嚴重違規者。
現在事情變得有趣了。讓我們假設配置（伺服器、網路和防火牆）都很好。在這種情況下，您的文件伺服器很可能啟動了與外部 IP 的通信。然後返回通信觸發了 sfPortscan 預處理器，導致 pfSense 顯示警報。這可能是一件壞事。如果我是你，我會開始對進出你的文件伺服器和外部地址的任何內容進行數據包擷取。然後您可以開始查看數據包擷取並嘗試找出發生了什麼。