せきゅぽろ 14

まずは、昨年、シマンテック社主催で開催された高校生向けの CTF、「シマンテック サイバーセキュリティチャレンジ」に参加した札幌国際情報高校の「もやしーず」と、ネットエージェントの松田和樹さんのパネルディスカッション、だったんですが、全編オフレコという事で、内容に関してはなにも書けません。

う〜ん、どうなんだろう。オフレコにしなきゃいけない程の事だったんですかねぇ ＞シマンテックさん。

で、後半は松田和樹さんによる、「オンラインゲームにおけるセキュアコーディング」ということで、ゲームの「チート」（「ズル」の類）をテーマにしたセキュリティのお話しでした。

チート自体は、かつては、国内でのゲームが専用ゲーム機に偏っていた事もあって、PC でのゲームが盛んだった海外に比べると少なかったのが、最近は急激にカジュアル化しているそうです。

で、典型的なチートの例として、ニセのハイスコアをたたき出す、という話で、URL のパラメータにスコアそのものがあったり、json のデータに埋め込まれていたり、といった、「改ざんして下さい」と言わんばかりの例もあったり、じゃぁ、そういった事を防ぐために具体的にどんな方策があるのか、といった話から始まりました。

で、改ざん防止にリプレイデータを、と思っても、「で、そのリプレイデータって本物？」ということで、例えば、人脈を駆使して本当にうまい人にやってもらう、といったソーシャルハッキング（？）もあれば、Bot による自動操作や、自動操作が難しいゲームに関しては、プログラムのメモリ空間を監視や、API のフックを使ったツールを作って、プレイの補助をさせる、といった事まであるそうです。そこまでがんばれば、そのハイスコアも努力の結果と言えなくもないですが...

で、オンラインゲームに求められるセキュリティ、という事になるのですが、実は、個々の必要な対策はゲーム固有のものでは無い、といった印象でした。それを如実に表している言葉が「クライアントからの通信は一切信用してはいけない」。

ゲームに限らず、ネットワークに関連するプログラムなら、当然の前提です。昨今だと、通信に限らず、データファイルを読み込む時でも、矛盾のあるデータが入っているかもしれない、という事を意識しておかないと、単なるバグのつもりがセキュリティ上の脆弱性となるご時世です。入力データが正しいかどうか、矛盾する通信や、あり得ない手順の通信に対してきちんとブロックできるか、トランザクション処理のように排他が必要な処理を適切行っているか、といった、セキュアプログラミングの基本とも言えるお話でした。

ただ、これらが、特にオンラインゲーム業界できちんと出来ていない事には、ちょっと業界特有の事情もあるようです。

元々、専用ゲーム機でゲームを作っていたようなところから、オンラインゲームの世界に入ってくると、必要なスキルが違ってきます。例えば、

• クライアント／サーバ型のシステム
• ネットワーク・通信
• データベース
• 運用管理

といったスキルが必要になってきますが、これらの技術は元々、セキュリティ問題が普通に存在する分野です。自分はゲームの開発は全く無縁で、サーバの構築・運用が仕事としては多いですが、そこから見ると当然気にするポイントの事が、「ゲームを作る」とこから始まっている人には、なかなか理解されていない、という現実があるようです。まぁ、これはゲーム業界に限らず、例えば組み込み業界も、同様の問題があったり、多かれ少なかれ、「開発者」はセキュリティに無頓着、というのはありますね。

あと、オンラインゲームの場合は、サービス・インがスタートラインで、しかも、定期的に人を惹きつけるためのイベントを打ったり、と、充分にセキュリティに時間・コストをかけられない、という業界の事情もあるようです。

ということで、セキュアコーディングの基本が大切、というのを再認識するお話しでした。

時間が足りなくなって、ちょっと尻切れトンボになったのが残念でしたが、セキュアコーディングの基本を押さえたスライド資料だったので、公開できる範囲で公開してもらえると、教科書として良さそう、と思いました。

