« 2010年10月 | トップページ | 2010年12月 »

2010年11月の6件の記事

2010年11月26日

Linuxログファイル全世代を連結するスクリプト(PowerShell、Perl)

Linuxのログファイル(messagesなど)は、一定条件を満たすと、世代を表す拡張子(.0、.1)を付加してgzipで圧縮される。これがひとつのテキストファイルになっていた方がログを解析に都合がいいときがある。DOSプロンプトのcopyコマンドなら、

copy messages.3 + messages.2 + messages.1 + messages.0 + messages messages.txt

のように「+」でファイルを連結できる。欠点は、システムやログファイルによって世代数が変わるので、いちいちファイル名を入力しなければならないことだ。タブキーでファイル名を補完すればキータイプ回数を減らせるが、それでも面倒だ。スクリプトで自動化してみた。

DOSプロンプトのバッチファイルは「過去の遺物」であるので、PowerShellで作ってみた。正規表現やforeachが使えるのが非常によい。


# messages*ファイルを収集して、世代番号を配列に入れる。
$files = Get-ChildItem messages*| Where-Object {$_.Extension -match ".[0-9]+"} | foreach ($_) {$_.extension -replace "\.", ""}

#配列内の世代番号を数値型に変換する。
for ($i = 0; $i -le $files.Length - 1; $i++) { $files[$i] = $files[$i] -as [Int32] }

#世代数(世代番号の最大値)を求める。
$max = $files[0]
for ( $i=1; $i -le $files.Length; $i++) { if ($files[$i] -gt $max) { $max = $files[$i] } }

#一番古いものから順番にmessages.txtファイルへ書き出す。
#ログファイルはASCII文字だけという前提。日本語を含む場合はUnicodeを指定する。
for ($i=$max; $i -ge 0; $i--) { Get-Content "messages.$i" | Out-File messages.txt -Encoding ASCII -Append}

#最新世代のファイルを連結する
Get-Content messages | Out-File messages.txt -Encoding ASCII -Append}

Unicodeで出力した場合、英数字もUnicodeに変換され、ファイルサイズがオリジナル総計の約2倍になる。また改行文字もLinuxのLFからLF+CRに変換される。

ついでにPerlで書いてみた(注)。


use strict;
use utf8;

# messages*ファイルを収集して

my @files = do {
  opendir my $dir, '.' or die ("Cannot open the current directory");
  my @f = grep /messages\.[0-9]+/, readdir($dir);
  closedir $dir;
  @f;
};

# 世代番号を配列に入れる。
foreach my $gen (@files) {
	$gen =~ s/messages\.//g;
}

# 拡張子の最大を求める。

my $max = $files[0];

for (my $i = 0; $i < @files; $i++) {
	if ($files[$i] > $max) {
		$max = $files[$i];
	}
}

#一番古いものから順番にmessages.txtファイルへ書き出す。

open (OUT, ">messages.txt");

for ( my $i = $max; $i >= 0; $i--) {
	open (IN, "messages.$i");
	while (

) {
print OUT;
}
close IN;
}

#最新世代のファイルを連結する
open (IN, "messages");
while (

) {
print OUT;
}
close IN;
close OUT;

これもやはり改行文字がLinuxのLFからLF+CRに変換される。メッセージ本文はオリジナルの文字コードのままである。

(注)ファイル収集の処理は小飼弾氏のコードをお借りした。

perl - glob,readdir, and regexp
http://blog.livedoor.jp/dankogai/archives/51058540.html

| | コメント (3)

2010年11月22日

Firesheepと無線LANカードの相性

誰でも簡単に他人のTwitterやFacebookのセッションを乗っ取れるFiresheepだが、無線LANカードとの相性がある。自分宛以外の無線LAN通信パケットを捕捉するには、プロミスキュアスモード(promiscuous mode)をサポートしていなければならないし、プロミスキュアスモードをサポートしている無線LANカードでもうまく傍受できないことがある。FiresheepのGoogleグループには、どの無線LANカードが使えてどれが使えないというスレッドがある。

List of Wifi chipsets
https://groups.google.com/group/firesheep/browse_thread/thread/eb1438219981f7d6

