アクセス観測

★はじめに

ある時期から、自身が管理する独自ドメイン宛に大量のSPAMメールが継続的に届くようになった。
宛先は null@sky.0t0.jp で、これは無効アドレスではなく、意図的に受信・観測用として運用していた有効なメールアドレスである。

本稿は、このSPAM挙動と、その前後で観測されたメールおよびWebアクセスの変化について、感情や推測を排し、事実と構造のみを記録する技術メモである。

★環境の概要

・独自ドメインによるメール運用
・自前サーバーでの受信・ログ管理
・Web サイトは静的コンテンツ中心

メールは受信のみを行い、外部への送信はプロバイダ経由で行っていた。

★観測されていたSPAMの状況

・null@sky.0t0.jp 宛に、日常的かつ大量のSPAMメールが到達
・送信元は多岐にわたり、典型的な自動送信の特徴を示す
・到達は長期間にわたり継続
・正規メールは問題なく受信されていた

この時点では、SPAMは「一般的なインターネット上のノイズ」として扱っていた。

★共有ホスティング環境におけるSPAM判定仕様（観測ベース）

在職中に関係していた共有ホスティング環境について、管理画面・挙動・ログから以下の点が観測された。

・グローバルな RBL / BL（Spamhaus 等）を参照している形跡がない
・SPAM判定はユーザー単位の SpamAssassin 学習結果に強く依存
・アクセス制限・送信元制御が比較的緩い
・利用者が「なぜSPAMと判定されたか」を定量的に確認する手段が乏しい

これにより、利用者が意識的に学習させなければSPAMに埋もれやすい構造になっていると思われる。

★問題が発生した際の構図

SPAMが多発していた時期、関係者側ではこれを「メールアドレス漏えい」と解釈した。

その際、

・転送先が独自ドメインである
・自前サーバーでメールを受信している
・技術的な仕組みが十分に共有されていない

といった理由から、自分のメール転送設定が原因と見なされる状況が発生した。

しかし実際には、

・独自ドメインは中継ではない
・ブラックリストへの掲載は確認されていない
・当該サーバーはOP25Bの制約上受信のみで、送信は別経路

という、ごく基本的な構成であった。

自前サーバーを運用するという概念自体が、十分に共有されていなかったと考えられる。

★その後に観測された変化

この構成について技術的説明を行った後の時期と重なる形で、以下の変化が観測された。

その後、null@sky.0t0.jp 宛のSPAMメールが止めどもなく来るようになったと同時に、Webサイトに対して監視されているかのようなLOGが半年以上も継続して残るようになった。

しかし最近になり、null@sky.0t0.jp 宛のSPAMが完全に停止

・一晩で到達件数がゼロ
・過去に同様の停止事例はない
・正規メール（通知・連絡メール等）は通常通り受信
・Web サイトに対する定常的なアクセス（監視的挙動を含む）は継続

SPAMは段階的に減少することが多く、このような即時停止は一般的ではない。

★監視アクセスとSPAMの関係について

Web 側では、一般的なクローラとは異なる挙動を示すアクセスが継続して記録されていた。

・一般ブラウザを装った User-Agent
・定期的・継続的なアクセス

これらの挙動とSPAM停止との関係について、本稿では断定しない。
ただし、SPAMが偶然ゼロになる確率は極めて低いことは事実として記録しておく。

★問題の本質

本件を通じて明らかになったのは、共有ホスティングサービスの構造的問題である。

・利用者が理解していないこと自体が問題なのではなく、理解しなくても使えてしまう設計
・測定・検証ができないSPAM判定仕様
・問題発生時に「利用者責任」へ収束しやすい運用

これはユーザー側の運用上の問題ではなく、安価な共有ホスティング環境が抱えやすい構造的課題だと考えられる。

本日早朝、約30分間にわたり集中した通信が観測された。

ファイアウォールのカウンタでは、短時間で DROP 数が2000以上増加している。
主に HTTPS（443/tcp）宛ての接続試行が大半を占め、HTTP（80/tcp）および SSH（22/tcp）への試行も少数確認された。

DROP tcp dpt:22 16
DROP tcp dpt:80 74
DROP tcp dpt:443 2629

すべての通信はファイアウォールにより遮断されており、セッション確立や Web サービスへの到達は確認されていない。

iftop による観測状況

同時間帯に iftop で確認した通信状況を以下に示す。

pdf8621af.tubecm00.ap.so-net.ne.jp:https <= syn-024-167-221-251.res.spectrum.com:58920 256b 307b 102b
pdf8621af.tubecm00.ap.so-net.ne.jp:https <= ip68-228-247-224.ph.ph.cox.net:50471 240b 192b 64b
pdf8621af.tubecm00.ap.so-net.ne.jp:https <= 142.173.12.182:55359 240b 144b 48b
pdf8621af.tubecm00.ap.so-net.ne.jp:https <= 142.173.110.157:47419 240b 144b 48b
pdf8621af.tubecm00.ap.so-net.ne.jp:https <= 172.243.85.162:52556 0b 125b 42b
pdf8621af.tubecm00.ap.so-net.ne.jp:https <= 23-120-60-214.lightspeed.bcvloh.sbcglobal.net:35753 0b 96b 64b
pdf8621af.tubecm00.ap.so-net.ne.jp:https <= dhcp-9-134-100-80.gobrightspeed.net:55148 0b 51b 137b
pdf8621af.tubecm00.ap.so-net.ne.jp:https <= syn-104-231-067-103.res.spectrum.com:39906 240b 48b 48b
（以下略）

