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

SoftBankガラケー(Y!ケータイ) のIPアドレス帯域は こちら で公開されている。

携帯アクセスの判定には、USER_AGENT もしくは接続元の IPアドレス を参考にすることになるのだが、各キャリアは定期的にネットワークを増強するために IPアドレス は 追加/変更/削除されることになる。
公開されているIPアドレス帯域を個別に指定し、Apache の mod_access などの WEBサーバ 側でアクセス許可することもできるが、その場合、IPアドレス帯域が変更されるたびに、すべてのWEBサーバの設定を変更しなくてはならない。

具体的に、上記の SoftBank を例にすると、こうだ。

# 2012-02-08 現在 ~ 2012-03末
allow from 123.108.237.224/27
allow from 202.253.96.0/27

# 2012-03末 ~ 2012-06末
allow from 123.108.237.224/27
allow from 202.253.96.0/27
allow from 123.108.237.128/28
allow from 123.108.239.240/28
allow from 202.253.96.160/28
allow from 202.253.99.160/28
allow from 210.228.189.196/30

# 2012-06末 ~
allow from 123.108.237.128/28
allow from 123.108.239.240/28
allow from 202.253.96.160/28
allow from 202.253.99.160/28
allow from 210.228.189.196/30


これを運用しているすべてのWEBサーバ、サーバの各 Virtual Host に反映することは、苦痛以外のなにものでもない。もちろん SoftBank だけではなく docomo や au も同様である。
そこで、動的なコンテンツでは コンテンツ内部で IPアドレスを逆引きした結果のホスト名がマッチするか判定することで、IPアドレス帯域が変更になってもサーバ設定をメンテナンスする必要がない。

ホスト名マッチングとしては、以下のような判定が可能である。

*.docomo.ne.jp (docomo)
*.ezweb.ne.jp (au)
*.jp-[tkqc].ne.jp (SoftBank)
*.spmode.ne.jp (docomo SPモード)
*.au-net.ne.jp (au IS NET/au.NET)
*.panda-world.ne.jp (SoftBank iPhone)


しかし SoftBankガラケー の場合、逆引きできない IPアドレス からアクセスがある場合がある。その場合、コンテンツ側で拒否しないよう注意が必要だ。
結局、そうなるとリモートホストでのアクセス制限が意味をなさなくなってしまい、IPアドレス帯域が変更されると、今度は対象のコンテンツをすべて改修しなくてはいけなくなってしまうのだ。

ということで、逆引きができない(リモートホストが引けない) IPアドレスのアクセス制限を、WEBサーバやコンテンツで保守しないでも済むための Tips。
MySQL 5.1.48 にアップグレードをしようとしたら、configure の終了間際に変わったエラーが出力されていた。

