パケットキャプチャ

【前編】ファイルサーバーのハイブリッド化！認証の進化をパケットで確認！SMB・NTLM・Kerberos この記事の内容 ワークグループ環境でのSMB・NTLM認証の仕組みと課題を解説します Active Directory環境でKerberos認証がどのように動作するかを説明します パケットキャプチャを通じて、NTLMとKerberosの違いを具体的に確認します サービスプリンシパルネーム（SPN）の役割とCIFS・Hostの関係を説明します オンプレミスからクラウドへの認証進化の流れを整理します はじめに クラウド環境が普及した現在でも、Kerberos認証は多くの場面で利用されています。本記事では、身近なファイルサーバーを題材に、クラウドやオンプレミスの端末からファイルサーバーを利用する際、認証プロトコルがどのように進化してきたのかを解説します。シングルサインオンをはじめとした最新の認証手法やプロトコルの違いについても、パケットの観点から掘り下げていきます。 オンプレミスのActive Directory環境を利用しつつもクラウド活用を検討している方、ファイルサーバーの運用やクラウドストレージへの移行を考えている方、認証プロトコルの仕組みに興味がある方に特におすすめの内容です。 ワークグループ環境とNTLM認証 ワークグループ環境とは まずは認証の基礎から、ワークグループ環境について説明します。ワークグループ環境とは、Active Directoryなどの集中管理されたIDが存在しない、ご家庭や小規模事業でよく見られる構成です。たとえば、家電量販店で購入したWindows PC同士をそのまま使うと、この形態になります。 ローカルアカウントとファイル共有 各Windowsマシンにはローカルアカウントを作成できます。「コンピューターの管理」ツールの「ローカルユーザーとグループ」からユーザーを追加できます。共有フォルダーも作成可能で、Windowsクライアント自体がファイルサーバーとして機能します。 SMBとNTLM認証の仕組み この環境で他のPCの共有フォルダーへネットワーク越しにアクセスするには、SMB（Server Message Block）プロトコルとNTLM（NT LAN Manager）認証が利用されます。エクスプローラーで以下のように入力すると、「ネットワーク資格情報の入力」が求められます。 \ 1 0 . 1 . 1 . 4 ここで入力するユーザー名とパスワードはアクセス先サーバーのローカルアカウントです。サーバー側に該当ユーザーが存在しない場合は認証失敗、存在すればアクセスが可能です。 パケットレベルで見るNTLM認証 パケットキャプチャを行うと、以下の流れが確認できます。 TCP 445番ポートへの3ウェイハンドシェイク SMBプロトコルネゴシエート（バージョン交渉） NTLM認証の選択 SMB2プロトコルとNTLM認証のやり取りがパケット上で明示されており、認証の流れを視覚的に把握できます。 ワークグループ環境の課題 この方式では、ファイルサーバーごとに別々のローカルアカウント管理が必要となり、ユーザーは各サーバーで異なるIDとパスワードを覚える必要があります。すべてのサーバーで同じIDとパスワードを使う方法もありますが、セキュリティ上好ましくありません。 この「アカウント分散管理」はワークグループ運用の大きなデメリットです。現在ではほとんど利用されなくなりましたが、20年以上前には一般的な構成でした。 Active Directory環境とKerberos認証 Active Directoryの概要 ワークグループ環境の課題を解決するために登場したのが、Active Directory（AD）環境です。ADではドメインコントローラー（DC）がディレクトリデータベースを持ち、ユーザーやコンピューター、サービスを一元管理します。各マシンは「ドメイン参加」によりドメインと信頼関係を結びます。 Kerberos認証の導入 ファイルサーバーへのアクセス自体はSMBのままですが、認証方式はKerberosへと進化しました。KerberosはNTLMより遥かにセキュアで、複雑な仕組みを持っています。 Kerberos認証の流れ Kerberos認証は以下の3ステップで動作します。 ステップ1: TGTの取得 ユーザーがWindowsクライアントにログインすると、ドメインコントローラー（KDC: Key Distribution Center）からTGT（Ticket Granting Ticket）を受け取ります。 ...

