拖延了兩個月的總結(jié)！下面的很大一部分來自其它博客。

wireshark過濾器的區(qū)別

捕捉過濾器（CaptureFilters）：用于決定將什么樣的信息記錄在捕捉結(jié)果中。需要在開始捕捉前設(shè)置。在Capture -> Capture Filters 中設(shè)置
顯示過濾器（DisplayFilters）：在捕捉結(jié)果中進行詳細查找。他們可以在得到捕捉結(jié)果后隨意修改。

?

兩種過濾器的目的是不同的。

捕捉過濾器是數(shù)據(jù)經(jīng)過的第一層過濾器，它用于控制捕捉數(shù)據(jù)的數(shù)量，以避免產(chǎn)生過大的日志文件。顯示過濾器是一種更為強大（復(fù)雜）的過濾器。它允許您在日志文件中迅速準確地找到所需要的記錄。

?

兩種過濾器使用的語法是完全不同的。

捕捉過濾器
Protocol（協(xié)議）:
可能的值:ether, fddi, ip, arp, rarp, decnet, lat, sca, moprc, mopdl, tcp and udp
如果沒有特別指明是什么協(xié)議，則默認使用所有支持的協(xié)議。

Direction（方向）:
可能的值: src, dst, src and dst, src or dst
如果沒有特別指明來源或目的地，則默認使用 "src or dst" 作為關(guān)鍵字。
例如，"host 10.2.2.2"與"src or dst host 10.2.2.2"是一樣的。

Host(s):
可能的值:net, port, host, portrange.
如果沒有指定此值，則默認使用”host”關(guān)鍵字。
例如，"src 10.1.1.1"與"src host 10.1.1.1"相同。

Logical Operations（邏輯運算）:
可能的值：not, and, or.
否(“not”)具有最高的優(yōu)先級。或(“or”)和與(“and”)具有相同的優(yōu)先級，運算時從左至右進行。
例如，
"not tcp port 3128 and tcp port 23″與”(not tcp port 3128) and tcp port 23"相同。
"not tcp port 3128 and tcp port 23″與”not (tcp port 3128 and tcp port 23)"不同。

例子：

tcp dst port 3128
//捕捉目的TCP端口為3128的封包。
ip src host 10.1.1.1
//捕捉來源IP地址為10.1.1.1的封包。
host 10.1.2.3
//捕捉目的或來源IP地址為10.1.2.3的封包。
ether host e0-05-c5-44-b1-3c
//捕捉目的或來源MAC地址為e0的封包。如果你想抓本機與所有外網(wǎng)通訊的數(shù)據(jù)包時，可以將這里的mac地址換成路由的mac地址即可。
src portrange 2000-2500
//捕捉來源為UDP或TCP，并且端口號在2000至2500范圍內(nèi)的封包。
not imcp
//顯示除了icmp以外的所有封包。（icmp通常被ping工具使用）
src host 10.7.2.12 and not dst net 10.200.0.0/16
//顯示來源IP地址為10.7.2.12，但目的地不是10.200.0.0/16的封包。
(src host 10.4.1.12 or src net 10.6.0.0/16) and tcp dst portrange 200-10000 and dst net 10.0.0.0/8
//捕捉來源IP為10.4.1.12或者來源網(wǎng)絡(luò)為10.6.0.0/16，目的地TCP端口號在200至10000之間，并且目的位于網(wǎng)絡(luò) 10.0.0.0/8內(nèi)的所有封包。
src net 192.168.0.0/24
src net 192.168.0.0 mask 255.255.255.0
//捕捉源地址為192.168.0.0網(wǎng)絡(luò)內(nèi)的所有封包。

注意事項：

當(dāng)使用關(guān)鍵字作為值時，需使用反斜杠"/"。
"ether proto /ip" (與關(guān)鍵字"ip"相同).
這樣寫將會以IP協(xié)議作為目標。

"ip proto /icmp" (與關(guān)鍵字"icmp"相同).
這樣寫將會以ping工具常用的icmp作為目標。

可以在"ip"或"ether"后面使用"multicast"及"broadcast"關(guān)鍵字。
當(dāng)您想排除廣播請求時，"no broadcast"就會非常有用。

Protocol（協(xié)議）:
您可以使用大量位于OSI模型第2至7層的協(xié)議。點擊"Expression…"按鈕后，您可以看到它們。
比如：IP，TCP，DNS，SSH

String1, String2 (可選項):

協(xié)議的子類。
點擊相關(guān)父類旁的"+"號，然后選擇其子類。

