IPAがApacheなどのログを解析して攻撃を受けていることを検出するソフトを公開したと聞いた。iLogScannerという名前。v3.0だがそれ以前のバージョンの公開のときに聞いてない。

でやろうとしたのだが…。自分の環境では起動すらしなかった…。なんで今どきJavaアプレットなんだろうね。推奨環境はIE7でWindowsXPって意味不明だ。Javaを使ってなんでそうなるのかよくわからんな。Javaでやるのは結構なんだがアプレットなどというあやしげなものじゃなくてJava Web Startぐらい使ってくれればいいのに。

まず次のものを用意する。

• CA証明書
• サーバSSL証明書 (PEMとKeyファイル)
  
• クライアント証明書 (PKCS12)

一々手で用意するのも面倒なので TinyCA を使って作成した。TinyCAの使い方は省略。

クライアント証明書認証の概念をおおざっぱに説明すると サーバ側にクライアント証明書を見せて、サーバが証明書が正しい(CAに署名されている)ことを確認して、接続を許可するという流れになる。通常のSSL接続の設定に比べると、サーバ側にCA証明書の設定が必要になる。

サーバSSL証明書の設定

まずは通常のApache+SSLの設定をする。あまり詳細な説明はしない。他を参照すること。mod_sslを導入した上で設定ファイルを書く。この時点でPEMとKeyファイルをサーバにコピーした上で設定が必要となる。

SSLCertificateFile    /etc/ssl/apache/ssl-cert-ssltest.pem
SSLCertificateKeyFile /etc/ssl/apache/ssl-cert-ssltest.der

この時点でブラウザで接続すると通常は証明書が信頼できない云々のエラーが出る。そこでブラウザ側にCA証明書をインストールする。手順は略。ただし、この手順はセキュリティ的には書いてあったからそのままやるとか思ってると将来大変なことになるので注意。

この状態で接続するとSSL証明書に関するエラーは出なくなる。

クライアント証明書の設定

サーバ側にCA証明書をコピーする。これをApacheに設定した上でSSL証明書接続を要求する設定も追加する。

SSLCACertificateFile /etc/ssl/apache/SSLTESTCA-cacert.pem
SSLVerifyClient require

この状態で接続しようとしても接続できないことを確認する。

次にクライアント証明書をブラウザ側でインポートする。そのあと接続するとクライアント証明書を提示することの確認などがされて無事接続される。

環境変数のSSL_CLIENT_S_DN_CNに CommonName が入っている。これを利用してユーザーの確認をすればいい。

去年は間違った操作で削除しても困らなかった。今年も今日ログインして終わる気がする。

fail2ban-regexで実験しようとしたら…？？？初期設定のものをテストしても一切引っかからないのはなぜに？ と調べたら 0.7.5-2etch1は駄目だけど0.8.3-2では大丈夫。バグなのか？ よくわからん…。

filter.d/zope-plone-trackback.confを作成して次のように設定。適当すぎるがまあいい。

failregex =  <HOST> - - .*/trackback HTTP

jai.confに次のように設定。

[zope-plone-trackback]
enabled = true
port    = http,https
filter  = zope-plone-trackback
logpath  = /var/log/apache2/access.log
maxretry = 6

こんな感じでやったら

# iptables -L fail2ban-zope-plone-trackback
Chain fail2ban-zope-plone-trackback (1 references)
target     prot opt source               destination                    
DROP       0    --  92.48.127.153.svservers.com  anywhere            
RETURN     0    --  anywhere             anywhere   

とかなったので大丈夫かなと。

が、しかーし、逆引きはあるけど正引きがないという恐しいところホストがあった！ log に逆引きで記録してあるから IP がわからないので規制できないというよくわからん話が…。

僕はフリーソフトウェア作家の立場として行っている。やっぱり違和感があるんだよね。作成物に対する責任というのはあるのかどうか。報告してもらえるのはうれしいが、対処しなかったからと言って何やら言われるのはどうなんだという気がする。そこらへんはJPCERT/IPAの人も感じているようなんだけど。

あと、脆弱性の指摘。適当にしていいのか。治してくれないのはどうしたらいいか。商用サービスならいいが大学とかどうするんだ。予算がないからやらないというところをどうすればいいのか。悩みはつきぬ…。強制切断とかできりゃいいのか。

帰りにKDDIビルの写真を撮ってくるあたり壊れているよなあと思う。

JVNに登録されているので毎年出しているが、まともに使ったことが全然ない。中の人にも存在意義がよくわからんと直接文句言ったことがあるが、中の人も悩んでいるらしい。

あれ、返信封筒の切手自分で貼るの？去年までそうだったけ？

• Ruby - open-uriを使ったら  OpenSSL::SSL::SSLError: certificate verify failed となった
• Python - urllibを使ったらそのままスルー
• PHP5  - cURLを使ったら curl_execが FALSEを返すようだ。他のcURLも同じかな？

• クライアントとアプリケーションの参照しているDNSが両方乗っ取らられたら死ぬよね。認証サーバが変なとこ挿していても気付かない。
• さてアプリ側のDNSのみ乗っ取られたとする。偽CASサーバーを立ててアプリ側からそっちを見るようにする。偽CASサーバーは通常は透過的に本物のCASサーバーに接続させているとする。CASの手続として認証が終わったことにするとGETでチケットをアプリに渡して、アプリはチケットの検証を偽CASに問い合わせる。通常ならチケットは使い捨てのランダムな文字列なので、手動で適当にチケットを生成するなどの横取りは難しい。が、偽CASが偽チケットを許可したらどうなるか…。
• SSL証明書でサーバーの信頼性を確保？EV SSLじゃなかったら最近のSSL証明書なんてどこまで信用できるのやらという見方もできるよね。大体アプリのコードの中でSSL証明書の検証していますか？
• さて、この推測に誤りはあるのだろうか？
• さて、正しいものとして進める。確かにDNSを外部から乗っ取るのは楽ではないかもしれないが、DNSの管理者はアプリの管理者と同一とは限らない中でDNSの信頼性に頼るやりかたでいいのだろうか。脆弱性とはではいかんけどさ。SSL証明書がどこまで信用できるかがポイントかなあ。
• ところでせっかくのポータル上で動いてないのはなぜだろう。

今さら乱数表かよ。キーロガーがしかけられるような環境では固定の乱数表なんか何の意味があるのかわからん。

安全でない通信路で行われた場合、乱数表と入力されたパスワードからパターンを読まれないのか、ということ。ええ、実際キーロガー対策ツールなんぞが紹介されているということは弱点を認識しているということではないのかな？疑問が消えないなあ。

• 参考 - 捜したらこんな人もいた。メーカーにはきちんと数学的に安全性を証明してもらいたいよ
• 参考その2 もっと良い説明ですね