ブラックリストへの考察 メールのSPAMチェック DMARC、DNSBLについて
2018/08/07
2020/01/15
タグ: DMARC, DNSBL, なりすまし防止, メール
昔よりも更に複雑になったと思うサーバの種類にメールシステム(smtpサーバ:MTA)がある。振り返ってみると20年くらい前はデフォルトで作ったメールサーバでもすぐにインターネット上で使えましたが、今は兎に角セキュリティが厳しいので単純な設定ではまともに動かない。ガチガチだなーと感じる。時折サーバ講義の仕事をすると一番厄介なのがメールサーバの解説。正直言って1週間勉強した程度で理解できるのは初心者程度の知識だと思う。アンチSPAMの仕組みについては年々高度になっている。油断しているとおいて行かれるので定期的に情報に目を通さなければならないが、最近の技術の中ではDMARCはさすが効果あるね!と実感できる仕組み。この機能はSMTP通信におけるなりすましを確実にブロックしてくれる。単純ななりすましなら100%ブロックできるだろう。送信サーバがスパイウェアに感染していたら駄目だと思うが、そうなっていない限り大変安全な仕組みと思う。
DMARCを使用してよかった事
以前は、時折自分のメールアドレスFromで数は多くはなかったが1年に2,3回程度送信されてくることがあったがDMARCを導入してからはピタリと止まった。更に嬉しいことに偽メールを送られた受信メールサーバからレポートがxmlで送られてくるので実態が掴める。殆どがgmailとyahooメールからのものだが、これだけ人の名前とメールアドレスを騙って送る輩がいたのだと気付かされる。つまり実際にはもっと沢山偽メールが横行していたと考えられる。もちろんDMARCを実装しているメールサーバでなければこのようなやり取りはできないが、今後必須のシステムになってきそうだと思います。特にビジネスで利用されている企業は共有ホスティングのおまけでついてくるメールは使ってはいけないと私は思います。
DMARCの導入は難しい?
メールサーバの導入になれている人なら1,2時間の学習でDMARCは導入できると思います。DKIM,SPFを入れた経験があるならすぐに理解できると思います。少しDKIM,SPFでやったような作業がつきまといますが非常に難易度の高いものではありません。作業の中にDNSのレコードを操作する箇所があるのでDNSを知らない人は大変かもしれませんがぜひチャレンジしてみてください。CentOSでやるよりもUbuntuのほうがハードルが低そうです。
DNSBLの信頼性
DNSBLシステムは世界に点在しブラックリスト情報を収集して無料で使えるメールSPAM対策サービスが幾つかある。このサービスはDNSの仕組みを利用したレピュテーションサービス(ブラックリストの判定を返す)だが運営組織が何しろ非営利な組織だから出来ては消えての繰り返し。日本ではRBL.JPという日本のスパムデータ・ベースもあったが廃止されており、現在はほとんど海外のサービスを利用するのが多くなった。厄介なのは昨今のIPアドレス汚染だ。プロバイダーの持っているIPアドレスはリサイクルされるため、過去にブラックだったIPだとかなり厄介になることがあります。というのはDNSBLやWEBのブラックQUERYサービスの中にはネットワークブロックで設定しているケースが少なからずあるからだ。そうするとホワイトなIPアドレスでもブラック扱いにされてしまう可能性が十分にありえます。誤判定の多くは過去のIP悪さが起因するのもあるけれど、このようにネットワークマスクの縛りが原因でなってしまう場合もあります。IPアドレスのご判定は殆どが申請で取り消せるようになっていますがネットワークブロックで管理している場合は無理な時もあります。その意味でサーバを借りるときは必ずIPアドレスのチェックを行うことと、IPアドレスの再割り当てができるホスティングがベストです。
SPAM対策用のmain.cfの一部抜粋
reject_rbl_client が記述されているあたりがDNSBLのサーバエントリー。お付き合いしている会社により効きすぎたり、効かなすぎたりあるため使いながら外したりして調整を行う。
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 38 39 40 41 42 43 |
smtpd_helo_required = yes disable_vrfy_command = yes strict_rfc821_envelopes = yes invalid_hostname_reject_code = 554 unknown_local_recipient_reject_code = 554 unknown_relay_recipient_reject_code = 554 unknown_sender_reject_code = 554 unknown_virtual_alias_reject_code = 554 unknown_virtual_mailbox_reject_code = 554 unverified_recipient_reject_code = 554 unverified_sender_reject_code = 554 multi_recipient_bounce_reject_code = 554 non_fqdn_reject_code = 554 relay_domains_reject_code = 554 unknown_address_reject_code = 554 unknown_client_reject_code = 554 unknown_hostname_reject_code = 554 smtpd_relay_restrictions = permit_mynetworks, check_client_access hash:/etc/postfix/sender_access, permit_sasl_authenticated, reject_unauth_destination smtpd_client_restrictions = permit_mynetworks, check_client_access hash:/etc/postfix/stop_sender reject_non_fqdn_hostname, reject_unknown_client, reject_non_fqdn_sender, reject_unknown_sender_domain, reject_rbl_client bl.spamcop.net, reject_rbl_client spam.rbl-dns.com, reject_rbl_client b.barracudacentral.org, reject_rbl_client list.dsbl.org, reject_rbl_client zen.spamhaus.org=127.0.0.[2..11], permit smtpd_helo_restrictions = permit_mynetworks, check_client_access hash:/etc/postfix/hello_access, reject_invalid_hostname, permit |
共有サーバは勘違い判定の巣窟になる。
共有サーバは1台のサーバに多数のサイトが運営されるサーバですが、このサイトの中に詐欺サイトやマルウェア感染原因のサイトがあるとどうなるかご存知でしょうか?プロバイダーが認識した場合はプロバイダーから改善通知や停止を言われますが、実際のところ運営者も気づいていないものもかなりあると思います。私も自分のお客様で幾つかこの様な例を経験しましたが、結論はGoogleやYahooの検索結果に出てこなくなりました。イメージ的にはGoogleのインデックスには残っているのでしょうが、一時的にマスクされているように思えます。ブラック発見は無料のbaraccudacntral.orgのサービスでチェックし、その後別のプライベートホスティングに移設しDNSを切り替えたところ5分で検索結果にTOP5で表示されるようになりました。この経験でGoogleが如何に様々な詐欺行為のサイトを抑え込むチェックを行ってるかがわかりました。ビジネスで本気勝負をかけて集客、販売する会社は共有サーバ使ってはいけませんね。