と思いつつも、

飛んで火に入る夏の虫・・

とも思った。

ヤツがまた来た。それはもう清清しいくらいに同じ手法で。

おなじみの内容、件名におなじみの差出人（似非日本人みたいな差出人名）、おなじみの方法（1025秒前後で再送）で、おなじみの頻度（300通over/1日）だ。

でも内心また来て欲しいとも願っていた。あの後サーバーサイドに導入したSpamassassinの効果を確かめる絶好のチャンス。前回はspam対策として施していた以下の対策が全てスルーされていた。

1. 送信元ドメインの存在チェック
2. Greylistingによる受信制限
3. DNSBLを利用した受信制限

今回は以下の対策を施していた。

1. 送信元ドメインの存在チェック
2. Greylistingによる受信制限
3. Spamassassinによるspam判定

前回まで「3.」で施していた対策はPostfixへの以下の設定によるものであった。

smtpd_client_restrictions =
・・・・・
    reject_rbl_client dsn.rfc-ignorant.org,
    reject_rbl_client zen.spamhaus.org,
    reject_rbl_client dul.dnsbl.sorbs.net,
    reject_rbl_client bl.spamcop.net,
・・・・・

実はこれ、送信元IPアドレスがDNSBLに含まれる場合に問答無用でrejectするという男気溢れる挙動であった。情け容赦なしにrejectする様をPostfixのログから眺めるのもある種の味わいがあって好きであったし、それはそれで良かったのだが、今回導入したSpamassassinは実はそのあたりのチェックも行ってくれている。

上記のPostfixの設定は送信元のIPアドレスのみをチェックしているのだが、Spamassassinではこれと合わせてメール本文中に含まれるURL（のFQDN部分）もブラックリストと照合してくれている。

Spamassassinでは、その他、様々なチェックを行い、それぞれに「スコア」がつけれれており、最終的な「スコア」がある閾値（任意で設定出来る）を超えたメールをSPAMメールとして判定する。例えば、あるDNSBLチェックに引っかかってしまった場合でも、その他のチェックに引っかからなければ（閾値を超えなければ）SPAMメールとは判定されない。

よってこの慈悲深い挙動を確かめるために今回からPostfixの設定から「reject_rbl_client」の記述を削除することにした。

で、肝心のSpamassassin導入による効果だがヤツらからのほぼ全てのメールを以下の通り判定してくれた。

ちなみにルールセットは TELC様 のものを活用させていただいています。

というわけで、リベンジ成功です。上のスコアを見ると、ベイジアンフィルタによるスコア（BAYES_99=7.5）以外にも色々助けられてるな～と。それぞれの意味の詳細については今後書いていきたいと思います（多分書かない）

オープンソースで有名なベイジアンフィルタと言えば

• bsfilter
• SpamAssassin

等が挙げられる（っていうか、この2つか知らない:-) ）

前職で後者のSpamAssassinを使用していたので今回もサクッと導入出来るであろうと踏んでいたが、それは大きな間違いであった。「やりたいこと」は明確であったのだけど、その「やりたいこと」の1歩手前までは上手く行くんだけど最後の最後でどうしても解決方法が見つからない事ばかり。

「やりたいこと」というのは

これだけ。たったのこれだけなのに全てを満たすのに苦労した。

構築にあたって、必須の構成要素は

• MTA： Postfix
• ベイジアンフィルタ： SpamAssassin

とした。（この構成を変更しだすとキリがないので）

巷のWebページでも「Postfix + SpamAssassinによる迷惑メール対策」的な解説ページが多数見受けられたのだが、どのページを見ても、上の「やりたいこと」を全て満たすものではなかった。大抵のWebページが仮想ドメイン・仮想ユーザを想定しておらず、システムの実ユーザ環境での構築方法であった。

そう考えると前職で扱っていた環境は、MTAこそPostfixではなくqmailであったのだけど、「やりたいこと」を全て満たせていたので見事であった。（自分で言うな）

前職で扱っていた仕組みはこんな感じ↓（もう構成とか設定方法をだいぶ忘れているので適当に）

但し、短所としては赤色文字にあるように仮想ドメイン+仮想ユーザの組み合わせ分だけ実ユーザを作成しなければならなかったので管理が煩雑であった。

今の構成は Postfix + LDAP で仮想ドメイン・ユーザー環境を構成しており、仮想ユーザ宛のメール配送先等の情報はLDAPに格納している。Postfixでもqmailのような仮想ユーザと実ユーザの紐付けは可能であるが、上に挙げた短所を許容したくないためにこのような構成をとった。

よって「やりたいこと」の 4. の条件を次のように厳しくすることとする。