Comparison operators （比較運算符）:
可以使用6種比較運算符：

Logical e-xpressions（邏輯運算符）:

顯示過濾器

例子：
1. 協(xié)議過濾
snmp || dns || icmp //顯示SNMP或DNS或ICMP封包。
2. IP 過濾
ip.addr == 10.1.1.1 //顯示來源或目的IP地址為10.1.1.1的封包。
ip.src != 10.1.2.3 or ip.dst != 10.4.5.6 //顯示來源不為10.1.2.3或者目的不為10.4.5.6的封包。
換句話說，顯示的封包將會為：
來源IP：除了10.1.2.3以外任意；目的IP：任意
以及
來源IP：任意；目的IP：除了10.4.5.6以外任意
ip.src != 10.1.2.3 and ip.dst != 10.4.5.6 //顯示來源不為10.1.2.3并且目的IP不為10.4.5.6的封包。
換句話說，顯示的封包將會為：
來源IP：除了10.1.2.3以外任意；同時須滿足，目的IP：除了10.4.5.6以外任意
3. 端口過濾
tcp.port == 25 //顯示來源或目的TCP端口號為25的封包。
tcp.dstport == 25 //顯示目的TCP端口號為25的封包。
tcp.flags //顯示包含TCP標志的封包。
tcp.flags.syn == 0×02 //顯示包含TCP SYN標志的封包。
4. Http模式過濾
http.request.method=="GET", 只顯示HTTP GET方法的。
5. 邏輯運算符為 AND/ OR
常用的過濾表達式
過濾表達式 用途
http 只查看HTTP協(xié)議的記錄
ip.src ==192.168.1.102 or ip.dst==192.168.1.102 源地址或者目標地址是192.168.1.102

如果過濾器的語法是正確的，表達式的背景呈綠色。如果呈紅色，說明表達式有誤。
更為詳細的說明請見：http://openmaniak.com/cn/wireshark_filters.php

以上只是抓包和簡單的過濾，那么其實如果你要想達到能夠分析這些網(wǎng)絡(luò)包的要求時，還需要了解下一些數(shù)據(jù)包的標記，比如我們常說的TCP三次握手是怎么回事？

三次握手Three-way Handshake
一個虛擬連接的建立是通過三次握手來實現(xiàn)的
1. (Client) –> [SYN] –> (Server)
假如Client和Server通訊. 當(dāng)Client要和Server通信時，Client首先向Server發(fā)一個SYN (Synchronize) 標記的包，告訴Server請求建立連接.
注意: 一個 SYN包就是僅SYN標記設(shè)為1的TCP包(參見TCP包頭Resources). 認識到這點很重要，只有當(dāng)Server收到Client發(fā)來的SYN包，才可建立連接，除此之外別無他法。因此，如果你的防火墻丟棄所有的發(fā)往外網(wǎng)接口的SYN包，那么你將不 能讓外部任何主機主動建立連接。

2. (Client) <– [SYN/ACK] <–(Server)
接著，Server收到來自Client發(fā)來的SYN包后，會發(fā)一個對SYN包的確認包(SYN/ACK)給Client，表示對第一個SYN包的確認，并繼續(xù)握手操作.
注意: SYN/ACK包是僅SYN 和 ACK 標記為1的包.

3. (Client) –> [ACK] –> (Server)
Client收到來自Server的SYN/ACK 包,Client會再向Server發(fā)一個確認包(ACK)，通知Server連接已建立。至此，三次握手完成，一個TCP連接完成。
Note: ACK包就是僅ACK 標記設(shè)為1的TCP包. 需要注意的是當(dāng)三此握手完成、連接建立以后，TCP連接的每個包都會設(shè)置ACK位。

這就是為何連接跟蹤很重要的原因了. 沒有連接跟蹤,防火墻將無法判斷收到的ACK包是否屬于一個已經(jīng)建立的連接.一般的包過濾(Ipchains)收到ACK包時,會讓它通過(這絕對不是個 好主意). 而當(dāng)狀態(tài)型防火墻收到此種包時，它會先在連接表中查找是否屬于哪個已建連接，否則丟棄該包。

四次握手Four-way Handshake
四次握手用來關(guān)閉已建立的TCP連接

1. (Client) –> ACK/FIN –> (Server)
2. (Client) <– ACK <– (Server)
3. (Client) <– ACK/FIN <– (Server)
4. (Client) –> ACK –> (Server)

