Ubuntu18.04 迷惑メールの取り扱い

久しぶりに迷惑メールが届いたので、なんでかな？と調べてみたら、逆引きできてまともっぽい名前のサーバーからメールが送られてきていることが判明。
4:17に届いたメールの調査を6:17頃から始めて、7:58にこのサーバーがPing応答する状況を確認した。フィッシングメールなので当然の振る舞いか。

ウチはS25Rの考え方を適用させていただいており、逆引きできないサーバーや、特徴的なURLのサーバーからのリレーを受け付けない。
これは正しく動作しているし、割と大手っぽいサービスのメールも調べてみるとちょっと？な感じだったりして、これをいったん保留すること自体おかしな感じはしない。必要なメールなら、ホワイトリストに入れればいい。

環境
対策
今回届いた迷惑メールの特徴
特徴を再現したメール送信テスト
- Gmailで迷惑メールと識別されること(未解決)
- DNSキャッシュクリア
- SPF
- DKIM
- DMARC
- 宅内DNSサーバー設置
- ログレベル

やることは多くないけれども、よそに迷惑を掛けずに確認しようとすると、それなりに工数が掛かる印象だった。

環境

一般には、安心してメールを受け取ってもらうための仕組みとして導入されるSPF、DKIM、DMARCを受信の観点でテストしながら取り込んでいく。

Ubuntu 18.04 と銘打っているけれども、20.04でも全く問題なく動作すると思われる。

ホスト	IPアドレス	備考
mx.myhome.local	192.168.0.77/24	今回対策するサーバー。
dns.myhome.local	192.168.0.11/24	宅内で稼働するDNSで、各種対策の為に公開するレコードを取り扱う。
temp.hogeserver.hogeddns.jp	192.168.0.2/24	テストメールを送信するサーバー(1台目)。後からテスト用のDNSを同居させた。
work.hogeserver.hogeddns.jp	192.168.0.3/24	テストメールを送信するサーバー(2台目)。
hoge.myhome.local	192.168.0.55/24	メールを送ったり受け取ったりして試すクライアント。

すべてのホスト名とIPアドレスは記事のためにマスクしたもの。

今回の記事は「対策」から始めて、問題の迷惑メールがどのようなメールだったのか「分析」し、その特徴を持つメールを送信する「テスト」を行って、その結果を「対策」にフィードバックするやり方で整理した。

そのため、例えばGmailで迷惑メール判定されないようにするという観点では直接的な手順になっていないが、送られてきたメールをどのように見ているのかということを理解するのに役立つかもしれない。

受信の対策を固めた先で、テストの手順を整理して組み込んでいけば、安全と見なされるメールを送信することができるかもしれない。
これらのフィルターは表裏一体、自分は送信者でもあるけれど、受信者でもあるのだから。

対策

対策を考える上で、どのようなものがあって、仕組みと手順を知ることは重要なので、こうしたサイトで勉強させていただいた。
SIDN / Hands-on: implementing SPF, DKIM and DMARC in Postfix

S25R、SPF、DKIM、DMARCの順でフィルターを掛けていく。

HELOの段階でリジェクト

当該サイトからのアクセスは現在必要がないので、接続された段階で拒否する。
今回の迷惑メールはここから先で試そうとする各種手続きをしっかり踏んでいるので、正当と判断される可能性が高く、これが手っ取り早い対策。

うちのサイトはS25Rを活用させていただいていて、そこにこのサイトを入れる。
とはいえS25Rに限った対策というわけではなく、Postfixの機能を活用したリジェクト。

/etc/postfix/main.cf

smtpd_helo_restrictions =
    permit_mynetworks
    reject_invalid_helo_hostname
    check_helo_access regexp:/etc/postfix/helo_restrictions

※元々の設定に影響がないように注意して最後の行を加える。

2件の迷惑メールは、この日(2021/09/18、9/19)のドメイン登録状況、IPアドレス、DNSの状態からフィッシングサイトと判断。

/etc/postfix/helo_restrictions

# Illegal HELO command blocking specification
# Provided that your mail server's IP address is 223.12.34.56 and its
# acceptable domain name is "example.com", specify as follows:
#
#/^\[?223\.12\.34\.56\]?$/                      REJECT
#/^(.+\.)?example\.com$/                        REJECT
/^(.+\.)?desctrl\.com$/                         REJECT
/^(.+\.)?mnjzw\.com$/                           REJECT