次記事以降に実際の構築方法を「苦労した点」「解決方法」と共に書いていきたいと思います。

Wikipediaによると、

ということなので、実際にDNSクエリを投げて挙動を確かめてみよう。

ということで

• DNSBLドメイン（ゾーン）：zen.spamhaus.org
• 確認用IPアドレス：78.162.167.215

とする。

「zen.spamhaus.org」は Postfixの reject_rbl_client に実際に設定しているホスト名だ。

# これがDNSのゾーンを表していたとは知らなかった。

spamhausはこのあたりで「使ってはいけない」とか書かれているが、わたしはどちらかと言うとこういうスタンスの方が好きなので今後もガシガシ使っていく。（メールの到達性の保証とかあまり気にしないので）

「78.162.167.215」は先日の件（って今も継続中だけど）で晒したIPアドレスの中の1つだ。

さて、まずは「1.」にならって、「78.162.167.215」を「215.167.162.78」とする。
で、「2.」にならって、「215.167.162.78.zen.spamhaus.org」とする。
「3.」で「2.」のAレコードを引けっていってるので

Authorityを持つサーバがこれだけ（緑色文字）あるみたい。世界中からのDNSクエリをさばかないといけないわけだから当然といえば当然か。

実際のANSWERセクション（DNSクエリに対する回答）はオレンジ色文字の部分。Aレコードが、「127.0.0.10」と「127.0.0.4」と2つ返ってきた。ここは大抵127.0.0/8のループバックアドレスらしく、末尾の数字によって、IPアドレスの迷惑具合（SPAMMERホストなのか、open relayホストなのか）がわかるらしい。（このあたりは要確認）

さて、次に「2.」のAレコードがある場合、「2.」のTXTレコードに何やら付随した情報が含まれるというので早速引いてみる。

おお、何やらURLが記載されてる！ので
http://www.spamhaus.org/query/bl?ip=78.162.167.215

へアクセスすると

と、こんな感じで「PBL」と「XBL」の中にリストされてるよ！って表示される。（さっきの 127.0.0.4と127.0.0.10は「PBL」と「XBL」に対応してるのかも？）

で「PBL」の方をクリックすると

/13でブラックリスト入りしてやがる。ザマーミロ（笑）

「CBL」の方は /32 のようだ。（残念）

どちらにも共通して「ブラックリスト入りしているアドレスレンジ」、「いつブラックリスト入りしたのか？」、「ブラックリストからの削除用リンク（ボタン）」が用意されている。

削除用リンクをクリックすると、

URLの部分の「ip=ブラックリスト化されたIPアドレス」となっている。

もしかして、spamメール送信用とは別のボットかなんかで無差別にブラックリストから削除とか出来ちゃうんじゃないかと心配してHTMLのソースを眺めてみたら

<input name="ip" type="hidden" value="78.162.167.215" />
<input name="confirm" type="hidden" value="dhofgjaamcpnkikepedalhopnhiilgba" />

って赤色文字部分のようなランダムな値を持つinput要素があったので、多分この値とマッチングさせて削除可否を判断してるんだろうな。とか思ったけど、CAPTCHAとか使ってるわけじゃないから、このランダムな値も機械的に読み取れちゃうよな。。

ってことで、ブラックリスト削除ボットのためのブラックリストが出来て・・（以下ループ）

と言いたくなるくらい、まさに今、メールボックスが悲惨な事になってる。
1つのアドレスに 100 ～ 200通ほど、以下の内容のSPAMメールが届いてる。

   洗練された英文ライティングを実現!
    単調な文章も、一瞬で洗練された英文に！
    文法、スペル、句読点のチェックに加え、 英英辞書とシソーラス(同 意語辞典)機能で完璧なライティングを可能に。

          a 文法チェック a 文章の修飾 a シソーラス(同意語辞典)
          a スペルチェック a 英英辞書 a 英文テンプレート

    購入!

件名（Subject）についてはこんな感じ↓でランダム。（といっても幾つかのパターンだが）

差出人アドレスもこんな感じ↓でランダム。

と、こんな感じでこちらは数限りなくありそうなので、このあたりにしておく。

差出人アドレスのドメイン部分（@以降）が存在しないドメインである場合はMTA（Postfix）で拒否するようにしているので、それでも届くということは上記アドレス群のドメインは全て存在するドメインなんだと思う。

で、やっかいなのがリレー元MTAのIPアドレスで、これも以下の通り大量にある。

あー、もう大量にありすぎて晒しきれないのがムカつく（笑）

