迷惑メールの温床 sakura.ne.jp さくらインターネット

今年に入って sakura.ne.jp ドメインからの迷惑メールが増加。

普通、迷惑メールは国外のアクセスポイントを経由して送られてきますが、まれに国内アクセスポイントから送られてくることがあります。なぜ国外のアクセスポイントやサーバーが使われるかというと、国内アクセスポイントやサーバーを使うと簡単に足が付いて穴をふさがれるから。

例外が、さくらインターネット。このプロバイダーはひどい。 過去に何度かさくらインターネットのアクセスポイントからWebサーバーへの侵入を試みるアクセスが発生しています。

以下が私の FreeBSDサーバーの、先月(2022年2月)のメールログから sakura.ne.jp からの接続を一部抽出したもの。

Feb  5 12:57:24 sm-mta[96927]: 2153vN23096927: from=<supprot@ts3card.com>, size=36820, class=0, nrcpts=0, proto=ESMTP, daemon=IPv4, relay=ik1-430-47253.vs.sakura.ne.jp [153.127.65.7]
Feb  6 04:20:39 sm-mta[5208]: 215JKcsE005208: from=<supprot@ts3card.com>, size=0, class=0, nrcpts=0, proto=ESMTPS, daemon=IPv4, relay=os3-324-51806.vs.sakura.ne.jp [49.212.153.60]
Feb  6 07:46:32 sm-mta[5556]: 215MkVb2005556: from=<supprot@jcb.co.jp>, size=0, class=0, nrcpts=0, proto=ESMTPS, daemon=IPv4, relay=tk2-201-10024.vs.sakura.ne.jp [160.16.50.28]
Feb  6 07:46:32 sm-mta[5557]: 215MkVSu005557: from=<supprot@jcb.co.jp>, size=0, class=0, nrcpts=0, proto=ESMTPS, daemon=IPv4, relay=tk2-254-36502.vs.sakura.ne.jp [160.16.224.6]
Feb  6 12:11:20 sm-mta[13967]: 2163BJCA013967: from=<noreply@ts3card.com>, size=0, class=0, nrcpts=0, proto=ESMTPS, daemon=IPv4, relay=os3-303-41087.vs.sakura.ne.jp [49.212.194.91]
Feb  7 02:55:08 sm-mta[20018]: 216Ht8jO020018: from=<info@ts3card.com>, size=0, class=0, nrcpts=0, proto=ESMTPS, daemon=IPv4, relay=www31290ue.sakura.ne.jp [49.212.217.64]
Feb  7 03:10:51 sm-mta[20444]: 216IAnA6020444: from=<supprot@ts3card.com>, size=0, class=0, nrcpts=0, proto=ESMTPS, daemon=IPv4, relay=os3-298-38889.vs.sakura.ne.jp [49.212.175.143]
Feb 12 19:02:16 sm-mta[92368]: 21CA2GlZ092368: from=<info@amazon.co.jp>, size=0, class=0, nrcpts=0, proto=ESMTPS, daemon=IPv4, relay=ik1-221-80564.vs.sakura.ne.jp [133.242.210.68]
Feb 13 06:12:30 sm-mta[96969]: 21CLCTCR096969: from=<supprot@my.jcb.co.jp>, size=0, class=0, nrcpts=0, proto=ESMTPS, daemon=IPv4, relay=tk2-257-38431.vs.sakura.ne.jp [160.16.231.185]
Feb 13 06:12:30 sm-mta[96970]: 21CLCTOI096970: from=<supprot@my.jcb.co.jp>, size=0, class=0, nrcpts=0, proto=ESMTPS, daemon=IPv4, relay=tk2-222-20975.vs.sakura.ne.jp [160.16.93.229]
Feb 13 07:27:37 sm-mta[97151]: 21CMRapq097151: from=<noreply@my.jcb.co.jp>, size=0, class=0, nrcpts=0, proto=ESMTPS, daemon=IPv4, relay=tk2-262-40673.vs.sakura.ne.jp [160.16.240.177]
Feb 13 08:56:08 sm-mta[98128]: 21CNu7f9098128: from=<info@vpass.ne.jp>, size=0, class=0, nrcpts=0, proto=ESMTPS, daemon=IPv4, relay=ik1-339-29774.vs.sakura.ne.jp [153.126.207.28]
Feb 13 10:01:02 sm-mta[99024]: 21D1118f099024: from=<noreply@my.jcb.co.jp>, size=0, class=0, nrcpts=0, proto=ESMTPS, daemon=IPv4, relay=os3-379-22858.vs.sakura.ne.jp [133.167.99.112]
Feb 13 12:38:04 sm-mta[5763]: 21D3c3uX005763: from=<noreply@ts3card.com>, size=0, class=0, nrcpts=0, proto=ESMTPS, daemon=IPv4, relay=ik1-111-62024.vs.sakura.ne.jp [133.242.148.28]
Feb 13 12:38:04 sm-mta[5764]: 21D3c43q005764: from=<noreply@ts3card.com>, size=0, class=0, nrcpts=0, proto=ESMTPS, daemon=IPv4, relay=ik1-101-57296.vs.sakura.ne.jp [133.242.129.50]
Feb 13 14:23:48 sm-mta[6745]: 21D5NjXO006745: from=<supprot@ts3card.com>, size=0, class=0, nrcpts=0, proto=ESMTPS, daemon=IPv4, relay=ik1-122-67950.vs.sakura.ne.jp [133.242.171.204]
Feb 13 20:11:57 sm-mta[9657]: 21DBBuTt009657: from=<noreply@ts3card.com>, size=0, class=0, nrcpts=0, proto=ESMTPS, daemon=IPv4, relay=os3-377-21924.vs.sakura.ne.jp [133.167.95.178]
Feb 13 21:28:07 sm-mta[9774]: 21DCS6ZH009774: from=<info@my.jcb.co.jp>, size=0, class=0, nrcpts=0, proto=ESMTPS, daemon=IPv4, relay=tk2-262-40673.vs.sakura.ne.jp [160.16.240.177]
Feb 13 23:04:35 sm-mta[10721]: 21DE4YOw010721: from=<noreply@my.jcb.co.jp>, size=0, class=0, nrcpts=0, proto=ESMTPS, daemon=IPv4, relay=os3-382-24492.vs.sakura.ne.jp [133.167.105.246]
Feb 19 11:34:36 sm-mta[78188]: 21J2YZ6Y078188: from=<userid@aeon.co.jp>, size=0, class=0, nrcpts=0, proto=ESMTPS, daemon=IPv4, relay=ik1-114-63698.vs.sakura.ne.jp [133.242.154.202]
Feb 19 18:32:03 sm-mta[82005]: 21J9W0T2082005: from=<info@amazon.co.jp>, size=0, class=0, nrcpts=0, proto=ESMTPS, daemon=IPv4, relay=os3-329-54256.vs.sakura.ne.jp [49.212.185.10]
Feb 19 18:34:29 sm-mta[82013]: 21J9YSFO082013: from=<noreply@my.jcb.co.jp>, size=0, class=0, nrcpts=0, proto=ESMTPS, daemon=IPv4, relay=tk2-208-13718.vs.sakura.ne.jp [160.16.64.222]
Feb 19 18:34:29 sm-mta[82014]: 21J9YSOF082014: from=<noreply@my.jcb.co.jp>, size=0, class=0, nrcpts=0, proto=ESMTPS, daemon=IPv4, relay=tk2-224-21609.vs.sakura.ne.jp [160.16.96.113]
Feb 22 14:40:20 sm-mta[21382]: 21M5eJTs021382: from=<info@ts3card.com>, size=0, class=0, nrcpts=0, proto=ESMTPS, daemon=IPv4, relay=os3-285-32160.vs.sakura.ne.jp [219.94.248.164]
Feb 23 17:10:30 sm-mta[37244]: 21N8AT9K037244: from=<userid@aeon.co.jp>, size=0, class=0, nrcpts=0, proto=ESMTPS, daemon=IPv4, relay=os3-319-49362.vs.sakura.ne.jp [49.212.131.116]
Feb 24 15:18:25 sm-mta[47797]: 21O6INgO047797: from=<mail@contact.vpass.ne.jp>, size=0, class=0, nrcpts=0, proto=ESMTPS, daemon=IPv4, relay=os3-323-51064.vs.sakura.ne.jp [49.212.144.68]
Feb 27 11:10:31 sm-mta[81997]: 21R2AUXq081997: from=<userid@aeon.co.jp>, size=0, class=0, nrcpts=0, proto=ESMTPS, daemon=IPv4, relay=tk2-406-44074.vs.sakura.ne.jp [160.16.140.78]ろ