たとえばThinkPad T42が内蔵しているインテル2200BGは、プロミスキュアスモードをサポートしていないので、Firesheepを起動するとエラーになってしまう。ThinkPad X201のインテル6250ABNは、プロミスキュアスモードをサポートしているように見えて、Firesheepは起動するが、実際にはパケットをキャプチャできない。Wiresharkでも同様で、キャプチャできるのは自分宛のパケットと、ブロードキャストとおよびマルチキャストのパケットだけだ。インテルのプロミスキュアスモードは、特定ISVだけに開放しているのではないだろうか。以下のホワイトペーパには、3945ABGとAirMagnetの組み合わせでパケットキャプチャができると書いてある。

Managing Wireless Clients with the Administrator Tool
http://www.intel.com/network/connectivity/products/whitepapers/admin_tool_wp.pdf

MacBookも機種による。私の13インチMacBook(MacBook 2,1)ではだめだ。この機種はAtheosの無線LANチップを内蔵している。MacBookは2008年後半にAtheosからBroadcomに無線LANチップを変更したらしい。BroadcomのチップはFiresheepが正常動作するようだ。

AirPort(Wikipedia)
https://secure.wikimedia.org/wikipedia/en/wiki/AirPort

The particular brand and model of card has changed over the years; in early models, it was Atheros brand, while since late 2008 they have been Broadcom cards.

したがって、公衆無線LANスポットに自分のPCを持っていってFiresheepを起動し、他の人のセッションがひとつも見つからないからといって、その無線LANスポットが安全だなどと考えてはいけない。WPAやダイナミックWEP以外の公衆無線LANは、基本的に第三者傍受ができるものである。正しい装備を持った人であれば、他人の通信を完璧に盗聴することができる。盗聴を防ぐには、サーバとの間の通信をSSLで暗号化する必要がある。

| | コメント (0)

HTTPSを強制するFirefoxアドオン(HTTPS EverywhereとForce-TLS)

Firesheepなどの第三者傍受から身を守るには、サーバとの通信を暗号化するのが根本的な解決である。TechCrunchの「FiresheepからWiFiでログイン情報を守る方法」は、FirefoxアドオンのForce-TLSとHTTPS Everywhereを紹介している。

もともとForce-TLSは、WebサイトがStrict-Transport-Security HTTPヘッダを送ってきたときにSSLを強制するものだが、バージョン2.0から自分でサイトを追加できるようになった。たとえば、*.instapaper.comを追加してhttp://www.instapaper.comに接続すると、通信はHTTPで行われて、アドレスバーもhttps://www.instapaper.comに変わる。しかしhttp://instapaper.comは変換してくれない。満了日が1年先に設定されるのも少々不安だ。1年後にもう一度定義し直さなければいけないのだろうか。それはちょっと面倒だ。きっと忘れてしまう。

HTTPS Everywhereは、正規表現を使って自分でルールを書けば、任意のサイトでHTTPSを強制できる。以下のルールを定義すると、http://instapaper.comもhttp://www.instapaper.comもHTTPS接続に変換できる。こちらのほうが自由度が高いのでお勧めだ。

<ruleset name="Instapaper">
  <rule from="^http://instapaper\.com/" to="https://www.instapaper.com/"/>
  <rule from="^http://(www\.)?instapaper\.com/" to="https://www.instapaper.com/"/>
</ruleset>

(参考記事)

FiresheepからWiFiでログイン情報を守る方法(TechCrunch)
http://jp.techcrunch.com/archives/20101025firesheep/

(2010/11/24追記)
HTTPS Everywhereのバージョン0.3.0以降は<target>を指定しなければならない。これに対応したルールは以下のようになる。Twitterのルールを参考にして、<securecookie>も書いておいた。

ルールをHTTPSEverywhereUserRulesディレクトリに保存したあと、アドオンの設定画面でInstapaperにチェックが入っていることを確認しておく。もし設定画面にInstapaperが表示されないときは、ルールにエラーがある。Firefoxのエラーコンソールに何か表示されているはずだ。

<ruleset name="Instapaper">
  <target host="*.instapaler.com" />
  <target host="instapaper.com" />

  <securecookie host="^(.*\.)instapaper\.com$" name=".*" />

  <rule from="^http://instapaper\.com/" to="https://www.instapaper.com/"/>
  <rule from="^http://(www\.)?instapaper\.com/" to="https://www.instapaper.com/"/>
</ruleset>

(2011/01/27追記)
FacebookがフルHTTPSに移行する。アカウント設定でチェックを付ければ、パスワードなどの認証部分だけでなく、全ての通信がHTTPSになる。
A Continued Commitment to Security
http://blog.facebook.com/blog.php?post=486790652130

| | コメント (0)

公衆無線LANのセキュリティはかなりお寒い

