60歳からのホワイトハッカーへの道 #9


tcpdumpでパケットを捕まえた！IPアドレスとMACアドレスの違いが見えてきた


ホワイトハッカーを目指して勉強を始めた60歳の初心者です。


現在、『3分間ネットワーク基礎講座』という本を読みながら、

ネットワークの基礎を勉強しています。


ようやくOSI参照モデルのレイヤー2（データリンク層）まで読み進めました。


IPアドレス、MACアドレス、ARPなど、少しずつ用語は覚えてきたものの、

実際にどのように通信しているのかは、まだよく分かりません。


そこで今回は、Macのターミナルからtcpdumpというコマンドを使い、

実際にネットワークを流れるパケットを観察してみました。


これが思っていた以上に面白かったのです！（笑）



1．tcpdumpとは？


tcpdumpは、ネットワークインターフェースを通過するパケットを

取得して表示できるツールです。


普段、Webサイトを開いたり、メールを送ったりするとき、

コンピューターの内部ではさまざまな通信が行われています。


tcpdumpを使うと、その通信の一部を実際に確認できます。


今回は、MacBook ProのWi-Fiインターフェース

en0を使って実験しました。


2．まずはpingの通信を捕まえてみる


最初にターミナルを2つ開きます。


ターミナル①：通信を監視する


sudo tcpdump -i en0 -n icmp


このコマンドは、en0を通過するICMPパケットを表示します。


次に、別のターミナルからGoogleの公開DNSサーバーへpingを送ります。


ターミナル②：pingを送信する


ping -c 3 8.8.8.8


すると、tcpdumpに次のような通信が表示されました。


192.168.1.23 > 8.8.8.8: ICMP echo request, seq 0
8.8.8.8 > 192.168.1.23: ICMP echo reply, seq 0

192.168.1.23 > 8.8.8.8: ICMP echo request, seq 1
8.8.8.8 > 192.168.1.23: ICMP echo reply, seq 1

192.168.1.23 > 8.8.8.8: ICMP echo request, seq 2
8.8.8.8 > 192.168.1.23: ICMP echo reply, seq 2


※表示内容は、実際の取得結果から一部を抜粋・簡略化しています。


Echo Requestは問い合わせ、

Echo Replyはその応答です。


3回送信して3回応答が返ってきたので、

合計6パケットを捕まえることができました。


6 packets captured


これまでpingの結果は何度も見たことがありましたが、

実際に要求と応答のパケットを確認したのは初めてです。


「本当にこうやって通信しているんだ！」と、

ちょっと感動しました。（笑）



3．MACアドレスも表示してみる


次に、tcpdumpへ-eオプションを追加してみました。


sudo tcpdump -i en0 -n -e icmp


-eを付けると、リンク層のヘッダー情報も表示されます。


再びpingを実行すると、今度はIPアドレスだけでなく、

MACアドレスも表示されました。


4e:5d:3f:27:ac:4d > 1c:7c:98:cb:bc:a0
192.168.1.23 > 8.8.8.8
ICMP echo request


ここで、面白いことに気がつきました。


IPアドレスの宛先は8.8.8.8なのに、

MACアドレスの宛先は別のアドレスなのです。


これはどういうことなのでしょうか？


4．IPアドレスとMACアドレスは役割が違う


調べてみると、IPアドレスとMACアドレスは

役割が異なることが分かりました。


IPアドレスは、ネットワークを越えて

通信する際の送信元や宛先を表します。


一方、MACアドレスは、

同じリンク上でフレームを届ける相手を指定するために使われます。


今回、MacはGoogleの8.8.8.8へ通信しようとしています。


しかし、Googleのサーバーへ直接フレームを届けるわけではありません。

まず、自宅のルーターへ渡します。


【Mac】
IP：192.168.1.23
       |
       | MACアドレスを使って
       | ルーターへ届ける
       v
【自宅ルーター】
IP：192.168.1.1
       |
       | IPパケットを転送
       v
【インターネット】
       |
       v
【Google DNS】
IP：8.8.8.8


つまり、レイヤー3では最終的な通信先を示し、

レイヤー2では、そのリンク上で次に届ける相手を指定しているのです。


本で読んでいた内容が、少しずつ実際の通信とつながってきました。



5．ルーターのMACアドレスを確認する


次に、本当にtcpdumpで表示されたMACアドレスが

ルーターのものなのか確認してみました。


まず、デフォルトゲートウェイを調べます。


route -n get default


結果は次のとおりです。


gateway: 192.168.1.1
interface: en0


続いてARPテーブルを確認します。


arp -an


すると、次の情報が表示されました。


192.168.1.1 at 1c:7c:98:cb:bc:a0
192.168.1.23 at 4e:5d:3f:27:ac:4d


なんと、tcpdumpに表示されていたMACアドレスと完全に一致しました！


1c:7c:98:cb:bc:a0はルーター、

4e:5d:3f:27:ac:4dはMacのMACアドレスでした。


これで、MacからGoogleへの通信が、

まずルーターへ送られていることを確認できました。


6．ARPとは何だろう？


ここで新しい疑問が出てきます。


「Macは、どうやってルーターのMACアドレスを知ったのだろう？」


そこで登場するのがARP（Address Resolution Protocol）です。


ARPは、IPv4のローカルネットワークで、