設定を反映。

$ sudo systemctl reload postfix

ここにメールが送られてくると、このようなログが残る。

Sep 20 07:03:14 mx postfix/smtpd[29790]: NOQUEUE: reject: RCPT from temp.hogeserver.hogeddns.jp[192.168.0.2]: 554 5.7.1 <temp.hogeserver.hogeddns.jp>: Helo command rejected: Access denied; from=<spammer@temp.hogeserver.hogeddns.jp> to=<hoge@myhome.local> proto=ESMTP helo=<temp.hogeserver.hogeddns.jp>

当該のサイトが、接続時に名乗るホスト名を変えるまで有効。

SPFレコード確認

Sender Policy Framework(SPF)のポリシー判定を導入する。
SPFはHELO/EHLOと、MAIL FROMを検証し、メールをリジェクトしたり、ヘッダにReceived-SPFとして検証結果を追記したりする。

インストール手順はここに書かれている。
ubuntu Community Help Wiki / Postfix/SPF

$ sudo apt install postfix-policyd-spf-python

/etc/postfix/master.cf

# SPF
policy-spf  unix  -       n       n       -       -       spawn
     user=nobody argv=/usr/bin/policyd-spf

※追加する。

2023/07/01 追記
Ubuntu 22.04ではpolicyd-spfに名前が変わっていた。/usr/share/doc/postfix-policyd-spf-python/README.Debian 参照。

policyd-spf  unix  -       n       n       -       0       spawn
    user=policyd-spf argv=/usr/bin/policyd-spf

うちは25以外のポートを開放しておらず、内部からのリレー要求(Kopanoからのリレー等)を無条件に許可する設定なので、単純にSPFチェックを追加している。
一般にはsubmission等を使うのだろうから、元々ある条件を残しつつ…ということになるのだろう。参照先にはSPFモジュールが予期せぬ応答をしたときにオープンリレー状態になることを防ぐため、reject_unauth_destination でリジェクトの条件を入れた後に、SPFのチェックポリシーを入れるようにするように書かれていた。

/etc/postfix/main.cf

# SPF
smtpd_recipient_restrictions =
    permit_inet_interfaces
#   permit_mynetworks
    check_policy_service unix:private/policy-spf

※追加する。
※permit_inet_interfacesを入れて、自ホストからの接続はチェックしないようにした。
※permit_mynetworksを入れると、その範囲はチェック対象にならない。ローカルのDNSでSPFレコードを用意できたので、全チェックさせる。

2023/07/01 追記
Ubuntu 22.04ではpolicyd-spfに変わっている。

    check_policy_service unix:private/policyd-spf

ポリシーの動作設定はこのファイルでできるらしい。
/etc/postfix-policyd-spf-python/policyd-spf.conf

#  For a fully commented sample config file see policyd-spf.conf.commented

debugLevel = 1
TestOnly = 1

HELO_reject = Fail
Mail_From_reject = Fail

PermError_reject = False
TempError_Defer = False

skip_addresses = 127.0.0.0/8,::ffff:127.0.0.0/104,::1

設定を反映。

$ sudo systemctl reload postfix

この機能が有効になると、受信したメールのヘッダーに以下のような判定結果が付与される。

Received-SPF: Pass (mailfrom) identity=mailfrom; client-ip=192.168.0.2; helo=temp.hogeserver.hogeddns.jp; envelope-from=spammer@temp.hogeserver.hogeddns.jp; receiver=<UNKNOWN>

気になったのが、receiver=<UNKNOWN>の表記。
これはHide_Receiver = Noと設定すれば表示されるようになるらしい。
serverfault / spf header information, namely Pass(mailfrom), identity, and receiver=<UNKNOWN>

でも、セキュリティ上の理由ってなんだろう？と思ってman policyd-spf.confで確認したところ、これは宛先がBCCに含まれている場合にPostfixはそのことを教えてくれないので無差別表示になってしまう、そうなるとセキュリティを侵害することになる、ということの模様。このあたりは運用範囲を考えて設定しよう。

