忍者ブログ
[1] [2] [3] [4] [5] [6]

DATE : 2016/08/26 (Fri)
×

[PR]上記の広告は3ヶ月以上新規記事投稿のないブログに表示されています。新しい記事を書く事で広告が消えます。


DATE : 2013/04/20 (Sat)

これまで、tcpdumpなどのパケットキャプチャツールの存在は知っていましたが、それをどのように使うのか、いまひとつイメージが沸きませんでした。そこで、パケットキャプチャについての知識を仕入れようと思い、「実践 パケット解析 第2版」を読みました。代表的なパケットキャプチャツールであるWiresharkの使い方が中心ですが、どこにパケットキャプチャツールを仕掛けるべきか、プロトコルヘッダからパケット解析を行う際のコツ、使用事例まで書かれており、パケット解析を行うノウハウは十分に得られる内容となっていました。本記事では、「実践パケット解析 第2版」を読んで感じたことや興味深かったことを記します。

もともと、パケットキャプチャツールに対してはどこか近寄りがたいイメージがありました。ネットワークに流れる他人のパケットをキャプチャして解析というのは、いかにもクラッカーがすること、のようなイメージを抱いていたのです。

しかし最近、身の回りでネットワークのトラブルを見るにつけ、パケット解析の必要性を感じるようになりました。特定のホストだけインターネットに繋がらないといった、事象の切り分けが容易な場合は、ホストからpingを打ってみる、ホストの設定を見直すなど、ホストの操作だけで事足ります。しかし、全ホストが繋がらない、ネットワークが異様に遅いなど、事象の切り分けが難しい場合は、まず何が原因なのか、調査を行う必要があります。しかし、あちこちのマシンやルータの設定を見直すのでは、時間がかかります。ここでもし、ネットワーク上に流れているパケットの様子を見ることができれば、原因の絞り込みが容易となり、何の設定を見直せば良いのか、見当がつくようになります。

そこで、パケットキャプチャツールを用いたパケット解析の知識を仕入れようと、「実践パケット解析 第2版」を読みました。パケット解析とは何か、どのように行うのかといった問いに答えてくれそうでしたので、この本を選びました。

パケット解析のことをよく知らない自分にとっては、パケットキャプチャツールをネットワークに仕掛ける方法が印象的でした。仕掛ける、といっても様々な方法があり、状況に応じて異なります。基本的には、ネットワーク機器に直接触れることができるか、設定を変更することができるかというところが重要なポイントとなります。もし可能であれば、ポートミラーリングやネットワークタップ、リピーターハブを利用して、パケットキャプチャツールを仕掛けることができます。不可能であれば、ARPキャッシュポイゾニングを用いて、ホストと、スイッチングハブやルータとの間に割り込んでパケットキャプチャツールを仕掛けることになります。

本書の中心はWiresharkの使い方ですが、スクリーンショット付きで説明されており、わかりやすく書かれています。Wiresharkはオープンソース、マルチプラットフォームのパケットキャプチャツールで、パケットのプロトコルを解析し、ヘッダを分かりやすく表示するだけでなく、フィルタリング機能や統計表示機能など、パケットを解析する支援機能も充実しています。特にフィルタリング機能では、独自の構文を用いて検索条件を作成することができ、ヘッダの各要素レベルで条件を作成可能です。ネットワーク上では大量のパケットが流れるため、検索条件の善し悪しが解析作業の効率を左右すると感じました。

使用事例も記載されているため、初めてパケット解析を行う際には心強い味方となりそうです。ネットワークに繋がらないといったネットワークトラブルから、不正な侵入を受けた場合の解析など多岐にわたった事例が紹介されています(ただし、不正な侵入を受けた場合の解析は、それだけで奥深いテーマのため、本書では触り程度に触れられています)。ネットワークトラブルの場合は、まず異常な状態と正常な状態を区別するため、ベースラインとなる状態を定めておくべきである、という主張が繰り返しなされていたのが印象的でした。確かに、トラブルの有無にかかわらず、ネットワーク上にはパケットが流れ続けているわけですから、ベースラインとなる状態を定めておかないと、何と比較して異常な状態と判断するのか、基準がなくなってしまいます。