config.status: executing libtool commands
/bin/rm: cannot remove `libtoolT': No such file or directory


libtoolsのバグのようだが、下記手順にて configure を再生成する。(パスは適宜変更すること)

$ libtoolize --force
Using `AC_PROG_RANLIB' is rendered obsolete by `AC_PROG_LIBTOOL'
You should update your `aclocal.m4' by running aclocal.
$ aclocal
$ cp -p BUILD/compile-pentium-max compile
$ autoreconf
$ ./configure --prefix=/usr/local/mysql --enable-thread-safe-client --enable-local-infile --enable-assembler --disable-shared --with-client-ldflags=-all-static --with-mysqld-ldflags=-all-static --with-mysqld-user=mysql --with-charset=utf8 --with-collation=utf8_general_ci --with-extra-charsets=all --with-unix-socket-path=/usr/local/mysql/tmp/mysql.sock --with-libwrap --with-pthread --without-libedit --without-readline --with-plugins=max-no-ndb


これで無事、エラーは解決した。
既存の MySQL をアップグレードした場合、いくつかの my.cnf のシンタックスが変更になっているので起動時ログをチェックすること。

100720 16:44:40 mysqld_safe Starting mysqld daemon with databases from /usr/local/mysql/var
100720 16:44:40 [Warning] '--skip-locking' is deprecated and will be removed in a future release. Please use '--skip-external-locking' instead.
100720 16:44:40 [Warning] '--log_slow_queries' is deprecated and will be removed in a future release. Please use ''--slow_query_log'/'--slow_query_log_file'' instead.
100720 16:44:40 [Warning] '--log-long-format' is deprecated and will be removed in a future release. Please use '--log-short-format' instead.
100720 16:44:40 [Note] Plugin 'FEDERATED' is disabled.
InnoDB: The first specified data file ./ibdata1 did not exist:
InnoDB: a new database to be created!
100720 16:44:40  InnoDB: Setting file ./ibdata1 size to 10 MB
InnoDB: Database physically writes the file full: wait...
100720 16:44:40  InnoDB: Log file ./ib_logfile0 did not exist: new to be created
InnoDB: Setting log file ./ib_logfile0 size to 5 MB
InnoDB: Database physically writes the file full: wait...
100720 16:44:41  InnoDB: Log file ./ib_logfile1 did not exist: new to be created
InnoDB: Setting log file ./ib_logfile1 size to 5 MB
InnoDB: Database physically writes the file full: wait...
InnoDB: Doublewrite buffer not found: creating new
InnoDB: Doublewrite buffer created
InnoDB: Creating foreign key constraint system tables
InnoDB: Foreign key constraint system tables created
100720 16:44:41  InnoDB: Started; log sequence number 0 0
100720 16:44:41 [ERROR] Incorrect definition of table mysql.event: expected column 'sql_mode' at position 14 to have type set('REAL_AS_FLOAT','PIPES_AS_CONCAT','ANSI_QUOTES','IGNORE_SPACE','NOT_USED','ONLY_FULL_GROUP_BY','NO_UNSIGNED_SUBTRACTION','NO_DIR_IN_CREATE','POSTGRESQL','ORACLE','MSSQL','DB2','MAXDB','NO_KEY_OPTIONS','NO_TABLE_OPTIONS','NO_FIELD_OPTIONS','MYSQL323','MYSQL40','ANSI','NO_AUTO_VALUE_ON_ZERO','NO_BACKSLASH_ESCAPES','STRICT_TRANS_TABLES','STRICT_ALL_TABLES','NO_ZERO_IN_DATE','NO_ZERO_DATE','INVALID_DATES','ERROR_FOR_DIVISION_BY_ZERO','TRADITIONAL','NO_AUTO_CREATE_USER','HIGH_NOT_PRECEDENCE','NO_ENGINE_SUBSTITUTION','PAD_CHAR_TO_FULL_LENGTH'), found type set('REAL_AS_FLOAT','PIPES_AS_CONCAT','ANSI_QUOTES','IGNORE_SPACE','NOT_USED','ONLY_FULL_GROUP_BY','NO_UNSIGNED_SUBTRACTION','NO_DIR_IN_CREATE','POSTGRESQL','ORACLE','MSSQL','DB2','MAXDB','NO_KEY_OPTIONS','NO_TABLE_OPTIONS','NO_FIELD_OPTIONS','MYSQL323','MYSQL40','ANSI','NO_AUTO_VALUE_ON_ZERO','NO_BACKSLASH_ESCAPES','STRICT_TRANS_TABLES','STRICT_ALL_TABLES','NO_Z
100720 16:44:41 [ERROR] Event Scheduler: An error occurred when initializing system tables. Disabling the Event Scheduler.
100720 16:44:41 [Note] /usr/local/mysql/libexec/mysqld: ready for connections.
Version: '5.1.48-log'  socket: '/usr/local/mysql/tmp/mysql.sock'  port: 3306  Source distribution


ログによって mysql データベースに変更があったことがわかったので、以下のコマンドを実行する。(パスは適宜変更すること)

$ mysql_upgrade --basedir=/usr/local/mysql --datadir=/usr/local/mysql/var -uroot -p

管理ブログを MT-4.261 から MT-5.02 にアップグレードしたのだが、テスト環境で気づかなかったポイントを含む、本番環境への移行メモ。

・mt-config.cgi には "DefaultLanguage ja" を追記。
・同じく "PublishCharset" を定義しているときは "SQLSetNames 1" を追記。
・ただし、このサイトの場合はDBが元々UTF-8環境なので "PublishCharset" を定義せずに "SQLSetNames 0" とした。
・MT-5.02 は古いMT4パッケージを上書きインストールしないこと。個人的には毎回
# mv mt mt_old; ln -s [DocumentRoot]/MT-5.02-ja -> mt
とするような運用がおすすめ。
・アップグレードが終わったら、「システム」→「デザイン」→「テンプレート」より右にある「テンプレート初期化」アクションでグローバルテンプレートの初期化を行う。
・ダイナミックパブリッシング設定の場合、mtview.php が再構築されずに空白ページになてしまう場合があるようだ。その場合、「設定」→「全般」より「ダイナミックパブリッシング設定」の「条件付き取得を有効にする」にチェックを入れ、再構築をするとうまくいった。


ところで、当サイトではタグクラウドの表示はよくつけられているタグ上位20件を名前順に表示し、頻度が高いものを大きなフォントで表示している。巷では頻度順に表示する人が多いみたいなのだが、MT-5.02 では名前順に表示できなくなったしまった。
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設定に入ります。

アーカイブ

最近のコメント