午前零時からの集計で、443ポートへのDROP数が8500パケットを超えた。

接続できないことを理解した上で、なお繰り返されるアクセス。
これは偶然でも誤動作でもない。

率直に言って、その行為は違法（犯罪）である可能性が極めて高いが、本当に大丈夫なのだろうか。

日本の法律に照らすと、少なくとも次の2点が問題になる。

１．不正アクセス禁止法（未遂を含む）

ファイアウォールなどの「アクセス制御機能」を回避・突破しようとする行為そのものが禁じられている。
脆弱性スキャンや総当たり的な試行は、成功しなくても違法性を問われ得る。

また、脆弱性を収集・共有する行為も、不正アクセスの助長として問題視される。

２．電子計算機損壊等業務妨害罪（刑法234条の2）

いわゆるDoS／DDoSに関連する罪だ。
サーバーが実際にダウンしていなくても、大量のパケットを送り付け、運用や通信を妨害すれば成立し得る。

各国のVPSを使い、時間帯を揃えて負荷をかけている点から見ても、過失ではなく明確な妨害の意思が感じられる。

こちらは淡々とDROPしているだけだが、相手は一線を踏み越えている可能性が高い。
無意味な行動を続けるほど、記録だけが積み上がっていく。

第2波のアクセス（分散型 HTTPS 試行）に続いて、その後更に、海外のVPS・クラウドIPを中心とした 443番ポート通信の急増 が観測された。

Webサーバ層に到達する前段階でルーターにより遮断されており、本記事では、その 通信挙動そのもの を記録として残す。

pdf8621af.tubecm00.ap.so-net.ne.jp:https <= 136-0-105-211.ips.acedatacenter.com:60175 240b 192b 56b
pdf8621af.tubecm00.ap.so-net.ne.jp:https <= 92.113.115.224:51277 240b 144b 42b
pdf8621af.tubecm00.ap.so-net.ne.jp:https <= 173.214.177.113:60915 240b 144b 42b
pdf8621af.tubecm00.ap.so-net.ne.jp:https <= 209.127.143.128:43363 240b 96b 28b
pdf8621af.tubecm00.ap.so-net.ne.jp:https <= ec2-54-185-117-160.us-west-2.compute.amazonaws.com:7105 0b 48b 71b
pdf8621af.tubecm00.ap.so-net.ne.jp:https <= 192-210-191-185-host.colocrossing.com:51365 0b 48b 56b

接続元は以下のように分散している。

・AWS EC2（us-west-2）
・Ace Data Center
・ColocationAmerica
・Spectrum / Cox などの海外ISP
・その他クラウド・VPS系IP

いずれも 送信元ポートがランダム であり、特定のアプリケーション通信ではない ことが分かる。

パケットサイズの特徴

多くの通信で以下の特徴が見られる。

・送信：240b / 0b
・応答：192b / 144b / 96b / 48b
・極端に小さいサイズで完結

記事「不審アクセスの挙動分析（一般ユーザーを装った閲覧の可能性）」に対する追記。

最初の閲覧ログと443番ポートへの大量 DROP 発生から、1時間足らずでさらに約 1000 パケットの DROP が追加で発生した。
今回の特徴は、送信元が明確に分散している点である。

以下は確認された通信の一部である。

pdf8621af.tubecm00.ap.so-net.ne.jp:https <= 96-19-219-10.cpe.sparklight.net
pdf8621af.tubecm00.ap.so-net.ne.jp:https <= 162.243.235.175
pdf8621af.tubecm00.ap.so-net.ne.jp:https <= 134.122.126.186
pdf8621af.tubecm00.ap.so-net.ne.jp:https <= 207-246-120-238.lum-int.io
pdf8621af.tubecm00.ap.so-net.ne.jp:https <= 162.243.50.24
pdf8621af.tubecm00.ap.so-net.ne.jp:https <= 137.184.55.200
pdf8621af.tubecm00.ap.so-net.ne.jp:https <= spectrum.com / cox.net / myvzw.com など

・国・ASN・回線種別がばらけている
・単発かつ少量の HTTPS 試行
・正常なセッション確立には至らない
・すべて DROP 処理

明らかに 1つの回線からの連続試行ではない。

挙動の特徴

この第2波では、以下の点が顕著である。

・VPS（DigitalOcean 系）
・回線住宅系（Cable / Mobile）
・Proxy・踏み台用途でよく使われる AS

これらが短時間に混在しており、通常のクローラや誤設定では説明がつかない。

また、送信バイト数がほぼ一定である点から、

・HTTPS ハンドシェイク前段のみ
・到達可否チェック
・フィルタ挙動の確認

といった自動化された疎通確認である可能性が高い。

一連の流れの整理

ここまでの時系列は以下のようになる。

１．国内回線・一般的な UA での閲覧
２．不審アクセス対処記事を重点的に確認
３．数時間後、443番ポートへの集中的な試行
４．さらに1時間以内に、送信元を分散させた第2波