IPアドレスに対応するMACアドレスを調べるための仕組みです。


例えば、MacがルーターのMACアドレスを知らない場合、

次のような問い合わせを行います。


Mac：
「192.168.1.1を使っているのは誰？」

ルーター：
「私です！
 MACアドレスは1c:7c:98:cb:bc:a0です」


このやり取りを実際に見てみることにしました。



7．ARPパケットを捕まえてみる


ARPだけを表示するため、次のコマンドを実行しました。


sudo tcpdump -i en0 -n -e arp


そして、ルーターへpingを送ります。


ping -c 3 192.168.1.1


ところが、期待していたARP Requestが表示されません。


なぜだろう？


調べてみると、MacのARPテーブルには、

すでにルーターのMACアドレスが登録されていました。


つまり、Macは答えを知っていたので、

わざわざ問い合わせる必要がなかったのです。


なるほど、ARPは通信するたびに問い合わせるわけではないんですね。


これも実験して初めて分かったことでした。


8．ARPキャッシュを削除して再挑戦！


そこで、Macに保存されているルーターのARP情報を

いったん削除してみることにしました。


まず、ARPとICMPを同時に監視します。


sudo tcpdump -i en0 -n -e 'arp or icmp'


別のターミナルから次のコマンドを実行します。


sudo arp -d 192.168.1.1
ping -c 1 192.168.1.1


※ARPキャッシュの削除は、自分のMacで実施しました。

ネットワークの状態によっては通信が一時的に途切れる可能性があります。


すると、今度は期待していた通信を捕まえることができました！


① ARP Request


09:29:13.365376
Request who-has 192.168.1.1
tell 192.168.1.23


Macが「192.168.1.1のMACアドレスを教えて」と問い合わせています。


このときの宛先MACアドレスは、

ff:ff:ff:ff:ff:ffでした。


これはブロードキャストアドレスです。

LAN内へ問い合わせを送っています。


② ARP Reply


09:29:13.368826
Reply 192.168.1.1
is-at 1c:7c:98:cb:bc:a0


ルーターが自分のMACアドレスを返しています。


③ ICMP Echo Request


09:29:13.946152
192.168.1.23 > 192.168.1.1
ICMP echo request


MACアドレスを確認したあと、pingが送信されました。


④ ICMP Echo Reply


09:29:13.956288
192.168.1.1 > 192.168.1.23
ICMP echo reply


そして、ルーターから応答が返ってきました。


ARP Request → ARP Reply → ICMP Request → ICMP Reply


教科書で学んだ仕組みを、実際の通信で確認できました！


これはうれしいですね。（笑）



9．ARPテーブルにも情報が戻っていた


最後に、もう一度ARPテーブルを確認しました。


arp -an | grep 192.168.1.1


結果は、


192.168.1.1 at 1c:7c:98:cb:bc:a0


となっていました。


削除したはずのルーターのMACアドレスが、

再び登録されています。


つまり、


ARPキャッシュを削除
        ↓
ARP Requestで問い合わせ
        ↓
ARP ReplyでMACアドレスを取得
        ↓
ARPテーブルへ登録
        ↓
pingで通信


という流れを確認できたわけです。


10．知らないARP通信も流れていた


実験中には、次のような通信も表示されました。


Request who-has 0.0.0.0
tell 192.168.1.2


しかも、同じような通信が何度も表示されています。


これは今回の通常のMACアドレス解決とは異なる、

少し気になる通信です。


ただし、これだけで不正アクセスや攻撃だと

判断することはできません。


どの機器が何のために送っているのかは、まだ分かりません。


今後、Wiresharkなども使いながら調べてみたいと思います。


何でもすぐに「怪しい！」と判断するのではなく、

通信の内容を確認して考えることも大切ですね。



11．今回学んだこと


今回の実験では、次のことを学びました。


     

  • tcpdumpを使うと、ネットワークのパケットを観察できる

    •  

  • pingではICMPのEcho RequestとEcho Replyが使われる

    •  

  • IPアドレスとMACアドレスには異なる役割がある

    •  

  • 外部ネットワークへ送るフレームは、まずルーターへ届けられる

    •  

  • ARPを使うと、IPv4アドレスに対応するMACアドレスを調べられる

    •  

  • ARPの結果はキャッシュされ、毎回問い合わせる必要はない

    •  

  • ARPキャッシュを削除すると、再び問い合わせが発生することがある


これまで『3分間ネットワーク基礎講座』を読みながら、

レイヤー2やレイヤー3について勉強してきました。


しかし、文字だけでは理解できなかったことが、

実際の通信を見ることで少しずつ分かってきました。


60歳からの勉強ですが、こういう発見があると楽しくなります。


もちろん、まだまだ分からないことばかりです。（笑）


でも、少なくとも今回は、

「IPアドレスだけで通信しているわけではない」

ということを、自分の目で確認できました。


次回は、ネットワーク通信を画面で詳しく分析できる

Wiresharkにも挑戦してみたいと思います。


60歳からのホワイトハッカーへの道、まだまだ続きます！



※今回の実験について

この記事では、自分が管理するMacと自宅ネットワークで通信を観察しています。

パケットキャプチャにはIPアドレスやMACアドレスなどの情報が含まれるため、

取得したデータの公開や取り扱いには注意が必要です。