さて、リジェクトすると影響が大きいかなと思われるので、例えばOutlookなら、ヘッダーに以下が含まれていたら分類(色分け)してあげると目立って良いかもしれない。

Received-SPF: None
Received-SPF: Neutral
Received-SPF: Tempfail
Received-SPF: Softfail
Received-SPF: Permerror
Received-SPF: Fail ← これは、今の設定だとリジェクトされるだろうけれども。

ただし…今回届いた一連の迷惑メールは、SPFが設定されており、パス判定される。
たまたま、2通目のメールが着信したのでログを貼っておくが、こんな感じでパスしてしまい、はじくことができない。

Sep 18 22:54:55 mx policyd-spf[8550]: prepend Received-SPF: Pass (mailfrom) identity=mailfrom; client-ip=107.189.4.168; helo=mnjzw.com; envelope-from=amozon@mnjzw.com; receiver=<UNKNOWN>

DKIMレコード確認

DomainKeys Identified Mail(DKIM)の仕組みを導入する。

DKIMは受信したメッセージの署名を確認し、ヘッダにAuthentication-Resultsとして検証結果を追記する。

インストール手順はここに書かれている。少し古かったりもするようなので、追加の作業が幾つか必要にはなってくる。
ubuntu Community Help Wiki / Postfix/DKIM

$ sudo apt install opendkim
$ sudo systemctl stop opendkim
$ sudo mkdir -p /var/spool/postfix/var/run/opendkim
$ sudo chown opendkim:opendkim /var/spool/postfix/var/run/opendkim
$ sudo chmod 750 /var/spool/postfix/var/run/opendkim
$ sudo adduser postfix opendkim

/etc/opendkim.conf

Socket          local:/var/spool/postfix/var/run/opendkim/opendkim.sock

※赤文字箇所を追記。

サービスを起動。

$ sudo systemctl start opendkim

/etc/postfix/main.cf

# DKIM
milter_default_action = accept
milter_protocol = 6
smtpd_milters = unix:/var/run/opendkim/opendkim.sock
non_smtpd_milters = $smtpd_milters

※追加する。

設定を反映。

$ sudo systemctl reload postfix

この機能が有効になると、受信したメールのヘッダーに以下のような判定結果が付与される。

Authentication-Results: mx.myhome.local;
	dkim=pass (2048-bit key; unprotected) header.d=temp.hogeserver.hogeddns.jp header.i=@temp.hogeserver.hogeddns.jp header.b="ZXJiCAtH";
	dkim-atps=neutral

dkim-atps=neutralになっているのが気になるが、Gmailから送信してみても同じなので、何かの判断設定が追加で必要なのかもしれない。

これも、Outlookでヘッダーに以下が含まれていたら分類(色分け)してあげると目立って良いかもしれない。

dkim=fail
dkim=temperror

※これはテスト中に出たもの。他にも値はありそうだけれども、ちょっと情報を見つけられなかった。

今回のメールは署名がされており、恐らくはじくことはできないだろう。

DMARC

Domain-based Message Authentication, Reporting, and Conformance(DMARC)の仕組みを導入する。

DMARCはSPFとDKIMを補完するもので、SPCやDKIMで検証できなかったメッセージをどうするのか、例えば破棄したり隔離したりするようなポリシーをDNSを介して受信側サーバー示す。また、Fromヘッダーで指定された送信ドメインが封筒(envelope)で指定された送信ドメイン、および、DKIMヘッダーで指定された署名ドメインと一致するかどうかもチェックする。そして、その結果をレポートとして送信者に送信する。

どちらかというとメールを送信する側に良さそうな機能に見えるが、メールサーバーを立てている以上は送信者でもあることも踏まえて、受信するメールのチェック強化のために組み込んでみる。

インストール手順はここで教えてくれていて、milter_protocol=6が今はいいことを気付かせてくれた。
LinuxBabe / Set Up OpenDMARC with Postfix on Ubuntu to Block Spam/Email Spoofing

$ sudo apt install opendmarc
$ sudo /lib/systemd/systemd-sysv-install enable opendmarc
$ sudo systemctl stop opendmarc
$ sudo mkdir -p /var/spool/postfix/var/run/opendmarc
$ sudo chown opendmarc:opendmarc /var/spool/postfix/var/run/opendmarc
$ sudo chmod 750 /var/spool/postfix/var/run/opendmarc
$ sudo adduser postfix opendmarc

