メール送信ドメイン認証 SPF と Sender-ID の設定 (4)
それでは、詐称された場合の動作がどうなるか検証してみましょう。
まず、my.example.jp 側では、masquerade しない設定で、
From: too <too@vmfreebsd.my.example.jp>
でメールを送信する設定とします。また、ドメイン全体の TXT レコードを削除しておきます。
my.example.jp のゾーンファイル
vmfreebsd# cat /etc/namedb/my.example.jp.zone
$TTL 3600
@ IN SOA vmfreebsd.my.example.jp. root.vmfreebsd.my.example.jp. (
7 ;serial
150 ;Refresh
900 ;Retry
300 ;Expire
300 ) ;Minimum
IN NS vmfreebsd.my.example.jp.
IN MX 10 vmfreebsd.my.example.jp.
IN TXT "v=spf1 mx a:vmfreebsd.my.example.jp -all"
localhost IN A 127.0.0.1
vmhost IN A 10.1.2.1
vmfreebsd IN A 10.1.2.2
IN MX 10 vmfreebsd.my.example.jp.
IN TXT "v=spf1 a:vmfreebsd.my.example.jp. -all"
vmredhat IN A 10.1.2.3
vmfreebsd5 IN A 10.1.2.4
|
これで、vmfreebsd から送信すると受信メールは以下のように両方とも合格になりました。
From too@vmfreebsd.my.example.jp Tue May 17 11:55:13 2005
Authentication-Results: mail.example.com from=too@vmfreebsd.my.example.jp; sende
r-id=pass; spf=pass
X-SenderID: Sendmail Sender-ID Filter v0.2.7 mail.example.com j4H2tDYV014705
Date: Tue, 17 May 2005 11:52:02 +0900 (JST)
From: too <too@vmfreebsd.my.example.jp>
To: too@mail.example.com
Subject: test A mail
test A
この状態で、vmfreebsd と同じセグメントで別マシンの、vmredhat からメールを送ってみます。
From too@vmredhat.my.example.jp Wed May 25 17:13:42 2005
Authentication-Results: mail.example.com from=too@vmredhat.my.example.jp; sender
-id=neutral; spf=neutral
X-SenderID: Sendmail Sender-ID Filter v0.2.7 mail.example.com j4P8DgKJ031061
Date: Wed, 25 May 2005 17:15:22 +0900
From: Toru Morimoto <too@vmredhat.my.example.jp>
To: too@mail.example.com
Subject: from vmredhat
test
すると、sender-id も spf も「何ともいえない」という結果になりました。これは、vmredhat については何もDNSが言及していないからのようです。
では、ぜんぜん別のアドレスで詐称メールを送ってみます。ルータに1本足を追加して、以下のような構成にしました。
一番上に書いた evil.example.net が詐称メールを送る悪いやつだと思ってください。当然ですが、正当な差出人でのメール転送ができることは確認済みであるとします。
（余談。準備作業で一番はまったのは、vmfreebsd と mail.example.com で、DNS の forwarder を２つ指定しないといけないことです）
ではいろんなパターンで詐称メールを送ってみます。my.example.jp のゾーンファイルと見比べながら結果をご覧ください。
（例1）evil.example.net の sendmail.cf で (mcの) MASQUERADE_AS を利用して From: フィールドを詐称
From too@evil.example.net Wed May 25 13:00:56 2005
Authentication-Results: mail.example.com from=too@my.example.jp; sender-id=fail
(NotPermitted); spf=neutral
X-SenderID: Sendmail Sender-ID Filter v0.2.7 mail.example.com j4P40q82030940
Date: Wed, 25 May 2005 12:59:31 +0900
From: too@my.example.jp
To: too@mail.example.com
Subject: test for fake
fake mail
この場合は Sender-ID で詐称を検出できました。
（例2）hostname で得られる自分のホスト名を実在しないホスト名にして MAIL FROM を詐称。（RedHat Linux では /etc/sysconfig/network, FreeBSD では /etc/rc.conf で指定されている ）
From too@evil.my.example.jp Wed May 25 14:09:32 2005
Authentication-Results: mail.example.com from=too@my.example.jp; sender-id=fail
(NotPermitted); spf=fail (DomainDoesNotExist)
X-SenderID: Sendmail Sender-ID Filter v0.2.7 mail.example.com j4P59WjJ030956
Date: Wed, 25 May 2005 14:08:10 +0900
From: too@my.example.jp
To: too@mail.example.com
Subject: test for fake
fake mail
この例では SPF でも詐称を検出しました。
（例3）hostname で得られるホスト名を、実在するホスト名で詐称。
From too@vmredhat.my.example.jp Wed May 25 15:22:15 2005
Authentication-Results: mail.example.com from=too@my.example.jp; sender-id=fail
(NotPermitted); spf=neutral
X-SenderID: Sendmail Sender-ID Filter v0.2.7 mail.example.com j4P6ME2N030967
Date: Wed, 25 May 2005 15:20:33 +0900
From: too@my.example.jp
To: too@mail.example.com
Subject: test for fake 3
fake mail 3
詐称されているのに SPF が neutral というのは今ひとつな判定結果ですね。これは DNS の設定に起因しているようです。そこそこ大きな規模のサイトではメールを送信することのないホストが A レコードの多くを占めているはずですので、これに対処する方法は何かあるとは思います。引き続き調べてみます。
（例4）hostname で得られるホスト名を、TXTレコードが記述されているホスト名で詐称。
From too@vmfreebsd.my.example.jp Wed May 25 15:28:36 2005
Authentication-Results: mail.example.com from=too@my.example.jp; sender-id=fail
(NotPermitted); spf=fail (NotPermitted)
X-SenderID: Sendmail Sender-ID Filter v0.2.7 mail.example.com j4P6Sa7M030975
Date: Wed, 25 May 2005 15:27:15 +0900
From: too@my.example.jp
To: too@mail.example.com
Subject: test for fake 5
fake mail 5
今度は期待した結果になりました。
最近流行の MyDoom,Netsky などのウイルスが送信するメールで、詐称であることを証明するためであればこれだけでも結構効果はあると思われます。
では次に、my.example.jp の DNS がとまった場合の処理について考えてみます。通常、SOHOなどで内部から送信する際に参照するサーバと外部公開しているDNSサーバが一緒の場合、そもそも my.example.jp からメールが送信できないわけですが、セキュリティ向上などのため、内部参照と外部参照でDNSサーバを分けているケースだと、内部からメールは送信できるが、外部からDNSが引けないことが有りえます。
さて、sid-filter はこのようなオプションで起動されていました。
/usr/bin/sid-filter -h -l -p local:/var/run/sid-filter -r 0
添付したドキュメントに記したように、デフォルトでは DNS タイムアウトは5秒です。受信サーバが my.example.jp との通信ができないと、タイムアウトすることになります。このときの挙動も受信側のサーバで定義しますが、デフォルトだと
May 23 14:26:04 mail sendmail[29651]: j4N5PIfR029651: Milter: data, reject=451 4
.3.2 Please try again later
|
こういった形で一旦受信拒否することになるようです。したがって、送信側ドメインでは短時間であっても外部から「全く」DNSが引けないという事態は極力回避しなければなりません。通常は大きなサイトだとプロバイダにセカンダリ DNS を置いていたりするでしょうが、自サイトのメンテナンスなどで DNS を止める時にはちゃんとセカンダリが動作しているか確認しておきましょう。受信側ドメインでは、こういった受信拒否が複数のドメインで頻繁に発生するようならタイムアウト値のチューニングをしたほうがよいと思われます。
また、そう簡単にはできないことですが、DNS hijack には無力です。過去にはこんな事件もありました。もっとも本当に DNS hijack が行われれば、影響を受けるのはメールだけではないのでドメイン認証どころの騒ぎではないですが…。
おまけとして、SPF のサイトにあるフォームについてちょっとだけ説明を加えてみたいと思います。アドレスは http://spf.pobox.com/wizard.html でした。
ここでは、実際に外部から名前が引けるドメインであれば、ドメイン名を一番上に入れるだけで MX などを調べてくれます。このフォームにアクセスした IP から逆引きでドメインが特定できればそのドメイン名が最初に入るはずです。
設定項目がいくつかあるので先頭から説明します。
(1) a レコード
ドメイン名そのものに対する a レコードがある場合は追加されます。SOHO の場合や、http://ドメイン名 で Web サーバを公開している場合が該当します。
(2) mx レコード
MX レコードを持つサーバはメールを受信するサーバと考えられますが、このサーバで送信も行っていると考えていいかどうか尋ねています。
(3) ptr レコード
DNS 逆びきした際に my.example.com で終わる名前のものはすべて信頼してよいかどうか尋ねています。かなり緩い設定ですが、最初に動作を確認するためにはこういうオプションも便利だと思います。
(4) a: 欄
上で定義した以外にメールを送信するサーバのホスト名をFQDNで指定します。
(5) mx: 欄
上で定義した以外にメールを送信するサーバのドメイン名を指定します。そのドメインの MX レコードを持つサーバはメールを送信することが正当であるとみなされます。
(6) ip4: 欄
上で定義した以外にメールを送信するサーバのIPアドレスを指定します。CIDR形式でアドレスブロックを指定することもできます。
(7) include 欄
メールサーバなどを外部の ISP などに置いている場合、ISP のドメイン名を追加します。
(8) all
my.example.jp ドメインでメールを送信するサーバは (1) - (7) で指定しつくされているかどうかのフラグです。どういうわけか、最も厳格な -all オプションは設定できないようです。何か勘違いしているのかな？
これらの値を設定すると、DNS に付け加えるべき項目が表示されますが、BIND を使っている場合の注釈を日本語訳しておきましたので、参考にしてください。
If you run BIND
Paste this into your zone file:
my.example.jp. IN TXT "v=spf1 ip4:10.1.2.0/24 mx mx:my.example.jp ~all"
When a mail server sends a bounce message, it uses a null MAIL FROM: <>,
and a HELO address that's supposed to be its own name. SPF will still operate,
but in "degraded mode" by using the HELO domain name instead. Because this
wizard can't tell which name your mail server uses in its HELO command, it lists
all possible names, so there may be multiple lines shown below. If you know which
hostname your mail server uses in its HELO command, you should pick out the
appropriate entries and ignore the rest.
訳：メールサーバが差し戻しメッセージを送るときには、（訳注：RFCの規定により）MAIL
FROM は <> の NULL 形式になる。HELOを交換するときのアドレスは自分自身の名前
（ホスト名）になるはずである。SPF はこの場合にも機能するが、degrated（訳注：弱い）
モードになり、HELO ではホスト名ではなくドメイン名を使用する。というのも、このウイ
ザードではそのHELOコマンドの中でどのメールサーバのホスト名を使うのか知る方法がない
から（訳注：複数MXを持ち、特にプライオリティが同じサーバがいるサイトでは、誰が
bounce mail を出そうとしているのか特定できない、といった意味でしょうか？ 指摘を
お待ちしております）。もしこういった時のHELOコマンドで伝えるべき適切なホスト名が
あるのなら、そのエントリを抜き出して後は無視しましょう。
So this should also appear in DNS. You may or may not be in charge of the DNS for
these entries; if you are, add them.
訳：ということで、これらのホストはDNSにないといけない。上に書いた状況に依存するが、
DNSで管理されているなら次のようなエントリを追加しましょう。
vmfreebsd.my.example.jp. IN TXT "v=spf1 a -all"
|
最後に
Internet Week などの講師としても有名なトランスコスモスの安藤さん( http://www.ppml.tv/ )が書いておられますが、このテクノロジは「送信者認証」ではありません。メールの送信元のドメインを認証しているだけです。したがって、
From: too@my.example.jp
というメールについて証明されるのは「my.example.jp」ドメインの管理者が承知しているサーバから送信されていることであって、「too」というIDの人が認証を受けた上で送信しているということではありません。送信者の身元確認には電子署名など別の仕組みが必要です。
また、すでにいくつかのメディアの記事でも指摘されている通り、「送信ドメインが確か」であることと「メールの内容が SPAM でないこと」は無関係です。送信ドメイン認証は SPAMMER が身元を偽りにくくする仕組みを提供しているに過ぎません。要は、SPAM 業者だって Sender-ID や SPF を用意する ことでしょう。つまり、そのドメインそのもののレピュテーション（評判）を考慮する必要があります。これが送信ドメイン認証に求められている「次のステップ」です。実際に SPAM 判定に利用するのであれば、可能な限りの手段を利用し、DNSBL や ORBS などのデータベースの情報もあわせて判断するようにすべきでしょう。また可能であれば送信ドメイン認証についても DomainKeys や必要に応じて他の規格もサポートする努力も必要になるかと思います。その点、ベンダーの都合に振り回されて Sender-ID が規格策定の途上で揉めているのは残念としか言い様がありません。
さらに、実際受信メールに対して SPAM の受信制限をするとなると、必ず発生しうる「誤判定」の問題にどう対応するのか、管理者や情報システム管理部門としてのポリシーを制定し、ユーザーに理解を求める必要があります。特に正当なメールを SPAM と判定した場合のリスクをユーザに周知しなければなりません。
特に SPF も Sender-ID も、どういったケースでneutralになるのかが私自身ちゃんと検証しきれませんでした。実際に受信側ドメインとして SPF/Sender-ID の設定をするとなれば、星の数ほどあるドメインを相手にこれらの検証をすることになります（もっとも現時点では相手のドメインが SPF/Sender-ID に対応していないことも多いでしょうが）。運用に必要なこういった挙動についての情報があまり Web でも見つかりませんでした。普及を考えた場合に鶏と卵の関係になっているこの種の情報収集は管理者諸氏にとって頭の痛い問題であることに違いありません。
SPAMMER との戦いはいたちごっこになることが予想されます。今後も新技術から目を離さずにいなければならないでしょう。
--