NetSkyウィルスって

　ここ一月の間で、W32.Netsky.D@mmっていうウィルスを１１匹捕まえてる。うちのWindows機には、SymantecのNorotn SystemWorks 2006 Premierを入れてるんだけど、こいつがそのうちの９匹を自動的に駆除してくれてる。
　残りの２匹はというと、アカウントリトリーバーのfetchmailで自宅のメールサーバに入れたおかげで、IMAPメールボックスの中で生きながらえてる。けど、ダンプを眺めてみようかな？　なんて思ってウィルス本体である添付ファイルを切り出そうとすると、SystenWorksが気を利かせて削除してくれるもんだから、ちょっとした知的好奇心（笑）を満たせずにいる(ぉぃ）。
　ただ、人の振り見て何とか、ってわけじゃないけどこればっかりは他人事で済ませられないよね。明日は我が身、だから。
　それにしてもウザいな、ウィルス。

SSL証明書

　SSLの証明書は、自分的にまだ学習の余地がありそうだ。昨日の段階で作ったサーバ証明書なんだけど、利用するアプリケーション側が期待する形になっていなかったようだ。
　SSL証明書を生成するとき、公開鍵と秘密鍵を同時に生成するんだけど、今回は生成した秘密鍵をアプリケーションから読めないようになっていたようで、そのせいかデーモンをあげようにもそこが引っかかって起動していないことが判明。Dovecotのほうは秘密鍵のパーミッションを変えれば解決するんだけど、SSL化したtcpserverのほうでは、秘密鍵を読むオプションがないようなので、しかたないので秘密鍵も含めた証明書を生成することにした。
　ということで、こんな感じで実行。

# openssl req -newkey rsa:1024 -keyout private.key -nodes \
           -x509 -days 365 -out public.key
# echo "" > tmp
# cat private.key tmp public.key > cert.pem
# rm tmp

　早い話、生成した秘密鍵と公開鍵を、LFのみのファイルtmpを間に挟んでcatでつなげただけなんだけど、こんな処理でもちゃんと動いてくれるから不思議だ。
　もっとも、もっとOpenSSLについて調べておけば、こんな回りくどいことをせずともスマートに証明書の生成ができるんじゃないかな？

引っ越し その２のその後#1

　SMTP部分が一応うまく動作しているので、次に受信部分の構築にかかることにした。いままではCourier-IMAPを利用していたんだけど、daemontoolsで管理するにはどうやら起動スクリプトの全面書き直しが必要なようだ(Running Courier-IMAP under daemontools参照)。
　「こいつはちと面倒そうだ。」ということで、もっとイージーに動作する(と思われる)Dovecotを試してみることにした。インストールについてはPortsを利用するので特に難しいところはなく終了。起動スクリプトについてはthe djb way : an eye for an imapのDovecotの記述例が多いに参考になった(と言うかそのまんま^^;)。-Fでフォアグラウンド起動するところがミソらしい。

#!/bin/sh
PATH=/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin
export PATH
RUNAS=dovecot
IPADDR=0
PORT=""
CONF=/usr/local/etc/dovecot.conf

exec 2>&1
exec envuidgid ${RUNAS} dovecot -F -c ${CONF}

　設定ファイルdovecot.confについてはこんな感じかな?　以下デフォルトから変わっているところのみを列挙。

protocols = imaps pop3s
ssl_cert_file = /var/qmail/control/certs/cert.pem
ssl_key_file = /var/qmail/control/certs/private.key
ssl_verify_client_cert = yes
log_path = /dev/stderr
log_timestamp =
login_process_size = 64
verbose_proctitle = yes
first_valid_gid = 0
mail_extra_groups = mail
default_mail_env = maildir:/usr/home/%u/Maildir
auth default { mechanisms = plain digest-md5 cram-md5 apop }

  この状態でdaemontoolsで起動。・・・SSLの証明書がないとおこられる。サーバ証明書を作るのを忘れていたので、こいつをOpenSSLで急遽作成して再挑戦。どうやらうまくいったらしい。
　ということで、今日はこの辺で寝る。まだまだ先は長いなぁ。

引っ越し その２

　今度の引っ越しは、メールサーバの引っ越し。現在運用中のサーバが、動作音が少し気になりだしたので、Vineを1台用意したで組み上げた自作機にFreeBSDをインストールしなおして新たに再構築を始めた。
　ただ、単に以前の設定をそのまま移植しても面白味に欠けるし、将来的にLinux環境への移行も視野に入れた上で、「どうせなら」ということで次のような目標を立ててみることにした。

1. MTAにqmailを使う(メールボックス形式はMaildir)。
2. SMTP AUTHを実装する。
3. daemontools配下で各デーモンを管理する。
4. POP/IMAP over SSLとSMTP over SSLを実装する。
5. ウィルススキャナとスパムフィルタを実装する。

　なんでdaemontoolsを使おうと思ったのには僕がLinux特有のランレベルの概念をよく理解してないから、という側面が強いだけの話なので、特に意味はないんだけど。

　というわけで作業開始。まずdaemontoolsとqmailをそれぞれインストールする。SMTP AUTHを実装するので、今回はqmail-vidaをチョイスした。インストールにPortsを使うと、手でビルドするときに内部処理が不透明になりがちなんだけど、今回はそのへんの事情はおいておく。Portsツリーを最新の状態にして、それぞれのディレクトリでmake installを実行するだけで、イージーにインストールできてしまう。sysutils/daemontoolsにはknobがなかったけど、daemontoolsを使うこともあってmail/qmail-vidaには次のknobを定義してインストールした。ちなみに「RCDLINK」が設定されていると、起動時に「起動スクリプトがない」とおこられてウザいので、RCDLINKはキャンセル。

• QMAILQUEUE_PATCH
• LOCALTIME_PATCH
• TCPSERVER_MAN

　portupgradeで自動インストールできる設定にするには、pkgtools.confに次のように書くといいかも。

'mail/qmail-vida' => [
　　　　'BATCH=yes',
　　　　'WITH_QMAILQUEUE_PATCH=yes',
　　　　'WITH_LOCALTIME_PATCH=yes',
　　　　'WITH_TCPSERVER_MAN=yes',
　　　　'WITHOUT_RCDLINK=yes',
]

　qmail-vidaをインストールすると、一緒にucspi-tcpもqmailのインストールプリフィックスである/var/qmail以下にインストールされるんだけど、SSLも使いたいので、新たにインストールしてやる。これもPortsでイージーに。設定したknobはこんなもの。ちなみにインストールプリフィックスは/usr/localなので、qmail-vidaのそれとバッティングすることはないので、安心。

• MAN
• SSL

　ひとまず役者は揃ったので、まず正常にMTAとして動作させるための設定を始めた。daemontoolsで使う起動スクリプトrunの記述例は、Tips Collection - daemontools を参考に書いていった。ひとまずqmail-smtpdの起動スクリプトをのせておく。

#!/bin/sh
PATH=/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin:/var/qmail/bin
ALLOWPLAIN=" "
export PATH ALLOWPLAIN

RUNAS=qmaild
ACLS=/usr/local/etc/acl-cdb/qmail-default.cdb
IPADDR=0
PORT=smtp
FQDN=mail1.formula97.dip.jp

exec 2>&1
exec envuidgid ${RUNAS} tcpserver -vHRU -x ${ACLS} ${IPADDR} ${PORT} \
                qmail-smtpup ${FQDN} checkpassword qmail-smtpd

　とりあえずこの状態で、動作確認の意味で自分宛にメールを書いてみる。自分のメールアドレスやSubjectなんかを書いたテキストファイルを用意して、qmail-injectにリダイレクションで流し込むだけなので、特に難しいことはなく、きちんとメールが配送されていることが確認できた。
　一応うまく動いていることが確認できたので、今日はこの辺でやめる。

transport V.S. relayhost

　このたび僕が契約している@niftyがセキュリティ強化の一環ということで、「25番ポートブロック」(Outbound Port 25 Blocking、以下"OP25B")を実施することになり、自宅で運営しているメールサーバの設定をいじることになった。サーバにはPostfixを利用している。
　オープンソースマガジン2006年2月号にOP25Bに関する記事があったので、どんなものなのかということは知識として知ってはいたけど、いざ自分の身に降りかかってくるとなると、ちょっとあわてる。
　とは言うものの期限は今月の15日と迫ってきているので、FAQを見ながら設定に取り掛かる。@niftyのFAQではtransportを使うよう推奨されていたので、Postfixの資料をひっくり返してtransportまわりの設定を調べる。で、Postfixがtransport（とtransport.db）を読みにいくようにmain.cfを設定してPostfixを再起動するわけだけど、LAN内に別のMTAがあるわけでなし、上流へは@niftyのSMTPサーバを中継しなければならないわけで、別にtransportじゃなくてもrelayhostの設定でいいような気もしてきた。
　とりあえず、これで外向きメールの配送は行えるはずなんだけど………。しかし、プロバイダのメールサーバに、何でもかんでもメールをまる投げするようなことをしててもいいんだろうか？　と心配になるんだが………。

Is Postfix dead???

タイトルが英語なのには、あんまり意味がありませんです。単に「Postfixが死んだかも？」ってあわててただけなんだけど、今回はその顛末を。