/etc/opendmarc.conf

# RejectFailures false
RejectFailures true
<...>
Socket          local:/var/spool/postfix/var/run/opendmarc/opendmarc.sock

※赤文字箇所を追記。

サービスを起動。

$ sudo systemctl start opendmarc

/etc/postfix/main.cf

# DKIM
milter_default_action = accept
milter_protocol = 6
smtpd_milters = unix:/var/run/opendkim/opendkim.sock unix:/var/run/opendmarc/opendmarc.sock
non_smtpd_milters = $smtpd_milters

※追加する。

設定を反映。

$ sudo systemctl reload postfix

この機能が有効になると、受信したメールのヘッダーに以下のような判定結果が付与される。

Authentication-Results: mx.myhome.local; dmarc=none (p=none dis=none) header.from=temp.hogeserver.hogeddns.jp
　とか
Authentication-Results: mx.myhome.local; dmarc=pass (p=reject dis=none) header.from=temp.hogeserver.hogeddns.jp

/etc/opendmarc.confに入れたRejectFailures trueの設定は、spammer@temp.hogeserver.hogeddns.jpのメールをwork.hogeserver.hogeddns.jpから送ってきたようなときに、DMARCのポリシーに従ってリジェクトできるようにするもの。本家が「オレは他からメールを送らせたりはしない！」といっているのだから、リジェクトしてあげるのが自然だけれど、テストで設定を変えて受け取ってみたらこんな感じのヘッダーが付与されていた。

Received-SPF: None (mailfrom) identity=mailfrom; client-ip=192.168.0.3; helo=work.hogeserver.hogeddns.jp; envelope-from=spammer@work.hogeserver.hogeddns.jp; receiver=<UNKNOWN> 
Authentication-Results: mx.myhome.local; dmarc=fail (p=reject dis=none) header.from=temp.hogeserver.hogeddns.jp

※envelope-fromってこういうことなのね。

ということで、これもOutlookでヘッダーに以下が含まれていたら分類(色分け)してあげると目立って良いかもしれない。

dmarc=fail
dmarc=none ← これは対応していないサーバーも多いので、一概になんとも言えない。

今回のメールはSPFとDKIMをパスし、DMARCレコードがあるので検証もパスするので、はじくことができない。

SpamAssassin

今回送られてきたメールは、SPF, DKIM, DMARCのすべてをクリアしていたので、何の問題も検出できずに受信者にメールが届いてしまう。
これをスパムだと検出するためには、もっと詳細な分析をする仕組みが必要になってくる。

SpamAssassinは受け取ったメールを多角的に検証してスパム判定する仕組みで、今回のようなメールの場合はこれで判定していくのではないかと思う。

思うが…範囲が広すぎる。また今度。

今回届いた迷惑メールの特徴

今回のメールはフィッシングで、差出人が amozonjp-update-account@desctrl.com となっている。

このようなログが残されている。

Sep 18 04:17:23 hoge postfix/smtpd[29441]: connect from desctrl.com[nnn.nnn.nnn.nnn]

※このIPアドレス自体が問題というわけではなくて、調べるための手がかり。

逆引きができる。

$ dig -x nnn.nnn.nnn.nnn
<...>
;; ANSWER SECTION:
nnn.nnn.nnn.nnn.in-addr.arpa. 30 IN      PTR     desctrl.com.
<...>

IPアドレスから、これを提供しているサービスにたどり着いた。
どうもこれはDNS逆引きサービスに対応し、256IPアドレスが使え、125USドル/月でリースされているものと想定される。

このサイトの権威サーバーはjm1.dns.comとjm2.dns.comとなっていて、4つのIPアドレスがある。
また、サーバーのIPアドレスとSPFレコードが登録されている。

$ dig @jm1.dns.com desctrl.com -t txt
<...>
;; ANSWER SECTION:
desctrl.com.            600     IN      TXT     "v=spf1 a mx ip4:nnn.nnn.nnn.nnn/32  ~all"
<...>

$ dig @jm1.dns.com desctrl.com -t mx
<...>
desctrl.com.            600     IN      MX      10 desctrl.com.
<...>