ログの from= フィールドはJCBのような大手カード会社、Amazon、イオン ドメインのアドレスを騙り、relay= のフィールドが xxxx.vs.sakura.ne.jp となっていて、迷惑メール送信であることが明らか。

特定のレンタルサーバーだけから迷惑メールが送られてきているのであれば、管理能力が低い借主がハッキングされたのかと考えますが、awk, sort, uniq を使って、送信元ホスト名を処理してみると、

ik1-101-57296.vs.sakura.ne.jp
ik1-111-62024.vs.sakura.ne.jp
ik1-114-63698.vs.sakura.ne.jp
ik1-122-67950.vs.sakura.ne.jp
ik1-221-80564.vs.sakura.ne.jp
ik1-339-29774.vs.sakura.ne.jp
ik1-430-47253.vs.sakura.ne.jp
os3-285-32160.vs.sakura.ne.jp
os3-298-38889.vs.sakura.ne.jp
os3-303-41087.vs.sakura.ne.jp
os3-319-49362.vs.sakura.ne.jp
os3-323-51064.vs.sakura.ne.jp
os3-324-51806.vs.sakura.ne.jp
os3-329-54256.vs.sakura.ne.jp
os3-377-21924.vs.sakura.ne.jp
os3-379-22858.vs.sakura.ne.jp
os3-382-24492.vs.sakura.ne.jp
tk2-201-10024.vs.sakura.ne.jp
tk2-208-13718.vs.sakura.ne.jp
tk2-222-20975.vs.sakura.ne.jp
tk2-224-21609.vs.sakura.ne.jp
tk2-254-36502.vs.sakura.ne.jp
tk2-257-38431.vs.sakura.ne.jp
tk2-262-40673.vs.sakura.ne.jp
tk2-406-44074.vs.sakura.ne.jp
www31290ue.sakura.ne.jp

