システム奮闘記：その111

スパムメール認定、スパムメールの発信源



Tweet 

(2019年10月24日に掲載)


はじめに

　スパムメールの発信源。
　メールサーバーの不正中継
　まさかウイルスによって不正中継が行われるとは想像もしなかった。
　というわけで、ウイルスによるスパムメールの発信源になってしまった話を書きます。




スパムの発信源


　2018年12月、警視庁から会社に電話が入った。

　スパムメールがあり、発信源を調べましたら御社のIPでした

　だった。

　だが、思い当たる節がない。
　メールサーバーは2018年11月に、自社サーバーから、さくらインターネットのレンタルサーバーに移行した。
　詳しくは「システム奮闘記:その109」(メールサーバーをレンタルサーバーへ移行)をご覧ください。

　そのため社内にあるメールサーバーの不備な点を突かれて、不正中継されている可能性は考えられない。
　この時、調べてみたものの、何が原因なのかさっぱりわからなかった。

　警視庁からの電話だったため、上司から

　君が悪い事をしたのかと思ってビックリした

　と言われてしまった。



　正月明けにも警視庁から確認の電話があった。
　私は・・・

　正直、該当する物が見つかりません

　と答えた。
　思い当たる節がないため、全く見当がつかない。

　この時、警視庁からの電話が、これから起こる厄介な問題の前触れだとは予想していなかった。




グーグルメールに送信できない


　2019年1月下旬になり、厄介な問題が起こるようになった。
　ある営業所の所長から

　お客さんにメールが届かへん!!

　だった。

　お客さんにメールを送ったものの、エラーで返ってくるという問題が発生していた。
　そこで所長にエラー内容を送ってもらう事にした。

　エラー内容を見てみた。

　すると・・・

　グーグルがメール受信を拒否しとる!!
エラーで戻ってきたメールのヘッダーの内容
The original message was received at Tue, 29 Jan 2019 11:25:45 +0900 (JST)
from aaa.sakura.ne.jp [XXX.YYY.ZZZ.RRR]

----- The following addresses had permanent fatal errors -----
<xxxxxxx@aaaa.bbbbb.com>
(reason: 550-5.7.1 This message does not have authentication information or fails to pass)

----- Transcript of session follows -----
... while talking to aspmx.l.google.com.:
>>> DATA
<<< 550-5.7.1 This message does not have authentication information or fails to pass
<<< 550-5.7.1 authentication checks. To best protect our users from spam, the
<<< 550-5.7.1 message has been blocked. Please visit
<<< 550-5.7.1 https://support.google.com/mail/answer/81126#authentication
for more
<<< 550 5.7.1 information. l5si35726872pls.423 - gsmtp
554 5.0.0 Service unavailable
エラーメッセージを見ると、うちから送ったメールを、グーグルがスパムメールと判定し
メールを届かないようにしている事がわかる。 

　うちの会社から送ったメールを・・・

　グーグルが迷惑メール認定し、受信拒否しとる!!

　だった。

　そこで
Gmailのヘルプ
gmailのヘルプのサイト
お問い合わせフォームを選ぶ。 

　そしてお問い合わせフォームを開いた。
Gmailのお問い合わせフォーム
gmailのお問い合わせフォームのサイト
お問い合わせフォームに、迷惑メール認定の解除の申し入れを書いた。 

　だが、グーグルから返答も何も来ない。

　グーグル、なめとんのか!!


　そこで所長に連絡した。
所長との会話
私 所長、こちらからグーグルに連絡しても無視されているので
すみませんが所長の方から、お客さんに対して次の事を伝えてください。

お客様がお使いのがプロバイダーのグーグルの機能によって
弊社から送信しています全てのメールが、迷惑メール認定されてしまい
お客様の所へメールが届かないようになっています。
そのためお手数ですが、グーグルに対して迷惑メール認定の解除をご要請をお願いします。
所長 菅くん、お客さんに、それは言いにくいよ
俺、上手に説明できない上、それを下手に言うと、お客さんに非があるように伝わってしまうし。
私 でも、所長。うちからグーグルに申し入れも無視されるだけで
全く打開策がないですよ。お願いします。
所長・・・。

