Pages

Apr 30, 2006

『割れ窓理論による犯罪防止』

 


border="0">









"http://www.amazon.co.jp/exec/obidos/ASIN/483011021X/bluepill-22/"
target="_top">割れ窓理論による犯罪防止―コミュニティの安全をどう確保するか
"http://www.amazon.co.jp/exec/obidos/ASIN/483011021X/bluepill-22/"
target="_top">割れ窓理論による犯罪防止―コミュニティの安全をどう確保するかsrc=
"http://images.amazon.com/images/P/483011021X.09._SCMZZZZZZZ_.jpg"
border="0" />
G.L.ケリング C.M.コールズ 小宮
信夫

文化書房博文社 2004-03
売り上げランキング : 53,926
おすすめ平均starsrc=
"http://g-images.amazon.com/images/G/01/detail/stars-3-0.gif"
border="0" />


 


style="MARGIN-RIGHT: 0px">id="st"
name="st">id="st"
name="st">割れ
id="st"
name="st">窓
id="st"
name="st">理論とは


style="MARGIN-RIGHT: 0px">

style="MARGIN-RIGHT: 0px">name="st">name="st">割れid="st"
name="st">窓
id="st"
name="st">理論
(われまどりろん、Broken Windows Theory)は、
軽微な犯罪も徹底的に取り締まることで凶悪犯罪を含めた犯罪を抑止できるとする環境犯罪学上の"st"
id="st"
name="st">理論
。アメリカで考案された。「建物の"st"
id="st"
name="st">窓
が壊れているのを放置すれば他のid="st"
name="st">窓
もまもなく全て壊されるだろう」との考え方からこの名がある。

Wikipediaより



実際北海道県警が札幌の繁華街で割れ窓=違法駐車と置き換えてキャンペーンを行い、
2年間で犯罪を15%減らすという一定の成果を得たそうだ。


警察が行った面白い実験
A, 警察官がパトカーに乗って街頭をパトロール。
B, 警察官が徒歩、もしくは自転車でパトロール。
2つのパターンのうち住民に歓迎されたのはBだったという。徒歩だと機動力が落ち、
パトロールの範囲は限定されるにも関わらず住民はそちらを望んだのだという。


これはつまり治安を維持する上では、守る側と守られる側の心理的距離を無視できないということだろう。
これをコンピュータセキュリティに応用してみる。


コンピュータセキュリティの現状
セキュリティポリシーを定めて、
組織のメンバーにそれを守らせるというコンピュータセキュリティの世界で現在一般的に行われている方法は守る側と守られる側の心理的距離などはまったく考慮していない。

むしろセキュリティポリシーを書いた文書に経営者のサインを入れ、ポリシーに権威と強制力をもたせる事に腐心している。
結果確かにセキュリティレベルは上昇したが、セキュリティを口にするだけでユーザに疎まれがちな状況になってしまった。
セキュリティ部門とユーザが対立することはビジネス上望ましくないことであるのはもちろん、
セキュリティ対策を進める上でも大きな障害となる。

徒歩パトロールの教訓を生かして
ユーザとセキュリティ部門の溝がこれ以上深くなる前に、セキュリティ部門は警察の徒歩パトロールを応用したらどうだろう。
週に一度ランダムに選んだ社員のパソコンにログインさせてもらって、セキュリティポリシーに反したソフトがないことを確認する。
もちろん目的は「守る側と守られる側の距離を近くする」ことなのであくまでフレンドリーに。セキュリティ部門が「偉そうにあれをやれ、
これをやれと口うるさく言ってくるヤツラ」と思われないように。


コンピュータセキュリティは歴史が浅い。犯罪捜査・防犯のエキスパートの警察から学ぶべきことは他にもあるのだろうと思った。


 