メールにはDKIMの署名もされていて、DNSには公開鍵が設定されている。

$ dig @jm1.dns.com defult._domainkey.desctrl.com -t txt
<...>
;; ANSWER SECTION:
defult._domainkey.desctrl.com. 600 IN   TXT     "v=DKIM1; k=rsa; p=MIGfM…DAQAB"
<...>

$ dig @jm1.dns.com _adsp._domainkey.desctrl.com -t txt
<...>
;; ANSWER SECTION:
_adsp._domainkey.desctrl.com. 600 IN    TXT     "dkim=all"
<...>

DMARCの設定もされていて、とりあえず受信者にメールを届けてくれ、レポートは受け付けない、となっている。

$ dig @jm1.dns.com _dmarc.desctrl.com -t txt
<...>
;; ANSWER SECTION:
_dmarc.desctrl.com.     600     IN      TXT     "v=DMARC1; p=none"
<...>

これだけの情報が登録されたサーバーからのメール送信なので、これを受け付けてしまうのは致し方ないと考えられる。
これをリジェクトしたり、スパム認定したりするには、メールをもっと詳細に分析する必要があるのだろう。

Gmailにメールを送ると、着信までにちょっとタイムラグがあるが、この間に詳細な分析をしているのだろう。

まぁしかし、なめられたもんだよな。

DNS登録しているということは、少なくとも何らかの申請情報があるわけだよなぁ。
逆引きができて、SPFを設定できているということで、このIPアドレスを提供しているサービスプロバイダーに聞いたら、どこの国のどんな人なのか分かりそう。
DNSが4つあってそれぞれが応答しているから、仮に動的に振り出されるIPだとしても、その瞬間に誰に振り出されているのか分かりそう。

何をやっても平気だと思っているわけだ。

これらがすべて盗み出した情報や、ハックされたサーバーによって構築されているんだとしたら、なかなかに力が入っているわけだけれども、フィッシングメールってそこまで儲かるのかな？と思うと、ちょっと疑問。
彼の国がその気になるかならないかだけで、犯人が見つかるかどうかが決まるんだろ？その気にさせられないわけだな。

特徴を再現したメール送信テスト

テストは自前でサーバーを用意して宅内で実施している。色々なパターンで、どんな風に書くと否定的な判定になるのかを確かめたかったから。

そして、ある程度正しく動くことが確認できてから、外に向かって少ない回数で丁寧にテストを依頼するのがよさそうだ。
トホホなことが発生しているので、あえて失敗を最初に書く。

Gmailで迷惑メールと識別されること(未解決)

まずは、こういう仕組みがあることを知っておいて、登録しておいて様子を確認していくのが大切。
Googleヘルプ / Postmaster Tools を使ってみる
登録したばかりでデーターがなく、そもそもGmailへのメール送信なんてそんなにしないとはいえ、もしかすると何かが分かってくるかもしれない。

せっかく立っているサーバーが迷惑メール送信サーバーと認識されるのは困る。
なので、Gmailでテストするなら最小限で、しかも、普通の連絡を試してみるのが良いと思う。

というのも…

メールサーバーの設定を調整し、宅内でのテストを経て、問題ないだろうということでGmailにメールを投げてみると、迷惑メールのラベルが付く。
SPF、DKIM、DMARCの条件をそれぞれクリアしていてもそうなる。

Subject: test
Message-ID: <kcEE.o0cfMNo9QEiYJBpGO5DJoA.ABUberWt1wE@myhost>
test

のようなメールを何通も送っていた。

最初は「スパムと判断されたメールに似ている」という理由でラベルが付けられる。
そのうち、「temp.hogeserver.hogeddns.jpさんから受信した多数のメールは、以前迷惑メールとして識別されています。」という理由でラベルが付けられるようになった。

Gmailからのメールに返信したときには、そのままメールツリーに入るが、これは正当なReferenceヘッダーが付いているからだろう。
Referenceヘッダーに変な細工なんかしようものなら、恐らくはどんどんサイトの評価が下がっていくと思われる…

普通に使って、普通に実績ができていけば、問題なく受け付けてくれるようになるかもしれない。