このように、基本から丁寧に説明されているため、パケット解析のノウハウが一通り得られたように思えました。実際にパケット解析を行う場面となった際には、本書を片手に頑張ってみようと思います。もっとも、企業でパケットキャプチャツールを使用する場合は、企業のセキュリティポリシー上、インストールや使用が禁止されている場合があるため、関連部署との調整が必要不可欠ではありますが……。

PR

DATE : 2013/03/14 (Thu)

Javaソースコードのカバレッジ計測ツールのEMMAには、HTMLレポートの生成時にJavaソースコードの文字エンコーディングを指定する機能がありません。そこで、HTMLレポート生成時に、ソースコードの文字エンコーディングを指定できるようにしたパッチを作成しました。パッチは本家に投稿済みであり、Android SDK版についてはGitHubにもアップロードしています。

現在最新バージョンのEMMA(2.0.5312)では、HTMLレポートを生成する際に、ソースコードの文字エンコーディングを指定することができません。プラットフォームのデフォルト文字エンコーディングがソースコードの文字エンコーディングとして使用されるため、両者が一致していない場合はHTMLレポートが文字化けしてしまいます。例えば日本語版Windowsのデフォルト文字エンコーディングはShift JISのため、それ以外の文字エンコーディングで書かれたソースコードからHTMLレポートを生成すると、文字化けしてしまいます。

そこで、ソースコードの文字エンコーディングを指定できるようにしたパッチを作りました。本パッチを適用したEMMAでは、以下のいずれかの方法でソースコードの文字エンコーディングを指定することができます。

  1. EMMA report generation property」としてreport.source.encodingキーを追加したため、その値として文字エンコーディングを指定する。
  2. Ant向けに、html要素にsourceencoding属性を追加したため、その値として文字エンコーディングを指定する。

本パッチは、本家に投稿済みです。また、Android SDKに含まれているEMMAについても本パッチを適用し、結果をGitHubにアップロードしましたEMMAプロジェクトは現在休止中であるため、マージが待てない方は本パッチをご自由に(ただし自己責任で)お使いください。


DATE : 2013/01/26 (Sat)

ビルド時にJDK 1.4が必要なライブラリをビルドしようと64ビット版XubuntuにJDK 1.4をインストールしようとしたのですが、「./install.sfx.8648: not found」というエラーメッセージとともにインストーラが停止してしまいました。x64用Linux版JDK 1.4はOracleのサイトのアーカイブにはなく、x32用しかありません。そのためx32用JDKをダウンロードしてインストーラを実行したのですが、「./install.sfx.8648: not found」というエラーメッセージが出力され、インストールできなかったのです。

そこで調べてみると、g++-multilibパッケージをインストールすると32ビット用JDKを64ビット版Linuxにインストールできることがわかりました。g++-mutilibとは、g++に標準で備わっているアーキテクチャのサポートをさらに追加するためのパッケージで、このパッケージをインストールすることで64ビット版Linuxでも32ビット向けプログラムをビルドできるようになります。

実際にg++-multilibをインストールし、再びJDK 1.4のインストーラを起動したところ、無事にJDK 1.4をインストールできました。前述のライブラリのビルドにも成功しました。

参考文献


DATE : 2012/10/10 (Wed)

Androidアプリの開発でテスト用のスクリプトを書いていると、特定のログが出力されるまで待機したい、ということがあります。しかし、Android SDK Revision 20の時点では、adbにはそのような機能はありませんし、monkeyrunnerにもそのようなAPIはありません。

そこで、指定したログがlogcatから出力されるまでスクリプトを待機させるPythonモジュールを作りました。以下のように使うと、Activityが起動するまで待機できます。

