キャプチャツール-Wireshark(TCPスリーウェイハンドシェイクデータ分析で詳しく説明)
Capture Tool Wireshark
関数使用の詳細な紹介
Wireshark(公式ダウンロードサイト: Http://www.wireshark.org/)は、ネットワークデータパケットを取得するために使用されます。ネットワークデータパケットは、さまざまなネットワークパケットを傍受し、http、TCP、UDP、およびその他のネットワークプロトコルパッケージを含むネットワークパケットの詳細情報を表示できます。注:wiresharkは、パケットの内容ではなく、パケットのみを表示したり、パケットを送信したりできます。
まず、インターフェースを開始します
図1に示すように、インターフェースを開始します。
図1(wireshark開始インターフェイス)
[Caputre]-> [Interfaces]をクリックすると、図2に示すダイアログボックスが表示され、ネットワークパケットをキャプチャする必要があるネットワークカードを選択し、[スタート]ボタンをクリックしてパケットのキャプチャを開始します。
注:インターフェースをクリックすると、プロンプトが次のようにポップアップ表示されます。「キャプチャを実行できるインターフェースはありません。」 ->解決策:管理者として実行
図2(キャプチャインターフェイス)
第二に、ウィンドウインターフェイスの紹介
図3に示すように、パッケージをキャプチャした後のウィンドウインターフェイスと、それ自体で追加されたインターフェイスの説明です。
図3(wiresharkウィンドウ)
1、フィルター(フィルタリングルールの概要)
フィルタリングを使用することは非常に重要です。キャプチャされたデータには冗長な情報がたくさんあるため、フィルタリング機能は、非準拠のパッケージを除外し、分析効率を向上させるのに役立ちます。
フィルタには次の2つのタイプがあります。
1)図3のフィルターである表示フィルターは、キャプチャーされたレコードで見つかった必要なレコードをフィルター処理するために使用されます。フィルタリング後、保存ボタンをクリックして、フィルターバーに保存したばかりのデータボタンを追加できます。
といった:
Tcp->はTCPプロトコルのレコードのみを表示します
Http-> HTTPプロトコルのレコードのみを見る
Ip.src == 192.168.1.102->送信元アドレスが192.168.1.102のレコードを表示します
Ip.dst == 192.168.1.102->宛先アドレスが192.168.1.10のレコード
Ip.addr == 42.121.252.58->ホストとの通信のみを表示
Tcp.port == 80->ポートは80です
Tcp.srcport == 80-> TCPプロトコルの送信元ポートが80であることのみを示します
Http.request.method == 'GET'-> HTTPGETメソッドのみを表示します
Eth.type == 0x806-> ARPパケットのみを表示します。このフィールドの値は、それがARPパケットであることを示します。 IPパケットの場合、値は0x8000です。
注:タイプの後の値を思い出せない場合は、図4に示すように、式で選択できます。
図4(式の設定)
2)キャプチャ->キャプチャフィルタ。キャプチャされたパケットをフィルタリングして、あまりにも多くのレコードをキャプチャしないようにするために使用されます。
2、パッケージリスト(パケットリストペイン)
パッケージリストのパネルには、番号、タイムスタンプ、送信元アドレス、宛先アドレス、プロトコル、長さ、およびパケット情報が表示されます。さまざまなプロトコルがさまざまな色で表示されていることがわかります。もちろん、[表示]-> [カラーリングルール]で色を表示するためのルールを変更することもできます。
3、パケットの詳細(パケットの詳細ペイン)
これは、プロトコルの各フィールドを表示するために使用される最も重要な情報です。 OSIの7層モデルは、物理層、データリンク層、ネットワーク層、トランスポート層、セッション層、プレゼンテーション層、およびアプリケーション層です。
パケット情報では、各行の対応する意味とOSIモデルの対応する関係は次のとおりです。
フレーム:物理層のデータフレームの概要-> OSI7層モデルの[物理層]に対応
イーサネットII:データリンク層イーサネットフレームヘッダー情報-> OSI7層モデルの[データリンク層]に対応
インターネットプロトコルバージョン4:インターネット層のIPパケットヘッダー情報->対応するOSI7層モデル[ネットワーク層]
伝送制御プロトコル:トランスポート層Tのデータセグメントヘッダー情報。これは、TCP->対応するOSI7層モデルの[トランスポート層]です。
ハイパーテキスト転送プロトコル:アプリケーション層の情報。これがHTTPプロトコルです-> OSI7層モデルの[アプリケーション層]に対応します。
パケットの各層の詳細な意味は次のとおりです。
次のパケットデータ解析はブログからのものです。 https://my.oschina.net/u/1585857/blog/479306
(1)物理層のデータフレームの概要
フレーム5:ワイヤ上で268バイト(2144ビット)、インターフェイス0でキャプチャされた268バイト(2144ビット)#5フレーム、ライン268バイト、実際には268バイトをキャプチャ
Interface id: 0 #interface id Encapsulation type: Ethernet (1) #Package type Arrival Time: Jun 11, 2015 05:12:18.469086000 China Standard Time #Capture Date and Time [Time shift for this packet: 0.000000000 seconds] Epoch Time: 1402449138.469086000 seconds [Time delta from previous captured frame: 0.025257000 seconds] #Time interval between this package and the previous package [Time since reference or first frame: 0.537138000 seconds] #Time interval between this packet and the first frame Frame Number: 5 #Frame number Frame Length: 268 bytes (2144 bits) #Frame length Capture Length: 268 bytes (2144 bits) #Capture length [Frame is marked: False] #Does this frame be marked: No [Frame is ignored: False] #This frame is ignored: No [Protocols in frame: eth:ip:tcp:http] #Intra-packaged protocol hierarchy [Number of per-protocol-data: 2] # [Hypertext Transfer Protocol, key 0] [Transmission Control Protocol, key 0] [Coloring Rule Name: HTTP] #Colored Tag Protocol Name
[カラーリングルール文字列:http || tcp.port == 80]#カラーリングルール表示の文字列
(2)データリンク層イーサネットフレームヘッダー情報
イーサネットII、Src:Giga-Byt_c8:4c:89(1c:6f:65:c8:4c:89)、Dst:Tp-LinkT_f9:3c:c0(6c:e8:73:f9:3c:c0)
宛先:Tp-LinkT_f9:3c:c0(6c:e8:73:f9:3c:c0)#ターゲットMACアドレス
Source: Giga-Byt_c8:4c:89 (1c:6f:65:c8:4c:89) # MAC Type: IP (0x0800)
(3)インターネット層のIPパケットヘッダー情報
インターネットプロトコルバージョン4、Src:192.168.0.104(192.168.0.104)、Dst:61.182.140.146(61.182.140.146)
バージョン:4 #Internet Protocol IPv4
Header length: 20 bytes #IP packet header length Differentiated Services Field: 0x00 (DSCP 0x00: Default ECN: 0x00: Not-ECT (Not ECN-Capable Transport)) #Differential Service Field Total Length: 254 #IP packet total length Identification: 0x5bb5 (23477) #flag field Flags: 0x02 (Don't Fragment) #tag field Fragment offset: 0 # Time to live: 64 # lifetime TTL Protocol: TCP (6) #The upper layer protocol encapsulated in this packet is TCP. Header checksum: 0x52ec [validation disabled] #Checksum of header data Source: 192.168.0.104 (192.168.0.104) # IP Destination: 61.182.140.146 (61.182.140.146) #Target IP address
(4)トランスポート層TCPデータセグメントヘッダー情報
伝送制御プロトコル、Srcポート:51833(51833)、Dstポート:http(80)、Seq:1、Ack:1、Len:214
ソースポート:51833(51833)#
Destination port: http (80) #Target port number Sequence number: 1 (relative sequence number) # (relative serial number) [Next sequence number: 215 (relative sequence number)] #Next serial number Acknowledgment number: 1 (relative ack number) #confirm serial number Header length: 20 bytes #head length Flags: 0x018 (PSH, ACK) #TCP field Window size value: 64800 # Checksum: 0x677e [validation disabled] #TCP data segment checksum
パケットキャプチャデータを組み合わせてTCPスリーウェイハンドシェイクプロセスを分析する
1.まず、図5に示すように、TCPスリーウェイハンドシェイクプロセスを知る必要があります。
図5(TCPスリーウェイハンドシェイクプロセス)
Baidu百科事典では、TCPスリーウェイハンドシェイクプロセスについて次のように説明しています。
最初のハンドシェイク:接続を確立すると、クライアントはサーバーにsynパケット(syn = j)を送信し、SYN SENT状態に入り、サーバーがSYNを確認するのを待ちます。これはSynchronize SequenceNumbersです。
2番目のハンドシェイク:サーバーはsynパケットを受信し、クライアントのSYNを確認する必要があり(ack = j + 1)、SYNパケット(syn = k)、つまりSYN + ACKパケットとサーバーも送信します。 SYNRECV状態になります。
3番目のハンドシェイク:クライアントはサーバーからSYN + ACKパケットを受信し、確認応答パケットACK(ack = k + 1)をサーバーに送信します。パケットが送信された後、クライアントとサーバーはESTABLISHED状態に入り、3回完了します。ハンドシェーク。
2. TCPパケットの特定の内容が図6に示されていることを明確にします(TCPパケットの特定の内容はブログからのものです: http://www.cnblogs.com/TankXiao/archive/2012/10/10/2711777.html)
図6(TCPパッケージの特定のコンテンツ)
3、次の例では、wiresharkでtcpスリーウェイハンドシェイクプロセスを使用しています。
1)wiresharkを開いた後、ブラウザにアクセスアドレスを入力します。 http://www.cnblogs.com/Chilam007/では、wiresharkはデータパケットを自動的にキャプチャし、分析が必要なデータをフィルタリングします。これは、ホストとの通信をフィルタリングするレコードです。
フィルタリングルールはip.addr == 116.211.169.93であり、フィルタリングされたデータは図7のようになります。
図7(フィルタリングされたパケット表示、注:パケットがここで複製される理由はわかりません)
574フレームは、クライアントが接続を確立するためにサーバーにTCP要求を送信することです。識別子はSYNです。
619フレームは、サーバーが要求を受信した後、確認パケットでクライアントに応答するプロセスです。識別子はSYN、ACKです。
620フレームは、クライアントが確認応答パケットを送信するサーバーに応答し、サーバーで接続を確立するプロセスです。識別子はACKです。
663フレームは、クライアントがHTTP要求コンテンツをサーバーに送信するプロセスです。 IDはGETです。
667フレームは、サーバーがクライアント要求に応答して要求を受信するプロセスです。識別子はACKです。
674フレームは、サーバーがクライアントに応答するプロセスです。
2)TCPスリーウェイハンドシェイク分析:
図8に示すように、最初のハンドシェイクパケット、クライアントはTCPを送信し、フラグはSYN、シリアル番号は0であり、接続を確立するためのクライアント要求に代わって行われます。
図8(最初のハンドシェイク)
2回目のハンドシェイクでは、サーバーはフラグビットSYN、ACKを含む確認応答パケットを送り返します。図9に示すように、確認応答番号をクライアントのI SNプラス1から0 + 1に設定します。
図9(2回目のハンドシェイク)
3番目のハンドシェイクのデータパケットであるクライアントは、確認応答パケット(ACK)を再度送信します。 SYNフラグビットは0、ACKフラグビットは1であり、サーバーから送信されたシーケンス番号フィールド+1は、決定フィールドに配置され、相手に送信されます。そして、図10に示すように、ISNの+1をデータセグメントに配置します。
図10(3番目のハンドシェイク)
上記は、wiresharkでのtcpスリーウェイハンドシェイクプロセスです。
https://www.cnblogs.com/Chilam007/p/6973990.htmlから転載