と、26の異なるホストから送信されていることがわかります。
さらに、処理範囲を2022/01/01 – 本日(2022/03/09) の間に対象を広げてみると、

ik1-101-57296.vs.sakura.ne.jp
ik1-111-62024.vs.sakura.ne.jp
ik1-113-63462.vs.sakura.ne.jp
ik1-114-63698.vs.sakura.ne.jp
ik1-122-67950.vs.sakura.ne.jp
ik1-215-78072.vs.sakura.ne.jp
ik1-221-80564.vs.sakura.ne.jp
ik1-339-29774.vs.sakura.ne.jp
ik1-430-47253.vs.sakura.ne.jp
ik1-432-48289.vs.sakura.ne.jp
ik1-435-49653.vs.sakura.ne.jp
ik1-442-53468.vs.sakura.ne.jp
os3-285-32160.vs.sakura.ne.jp
os3-298-38889.vs.sakura.ne.jp
os3-303-41087.vs.sakura.ne.jp
os3-313-46350.vs.sakura.ne.jp
os3-314-46861.vs.sakura.ne.jp
os3-319-49362.vs.sakura.ne.jp
os3-319-49385.vs.sakura.ne.jp
os3-322-50520.vs.sakura.ne.jp
os3-323-51064.vs.sakura.ne.jp
os3-323-51103.vs.sakura.ne.jp
os3-324-51806.vs.sakura.ne.jp
os3-329-54256.vs.sakura.ne.jp
os3-330-54719.vs.sakura.ne.jp
os3-358-12183.vs.sakura.ne.jp
os3-374-20085.vs.sakura.ne.jp
os3-377-21924.vs.sakura.ne.jp
os3-379-22858.vs.sakura.ne.jp
os3-379-22999.vs.sakura.ne.jp
os3-382-24492.vs.sakura.ne.jp
tk2-201-10024.vs.sakura.ne.jp
tk2-204-11544.vs.sakura.ne.jp
tk2-208-13718.vs.sakura.ne.jp
tk2-213-16255.vs.sakura.ne.jp
tk2-216-17859.vs.sakura.ne.jp
tk2-218-18876.vs.sakura.ne.jp
tk2-222-20975.vs.sakura.ne.jp
tk2-224-21609.vs.sakura.ne.jp
tk2-224-21806.vs.sakura.ne.jp
tk2-250-34581.vs.sakura.ne.jp
tk2-254-36502.vs.sakura.ne.jp
tk2-257-38431.vs.sakura.ne.jp
tk2-259-39185.vs.sakura.ne.jp
tk2-260-39959.vs.sakura.ne.jp
tk2-262-40504.vs.sakura.ne.jp
tk2-262-40673.vs.sakura.ne.jp
tk2-262-40709.vs.sakura.ne.jp
tk2-262-40887.vs.sakura.ne.jp
tk2-406-44074.vs.sakura.ne.jp
www31290ue.sakura.ne.jp

