Wiresharkを使ったパケット解析の基本

どうもはじめまして。
マネックス証券 システム開発部の芦刈です。

今回は通信監視、パケット解析ツールとしてメジャーなWiresharkとそれを利用したパケット解析の基本についてお話したいと思います。

Wiresharkとは

wiresharkとは、GPLライセンスで配布されているオープンソースのネットワークプロトコルアナライザです。 様々なレイヤにおける多岐プロトコル(EthernetフレームからHTTPメッセージまで)に渡って対応しており、ネットワーク内に流れている特定のパケットをキャプチャしたり、統計情報にまとめたりすることができるグラフィカルなツールです。

パケットキャプチャツールとしては、tcpdumpやtcpflow、SNMPを利用したRMONなどがもありますが、CUIであるためとっつきにくかったり、RMONについてはそもそも一定間隔でしか取得できないため、通信監視やパケット解析についてこれから勉強しようとされる方にはWiresharkがおすすめです。

パケット分析手法

パケット分析手法には、大きく2種類の手法があります。

1つ目はミクロ的な分析手法です。 これはネットワークを流れるパケットのひとつひとつに着目し、機器間における通信の向きや通信によってやり取りされている内容について分析する手法です。 パケットのダンプファイルを使って実施するダンプ解析や各プロトコルのストリーム分析が該当します。

2つ目はマクロ的な分析手法です。 これはネットワークにおけるトラフィック全体に着目し、正常なトラフィックに混ざる 異常なトラフィックを検知して分析する手法です。 通常時とは異なるプロトコルや通信先に対するトラフィックに着目するアノマリ分析や トラフィック流量の多寡に着目する流量分析が該当します。

手法
ミクロ的手法 ダンプ解析、TCPストリーム分析、TLSストリーム分析 ...etc
マクロ的手法 アノマリ分析、流量分析 ...etc

本記事では、ミクロ的な手法について言及します。

ブラウザからのリクエストパケットの取得

各種アプリケーションの通信をキャプチャすることも可能ですが、昨今はほぼ確実にSSL/TLS等で通信が暗号化されています。
通信内容を詳らかにするには秘密鍵を把握しておく必要があるのですが、そのためにはCharlesやBurpShiteなどのローカルプロキシをセットアップし、有効なルート証明書を登録した上で、アプリ自体をローカルプロキシ経由で通信させる等、些かハードルが高くなります。
そのため、比較的簡単にできるchromeブラウザからのリクエストパケットの取得を実施します。

事前準備

  • 秘密鍵情報の出力設定
    ブラウザを介して取得した秘密鍵をファイルに出力するようにします。
    手順は簡単で、ブラウザのショートカットプロパティに下記オプションを設定します。
    なお、パスとファイル名は任意で設定できます。ブラウザを起動した際に、ファイルが作成されることだけ確認してください。
--ssl-key-log-file=D:\work\sslkeys.log

f:id:tashi_monex:20200617065422p:plain:w200
プロパティ設定例

  • ブラウザのキャッシュクリア
    忘れがちですがこちらも必要です。
    キャッシュが残っている場合、「304 Not Modified」で返って来てしまいます。
    f:id:tashi_monex:20200617071101p:plain:w200
    chromeのキャッシュクリア
     
  • TLS復号設定 WireSharkを起動して、TLS通信の内容を復号するための設定をします。
    画面上部のメインツールバーから [編集] > [設定] > [Protocols] > [TLS] の順に選択し、「(Pre)-Master-Secret log filename」欄に、前述の秘密鍵情報の出力設定で設定したファイルパスを記載します。
    f:id:tashi_monex:20200617072119p:plain:w200
    Wireshark における TLS復号設定

パケットの取得と解析

事前準備が完了したら、早速パケットの取得です。
といっても、複雑な操作は一切必要なく、Wiresharkを起動して、キャプチャの欄から適切なネットワークアダプタを選択するだけです。自分がどのネットワークアダプタを利用しているかはコントロールパネルの「ネットワークとインターネット」から確認できます。下記の図のように、私の場合は「イーサネット」となります。

f:id:tashi_monex:20200617073417p:plain:w200
ネットワークアダプタの確認

Wiresharkのアプリケーションウィンドウは下記の図のようになっています。
以降、①をパケット一覧、②をパケット詳細、③をパケットバイト列と呼称します。
なお下記図ではパケット一覧におけるTimeカラムだけ、日時表示となるようにデフォルトから変更しています。変更の方法は画面上部メインツールバー[表示] > [時刻表示形式] から「日時」を選択するだけです。

