この5/15の12:00あたりから、新しいタイプのスパム送信手法により、多くのメールサーバが自サーバから多数のスパムを送信されてしまう攻撃を受けており、その影響でメール送信の遅延や障害が発生していました。
ここで使われたスパム送信手法のことを「サブミッションスパム」と呼ぶことにします*1。
このサブミッションスパムがどうやって送信されていると考えられるか、またその対策について説明します。
各社の状況
まず、各ISPなどの障害報告をリストアップしてみました。
【シナプス】シナプスメール遅延発生 - 鹿児島のプロバイダSYNAPSE（シナプス）
http://www.synapse.jp/info/cgi/?trouble2012051401【ケーブルテレビ可児】メール送受信障害のお知らせ（５報）（午後5時5分） - CTK ケーブルテレビ可児
http://www2.ctk.ne.jp/support/trouble/detail/id=13054【NMC CASH RADAR Pro】（復旧）メール通信の障害発生につきまして
http://www.nmc.ne.jp/crp/osirase/SN120515_2.htm【ジェイコム】ケーブルテレビのJ:COM (ジェイコム：ジュピターテレコム) 【復旧】メール送受信不安定について
http://www.jcom.co.jp/notice/_46121.html【DTI】DTI | アナウンス
http://info.dti.ne.jp/announce/docs/20120516_07.html【ジェットインターネット】障害発生のご報告(2012/05/15)｜相談できるプロバイダー-ジェットインターネット｜ジェットインターネット
http://www.jet.ne.jp/index.php?id=332【NetLaputa】NetLaputa Secretariat: 障害情報
http://notification.paslog.jp/category/82717.html【フューチャースピリッツ】メールサーバー配送遅延復旧のご報告｜フューチャースピリッツのレンタルサーバー・ホスティングサービス
http://server.future-s.com/trouble/2012/05/post_25.html【ぷらら】plala メンテナンス・故障情報（東京都）: 【故障】メール送信（海外からの接続） http://www.plala.or.jp/support/network/kosyo/tokyo/?entry_id=122635
他にもたぶん多くのISPのメールサーバで、このスパムによる障害対応が必要だったのではないかと思います。
どうやって出しているのか
今回のサブミッションスパムがどうやって出されたのかを説明するのに、まず従来のスパムがどうやって出されているかを説明します。
従来のスパムは主に、botnetと呼ばれる、ウイルスに感染して遠隔操作出来るようにされた多数のPCから、直接送信先のメールサーバの25番ポートに対してメールを送り付ける、という方法で行われてきました。
【botnetからのスパム送信】
これに対抗するため、(特に日本では)OP25B(Outbound Port 25 Blocking)という、外部への25番ポートへの接続を塞いでしまうことで、botから「スパムを出させない」手法が導入されてきました。
【OP25Bでのスパム対策】
OP25Bが導入されている場合、自分が接続に利用しているISP以外のメールサーバからメール送信を行う場合は、通常サブミッション(Submission)と言う587番ポートを使った接続が使われます。(図の左下PCの例)
サブミッションではユーザ名とパスワードで認証を行なってからメール送信を行うため、単にbotからポート587に接続してメール送信を行おうとしても出来ません。
今回のサブミッションスパムでは、このサブミッションを使ってメールの送信を行ってきました。
【サブミッションスパムの出し方】
ということは、なんらかの手法でユーザのメールアカウント(ユーザIDとパスワード)を取得しているということです。
ユーザIDとパスワードが取得されてしまえば、メールサーバ側では正規のユーザかbotかを見分けることは出来ないため、メールサーバの管理者側はアカウントを乗っ取られていると思われるユーザIDをログから調べ、そのアカウントIDのパスワードを変更することで新規のスパム送信を止めたはずです。
どうやってアカウントを取得したか
どうやってユーザのアカウントを取得したかは、具体的な証拠はありませんが、状況からみて以前に該当ユーザのPCにウイルスを感染させて取得した可能性が高いと考えられます。*2
これは2009年頃に流行ったガンブラー(GENOウイルス)のことを思い出してもらうと良いでしょう。
ガンブラーとは、ホームページを見ただけで感染してしまうような脆弱性をついて広まったウイルスで、感染したユーザPCからFTPアカウントを盗み出してbotnetの管理者に送っていました。
そしてそのFTPアカウントを他のbotが利用して、感染したユーザの持っているホームページを、新たな感染元となるように改ざんして広めていきました。
この時に、FTPのアカウントだけではなくメールのアカウントも取得していた可能性は十分ありますし、他のウイルスもメールのアカウントなどを取得するように作られているものも多いでしょう。
そしてそういったアカウント情報のリストは、アンダーグラウンドで売買されているそうです。
こうやって過去に(ガンブラーに限らず)ウイルスにより取得されたアカウントを用いてアクセスしていると考えられます。
対策
サブミッションスパムはこちらのメールサーバからスパムを出すため、メールサーバのキューにエラーメールが大量にたまり、メールサーバの負荷が高くなって、一般ユーザのメールも遅延しだして気が付きます。
メールログからスパムのキューIDなどで特定して、スパマーに盗用されているユーザIDを割り出します。
盗用されているIDのパスワードを変更してしまえば新たなスパム送信はできなくなります。
そしてキューに溜まっているスパムを削除すれば遅延は解消されます。(頑張りましょう…)
また大量のスパムを出すと、DNSBLや海外の大手ISPから、メールサーバのIPをスパム送信のブラックリストに入れられてしまうことがあります。
この場合、特定のメールサーバに対してメールが届かないということが起こるので、そういったところを調査してブラックリストからの解除を申請する必要があります。
サブミッションの認証ログ(postfixだとsasl_usernameあたり)を抜き出すと、接続元のIPとFQDNがわかります。
日本のISPはほとんど逆引き設定をしているため、接続元のFQDNが「.jp」じゃない場合、海外からの接続である可能性が高いです。
海外から接続してくるユーザは全体から比べればごく少数ですから、それだけでbotからの接続である可能性が高いです。
またbotは大量にメールを送ることを意図した設計をしているため、本来はメールサーバからの返答を待たなければいけないタイミングで、すぐに送信を送ってきたりします。
その動きのクセを逆に利用して、遅延を掛けることでスパムの受信をフィルタする手法をtarpittingといいます。
自分はこのtarpittingを、怪しい接続に対してだけ選択的に掛ける、taRgreyとStarpitというスパム対策手法を提案しています。
この考え方は、このサブミッションスパムにも応用が出来る可能性が高いです。
つまり、サブミッションの接続に対してFQDNが怪しい(自ネットワークではない、逆引きが「.jp」じゃない等)時にだけ、tarpittingを掛けるわけです。
こうすると、自ネットワークの接続を利用しているユーザや、国内ISPから接続しているユーザの場合はこれまで通りすぐにメール送信でき、海外の接続からでもメール送信時に数秒待たされるだけで送信可能です。
Postfixの場合だと、master.cf の submission の設定に -o で smtpd_recipient_restrictions などでチェックを増やしてやり、該当する接続に対してだけ sleep を何秒か掛けてやればよいでしょう。
(追記)
twitterで@muses_pさんからレポートいただきました。
https://twitter.com/#!/muses_p/status/203360244187922432
手元のサーバだとunknownに対して5秒のsleepでほぼ止まってます。3秒だと駄目でした。
とのことです。
たぶん、.jpに対しては1秒、それ以外は5秒あたりがいいんじゃないかと思っています。
他にも良さそうな設定などあればレポートいただけますとありがたいです。
(/追記)
(追記)
2014/12 に Postfix Advent Calendar 2014 用に、この対策をするための具体的な設定方法を書きました。
Postfixでのサブミッションスパムの簡易対策方法 - モーグルとカバとパウダーの日記
http://d.hatena.ne.jp/stealthinu/20141211/p1
(/追記)
しかしこの手法も、このスパマーがちゃんとこちらの応答を待たない、ということを前提としたものなので、ちゃんと待つサブミッションスパムが出てくると簡単に破られます。
その時には、policydなどのスロットリング(流量制限)が出来るフィルタを導入して対抗することになります。
感想
実はこの流れ(OP25Bの普及→Submissionを使ったスパム送信)は、OP25Bの導入が進められていた時点ですでに想定されていたことでした。
当時、JEAGがOP25Bすすめようって頑張ってた時の説明資料にも、そういうロードマップがあって、そこで想定されていた対策はスロットリングだったように思います。*3
が、最近のスパムの主戦場はすでにメールからSNSへと移行されつつあり、自分はもはやメールに対して新しい手法は使われてこないかなと思っていました。
今後もまだ何年かは、スパムとの戦い続きそうですね。
(追記)
JPCERTからこの件に関してと思われる、情報提供のお願いが出ていました。
どうやってメールアカウントが取得されたのかについて、情報を出して欲しいとのこと。
あと、このニュースリリース見ると、去年2011年8月頃からこの手のスパム送信が行われていたそうです。
そうなると、なんらかの法則性(IPだとかAS番号だとか？)にそって順繰りにMTAが攻撃に使われてたのではないかと思います。
Telecom-ISAC Japan News Release 2011/12/5
(/追記)
（追記）
友人のいる会社で、特にこの件を意識した対応をしたアップデートをされてた。
IPアドレスによる大量メール送信のチェック以外に、認証ユーザに対してのスロットリングも行うとのこと。
急増するISPへの攻撃に対し、SpamGuardのメールシステム保護機能拡充版を緊急リリース
〜 SMTP認証によるメール大量送信に対してメールシステムを保護する機能を追加 〜
（/追記）