まともなメールが出るようになるまで、自前の環境でしっかりとテストしていった方が身のため。
宅内で付いたヘッダーは、基本的にはちゃんとGmailまで届くので、宅内でのテストで十分だ。

DNSキャッシュクリア

テストしているときに、SPFやDKIM、DMARCのレコードを修正していたのだが、特にSPFについてはキャッシュを参照する関係で、修正しても結果が変わらないことがあって、あれ、変えたはずなのに動作が変わらない…というのが結構な頻度で発生していた。

なので、キャッシュをクリアする方法をメモ。
kledgeb / Ubuntu 17.04 その65 – DNSキャッシュをクリア（フラッシュ）するには

$ sudo systemd-resolve --flush-caches

これをメールを受信するサーバーで打っておけば、新しい情報でチェックが行われる。

SPF

SPFについてメール送信する側でやることは、DNSでメールサーバーの存在を示し、SPFの書き方に沿ったTXTレコードを示すこと。

具体的には、Samba-ad-dcの内蔵DNSにMXレコードとTXTレコードを追加。

$ samba-tool dns add localhost hogeserver.hogeddns.jp temp MX "temp.hogeserver.hogeddns.jp 10" -U dnsman
$ samba-tool dns add localhost hogeserver.hogeddns.jp temp TXT "'v=spf1 a mx ip4:192.168.0.2/32 -all'" -U dnsman

※dnsmanはdns操作ができる権限ができるユーザー。

SPFで-allとしているが、他のサーバーから自分のメールを送ることがある場合には~allを設定するのだそう。
ウチのメールを他のサーバーに委託しておくってもらうことなんて、まぁ絶対にないと言えるので、他から送られてきたメールは拒否してもらって構わない、ということで、-allとしている。

今回送られてきた迷惑メールの送信元ドメインと同じように見えるか確認。
~allが-allになっていること以外に差はなく、Postfixからは同じような状態に見えるだろう。

$ dig temp.hogeserver.hogeddns.jp -t any
<...>
;; ANSWER SECTION:
temp.hogeserver.hogeddns.jp. 900 IN     A       192.168.0.2
temp.hogeserver.hogeddns.jp. 900 IN     MX      10 temp.hogeserver.hogeddns.jp.
temp.hogeserver.hogeddns.jp. 900 IN     TXT     "v=spf1 a mx ip4:nnn.nnn.nnn.nn2/32 -all"
<...>

Postfixがこのサーバーを参照するようになっていれば、同じような判定ができる。

ところで、現在、各サーバーはlogcheckで状態をメールで送ってくるようになっている。
このサーバーからのリレーももちろんSPFによるチェック対象になるので、サブドメイン用にTXTレコードを登録が必要(どこのサイトでも「サブドメインが定義できる」的な表現がされているが、定義しないと判定そのものが行われない)。
例えば、

$ dig subdomain.temp.hogeserver.hogeddns.jp -t any
<...>
;; ANSWER SECTION:
subdomain.temp.hogeserver.hogeddns.jp. 900 IN     A       192.168.0.102
subdomain.temp.hogeserver.hogeddns.jp. 900 IN     TXT     "v=spf1 a -all"
<...>

という定義がされていて、EHLO/HELOでsubdomain.temp.hogeserver.hogeddns.jpをちゃんと答えられればチェックがされる。
EHLO/HELOでサーバー名を間違えてしまい、数時間、チェックできないチェックできない…と悩んでしまったので追記しておく。

DKIM

送信時の署名

テストサーバーが送信するメールに署名するために、以下の手順を踏む。

まずは、OpenDKIMをインストールし、秘密鍵と公開鍵を生成する。
生成した鍵は、所定の場所に配置する。

$ sudo apt install opendkim opendkim-tools
$ opendkim-genkey -t -s mail -d example.jp
$ sudo cp mail.private  /etc/mail/dkim.key
$ sudo chown opendkim:opendkim /etc/mail/dkim.key

※鍵を生成する際の -d はメール送信用サーバーのドメイン名を入れておく。
※鍵の長さは-bで指定可能。

/etc/opendkim.conf

Domain                  temp.hogeserver.hogeddns.jp
KeyFile                 /etc/mail/dkim.key
Selector                mail

# 最後の方に追加
InternalHosts           /etc/mail/dkim-internal.hosts