注意: 由于TCP連接是雙向連接, 因此關(guān)閉連接需要在兩個方向上做。ACK/FIN 包(ACK 和FIN 標記設(shè)為1)通常被認為是FIN(終結(jié))包.然而, 由于連接還沒有關(guān)閉, FIN包總是打上ACK標記. 沒有ACK標記而僅有FIN標記的包不是合法的包，并且通常被認為是惡意的。

連接復(fù)位Resetting a connection

四次握手不是關(guān)閉TCP連接的唯一方法. 有時,如果主機需要盡快關(guān)閉連接(或連接超時,端口或主機不可達),RST (Reset)包將被發(fā)送. 注意在，由于RST包不是TCP連接中的必須部分, 可以只發(fā)送RST包(即不帶ACK標記). 但在正常的TCP連接中RST包可以帶ACK確認標記

請注意RST包是可以不要收到方確認的?

無效的TCP標記Invalid TCP Flags

到目前為止，你已經(jīng)看到了 SYN, ACK, FIN, 和RST 標記. 另外，還有PSH (Push) 和URG (Urgent)標記.

最常見的非法組合是SYN/FIN 包. 注意:由于 SYN包是用來初始化連接的, 它不可能和 FIN和RST標記一起出現(xiàn). 這也是一個惡意攻擊.

由于現(xiàn)在大多數(shù)防火墻已知 SYN/FIN 包, 別的一些組合,例如SYN/FIN/PSH, SYN/FIN/RST, SYN/FIN/RST/PSH。很明顯，當(dāng)網(wǎng)絡(luò)中出現(xiàn)這種包時，很你的網(wǎng)絡(luò)肯定受到攻擊了。

別的已知的非法包有FIN (無ACK標記)和”NULL”包。如同早先討論的，由于ACK/FIN包的出現(xiàn)是為了關(guān)閉一個TCP連接，那么正常的FIN包總是帶有 ACK 標記。”NULL”包就是沒有任何TCP標記的包(URG,ACK,PSH,RST,SYN,FIN都為0)。

到目前為止，正常的網(wǎng)絡(luò)活動下，TCP協(xié)議棧不可能產(chǎn)生帶有上面提到的任何一種標記組合的TCP包。當(dāng)你發(fā)現(xiàn)這些不正常的包時，肯定有人對你的網(wǎng)絡(luò)不懷好意。

UDP (用戶數(shù)據(jù)包協(xié)議User Datagram Protocol)

TCP是面向連接的，而UDP是非連接的協(xié)議。UDP沒有對接受進行確認的標記和確認機制。對丟包的處理是在應(yīng)用層來完成的。(or accidental arrival).

此處需要重點注意的事情是：在正常情況下，當(dāng)UDP包到達一個關(guān)閉的端口時，會返回一個UDP復(fù)位包。由于UDP是非面向連接的, 因此沒有任何確認信息來確認包是否正確到達目的地。因此如果你的防火墻丟棄UDP包，它會開放所有的UDP端口(?)。

由于Internet上正常情況下一些包將被丟棄，甚至某些發(fā)往已關(guān)閉端口(非防火墻的)的UDP包將不會到達目的，它們將返回一個復(fù)位UDP包。

因為這個原因，UDP端口掃描總是不精確、不可靠的。

