Unofficial Planet WordPress Japan

PacSecではプロの翻訳者に極力依頼しないことにした。

プロの翻訳者はすごい。期日はきっちり守るし、訳抜けとか明らかな誤訳はない。翻訳に手を出したことのあるひとなら、この程度ですらきっちり仕上げるのは大変だということを理解できると思う。まぁ、金取ってるのだから当たり前と言えば当たり前。それでも、その分野の専門家ではないわけで(だからこそ、無難に翻訳できることがすごいのだけれど)、まったく新しい概念や、極めて専門的な内容まで押さえているわけではない。だからどうしても、その業界のひとが読むと「なにか引っかかる」訳になる。金さえ出せば、その辺も(翻訳会社とかの)reviewerがしっかりフォローできるかもしれないけれど、ふつーは無理。セキュリティの最先端の話題を理解できるreviewerなんてそうそういないだろうし。ま、それは翻訳者の責任ではない。そこまでの品質を求めるのであれば、金を積むか、依頼側がreviewするべき。でもそこまでやるなら、最初っからその筋のひとに翻訳を依頼した方が、reviewのコスト(金銭的なコストだけではない)も下げられるし、品質も上がることがわかった。それから、プロの翻訳者(翻訳会社か)は原文のフォーマットを選ぶ。odpひとつですら大騒ぎ。ましてやTeXやMakefileをや。

技術者にお願いする際には、自分がプレゼンするならどう日本語で書くかを意識するようお願いした。少々原文にないことを付け足しても、より意図が伝わるならそのほうがいい。それが適切かどうかは自分が判断するし、その結果も自分が責任を負うつもりで。その結果、(プロの翻訳基準からすれば)ありえないミスもあったかもしれないけれど、全体としてありえない訳文は少なかったはず。あったとしたら(実際、あります)それは自分の責任です。

スライドが用意できたのもギリギリだったし、締切りも厳しく、ましてや対価が支払われる仕事でもないのに協力していただいたみなさんには本当に感謝してます。

まー、相変わらずばたばたしてましたが。

今年は、翻訳関連は全部の権限を奪って好きなようにさせてもらった。翻訳者の選定からスライドの割り当て、成果物のレビューも。自分は仕切りに回って、最後までなるべく手を空けておいたけど、それはやっぱり正解で、最後の最後でややこしい問題が起きてもなんとか余裕を持って対応できた。翻訳に関して言えば一番まともだったと思う。いくつかレビューが間に合わないものがあったり、ギリギリまでスライドを翻訳者にお渡しできなかったりしたけれど、全体としては充分合格点だった。ただ、自分として(翻訳の内容とかではなく)この結果にはまだ不満足で、もっとよくできたはずという思いが残った。このあたりを改善するには、もっと運営にcommitしなくてはいけないね。

運営のほうは改善すべき点がたくさんあって、これは日本人をもう少しスタッフに加えればなんとかなるはず。Dragosはできのいいリーダーなのだけれど、彼が運営まで手を回す(回さなければいけない)から粗が出てくる。細部に美を宿らせる日本人のQA意識を持ち込めば、みんなが幸せになれるカンファレンスにできるはず。ということで、これから日本人スタッフを集めることにした。声をかけた皆さん、よろしくおねがいします。手伝ってみたいひとは連絡ください。

1日目はちょっとだけ、2日目の午後も少しだけ話を聞いただけ。なので、そのなかからおもしろかったネタをご紹介。

Malicious Origami in PDF

PDFネタ。PDFのフォーマット(というかもはや言語に近い)をセキュリティの視点から徹底的に分析したフランス人(フランスのセキュリティカンファレンスの主催者らしい)による発表。当初、スライドが113枚もあって、しかもTeXで、届いたのも2日前という翻訳者泣かせ。相当文句言ったけど、翻訳しがいのある内容だったので許してやった。

PDFはいくつものバージョンを重ね、様々な機能が追加されている。中には、使い方次第で危険な機能もあるけれど、それに対する制限が甘々で、実に危険。具体的には

• 外部プログラムの起動
• 外部リソースの読み込み
• JavaScriptの実行
• 外部サイトへのHTTPによるPOST