※追加する。

/etc/mail/dkim-internal.hosts ※新規作成

127.0.0.0/8
192.168.0.0/24
::1
24nn:nnnn:nnnn:nnnn::/64
client.hogeserver.hogeddns.jp

※適切な署名範囲を記入。

設定を反映する。

$ sudo systemctl restart opendkim

DNSに公開鍵を登録

先程生成した公開鍵をDNSに登録する。

具体的には、Samba-ad-dcの内蔵DNSにMXレコードとTXTレコードを追加。

$ samba-tool dns add localhost hogeserver.hogeddns.jp mail._domainkey.temp TXT "'v=DKIM1; h=sha256; k=rsa; ' 'p=MIIBI…r7Cgm' '0VbJc…DAQAB'" -U dnsman
$ samba-tool dns add localhost hogeserver.hogeddns.jp _adsp._domainkey.temp TXT "dkim=all" -U dnsman

※dnsmanはdns操作ができる権限ができるユーザー。

DNSは1行255文字(？)の制限があるみたいなので、複数行になるように空白で区切って登録する。
ついついDKIMレコードに登録する文字の長さばかりに気を取られてしまうが、_adspというレコードも登録して、このサーバーから送信されるメールにはすべて署名していることを知らせておく。

同じように見えるか確認。

$ dig mail._domainkey.temp.hogeserver.hogeddns.jp -t txt
<...>
;; ANSWER SECTION:
mail._domainkey.temp.hogeserver.hogeddns.jp. 900 IN TXT "v=DKIM1; h=sha256; k=rsa; " "p=MIIBI…r7Cgm" "0VbJc…DAQAB"
<...>

$ dig _adsp._domainkey.temp.hogeserver.hogeddns.jp -t txt
<...>
;; ANSWER SECTION:
_adsp._domainkey.temp.hogeserver.hogeddns.jp. 900 IN TXT "dkim=all"
<...>

受信時のDNS参照

今度は、テストメールを受け取る側の設定。

OpenDKIMはDNSSECで接続して公開鍵を確認しにいくのだが、debian系の実装は/etc/resolv.confを考慮せず、直接ルートサーバーに聞きに行くようなので、その設定を変えてローカルでテストできるようにする。
serverfault / OpenDKIM query timed out (even with opendkim-testkey and Nameservers set)

/etc/opendkim.conf

#TrustAnchorFile       /usr/share/dns/root.key
Nameservers           192.168.0.100

設定を反映させる。

$ sudo systemctl restart opendkim

本番運用では、TrustAnchorFileを有効化して、Nameserver指定をコメントにする(元に戻す)。

3つのサーバーすべてに設定を入れたら、メールを送信して検証することができる。

DMARC

メール送信する場合に、DMARCのポリシーをDNSで公開する。
Google Workspace 管理者ヘルプ / DMARC レコードの追加

$ samba-tool dns add localhost hogeserver.hogeddns.jp _dmarc.temp TXT "'v=DMARC1; p=reject; rua=mailto:postmaster@hogeserver.hogeddns.jp; pct=100; adkim=s; aspf=s'" -U dnsman

※dnsmanはdns操作ができる権限ができるユーザー。

メール送信を委任することはないので、かなり強気の「ウチからのメールじゃない場合はリジェクトしてくれ」という宣言になっている。

同じように見えるか確認。

$ dig _dmarc.temp.hogeserver.hogeddns.jp -t txt
<...>
;; ANSWER SECTION:
_dmarc.temp.hogeserver.hogeddns.jp. 900 IN TXT  "v=DMARC1; p=reject; rua=mailto:postmaster@hogeserver.hogeddns.jp; pct=100; adkim=s; aspf=s"
<...>

この他にspというオプションがあり、サブドメインからメールが来たらどうするか決めておくことができる模様。
このテストサーバーはサブドメインからのをreject設定して良さそうだし、本番サーバーはサブドメインからのメールをリレーするときにはnoneでそのまま届けて欲しい、なんて設定ができそうだ。

宅内DNSサーバー設置

Samba-ad-dcがDNSSECで問い合わせを受けられない？と勘違いしたために、小一時間掛けてメールサーバーにDNSを同居させてしまった。
勘違いの原因はOpenDKIMがいきなりルートに情報を聞きに行く初期設定になっていたことで、Samba-ad-dcは問い合わせに応答できる。

