共計 5363 個字符，預計需要花費 14 分鐘才能閱讀完成。
這篇文章給大家介紹 iptables 的狀態機制如何分析，內容非常詳細，感興趣的小伙伴們可以參考借鑒，希望對大家能有所幫助。
1.6 狀態機制
狀態機制是 iptables 中較為特殊的一部分，這也是 iptables 和比較老的 ipchains 的一個比較大的區別之一，運行狀態機制（連接跟蹤）的防火墻稱作帶有狀態機制的防火墻，以下簡稱為狀態防火墻。狀態防火墻比非狀態防火墻要安全，因為它允許我們編寫更嚴密的規則。
在 iptables 上一共有四種狀態，分別被稱為 NEW、ESTABLISHED、INVALID、RELATED，這四種狀態對于 TCP、UDP、ICMP 三種協議均有效。下面，我們來分別闡述四種狀態的特性。
NEW：NEW 說明這個包是我們看到的 *** 個包。意思就是，這是 conntrack 模塊看到的某個連接的 *** 個包，它即將被匹配了。比如，我們看到一個 SYN 包，是我們所留意的連接的 *** 個包，就要匹配它。
ESTABLISHED：ESTABLISHED 已經注意到兩個方向上的數據傳輸，而且會繼續匹配這個連接的包。處于 ESTABLISHED 狀態的連接是非常容易理解的。只要發送并接到應答，連接就是 ESTABLISHED 的了。一個連接要從 NEW 變為 ESTABLISHED，只需要接到應答包即可，不管這個包是發往防火墻的，還是要由防火墻轉發的。ICMP 的錯誤和重定向等信息包也被看作是 ESTABLISHED，只要它們是我們所發出的信息的應答。
RELATED：RELATED 是個比較麻煩的狀態。當一個連接和某個已處于 ESTABLISHED 狀態的連接有關系時，就被認為是 RELATED 的了。換句話說，一個連接要想是 RELATED 的，首先要有一個 ESTABLISHED 的連接。這個 ESTABLISHED 連接再產生一個主連接之外的連接，這個新的連接就是 RELATED 的了，當然前提是 conntrack 模塊要能理解 RELATED。ftp 是個很好的例子，FTP-data 連接就是和 FTP-control 有關聯的，如果沒有在 iptables 的策略中配置 RELATED 狀態，FTP-data 的連接是無法正確建立的，還有其他的例子，比如，通過 IRC 的 DCC 連接。有了這個狀態，ICMP 應答、FTP 傳輸、DCC 等才能穿過防火墻正常工作。注意，大部分還有一些 UDP 協議都依賴這個機制。這些協議是很復雜的，它們把連接信息放在數據包里，并且要求這些信息能被正確理解。
INVALID：INVALID 說明數據包不能被識別屬于哪個連接或沒有任何狀態。有幾個原因可以產生這種情況，比如，內存溢出，收到不知屬于哪個連接的 ICMP 錯誤信息。一般地，我們 DROP 這個狀態的任何東西，因為防火墻認為這是不安全的東西。
每個狀態相對于不同的第四層協議來講，稍微有些區別，對于 TCP 協議來說，當防火墻收到 *** 個數據包，也就是 SYN 報文時，將該會話標記為 NEW 狀態，在系統的 /proc/net/ 目錄下，可以查閱文件 ip_conntrack，這是在內存空間里存放防火墻當前狀態表的臨時文件，對于 NEW 狀態的記錄如下：
tcp 6 117 SYN_SENT src=192.168.1.5 dst=192.168.1.35 sport=1031 dport=23 [UNREPLIED] src=192.168.1.35 dst=192.168.1.5 sport=23 dport=1031 use=1從上面的記錄可以看出，SYN_SENT 狀態被設置了，這說明連接已經發出一個 SYN 包，但應答還沒發送過來，這可從 [UNREPLIED] 標志看出，當服務器端回應了 SYN/ACK 包后，狀態表改寫為：
tcp 6 57 SYN_RECV src=192.168.1.5 dst=192.168.1.35 sport=1031 dport=23 src=192.168.1.35 dst=192.168.1.5 sport=23 dport=1031 use=1現在我們已經收到了相應的 SYN/ACK 包，狀態也變為 SYN_RECV，這說明最初發出的 SYN 包已正確傳輸，并且 SYN/ACK 包也到達了防火墻。這就意味著在連接的兩方都有數據傳輸，因此可以認為兩個方向都有相應的回應。
接下來，TCP 三次握手的隨后一個報文 ACK 包也到達了防火墻，防火墻上的狀態表變成了：
tcp 6 431999 ESTABLISHED src=192.168.1.5 dst=192.168.1.35 sport=1031 dport=23 src=192.168.1.35 dst=192.168.1.5 sport=23 dport=1031 use=1現在，我們來看看 UDP 協議的狀態描述方法，從協議本身的特性來看，UDP 連接是無狀態的，因為它沒有任何的連接建立和關閉過程。以某個順序收到的兩個數據包是無法確定它們的發出順序的。但內核仍然可以對 UDP 連接設置狀態。我們來看看是如何跟蹤 UDP 連接的，以及在核心目錄 /proc/net/ip_conntrack 的相關記錄。
當 *** 個 UDP 的數據包到達防火墻后，防火墻在他的狀態表中留下了這樣的記錄：
udp 17 20 src=192.168.1.2 dst=192.168.1.5 sport=137 dport=1025 [UNREPLIED] src=192.168.1.5 dst=192.168.1.2 sport=1025 dport=137 use=1UNREPLIED 代表這是一個狀態為 NEW 的數據包，當這條連接的回應數據包到達防火墻后，防火墻立即將修改這條狀態記錄：
udp 17 160 src=192.168.1.2 dst=192.168.1.5 sport=137 dport=1025 src=192.168.1.5 dst=192.168.1.2 sport=1025 dport=137 use=1在這條新的狀態記錄中，UNREPLIED 被刪除了，這代表現在防火墻已經建立了一條 UDP 協議的會話，但這里并沒有象 TCP 協議那樣顯示 ESTABLISHED 標記，這是 TCP 的狀態記錄和 UDP 的狀態記錄稍微不同的一個地方，當然，還有一個地方需要注意，在測試中，還需要有一些數據包經過，防火墻才會將狀態記錄改寫成：
udp 17 179 src=192.168.1.2 dst=192.168.1.5 sport=137 dport=1025 src=192.168.1.5 dst=192.168.1.2 sport=1025 dport=137 [ASSURED] use=1ASSURED 狀態表示當前有數據在進行傳輸，表面當前連接的狀態是 ACTIVE 的。如果，在這個狀態下數據停止了傳輸，則這條記錄會有一個計時器，也就是記錄中的第三個字段，上面這條記錄的第三個字段是 179，代表當前的 ASSURED 狀態還能夠保持 179 秒，如果還有新的數據包經過，那么計時器會被重新設置成缺省的 180 秒，如果在 180 秒內都沒有流量，那么這條狀態記錄就會從狀態表中被刪除。
***，我們在來看看 Linux kernel 是如何標示 ICMP 協議的狀態的，ICMP 也是一種無狀態協議，它只是用來控制而不是建立連接。ICMP 包有很多類型，但只有四種類型有應答包，它們是回顯請求和應答（Echo request and reply），時間戳請求和應答（Timestamp request and reply），信息請求和應答（Information request and reply），還有地址掩碼請求和應答（Address mask request and reply），這些包有兩種狀態，NEW 和 ESTABLISHED。時間戳請求和信息請求已經廢除不用了，回顯請求還是常用的，比如 ping 命令就用的到，地址掩碼請求不太常用，但是可能有時很有用并且值得使用。看看下面的圖，就可以大致了解 ICMP 連接的 NEW 和 ESTABLISHED 狀態了。
如圖所示，主機向目標發送一個回顯請求，防火墻就認為這個包處于 NEW 狀態。目標回應一個回顯應答，防火墻就認為包處于 ESTABLISHED 了。當回顯請求被發送時，ip_conntrack 里就有這樣的記錄了：
icmp 1 25 src=192.168.1.6 dst=192.168.1.10 type=8 code=0 id=33029 [UNREPLIED] src=192.168.1.10 dst=192.168.1.6 type=0 code=0 id=33029 use=1可以看到，ICMP 的記錄和 TCP、UDP 的有點區別，協議名稱、超時時間和源、目地址都一樣，不同之處在于沒有了端口，而新增了三個新的字段：type，code 和 id。字段 type 說明 ICMP 的類型。code 說明 ICMP 的代碼，這些代碼在附錄 ICMP 類型里有說明。id 是 ICMP 包的 ID。每個 ICMP 包被發送時都被分配一個 ID，接受方把同樣的 ID 分配給應答包，這樣發送方能認出是哪個請求的應答。
[UNREPLIED] 的含義和前面一樣，說明數的傳輸只發生在一個方向上，也就是說未收到應答。再往后，是應答包的源、目地址，還有相應的三個新字段，要注意的是 type 和 code 是隨著應答包的不同而變化的，id 和請求包的一樣。和前面一樣，應答包被認為是 ESTABLISHED 的。然而，在應答包之后，這個 ICMP 連接就不再有數據傳輸了。所以，一旦應答包穿過防火墻，ICMP 的連接跟蹤記錄就被銷毀了。因此，要想在 /proc/ip_conntrack 文件中抓到 ICMP 協議的狀態記錄實在不是一件容易的事。您可以用如下的命令來嘗試獲取這些記錄：
#cat /proc/net/ip_conntrack | grep icmp如果沒有輸出，那么就不停的重復這個命令，直到發現 icmp 的記錄為止。
以上各種情況，請求被認為 NEW，應答是 ESTABLISHED。換句話說，就是當防火墻看到一個請求包時，就認為連接處于 NEW 狀態，當有應答時，就是 ESTABLISHED 狀態。
—————————
state 匹配：state 匹配在防火墻配置過程中非常重要的，如果沒有 state 的配置，那么需要配置雙向的規則才能滿足通訊的需要，但防火墻既然有狀態檢測功能，我們為什么不好好使用它呢？
–state：state 的狀態有四種，指定要匹配包的的狀態，當前有 4 種狀態可用：INVALID，ESTABLISHED，NEW 和 RELATED。四種數據包的狀態我們在前面已經做了詳細的描述本節我們只進行 state 的用法描述，如下例所示：
#iptables ndash;A FORWARD ndash;p tcp ndash;m state --state RELATED,ESTABLISHED ndash;j ACCEPT本例表明凡是數據包狀態為“RELATED”、“ESTABLISHED”的 tcp 包允許通過防火墻。在一般情況下，基于狀態的策略都是配置在每一條 chain 的最前面，因為當包被匹配到以后，就能夠直接被處理了，這是一種比較高效的配置方法。關鍵字 ESTABLISHED 比較容易理解，即匹配狀態為“已經建立連接”的數據包，那么怎么理解“RELATED”呢，RELATED 表示不屬于已經建立的那條連接，但和那條連接有關，比如 ftp，ftp 在建立連接的過程中會首先建立一條 ftp-control 連接用以傳輸指令等，真正傳輸數據的是一條叫做 ftp-data 的連接，而傳輸數據的連接是和傳輸控制信號的連接相關的，因此“RELATED”是用于類似這些特殊服務的。在正常情況下，對于每一種協議：TCP、UDP、ICMP 都可以單獨的配置狀態策略，但一種比較簡單高效的做法是：
#iptables ndash;A INPUT ndash;p all ndash;m state --state RELATED,ESTABLISHED ndash;j ACCEPTmultiport: 這個匹配選項為我們解決了如何在一條策略種匹配那些端口不連續的服務，在一般情況下，一個公司或企業的安全策略是允許內部網絡使用有限的 Internet 服務，如收發電子郵件、上網瀏覽網頁、msn 聊天等，看看下面的例子：
#iptables ndash;A FORWARD ndash;i eth0 ndash;p tcp ndash;m multiport --dports 25,80,110,443,1863 ndash;j ACCEPT
#iptables ndash;A FORWARD ndash;i eth0 ndash;p udp --dport 53 ndash;j ACCEPT僅僅兩條命令就解決了內部用戶上網收發 E_mail、瀏覽網頁、使用 msn 聊天等需求，怎么樣，就這么簡單~
關于 iptables 的狀態機制如何分析就分享到這里了，希望以上內容可以對大家有一定的幫助，可以學到更多知識。如果覺得文章不錯，可以把它分享出去讓更多的人看到。