尚、Amazonの書評で日本語訳がめちゃくちゃという評はその通りで、日本語の文章になっていない。
原書もチャレンジしてみたが、専門用語・語法が多く挫折した。というわけで訳書のほうが「まだ読める」と思います。
一応原書へのリンク↓
href=
"http://www.amazon.co.jp/exec/obidos/ASIN/0684837382/ref=pd_bxgy_text_2/503-8560393-8560740"
target=
"_blank">http://www.amazon.co.jp/exec/obidos/ASIN/0684837382/ref=pd_bxgy_text_2/503-8560393-8560740


 

Apr 25, 2006

Still in Singapore

Our 3-day trip to Singapore is almost over. Everything had been as scheduled or better than we expected.
Due to electricity stuff problem, the departure of our flight (which was originally 23:40) was postponed to 1AM.
It's 0:30AM right now. We are still in the airport waiting for the plane to be ready.
I am anxious about our arrival time in Tokyo.

Apr 21, 2006

デスクトップサーチでサクッとメール検索!

"http://blog.sparky.jp/bluepill/media/file_20060421T004046264.jpg"
target="_blank">
 "http://blog.sparky.jp/bluepill/media/file_20060421T004046845.jpg"
target="_blank">height="290"
alt="windows-desktop-search"
src=
"http://blog.sparky.jp//media/img_20060421T004045172.png"
width="400" />


ここ最近で一番インパクトのあったフリーウェアはMicrosoftの"http://desktop.msn.co.jp/">Windows デスクトップサーチです。
会社でも家でもOutlookを使っていますが、メールボックスは捨てるに捨てられないメールが14万件たまっています。
ここまでメールが増えると、たとえば「去年、田中さんに送ってもらったあのエクセルファイルはどこだっけ?」
という風に過去のメールを発掘せざるを得ない状況が頻繁に起こるわけです。
もちろんOutlookやWindowsの検索機能を使ってもいいのですが、下手すると検索結果が表示されるまでに1時間かかってしまい、
とても実用に耐えません。そこでWindows デスクトップサーチの出番です。


当初この手のソフトは常駐して常にインデックスを更新しているのでパソコンが遅くなると敬遠していました。
インデックスファイルにディスクを占拠されるのもあれですし。
しかしあまりに検索が高速で便利になったことから、今では過去の自分の考えを悔い改めて毎日便利に使っています。
14万件のメールに対してインデックスのサイズは800MB。決して小さくはないですが、これも許容範囲です。


そのまま使っても便利なWindows
デスクトップサーチ
ですが、ちょっとした検索のコツをつかむとさらに効率よく検索が可能です。
ここでは自分が普段よく遭遇するケースについて、どのように検索条件を指定しているかを紹介します。
どんな検索条件でも5秒以内には結果が表示されるはず。
何かの参考になれば幸いです。もっと便利な方法知っている方がいたら教えてください。

ちなみに"http://desktop.google.co.jp/">googleもデスクトップサーチをリリースしてます。
僕はMS好きなのでWindowsデスクトップサーチを使ってますが、Googleでも似たような事はできるはずです。お好きな方を。


 




 


デスクトップサーチが生きる!
10のケース



ケース1:田中さんもしくは竹中さんからもらった添付ファイル付きのメール

差出人:(tanaka OR takenaka) 含む:添付ファイル
size="2">ポイント - ORとNOTの条件指定は大文字で!
"含む:添付ファイル"は最も使えるキーワードのひとつです。


ケース2:2005/5/1より後に、佐藤さんからもらった、もしくは佐藤さんに送ったメールで”サッカー”
が含まれるもの

person:佐藤 date:>2005/05/01 サッカー


name="st">ケース3:鈴木さんから2月にもらったメールで件名に”野球”が入っているもの、さらに”
巨人”や”セリーグ”が含まれないもの
受信日時:2月 差出人:suzuki
件名:野球 -(巨人 OR セリーグ)
size="2">ポイント - 日時の指定には"2月"、"先週"、"昨日"など相対日時が使えます。


name="st">ケース4:先週のメールでEXCELのファイルが添付されていて、
CCに吉田さんが含まれるもの

date:先週 添付ファイル:*.xls cc:yoshida