看起來大UDP包的碎片是常見的DOS (Denial of Service)攻擊的常見形式 (這里有個DOS攻擊的例子，http://grc.com/dos/grcdos.htm ).

ICMP (網(wǎng)間控制消息協(xié)議Internet Control Message Protocol)

如同名字一樣， ICMP用來在主機/路由器之間傳遞控制信息的協(xié)議。 ICMP包可以包含診斷信息(ping, traceroute - 注意目前unix系統(tǒng)中的traceroute用UDP包而不是ICMP)，錯誤信息(網(wǎng)絡(luò)/主機/端口 不可達 network/host/port unreachable), 信息(時間戳timestamp, 地址掩碼address mask request, etc.)，或控制信息 (source quench, redirect, etc.) 。

你可以在http://www.iana.org/assignments/icmp-parameters 中找到ICMP包的類型。

盡管ICMP通常是無害的，還是有些類型的ICMP信息需要丟棄。

Redirect (5), Alternate Host Address (6), Router Advertisement (9) 能用來轉(zhuǎn)發(fā)通訊。

Echo (8), Timestamp (13) and Address Mask Request (17) 能用來分別判斷主機是否起來，本地時間 和地址掩碼。注意它們是和返回的信息類別有關(guān)的。 它們自己本身是不能被利用的，但它們泄露出的信息對攻擊者是有用的。

ICMP消息有時也被用來作為DOS攻擊的一部分(例如：洪水ping flood ping,死 ping ?呵呵，有趣 ping of death)?/p>

包碎片注意A Note About Packet Fragmentation

如果一個包的大小超過了TCP的最大段長度MSS (Maximum Segment Size) 或MTU (Maximum Transmission Unit)，能夠把此包發(fā)往目的的唯一方法是把此包分片。由于包分片是正常的，它可以被利用來做惡意的攻擊。

因為分片的包的第一個分片包含一個包頭，若沒有包分片的重組功能，包過濾器不可能檢測附加的包分片。典型的攻擊Typical attacks involve in overlapping the packet data in which packet header is 典型的攻擊Typical attacks involve in overlapping the packet data in which packet header isnormal until is it overwritten with different destination IP (or port) thereby bypassing firewall rules。包分片能作為 DOS 攻擊的一部分，它可以crash older IP stacks 或漲死CPU連接能力。

Netfilter/Iptables中的連接跟蹤代碼能自動做分片重組。它仍有弱點，可能受到飽和連接攻擊，可以把CPU資源耗光。

OK，到此為止，關(guān)于Wireshark抓包工具的一些小教程已經(jīng)寫完了，而導(dǎo)致我想寫這么一個糾結(jié)的教程的原因是，前幾天通過這個抓包解決了夢幻西游在網(wǎng)維大師無盤上容易掉線的問題，當(dāng)時捕捉到夢幻西游掉線時的數(shù)據(jù)包是這樣的。
注意下圖中的紅色數(shù)據(jù)，123.58.184.241是夢幻西游的服務(wù)器，而192.168.1.41是玩夢幻西游的客戶機，在掉線時，發(fā)現(xiàn)是先有夢幻西游的服務(wù)器向客戶機發(fā)送一個[FIN,ACK]數(shù)據(jù)包，根據(jù)上面的解釋，F(xiàn)IN標記的數(shù)據(jù)包是代表要斷開連接的意思，而接著客戶機又回給服務(wù)器一個確認斷開鏈接包。當(dāng)看到這個抓包數(shù)據(jù)時，就意識到，大家說的在網(wǎng)維大師系統(tǒng)虛擬盤上夢幻愛掉線的問題，并非普通的網(wǎng)絡(luò)問題，因為通過數(shù)據(jù)包的信息來看，是夢幻服務(wù)器主動要求斷開鏈接，產(chǎn)生這個情況無非是以下幾個原因：
1、服務(wù)器發(fā)現(xiàn)客戶端非法，比如有外掛什么的，踢掉了客戶機；
2、服務(wù)器壓力大，踢掉了客戶機；
3、總之不是客戶端問題導(dǎo)致的掉線；

那么既然結(jié)論是如此，為什么會有在網(wǎng)維大師系統(tǒng)虛擬盤上容易出現(xiàn)夢幻掉線問題呢？原因是由于網(wǎng)維大師系統(tǒng)虛擬盤是模擬真實硬盤方式來實現(xiàn)的，而在模擬過程中，將硬盤的序列號設(shè)置為固定過的OSDIY888了，而夢幻西游剛好后識別客戶機硬盤信息，發(fā)現(xiàn)大量客戶端的硬盤序列號都是一樣的，就認為是作弊或者使用掛機外掛了，結(jié)果就導(dǎo)致隨機被服務(wù)器踢下線的情況發(fā)生，后來我們將硬盤序列號設(shè)置為空，則沒再出現(xiàn)該問題。這個問題在未來的新版本中會解決掉。

其它的一些介紹
網(wǎng)絡(luò)層名詞解析：view->name resolve->network layer
如果為官網(wǎng)的便攜版，要用管理員角色
捕獲界面有個Filter標簽，那個其實是一個Display Filter按鈕

?

引用

說得很詳細的一篇文章
http://www.cnblogs.com/TankXiao/archive/2012/10/10/2711777.html
Wireshark抓包工具使用教程以及常用抓包規(guī)則
http://fangxin.blog.51cto.com/1125131/735178
如果看了這個你還是不會用Wireshark，那就來找我吧
https://community.emc.com/thread/194901

過濾器實例
http://3layer.blog.51cto.com/57448/964580
http://missuniverse110.blog.51cto.com/784017/738884

替代軟件ntop/cacti
http://dl528888.blog.51cto.com/2382721/851461
微軟的sniffer

?

wireshark總結(jié)