f:id:tashi_monex:20200617074722p:plain
Wireshark 表示例

さて、Wiresharkのパケット一覧が自動的にスクロールし、パケットをキャプチャできていることが確認できたら、事前準備で設定したブラウザのショートカットからブラウザを起動し、下記リンクを開いてください。
リンク先からも色々な記事のリンクに飛んでみてくださいね(笑)
https://blog.tech-monex.com/

いっぱいアクセスいただけましたら、パケット一覧上部にあるディスプレイフィルタに下記を入力してください。
(そのままだと、以降の作業実施中もずっとパケットキャプチャが実施されるため、このタイミングでメインツールバー左下の赤い四角ボタンを押してキャプチャを停止するのがおすすめです。)

http.request.uri contains "blog.tech-monex.com"

すると、下記のように復号されたHTTPの通信内容が確認できます。

f:id:tashi_monex:20200617080322p:plain
復号されたHTTP通信内容

次にHTTPリクエストに対して200 OK でレスポンスされたパケットのうち、htmlを返しているものを選択して右クリックし、コンテキストメニューから[追跡] > [HTTP ストリーム]を選択します。
そうすることで、新規にウィンドウが開き、一連のリクエストレスポンスにおけるHTTPヘッダとHTMLボディが表示されます。 赤がクライアントからのリクエストで、青がサーバからのレスポンスを表しています。

f:id:tashi_monex:20200617082016p:plain
HTTP ストリーム

また、上記操作によってパケット一覧にはHTTP通信のパケットのみではなく、そのHTTP通信と組み合わせて使われたSSL/TLSのパケットや下位層のTCPプロトコルを表示してくれます。
ⅰが3 way handshakeによるTCPコネクションの確立、ⅱがSSL/TLSのhandshakeによる鍵交換と証明書の確認、ⅲが(TCP上で実施される)HTTPのリクエストとレスポンスです。

f:id:tashi_monex:20200617083659p:plain
Webサーバとの通信例

ここまで見ることが出来るようになれば、Webサーバに対するリクエストレスポンスのパケット解析の基本ができるようになったといって過言ではないでしょう。

解析したパケットの評価

上記では、Webサーバへのリクエストレスポンスパケットの解析をしましたが、それをもとに簡単な遅延評価ができます。
上記で取得した通信の概要について下記に図示します。

f:id:tashi_monex:20200617103524p:plain
クライアントとWebサーバ間の通信概略図

図では、遅延が発生した場合に原因がわかりやすい部分について、①~⑤の番号をつけています。
①~⑤のいずれかにおいて、遅延とみなせる程大きくパケット送受信の時間間隔が開いてしまった場合、下記のようなボトルネックがあることが推察できます。

No ボトルネック 対策
ソケット起動状態でのClient - Server間の接続処理のため、ネットワーク上での遅延が考えられる。 遅延の少ない回線に変更したり、中継機器を高性能なものに変える。
ClientのAck応答速度のため、Clientの性能の問題が考えられる。 CPUやメモリリソースを確認し、足りない分を増強する。
SSL/TLS Server の応答速度のため、SSL/TLS Server の性能の問題が考えられる。また、SSL/TLS handshakeが何度も実施されている場合、HTTP通信後にコネクションをcloseしている可能性がある。 SSL/TLS Serverの増強。コネクションをKeep Aliveするように、またはKeep Aliveの持続時間を延ばすようにWebアプリを修正する。
Web Serverの応答速度のため、Web Serverの性能の問題が考えられる。また、Web ServerのOSで遅延ACKを実施するような設定になっている。 Web Serverの増強。または、Web Server側のOSのTCPチューニング。
Webアプリケーションがレスポンスメッセージを作るまでの速度のため、Webアプリケーションの問題が考えられる。DBへのSQL問合せの処理に時間がかかっている場合が多い。 Webアプリケーションの実装を見直す。

どうでしょうか?
意外かもしれませんが、プロトコルの仕組みさえ理解できていれば、ちょっとパケットを覗くだけで、いろいろなものが見えてきます。

最後に

Wiresharkを利用したパケット解析は、参考になるサイトも多く、敷居が低いながら奥が深いです。
会社の社内Webサーバの性能分析であったり、Webサービス開発時の評価の1手法として導入したり、はたまた大学生の方なら短期研究のテーマにして単位の足しにしたり等、触ってみていただけると幸いです。