Firesheepが公開されて、公衆無線LAN内の他人のTwitterやFacebookのセッションを誰でも簡単に乗っ取る(sidejack)ことができるようになってしまった(参考記事1)。

ソフトバンクモバイルが無料で配布しているせいか、最近あちこちで電波を見かけるFONは通信を暗号化していない。Firesheepの格好の餌食である。

WEPを使っている公衆無線LANも危険だ。アクセスポイントのWEPキー(パスワード)は公開されていて、そのキーをもとに全クライアントに共通の鍵を生成して暗号化する。これは暗号化していないのと同じだ。「通信内容を暗号化することでセキュリティーを強化」とホームページなどで喧伝している公衆無線LANサービスもあるが、それがWEPなら虚偽広告といって構わない。

NTT系の公衆無線LAN(ホットスポット、Mzone、フレッツ・スポット)は、IEEE802.1X認証によってクライアントごとの個別鍵を動的に生成するダイナミックWEPが使える。個別鍵に加えて、鍵を定期的に更新しているらしい。ダイナミックWEPであれば多少なりとも安全かもしれないが、更新の間隔が公開されていない。WEPは1分以内に破られてしまうから、どの程度防御されているか判断できない。また802.1X認証はオプション扱いだったり、専用のクライアントソフトをインストールしなければならなかったりする。何もせずに接続すれば共通鍵のWEPである。

いちばんも安心なのはWPA/WPA2である。しかし公衆無線LANサービスでこの方式を使っているものは少ない。私が調べたかぎりでは、ワイヤ・アンド・ワイヤレスのWi2 300がサポートしている。しかし「ローミングエリア、バス車内、および一部店舗においては、WPA/WPA2(802.11i)に対応しておりません。 ご了承ください」とのこと。つまりWi2 300独自のアクセスポイントだけでWPA/WPA2が使えるようなのだが、エリアが狭くて話にならない。大多数はBBモバイルポイントやlivedoor Wirelessのローミングである。

このように公衆無線LANのセキュリティはかなりお寒い状況なので、自分の身は自分で守るしかない。HTTPS(SSL)でサーバとの通信を暗号化するのが必須である。

(参考記事)
Twitter、Facebook、Dropbox、Evernote、全部危ない―WiFiでログイン情報を盗み取れるFirfoxアドオンFiresheep(TechCrunch)
http://jp.techcrunch.com/archives/20101024firesheep-in-wolves-clothing-app-lets-you-hack-into-twitter-facebook-accounts-easily/

| | コメント (0)

iPhoneアプリの通信をパケットキャプチャ

写真共有SNS「Instagram」のiPhoneアプリが、パスワードを平文で送信していた(参考記事1)。最新版1.0.4で修正されたというので、本当に直っているかどうかを確認するため、パケットキャプチャを取った。Webブラウザで使うサービスなら、通信が暗号化されているかどうかをブラウザの鍵アイコンで判別できる。しかしアプリは簡単に判別する手段がなく、パケットキャプチャを取るしかない。

iPhoneの通信をパケットキャプチャする方法はいくつか考えられるが、WindowsのICS(インターネット接続共有)を使って、Windows上のWiresharkでキャプチャすることにした。ICS以外に、ARP SpoofingによってiPhoneとADSLモデム間の通信を盗聴する方法や、無線LANの通信を第三者傍受する方法も考えられる。

我が家のネットワークは、ADSLのブロードバンドモデムに無線LANアクセスポイントをブリッジ接続し、PCやiPhoneを無線LANで接続している。無線LANアクセスポイントは4ポートのスイッチングハブを内蔵している。ここにPCを有線接続し、ICSで無線LANと有線LANをルーティングする。

(通常)
インターネット ←→ ADSLモデム ←→ 無線LAN AP ←無線→ iPhoneやPC

(ICS構成)
インターネット ←→ ADSLモデム ←→ 無線LAN AP ← 有線→  PC ←無線→ iPhone

まずPCとiPhoneを無線LANでアドホック接続する。ワイヤレスネットワーク接続のプロパティ→ワイヤレスネットワークで適当なSSIDを追加する。念のためWEPで暗号化しておく。「これはコンピュータ相互(アドホック)のネットワークで、ワイヤレスアクセスポイントを使用しない」をチェックすればアドホック接続用SSIDとなる。「ブロードキャストしていない場合でも接続する」「範囲内にあるとき接続する」もオンにしておく。この時点でPCの無線LANインタフェースにはIPアドレスが割り当てられていない。アドホックの無線LANのSSIDがiPhoneから見えて接続できるが、通信はできない。