しかも、こうした危険な機能に対する制限の実装方法がうんこで、簡単に回避可能。例えば、ブラックリスト方式(明示的に禁止した機能以外はすべて許可)であったり、チェックする実装に欠陥(単純な文字列比較のみ)があったりする。極めつけは、特定の機能はAdobeによるPKIのデジタル署名を必要とするのだけど、Adobeの秘密鍵は誰でも手に入れられる状態。よーするに、だれでも署名して特権を必要する機能を許可できる。PKIの基礎もセキュリティ設計も何もかもがグダグダ。Adobeは全然歴史から学んでいない。アホかと。笑ったのは、このネタの前にAdobeのsecurity researcherがAdobeのセキュリティモデルについて話していた。会場では針のむしろだったのではないかと思う。こんなわけで、PDF virusだって簡単に作れる。PoCもsecurity-labs.orgで公開されてる。もはやPDFは静的な文書ではなく、きわめて動的で危険な機能も含む言語だと認識すべき。

この他にもKerberos認証の突破、ウェブアプリケーションにおけるクロスドメインモデルネタ、Flashを使ったXSSネタがじつにおもしろかった。最後のトークは、speakerが来日できなかったため、NICにSSHサーバを設置するというネタをなんとスイスのGenevaからインターネット中継。これも拍手喝采だった。ライトニングトークでは、招待したTAKESAKOさんがバイナリ2.0ネタを某yappo氏のやる気のないイヌ画像とともに披露。「なんというイヌだ」という声がささやかれる。カンファレンス終了後は、speakerと参加者によるいつものパーティ。いろんなひととつっこんだ話もできたし、PacSecのファンも増えた。やっぱりパーティに参加するまでがPacSecだよねー。speakerと参加者の距離が極めて近くて、いろんなinteractionとか人脈の広がりとか、そういう方向性がPacSecをPacSecたらしめているんだなーと。

というわけで、今年もおもしろいネタばかりで内容はとても充実したカンファレンスでした。直前の参加費用の金額はとても高い(16万円)けれど、事前に登録すれば半額以下になるので、今から来年のPacSecの稟議を通そう!スポンサーには招待枠も与えられるので、何人か送り込むならスポンサーになったほうがお得ですし!運営に参加すれば招待もありまっせ!

UPDATE: 直前までagendaが決まらないのはある意味仕様です。最先端な内容を提供する以上、それは曲げられないとのことです。

組織のセキュリティポリシーを破る行為は必ずしも違法ではない。破った結果が違法行為になることはあるけど。

とはいえ、セキュリティポリシーはその組織の法律みたいなものであって、破ったからにはそれなりの社会的制裁を受けるもの。そしてシステム管理者は、セキュリティポリシーの侵害があればそれに対して何らかの対応をするのが仕事。ポリシーの策定にあたって提案をすることはあっても決定権はないし、決まった以上は「悪法も法なり」という姿勢で対応する。決定されたポリシーをいかに実効あるものにするかに心を砕いて、ポリシーを単なる文章に終わらせず、なんとかして実装する。けれども、どんな対策にも抜け道があるし、完全にポリシーを強制することが必ずしも最善な対策ではないことだってある。だからこそ、コスト、利便性やあるべきセキュリティをはかりにかけて、現実的な対策は何かを一生懸命考える。

NSM Dojoに来てもらったひとならわかると思うけど、よく訓練されたシステム管理者は通信のパターンで何が起きているのかを把握できる。ってか、それぐらいじゃないとIDSの面倒なんか見れないの。膨大な通信の中から、あるかないかわからないセキュリティインシデントを発見するために日々精進しているわけで。

技術的には、システム管理者はそのネットワークやシステムにおける神であって、やる気になればたいていのことは調べられるし、やる気にならなくてもいろいろな事が見えてしまったりする。けれども、技術者の倫理の一つとして、業務上知り得た秘密や事実は墓場まで持って行くつもり。業務時間内にSNSを見ようが、blogでつまらん日記を書き散らしていようが、業務に影響を与えないとか組織にとってリスクにならない限りにおいて見て見ぬふりをするし、それは見てしまっても見ていないことにする。でもね、何をしているのかは常に監視されていると思ったほうがいい。Mixiに組織のありがちなぐちを書いていても、それがいつ会社にとってリスクになるかはわからないし、知ってしまった以上、自分の責任問題になりかねないから、あぶなそうな行動をしている人物は常に頭に入ってる。