import logmatcher

logmatcher.start()

# ... (Activityの起動)

logmatcher.wait(
    'START {act=android.intent.action.MAIN cat=[android.intent.category.LAUNCHER]')

以下の環境でスクリプトは動作します。

  • Python 2.7
  • monkeyrunner (Android SDK Revision 20以上)
  • Jython 2.5

GitHubでスクリプトを公開しています。「Downloads」からアーカイブをダウンロードしてください。ライセンスはApache License, Version 2.0です。

特定の文字列がログに現れるのを待機するほかに、特定の正規表現パターンにマッチする文字列がログに現れるのを待機することもできます。詳しくは、READMEをご覧ください。


DATE : 2012/02/23 (Thu)

Javaでは、メソッドやクラスなどをパッケージスコープとする際にアクセス修飾子を省略します。しかしソースコードの作者以外の人から見ると、アクセス修飾子を省略したのかそれとも書き忘れたのか、判断できません。そこでパッケージスコープであると明示的に示そうと、「/* package */」のようなコメントをアクセス修飾子がない代わりに入れることがあります。例えば、パッケージスコープなメソッドは次のように書きます。

    /* package */ void method() {
        ...
    }

Eclipseの一部やAndroidに標準搭載されているブラウザアプリケーションや設定アプリケーションなどがそのようなコーディングルールで記述されています。

Javaで書かれたソースコードがコーディング規約に従っているかどうかをチェックする際には、Checkstyleがよく使用されます。しかし、本記事の執筆時点の最新バージョンであるCheckstyle 5.5では、パッケージスコープを表すコメントの有無をチェックできません。

そこで今回、パッケージスコープを表すコメントの有無をチェックするCheckstyleプラグインを作ってみました。GitHubで公開しています。ライセンスはCheckstyleと同じLGPLです。Checkstyle 5.5以上に対応しています。

本プラグインでは、アクセス修飾子のないクラスなどの定義にパッケージスコープを表すコメントが書かれていることをチェックし、書かれていなければ警告します。加えて、アクセス修飾子が書かれているにもかかわらず以下のようにパッケージスコープを表すコメントがある場合に警告を行います。

    /* package */ public void method() {
        ...
    }

使い方は次の通りです。まず、Checkstyleの設定ファイルに本プラグインのモジュールを追加します。本プラグインのモジュールは、TreeWalkerモジュールのサブモジュールです。例えば、次のようになります。

  <module name="TreeWalker">
    <module name="CommentedPackageVisibilityCheck" />
  </module>

クラスパスに本プラグインのJARファイルを追加して、Checkstyleを実行してください。

JARファイルは、「commented-package-visibility-check-0.1.zip」をダウンロードして展開すると手に入ります。

CommentedPackageVisibilityCheckモジュールには、以下のプロパティを用意しています。必要に応じて設定してください。

プロパティ名 説明 省略時の値
format パッケージスコープを表すコメントにマッチする正規表現。 /\* package \*/
requireLatterWhiteSpace パッケージスコープを表すコメントの直後に、少なくとも1文字以上の空白が必要か。 true
忍者ブログ [PR]
ブログ内検索
最近の状況
リンク
カレンダー
07 2016/08 09
S M T W T F S
1 2 3 4 5 6
7 8 9 10 11 12 13
14 15 16 17 18 19 20
21 22 23 24 25 26 27
28 29 30 31
使用許諾
最新コメント
(08/15)
(05/04)
(03/06)
(03/04)
(09/25)
最新トラックバック
T/O
(11/05)
ブログ内検索
最近の状況
リンク
カレンダー
07 2016/08 09
S M T W T F S
1 2 3 4 5 6
7 8 9 10 11 12 13
14 15 16 17 18 19 20
21 22 23 24 25 26 27
28 29 30 31
使用許諾
最新コメント
(08/15)
(05/04)
(03/06)
(03/04)
(09/25)
最新トラックバック
T/O
(11/05)