5.サーバの最近のブログ記事

Apple Security Update 2009-002 を Leopard に適用してしばらくして、当サイトを含む複数のサイトドメインが引けなくなってしまい、サーバ自身も外部の名前解決ができなくなってしまった。
原因は、Security Updateに含まれるBINDのバージョンアップ。

* BIND

CVE-ID：CVE-2009-0025
対象となるバージョン：Mac OS X v10.4.11、Mac OS X Server v10.4.11、Mac OS X v10.5 ～ v10.5.6、Mac OS X Server v10.5 ～ v10.5.6
影響：BIND が DNSSEC を使用するように設定されていると、スプーフィング攻撃の影響を受ける。
説明：BIND で OpenSSL DSA_do_verify 関数の戻り値をチェックする方法が誤っています。DNSSEC (DNS Security Extension) プロトコルを使用するシステム上では、悪意を持って作成された DSA 証明書が検証を回避する可能性があるため、スプーフィング攻撃を受ける可能性があります。DNSSEC は、デフォルトでは有効化されていません。このアップデートでは、BIND をバージョン 9.3.6-P1 (Mac OS X v10.4 の場合)、および 9.4.3-P1 (Mac OS X v10.5 の場合) にアップデートすることで、問題を解消しています。詳細については、ISC の Web サイト ( https://www.isc.org/ ) を参照してください。

SYSLOG (/var/log/system.log) には以下のエラーログが記録されていた。
"could not get query source dispatcher (0.0.0.0#53)"

/etc/named.conf にて指定していた「query-source port 53;」エントリをコメントアウトすることで復旧した。

参考：http://oldwww.isc.org/sw/bind/view/?release=9.4.3-P1&noframes=1

DSOモジュール組み込みメモ。

$ tar zxvf mod_tsunami-3.0.tar.gz
$ cd mod_tsunami-3.0/
$ /usr/local/apache/bin/apxs -c mod_tsunami.c
gcc -DLINUX=22 -I/usr/include/db1 -DUSE_HSREGEX -fpic -DSHARED_MODULE -I/usr/local/apache/include -c mod_tsunami.c
gcc -shared -o mod_tsunami.so mod_tsunami.o
# /usr/local/apache/bin/apxs -i -a -n 'tsunami' mod_tsunami.so
[activating module `tsunami' in /usr/local/apache/conf/httpd.conf]
cp mod_tsunami.so /usr/local/apache/libexec/mod_tsunami.so
chmod 755 /usr/local/apache/libexec/mod_tsunami.so
cp /usr/local/apache/conf/httpd.conf /usr/local/apache/conf/httpd.conf.bak
cp /usr/local/apache/conf/httpd.conf.new /usr/local/apache/conf/httpd.conf
rm /usr/local/apache/conf/httpd.conf.new

メール受信(POP3)に使用するプロトコルはPOPが一般的であるが、オプションである暗号化パスワードを使用できるAPOP認証に脆弱性が見つかった。

情報処理推進機構セキュリティセンター(IPA)
「APOP（エーポップ）方式におけるセキュリティ上の弱点（脆弱性）の注意喚起について」

そもそも平文で認証を行うPOPを利用しているユーザはほとんどいないはず...であるがこれで、いま現在一般的に行われているAPOP認証も使えないものとなってしまった。
APOPパスワード漏洩によるさらなる重大な問題は、メールの不正送信をされる危険があることだ。

単純にAPOPパスワードが漏洩するだけでは、メールサーバに保存されている受信メールの読み出しが行えることと、サーバ上のメール消去が自由にできるようになるだけである。
ここで注意が必要なのは、一般的なメール送信の認証方法はAPOP認証に通過したネットワークからを無条件で許可する、という仕組みである。

・メールの受信プロトコルがPOP/APOP
・メールの送信認証がPOP before SMTP
・SMTPサーバとPOPサーバが同じ

という環境である場合、漏洩したアカウントで自由にメールを送ることが可能になる。
SMTP認証でSMTP-AUTHが提供されている場合にはこの限りではないが、今回のAPOP問題の根本原因はMD5ハッシュのコリジョンであるから、この先も安全が保証されるわけではない。

そこで、解決方法のひとつである「POP over SSL」である。

「POP over SSL」を利用することによって、メールの読み出しクライアントとPOPサーバとの間の通信はSSLにより暗号化される。アカウントのみならずPOPサーバから読み出し中のメール本文そのものも完全に隠蔽できるわけだ(※メールサーバ間の通信は平文なので注意)。

ZDNetの記事によると、NTTデータが PostgreSQL で ISO/IEC15408 認証を取得したそうだ。

『NTTデータは4月11日、オープンソース（OSS）のDBMS「PostgreSQL」と、その運用モデルでISO/IEC15408に基づくITセキュリティ認証を取得したと発表した。OSSのDBMSでITセキュリティ認証を取得したのは世界初という。

ISO/IEC15408は、情報技術に関連した製品やシステムが適切に設計され、正しく実装されているかどうかを評価するセキュリティ評価の国際標準規格。独立行政法人情報処理推進機構（IPA）が国内で制度を運営している。

認定取得にあたりNTTデータでは、PostgreSQLのセキュリティ関連機能を強化するとともに、セキュアな運用ガイドラインを規定。2006年9月に申請を行い、今回の取得に至った。

なお、認証を取得したPostgreSQLは、PostgreSQL 8.1をベースに、パスワード認証、監査ログ表示・閲覧機能などを強化してセキュリティ評価基準に適合するよう構成されている。』

ダウンロードは
http://www.nttdata.co.jp/services/postgreSQL/
から。

MD5 チェックサムは

a6037990f222f3f4bb909ebfa9d9d552 postgresql-8.1.5-ISO15408_Linux.i386.rpm

最近、オープンソース RDBMS の信頼性向上がめざましい。
ちなみに、かの「mixi」も mod_perl + MySQL 構成だそうですね。

年末からここ最近、当サイトのメールサーバの応答性が非常に悪くなっていたのだが、原因はこんなことだった。

・スパム対策ブラックリストの「ORDB.org」がサービス停止：ITPro
・ORDBが閉鎖：スラッシュドットJ
・迷惑メールブラックリストを提供してきたORDB.orgが活動停止：ITmedia

スパムメールへの対策としてここ5～6年の間一般的にプロバイダやサーバ管理者に取り入れられることも多かった仕組みが「RBL」である。
RBLはインターネットの基幹技術であるDNSを利用し、スパムメールを送信しようとするメールサーバのIPアドレスをデータベースに管理し、広く公開することによっていわばブラックリストを全世界で共有できるというシステム。枯れた技術であるDNSを利用することによって、またDNSは通信プロトコルとして非常に高速なUDPであるから、とても有用で画期的であったわけだ。

しかし、DNSを用いている以上、根本的な問題を抱えるシステムであるともいえる。
「RBLサービスのDNSサーバが停止すると、著しくメールサーバの応答性が悪化する」のである。

RBLサービスは複数あり、たいていのRBL導入システムでは複数のRBLサービスを参照する。
今回のように、ORDBのようなRBLサービスが停止することによって、メールサーバはORDBからのDNSレスポンスが得られないため、メールの送信処理に進むことができないのだ。

ezmlmでは、ML→ML転送は暗黙のうちに拒否される(というか捨てられる)。
これは、MLがループしないための保護機能で、自動応答(バケーションメッセージ)にたいしても同様に動作する。

maillog に「Precedence:_junk_-_message_ignored」が残っていたら、間違いない。

だが、自分で管理するMLが他のMLに登録されてしまうこともあるだろう。
一番間違いがないのは、他のMLメンバーをこちらのMLに登録し直すことなのだが、いろいろな理由でそれがかなわないとしたら、以下の手段を試してみてほしい。

1．ダミー用にアカウントを作成する

2．.qmail にて procmail を経由させる

| /usr/bin/procmail -m ./.procmailrc
/usr/local/vpopmail/domains/example.jp/dummy-account/Maildir/

3．.procmailrc ファイルでヘッダを改変し、MLに転送する

HOME=/usr/local/vpopmail/domains/example.jp/dummy-account
MAILDIR=$HOME/Maildir
#LOGFILE=$HOME/procmail.log

:0 Hf
* ^Precedence: bulk
| formail -R "Precedence:" "_Precedence:"

:0 Hf
* ^_Precedence: bulk
| formail -R "Mailing-List:" "_Mailing-List:"

:0
! realml@example.jp

4．他のMLに登録されているアドレスをMLからダミーアドレスに変更する

前回は送信側の設定を行い、所有するドメインの正規なメールサーバを全世界に宣言した。今度は、自分と同じようにメールサーバを公開しているドメインを参照し、SPF認証を行う機能をMTAに組み込んでみよう。

当サイトではMTAにqmailを使用しているので、qmailをSPF認証に対応させるパッチを公開しているchristophe氏にありがたく感謝をしつつ、さっそくダウンロード。

現在の最新版は qmail-spf-rc5.patch。RCリリースになっているのは、SPFの仕様がRFCとして確定してないからのようだが、安定版とのことなので気にしないことにする。

このパッチ、かなりの範囲で qmail に手を入れるのですでに他のパッチを多数当てている環境な人には、一発で当たらないかもしれない。当サイトでもそうだったのだが、こういった場合パッチはサイズの大きな大手術ものから先に当てていくと、あとあと楽である。
ちなみに当サイトの場合は以下の手順でコンパイルした。

$ cd /usr/local/src
$ tar zxvf qmail-1.03.tar.gz
$ cd qmail-1.03

■SPF対応化パッチ。
$ patch -p1 < ../qmail-spf-rc5.patch
patching file byte_cspn.c
patching file byte.h
patching file byte_rcspn.c
patching file dns.c
patching file dnsfq.c
patching file dns.h
patching file dnsptr.c
patching file dnstxt.c
patching file FILES
patching file Makefile
patching file qmail-control.9
patching file qmail-showctl.c
patching file qmail-smtpd.8
patching file qmail-smtpd.c
patching file spf.c
patching file spf.h
patching file spfquery.c
patching file str_cpyb.c
patching file str.h
patching file strsalloc.c
patching file strsalloc.h
patching file TARGETS
patching file tcp-env.c

■qmailの648行目の条件分岐を修正するパッチ。
$ patch -p1 < ../qmail-1.03.qmail_local.patch
patching file qmail-local.c

■DNSを引いたとき返答のUDPパケットが512バイトを超えると処理できなくなる不具合に対応したパッチ。
$ patch -p1 < ../qmail-dns-patch
patching file dns.c
Hunk #1 succeeded at 22 (offset 1 line).
Hunk #2 succeeded at 48 (offset 1 line).
Hunk #3 succeeded at 84 (offset 1 line).

■qmailに日本標準時のヘッダを付加するパッチ。
$ patch -p1 < ../qmail-date-localtime.patch
patching file date822fmt.c

■110番ポートでPOP3認証とAPOP認証を自動的に認識させるパッチ(checkpw同梱)
patch -p1 < ../checkpw-1.00/qmail-popup-auth.patchpatching file Makefile
patching file qmail-popup.c

最後に、badmailfromをログに出力するパッチを当てます。
このパッチは --dry-run オプションでことごとくエラーが出たので手編集で直接 Makefile と qmail-smtpd.c を編集。
あとは通常通りに、make → su → make setup check。

これで、qmailを一度起動してひととおり送受信チェック。問題がなければ肝心のSPF設定に入ります。

今日、ドコモが新たな迷惑メール対策を発表した。さる12/6にも、KDDIが同様の発表をしたばかり。
ドコモのニュースリリースでは具体的な技術案件は記載されていないが、おそらくKDDIと同じ「SPF(Sender Policy Framework)/Sender ID(Caller ID for E-Mail)」認証を行うのであろう。digでTXTレコードを調べてみたところ、SPFの記述があった。

$ dig TXT ezweb.ne.jp
;; ANSWER SECTION:
ezweb.ne.jp. 1249 IN TXT "v=spf1 include:spf-im1.ezweb.ne.jp include:spf-im2.ezweb.ne.jp include:spf-im3.ezweb.ne.jp include:spf-im4.ezweb.ne.jp include:spf-im5.ezweb.ne.jp include:spf-im6.ezweb.ne.jp include:spf-nm.ezweb.ne.jp include:spf-az.ezweb.ne.jp ~all"

$ dig TXT docomo.ne.jp
;; ANSWER SECTION:
docomo.ne.jp. 83965 IN TXT "v=spf1 +ip4:203.138.203.0/24 ~all"

「SPF/Sender ID」はメールの送信元ドメインについて、そのドメインのDNSを問い合わせることによって送信元ドメインの正当性を評価する仕組みである。メールプロトコルの仕組み上、いままでは簡単に送信元を詐称することが可能であったのでフィッシング詐欺など大きな問題となっていた。これが、「SPF/Sender ID」を導入することによってドメイン詐称の可能性を評価できるようになったため、偽装したスパムやフィッシングメールは受信そのものを拒否し、ブラックリストへの登録によって第三者に騙られたドメインが誤ってブラックリストに登録されてしまうのを防ぐこともできる。
まだ一般的とまでには普及していない「SPF/Sender ID」認証だが、いままでのインターネットメールの仕組みでは難しかったスパムメールの抑制効果が期待されている。現時点で上記のドコモ、KDDI以外にもAOL、Gmail、IIJなど続々と対応が始まっている。

SPFとSender IDの違いだが、SPFは「Envelope-From」を確認するのに対し、Sender IDは「From:→Sender:→Resent-From:→Resent-Sender:」の優先順位でヘッダを順に評価する。メールがバウンスしたときMTAは「Envelope-From」へメールの差し戻しを試みるので、SPFのほうが扱いとして正しい気がする。現時点での普及度では、「Sender ID」でマイクロソフトがライセンスがらみで一悶着あったらしく「SPF」のほうがより導入度が高いと言えそうである。

そこで、当サイトでも「SPF/Sender ID」がもたらす「なりすましメールの根絶」の効果と、具体的にどのように設定を行えばいいのかを検証してみよう。当サイトではDNSにはbind、MTAにqmailを使用しているので、bind + qmail + SPF の構成を構築する。
「SPF/Sender ID」は送信側と受信側でそれぞれ独立した設定が必要であるが、両方行わずとも大きなメリットがある。
送信側で「SPF/Sender ID」に対応すれば、スパマーに自分が所有している大切なドメインを騙られてスパムを送らてしまうことを防ぐことができるし(厳密には、受信側で対応されてないとスパムは届いてしまうことになるが、最低限責任を果たしているといえるだろう)、受信側で対応すれば、無駄なメールを受信すらしないこともできる。

今回は、送信側の設定として上記のサイトのように、DNSゾーンに「SPF/Sender ID」対応レコードを追加してみよう。

PHPはApacheなどWEBサーバと連携して使用することが多いが、v4.2.0以降ではコマンドライン(CLI)でも動作するようになっている。UNIX、LINUX系では、シェル(csh、bashなど)やPerlなどの言語を標準で使えるが、どうせならPHPでバッチプログラムなどを作成してもいいだろう。
v4.3.0以前のPHPをコマンドラインで利用するには明示的に ./configure --enable-cli する必要があったが、現在のバージョンではデフォルトで有効となった。configureオプションでapacheのapxsなどのSAPIモジュールを有効にするか、--disable-cgi オプションを指定するとCLIがインストールされる。

ただし、気をつけなければ行けないのは「PHPをCLIとしてのみ使用したい」とき。
このとき、configureオプションから単にApacheのDSOモジュールサポートオプション(--with-axps)を外すと、PHPがCGIとしてインストールされてしまう。

もし、シェルで

$ php --help
Usage: php [-q] [-h] [-s] [-v] [-i] [-f <file>]
php <file> [args...]

のように、「-r」オプションが表示されない場合はおそらくCGIとしてインストールされている。これでは、実行ごとにいちいちヘッダを出力されてしまったり、色々とめんどくさいことになってしまう。

こんなときは、「make install」直後に「make install-cli」としてみよう。今度は「-r」オプションが表示されたはずだ。
「-r」オプションはちょっとしたコードをシェル上で試せるのでとても便利でおすすめです。


[参考]
http://jp.php.net/manual/ja/features.commandline.php

Redhat8以降、OSインストール時に日本語を追加しているとデフォルトのロケールを英語にしていても日本語(EUC-JP)になってしまう。

ものによっては(Oracleなど)、インストール時に問題となる場合が多いので /etc/.bashrc などで強制的に export LANG=C としてしまっている人も多いかもしれない。
この方法だと、/etc/rc.d/init.d 以下の各種デーモン管理スクリプトでの起動/停止メッセージまで変更することができない。