そんなシステム管理者がいる場合に、明確な悪意を持ってセキュリティポリシーを侵害するとどうなるか。外部の攻撃者が悪意を持っているのはあたりまえで、(最近は事情が異なるとはいえ)内部の人間には一定の信頼というか少なくとも明確な悪意はないという前提でいろいろやっているのに、背後から切りつけるような行為を許すわけがない。違法行為も辞さないという覚悟でもない限り、ちょっとした欲望のためにセキュリティポリシーを侵害することはおすすめしないし、そっちがそのつもりならこっちも考えがありますよ、ということ。なにかしたいことがあるなら相談してほしいし、現状のポリシーに不具合や不都合があって業務に差し支えるのであれば力にもなります。でもそういうのを吹っ飛ばして、どうやったら制限を回避できるかなんてことをまず考えているひとは危険。組織にとっても本人にとっても。

そんなことをこういうあほな記事を書くひととそれに飛びつくひとたちには知ってほしい。

結論: XSSの(現時点での)すべてをまとめた良書(ISBN-10: 1597491543)。

あのRSnake氏が書いた本ということでゲットした(死語)。まぁ、よく網羅したというか。基本的に、pentester向けの本なので、それが本職じゃないひとにはやや冗長かもしれない。でも、XSSの仕組みから具体的なexploitの作成、XSSがもたらすconsequenceまでが解説される過程で、攻撃者の豊かな想像力に圧倒され「中途半端な対策は無駄だ」と否が応でも悟らせる。自分は、防御側の方がはるかに困難で、だからこそやりがいもあると感じているひとなのだけど、これを読むとblack hatに(金銭的な側面を別としても)魅力を感じるのもわかる。この本の中で取り上げられているexploitはそのまま防御に役立つというわけではないけれど、攻撃者の思考や方法論を知ることはまったく役に立たないわけではない。でも、開発者としてXSS対策を学びたいというのであれば、この本にその直接的な回答はないので別の本を当たるべきだと思う。

ということで、pentester志望なら買え。今すぐ。「XSSってJavaScriptが実行されちゃうあれでしょ」としか理解していない開発者なら、XSSの潜在的な可能性を知るために買った方がいい。すでにXSSの破壊力を理解しているなら、防御側の視点に立った別の本にあたったほうがいいかも。480ページだけど、実質400ページクラスだと考えていい。通勤時間に1週間もあれば読める。

appendixにexploitableなURLをこれでもかというくらいに列挙しているんだけど、大丈夫なのかな。

いろいろと騒ぎになってるみたい。まだ詳細は不明だけど、「いまのところ影響を受けないOSは確認していない」そうなので、大変ですな。

• New DOS Attack Is a Killer RSnake氏による記事
• New attacks reveal fundamental problems with TCP TechTargetの記事
• Researchers caution against TCP/IP weakness pcworld。若干詳しい
• New Denial-of-Service Attack Is a Killer /.の記事 How this really SEEMS to work Computing SYN cookies? この2つは興味深い I’m safe あほだ
• Clearing up some factual inaccuracies… 発見者によるコメント

個人的には、SYN cookieの値が推測可能に1000点入れとく。

UPDATE: Explaining the “New” TCP Resource Exhaustion Denial of Service (DoS) Attack Fyodor様によるspeculationでますた。TCP DoS (probably) real Errata Securityからも。なーんか見えてきた気がする。

UPDATE: TCP Selective ACK considered evil これは実装依存なかんじ(根拠があるわけではない)

UPDATE: Conjecture, speculation… いい線いってるらしい Why The TCP Attack Is Likely Bad, But Not That Bad

UPDATE: Re: TCP Resource Exhaustion Attacks slides from the SEC-T conference sockstress

TLUGのtech sessionでしゃべってきました。ModSecurityのスライドは前回から倍増して、やや時間が押しぎみだったけど、途中で頭が真っ白になることもなく、2回目の英語によるプレゼンにしてはまぁまぁな出来だったかな。一通りの紹介はできたと思うので、ぜひ使ってください。次は、もうすこし進んだ使い方とかパフォーマンスの実際とかを紹介してみたい。

2本目は、Windows OEM製品の「税金」を取り戻そうとしているRacketware.infoの紹介。よーするに、顧客がバンドルされているソフトウェアを選択できるようにすべきだ、という主張のために活動しているらしい。実際に訴訟を起こしたり、議会への働きかけやベンダーとの対話(まだうまくいっていないようだけど)をしているらしい。なんつーか、行動に移すフランス人エラい。さすが自由の国。