ルーティングテーブル・スタティックルート・Windows 10のルーター化をWiresharkで理解する この記事の内容 2つのネットワークをまたぐ通信がなぜ失敗するか、ルーティングテーブルで理解する Windows 10の「Routing and Remote Access」サービスを使ってルーターとして動作させる方法 デフォルトゲートウェイとスタティックルートの違いと使い分け route add コマンドによる静的ルート追加の手順（永続化オプション含む） Wiresharkでパケットキャプチャしながらレイヤー2/レイヤー3それぞれの動きを追う 検証環境の構成 今回の検証では、以下の3台のPCを使用します。 マシン ネットワーク IPアドレス PC-A 192.168.2.0/24 のみ 192.168.2.202 PC-B（中継機） 192.168.1.0/24 と 192.168.2.0/24 の両方 192.168.1.203 / 192.168.2.201 PC-C 192.168.1.0/24 のみ 192.168.1.203 PC-B は2つのネットワークに足を出しており、ルーターとして構成することが今回の目標です。また、PC-AとPC-Cはインターネットへの接続のためデフォルトゲートウェイが設定されています。 ルーティングテーブルの基本 パケットを送信する際、OSはまずルーティングテーブルを参照して「どのインターフェイスから、どのゲートウェイを経由して送るか」を決定します。 ルーティングテーブルを確認するには、コマンドプロンプトで以下を実行します。 route print ルーティングテーブルには宛先ネットワーク、サブネットマスク、ゲートウェイ、インターフェイス、メトリックが含まれています。パケットは宛先IPアドレスに最も一致するエントリに従って転送されます。どのエントリにも一致しない場合は、デフォルトゲートウェイ（0.0.0.0/0）へ転送されます。デフォルトゲートウェイも設定されていない場合は、転送エラーになります。 検証1：ルート未設定での通信失敗 PC-A（192.168.2.202）から PC-C（192.168.1.203）に対して ping を打ちます。 ping 192.168.1.203 結果：転送失敗（エラー） PC-A のルーティングテーブルには 192.168.2.0/24 のエントリは存在しますが、192.168.1.0/24 のネットワークは登録されていません。また、このPCにはデフォルトゲートウェイが設定されていないため、どのエントリにも一致せず、パケットを送り出せずにエラーとなります。 検証2：デフォルトゲートウェイ経由での誤ルーティング デフォルトゲートウェイが設定されているPCから同様の ping を試みます。 ping 192.168.1.203 結果：タイムアウト（Request timed out） このケースでは以下の動きが発生します。 ルーティングテーブルに 192.168.1.0/24 のエントリがないため、デフォルトゲートウェイ（例：192.168.1.254）へ転送される レイヤー2レベルでは、デフォルトゲートウェイのMACアドレス宛にフレームが送出される パケットはデフォルトゲートウェイの先へ転送されるが、192.168.2.0/24 は全く別のネットワークのため、応答が返ってこない Wiresharkでキャプチャすると、ICMPパケットのソースとデスティネーションのIPアドレスは正しいものの、イーサネットフレームの宛先MACアドレスがデフォルトゲートウェイのものになっていることを確認できます。 ...

ネットワークアドレス / サブネットマスク / ルーティングテーブルをパケットキャプチャで理解する この記事の内容 IPアドレスとサブネットマスクのビット演算によってネットワークアドレスが決まる仕組みを解説します route print コマンドでルーティングテーブルを確認し、その読み方を説明します Wiresharkを使って実際の通信（ICMP・ARP）の流れをパケットレベルで観察します 同一ネットワーク内での通信と、複数NICを持つPCのルーティング動作を検証します ブロードキャストが同じネットワーク上の全端末に届く様子をキャプチャで確認します はじめに 今回はWiresharkを使ったパケットキャプチャを通じて、ネットワークアドレス・サブネットマスク・ルーティングテーブルの仕組みを実際の通信を見ながら確認していきます。 検証環境として、Windows 10のPCを3台用意しました。まず 192.168.1.0/24 というネットワークに3台を接続し、それぞれに以下のIPアドレスを割り当てています。 PC1: 192.168.1.201 PC2: 192.168.1.202 PC3: 192.168.1.203 ネットワークアドレスとサブネットマスクの関係 IPアドレスとサブネットマスクを組み合わせることで、そのホストが所属するネットワークアドレスが分かります。 サブネットマスク 255.255.255.0 を2進数で表すと次のようになります。 2 = 5 5 1 . 1 2 1 5 1 5 1 . 1 2 1 5 1 5 . . 1 0 1 1 1 1 1 1 1 . 1 1 1 1 1 1 1 1 . 0 0 0 0 0 0 0 0 このサブネットマスクをIPアドレスとビット単位でAND演算すると、ネットワークアドレスが求められます。 ...