DNSBL制限もすり抜けてきているので、この、今日1日で数えるだけで200個くらいありそうなIPアドレス全てが未だ世界中のDNSBLにも登録されていない（？）

で、最もイタタタなのが、Postgrey導入によって効果てき面！Dis率90%以上を誇っていたGreylistingも全て突破してきてるぅぅぅ！！

これら突破されたメールがどれくらいの間隔で再送されているのかを調べると、ほぼ全てが「1020秒～1050秒」の間で再送されてきていることがわかった。明らかにGreylistingすり抜け対策だ。

これだけの数のネットワーク上のMTAを駆使して、Greylistをすり抜けるようなメール送信方法を全てのMTAが実装してるってことは、spam送信プログラムがopen relayなMTAを利用しているのではなく、自身がMTAになってSMTPしゃべってるんだろう。
これがいわゆるボットネットを利用したSPAMメール送信ってやつですか？こんなに強烈なのは初体験です。

いよいよベイジアンフィルタ導入せねばならんのか？？

最後に、大量SPAM被害前と後でのPostfixのログのサマリをご覧頂いてお別れします。

■被害前

Grand Totals
------------
messages

    290   received
    144   delivered
      0   forwarded
      0   deferred
      0   bounced
    425   rejected (74%)
      0   reject warnings
      0   held
      0   discarded (0%)

    896k  bytes received
    896k  bytes delivered
    133   senders
    130   sending hosts/domains
      5   recipients
      2   recipient hosts/domains

Per-Day Traffic Summary
    date          received  delivered   deferred    bounced     rejected
    --------------------------------------------------------------------
    Jan 16 2009        88         44          0          0        203
    Jan 17 2009       202        100          0          0        222

Per-Hour Traffic Daily Average
    time          received  delivered   deferred    bounced     rejected
    --------------------------------------------------------------------
    0000-0100           1          1          0          0         25
    0100-0200          82         41          0          0         68
    0200-0300          18          9          0          0         19
    0300-0400           0          0          0          0          3
    0400-0500           1          1          0          0          3
    0500-0600           2          1          0          0          6
    0600-0700           1          1          0          0          2
    0700-0800           1          1          0          0          4
    0800-0900           2          1          0          0          2
    0900-1000           3          2          0          0          4
    1000-1100           4          2          0          0          4
    1100-1200           4          2          0          0          8
    1200-1300           1          1          0          0          3
    1300-1400           5          3          0          0          8
    1400-1500           3          2          0          0          2
    1500-1600           3          2          0          0         14
    1600-1700           2          1          0          0          4
    1700-1800           0          0          0          0          7
    1800-1900           0          0          0          0          4
    1900-2000           1          1          0          0          4
    2000-2100           4          2          0          0          6
    2100-2200           3          2          0          0          9
    2200-2300           3          2          0          0          8
    2300-2400           1          1          0          0          3

■被害後

Grand Totals
------------
messages

   1038   received
    517   delivered
      0   forwarded
      0   deferred
      0   bounced
   1021   rejected (66%)
      0   reject warnings
      0   held
      0   discarded (0%)

   3628k  bytes received
   3628k  bytes delivered
    504   senders
    497   sending hosts/domains
      5   recipients
      2   recipient hosts/domains

Per-Hour Traffic Summary
    time          received  delivered   deferred    bounced     rejected
    --------------------------------------------------------------------
    0000-0100           0          0          0          0          0
    0100-0200           0          0          0          0          0
    0200-0300         104         52          0          0        122
    0300-0400         133         66          0          0         80
    0400-0500          32         16          0          0         97
    0500-0600         160         80          0          0        126
    0600-0700          24         12          0          0         54
    0700-0800          38         19          0          0         10
    0800-0900           8          4          0          0         19
    0900-1000          54         27          0          0         61
    1000-1100          22         11          0          0         17
    1100-1200           6          3          0          0          5
    1200-1300           0          0          0          0          4
    1300-1400           6          3          0          0         15
    1400-1500          46         23          0          0         47
    1500-1600          16          8          0          0          7
    1600-1700          15          7          0          0         44
    1700-1800          40         20          0          0         47
    1800-1900         283        140          0          0        248
    1900-2000          51         26          0          0         17
    2000-2100           0          0          0          0          1
    2100-2200           0          0          0          0          0
    2200-2300           0          0          0          0          0
    2300-2400           0          0          0          0          0

※1/22追記

SPAMをはじめとする「迷惑メール」発信元のIPアドレスをブラックリスト化したものを「RBL」と今まで呼んでたけど、どうやらメールに限らず、色々なプロトコル上で迷惑な振る舞いをするIPアドレスの一覧データベースのことを「DNSBL」と呼んで、「RBL」は「DNSBL」のイチ実装に過ぎず、かつ、登録商標を持つシステム名に過ぎない（※1）みたいなので、本投稿中の表記を「RBL」⇒「DNSBL」へと修正した。

