Last-Modified: 2006/6/4
いますぐ実践! Linux システム管理 / Vol.060 / 読者数:827名
こんばんは、うすだです。
今日、子どもの友だちが、わが家へ遊びに来ていました。
当然なのですが、友だちはみな、子どもを呼ぶときには、「うすだ」とか 「うすだくん」とか言うわけですね。
でも、普段名前を呼ばれることのないわたしは、子どもが呼ばれる度に、
心が反応してしまいます。
一瞬、え? 親のわたしになんの用?? …と思ってから、ワンテンポ遅れて、
子どもを呼んでいるということに気がつきます。
という話をよめにしたのですが、まったく共感されませんでした。
わたしは、自意識過剰なのでしょうか。
外面だけでなく、中身も謙虚にならなければ、と思いました。
それでは、今週も、はりきってまいりましょう!
今週のお題 - tcpdump でネットワークを確認する
さて、先週は、tcpdump の使い方について、ご紹介しました。
Vol.059 - tcpdump でネットワークを盗み見る http://www.usupi.org/sysad/059.html
今週は、tcpdump の使用例を、少しご紹介したいと思います。
できましたら、実用的なのかどうかという厳しい目で見るのではなく、生
のパケットを見ることに喜びを見出していただけますと、幸いです。
− − − − − − − − − − − − − − − − − −
まずは、とあるマシンと通信できないときに、tcpdump を使って、原因を 探ってみたいと思います。
そういうときは、traceroute で確認するのが、王道と言えるでしょう。
traceroute を使いますと、宛先までの経路を調べることができますので、
どこまで届いているかということがわかります。
でも、通信できないマシンがサブネット内にあるときは、traceroute では
原因を突き止められません。
ですので、各所で tcpdump を実行して、どこまではパケットが届いている
のかというのを、地道に確認していきましょう。
ここでは、簡単な例として、以下のような環境を想定してみました。
送信元A が宛先B に ping しても返事がない、という状況だとします。
送信元A ------------HUB ------------ HUB ------------ 宛先B
| |
マシンC マシンD まず、送信元A は、宛先B とお話しするために、宛先B の MAC アドレスを
知る必要があります。そのために、ARP 要求をブロードキャストします。
これが届いていないとなると、物理的な問題の可能性が高そうです。
送信元A が宛先B へ ping しようとしているときに、宛先B 上で、以下の
ように tcpdump を実行します。
宛先B# tcpdump arp
...中略...
23:02:48.234799 arp who-has 宛先B tell 送信元A
23:02:48.234855 arp reply 宛先B is-at 00:01:02:03:04:05 ping を実行すると、通常は、上記のように、送信元A からの ARP 要求に 宛先B が応答します。(00:01:02:03:04:05 が MAC アドレスです。)
もし、宛先B に ARP 要求が届いていない場合は、マシンC やマシンD 上で
tcpdump を実行して、どこまで届いているかを確認します。
たとえば、マシンC には届いていて、マシンD には届いていない場合は、
HUB の間のケーブルやポートが怪しそうです。
そうではなく、マシンC にもマシン D にも届いているなら、HUB と宛先B
との間のケーブルや、HUB のポートが怪しいように思われます。
(しかし、そんなときは、他のマシンとの通信もできないと思いますので、
tcpdump を使わなくても、原因は追求できそうですね…。)
さて、ARP のやりとりはできているのに、ping が通らない場合について、 少し考えてみたいと思います。
たとえば、宛先B が ICMP を無視する設定になっていると、以下のように ICMP echo request だけが、虚しく空を舞うことになります。
# tcpdump icmp
...中略...
23:39:23.573873 IP 送信元A > 宛先B: icmp 64: echo request seq 1
23:39:24.588362 IP 送信元A > 宛先B: icmp 64: echo request seq 2
23:39:25.588396 IP 送信元A > 宛先B: icmp 64: echo request seq 3
...後略... これは、宛先B が、パケットフィルタリングで ICMP を受信しない設定に なっているときなどに、起こりえます。
もし、パケットフィルタリングをなにも設定していないなら、簡単に再現
させることができます。
試していいマシン上で以下を設定して、別のマシンから ping します。
# iptables -A INPUT -p icmp -j DROP …再現したでしょうか。
試したら、以下を実行して、もとに戻しましょう。
# iptables -F また、送信元A が ICMP を受信しない設定になっていたり、逆に ICMP を 送信しない設定になっているということも、考えられます。
…といったあたりを、tcpdump で追っかけることができるのではないかと 思います。
− − − − − − − − − − − − − − − − − −
えー、次に、FTP のパケットを tcpdump で眺めてみましょう。
パスワードが生で流れるところを、確認できます。
FTP クライアントか FTP サーバ上で、以下を実行します。
# tcpdump -x -s 0 port ftp
...中略...
23:55:54.883356 IP クライアント.1042 > サーバ.ftp: P 1:12(11) \
ack 53 win 5840 <nop,nop,timestamp 189907676 149446765>
0x0000: 4510 003f 8c1a 4000 4006 2a5a c0a8 01d3 E..?..@.@.*Z....
0x0010: c0a8 0111 0412 0015 a496 4e56 bbf5 802b ..........NV...+
0x0020: 8018 16d0 d252 0000 0101 080a 0b51 c2dc .....R.......Q..
0x0030: 08e8 606d 5553 4552 2074 6573 740d 0a ..`mUSER.test..
...中略...
23:55:55.883271 IP クライアント.1042 > サーバ.ftp: P 12:24(12) \
ack 86 win 5840 <nop,nop,timestamp 189907776 149446916>
0x0000: 4510 0040 8c1c 4000 4006 2a57 c0a8 01d3 E..@..@.@.*W....
0x0010: c0a8 0111 0412 0015 a496 4e61 bbf5 804c ..........Na...L
0x0020: 8018 16d0 c50d 0000 0101 080a 0b51 c340 .............Q.@
0x0030: 08e8 6104 5041 5353 2074 6573 7431 0d0a ..a.PASS.test1..
...後略... TCP の ACK とかが行きかうため、やや見にくいですが、大事なところだけ を抜き出したのが上記です。
1つ目で、ユーザ名が test であること、2つ目で、パスワードが test1 で
あることが、おぼろげにわかるのではないかと思います。
(ちなみに、4510 〜 0111 が IP ヘッダ、0412 〜 最後が TCP です。
クライアントとかサーバとか書いていますが、IP アドレスが丸見えです
ね…気づかなかったことにしてくださいまし。)
TELNET の場合、1文字毎にサーバへ送信されるため、さらに見づらくなり
ますが、やはりパスワードが丸見えであることがわかります。
…が、こちらは、自由課題とさせていただきます。
余力があれば、tcpdump -x -s 0 port telnet を実行してみましょう。
− − − − − − − − − − − − − − − − − −
以上、簡単なわりにごちゃごちゃした文章ではございますが、tcpdump の 使用例をご紹介しました。
適当な例だったかと言われますと非常に心が痛みますが、上記を手がかり として、何らかの応用につなげていただけますと、幸いです。
ほかにも、いろんなプロトコルを眺めてみると、面白いと思います。
SSH はほんとに暗号化されているのかとか、IP じゃないプロトコルのもの
が流れていたら調べてみるとか、好奇心をそそられそうなネタが、現実の
世界にはたくさんありそうですね。(^ε^)
というわけで、ときどきは、tcpdump で生のパケットを眺めて、ほへぇー などと感心してみてくださいまし。
宿題の答え
先週の宿題は、
あなたのアカウントが、tcpdump だけを、パスワードなしで実行できる
ように、sudo の設定を行ってください。 でした。
visudo コマンドを起動して、以下の設定を追加してください。
(以下では、アカウント名を usu としています。)
usu ALL=(root) /usr/sbin/tcpdump はい、それだけです。sudo tcpdump を実行して、実感してください。
sudo に関するネタは、近い過去にやりました。
ご存知ない方は、以下をご覧いただくと、わかるかもしれません。
Vol.052 - 管理者の権限を少しだけ与える
http://www.usupi.org/sysad/052.html
Vol.053 - sudo をカスタマイズする
http://www.usupi.org/sysad/053.html
Vol.054 - /etc/sudoers をすっきりさせる
http://www.usupi.org/sysad/054.html
今週の宿題
今週の宿題は、
tcpdump を使って、POP3 のパケットを眺めてみましょう。 です。
POP3 といえば、MUA がメールを受信するためのプロトコルですね。
プロトコルは RFC1939 で規定されています。
POP3 は TCP の 110番を使いますので、以下のように実行すれば、眺める
ことができます。
# tcpdump -x -s 0 port 110 ただし、APOP じゃないと、パスワードが見えてしまいます。
間違っても、他人のやりとりを盗み見ないようにしてください。
で、中身の解釈を、宿題にしたいと思います。
詳しくやると本題に匹敵してしまいますので、さららっと流す予定です。
あとがき
すみません、先週のあとがきに、間違いがありました。
先週ご紹介した本の URL が、間違っていました。
(特に誰からも指摘はなかったのですが… orz)
子どもが育つ魔法の言葉 www.amazon.co.jp/exec/obidos/ASIN/4569660231/usupiorg-22
ところで、わたしは、usupi.org というドメインを所有しています。
DNS や WWW などのサーバは、友人宅にあるマシンを、無料で間借りして
いるのですが、安定性や諸費用を考慮して、移転を検討しています。
いま、最も有力なのが、レンタルサーバへの移管です。
レンタルサーバといっても、いろんな種類があるようです。
大きく分けると、共用と専用があります。
共用は、1台のサーバを何人か(何十人か?)で使います。DB などさまざまな 機能が最初から豊富に用意されていますが、ログインや root 権限はあり ませんので、設定変更などは、WWW を介して行う必要があります。
かたや、専用は、1台のサーバをひとりで自由に使えます。
root 権限が得られますので、SSH でログインして新たにサービスを立ち
上げるなど、オールマイティになんでもできます。
いろいろやりたいわたくしとしましては、専用サーバを選びたいところで
ありますが、専用と共用では、値段がぜんぜん違います。
共用では、安いところだと月々300円未満からありますが、専用ですと、
安くても月々7千円近くかかります。
(友人とわりかんですので、実際には半額でいいのですが…。)
Xen を使った仮想専用サーバというのもあり、こちらは5千円程度で済む ようなのですが、スペック的にやや問題になりそうな予感です。
おそらく、安い専用サーバでなんとか、というところに落ち着きそうです ので、このあたり面白い話になってきましたら、経緯などをご紹介したい と思います。
ここのサーバはいいよとか、ここはやめたほうがいいなど、情報をお持ち でしたら、ご連絡いただけますと、幸いです。
今週も、ここまで読んでいただき、ありがとうございました。
それでは、また来週に、お会いしましょう!
「いますぐ実践! Linux システム管理」はこちらです。
メルマガの解除、バックナンバーなども、以下からどうぞ。
https://www.usupi.org/sysad/ (まぐまぐ ID:149633)
その他、作者に関するページは、概ね以下にございます。
https://www.usupi.org/kuri/ (まぐまぐ ID:126454)
http://usupi.seesaa.net/ (栗日記ブログ)
https://twitter.com/kuriking/ (twitter)
https://facebook.com/kuriking3 (facebook)
https://jp.pinterest.com/kuriking/pinterest)
https://www.instagram.com/kuri_king_/ (instagram)