　所長の気持ちもよくわかる。
　お客さんもITの専門家ではない。そのため上手に説明しないと、
お客さんに非があるように伝わってしまう危険性がある。
　不毛な争いにならないようにするためには、至難の業なのだ。


　しかし、いくらグーグルに対して対応を求めても無視されたままだった。
　しかもグーグルの場合・・・

　電話窓口があらへん!!

　実際には代表電話があるものの、そこにかけても音声案内で

　お問い合わせはネットから・・・

　という始末だった。

　解決の糸口が見えないまま、時間が過ぎて行った。




救世主は大手通信会社


　ある時、うちの会社が使っている通信回線について、大手通信会社へメールを送った。
　この時、メールがエラーで返ってきた。エラー内容を見ると・・・

　グーグルメールで拒否されている!!

　だった。
　大手通信会社のメールはグーグルメールを使っている。


　この時、良い案が思いついた。

　大手通信会社からグーグルへ申し入れをさせれば

　さすがにグーグルでも大手顧客の声は無視はできへんやろ

　大手通信会社とはいえ、うちの会社が顧客の立場。非常に言いやすい。
　そこで通信会社の営業担当者に電話連絡する事にした。

　電話で事情を説明した後、エラー内容を、私的のメールアドレスから送った。


　数日後、通信会社から返事がやってきた。
通信会社からの返事
お世話になっております。
XXX会社のYYです。

本件、Googleサポートより、以下コメントございました。
一度、ご確認をお願い致します。

■Googleサポートコメント

本件、ご提供いただきました情報をもとにお調べしたところ、
送信ドメイン 'xxxxxxx.co.jp' に SPF レコードが設定されて
いないことに起因して、正当なメッセージではないと判定され、
受信が拒否された可能性がございます。

そのため、根本的な解決をするには 送信元へ
SPFレコードの登録をご検討頂けますようご依頼頂けますでしょうか。

以下、Gmailに関する内容ですが、お役にたちますと幸いです。
参照ヘルプ：SPF でメールの送信者を承認する
https://support.google.com/a/answer/33786?hl=ja

よろしくお願い致します。 

　これを見た時・・・

　SPFレコードで何やねん??

　だった。




SPFレコードの設定


　DNSサーバーにSPFレコードの設定を行うのだが・・・

　SPFって何やねん?

　だった。
　2000年にDNSサーバーの設定を行って以来、19年間経つが、今までSPFレコードという言葉を見た事がなかった。


　そこでネットで「SPF レコード」で調べてみる。

　なりすましメール撲滅に向けたSPF（Sender Policy Framework）導入の手引き(IPA 独立行政法人 情報処理推進機構)
　DNSのTXTレコート゛のSPF設定の要点

　を見つけた。
　DNSサーバーにSPFレコードを登録する事で、相手方に対して

　このIPから送信されたメールは本物やで

　を伝える物だ。
SPFレコードと偽装メールの判定の仕組み(メールの到着)
メールが飛来した時
「 suga@example.co.jp 」からメールがやってきたとする。
この時点では発信元を偽装しているメールかどうかはわからない。 

　そこでやってきたメールのドメインの素性を調べるため、DNSサーバーに問い合わせを行う。
SPFレコードと偽装メールの判定の仕組み(DNSサーバーへの問い合わせ)
DNSサーバーに問い合わせ
「 example.co.jp 」のドメインから送られるメールの場合
どのメールサーバーのIPアドレスから送られるか問い合わせを行う。 