※1  携帯用音楽プレーヤーのことをウォークマン（今ならiPodか？）、ゲームのことを「ファミコン」と呼ぶのと同じようなもんか？

Apacheのリアルタイムなアクセス統計情報を表示させるために「mod_status」を利用する。（※おそらく大抵のconfigでデフォルトでこの記述があるはず）
まずは、mod_statusを読み込む必要があるため、httpd.confに以下を追加する。

続いて、ステータスレポート（リアルタイムの統計情報）を表示させたいコンテキスト内（サーバ設定ファイルorバーチャルホスト）で

Status を使用可能にする

example.com ドメインからのブラウザのみに対して ステータスの報告を使用可能にするには 以下のコードを httpd.conf 設定ファイルに追加します

<Location /server-status>
SetHandler server-status
Order Deny,Allow
Deny from all
Allow from .example.com
</Location>

引用元: mod_status - Apache HTTP サーバ

上記マニュアルにある通り、以下の設定を記述する。

<Location /server-status>
    SetHandler server-status

    Order Deny,Allow
    Deny from all
    Allow from 許可するホスト または IPアドレスのリスト
</Location>

で、Apache再起動の後に、http://○○○/server-status/ へアクセスすると・・・

のような画面が表示される。
表示される内容は以下の通り。（マニュアル抜粋）

但し、このままでは表示出来る情報がそれほど多くないので、

とすることで（この設定のコンテキストは「サーバ設定ファイル」のみ/バーチャルホスト内では使えない）

上記の通り「ExtendedStatus Off」の時と比べて

上記情報が追加される。
これらの情報があれば問題発生時に色々と切り分け出来るのだが、その切り分け方法については後日・・・（多分書かない）

ムカつくアイツが席を立ったならば、彼のunixコンソール上で以下のコマンドを実行だ！

Ctrl-l あたりでとりあえず画面をキレイにしておくことも忘れるな。

情け

情け

情け

情け

彼が本気で困っている事が窺える場合は耳元でそっと「Ctrl-D」と囁くべし。

suexec使うからにはセキュリティ上必要な機能だっていうのはわかるんだけど、特にCentOSのhttpdパッケージに含まれるsuexecは「–with-suexec-docroot=/var/www」なんかでコンパイルしてあるもんだから、CentOSの流儀ではsuexecを使用する場合、DocumentRootを/var/www以下に設定しないといけない。

パッケージ如きにディレクトリ・レイアウトを強制されるのもムカつくのだが、じゃあ、最初からパッケージ使わずにソースからインストールすればいいじゃん？というのはごもっともなのだが、やっぱメンテナンス性を考えるとパッケージの利便性を選択してしまう。（昔は何かよくわからずにとりあえず最新を追いかけたかったからソースインストールばかりしてたけど）

だったら、せめてSRPMから再ビルドすれば？って話なのだが、もちょっとお手軽（？）に件の設定を変更したい。所詮、設定値なのだから。

ということで、ちょっと強引な方法を紹介する。

用意するものは

• suexec
• emacs

そう、

emacsをバイナリエディタとして使用して、バイナリに含まれる値を変更してしまおう。

具体的なやり方は以下の通りである。なお、もちろん動作については一切保証しないので自己責任で試してね。

まずは何か問題が発生してもすぐに切り戻せるようにsuexecをバックアップしよう。

suexecの現在の設定値を確認する。

そして、emacs登場。

バイナリエディタとして使用するために「hexl-mode」としよう。

emacs上で「M-x hexl-mode」とする。

こんな感じ

CGI実行可能なトップディレクトリのパス（今回は /var/www）を検索する

カーソルを合わせて（画像の中の緑色の部分）

今回 /var/www を /home へ変更するとして、「/home」と入力

画像の例だと、/homewww となっているので、wwwの部分はnullにしよう。
emacs上で「M-x hexl-insert-hex-string」として

nullにしたい各文字毎に「00」を入力、
※ 画像中では www を null に変えたいので 「000000」と入力した

「/var/www」が「/home…」となったことを確認して保存（ C-c C-s ）すると下記のように聞かれるので「y」すると

conding systemを選べとか言われるので、バカヤロー、バイナリだこのやろーということで「no-conversion」と入力

無事保存出来たらemacsを終了しよう。

さて、動作確認のために以下のコマンドを実行すると

あとは

上記のようにsuexecを差し替えて適当に動作確認して下さい。suexecのログもちゃんと確認してね！