3本目が、急遽お願いしたpaperboy&co.の宮下さんによるスケーラブルなファイルシステムネタ。英語だからなのか、YAPCのプレゼンと比較して、しゃべり方がびみょーに「ガイジン」っぽくておもろかった。英語でしゃべると人格って変化しますよね。こうしたネタは自分もしっかり取り組んでこなかった分野でもあるので、ZFSや他の仕組みを組み合わせた解を探してみたい。「スケーラブル」の定義がもう少しクリアになると、「これだとこうできるけど、これはできないよ」みたいな話も出やすくなるんじゃないかな。こういうネタはトレードオフだらけだし。どっちかというと、ご意見募集なプレゼンで、懇親会でそのへんの意見交換ができたらいいなと思っていたんですけど、急な事情でそれができなくなってしまったのはちょっと残念でした。TLUGの飲み会では技術的に突っ込んだ話を気軽にできるので、また次回でもご参加ください。UPDATE: How to build a scalable storage system with OSS

今回はSun Microsystems様に会場を提供していただきました。こうしてご協力頂けるのもすばらしいのですが、Sunのひとたちの姿勢というか意識の変わりようがすごい。って、以前どうだったのかあまり知らずに書いてますが。リリース記念パーティに参加した時は、ユーザコミュニティとの付き合い方を模索している感が強かったのだけど、ずいぶん自然にというか、いい感じにTLUGの雰囲気に溶け込めたように今回は思えました。何より楽しそうにしていらしたのが印象的で、OpenSolarisという仕事があるにせよ、一技術者としてこうしたコミュニティとの付き合いを楽しんでいるように見えました。いろいろおもしろいネタを聞かせていただいたのですが、「そういうネタはもっと外にだすべき。OpenSolaris使えねーという意見には全力でdisり返すべき」みたいなことをお願いしてきました。「Linux kernelでこれやってみろ」みたいな挑発的なプレゼンとかおもしろいんじゃないかな。

今回は「初めてTLUG来ました」なひとも多く、始まってすぐ英語で自己紹介させられて困惑されていたようですが、ゆるーいミーティングなので、ぜひこれからも参加していただきたい。使用言語は英語がdefaultですが、日本語をしゃべるnon-Japaneseも多いし、居酒屋で馬刺しを巡って議論するようなひともいますから、そんなに気後れすることはありません。とりあえず継続して参加してくれるとうれしいです。

ということで、matsuuはタイル型window managerのプレゼンをTLUGですべき。

UPDATE: Tokyo Linux User Group 091308 Jimさんによる写真がいっぱい

Tokyo Linux Users Groupのtechnical sessionで、GPLなWeb Application FirewallであるModSecurityについてお話しします。

• URL: Meetings:2008:09
• 参加資格: 特になし
• 参加費用: なし
• 参加手続き: 特になし(直接会場へ)
• 場所: サン・マイクロシステムズ株式会社 用賀本社 地図
• 日時: 2008/09/13 (土) 14:00-16:30 (開場は13:30から)

内容はシステム管理者、Webアプリケーション開発者を対象に、ModSecurityのuse case、設置例、ルールの書き方、最近の新機能、テストや運用に役立つツールの紹介などです。今回はたっぷり時間があるので、Yokohama.pmで話した内容に大幅加筆しています。2本目のsessionがまだ未定ですが、LT形式で参加者に何かしゃべってもらおうという話もあります。話したいというひともぜひ。終了後は任意参加の懇親会もあります。Tokyo Linux Users Groupと名前は付いていますが、Linux、BSD、Solarisなどなんでもありです。お気軽にどうぞ。

UPDATE: LTはいっぱいみたいです

NSM Dojoの2回目を終えました。参加して頂いた皆さん、6時間お疲れ様でした。でも終了後には、なぜ6時間でも足りないのかご理解頂けたことでしょう。

2回目にもなるとだいぶ余裕が出てきて、ずいぶん落ち着いてできました。CD-ROMはやめて、HeXをLive USBで起動するようにしたので、さくさく操作できたはずです。残念ながら新しいリリースが間に合わなかったので、argusとかのツールが古いバージョンだったのが心残りです。ツールの紹介や解説は駆け足にして、tsharkやargusで手を動かすのに重点を置いたので、それなりに実践的な内容になったと思います。本当は、tsharkやargusとgnuplotとの連携や、自分でツールを作る重要性とかにもう少し触れたかったのですが。

