1.什么是狀態(tài)檢測
每個(gè)網(wǎng)絡(luò)連接包括以下信息：源地址、目的地址、源端口和目的端口，叫作套接字對(socket pairs)；協(xié)議類型、連接狀態(tài)(TCP協(xié)議)和超時(shí)時(shí)間等。防火墻把這些信息叫作狀態(tài)(stateful)，能夠檢測每個(gè)連接狀態(tài)的防火墻叫作狀態(tài)包過濾防火墻。它除了能夠完成簡單包過濾防火墻的包過濾工作外，還在自己的內(nèi)存中維護(hù)一個(gè)跟蹤連接狀態(tài)的表，比簡單包過濾防火墻具有更大的安全性。
iptables中的狀態(tài)檢測功能是由state選項(xiàng)來實(shí)現(xiàn)的。對這個(gè)選項(xiàng)，在iptables的手冊頁中有以下描述：
state
這個(gè)模塊能夠跟蹤分組的連接狀態(tài)(即狀態(tài)檢測)。
--state state
這里，state是一個(gè)用逗號(hào)分割的列表，表示要匹配的連接狀態(tài)。有效的狀態(tài)選項(xiàng)包括：INVAILD，表示分組對應(yīng)的連接是未知的； ESTABLISHED，表示分組對應(yīng)的連接已經(jīng)進(jìn)行了雙向的分組傳輸，也就是說連接已經(jīng)建立；NEW，表示這個(gè)分組需要發(fā)起一個(gè)連接，或者說，分組對應(yīng)的連接在兩個(gè)方向上都沒有進(jìn)行過分組傳輸；RELATED，表示分組要發(fā)起一個(gè)新的連接，但是這個(gè)連接和一個(gè)現(xiàn)有的連接有關(guān)，例如：FTP的數(shù)據(jù)傳輸連接和控制連接之間就是RELATED關(guān)系。
對于本地產(chǎn)生分組，在PREROUTING或者OUTPUT鏈中都可以對連接的狀態(tài)進(jìn)行跟蹤。在進(jìn)行狀態(tài)檢測之前，需要重組分組的分片。這就是為什么在iptables中不再使用ipchains的ip_always_defrag開關(guān)。
UDP和TCP連接的狀態(tài)表由/proc/net/ip_conntrack進(jìn)行維護(hù)。稍后我們再介紹它的內(nèi)容。
狀態(tài)表能夠保存的最大連接數(shù)保存在/proc/sys/net/ipv4/ip_conntrack_max中。它取決于硬件的物理內(nèi)存。
2.iptables的狀態(tài)檢測是如何工作的？
2.1.iptables概述
在討論iptables狀態(tài)檢測之前，我們先大體看一下整個(gè)netfilter框架。如果要在兩個(gè)網(wǎng)絡(luò)接口之間轉(zhuǎn)發(fā)一個(gè)分組，這個(gè)分組將以以下的順序接收規(guī)則鏈的檢查：
PREROUTING鏈
如果必要對這個(gè)分組進(jìn)行目的網(wǎng)絡(luò)地址轉(zhuǎn)換(DNAT)和mangle處理。同時(shí)，iptables的狀態(tài)檢測機(jī)制將重組分組，并且以以下某種方式跟蹤其狀態(tài)：
分組是否匹配狀態(tài)表中的一個(gè)已經(jīng)實(shí)現(xiàn)(ESTABLISHED)的連接。
它是否是和狀態(tài)表中某個(gè)UDP/TCP連接相關(guān)(RELATED)的一個(gè)ICMP分組。
這個(gè)分組是否要發(fā)起一個(gè)新(NEW)的連接。
如果分組和任何連接無關(guān)，就被認(rèn)為是無效(INVALID)的。
FORWARD鏈
把分組的狀態(tài)和過濾表中的規(guī)則進(jìn)行匹配，如果分組與所有的規(guī)則都無法匹配，就使用默認(rèn)的策略進(jìn)行處理。
POSTROUTING鏈
如果有必要，就對分組進(jìn)行源網(wǎng)絡(luò)地址轉(zhuǎn)換(SNAT)，
注意：所有的分組都必須和過濾表的規(guī)則進(jìn)行比較。如果你修改了規(guī)則，要拒絕所有的網(wǎng)絡(luò)流量，那么即使分組的狀態(tài)匹配狀態(tài)表中的一個(gè)ESTABLISHED條目，也將被拒絕。
下面，我們對UDP、TCP和ICMP三個(gè)協(xié)議分別進(jìn)行分析。
2.2.UDP連接
UDP(用戶數(shù)據(jù)包協(xié)議)是一種無狀態(tài)協(xié)議，以為這個(gè)協(xié)議沒有序列號(hào)。不過，這并不意味著我們不能跟蹤UDP連接。雖然沒有序列號(hào)，但是我們還可以使用其它的一些信息跟蹤UDP連接的狀態(tài)。下面是狀態(tài)表中關(guān)于UDP連接的條目：
udp 17 19 src=192.168.1.2 dst=192.168.1.50 sport=1032 dport=53 [UNREPLIED] src=192.168.1.50 dst=192.168.1.2 sport=53 dport=1032 use=1
這個(gè)狀態(tài)表項(xiàng)只有在iptables過濾規(guī)則允許建立新的連接時(shí)，才能建立。以下的規(guī)則可以產(chǎn)生這類狀態(tài)表項(xiàng)，這兩條規(guī)則只允許向外的UDP連接：
iptables -A INPUT -p udp -m state --state ESTABLISHED -j ACCEPT
iptables -A OUTPUT -P udp -m state --state NEW,ESTABLISHED -j ACCEPT
上面的狀態(tài)表項(xiàng)包含如下信息：
連接的協(xié)議是UDP(IP協(xié)議號(hào)17)。
這個(gè)狀態(tài)表項(xiàng)還有19秒中就超時(shí)。
發(fā)起連接方向上的源、目的地址和源、目的端口。
應(yīng)答方向上的源、目的地址和源、目的端口。這個(gè)連接使用UNREPLIED標(biāo)記，表示還沒有收到應(yīng)答。
UDP連接的超時(shí)時(shí)間在/usr/src/linux/net/ipv4/netfilter/ip_conntrack_proto_udp.c文件中設(shè)置，如果改變了這個(gè)值，需要重新編譯Linux內(nèi)核源代碼才能生效。下面是UDP連接超時(shí)時(shí)間的相關(guān)的源代碼：
#define UDP_TIMEOUT (30*HZ)
#define UDP_STREAM_TIMEOUT (180*HZ)
一個(gè)UDP請求等待應(yīng)答的時(shí)間是30*HZ(這個(gè)值一般是30秒)。在上面的例子中，等待的時(shí)間已經(jīng)消耗了11秒，還剩余19秒，如果在這段時(shí)間之內(nèi)沒有收到應(yīng)答分組，這個(gè)表項(xiàng)就會(huì)被刪除。一旦收到了應(yīng)答，這個(gè)值就被重置為30，UNREPLIED標(biāo)志也被刪除。這個(gè)表項(xiàng)編程如下形式：
udp 17 28 src=192.168.1.2 dst=192.168.1.50 sport=1032 dport=53 src=192.168.1.50 dst=192.168.1.2 sport=53 dport=1032 use=1
如果在這一對源、目的地址和源、目的端口上，發(fā)生了多個(gè)請求和應(yīng)答，這個(gè)表項(xiàng)就作為一個(gè)數(shù)據(jù)流表項(xiàng)，它的超時(shí)時(shí)間是180秒。這種情況下，這個(gè)表項(xiàng)就變成如下形式：
udp 17 177 src=192.168.1.2 dst=192.168.1.50 sport=1032 dport=53 src=192.168.1.50 dst=192.168.1.2 sport=53 dport=1032 [ASSURED] use=1
這時(shí)我們看到這個(gè)表項(xiàng)使用ASSURED標(biāo)志。一旦連接表項(xiàng)使用ASSURED標(biāo)志，那么即使在網(wǎng)絡(luò)負(fù)沉重的情況下，也不會(huì)被丟棄。如果狀態(tài)表已經(jīng)飽和，當(dāng)新的連接到達(dá)時(shí)，使用UNREPLIED標(biāo)志的表項(xiàng)會(huì)受被丟棄。
2.3.TCP連接
一個(gè)TCP連接是通過三次握手的方式完成的。首先，客戶程序發(fā)出一個(gè)同步請求(發(fā)出一個(gè)SYN分組)；接著，服務(wù)器端回應(yīng)一個(gè)SYN|ACK分組；最后返回一個(gè)ACK分組，連接完成。整個(gè)過程如下所示：
Client Server
SYN --->
<--- SYN+ACK
ACK --->
<--- ACK
ACK --->
.........
.........
SYN和ACK是由TCP分組頭的標(biāo)志決定的。在每個(gè)TCP分組頭還有32位的序列號(hào)和應(yīng)答號(hào)用于跟蹤會(huì)話。
為了跟蹤一個(gè)TCP連接的狀態(tài)，你需要使用下面這樣的規(guī)則：
iptables -A INPUT -p tcp -m state --state ESTABLISHED -j ACCEPT
iptables -A OUTPUT -p tcp -m state --state NEW,ESTABLISHED -j ACCEPT
2.3.1.連接建立過程中狀態(tài)表的變化
下面，我們詳細(xì)討論在連接建立的每個(gè)階段中，狀態(tài)表發(fā)生的變化：
一旦一個(gè)初始SYN分組進(jìn)入OUTPUT鏈，并且輸出規(guī)則允許這個(gè)分組建立一個(gè)新的連接，狀態(tài)表的相關(guān)表項(xiàng)將如下所示：
cp 6 119 SYN_SENT src=140.208.5.62 dst=207.46.230.218 sport=1311 dport=80 [UNREPLIED] src=207.46.230.218 dst=140.208.5.62 sport=80 dport=1311 use=1
其中，TCP連接狀態(tài)是SYN_SENT，連接被標(biāo)記為UNREPLIED。
現(xiàn)在，我們等待SYN+ACK分組的響應(yīng)。一旦得到響應(yīng)，這個(gè)TCP連接表項(xiàng)就變?yōu)椋?
tcp 6 57 SYN_RECV src=140.208.5.62 dst=207.46.230.218 sport=1311 dport=80 src=207.46.230.218 dst=140.208.5.62 sport=80 dport=1311 use=1
連接的狀態(tài)變?yōu)镾YN_RECV，UNREPLIED標(biāo)志被清除。
現(xiàn)在我們需要等待完成握手的ACK分組。ACK分組到達(dá)后，我們首先對其序列號(hào)進(jìn)行一些檢查，如果正確，就把這個(gè)連接的狀態(tài)變?yōu)镋STABLISHED，并且使用ASSURED標(biāo)記這個(gè)連接。這時(shí)，這個(gè)連接的狀態(tài)如下所示：
cp 6 431995 ESTABLISHED src=140.208.5.62 dst=207.46.230.218 sport=1311 dport=80 src=207.46.230.218 dst=140.208.5.62 sport=80 dport=1311 [ASSURED] use=1
2.3.2.透視狀態(tài)表
上面，我們涉及了很多CP連接的狀態(tài)。現(xiàn)在，我們分析一下TCP連接的狀態(tài)檢測。實(shí)際上，狀態(tài)表只知道NEW、ESTABLISHED、RELATED和INVALID。
要注意：狀態(tài)檢測的狀態(tài)不等于TCP狀態(tài)。當(dāng)一個(gè)SYN分組的響應(yīng)SYN+ACK分組到達(dá)，Netfilter的狀態(tài)檢測模塊就會(huì)認(rèn)為連接已經(jīng)建立。但是，這時(shí)還沒有完成三次握手，因此TCP連接還沒有建立。
另外，包過濾規(guī)則不能刪除狀態(tài)表中的表項(xiàng)，只有連接超時(shí)，對應(yīng)的狀態(tài)表項(xiàng)才會(huì)被刪除。ACK分組能夠建立一個(gè)NEW狀態(tài)表項(xiàng)。向防火墻之后一臺(tái)并不存在主機(jī)發(fā)送ACK分組，并不會(huì)返回RST分組，可以證明這個(gè)結(jié)論。因此，你需要使用以下的規(guī)則明確新的TCP連接應(yīng)該是SYN分組建立的：
iptables -A INPUT -p tcp !--syn -m state --state NEW -j DROP
這樣可以阻止空會(huì)話的繼續(xù)進(jìn)行。
2.3.3.超時(shí)
所謂狀態(tài)表項(xiàng)的超時(shí)值是指每個(gè)表項(xiàng)存在的最大時(shí)間，這些超時(shí)值的大小在/usr/src/linux/net/ipv4/netfilter/ip_conntrack_proto_tcp.c文件中設(shè)置。以下是相關(guān)的代碼：
static unsigned long tcp_timeouts[]
= { 30 MINS, /* TCP_CONNTRACK_NONE, */
5 DAYS, /* TCP_CONNTRACK_ESTABLISHED, */
2 MINS, /* TCP_CONNTRACK_SYN_SENT, */
60 SECS, /* TCP_CONNTRACK_SYN_RECV, */
2 MINS, /* TCP_CONNTRACK_FIN_WAIT, */
2 MINS, /* TCP_CONNTRACK_TIME_WAIT, */
10 SECS, /* TCP_CONNTRACK_CLOSE, */
60 SECS, /* TCP_CONNTRACK_CLOSE_WAIT, */
30 SECS, /* TCP_CONNTRACK_LAST_ACK, */
2 MINS, /* TCP_CONNTRACK_LISTEN, */
};
2.3.4.連接的中斷
關(guān)閉一個(gè)TCP連接可以有兩種方式。第一種類似于建立TCP連接的三次握手。一旦一個(gè)TCP會(huì)話完成，要終止會(huì)話的一方首先發(fā)出一個(gè)FIN為1的分組。接收方TCP確認(rèn)這個(gè)FIN分組，并同志自己這邊的應(yīng)用程序不要在接收數(shù)據(jù)了。這個(gè)過程可以如下所示：
Client Server
.........
.........
FIN+ACK --->
<--- ACK
<--- FIN+ACK
ACK --->
在這個(gè)過程之中或者之后，狀態(tài)表的連接狀態(tài)變?yōu)門IME_WAIT。在默認(rèn)情況下，2分鐘之后從狀態(tài)表刪除。
除此之外，還有其它關(guān)閉中斷的方式。TCP會(huì)話的任何一方發(fā)出一個(gè)RST標(biāo)志為1的分組，可以快速斷開一個(gè)TCP連接。而且，RST分組不需要應(yīng)答。在這種情況下，狀態(tài)表項(xiàng)的狀態(tài)變?yōu)镃LOSE，10秒之后被刪除。和http連接經(jīng)常通過這種方式中斷，如果一個(gè)連接很長時(shí)間沒有請求了，服務(wù)器端就會(huì)發(fā)出一個(gè) RST分組中斷連接。
2.4.ICMP
在iptables看來，只有四種ICMP分組，這些分組類型可以被歸為NEW、ESTABLISHED兩類：
ECHO請求(ping,8)和ECHO應(yīng)答(pong,0)。
時(shí)間戳請求(13)和應(yīng)答(14)。
信息請求(15)和應(yīng)答(16)。
地址掩碼請求(17)和應(yīng)答(18)。
這些ICMP分組類型中，請求分組屬于NEW，應(yīng)答分組屬于ESTABLISHED。而其它類型的ICMP分組不基于請求/應(yīng)答方式，一律被歸入RELATED。
我們先看一個(gè)簡單的例子：
iptables -A OUTPUT -p icmp -m state --state NEW,ESTABLISHED, RELATED -j ACCEPT
iptables -A INPUT -p icmp -m state --state ESTABLISHED,RELATED -j ACCEPT
這鏈條規(guī)則進(jìn)行如下的過濾：
一個(gè)ICMP echo請求是一個(gè)NEW連接。因此，允許ICMP echo請求通過OUTPUT鏈。
當(dāng)對應(yīng)的應(yīng)答返回，此時(shí)連接的狀態(tài)是ESTABLISED，因此允許通過INPUT鏈。而INPUT鏈沒有NEW狀態(tài)，因此不允許echo請求通過INPUT鏈。也就是說，這兩條規(guī)則允許內(nèi)部主機(jī)ping外部主機(jī)，而不允許外部主機(jī)ping內(nèi)部主機(jī)。
一個(gè)重定向ICMP(5)分組不是基于請求/應(yīng)答方式的，因此屬于RELATED。INPUT和OUTPUT鏈都允許RELATED狀態(tài)的連接，因此重定向(5)分組可以通過INPUT和OUTPUT鏈。
3.FTP協(xié)議的狀態(tài)檢測
上面，我們比較詳細(xì)地介紹了iptables的態(tài)檢測機(jī)制。現(xiàn)在，我們以FTP狀態(tài)檢測為例介紹如何使用iptables進(jìn)行連接狀態(tài)檢測。
首先，你需要加載ip_conntrack_ftp模塊。使用如下規(guī)則就可以允許建立FTP控制連接(這里沒有考慮IMCP問題):
iptables -A INPUT -p tcp --sport 21 -m state --state ESTABLESED -j ACCEPT
iptables -A OUTPUT -p tcp --dport 21 -m state --state NEW,ESTABLISED -j ACCEPT
除了控制連接之外，F(xiàn)TP協(xié)議還需要一個(gè)數(shù)據(jù)通道，不過，數(shù)據(jù)連接可以通過主動(dòng)和被動(dòng)兩種模式建立，我們需要分別討論。
3.1.主動(dòng)模式
在主動(dòng)模式下，客戶程序在控制通道上，使用PORT命令告訴FTP服務(wù)器自己這邊的數(shù)據(jù)傳輸端口，然后FTP從20端口向這個(gè)端口發(fā)起一個(gè)連接。連接建立后，服務(wù)器端和客戶端就可以使用這個(gè)連接傳輸數(shù)據(jù)了，例如：傳誦的文件、ls等命令的結(jié)果等。因此，在主動(dòng)模式下FTP數(shù)據(jù)傳輸通道是反向建立的，它從 FTP服務(wù)器端向客戶端發(fā)起。
在主動(dòng)模式下，客戶端使用的數(shù)據(jù)傳輸端口是不固定的，因此我們需要在規(guī)則中使用端口范圍。由于客戶端使用的端口都是大于1024的，這并不會(huì)降低系統(tǒng)的安全性。
在iptables 中，有一個(gè)專門跟蹤FTP狀態(tài)的模塊--ip_conntrack_ftp。這個(gè)模塊能夠識(shí)別出PORT命令，并從中提取端口號(hào)。這樣，F(xiàn)TP數(shù)據(jù)傳輸連接就被歸入RELATED狀態(tài)，它和向外的FTP控制連接相關(guān)，因此我們不需要在INPUT鏈中使用NEW狀態(tài)。下面的規(guī)則可以實(shí)現(xiàn)我們的意圖：
iptables -A INPUT -p tcp --sport 20 -m state --state ESTABLISED,RELATED -j ACCEPT
iptables -A OUTPUT -p tcp --dport 20 -m state --state ESTABLISED -j ACCEPT
3.2.被動(dòng)模式
和主動(dòng)模式相反，在被動(dòng)模式下，指定連接端口的PORT命令是服務(wù)器端發(fā)出的。FTP服務(wù)器通過PORT命令告訴客戶端自己使用的FTP數(shù)據(jù)傳輸端口，然后等待客戶端建立數(shù)據(jù)傳輸連接。在被動(dòng)模式下，建立數(shù)據(jù)傳輸連接的方向和建立控制連接的方向是相同的。因此，被動(dòng)模式具有比主動(dòng)模式更好的安全性。
由于ip_conntrack_ftp模塊能夠從PORT命令提取端口，因此我們在OUTPUT鏈中也不必使用NEW狀態(tài)，下面的規(guī)則可以實(shí)現(xiàn)對被動(dòng)模式下的FTP狀態(tài)檢測：
iptables -A INPUT -p tcp --sport 1024: --dport 1024: -m state --state ESTABLISHED -j ACCEPT
iptables -A OUTPUT -p tcp --sport 1024: --dport 1024: -m state --state ESTABLISHED,RELATED -j ACCEPT
綜合以上的分析，我們可以得到FTP連接的狀態(tài)檢測規(guī)則，對于主動(dòng)模式的FTP，需要下面的iptables規(guī)則：
iptables -A INPUT -p tcp --sport 21 -m state --state ESTABLESED -j ACCEPT
iptables -A OUTPUT -p tcp --dport 21 -m state --state NEW,ESTABLISED -j ACCEPT
iptables -A INPUT -p tcp --sport 20 -m state --state ESTABLISED,RELATED -j ACCEPT
iptables -A OUTPUT -p tcp --dport 20 -m state --state ESTABLISED -j ACCEPT
對于被動(dòng)模式的FTP連接，需要使用如下iptables規(guī)則
iptables -A INPUT -p tcp --sport 21 -m state --state ESTABLESED -j ACCEPT
iptables -A OUTPUT -p tcp --dport 21 -m state --state NEW,ESTABLISED -j ACCEPT
iptables -A INPUT -p tcp --sport 1024: --dport 1024: -m state --state ESTABLISHED -j ACCEPT
iptables -A OUTPUT -p tcp --sport 1024: --dport 1024: -m state --state ESTABLISHED,RELATED -j ACCEPT
本文中提到的狀態(tài)檢測，在iptables中實(shí)際叫作連接跟蹤(Connection tracking)，出于自己的習(xí)慣，我在本文中一律改為狀態(tài)檢測