name="st">ケース5:
dshieldのメーリングリストに流れるメールで2006/3/1から2006/5/1までのもの、
さらにphpもしくはhttpもしくはddosの言葉を含むもの
person:list-bounces@lists.dshield.org
date:2006/3/1..2006/5/1 (php or http or ddos)
size="2">ポイント - ".."で時間の範囲指定ができます。


ケース6:件名にSPAMという単語が入るもの
subject:"spam"
size="2">ポイント -
subject:spamだとspammer,spammingなどにもヒットしてしまいます。


ケース7:連絡先に登録している人の中でPHSユーザ
携帯電話:070


ケース8:連絡先に登録している人の中で横浜にオフィスのある人
勤務先電話番号:045


ケース9:ウィークデイに受け取ったメール
受信日時:月曜..金曜
size="2">ポイント -
応用して週末に受け取ったメールを検索しようと"date:土曜..日曜"とやるとうまくいかない。
その場合は素直に"受信日時:日曜 OR 受信日時:土曜"とする。


ケース10: 自分が送った添付ファイル付のメール
含む:添付ファイル フォルダ:送信済み
size="2">ポイント - フォルダを指定することで検索対象のフォルダを限定できます。便利です。


 


メールの山に埋もれている方、一度使ってみてください。

[緊急] サーバ管理者の意見求む

height="360"
alt="DSC05262"
src=
"http://blog.sparky.jp//media/img_20060420T232416695.jpg"
width="480" />


会社の"http://www2.elecom.co.jp/furniture/19inch-rack/index.asp">ラックに張ってあったこのシール。
意味がまったくわからない。本当にわからない。


・中腰での作業は控えましょう。
・サーバはできるだけ高い場所(手の届くギリギリ)に設置しましょう。
・1ラックに設置できるサーバは1台だけです。
・サーバが飛び出します。落ち着いて両手で止めましょう。

さぁどれだ???


出っ張ってるのはサーバじゃなくてドロワーか?それにしても分からん。

Apr 16, 2006

鳥はむに初挑戦

鳥はむの作り方
(失敗無し編)
を参考に、初めて鳥はむにチャレンジしました。2ちゃんねるで紹介され火がついたレシピです。


作り方は簡単。
なによりも鳥むね肉とは思えない触感。作る前の想像をはるかに上回るうまさです。びっくりしました。


レシピを見ればほとんど味が想像できるという、料理慣れした方にこそお勧めです。
失敗しても材料は安いですしね。


鳥はむ出来上がり
"http://blog.sparky.jp/bluepill/media/file_20060416T144838935.jpg"
target="_blank">height="139"
alt="chickenham1"
src=
"http://blog.sparky.jp//media/img_20060416T144837703.png"
width="240" />


スライスした鳥はむ(包丁入れるときの感触はハムそのもの)

"http://blog.sparky.jp/bluepill/media/file_20060416T144839245.jpg"
target="_blank">height="160"
alt="chickenham2"
src=
"http://blog.sparky.jp//media/img_20060416T144838584.png"
width="240" />