#3もやるつもりですが、しばらく先になりそうです。それまでは、ちょくちょくtipsみたいなかんじでここに書いていきますのでお楽しみに。

• Practice of Programming NSM Dojo #2に行って来た

Critical: openssh security update

詳細は明かになっていないけど、なんらかのセキュリティインシデントが起きて、(おそらく改竄された)OpenSSHのRed Hat Enterprise Linux 4および5のパッケージにRed Hatの正規の鍵を使って署名されてしまった、だそうです。アナウンスによると、パッケージ更新の経路がRHN経由なら問題なし、らしい。

Based on these efforts, we remain highly confident that our systems and processes prevented the intrusion from compromising RHN or the content distributed via RHN and accordingly believe that customers who keep their systems updated using Red Hat Network are not at risk. We are issuing this alert primarily for those who may obtain Red Hat binary packages via channels other than those of official Red Hat subscribers.

In connection with the incident, the intruder was able to sign a small number of OpenSSH packages relating only to Red Hat Enterprise Linux 4 (i386 and x86_64 architectures only) and Red Hat Enterprise Linux 5 (x86_64 architecture only).

ということで、「yohgaki’s blog Fedoraプロジェクトがクラックされた原因 - RedHat系ユーザは早急に対応が必要」の

先週Fedoraプロジェクトがクラックされた原因はSSHパッケージの脆弱性が原因だったようです。

は飛躍しすぎで、アナウンスからは原因はまだ不明です。Fedoraといえど、まさかRed Hat以外のルートから入手したOpenSSHでほいほいアップデートするとは考えにくく、原因は別と考えるのが自然でしょう。それにRed HatからFedoraがパッケージを取ってくるなんてことはあるんでしょうか。Fedoraのことはよく知りませんが、逆なんじゃないですかね。

早急に対策が必要です。直ぐに対応できない場合、sshを止めてしまうのが良いです。困る場合はポートノッキングを実装するとよいでしょう。Webサーバが稼働しているなら、CGIを利用してWebによるポートノッキングを簡単に実装できます

OpenSSHとsetuidされたCGIのどっちがましですかねぇ。

ちなみに、Red Hatの鍵を使ってパッケージに署名ができたということは鍵も盗まれてしまったのかというと、そうではないようです。Red Hatの中の人による”New Red Hat Signing Keys“によると、

The new key, in contrast, was created in a hardware cryptographic device which does not allow the unprotected key material to be exported. This means we can give authorised signers the ability to sign with the key, but no one can ever can get access to the key material itself.

だそうで、これはひとつのproactive securityが効を奏したのでしょう。個人的に、SELinuxがどう役に立ったのか(もしくは立たなかったのか)が知りたいところです。

アーキテクチャが該当するか、自動更新が有効になっていたのか、どの経路でパッケージを入手していたのか、などなどで影響範囲は異なる。関係者はそれぞれ対応して頂きたく。

お題は「mod_securityとParse::ModSecurity::AuditLog」でしゃべってきました。YAPCの容赦ない進行に恐れをなして、10分の制限時間で終われるように初めて事前にプレゼンのリハーサルしましたよ。実際には、ちょっと大目に見ていただけたようで、「時間が来たのでぶちっ」ということはありませんでしたが。

肝心のモジュールはまだCPANにあげてません。てか、CPANのアカウント申請してから音沙汰がないのであげられません。ということで、興味のある方はこちらからどうぞ。スライドもありますので、合わせてどうぞ。

結果はどうだったのかというと、「正直、むずかしいですねぇ」という反応が大勢で。ま、あまり期待はしていないというか、受け入れられるには時間がかかるだろうと予測はしているので、簡単にはあきらめません。あきらめない心が大事だってのは、この五輪で教わったしな!くじけない心でこの先も続けます。

super cookie問題は知っているひとはいたけど、public suffix問題については、あまり知られていないようだった。これについては自分でも書く予定。

次に話せる機会があれば、純粋にPerlのネタとかやりたいね。POEとか。securityネタは好きでやってるわけではないから。ま、そんなことを言っていてもしかたがないので、気持ちを切り替えて次のセミナーに向けて頑張ります。前回は即日満席でしたが、まだ空きはありますので、network securityに興味があるという奇特な人はぜひご参加ください。