　すると問い合わせを受けたDNSサーバーは、SPFレコードを確認して回答を行う。
SPFレコードと偽装メールの判定の仕組み(DNSサーバーからの回答)
DNSサーバーからの回答
DNSサーバーは、SPFレコードの記述を確認し、SPFの記述があれば
そのドメインのメールサーバーのIPアドレスを返答する。 

　この仕組みによって、メールの発信元を偽装しても見破れる形になっている。
偽装メールの判定方法
偽装メール
受信側のメールサーバーが、DNS問い合わせによって、正しい発信元のIPアドレスを入手できる。
そのため偽装メールを発信しても、発信元のIPアドレスが正しくなければ
偽装メールだと認定できるのだ。 

　こんな仕組みになっていたとは知らへんかった!!

　DNSサーバーは進化している。しかしDNSサーバーの進化から取り残さていると、
浦島太郎になってしまっているのだ。


　浦島太郎のままでは前に進まない。
　そこでネットに書かれている設定方法を参考にしながら、DNSサーバーの設定を行う事にした。
　でも、行う事は難しくなかった。

　正引きのファイルにSPFレコードを記述する

　のみだった。
DNSの正引きの設定

XXXXXXX.co.jp.      IN      TXT     "v-spf1 +ip4:AAA.BBB.CCC.DDD +mx -all"
赤い部分は、うちの会社のドメイン。
青い部分は、メールサーバーのIPアドレス。

　ところが、別の部署の人から連絡があった。

　仕入先へメールが送られへん!!

　エラーで戻ってくるのだ。
　うちの会社のメールサーバーは、さくらインターネットのレンタルサーバーを使っている。


　そこで、さくらインターネットへ問い合わせを行う。
さくらインターネットへの問い合わせ
顧客にメールを送りましたら、以下のエラーが出て戻ってきました。
------------------------------------------------------------------
The original message was received at Fri, 1 Mar 2019 10:01:42 +0900 (JST)
from XXXX.sakura.ne.jp [XXX.YYY.ZZZ.RRR]
----- The following addresses had permanent fatal errors -----
<info@KKKK.YYY>
(reason: 554 Reject by behaviour spam at Rcpt State(Connection IP 
address:AAA.BBB.CCC.DDD)ANTISPAM_BAT[01201311R156a, e02c03291]: spf check failedCONTINUE)
----- Transcript of session follows -----
... while talking to mx1.mx1.aaa.vvv.ccc.aaa.:
>>> DATA
<<< 554 Reject by behaviour spam at Rcpt State(Connection IP 
address:AAA.BBB.CCC.DDD ) ANTISPAM_BAT[01201311R156a, e02c03291]: spf check failedCONTINUE
554 5.0.0 Service unavailable
<<< 503 bad sequence of commands
451 4.4.1 reply: read error from mx1.aaa.vvv.ccc.aaa
-- 
添付メッセージ部
Reporting-MTA: dns; +++++.sakura.ne.jp
Received-From-MTA: DNS; *****.sakura.ne.jp
Arrival-Date: Fri, 1 Mar 2019 10:01:42 +0900 (JST)
Final-Recipient: RFC822; info@KKKK.YYYY
Action: failed
Status: 5.0.0
Remote-MTA: DNS; mx1.aaa.vvv.ccc.aaa
Diagnostic-Code: SMTP; 554 Reject by behaviour spam at Rcpt State(Connection IP 
address:AAA.BBB.CCC.DDD)ANTISPAM_BAT[01201311R156a, e02c03291]: spf check failedCONTINUE
Last-Attempt-Date: Fri, 1 Mar 2019 10:01:47 +0900 (JST)
-----------------------------------------------------------------------
DNSサーバーは自社サーバーで運用しています上、
SPFレコードの登録も、xxxxx.sakura.ne.jp のサーバーのIPで登録しています。
それでもスパムとして認定されています。
さくらインターネットの設定が必要なのでしょうか。
すみませんが、よろしくお願いいたします。


　すると回答が返ってきた。

　メールサーバーのIPアドレスが間違えています

　だった。