ネットワークパケットキャプチャ入門 ─ WiresharkでHTTP通信の中身を見てみよう この記事の内容 WiresharkでHTTPプロトコルのパケットをキャプチャし、通信の中身を確認する手順を解説します TCPの3ウェイハンドシェイクからHTTP GETリクエスト・レスポンスまで、一連の通信フローを追います HTTPストリーム追跡機能を使って、リクエストとレスポンスの内容を人間が読める形式で確認します HTTPとHTTPSの違い（暗号化の有無）と、HTTPSトラフィックが直接見えない理由を説明します 概要 本記事はネットワークパケットキャプチャシリーズの第3弾です。今回はHTTPプロトコルに焦点を当て、Webサイトを閲覧したときに裏側でどのような通信が行われているかをWiresharkで実際に確認していきます。 対象のWebページには、以下のような非常にシンプルなHTMLで構成されたテストページを使用します。 <html> <head><title>テストページ</title></head> <body> <p>テストページです</p> </body> </html> キャプチャの準備とフィルタリング Wiresharkを起動してキャプチャを開始した状態で、ブラウザからテストページにアクセスします。アクセスすると大量のパケットが表示されますが、今回はHTTPプロトコルに絞って観察したいため、表示フィルターに以下を入力します。 h t t p これにより、HTTPプロトコルのパケットのみが表示されるようになります。 パケットの中身を確認する フィルタリングされたパケット一覧から、テストページへのGETリクエストを確認できます。パケットの情報には以下のような内容が含まれています。 Source（送信元）：自分のPC（例：192.168.1.xxx） Destination（宛先）：テストページのサーバーIPアドレス プロトコル：HTTP 内容：GETリクエスト（ページの取得） TCPストリームで通信全体を追跡する HTTPパケットを右クリックし、「追跡」→「TCPストリーム」を選択すると、その通信セッション全体の流れを一覧で確認できます。 TCPストリームでは以下の流れが確認できます。 3ウェイハンドシェイク（SYN → SYN-ACK → ACK）による通信確立 クライアントのポート番号（例：60321）からサーバーの80番ポートへの接続 HTTPによるGETリクエストの送信 サーバーからの200 OKレスポンスとコンテンツの返却 FINパケットなどによる接続の切断 クライアント側のポート番号は接続のたびに変わりますが、サーバー側（80番ポート）は常に同じです。 HTTPストリームで内容を読み取る TCPストリームではTCPレベルの通信が見えますが、HTTPに特化した内容を確認したい場合は「HTTPストリーム」を使います。 HTTPパケットを右クリックし、「追跡」→「HTTPストリーム」を選択します。 リクエスト（赤色部分） クライアントからサーバーへ送信した内容が赤色で表示されます。 G H U （ E o s そ T s e の t r 他 / : - H t A T e e g T s b e P t i n ヘ / s t ッ t u : ダ e d ー s a （ ） t . ブ . c ラ h o ウ t m ザ m 情 l 報 ） H T T P / 1 . 1 GET：ページを取得するコマンド Hostヘッダー：接続先のホスト名 User-Agent：ブラウザの種類やバージョンなどの情報 レスポンス（青色部分） サーバーからクライアントへ返ってきた内容が青色で表示されます。 ...