鳥はむの応用メニューがいろいろなページに載っているので(例:"http://3waraji.com/torihamu.htm">http://3waraji.com/torihamu.htm
、来週はいろいろ試してみよう。

Apr 5, 2006

沖縄

先週末は沖縄にいました。 


"http://blog.sparky.jp/bluepill/media/file_20060405T001643741.jpg"
target="_blank">height="160"
alt="20060403111605"
src=
"http://blog.sparky.jp//media/img_20060405T001643240.png"
width="240" />


食べものはみんなおいしかったけど、一番は公設市場で食べた海老の刺身かな。


ひめゆり平和祈念資料館は展示の質・量ともに圧倒的で、結局3時間くらい見ました。出てきたときはグッタリでした。
本土決戦を遅らせるために沖縄が捨石となったとか、本土から来た日本軍にガマ(壕)を追い出されたとか。
沖縄の戦争経験者の怒りのベクトルが日本本土を向いているということに正直びっくりしました。


 


 

Annual Certification Maintenance Fee - 資格継続料金

CISSP取得して約1年を迎えようとしています。CISSPは年度ごとに"Annual
Certification Maintenance Fee"を払う必要があります。年間US$85です。
受験に68250円払っているのでもうこれ以上お金を使いたくないのですが、
資格継続のためには払うしかありません。

この継続手続きがどのようなものなのか、取得前にはほとんど説明が無かったのでここで解説しておきます。
1、CISSP取得後1年で(ISC)2から案内メールが届く。
2、曰く・・・
       期日までに85$をお支払いください。
       支払いが期日より60日遅れると$20の遅延手数料が発生します
(!)
3、しぶしぶWebページから支払い。クレジットカード決済。

お金のかかる資格ですね。
そういった観点から日本の情報処理技術者試験はコストパフォーマンス最高のすばらしい制度だと思います。

DNS増幅攻撃

なぜDNS増幅攻撃について書くのか?

先週(2006/3/29)、"http://www.jpcert.or.jp/at/2006/at060004.txt">JPCERTJPRSが注意喚起を呼びかけた"DNS
の再帰的な問合せを使った DDoS"の件。
本質的な危険が理解されないまま途方にくれている方が多そうなのでフォローします。

DNS増幅攻撃とは
まず"DNS の再帰的な問合せを使った DDoS攻撃"というのが表現が分かりにくいのですが、これはDNS
Amplification Attacksという攻撃の手法を指しています。
ここではDNS増幅攻撃と呼びます。今回のJPCERT,JPRSからのアナウンスの意図を理解するには
このDNS増幅攻撃を理解することが大切ですので、ここで説明します。

DNS増幅攻撃の登場人物は以下のとおりです。
攻撃者:DNS増幅攻撃する悪意あるクラッカー
踏み台:不適切な設定のDNSサーバ、及びその管理者
犠牲者:DNS増幅攻撃の犠牲になる人(具体的には
2006年あたまからVeriSignがこの攻撃を受けています。)

どのように攻撃が成立するかというと・・・
1、攻撃者はDNSサーバにソースIPを偽装したDNSリクエストを送る。
2、DNSサーバは偽装されたIPに対してリクエストの結果を送信する。
3、結果的に犠牲者のネットワークに大量のDNSトラフィックが押し寄せて、通信の遅延などが発生する。
ということです。

既存のDoSとの違い
ここまで読んで、「なんだ今までBotNetがやっていたことと変わらないじゃないか?」と思った方は鋭いです。

確かにここまではありきたりなDDoSの一種と大差ありません。ここからがポイントです。

DNSを使った名前解決はクエリー要求とクエリー応答の通信量の差が大きいです。
試しに、nslookupコマンドで""return top.js.OpenExtLink(window,event,this)"
href="http://u-tokyo.ac.jp/"
target="_blank">u-tokyo.ac.jp
"の全てのレコードを要求してみます。


style="MARGIN-RIGHT: 0px">

> set type=all
> href="http://www.u-tokyo.ac.jp/"
target="_blank">www.u-tokyo.ac.jp

Server:  "return top.js.OpenExtLink(window,event,this)"
href="http://ns1.mss-iss.ne.jp/"
target="_blank">ns1.mss-iss.ne.jp

Address:  "return top.js.OpenExtLink(window,event,this)"
href="http://211.19.41.185/"
target="_blank">211.19.41.185


Non-authoritative answer:
href="http://www.u-tokyo.ac.jp/"
target="_blank">www.u-tokyo.ac.jp
     
internet address = "return top.js.OpenExtLink(window,event,this)"
href="http://133.11.128.254/"
target="_blank">133.11.128.254

href="http://www.u-tokyo.ac.jp/"
target="_blank">www.u-tokyo.ac.jp
     
MX preference = 10, mail exchanger = "return top.js.OpenExtLink(window,event,this)"
href="http://www.u-tokyo.ac.jp/"
target="_blank">www.u-tokyo.ac.jp


href="http://u-tokyo.ac.jp/"
target="_blank">u-tokyo.ac.jp
  nameserver =
href="http://dns3.nc.u-tokyo.ac.jp/"
target="_blank">dns3.nc.u-tokyo.ac.jp

href="http://u-tokyo.ac.jp/"
target="_blank">u-tokyo.ac.jp
  nameserver =
href="http://dns1.nc.u-tokyo.ac.jp/"
target="_blank">dns1.nc.u-tokyo.ac.jp

href="http://u-tokyo.ac.jp/"
target="_blank">u-tokyo.ac.jp
  nameserver =
href="http://dns2.nc.u-tokyo.ac.jp/"
target="_blank">dns2.nc.u-tokyo.ac.jp

href="http://www.u-tokyo.ac.jp/"
target="_blank">www.u-tokyo.ac.jp
     
internet address = "return top.js.OpenExtLink(window,event,this)"
href="http://133.11.128.254/"
target="_blank">133.11.128.254

href="http://dns3.nc.u-tokyo.ac.jp/"
target="_blank">dns3.nc.u-tokyo.ac.jp
  AAAA IPv6
address = 2001:200:180::35:3
href="http://dns3.nc.u-tokyo.ac.jp/"
target="_blank">dns3.nc.u-tokyo.ac.jp
  internet
address = "return top.js.OpenExtLink(window,event,this)"
href="http://157.82.0.1/"
target="_blank">157.82.0.1

href="http://dns1.nc.u-tokyo.ac.jp/"
target="_blank">dns1.nc.u-tokyo.ac.jp
  AAAA IPv6
address = 2001:200:180::35:1
href="http://dns1.nc.u-tokyo.ac.jp/"
target="_blank">dns1.nc.u-tokyo.ac.jp
  internet
address = "return top.js.OpenExtLink(window,event,this)"
href="http://133.11.0.1/"
target="_blank">133.11.0.1

href="http://dns2.nc.u-tokyo.ac.jp/"
target="_blank">dns2.nc.u-tokyo.ac.jp
  AAAA IPv6
address = 2001:380:1ab::35:2
href="http://dns2.nc.u-tokyo.ac.jp/"
target="_blank">dns2.nc.u-tokyo.ac.jp
  internet
address = "return top.js.OpenExtLink(window,event,this)"
href="http://219.166.230.42/"
target="_blank">219.166.230.42



このときクライアントからDNSサーバへの通信は53byteです。
たいしてDNSサーバからの応答は各種レコード、IPv6アドレスなどが含まれており、
約7倍の350byteもの通信が発生します。

たとえばDoSを仕掛ける攻撃者が32Kbpsのダイヤルアップ回線を使っていたとしましょう。
攻撃者が直接www.u-tokyo.ac.jpにDoSをしたとしても、
細いダイヤルアップ回線がボトルネックとなって
1時間で犠牲者のネットワークに送ることのできるトラフィックは10MByte程度にしかなりません。(図「普通のDoS」)


height="360"
alt="dos_normal"
src=
"http://blog.sparky.jp//media/img_20060404T230925404.jpg"
width="353" />

そこでDNS増幅攻撃の登場です。攻撃者は再帰問い合わせを許すDNSサーバにクエリー要求をします。
ソースIPが偽装されているのでDNSサーバからの応答は"http://www.u-tokyo.ac.jp">www.u-tokyo.ac.jpに送られます。
このトラフィックは、クライアントからDNSサーバへの通信の約7倍ですので、先ほどの7倍約70MByteになります。。
(図「DNS増幅攻撃を使ったDoS」)


height="360"
alt="dos_dnsamp"
src=
"http://blog.sparky.jp//media/img_20060404T230926295.jpg"
width="367" />

このようにDNSのプロトコルの性質を巧みに利用して
今までのDDoS以上のトラフィックを犠牲者のネットワークに送りつけることをDNS増幅攻撃と言います。

DNS増幅攻撃をもっと増幅する方法!?
増幅が7倍という風に書きましたがこれはあくまで一例で、7倍以上に増幅する方法もあります。"return top.js.OpenExtLink(window,event,this)"
href="http://www.isotf.org/news/DNS-Amplification-Attacks.pdf"
target=
"_blank">http://www.isotf.org/news/DNS-Amplification-Attacks.pdf
にはクエリーの方法を変えて60byteのDNSクエリーに対して、
合計4320 Byteの通信を発生させられるとあります。この場合、72倍の増幅攻撃が成立します。

またSmurfの手法を応用するということが考えられます
SmurfはソースIPをブロードキャストアドレスにするという手法でしたが、
この手法を応用してDNS増幅攻撃をさらに増幅するという攻撃例がすでにあるそうです。

そして中長期的視点から考えた場合、DNSのクエリー応答の通信量は増える傾向にあります。
DNSが多機能化してきているからです。
IPv6,DNSSEC,NAPTRなどをサポートするようになればDNSサーバからの通信量はさらに増加します
DNS増幅攻撃が行いやすくなると言えます。


対策
DNS増幅攻撃を許してしまう主な原因は以下の2つです。
1、キャッシュサーバが誰からのクエリーでも応答する設定になっている。
2、spoofされたトラフィックを外部に流すことを許しているネットワークが多い。
この2つの原因、どちらかを是正することでDNS増幅攻撃を止めることができます。


対策についてはJPRS,JPCERTからのアドバイザリに詳しく載っていますので、そちらを参照してください。

このアドバイザリが出たのは、このような背景、
そして現実に被害を受けているサイトがあるという現実を踏まえて
「とりあえず比較的対策が簡単なキャッシュサーバの設定を是正をしていきましょう」という意図だと思います。


最後に
誰からのクエリーでも応答するDNSキャッシュサーバのことを、「オープンルックアップ」といいます。
MTAの「オープンリレー」になぞらえているんでしょう。
様々な方ががんばった結果、MTAに関してはSPAMの中継をしないようにきちんと設定する
(=オープンリレーのMTAを放置しない)という意識が、管理者一般に浸透しています。
同じようにDNSもオープンルックアップのまま外部に公開していると、
他サイトへのDDoSの踏み台になる可能性があるということを広く伝える地道な努力が必要です。

参考

DNS Amplification Attacks
href="http://www.isotf.org/news/DNS-Amplification-Attacks.pdf"
target=
"_blank">http://www.isotf.org/news/DNS-Amplification-Attacks.pdf


The Continuing Denial of Service Threat Posed by DNS
Recursion
href=
"http://www.us-cert.gov/reading_room/DNS-recursion121605.pdf"
target=
"_blank">http://www.us-cert.gov/reading_room/DNS-recursion121605.pdf


DNS の再帰的な問合せを使った DDoS 攻撃に関する注意喚起
href="http://www.jpcert.or.jp/at/2006/at060004.txt"
target=
"_blank">http://www.jpcert.or.jp/at/2006/at060004.txt


DNS の再帰的な問合せを使った DDoS 攻撃の対策について
href=
"http://jprs.jp/tech/notice/2006-03-29-dns-cache-server.html"
target=
"_blank">http://jprs.jp/tech/notice/2006-03-29-dns-cache-server.html


どなたかのホームページ
href=
"http://www.vwnet.jp/mura/BookFollow/JPCERT-AT-2006-0004.htm"
target=
"_blank">http://www.vwnet.jp/mura/BookFollow/JPCERT-AT-2006-0004.htm


激しいDDoS攻撃の詳細を明らかにしたVeriSign社
href=
"http://blog.privacy-jp.com/index.php/2006/03/18/e_sei_ao_a_ra_na_ifdifpa_cs_c_ca_a_a_da"
target=
"_blank">http://blog.privacy-jp.com/index.php/2006/03/18/e_sei_ao_a_ra_na_ifdifpa_cs_c_ca_a_a_da
 
(警察庁の翻訳)
href=
"http://www.techworld.com/security/news/index.cfm?NewsID=5586"
target=
"_blank">http://www.techworld.com/security/news/index.cfm?NewsID=5586
 
(原文)