次にICSを設定する。Windows XPの場合、ローカルエリア接続のプロパティ→詳細設定で「インターネット接続の共有」にチェックを入れればよい。

ファイアウォールが有効になっていると、パケットのルーティングができない。ファイアウォールの詳細設定で、特定のインタフェースだけ有効/無効にすることができるようだ。これを試してみる価値はあるが、今回はPC全体で無効とした。我が家のネットワークはNATルータを経由しているので、外部からの攻撃はブロックできるはずだ。もちろんパケットキャプチャが終わったらすぐ有効に戻しておく。

有線LAN側でICSを有効にすると、無線LAN側に192.168.0.1/255.255.255.0のIPアドレスが自動的に割り当てられる。このアドレスは変更できない。困ったことにADSLモデムと重複してしまう。やむなくADSLモデムを192.168.1.1に変更した。ユーザからの声が多かったのか、Windows 7で192.168.1.137に変更されたようだ。

これでiPhoneからの通信をルーティングできるはずだが、一度リブートした方がよい。リブートするまでICS用のDHCPサーバが正常に動作しないことが何回かあった。リブート後にPCとiPhoneの両方を上で設定したSSIDに接続すると、192.168.0.xxxがiPhoneに割り当てられる。ゲートウェイとDNSサーバは192.168.0.1になっているはずだ。

あとはiPhoneでアプリを起動して通信し、そのパケットをWiresharkでキャプチャすればよい。以前のバージョンのInstagramは確かにパスワードを平文で送信していた。1.0.4(注)はログイン時の通信をSSLで暗号化していて、ユーザ名やパスワードが盗聴できなくなっていいる。これで安心だ。

(注)App Store上の表記。アプリのAbout画面ではv1.9.5。

TechCrunchの記事はこう書いている。

FoursquareとGowallaにもまったく同一の問題があった。同様の欠陥がある無名のiPhoneアプリとなれば数えきれないほどだろう。

日本でも2008年12月に高木浩光氏が指摘していた(参考記事2)。

このように、(Webブラウザの場合では、WebサイトがちゃんとSSLを使っているかどうかは利用者が目視で確認することができたのに対し、)個別に作られたアプリケーションの場合は、それがちゃんと暗号化を施しているかどうかは、通信を傍受するなどして確かめてみないとわからないという問題がある。

アプリの通信を暗号化するかどうかは、開発者の判断やセキュリティ意識に任されている。SDKが暗号通信を強制したり、App Storeが審査基準に加えたりしないかぎり、この手の問題は繰り返すだろう。App Storeにあるアプリをホイホイとダウンロードして、パスワードなど本来秘密にすべき情報を入力するのは、かなり危険な行為である。見られると困る写真をアップロードしているわけではないと言う人がいるかもしれない。しかしパスワードを盗まれてヌード写真などをアップロードされてしまうと、SNS内でその人の評判はあっという間に落ちてしまう。自分がやったのではないと証明したり評判を回復したりするのはそう簡単ではない。

(参考記事)

InstagramもiPhoneアプリでセキュリティー無視(数日後には修正の予定)
http://jp.techcrunch.com/archives/20101118yet-another-hot-startup-leaves-a-gaping-security-hole-in-its-iphone-app/

公衆無線LANで使うと危ないiPod touchアプリに注意(高木浩光@自宅の日記)
http://takagi-hiromitsu.jp/diary/20081206.html

| | コメント (0)

2010年11月18日

GRCのDNS BenchmarkでDNSをスピードアップ

ポッドキャスト「Security Now!」のSteve GibsonによるDNS性能測定ツール「DNS Benchmark」が完成し、Gibson Research Corporation(GRC)のサイトからダウンロードできるようになった。無料で使える。例によってアセンブラ言語で開発され、ファイルサイズはたった163KBである。

dns_benchmark

Google ChromeがDNSプリフェッチを取り入れたり、Google自身がDNSサーバを立ち上げたりして、DNS名前解決スピードがWebブラウジングの快適さにかなり関係しているということが徐々に認識されてきた。DNS Benchmarkは、公開されているDNSサーバに対してクエリを送信し、そのレスポンスを測定する。