#!/bin/sh

cat << EOF
	hoge
	fuga
EOF

と書いて、これを実行すると

	hoge
	fuga

という出力となる。

ヒアドキュメントでは識別文字（この例ではEOF）から識別文字までの間を「忠実に」出力するわけなので、この出力で正しい。

このため、実行結果には反映させたくなくとも、スクリプト内の「見やすさ」のためにヒアドキュメント内で空白文字を使うと、予期せぬ（この場合は忠実であることが人間にとって予期せぬ＝期待しないというだけだが）こととなる。

ヒアドキュメントとはそういうものだ、と長らく思っていたが、実は実に簡単な方法での解決方法があった。

以下の通り実行する。

#!/bin/sh

cat <<- EOF
	hoge
	fuga
EOF

赤色文字の「-」を追加しただけだが、たったのこれだけで

hoge
fuga

前述の例のように先頭に空白文字は含まれず、このように都合のいい出力となる。
sh(1)によると

Here Documents
       This  type  of  redirection  instructs the shell to read input from the
       current source until a line containing  only  word  (with  no  trailing
       blanks)	is seen.  All of the lines read up to that point are then used
       as the standard input for a command.

       The format of here-documents is:

	      <<[-]word
		      here-document
	      delimiter

       No parameter expansion, command substitution, arithmetic expansion,  or
       pathname expansion is performed on word.  If any characters in word are
       quoted, the delimiter is the result of quote removal on word,  and  the
       lines  in the here-document are not expanded.  If word is unquoted, all
       lines of the here-document are subjected to parameter  expansion,  com-
       mand  substitution,  and arithmetic expansion.  In the latter case, the
       character sequence \<newline> is ignored, and \ must be used  to  quote
       the characters \, $, and `.

       If the redirection operator is <<-, then all leading tab characters are
       stripped from input lines and  the  line  containing  delimiter.   This
       allows  here-documents within shell scripts to be indented in a natural
       fashion.

とあるようにリダイレクトが「<<-」である場合はそれぞれの行の行頭にあるタブは全て取り除かれる、とある。
試してみたところ、タブが複数あっても全て取り除かれる、またタブではなく空白文字（スペース）ではNG（取り除かれない）であった。

以上の内容をBシェル触りだして10年ほど経つ今日初めて知った。（恥）

/etc/postfix/master.cfで

とかやって

smtp(25)->amavisd(10024)->smtp(10025)の時、postfixのlogを見るとsmtp(10025)でちゃんと元のSMTPクライアントのIPアドレス拾えてるんだけど。

smtp(25)でsmtp_send_xforward_command=yesにする必要ないのかな？

1/15追記

client(x.x.x.x)  -(1)-> smtp(25) -(2)-> amavisd(10024) -(3)> smtp(10025) の時、

amavisdは(3)でsmtp(10025）に対して XFORWARD ADDR=x.x.x.x を送っていることがログから確認出来た。

またtcpdumpで(2)の通信をキャプった結果、以下の通りであった。

CentOS 5のパッケージ「amavisd-new-2.5.4-1.el5.rf（DAGリポジトリ）」に含まれる amavisd.conf-sample を見ると

という記述があったので、amavisd-newにfeedするPostfix serviceであるところのsmtp(25)の設定で ‘-o smtp_send_xforward_command=yes’ を有効にしないといけないのかな？と思ったのだけれど、どうやらこの記述は smtp(25)に設定したcontent_filter経由で、例えば content_filter=amavis-smtp:127.0.0.1:10024 とした時のSMTPクライアントである amavis-smtpに設定するものであるようだ。

なるほど、確かにsmtpd_proxy_filterはその名の通り SMTPのProxyであるので、デフォルトでXFORWARDを付与してくれており（HTTP ProxyがProxy先にX-Forwarded-Forを付与するイメージ）、content_filterの場合は SMTP Proxyというわけではないので（結果、SMTP Proxyとして動作するにせよ）明示的に smtp_send_xforward_command=yes を設定する必要がある、と。

よくよくPostfixのマニュアルを読むと

と書かれている。まさしくSMTPエージェント（クライアント）の設定項目であった。

smtpd_proxy_filterを設定したSMTPデーモン（サーバー）もProxyする際はまさにSMTPクライアントとして動作するのだけど、その場合はデフォルトでXFORWARDを付与してくれるのでsmtp_send_xforward_command=yesを設定する必要はない、というのが結論。

echo "test" 2>&1

その逆で、標準出力を標準エラー出力に出力（リダイレクト）する方法はあまり知られていないが、以下の通りとなる。

echo "test" >&2