とはいえ、テスト用に気軽にDNSを立てる手順にはなったと思うので、メモとして残しておく。

Samba-ad-dcでDNSSECは多分できないので、Bind9をインストールする。
Server World / Ubuntu 20.04 / BIND : 内部ネットワーク向けの設定

$ sudo apt install bind9 bind9utils

/etc/bind/named.conf.options

options {
<...>
        forwarders {
                192.168.0.11;
        };

        allow-query {
                localhost;
                192.168.0.0/24;
        };

        recursion yes;
<...>

ゾーンを定義する。
/etc/bind/zones.temp.hogeserver.hogeddns.jp

zone "hogeserver.hogeddns.jp" IN {
        type master;
        file "/var/cache/bind/db.hogeserver.hogeddns.jp";
};

zone "0.168.192.in-addr.arpa" {
        type master;
        file "/var/cache/bind/db.0.168.192.in-addr.arpa";
};

/var/cache/bind/db.hogeserver.hogeddns.jp

$TTL 86400
@ IN SOA temp.hogeserver.hogeddns.jp. postmaster.temp.hogeserver.hogeddns.jp. (
        2021091901      ; Serial Number
        3600            ; Refresh
        1800            ; Retry
        604800          ; Expire
        86400           ; Negative Cache TTL
)

        IN      NS      temp.hogeserver.hogeddns.jp.
        IN      A       192.168.0.2
        IN      MX      10 temp.hogeserver.hogeddns.jp.

temp    IN      A       192.168.0.2
temp    IN      TXT     "v=spf1 a mx ip4:192.168.0.2/32 -all"

/var/cache/bind/db.0.168.192.in-addr.arpa

$TTL 86400
@ IN SOA temp.hogeserver.hogeddns.jp. postmaster.temp.hogeserver.hogeddns.jp. (
        2021091901      ; Serial Number
        3600            ; Refresh
        1800            ; Retry
        604800          ; Expire
        86400           ; Negative Cache TTL
)

        IN      NS      temp.hogeserver.hogeddns.jp.

2       IN      PTR     temp.hogeserver.hogeddns.jp.

作成したゾーンを引き込む。
/etc/bind/named.conf.local

include "/etc/bind/zones.hogeserver.hogeddns.jp";

※追記する。

設定を反映する。

$ sudo systemctl restart bind9

名前解決の先を変更(これは必要かどうか分からない…通常使いのDNSから明示的に切り離したかった)。
/etc/netplan/50-cloud-init.yaml

<...>
            nameservers:
                addresses:
                - 127.0.0.1
                search:
                - hogeserver.hogeddns.jp
<...>

設定を反映。

$ sudo netplan apply

名前解決の状態は、以下で確認できる。

$ systemd-resolve --status

ログレベル

Postfixのログレベル設定。

/etc/postfix/main.cf

debug_peer_list = 192.168.0.20
debug_peer_level = 3

※多分、Reloadせずに反映される。

さいごに

DKIMがいきなりルートサーバーに情報を聞きに行くようになっている、というのを見て、トップレベルドメインのサーバーやその下にいるサーバー達はとてつもない量の要求を捌いているんだなと、改めて恐ろしくなってみたり感謝してみたり。

そして、これほど大胆にその仕組みを使ったフィッシングメールが普通に送られてくる現実。
つくづく、彼らに文明の利器は早すぎたんだなということが分かる。限度を知らないというか、際限がないというか、とことんどこまでも悪事を働くあの姿…

環境

対策

HELOの段階でリジェクト

SPFレコード確認

DKIMレコード確認

DMARC

SpamAssassin

今回届いた迷惑メールの特徴

特徴を再現したメール送信テスト

Gmailで迷惑メールと識別されること(未解決)

DNSキャッシュクリア

SPF

DKIM

送信時の署名

DNSに公開鍵を登録

受信時のDNS参照

DMARC

宅内DNSサーバー設置

ログレベル

さいごに

コメントはこちらから お気軽にどうぞ ～ 投稿に関するご意見・感想・他

コメントはこちらからお気軽にどうぞ～投稿に関するご意見・感想・他