途中、ネタとして登場した、「ポケットモンスター　ピカチュウバージョン」にある、任意の Z80 バイナリが実行できる脆弱性はすごかった。これ、CVE 番号とか、JVNDB 番号とか付かないんですかね(^^;

Google Safe Browsing の診断結果が更新された。

このサイトで過去 90 日間に Google がテストした 3532 ページのうち 266 ページで、ユーザーの同意なしに不正なソフトウェアがダウンロードされ、インストールされていたことが判明しました。Google が最後にこのサイトを巡回したのは 2013-03-05 で、このサイトで不審なコンテンツが最後に検出されたのは 2013-03-04 です。

昨日と比べると、全然ちがってますね。これだと、

• 診断結果として表示しているのは、ブロックする前の情報で、実は既に問題が発見されていた。
• 今になって、その情報が診断結果のページに表示されだした。

という可能性が高そうですね。

よーく見ると、昨日の画面の右下に「更新: 16 時間前」と書いてあるので、私がこのページを見たのが確か、昨日の夕方頃だったはずなので、3/4 深夜から 3/5 の未明での診断結果だったと思われます。

mainichi.jp がいつからブロックされていたかは分かりませんが、mainichi.jp にかぎらず多くのページがブロックされた話は、昨日の午前中からあったと記憶してます。

何れにしても、

• 「ブロックされている」という状態

と

• 診断結果

が一致していなかった可能性もあります。

う〜ん、外してしまったかも...。

にしても、既にブロック状態にあるのに、辿れる診断結果が古いままだったら、「なんのこっちゃ？」だよなぁ。

Google Safe Browsing の判断基準

大手サイトが Google Safe Browsing でブロックされたニュースがありました。

「毎日jp」など「不正なソフトウェアが存在する可能性」でGoogleからブロック - ITmedia NEWS

文中に

Googleがブロックしている理由は不明だが、

と書かれていますが、診断画面をよく見ると、おそらくこんな理由だろう、というのが分かります。

毎日新聞を例に診断結果を見てみます。

現在のところ、このサイトは疑わしくないと認識されています。

と書かれています。これだと「じゃぁ、なんでブロックされているんだぁ？」になりますが、真ん中ぐらいに

このサイトは 5 個のネットワーク（AS4694 (IDC), AS2516 (KDDI), AS17506 (UCOM) など）でホストされていたことが判明しました。

と書かれています。

この「AS」の後ろに突いた番号は、おそらく、ルーティングプロトコルの BGP で使われる AS 番号だと思われます。

で、この AS 番号が書かれたところのリンク先を見てみます。AS4694 の情報を見てみると、

このネットワークで過去 90 日間に Google がテストした 8409 個のサイトのうち、90 個のサイト（www.medianetjapan.com/2/20/fasshion/devota/, pixiv.net/, brazil-propolis.jp/ など）のコンテンツで、ユーザーの同意なしに不正なソフトウェアがダウンロードされ、インストールされていたことが判明しました。

と書かれています。

と言うことは、mainichi.jp のサーバが置かれているところと同じ AS 番号で認識されるネットワーク中に、マルウェアを配るサイトがあった、という事になります。

つまり、

• mainichi.jp 自体には、今のところ問題は見つかっていない。
• でも、近くにあるサーバがマルウェアを配っていた。

という状況だと思われます。

おそらく、Google 側としては、悪質なサイトと同一のネットワークを、緊急避難的にブロックしたのでしょう。同一ネットワークのサーバにマルウェアが広まっている可能性を考慮した上で、ひとまず、同一 AS 番号のネットワークをブロックし、個々のサイトに関しては、Google がクロールした結果から大丈夫と判断できれば、随時解除されていく、といった所ではないかと想像します。

この辺、オフィシャルな文章があると、「これが理由だ！」と言えるんですけどねぇ。

追記：

外したかも....

OpenLDAP 上のパスワード情報

OpenLDAP で userPassword アトリビュートにパスワード情報を保存する場合、推奨はソルト付き SHA（SSHA）とされていると思います。実際、CentOS Ver 6.3 上の OpenLDAP に付いてくる slappasswd コマンドは、オプションを指定しないデフォルトは、SSHA の形式を出力します。

しかし、高速な GPU が廉価に販売され、その GPU を駆使して並列計算をすると、ブルートフォースによる解析が、実用的な時間で成功するようになりました。

去年の 12 月に飛び込んできた、「NTLM ハッシュが 8 文字までのパスワードなら５時間版」*1は衝撃的で、私もそのことを日記に書きました*2。NTLM ハッシュは Unicode で表現されたパスワード文字列の MD4 ハッシュ値で、SHA-1 よりは出力されるハッシュ値の bit 長も短く、１つのハッシュ値を求める時間はおそらく、SHA-1 より MD4 の方が短いとは思いますが、それでも、何百倍、何千倍も違う、という事ではないでしょう。

http://www.cryptopp.com/benchmarks.html

上記サイトに、様々はハッシュ値計算や暗号化処理のベンチマーク結果がありますが、MD5 と SHA-1 の比較で、およそ２倍（MD5 の方が高速）という結果になっています。MD4 がどのくらいになるのか分かりませんが、大きく見積もっても 10 倍にはならないと思います。

仮に、SHA-1 の計算が MD4 より 10 倍の時間がかかる、としても、先の「５時間半」は「55 時間」にしかなりません。２日余りで必ず解ける、という事になってしまいます。「塩加減は重要？ - JULYの日記」でも書きましたが、ソルトの有無は Rainbow Table 対策にはなっても、ブルートフォース対策にはなりません。

また、実際に SHA の値を単一の GPU で 33 日間で見つけられたという２年前の記事*3もあります*4。

ブルートフォース対策にはストレッチング、なのですが、自分で作る Web アプリケーションならともかく、LDAP のパスワードフィールドに対して、独自のストレッチングを行う OpenLDAP 用の overlay や plugin を作る、というのも気が引けます。

{CRYPT} は crypt(3)

OpenLDAP のパスワード・スキームに、{CRYPT} というのがあります。これは、古くから UNIX 系 OS の /etc/passwd や /etc/shadow のパスワード・フィールドに記述するされる形式で、古典的には ASCII のパスワード文字列を DES の鍵として、全ビット 0 のデータを出発点に、繰り返し暗号化した結果になります*5。

しかし、今時、この DES を使った形式の値を保存している物を見ません。商用 UNIX でも、Linux でも、10 年以上前から、MD5 を使った形式などに変わってきています。

これは、このパスワード・フィールドに記述する内容を計算する crypt という C 言語用の関数を拡張する形で実現されました。具体的には crypt の引数に渡すソルトで、先頭 3 文字に特別な意味を持たせ、それによって計算処理を変えるようになっています。例えば、「$1$」で始まったソルトが渡されたら、MD5 を使った計算処理を行う、といった感じです。今では MD5 の代わりに SHA-256、SHA-512 を使った形式もあり、最近の Linux ディストリビューションでは SHA-512 を使う「$6$」になっています。

ところが、設定したパスワードとソルトから MD5 の値を求めようとしても、実際に /etc/shadow に書き込まれた物とは、似ても似つかない結果になります。で、実際に crypt の処理を調べたことがあります。

調べてみると、結構複雑 - JULYの日記

実は MD5 を使った crypt というのは、1,000 回のストレッチングを行った処理でした。ちなみに SHA-256 や SHA-512 の場合も、同様のストレッチングをしています。

で、改めて OpenLDAP のドキュメントを読むと、slapd.conf の設定に password-crypt-salt-format*6 という項目がありました。

OpenLDAP Faq-O-Matic: How do I specify the crypt(3) salt format to use?

password-crypt-salt-format に指定するのは printf の書式指定子の形式で記述します。上記ページでは、「password-crypt-salt-format "$1$%.8s"」という例が出ていますが、こうすれば、「$1$」で始まり、その後ろに 8 桁のソルト文字列が続くことになります。

つまり、

• password-hash に {CRYPT} を指定し
• password-crypt-salt-format に "$1$%.8s" と設定する

と、MD5 を 1,000 回繰り返すストレッチング処理をした結果が、userPassword のアトリビュートに書き込まれる事になります。MD5 の計算時間が SHA-1 の半分だっとしても、ブルートフォースで解くには、単純計算で {SSHA} の 500 倍の時間がかかる事になります。仮に、MD5 と MD4 の計算時間が同程度、と控えめに見積もっても、先の 5.5 時間の装置で 2,750 時間、4 ヶ月近い時間がかかる事になります。もし SHA-512 の crypt を使うようにすれば、先に紹介したベンチマーク結果を見ると、さらに 2.5 倍程度の時間を要するので 10 ヶ月の期間が必要、という事になります。

制限事項

slapd を動かす OS 上の crypt(3) の機能

OpenLDAP の {CRYPT} は、その OS 上の crypt 関数の実装に依存します。なので、複数の slapd で同期をしているような場合、それぞれの OS 上の crypt の実装で揃っている必要があります*7。MD5 を使った形式であれば、よほどの事が無い限り、対応していない事は考えられませんが、SHA-256、SHA-512 を使うのであれば要注意です。

ちなみに、RHEL / CentOS の場合、pam_unix で SHA-256、SHA-512 対応となったのは Ver. 5.2 です*8ので、少なくともこのバージョン以降であれば大丈夫なはずです。

LDAP を使うプログラムの実装

ユーザ認証を行うプログラムが、そのバックエンドとして LDAP を使う場合、大きく分けて 2 つの実装方法があります。

• 入力されたアカウント名、パスワードを使って、LDAP サーバへのバインドを試みる。
• userPassword アトリビュートを直接参照・比較する。

前者の場合は、slapd がどんなパスワード・スキームを使ってるかは全く関係ありませんが、後者の場合はプログラム側が {CRYPT} で DES 以外の形式が扱えるか、という問題になります。

例えば、Dovecot でユーザ認証に LDAP を使う場合、

• Passdb LDAP with authentication binds (http://wiki2.dovecot.org/AuthDatabase/LDAP/AuthBinds)
• Passdb LDAP with password lookups (http://wiki2.dovecot.org/AuthDatabase/LDAP/PasswordLookups)

の二通りの方法があり、auth_bind を yes にすれば前者、no にすれば後者になります。

もし、POP3 で APOP、IMAP で DIGEST-MD5 や CRAM-MD5 を使いたければ後者しか選択の余地がありませんが、そうでなければ、前者の方式が使えます。

前者の方式が使えるのであれば、パスワード・スキームの問題は生じませんが、後者の場合は、Dovecot がうまく扱えるかどうか、確認する必要があります*9。

RFC 3062 非対応

パスワードを変更する際、RFC 3062 の「LDAP Password Modify Extended Operation」に対応しているプログラムからであれば、slapd が userPassword を設定したパスワード・スキームで保存してくれますが、これに非対応の場合、userPassword に保存する内容を直接書き込む物があります。コマンドラインの ldappasswd は RFC 3062 対応なので問題ないのですが、例えば Apache Directory Studio*10 は対応していません*11。

これは、password-crypt-salt-format を指定してるか否かにかかわらず、クライアント側で勝手にパスワード・スキームを変更できる事になるのでうれしくないのですが、もし、これらのツールを使うのであれば、slappasswd で -c オプションに password-crypt-salt-format に指定したのと同じ物を指定し、-h オプションに {CRYPT} を指定すれば、userPassword アトリビュートに保存される値が計算できます。

$ slappasswd -h {CRYPT} -c '$1$%.8s'
New password:
Re-enter new password:
{CRYPT}$1$t6PXjyr8$R9LHggt9sf2ietomynfRo0

ただ、slappasswd が使えるなら、ldappasswd で変えた方が早いですが...。

パフォーマンス

そもそも、１度の SHA-1 の計算処理で綱渡り状態にあるようなサーバの場合、そのままパスワード・スキームを変更すれば破綻します。そもそも、認証処理でそこまで重い状態な時点で、システム増強などを検討すべきですが...。

まとめ

ということで、もし、システム全体で問題が無いのであれば、OpenLDAP でのパスワードスキームは、

password-crypt-salt-format を指定した上で、{CRYPT} を使う。

が、今のところ正解、という事になります。ブルートフォース耐性は、"$1$%.8s" で {SSHA} のおよそ 500 倍に上がります。パスワード長を１文字増やしたより高い効果が得られる事になります。

ただし、短いパスワードや単語を使ったようなパスワードなどを設定したら、ほとんど効果はありません。十分に長く、複雑なパスワードで、使い回しをしない、という鉄則は、何ら変わることはありません。

*1:8文字の全パスワードを5時間半で解析するコンピュータクラスタが登場 - CNET Japan

*2:こんなに早く、この日が来るとは... - JULYの日記

*3:エフセキュアブログ : 「SHA-1+salt」はパスワードに十分だと思いますか？

*4:指数表現は実感しにくい - JULYの日記

*5:crypt (C) - Wikipedia Traditional DES-based scheme 参照

*6:今時の cn=config からオンラインで設定変更をする場合だと olcPasswordCryptSaltFormat に該当します。

*7:試してはいませんが、同期自体は正常に行われるかもしれません。ただ、userPassword アトリビュート自体が正しく同期できても、バインド時に正しく認証できない、という事態になる事が想像されます。

*8:Bug 435804 – RHEL5.2 Release Notes: SHA-256 and SHA-512 support in password hashing

*9:未確認。Dovecot が {CRYPT} だった時にそのまま crypt 関数を呼び出していれば、大丈夫なはず。

*10:Welcome to Apache Directory Studio — Apache Directory

*11:Ver. 1.5 系の場合。Ver. 2 系は不明ですが、試した感じでは対応している気配が無かったです。サーバ側の設定の関係とか、あるのかなぁ。

LDD13is

LDD13is（LOCAL DEVELOPER DAY'13/Infra & Security）に行ってきました。

IT エンジニアの将来 - 吉田 パクえ

基調講演として、co-meeting の吉田パクえさん（本名で紹介されなかった）から、インフラ・エンジニアのクラウドとのつきあい方に関してお話がありました。

クラウドのメリットは、スピードとリスク対策で、コストに関してはケースバイケース、というのは、私も思っていたところなのですが、逆に、そこが力の発揮どころ、というのは、その通りだと思いました。

クラウドをどう使うか、という事をきちんと考えられるかどうか、がポイントで、目的次第でクラウドの使い方も変わるし、既存のホスティングで充分で安上がりだったり、全体としてのセキュリティ・ポリシーによっては、オンプレミスの方が良い場合もあるし。

結局、個々の目的、環境によってどうするのが適切かを判断する必要がある、ということに関しては、クラウドの有無に関係ないわけで、単に選択肢が増えた、ということかな、と。ただ、この選択肢を無視する事はありえないので、サービス全体から見たクラウドの使いどころ、というのを意識していく事が大切なのではないか、と思いました。

ライブコーディングとデモで理解する Web セキュリティの基礎 - 岸谷 隆久

SQL インジェクション、コマンド・インジェクション、XSS といった脆弱性を、実際のデモを交えた解説でした。個人的には、一応、知っている話だったのですが、具体的なコードと、実際の動作によるデモ、というのは、ありそうで無かったような気がします。

特に XSS は、「alert() が動く」というのが定番で、これだと、「何か大変な事が起きている」というのが実感しずらいのですが、セッション ID を保持している Cookie の値を盗む、というデモだったので、問題を実感できた人が多かったのでは、と思います。

個々の問題に対して、コードを修正して、実際に脆弱性が無くなる、というところもデモをしていましたが、具体的な対策は、このセッションの最後でも紹介されていましたが、まずは「徳丸本」ですね。

体系的に学ぶ 安全なWebアプリケーションの作り方 脆弱性が生まれる原理と対策の実践

VPS はじめての一歩 - 鷲北 賢

VPS サーバを使う上で、やるべきセキュリティ対策に関するお話でした。

と言っても、基本的には普通のサーバでの対策と同じです。SSH で、PermitRootLogin を no にしたり、ssh のブルートフォースを避けるためにポート番号を変更*1したり、公開鍵認証を使ったり、といった ssh 周りの対策や、sudo のすすめや iptables の話など、VPS に限らず、一般的な UNIX サーバでも推奨されるお話でした。

一つ、VPS ならではなのは「まずは、root のパスワードの変える」。さくらの VPS では契約直後は停止状態だそうすが、それでも、いきなりインターネット上にさらされる訳ですから、なにはともかく、パスワードの変更ですね。

エンジニアのお仕事 実際の話

３名の方の、お仕事の様子のお話です。

東京の会社で札幌での在宅勤務されている方、元花屋のインフラエンジニア、ソーシャルゲームの開発者、といった三者三様のエンジニア・ライフのお話がありました。

最後の質問タイムで飛び出した、「手 JOIN」*2は、目 grep の次にくるエンジニア必須のテクニックに(^^?。

狙われる日本 - Boris Sharov

なんと、Dr.Web の CEO である Boris Sharov さんの講演です。タイトルは「狙われる日本」でしたが、日本が特に何か、というよりも、世界を見渡せば酷い国・地域があり、日本も無関係ではいられない、といった事が印象に残りました。

とにかく、「安全と思い込む」のが一番危険、ということで、Mac で大規模なマルウェアの感染が見つかった時は、特に米国では大きな騒ぎだったようです。

後半、クラウドのセキュリティに関して話されて、その中で印象に残ったのは、クラウド自体は安全でも、所詮、アカウントとパスワードで認証しているだけだから、アカウント情報が漏れたらいくらでも成り済ます事ができる、という、当たり前だけど忘れがちな点について話されていたことです。故に Boris さんは「クラウドが嫌い」と言っていましたが、クラウドセキュリティの肝は認証、という事を強く思いました。

Free Software Way - 小岩 秀和

WCIT-12 の話から始まって、電子書式で購買履歴が管理されてしまう、といった話をマクラに、Free Software の話を小岩さんが熱く語ってました。個人的には、この辺の話は割と知っていて、とかく宗教論争になりやすいんだよなぁ、などと思いながら聞いていました。

どっちかというと「Stallman よりは Raymond」の自分としては、「ちょっと苦手」な感じもあるんですが、質疑の時に GPL と MIT や BSD ライセンスとの比較の話で、小岩さんが「GPL はきつい」と言われていたのが、ちょっと意外、というか、個人的にはホッとした感じがありました。

LT が 6 本

そういえば、せきゅぽろでは、このところ LT やってないですね。LT は毎度、楽しませてもらう側で、いつかは挑戦して見たいんだけど、笑い取れないしなぁ。

ということで次回は

せきゅぽろ #14 は 3/9 で、内容は...、と思ってせきゅぽろのページを見たら、まだ書かれてなかったですね。
ちょうど１年前のこの時期のせきゅぽろは、入院していて出られなかったんだよなぁ、今年は大丈夫かな。

*1:10022 番への変更例が多いために、すでに 10022 番ポートは、準 Well Known ポート状態だそうです。

*2:DB サーバを並列で増やした時に、上物のプログラムで複数の DB を横断するクエリーを実現する方法

milter-greylist の Tarpit 機能

長らく、バージョンアップが無かった milter-greylist ですが、10/11 に Ver. 4.4 がリリースされ*1、長い間、開発版扱いだった Ver 4.3 系に実装された機能が、リリース版となりました。

milter-greylist の Tarpit 機能は、milter-manager の開発に携わっている、株式会社クリアコードの須藤功平さんが作成したパッチで、Ver. 4.3.4 でマージされました*2。その機能が、リリース版で使えるようになった、ということで、実際に動作を確認してみました。

Tarpitting とは

語源は「tar pit」で、日本語に訳すと「タール抗」で、タール状の物が貯まっているようなところを指すようです。

spam 対策での Tarpitting は、送信相手に対して、わざとレスポンスを遅らせます。送信相手が普通のサーバであれば、分単位でレスポンスが返ってこなくても、コネクションが切られるような事はありません。

しかし、spammer の立場に立つと、できるだけ多くのメールを送信したい訳ですから、そんなレスポンスの遅いサーバへの送信はさっさと打ち切って、次の宛先へ送信した方が良い、ということになります。

一般的な Greylisting では、SMTP のレスポンスでステータスを一時エラーとして、「再送してくるか？」を確認するのに対し、遅いレスポンスに対して「待ちきれるかどうか？」を試すのが Tarpitting です。

milter-greylist で Tarpitting

前項の最後に書いたように、「相手がまっとうだったら、こうなるはず」という事を実際に試して様子を見る、という点では Greylisting も Tarpitting も同じです。なので、Tarpitting 単独での挙動は、下記のようになります。

1. 相手からの要求に対して、一定時間、一切の応答を返さない。
2. もし、相手がコネクションを切断する事無く、応答を待つ事ができれば、その先の処理は通常通り。
3. 我慢できずに切断すれば、そこでおしまい。

milter-greylist で Tarpitting を行う時に、こういった挙動をさせるには、greylist.conf に次のように書きます。

racl whitelist tarpit 90s

上記の例では、90 秒後に応答を返すようにして、これに耐えられたら whitelist、つまり、受信・中継を許可する、ということになります。

ここまでは普通の Tarpitting なのですが、問題は途中で切断した時です。

Greylisting のような Tarpitting

途中で切断し、再度、同じ相手から同じ宛先へのメールがあったとします。この場合、tarpit を指定した ACL の行が、あたかも存在していなかったような挙動になります。この事は、須藤さんがパッチを送った時のメールにも説明されています。
[PATCH] tarpit support

This ACL means that clients that can wait a response in
65s are whitelisted. If the clients access again, they are
acceptted without lazy response because they are in
auto-whitelist.

If clients that couldn't wait a lazy response access again,
the ACL doesn't match.

「この ACL は、65 秒*3間、応答を待つ事ができたクライアントは、ホワイトリスト扱いとなる事を意味します。そのクライアントが再度アクセスしてきた場合、自動ホワイトリストに入っているので、待たされることなく受理されます。
もし、待ちきれなかったクライアントが再度アクセスしてきた場合、この ACL にマッチしません。」

つまり、きちんと待てたクライアントはホワイトリスト扱いで、かつ、自動ホワイトリストに入って、以後、待たされずに受理されますが、待てずに切って、再度接続してきた場合、tarpit を書いた ACL の行は、条件として引っかからず、その ACL より後に記述された内容に、判断がゆだねられる事になります。

下手すると spammer の方が有利

この挙動を考えると、「tarpit」の ACL は注意が必要です。「racl whitelist tarpit 90s」と書くと、辛抱強く待っていた相手が救われて、途中で切ってしまうせっかちな相手は拒否されるように思えますが、もし、

racl whitelist tarpit 90s
racl whitelist default

と書かれていたら、数秒で反応が無いと判断してコネクションを切断し、再接続した方が、辛抱強く 90 秒間待っていたより、少ないペナルティで配送されることになります。普通に Greylisting していても、ひたすら再送信を繰り返して、自動ホワイトリスト入りする相手がいますので、これでは下手すると、spammer の方が有利になってしまいます。

tarpit の後ろは大きなペナルティ

tarpit の直後の ACL は、Tarpitting に耐えられない相手に対するルールを記述するのが基本になります。もし、Tarpitting に耐えられたのであれば、tarpit を記述した行で配送される事になります。一番、単純な記述だと、下記のようになります。

racl whitelist tarpit 90s
racl blacklist default

これだと、全てのメールに対して 90 秒間の Tarpitting を行い、耐えられた物は配送し、耐えられなかったものは拒否する、という動きになります。

無条件に Tarpitting する場合は、上記のような記述になると思いますが、S25R や DNSBL を使った「条件付き Tarpitting」をする場合には、ペナルティを課す ACL でも同じ条件を与えないと、Tarpitting とは無関係に、その ACL が評価されます。

racl whitelist domain example.com tarpit 90s
racl blacklist default

上記の場合、相手 MTA が example.com だった場合に Tarpitting をして、耐えられなかったら拒否、という挙動になりますが、そもそも、相手が MTA が example.com では無かった場合には、１行目には引っかからずに２行目で引っかかる事になるので、「相手の MTA が example.com 以外は必ず拒否」という事になります。この場合であれば、

racl whitelist domain example.com tarpit 90s
racl blacklist domain example.com

とすべきでしょう。

tarpitting + greylisting

ここまでは、tarpit を指定した行を「whitelist」としていましたが、この代わりに「greylist」と記述することも出来ます。

racl greylist tarpit 90s
racl blacklist default

greylist を指定すると、「Tarpitting に耐えたら greylisting」という挙動になります。つまり、仮に Tarpitting に耐えたとしても、一度目は中継を許可されず、再送されると許可される、という挙動になります。

ただ、ちょっと挙動が微妙です。

一見、最初に Tarpitting に耐えたあとに Greylist 入りして、２度目に許可されそうに思いますが、実際に試すと、許可されるのは３度目でした。

1. Tarpitting を受けた挙句に、一時エラー。
2. Tarpitting は無いけど、一時エラー。
3. 普通に許可

という事になるので、greylist で指定された Tarpitting の場合、相手 MTA の再送間隔の２倍の遅れが発生することになります。

使いどころ

Tarpitting は、ボットネットを使った spam 送信のように、「通常のメールサーバであれば、その様な挙動にならない」という事を基準にしている点は Greylisting と同じです。ただ、milter-greylist の Greylisting では、「しつこく再送してくる」タイプは許可してしまうのに対し、この Tarpitting は、tarpit を書いた ACL の次の行との組み合わせで、より強力なペナルティを科せられる、というのがポイントです。DNSBL などで怪しい物を抽出して Tarpitting してやると、せっかちな相手を確実にブロックする事ができると思います。

ただ、近頃の、特に日本語の spam の場合、普通に国内の固定 IP をもって、普通に MTA のサーバを立てて、しっかり SPF も設定して送ってくる事が多くなってきている印象があります。spam 送信にボットネットを借りるのと、Amazon ECS を借りるのとで金額が違わない、なんて話もあるので、前よりは Greylisting の効果は小さくなってきたかもしれません。

にしても、そんなに儲かるのかなぁ、spam の送信って。

*1:その後、10/19 に Ver. 4.4.1 がリリース

*2:milter-greylist 4.3.4 is available

*3:メールの中に書かれている例では、「tarpit 65s」という記述。

8 文字 5 時間半のインパクト

グラフィックコントローラの中枢である GPU を、通常の計算処理用に使わせる GPGPU というのがあります。これを使うと、並列計算が通常の CPU に比べて飛躍的に速くなります。

これを、パスワードクラッキングに使う動きが、幾つか出ていました。パスワードクラッキングツールの「John the Ripper」で GPGPU がサポート*1されたり、実際にソルト付き SHA-1 を解析させてみたり*2、「8 文字程度のパスワードをブルートフォースで解くのが現実的になってきたなぁ」という実感がありました。

そこに、「8 文字 5 時間半」という、驚異的な数字が飛び込んできました。

8文字の全パスワードを5時間半で解析するコンピュータクラスタが登場 - CNET Japan

グラフィックコントローラを合計 25 個用意したクラスタ、ということで、個人で用意するには躊躇する金額になるとは思いますが、それを目的としている人なら、大金とまではいかない金額で作れるでしょう。

最初、「全てのパスワード、って本当か？」と思ったのですが、記事の中にある「毎秒 3500 億通り」が正しいとすると、5.5 時間で解析出来る数は、

350,000,000,000 ☓ 60 ☓ 60 ☓ 5.5 = 6,930,000,000,000,000 通り

で、ASCII 図形文字で 8 文字のバリエーション、

95⁸ = 6,634,204,312,890,625 通り

を超えます。確かに、５時間半かければ、どんな 8 文字のパスワードでも解けることになります。なので、記事の最後にある、

つまりは、十分注意して、可能な限り堅牢なパスワードを作成する必要があるということだ。

は、ちょっと妙な話です。

多くの人は「十分に注意して」と言われると、大文字小文字に数字に記号を混ぜて、といった感じの事を想像すると思いますが、どんなにランダムな文字のパスワードでも、８文字以下だったら、最長 5 時間半で解ける、というのが、今回のポイントです。

なので、自分が書くなら、

つまりは、最低でも 10 文字以上のパスワードを作成する必要があることだ。もちろん、記号や数字を混ぜることも忘れずに。

とします。

とりあえず、このシステムを使っても 10 文字のパスワードは、最悪のケースで約 2068 日 になります。平均で３年弱は大丈夫、という事になります。

とはいえ、３年程度であれば、安心とは言えないですね。10 文字は「最低ライン」でしょう。

逆に、認証システムを作る側だと、ストレッチングの重要性が増したと思います。NTLM ハッシュは、UNICODE で記述したパスワード文字列の MD4 ハッシュなので、計算量は小さいと思います。1000 回のストレッチングをしていれば、単純計算で、5.5 時間が 5,500 時間になるので、半年以上は持ちます。

にしても、ここまで早く、現実的な問題になってくるとは思わなかったなぁ。

*1:John the Ripper GPU support [Openwall Community Wiki]

*2:エフセキュアブログ : 「SHA-1+salt」はパスワードに十分だと思いますか？