51ものサーバー名が抽出されました。穴があるだけなのか?乗っ取られているのか?プロバイダーのふりして不正事業を運用しているのか?

この不正数になると、一部の利用者の管理レベルが低くてサーバーが不正利用されているというより、sakura.ne.jp のレンタルサーバー事業にセキュリティー的な問題があるとしか言えません。まったくセキュリティー管理がなされていない。詐欺メールの加害者側と考えてもよいレベル。ひょっとすると、さくらインターネット自体がフィッシングメールを企画して市民を騙している可能性がでてきます。

そもそも、このプロバイダー、被害者から連絡を受け付ける姿勢が無く、過去、情報をインプットしても、何のレスポンスもしない、くそプロバイダーです。

sakura.ne.jp は全くあてにならりません。では対策はどうする?

さくらインターネットと付き合いをする必要はないので、さくらインターネットをホスティング使用しているサイトからのメールを全てREJECTしてしまうことにします。
FreeBSD の場合は、/etc/mail/access に

vs.sakura.ne.jp       REJECT

と一行書いて、make maps すればブロック完了。

さくらインターネット って、ただの迷惑なプロバイダーなのか、それとも犯罪加害者側組織なのか?

追記:

上記一行の拒否設定を行ったことで、以下のように、vs.sakura.ne.jp アクセスポイントからのメールは、接続段階で拒否できています。

Mar 9 23:12:23 sm-mta[34814]: ruleset=check_relay, arg1=os3-305-42423.vs.sakura.ne.jp, arg2=49.212.201.177, relay=os3-305-42423.vs.sakura.ne.jp [49.212.201.177], reject=550 5.7.1 Access denied

Comments

  1. 当方さくらユーザーです。
    私の場合、手元に届く国産(?)スパムは「お名前ドットコム」を使ったものがほとんどですね。

    で、そちらのホスト名から推測するに、「さくらのVPS」というサービスだと思います。巨大なサーバの中にXenで複数の仮想PC環境を生成して、それぞれの仮想PCの管理はroot権限まで丸ごとユーザに移譲。httpd、smtpdなどのセキュリティ管理サービスがオプションで存在するかどうかは分かりませんが、少なくとも私自身はVPS時代にそういうオプションの契約はしていませんでした。

    なので、管理不行き届きなVPSが踏み台にされていると考えるのが順当です。スパムメールの現物を添えて定期的に(たとえば毎週1回くらいのペースで)さくらの問い合わせ窓口に通報するのがいいと思います。

    もちろんこの通報作業も、可能な範囲で極力自動化します。
    (たとえば、~/Maildir/spam.sakura/cur/ の中身を丸ごとtarかzipで固めてbase64エンコードまで行うスクリプトを用意しておくとか。)

    いかがでしょう。

    1. いいじまさん、お久しぶりです。
      さくらユーザーでしたか。

      私のサーバーへ、国内のサーバーを経由して、不正メールやスキャンを行ってくるのは、なぜかsakura.ne.jpドメインばかりで、国内ということで さくらインターネットのabuse窓口に情報を入れるのですが、レスポンスはないし、対策が取られる様子も無し。報告するだけ労力の無駄を感じるだけのプロバイダーです。
      一台、二台のIPアドレスから接続があるなら、責任は利用者なのでしょうが、数十のIPアドレスから不正アクセスがあるということは、利用者だけじゃなく、サーバー仕様の問題と言わざるを得ないというのが私の結論です。

      root権限までもらえるという仕様は、クラウドで済ませる主義の人には良いサービスなんでしょうが、不正侵入を防ぎきるのは結構大変な労力とスキルが必要になりますから、そのアンバランスな点を突かれているのかもしれませんね。

  2. 私のとこにもvs.sakura.ne.jpの迷惑メールが来ます。
    わたその場合、正規なメールもvs.sakura.ne.jp
    を使っている物があり、vs.sakura.ne.jp
    丸ごと拒否れないので同フィルタするか検討中です。

    1. テストは必要ですけど、sendmail のメールサーバーなら、access ファイルに以下のように、利用しているサーバー名と、続けて拒否するドメインを書いて、make すればいけるんじゃないかと思います。

      tk2-406-44074.vs.sakura.ne.jp    OK
      vs.sakura.ne.jp                  REJECT
      

コメントを残す