　間抜けな事をしてしまった。
　そこで正しいメールサーバーのIPアドレスを入力した。
　すると、仕入先にメールが届くようになった。




JPCERTからの連絡


　2019年2月12日、JPCERTから連絡があった。
　うちの会社のホームページの問い合わせフォームから、連絡が寄せられた。
うちの会社の問い合わせフォームから送られた内容
会社名 ： JPCERT/CC
会社名フリガナ ： JPCERT コーディネーションセンター
ご担当者様名 : AAAA
郵便番号 : 
住所 : 東京都中央区日本橋本町4-4-2 東山ビルディング8階
電話番号 : 03-6271-8901
メールアドレス : info@jpcert.or.jp
件名: その他
製品名: 
お問い合わせ内容 : この連絡は、JPNIC、JPRS WHOIS データベースに登録されている以下の企業の方にお送りしています。

  XXX.YYY.ZZZ.AAA/29

JPCERT/CC では、貴社ネットワーク下のメールサーバからマルウエアが添付されたメールが配送されたとの情報をご提供いただいております。
もし実際に、貴社メールサーバにおいて当該メールの配送が行なわれており、貴社の意図に反したものである場合には、適切な措置をお取りください。

      関係するメールサーバのアドレス: XXX.YYY.ZZZ.BBB
      配送の時刻: 1月24日 17:04 (UTC+0900) 頃

また、調査、対応いただいた内容について、差し支えない範囲でメールにて
ご連絡いただければ幸いです。ご連絡を頂きます際には、メールの件名もしく
は本文に次の番号をご記入ください。

        JPCERT#2*******3

[参考資料]
      コンピュータセキュリティインシデントへの対応
      https://www.jpcert.or.jp/ed/2002/ed020002.txt

      関係サイトとの情報交換
      https://www.jpcert.or.jp/ed/2002/ed020001.txt

