DATE : 2013/04/20 (Sat)
これまで、tcpdumpなどのパケットキャプチャツールの存在は知っていましたが、それをどのように使うのか、いまひとつイメージが沸きませんでした。そこで、パケットキャプチャについての知識を仕入れようと思い、「実践 パケット解析 第2版」を読みました。代表的なパケットキャプチャツールであるWiresharkの使い方が中心ですが、どこにパケットキャプチャツールを仕掛けるべきか、プロトコルヘッダからパケット解析を行う際のコツ、使用事例まで書かれており、パケット解析を行うノウハウは十分に得られる内容となっていました。本記事では、「実践パケット解析 第2版」を読んで感じたことや興味深かったことを記します。
もともと、パケットキャプチャツールに対してはどこか近寄りがたいイメージがありました。ネットワークに流れる他人のパケットをキャプチャして解析というのは、いかにもクラッカーがすること、のようなイメージを抱いていたのです。
しかし最近、身の回りでネットワークのトラブルを見るにつけ、パケット解析の必要性を感じるようになりました。特定のホストだけインターネットに繋がらないといった、事象の切り分けが容易な場合は、ホストからpingを打ってみる、ホストの設定を見直すなど、ホストの操作だけで事足ります。しかし、全ホストが繋がらない、ネットワークが異様に遅いなど、事象の切り分けが難しい場合は、まず何が原因なのか、調査を行う必要があります。しかし、あちこちのマシンやルータの設定を見直すのでは、時間がかかります。ここでもし、ネットワーク上に流れているパケットの様子を見ることができれば、原因の絞り込みが容易となり、何の設定を見直せば良いのか、見当がつくようになります。
そこで、パケットキャプチャツールを用いたパケット解析の知識を仕入れようと、「実践パケット解析 第2版」を読みました。パケット解析とは何か、どのように行うのかといった問いに答えてくれそうでしたので、この本を選びました。
パケット解析のことをよく知らない自分にとっては、パケットキャプチャツールをネットワークに仕掛ける方法が印象的でした。仕掛ける、といっても様々な方法があり、状況に応じて異なります。基本的には、ネットワーク機器に直接触れることができるか、設定を変更することができるかというところが重要なポイントとなります。もし可能であれば、ポートミラーリングやネットワークタップ、リピーターハブを利用して、パケットキャプチャツールを仕掛けることができます。不可能であれば、ARPキャッシュポイゾニングを用いて、ホストと、スイッチングハブやルータとの間に割り込んでパケットキャプチャツールを仕掛けることになります。
本書の中心はWiresharkの使い方ですが、スクリーンショット付きで説明されており、わかりやすく書かれています。Wiresharkはオープンソース、マルチプラットフォームのパケットキャプチャツールで、パケットのプロトコルを解析し、ヘッダを分かりやすく表示するだけでなく、フィルタリング機能や統計表示機能など、パケットを解析する支援機能も充実しています。特にフィルタリング機能では、独自の構文を用いて検索条件を作成することができ、ヘッダの各要素レベルで条件を作成可能です。ネットワーク上では大量のパケットが流れるため、検索条件の善し悪しが解析作業の効率を左右すると感じました。
使用事例も記載されているため、初めてパケット解析を行う際には心強い味方となりそうです。ネットワークに繋がらないといったネットワークトラブルから、不正な侵入を受けた場合の解析など多岐にわたった事例が紹介されています（ただし、不正な侵入を受けた場合の解析は、それだけで奥深いテーマのため、本書では触り程度に触れられています）。ネットワークトラブルの場合は、まず異常な状態と正常な状態を区別するため、ベースラインとなる状態を定めておくべきである、という主張が繰り返しなされていたのが印象的でした。確かに、トラブルの有無にかかわらず、ネットワーク上にはパケットが流れ続けているわけですから、ベースラインとなる状態を定めておかないと、何と比較して異常な状態と判断するのか、基準がなくなってしまいます。
このように、基本から丁寧に説明されているため、パケット解析のノウハウが一通り得られたように思えました。実際にパケット解析を行う場面となった際には、本書を片手に頑張ってみようと思います。もっとも、企業でパケットキャプチャツールを使用する場合は、企業のセキュリティポリシー上、インストールや使用が禁止されている場合があるため、関連部署との調整が必要不可欠ではありますが……。
DATE : 2008/03/29 (Sat)
「The Art of UNIX Programming」（Eric S.Raymond 著、長尾高弘 訳、アスキー、2007）を読みました。UNIX の設計やそれをとりまくコミュニティの伝統から、「UNIX では、なぜそうなっているのか」を解説する本です。
こういった、これまでにあるものを例として、その本質を抜き出して解説するという本は珍しかったので、面白かったです。特に、テキスト形式のデータの重要性を説いた部分では、実際に使われているデータファイルや、POP3 などの通信プロトコルを例として具体的に説明しています。さすがに、長年使われてきただけあって、説得力がありました。
また、マルチスレッドプログラミングに関しても面白い記述がありました。マルチスレッドプログラミングのやっかいな問題として、スレッド間で共有されているデータが挙げられます。書き換えられるタイミングを調整するのがとても難しいため、本書ではマルチプロセスへの分割を推奨しています。例えば、サーバとクライアントに分けられる場合は、サーバプロセスとクライアントプロセスに分割してプロセス間通信を行うことで、データの保護を行います（例として、PostgreSQL や X サーバなどが挙げられています）。
本書によると、そもそも UNIX の世界にはマルチスレッドの考え方がなかったようです。そのため、普段 Windows を使っている身としてはこの部分は非常に驚きました。確かに、マルチスレッドとは異なり、マルチプロセスの場合は、データへのアクセス方法がプロセス間通信に限られます。まさに、情報隠蔽の考え方だと思いました。
また、オープンソースに関わる方法についても触れられています。例えば、SourceForge などからダウンロードしたパッケージを展開すると、だいたい似通ったディレクトリ構成になっていることに気づきます。この構成は長年培われてきたもので、その意味やその理由について詳しく述べられています。また、パッチの送り方などにも触れられており、オープンソースに関わる際には貴重な指針となりそうです。
実際に使われているアプリケーションや言語などを基に解説されているため、例に用いられている中には、すでに古いものもあります。しかし、そこから抽出された本質はなかなか変わるものではありません。そのため、記述されているアプリケーションがこれから使われなくなったとしても、当分は役に立つ本と言えそうです。
DATE : 2008/02/11 (Mon)
「デバッガの理論と実装」（Jonathan B.Rosenberg著、吉川邦夫訳、アスキー、1998）を読みました。デバッガのアルゴリズムや、各種OSのデバッグ API について述べられた本です。
デバッガには常々お世話になっており、その動作が気になっていたのですが、実際にはかなり細々としたことを行っていました。
例えば、ブレークポイントを設定して、デバッギ（デバッガによってデバッグされるプログラムのこと）の動作を途中で止めるには、ブレークポイントの対象となっているメモリ内の命令を、CPU のブレークポイント命令に置き換えることで行っています。処理の再開は、置き換えた命令を元の命令に戻すことで行います。シングルステップ実行も似たようなもので、命令を実行する前に、次の命令をブレークポイント命令に置き換えます。そしてブレークポイントで処理が停止したら、置き換えた部分を元の命令に戻し、次の命令をブレークポイント命令に置き換え……という処理を繰り返します。
つまり、デバッガはデバッギのあるメモリを様々に操作することで、デバッグを実現していると言えます。
ところが、これではデバッギの実行は、通常の実行時とメモリの状態が異なることになります。本書でも「デバッガの諸原則」（p.26～）で述べられていますが、計測によって実際の状態が乱れてしまう「ハイゼンベルク効果」が現れてきます。つまり、通常の実行時には現れていたバグがデバッグ時には消えたり、その逆もありうるのです。この影響の度合は、デバッグ API を提供する OS によって異なりますが、デバッガが存在する限り、ゼロにはできません。同時に実行されるプロセスが1つ増えることで、命令の実行順序やイベントの送信順序も変化するためです。そのため、バグによってはデバッガでも捕らえきれないものが存在します。
これはとても勉強になった部分でした。デバッガというと、動作が神秘的でできないことはないような気がしていました。しかし、デバッガのアルゴリズムを知ることで、その限界も知ることができたような気がします。
（；^ω^）これからも、デバッガとは良いお付き合いをしていきたいと思います。
DATE : 2008/01/05 (Sat)
「ヒューメイン・インタフェース」（ジェフ・ラスキン：著、村上 雅章：訳、ピアソン・エデュケーション、2001）を読みました。人に優しいインタフェースについて、マッキントッシュのプロジェクトを立ち上げた人物が書いた本です。
本書では、マッキントッシュやCanon Catなど、ジェフ・ラスキン本人の手がけた製品のユーザインタフェースを中心に解説しています。中でも、モードをなくすことやアイコン多用の厳禁、GUI への批判などが繰り返し出てきます。
Canon Cat は海外のみで発売されたものらしく、私も本書を読むまでは存在すら知りませんでした。が、電源を落とす前に現在の画面を画像として保存しておいて、次回の電源投入時には立ち上げが完了するまでその画像を表示しておくなど、非常に面白いハードだと思いました。本書によると、状況に応じて人が頭を切り替えるのには約10秒かかるそうです。そのため、次回の電源投入時に終了直前の画面を表示しておくと、立ち上がり完了とともに人が作業を再開できるようになると言います。
その一方で、Canon Cat は、思わず顔をしかめてしまいそうなほど「直感」とはほど遠いインタフェースとなっています。Canon Cat にはマウスはなく、ディスクのフォーマットからメールの送信まで全てキーボード操作で行います。また、GUI はなく、全てテキスト上で完結するインタフェースとなっています。
これだけ見ると、どこが人に優しいのか疑問になってきます。ところが、著者はこれこそが人に優しいインタフェースなのだと主張しています。まず、よくユーザインタフェースの評価で言われる「直感的」というのはしょせん「これまでに見たことがある」ものに過ぎず、ユーザの国籍やこれまでの経験などによって解釈が変わりうるそうです。そして、これまでに見たことがある = 人に優しいとは限らず、本当に人に優しいのは、教育のしやすいインタフェースであり、ユーザの作業の邪魔をしないインタフェースであると述べています（実際にはさらにいろいろと述べていますが、省きました）。
しかし、これはなかなか難しい問題といえます。例えば、見ただけで嫌になりそうなインタフェースの製品を買いたいかというと、正直いって私は買いたくありません。かといって、見た目が良さそうなので買ってみたら、思うように操作できずイライラする……ということも珍しくありません。
結局のところ、その製品でなにを重視するかが問題となってくるのだと思います。例えば、長期間、頻繁に使われるような製品であれば、ユーザが快適に作業できるインタフェースが必要となりますが、時々しか使われない製品であれば、目で見て使い方が分からないと不便です。また、既存の製品に対抗する場合には、その製品のインタフェースに似せて、ユーザが移行しやすいようにする必要もあります。Canon Cat の場合は、ユーザの快適さに重視を置いたため、一見するとややこしいインタフェースになっているのでしょう。
（；^ω^）私の身近な例では、vi エディタが該当するかと思います。キーボード操作だけでテキストの編集ができる反面、とっつきはかなり悪いものとなっています。全ての操作はとても覚えきれません。ただ、一部の操作だけでもじゅうぶん快適に使えますし、なによりキーボードから手を離さなくてもいいという点は魅力です。もっとも、人に強くおすすめできるかというと、とっつきが悪い以上なかなか難しいと思います。
DATE : 2007/12/13 (Thu)
「プログラミング作法」（Brian W.Kernighan, Rob Pike著、福崎俊博訳、アスキー、2000）を読みました。プログラムを書く際のスタイルや、プログラミングの際の心構えなどについて書かれた本です。
以前、「Code Complete 第2版 ――完全なプログラミングを目指して」を読んだことがあったので、頭の中で「Code Complete」と比較しながら読みました。「Code Complete」と比べると、「プログラミング作法」はプログラミングを始めた人も対象とした内容となっています。そのため、手続き型言語やスクリプト言語を中心に取り上げています。また、前者がコードの書き方に重点を置いていたのに対し、後者はコードの書き方から始まってアルゴリズムやリソース管理の方法など、プログラミング全般に渡っています。
両者を見比べてみると、細かい点で違いが見つかります。個人的に最も目に付いたのは、変数名の付け方でした。「プログラミング作法」では、グローバル変数は長くフルスペルで、ローカル変数は短く省略形でという名付け方が推奨されています。しかし、「Code Complete」では特にグローバル変数は、ローカル変数はという違いには触れておらず、ただ単にフルスペルで長く名付ける方法が推奨されていました。グローバル変数、ローカル変数にかかわらずという表現ではなかったので、本当のところは分からないのですが、私としてはグローバル変数、ローカル変数に関わらず、名前はフルスペルで長く付ける方法の方が良いと思います。
（；^ω^）ただ、ここから思うのは、コードを書く作法は決まりきっていないということですね。「Code Complete」にしても「プログラミング作法」にしても、名著と呼ばれている本ですが、細かい部分では著者の考え方によって違いが出てくるわけです。結局のところ、コードの書き方は、コードを書く度にしっかりと考えていかなければならないようです。