ネットワークパケットキャプチャで学ぶ TCP 3ウェイハンドシェイク この記事の内容 ICMPとTCPの接続確立方式の違いについて解説します netstat コマンドを使ってリッスン状態のポートとESTABLISHED接続を確認します WiresharkでSYNフラグをフィルタリングし、3ウェイハンドシェイクのパケットを観察します 送信元・送信先のIPアドレスとポート番号の4つの要素でTCP接続を識別する仕組みを説明します WiresharkのTCPストリーム追跡機能を使った接続トラブルシューティングの方法を紹介します ICMPとTCPの違い 前回の動画では、Wiresharkを使ってICMPパケット（pingコマンド）の動きを確認しました。ICMPはリクエストを投げて返ってきたら「届いた」、返ってこなければ「届かなかった」というシンプルな仕組みです。接続を「確立する」という概念がありません。 一方、TCP（Transmission Control Protocol） はきちんと接続を確立するという手続きがあります。接続が確立されているかどうかを確認することが、ネットワークのトラブルシューティングにおいて非常に重要になります。 今回は、この接続確立の仕組みである3ウェイハンドシェイクをWiresharkで観察していきます。 環境の確認：リッスンしているポートの確認 まず、仮想マシン上で待ち受けているポートを確認します。 netstat -an このコマンドを実行すると、現在リッスン（待ち受け）しているポートの一覧が表示されます。 T T T C C C P P P 0 0 0 . . . 0 0 0 . . . 0 0 0 . . . 0 0 0 : : : 1 4 5 3 4 0 5 5 4 0 0 0 0 . . . 0 0 0 . . . 0 0 0 . . . 0 0 0 : : : 0 0 0 L L L I I I S S S T T T E E E N N N I I I N N N G G G LISTENING の状態にあるものが待ち受けているポートです。今回はこの中から 135番ポート に対してTCP接続を試みます。 ...

ネットワークパケットキャプチャ入門 — Wiresharkで学ぶARPとICMP この記事の内容 Windows 10仮想マシン2台にWiresharkをインストールし、パケットキャプチャ環境を構築します プライベートIPアドレスを手動設定し、2台間で通信できる状態を作ります ARPによるMACアドレス解決の仕組みをパケットレベルで確認します ICMPを使ったping通信をキャプチャし、到達確認とトラブルシューティングの基礎を学びます Windowsファイアウォールが原因でpingの返答がない場合の調査・対処を実演します Wiresharkのインストール 今回はWindows 10の仮想マシンを2台用意し、それぞれにWiresharkをインストールします。 Wiresharkのインストーラーをダウンロードして実行すると、インストールウィザードが順に進みます。途中でNpcap（ネットワークパケットキャプチャライブラリ）のインストールを求められますが、これもそのままインストールしてください。Wiresharkが内部でパケットをキャプチャするために必要なコンポーネントです。 インストール完了後、デスクトップにショートカットを作成しておくと便利です。同じ手順を2台目の仮想マシンにも行います。 注意: Wiresharkはキャプチャ時に管理者権限が必要になる場合があります。うまくキャプチャできない場合は「管理者として実行」で起動してください。 ネットワーク設定（プライベートIPアドレスの手動設定） 2台の仮想マシンが互いに通信できるよう、IPv4アドレスを手動で設定します。 プライベートIPアドレスの範囲（IPv4） 範囲 CIDR 10.0.0.0 〜 10.255.255.255 /8 172.16.0.0 〜 172.31.255.255 /12 192.168.0.0 〜 192.168.255.255 /16 テスト環境では、最も小さいレンジである 192.168.x.x 系が使われることが多いです。今回は以下のように設定します。 1台目: 192.168.1.1 / 255.255.255.0 2台目: 192.168.1.2 / 255.255.255.0 サブネットマスクはIPアドレス入力後にTabキーを押すと自動入力されます。デフォルトゲートウェイは今回のテストでは不要ですので空欄のままでかまいません。 この設定により、2台は同一ネットワーク（192.168.1.0/24）に属し、直接通信が可能な状態になります。 Wiresharkの起動とキャプチャ開始 Wiresharkを起動すると、利用可能なネットワークインターフェース一覧が表示されます。今回は実際の物理的なネットワークに対応する Ethernet アダプターを選択します。 インターフェースをダブルクリック、またはキャプチャ開始ボタンを押すと、パケットのキャプチャが始まります。通信が何も発生していなければパケットは表示されませんが、何らかの通信が起きると次々とパケットが流れてきます。 実際の業務ネットワークなどでは大量のパケットが流れるため、フィルター機能を活用して必要なパケットだけを絞り込むのがポイントです。 ICMPフィルターをかけてpingを確認する 1台目から2台目へpingを実行してみます。 ping 192.168.1.2 Wireshark側でICMPのみ表示するよう、フィルターバーに以下を入力します。 i c m p pingの返答がない場合 コマンドプロンプトでは「応答なし」が表示されますが、Wiresharkを確認すると、1台目からICMPエコーリクエストは確かに送出されています。 ...