[JPCERT/CC とは]
JPCERT/CC は、インターネット上におけるコンピュータセキュリティインシデ
ントについて、日本国内の組織およびユーザに関する技術的な支援を行なうこ
とを目的とした組織です (JPCERT/CC の詳細につきましては、
https://www.jpcert.or.jp/ をご覧ください)。

[記載内容の共有範囲について]
本メール内に記載しております情報は、本メールを受信された方およびインシ
デント対応に関係される方のみで共有をお願いいたします。

======================================================================
JPCERT コーディネーションセンター (JPCERT/CC)
TEL: 03-6271-8901  EMAIL: info@jpcert.or.jp



　年末年始、警視庁から電話があった内容と同じなのだ。
　だが、この時点でも・・・

　原因が全くわからへん!!

　だった。

　既にメールサーバーは、自社サーバーではなく、レンタルサーバーへ移管しているからだ。
　そのため、どういう対応をとれば良いのか、わからなかった。




ある企業からの連絡


　JPCERTからの問い合わせから一週間後の2月19日。
　今度は、スパムメールが送られてきたというメールがやってきた。
メールの内容
XXXX 株式会社
ネットワーク管理者様

お世話になります。株式会社YYYYYのZZと申します。

　御社管理のネットワークからスパム発信を確認いたしましたので、
下記、ヘッダー情報等をお送りします。
添付ファイルがあり、おそらくウイルスを含んでいたものと思われます。
ご対処くださいますようお願いいたします。

もし、会社内で運用しているパソコン等がある場合、ウィルスに感染し
下記スパムメールが送られた可能性があります。 

　だが、この時、添付されていたメールのヘッダーに気づいた。
メールのヘッダー
Received: from AA.QQQ.ZZZ.YYY.XXX.in-addr.arpa ([XXX.YYY.ZZZ.AA]:63481)
どのIPアドレスのマシンからメールが送られてきたという記述だ。
該当のIPアドレス(青い部分)に気づいた。 

　このIPアドレスは、社内にあるパソコンが外部へ出る際

　NATで変換されたIPアドレス

　だったのだ。

　つまりスパムの発生源はパソコンになる。
ウイルス感染したパソコン
ウイルス感染したパソコン
社内のパソコンの1台がウイルス感染していた。 

　そのウイルスが、闇雲にインターネット上のメールサーバーに接続して
ウイルスメールを中継させていた。
インターネット上のメールサーバーにウイルスメールを中継していた
インターネット上のメールサーバーにウイルスメールを中継していた
ウイルスが、闇雲にインターネット上のメールサーバーへ接続し
ウイルス付きのメールを中継していた。
そのためウイルスメールが送信されていたのだ。

パソコン上からヤマハのルーターを通ってメールサーバーへウイルスメールが送られるため
ウイルスメールの発信元が、ヤマハのルーターでNAT変換されたIPアドレスになっていた。 

　この時点では、どのパソコンがウイルス感染しているのか特定できていなかった。
　だが、特定できなくても、外部のメールサーバーへ中継できなくする方法はある。

　ルーターでパケットフィルターすれば良いのだ!
ルーターの設定(コンフィグ:config)
ip filter 41 pass 192.168.0.0/16 XXX.YYY.QQQ.HHH * * smtp
ip filter 42 reject * * * * smtp
青い部分は、さくらインターネットで使っているうちの会社のレンタルサーバーのIPアドレス。
うちのレンタルサーバー向けでポート25宛てのパケットは素通りさせる。

それ以外のポート「25」宛てのパケットは送信拒否の設定にした。 

　これでレンタルサーバー以外のメールサーバーへ接続しようとすると
接続拒否になるだけでなく、接続元が記録される。

　そこで数日待つ事にした。

　数日後、ルーターに記録されたログを見てみる事にした。

　見事にウイルス源が特定できた!!

　だった。
ルーターのログ
2019/02/20 14:13:29: PP[01] Rejected at OUT(42) filter: TCP 192.168.AAA.GGG:63579 > A.B.C.D:25
2019/02/20 14:13:29: PP[01] Rejected at OUT(42) filter: TCP 192.168.AAA.GGG:63580 > Q.T.Y.A:25
2019/02/20 14:13:29: PP[01] Rejected at OUT(42) filter: TCP 192.168.AAA.GGG:63553 > Y.G.A.T:25
IPアドレス「192.168.AAA.GGG」から、ポート「25」宛てのパケットが送信拒否されている。
ウイルスメールの犯人はIPアドレスが192.168.AAA.GGGのパソコンだとわかった。 

　そこで該当のパソコンのウイルス駆除を行った。
　それ以来、ルーターのログで、ウイルスメールを飛ばすパソコンは検知していない。

　そしてJPCERTにウイルス源の特定ができ、かつウイルス駆除ができた事を報告した。
　ウイルスメールの連絡を送ってくださった会社には報告と謝罪のメールを送った。




ブラックリスト


　あとスパムの発生源になった場合、メール配信に使っているアドレスが
ブラックリストに登録されている可能性がある。

　そのためブラックリストから外してもらう手続きを行う必要がある。
　そこで以下のサイトを参考にして、ブラックリストから外してもらう手続きを行った。

　メール配信に使っているアドレスがブラックリスト登録された時の対処法 - Benchmark Email マーケティングブログ
　ASCII.jp：不正なメールサーバーを「RBL」で排除しよう｜週刊セキュリティレポート



最後に

　迷惑メールといえば、メールサーバーの乗っ取りによる不正中継とばかり思っていましたが
ウイルスが、不特定多数のメールサーバーに接続して、ウイルスメールをまき散らす事を
体験してしまいました。

　それに加えて、DNSサーバーで、SPFレコードの設定をしていなかったため
うちの会社のドメインが、スパムメールのドメインと判定される事態になりました。
前章:「メールサーバーをレンタルサーバーへ移行」を読む
目次:システム奮闘記に戻る