TCP FLAG 標記基於標記的TCP包匹配經常被用於過濾試圖打開新連接的TCP數據包。 TCP標記和他們的意義如下所列
F : FIN - 結束; 結束會話
S : SYN - 同步; 表示開始會話請求
R : RST - 復位;中斷一個連接
P : PUSH - 推送; 數據包立即發送
A : ACK - 應答
U : URG - 緊急
E : ECE - 顯式擁塞提醒回應
W : CWR - 擁塞窗口減少
三次握手Three-way Handshake
一個虛擬連接的建立是通過三次握手來實現的
1. (B) --> [SYN] --> (A)
假如服務器A和客戶機B通訊. 當A要和B通信時，B首先向A發一個SYN (Synchronize) 標記的包，告訴A請求建立連接.
注意: 一個 SYN包就是僅SYN標記設為1的TCP包(參見TCP包頭Resources). 認識到這點很重要，只有當A受到B發來的SYN包，才可建立連接，除此之外別無他法。因此，如果你
的防火牆丟棄所有的發往外網接口的SYN包，那么你將不 能讓外部任何主機主動建立連接。
2. (B) <-- [SYN/ACK] <--(A)
接着，A收到后會發一個對SYN包的確認包(SYN/ACK)回去，表示對第一個SYN包的確認，並繼續握手操作.
注意: SYN/ACK包是僅SYN 和 ACK 標記為1的包.
3. (B) --> [ACK] --> (A)
B收到SYN/ACK 包,B發一個確認包(ACK)，通知A連接已建立。至此，三次握手完成，一個TCP連接完成
Note: ACK包就是僅ACK 標記設為1的TCP包. 需要注意的是當三此握手完成、連接建立以后，TCP連接的每個包都會設置ACK位
這就是為何連接跟蹤很重要的原因了. 沒有連接跟蹤,防火牆將無法判斷收到的ACK包是否屬於一個已經建立的連接.一般的包過濾(Ipchains)收到ACK包時,會讓它通過(這絕對不是
個 好主意). 而當狀態型防火牆收到此種包時，它會先在連接表中查找是否屬於哪個已建連接，否則丟棄該包
四次握手Four-way Handshake
四次握手用來關閉已建立的TCP連接
1. (B) --> ACK/FIN --> (A)
2. (B) <-- ACK <-- (A)
3. (B) <-- ACK/FIN <-- (A)
4. (B) --> ACK --> (A)
注意: 由於TCP連接是雙向連接, 因此關閉連接需要在兩個方向上做。ACK/FIN 包(ACK 和FIN 標記設為1)通常被認為是FIN(終結)包.然而, 由於連接還沒有關閉, FIN包總是打上
ACK標記. 沒有ACK標記而僅有FIN標記的包不是合法的包，並且通常被認為是惡意的
連接復位Resetting a connection
四次握手不是關閉TCP連接的唯一方法. 有時,如果主機需要盡快關閉連接(或連接超時,端口或主機不可達),RST (Reset)包將被發送. 注意在，由於RST包不是TCP連接中的必須部
分, 可以只發送RST包(即不帶ACK標記). 但在正常的TCP連接中RST包可以帶ACK確認標記
請注意RST包是可以不要收到方確認的?
無效的TCP標記Invalid TCP Flags
到目前為止，你已經看到了 SYN, ACK, FIN, 和RST 標記. 另外，還有PSH (Push) 和URG (Urgent)標記.
最常見的非法組合是SYN/FIN 包. 注意:由於 SYN包是用來初始化連接的, 它不可能和 FIN和RST標記一起出現. 這也是一個惡意攻擊.
由於現在大多數防火牆已知 SYN/FIN 包, 別的一些組合,例如SYN/FIN/PSH, SYN/FIN/RST, SYN/FIN/RST/PSH。很明顯，當網絡中出現這種包時，很你的網絡肯定受到攻了。
別的已知的非法包有FIN (無ACK標記)和"NULL"包。如同早先討論的，由於ACK/FIN包的出現是為了關閉一個TCP連接，那么正常的FIN包總是帶有 ACK 標記。"NULL"包就是沒
有任何TCP標記的包(URG,ACK,PSH,RST,SYN,FIN都為0)。
到目前為止，正常的網絡活動下，TCP協議棧不可能產生帶有上面提到的任何一種標記組合的TCP包。當你發現這些不正常的包時，肯定有人對你的網絡不懷好意。
RST攻擊
A和服務器B之間建立了TCP連接，此時C偽造了一個TCP包發給B，使B異常的斷開了與A之間的TCP連接，就是RST攻擊了。實際上從上面RST標志位的功能已經可以看出這種攻擊
如何達到效果了。
那么偽造什么樣的TCP包可以達成目的呢？我們至頂向下的看。
假定C偽裝成A發過去的包，這個包如果是RST包的話，毫無疑問，B將會丟棄與A的緩沖區上所有數據，強制關掉連接。
如果發過去的包是SYN包，那么，B會表示A已經發瘋了（與OS的實現有關），正常連接時又來建新連接，B主動向A發個RST包，並在自己這端強制關掉連接。
這兩種方式都能夠達到復位攻擊的效果。似乎挺恐怖，然而關鍵是，如何能偽造成A發給B的包呢？這里有兩個關鍵因素，源端口和序列號。
一個TCP連接都是四元組，由源IP、源端口、目標IP、目標端口唯一確定一個連接。所以，如果C要偽造A發給B的包，要在上面提到的IP頭和TCP頭，把源IP、源端口、目標IP、目
標端口都填對。這里B作為服務器，IP和端口是公開的，A是我們要下手的目標，IP當然知道，但A的源端口就不清楚了，因為這可能是A隨機生成的。當然，如果能夠對常見的OS如
windows和linux找出生成source port規律的話，還是可以搞定的。
序列號問題是與滑動窗口對應的，偽造的TCP包里需要填序列號，如果序列號的值不在A之前向B發送時B的滑動窗口內，B是會主動丟棄的。所以我們要找到能落到當時的AB間滑動
窗口的序列號。這個可以暴力解決，因為一個sequence長度是32位，取值范圍0-4294967296，如果窗口大小像上圖中我抓到的windows下的65535的話，只需要相除，就知道
最多只需要發65537（4294967296/65535=65537）個包就能有一個序列號落到滑動窗口內。RST包是很小的，IP頭＋TCP頭也才40字節，算算我們的帶寬就知道這實在只需
要幾秒鍾就能搞定。
那么，序列號不是問題，源端口會麻煩點，如果各個操作系統不能完全隨機的生成源端口，或者黑客們能通過其他方式獲取到source port，RST攻擊易如反掌，后果很嚴重。
RST攻擊的防御
對付這種攻擊也可以通過防火牆簡單設置就可以了。建議使用防火牆將進來的包帶RST位的包丟棄就可以了。