最後に、会場を提供していただいたデジタルハリウッド様、運営の皆様、ありがとうございました。

一般向けにNSM Dojoの2回目をやります。内容は1回目と同じです。ただし、前回より手を動かすほうに重点をおいた内容になります。前回はalphaということで無料でしたが、教材(USBメモリとか)の実費として2000円いただくことにしました。

• Network Security Monitoring Dojo - セキュリティとインシデントハンドリング
• 日時 2008/08/29(金) 10:00-17:00
• 場所 パソナテック本社(渋谷) 研修室
• 参加費 2000円
• 定員は16名
• 申し込み パソナテック様のページからどうぞ

終了後には懇親会も予定していますので、丸一日時間を空けておきましょう。

「もうsnortはダメかな」と思い始めて幾年月。broがすげーよ、とうるさく触れ回ってるんですが、なにせIDSのふりしたネットワークスクリプト言語なので、なかなかまとめ記事が書けない。とりあえずリンクだけ貼っておく。付属のPDFは内容が古いので、本家のWikiを参照のこと。

• bro-cluster
• High Performance Packet Capture
• Bro + Afterglow == Flow Insight with Link Graph これはargusででもできるかな
• Bro Scripting Language - The Basics
• Bro Publications broは論文がたくさん公開されてるのも特徴

基本的に今回の攻撃は、外部から任意のドメイン名を検索させることで、キャッシュポイズニングを成功させるものです。なので、NAT/NAPT配下だと、身内からの攻撃があれば別ですが、通常は外部から任意のドメイン名の検索を行わせるのは困難でしょうから、それほど心配の必要は無いといえます

<img src='http://aaaa.example.org/foo.jpg' />
<img src='http://aaab.example.org/foo.jpg' />
...

人手を介さないのだって、PTR引くときに正逆確認するのにAを引くとか、URLをチェックするspamアプライアンスとか、いくらでも思いつきますよ!

ってか、JPRSってどうなってるの?

パケットを扱うプログラムは特権が必要と思われているけど、実際には/dev/bpfをopenするときにだけ特権が必要。通常、それ以外は特権なんかいらない。それなのにtsharkやtcpdumpを特権ユーザで実行するのは危険極まりない。適切に書かれたプログラムは権限分離機能があるけど、中にはそういう危険性を考慮していないものもある。じゃ、/dev/bpfの権限を変えてしまえばいいんじゃね?

# pw groupadd bpf

FreeBSDでは動的にデバイスが生えてくる仕組みにdevfsを使っている。/etc/devfs.rulesで、bpfをグループbpfに許可。

[localrules=10]
add 15 path 'bpf*' mode 660 group bpf

/etc/rc.confでlocalrulesを起動時に有効にする。

devfs_system_ruleset="localrules"

あとは、bpfを必要とするユーザをグループbpfに追加すればよい。

お楽しみいただけたのか非常に不安の残るセッションでした。ええ、自分は楽しかったですよ。好きなことをいいだけしゃべることができて。一人で突っ走ってしまって、参加者の皆さんが置いてけぼりだったら悲しい。しかし、6時間でも足りないとは。本当はパケットの解析にもっともっと時間をかけたかったのですけど、ちょっと駆け足になってしまいました。すみません。

ネットワークセキュリティって、製品買っておしまいとか、外に投げておしまいとかじゃなくて、こうすればここまでわかりますよ、こうすればこういうことが見えてきますよ、ツールは人が使いこなしてこそ意味を持つんですよ、っていうことが伝わったらいいのですけど。

あと、紹介した書籍はTaoSecurityにまとまってます。読みましょう。

• The Tao of Network Security Monitoring: Beyond Intrusion Detection ちょっと内容は古くなってますが、NSMの基本をみっちり教えてくれます
• Extrusion Detection: Security Monitoring for Internal Intrusions 大規模環境における課題とか、高度な話題もあつかってます
• Real Digital Forensics ネットワークだけではなく、forensics全般をあつかってます。diskまわりのネタとかはとってもおもしろいです

パケット解析したいけどいいサンプルがないという人向けに、サンプルパケットを公開しているサイトもありますので、今回覚えた知識で挑戦しましょう。