測定している値は3種類ある。ひとつめはCached lookupsで、DNSサーバのキャッシュからの応答速度を測定する。まずクエリーを送信してレスポンスを待つ。この応答時間は無視する。次に同じクエリーを送信して、そのレスポンス時間を測定する。1回目のクエリーによって、その名前がキャッシュされたはずである。本当にキャッシュから返答しているかどうかを、レスポンス内のビットで確認する。DNSサーバは、さまざまなユーザから同じサーバ名のクエリーを受け取っている。実運用での名前解決は、キャッシュからの返答がほとんどであろう。この値にもっとも重きを置いて評価する。

ふたつめはUncached lookups。DNSサーバのキャッシュからではなく、相手ドメインのDNSサーバからの応答時間を測定する。たとえばeVNKhHzjoW.amazon.comのような、実際にはあり得ないサブドメイン名を生成し、DNSサーバにクエリーを送信する。他のユーザがこの名前を過去に問い合わせたことはあり得ないから、キャッシュに乗っていない。DNSサーバはDNSの階層をたどっていって、amazon.comのDNSサーバからの応答を得る。

三つめはDotcom lookupsで、測定対象のDNSサーバとインターネットの接続状態を確認する。eVNKhHzjoW.comのようなあり得ないドメイン名を生成し、.comのDNSサーバに問い合わせが行くようにして、応答時間を測定する。

DNS Benchmarkには、デフォルトで50個のDNSサーバが登録されている。これに加えて、自分の環境で使っているDNSサーバ、たとえばブロードバンドルータの内部DNSサーバや会社のDNSサーバを追加したり、不要なDNSサーバを削除したりできる。

さらにGRCのサイトのマスタファイルに4854個のDNSサーバが登録されている。これをダウンロードし、すべてのサーバに対して速度を測定し、その上位50サーバを自分専用のDNSサーバリスト(Custom Nameserver List)として使える。デフォルトで仕込んであるリストは、どうしてもアメリカ中心になりがちである。それを避けるための機能である。

私の自宅ネットワークは、So-netのADSLモデムがDNSサーバを内蔵している(192.168.1.1)。これをプライマリとし、セカンダリにSo-netのDNSサーバ202.238.96.26を設定している。Custom Nameserver Listを作成してベンチマークを実行した結果が以下の図である。クライアント同じセグメントにあるADSLモデム内蔵DNSサーバは、さすがにCached lookupsが速い。Uncached lookupsは上位10サーバであまり差がない。内蔵DNSサーバとSo-netのDNSサーバは、どちらもDotcom lookupsが遅い。

dns_benchmark_result1

インターネットの高速化のためという触れ込みで始まったGoogle Public DNSは、8.8.4.4が39位、8.8.8.8が44位とさんざんな結果に終わった。やはりサーバの速度ではなく、ネットワーク上の距離が大きく影響するのだろう。

Windowsは、プライマリDNSサーバと接続できなかったときだけ、セカンダリDNSサーバを使う。198.168.1.1のDotcom lookupsの遅さが気になるが、他のDNSサーバをプライマリにすると、もっとも頻繁に使うCached lookupsが遅くなってしまう。しかし、内蔵DNSサーバは家族だけが使っているものだ。GoogleやTwitterはキャッシュされるが、検索で見つけたサイトやTwitterで紹介されたサイトは外部のDNSサーバに問い合わせ、Uncached lookupやDotcom lookupとなる。プライマリDNSサーバをIIJ(210.130.1.1)にした方が全体のレスポンスが上がるのではないだろうか。セカンダリは第3位のInfosphere(202.239.113.18)にしてみる。

DNS Benchmarkは、DNSに関する攻撃対策がなされているかどうかもテストする。ひとつはDNSリバインディング攻撃で、残念ながら私の環境のトップ10はどれも未対策である。もうひとつはDan Kaminskyが報告したDNSスプーフィング(キャッシュ汚染)攻撃で、So-netは対策済みである。そのほかのサーバは対策済みかどうか判定できず、GRCが提供しているもうひとつのツールDNS Nameserver Spoofability Testを使用する必要がある。

(参考記事)
Chromeはなぜ速いのか
http://www.atmarkit.co.jp/news/analysis/200812/22/chrome.html

Google、無料DNSサービス「Google Public DNS」発表
http://www.itmedia.co.jp/enterprise/articles/0912/04/news018.html

(本ブログの関連記事)
Google Public DNSを使うと遅くなるかもしれない
http://raven.air-nifty.com/night/2009/12/google-public-d.html

| | コメント (0)

« 2010年10月 | トップページ | 2010年12月 »