iptables的狀態機制如何分析

這篇文章給大家介紹iptables的狀態機制如何分析，內容非常詳細，感興趣的小伙伴們可以參考借鑒，希望對大家能有所幫助。

1.6 狀態機制

狀態機制是iptables中較為特殊的一部分，這也是iptables和比較老的ipchains的一個比較大的區別之一，運行狀態機制（連接跟蹤）的防火墻稱作帶有狀態機制的防火墻，以下簡稱為狀態防火墻。狀態防火墻比非狀態防火墻要安全，因為它允許我們編寫更嚴密的規則。

在iptables上一共有四種狀態，分別被稱為NEW、ESTABLISHED、INVALID、RELATED，這四種狀態對于TCP、UDP、ICMP三種協議均有效。下面，我們來分別闡述四種狀態的特性。

1. NEW：NEW說明這個包是我們看到的***個包。意思就是，這是conntrack模塊看到的某個連接的***個包，它即將被匹配了。比如，我們看到一個SYN 包，是我們所留意的連接的***個包，就要匹配它。

2. ESTABLISHED： ESTABLISHED已經注意到兩個方向上的數據傳輸，而且會繼續匹配這個連接的包。處于ESTABLISHED狀態的連接是非常容易理解的。只要發送并接到應答，連接就是ESTABLISHED的了。一個連接要從NEW變為ESTABLISHED，只需要接到應答包即可，不管這個包是發往防火墻的，還是要由防火墻轉發的。ICMP的錯誤和重定向等信息包也被看作是ESTABLISHED，只要它們是我們所發出的信息的應答。

3. 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協議都依賴這個機制。這些協議是很復雜的，它們把連接信息放在數據包里，并且要求這些信息能被正確理解。

4. 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=1

UNREPLIED代表這是一個狀態為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=1

ASSURED狀態表示當前有數據在進行傳輸，表面當前連接的狀態是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 –A FORWARD –p tcp –m state --state RELATED,ESTABLISHED –j ACCEPT

本例表明凡是數據包狀態為“RELATED”、“ESTABLISHED”的tcp包允許通過防火墻。在一般情況下，基于狀態的策略都是配置在每一條 chain的最前面，因為當包被匹配到以后，就能夠直接被處理了，這是一種比較高效的配置方法。關鍵字ESTABLISHED比較容易理解，即匹配狀態為 “已經建立連接”的數據包，那么怎么理解“RELATED”呢，RELATED表示不屬于已經建立的那條連接，但和那條連接有關，比如ftp，ftp在建立連接的過程中會首先建立一條ftp-control連接用以傳輸指令等，真正傳輸數據的是一條叫做ftp-data的連接，而傳輸數據的連接是和傳輸控制信號的連接相關的，因此“RELATED”是用于類似這些特殊服務的。在正常情況下，對于每一種協議：TCP、UDP、ICMP都可以單獨的配置狀態策略，但一種比較簡單高效的做法是：

#iptables –A INPUT –p all –m state --state RELATED,ESTABLISHED –j ACCEPT

multiport:這個匹配選項為我們解決了如何在一條策略種匹配那些端口不連續的服務，在一般情況下，一個公司或企業的安全策略是允許內部網絡使用有限的Internet服務，如收發電子郵件、上網瀏覽網頁、msn聊天等，看看下面的例子：

#iptables –A FORWARD –i eth0 –p tcp –m multiport --dports 25,80,110,443,1863 –j ACCEPT
#iptables –A FORWARD –i eth0 –p udp --dport 53 –j ACCEPT

僅僅兩條命令就解決了內部用戶上網收發E_mail、瀏覽網頁、使用msn聊天等需求，怎么樣，就這么簡單~

關于iptables的狀態機制如何分析就分享到這里了，希望以上內容可以對大家有一定的幫助，可以學到更多知識。如果覺得文章不錯，可以把它分享出去讓更多的人看到。