• openpacket.org セキュリティに関するパケット
• Wireshark Wiki SampleCaptures ふつーのパケット
• Honeynet Challenges ハニーポットの観察記録

それからNSM関連のblogも紹介しておきます。

• TaoSecurity 師匠
• When {Puffy} Meets ^RedDevil^ HeX LiveCDの中のひと
• Inliniac snort inlineの中のひと

もうちょっとうまくやりたいので、2回目やろうかな。つか、チーム作ってパケット解析大会みたいなのがいいのかも。ツールの使い方よか、どういう点に着目したのかとか、分析における思考過程が大事なんで、他のひとの視点を学ぶっていう方向でやるといいのかもしれないな。

ご協力いただいたパソナテックの皆様、参加していただた皆様、準備を手伝ってくれた弟子、ありがとうございました。

• NSM Dojoへ行って来た

すぐ消したけど、GoogleのRSS readerに引っかかったらしい。livedoor Readerにはなかった。「やっちゃった」と書いている(Regarding The Post On Chargen Earlier Today)けど、draftを公開してしまったっつーことなんですかね。翻訳も解説もしないので原文をどーぞ。

Kaminsky’s DNS Issue Accidentally Leaked?

UPDATE: Kaminsky’s DNS Attack Disclosed, Then Pulled

一瞬で埋まってしまったNSM Dojoですが、2名ほど空きがありますので、参加したい方はご連絡ください。案内のページの連絡先メールアドレスでもいいですし、個人的に連絡(ここにコメント残すとかでも)してもらってもかまいません。

特定の条件に特化したruleを書いていると、if … thenが欲しくなる。明示的に「こういう条件下でのみこれを評価しろ」と書きたいこともあるし、いちいちchainを書くのが面倒ということもある。これを実現するにはactionのskipとskipAfterを組み合わせる。

# if any arg matches "foo"...
SecRule ARGS "foo" "phase:2,t:none,t:lowercase,skip:1,pass,nolog"
SecAction "phase:2,pass,nolog,skipAfter:1000"

# then find "bar" in the args...
SecRule ARGS "bar" "phase:2,t:lowercase,deny,log"
# or buz...
SecRule ARGS "buz" "phase:2,t:lowercase,deny,log"

SecMarker 1000

よーするに、最初の条件にマッチしたら、skip 1で次のSecActionを無視して(つまりSecMarkerの部分までskip*しない*)、続く条件を評価する。

Vulnerability Note VU#800113 Multiple DNS implementations vulnerable to cache poisoningだそうです(Alliance forms to fix DNS poisoning flaw)。 PowerDNSがNot Vulnerableなのはエラい。

で、BIND 9.5.0-P1のdiff取ってみると、OpenBSDのarc4randomを使うことにしたらしい。

* ARC4 random number generator obtained from OpenBSD

「よくわからんけど、あいつらのことだから大丈夫だろ」だそうです。

   /*
    * Derived from OpenBSD's implementation.  The rationale is not clear,
    * but should be conservative enough in safety, and reasonably large
    * for efficiency.
    */
  mgr->arc4ctx.count = 1600000;

networkとsecurityの両方の視点からインシデントの監視を行うNetwork Security Monitoring(NSM)について解説するセミナー、
Network Security Monitoring Dojoを7/25(金曜日 10:00-17:00)に渋谷で開催します。定員は16名でどなたでも参加できます。今回も会場はパソナテック様にご協力いただきました(いつもありがとうございます)。

NSMとは、Richard Bejtlich氏のTao of Network Security Monitoringで提唱されている実践的なネットワークセキュリティの監視手法の一つです。具体的には、L3からL7までの情報を活用しつつ、様々な角度からインシデントの経緯を明らかにし、セキュリティインシデントの予防と対策を行います。

セミナーではパケットの解析の基礎からデータの可視化まで広範なトピックを扱い、各種ツールを使いこなしながら、ネットワークを守るために必要なデータの取得方法や注目すべきデータの見つけ方に加えて、ツールの使い方にとどまらない実践的な知識と思考能力を身につけてもらいます。修了試験として、仮想のシナリオに基づいた攻撃を実際に解析していただきます。

毎度ながら、終了後には懇親会も予定していますので、時間に余裕のある方はぜひご参加ください。

UPDATE: すでに定員に達したみたいです。追加でもう1回やったほうがいいでしょうか