著者 Matt Connor
VPSのabuse complaintとは？通知の意味と対応方法
VPSのabuse complaintは、IP addressからの通信を報告する通知です。誰が報告し、ホストへどう届くか、分類ごとの意味と期限内の返信方法を解説します。
VPS の abuse complaint とは何か
VPS の abuse complaint は、あなたの IP address から送信された network traffic に関する報告です。この報告は、その IP block に公開されている abuse contact に送られ、ホスト事業者から返信期限付きであなたに転送されます。公開されている連絡先は、その address space を保有する会社のものです。そのため、あなたの server に関する報告を最初に読むのは、ほとんどの場合あなたではありません。ホスト事業者が IP と timestamp をアカウントに照合し、あなたに転送します。
この通知だけでは、あなたが意図的に何かを実行した証拠にはなりません。報告者が持つ識別情報は IP address だけです。03:00 に breached application が spam を送信した場合も、03:00 に人が spam を送信した場合も、同じ報告になります。だからこそ、重要なのは返信です。送信元が何であったか、そして何を変更したかを説明するよう求められています。
報告は誰が送り、どのようにホストへ届くのか
すべてのパブリック IP ブロックは、地域インターネットレジストリ（RIR）に登録されています。RIPE NCC、ARIN、APNIC、LACNIC、AFRINIC が該当します。各登録情報には abuse の連絡先が公開されており、報告はそこへ送られます。報告者が参照するのと同じ登録情報を確認できます。
whois 203.0.113.10 | grep -iE 'netname|descr|abuse'RIPE の登録情報には、abuse-c: のロールオブジェクトがあり、abuse-mailbox: の行が含まれます。ARIN の登録情報には OrgAbuseEmail: が含まれます。そこに公開されているアドレスが苦情を受け取るため、サーバーに関する報告は、あなたの受信トレイではなくホストに届きます。
報告を送るのは、通常はマシンです。ほとんどの場合、次の 4 種類に分類できます。
- 自動スキャナーとハニーポット。マシンがあなたの IP からの接続試行を記録し、ログの抜粋を添付して報告を送信します。
- メールボックスプロバイダーが運用するフィードバックループ（FBL）。受信者が迷惑メールボタンをクリックすると、メッセージのコピーが ARF（abuse reporting format）で返されます。ARF は、マシンが解析できるように設計された構造化メール形式です。
- 著作権代理人。torrent のスウォームを監視したり、公開 URL をクロールしたりして、ファイル名、あなたの IP、UTC のタイムスタンプを記載した DMCA（digital millennium copyright act）通知を送信します。
- ブロックリストの運用者とネットワークエンジニア。自身のログから問題の行を抜き出し、短いメールを送信します。
最初の報告の多くは自動生成されるため、返信で反論しても効果はありません。重要なのは事実です。何が動作していたのか、そしていつ停止したのかを示します。
期限付きの通知が届く理由
ホストもテナントの 1 つです。ホストのアドレス空間は上流キャリアの背後にあり、他者が運用するレピュテーションデータベースにも登録されています。報告に回答しないと、評価は個別のアドレスではなく、ブロック全体に対して悪化します。そのため、届いた期限は上流から引き継がれた対応要求です。通知に記載された対応期間を確認し、実際の期限として扱ってください。
回答しないケースに対して取られる措置は、通常、null route、つまりその 1 つの IP へのネットワークトラフィックを上流で破棄する措置か、インスタンスの停止です。通常のトリガーは元の事象ではなく、無回答です。特定のホストに対して何がいつ実施されるかは、そのホストのポリシーと通知自体に記載されています。引用する価値があるのはこの 2 つの文書だけです。プロバイダーが許可しているとフォーラムに書かれている内容だけを根拠に対応しないでください。
外部向けスパム: 送信していないメールが VPS から送信される理由
この報告は、使用している IP アドレスからスパムトラップへメールが配信されたか、受信者がメールを迷惑メールとして処理したことを示しています。主な原因は 4 つです。メールフォームを備え、レート制限のない Web アプリケーション、漏洩した SMTP 認証情報を第三者が使用しているケース、本来中継すべきでないホストのメールを中継するメールサーバー、ニュースレターアプリケーションの盗まれたログイン情報です。まずキューを確認してください。侵害された送信元は通常、キューに現れます。
sudo postqueue -p | tail -n 20
sudo postqueue -p | grep -c '^[0-9A-F]'認識できないアドレス宛てのメッセージがキューに数千件ある場合、そのホストがメールを送信しています。次に、認証したユーザーを確認します。
sudo grep -o 'sasl_username=[^ ]*' /var/log/mail.log | sort | uniq -c | sort -rn | head件数が他のアカウントを大きく上回るアカウントが、漏洩した認証情報です。/var/log/mail.log が存在しない場合、システムに rsyslog がインストールされていません。同じ行は journal に記録されています: sudo journalctl -t postfix --since '2 days ago'。
認証したユーザーがいない場合、送信元はローカルプロセスです。中継ルールと開いている接続を確認します。
sudo postconf -n | grep -E 'mynetworks|inet_interfaces|relay'
sudo ss -tnp state established '( dport = :25 )'標準状態の Debian または Ubuntu の Postfix は、見知らぬホストのメールを中継しません。mynetworks を手動でホスティング用サブネット全体に広げると、オープンリレーになります。そのサブネット上の他のテナントが、あなたのサーバー経由で送信することを信頼されるためです。メールサーバー以外のプロセスが所有する port 25 への接続は、そのプロセスが独自にメールを送信するスクリプトであることを示します。これは、侵害された PHP アプリケーションで通常発生する動作です。
調査を始める前に送信を停止し、証拠を保存してください。
sudo systemctl stop postfix
sudo tar czf /root/mailqueue.tgz -C /var/spool postfixsudo postsuper -d ALL はキューを空にしますが、送信内容の記録も破棄します。そのため、先にコピーを取得してください。次に、アプリケーションが保持するすべての認証情報を更新し、アプリケーションを更新して、侵入者が残したものを探します。スパムインシデントと侵害は、ほとんどの場合、同じ事象です。そのため、キューを消去するだけでなく、ハッキングされた VPS の復旧手順に従って対応してください。
ポートスキャンとブルートフォース攻撃: 侵害されたコンテナの状態
このレポートには、別の運用者のログから抜粋した行が含まれています。内容は次のようなものです。
sshd[2841]: Invalid user admin from 203.0.113.10 port 51992原因は、ほぼ例外なくファイアウォールで保護されていると思い込んでいたサービスです。Docker が典型例です。-p 6379:6379 でポートを公開すると、DOCKER-USER と nat のチェーンにルールが書き込まれます。これらは ufw のルールより先に評価されるため、ufw deny 6379 ではブロックできず、データベースがインターネット全体からの接続に応答します。
sudo ss -ltnp
sudo iptables -S DOCKER-USER
docker psss -ltnp で 0.0.0.0 または [::] にバインドされているものは、パブリックアドレスで待ち受けています。ホストからの接続だけが必要な場合は、代わりにループバックアドレス -p 127.0.0.1:6379:6379 へ公開してください。データベースを本来どこで稼働させるべきかは別の判断事項です。データベースを Docker またはホスト上で稼働させるでは、そのトレードオフを説明しています。
自分のサーバーが現在スキャンを実行しているか確認するには、次を実行します。
sudo ss -tnp state syn-sent多数の異なる宛先に対して半開き接続が多数存在する場合、送信元でスキャンが進行中です。カーネルログに nf_conntrack: table full, dropping packet が大量に記録されている場合も、別の観点から同じことが分かります。このサーバーが通常開く必要のない数の接続を、何かが開いています。
侵害されたコンテナは、内部を清掃するのではなく再構築してください。内部で他に何が変更されたかを証明できないため、信頼できるイメージから再構築し、信頼できるデータだけを復元し、そのコンテナが保持していた鍵をローテーションしてください。
著作権侵害通知: 実際に閲覧されたファイルを特定する
DMCA 通知には、URL または torrent info hash、IP アドレス、UTC のタイムスタンプが記載されています。原因のほとんどは、メディアファイルを公開状態で一覧表示するディレクトリか、ダウンロード完了後もシードを続けている torrent クライアントです。
アクセスログの時刻とタイムスタンプを照合します。nginx の combined ログ形式では、ステータスがフィールド 9、リクエストパスがフィールド 7 にあります。
sudo grep '14/Aug/2026:03' /var/log/nginx/access.log | awk '{print $9, $7}' | sort | uniq -c | sort -rn | head何も配信されていないと判断する前に、時刻を確認します。通知は UTC で記載されていますが、ログはサーバーのタイムゾーンを使用します。そのため、数時間のずれによって誤った時間帯を調べ、誤検知を報告することがあります。
timedatectl
sudo timedatectl set-timezone UTC次に原因を修正します。ファイルを削除またはアクセス制限し、nginx の location ブロックで autoindex off; を指定してディレクトリ一覧表示を無効にします。また、torrent クライアントをパブリックインターフェースではないインターフェースにバインドします。返信には、ファイル名、変更内容、変更した時刻を記載します。申し立て自体が誤りだと考える場合、それは送信者との間で解決する法的問題であり、通知に異議申し立ての方法が記載されています。判断する当事者はホストではないため、申し立ての内容を争うチケットを送っても解決しません。
迷惑メールリストへの掲載: なぜ送信メールが突然機能しなくなったのか
この問題は、受信メールがまったく届かない状態で発生することがよくあります。送信メールが突然受け付けられなくなり、バウンスメールに理由が示されます。
554 5.7.1 Service unavailable; Client host [203.0.113.10] blocked using zen.spamhaus.orgIP アドレスの4つのオクテットを逆順に並べ、リストのゾーンを問い合わせると、掲載状況を確認できます。
dig +short 10.113.0.203.zen.spamhaus.org空の応答は、そのリストには掲載されていないことを示します。127.0.0.x の応答は掲載されていることを示し、最後のオクテットで一致したサブリストが分かります。127.255.255.x の範囲の応答は、回答が返されたのではなく、問い合わせが拒否されたことを示します。通常は、大規模なパブリックリゾルバー経由で問い合わせたことが原因です。この無料サービスは、そのようなリゾルバーからの問い合わせに対応していません。サーバー自身のリゾルバーから再実行すると、実際の結果を取得できます。
掲載解除はホスト経由ではなく、リスト運営者のサイトで申請します。ただし、先に原因を解消しておく必要があります。掲載の原因になったトラップが残っていると、次のメッセージで再び掲載されるためです。その後にメールが正常に流れるかどうかは、他の2点にも左右されます。PTR レコードは、その IP アドレスの reverse DNS 名であり、ホスト側が管理します。IP アドレスと同じアドレスへ解決される PTR レコードを設定し、その名前を HELO に使用するようホストへ依頼してください。また、以前の利用者から再割り当てされたアドレスには、自分が作成していない履歴が残っている場合があります。DNS の再構成に1週間を費やす前に、この点を確認しておく価値があります。SPF (sender policy framework) と DKIM (domainkeys identified mail) のレコードを正しく設定し、それらを結び付ける DMARC ポリシーを設定する方法については、Mailcow で独自メールサーバーを運用するガイドで最初から最後まで説明しています。
中継インフラでは、迷惑メールへの対応も運用業務の一部です
Tor の出口ノード、パブリック VPN、または他者向けのプロキシを運用する場合、自分が生成していないトラフィックに関する苦情は、通常の運用コストです。重要なのは、侵害されたサーバーではなく、明確に中継ノードとして見える状態にすることです。逆引き DNS には説明的な名前を設定し、ポート 80 ではそのアドレスの用途を説明する短い案内ページを提供します。abuse メールには同じ説明を添えて迅速に返信し、ソフトウェアが提供するポリシー機能を使って、最も多く報告されるポートを遮断します。専用の IP アドレスで運用し、できれば専用のインスタンスも使用してください。そのアドレスが null route になっても、Web アプリケーションまで停止せずに済みます。開始前にホスティング事業者へ確認してください。許可される内容は会社や IP ブロックによって異なるため、フォーラムの投稿ではなく、事業者に確認する必要があります。VPS で Tor の出口ノードを運用するでは、出口ポリシーと案内ページについて詳しく説明します。
チケットをクローズできる回答方法
- 読まれる連絡先を公開します。RFC 2142 により、ドメイン上の
abuse@とpostmaster@が、通報者が最初に試すアドレスになります。このメールボックスは、保護対象のサーバー以外でホストしてください。停止されたインスタンスでは、停止されたことを知らせる通知を配信できないためです。 - ログを確認できる期間だけ保持します。12 日前の通信に関する報告も、7 日後にログがローテーションされていれば回答できません。
journalctl --disk-usageを確認し、/etc/systemd/journald.confにMaxRetentionSec=90dを設定してから、sudo systemctl restart systemd-journaldを実行します。Web ログとメールログは、/etc/logrotate.d/の設定に従ってそれぞれローテーションされます。 - サーバーのタイムゾーンを UTC にします。これにより、報告書のタイムスタンプとログのタイムスタンプを途中で換算せずに照合できます。
- 苦情を招くサービスと、失うことのできないサービスを分離します。メールは 1 つのアドレス、Web アプリケーションは別のアドレス、リレーサービスは専用のインスタンスで運用します。IP に対して実施された措置は、その背後にあるすべてに適用されます。
- 調査が終わっていなくても、期限内に回答します。回答予定時刻を記載した保留中の返信でも、初回対応としては十分です。
多くのチケットをクローズできる初回返信は、短く具体的です。
Received, thank you. Confirmed at 09:14 UTC.
Source: a contact form in our web app that allowed unauthenticated sending.
Action: form disabled, Postfix stopped, all SMTP credentials rotated 09:31 UTC.
Evidence: mail queue and logs preserved for 90 days if you need them.
Next: patched app redeployed by 18:00 UTC today. I will confirm here.把握している内容と、まだ解明できていない内容を伝えます。無回答は、管理されていないサーバーだと受け取られます。エスカレーションの手順は、管理されていないサーバーを対象としています。これらの対応がそもそも自分の担当かどうかは、購入した製品によって異なります。実務上の違いは、マネージド VPS ホスティングとアンマネージド VPS ホスティングの違いにあります。アンマネージドプランでは、テナント自身がセキュリティチームです。
問題なく機能している場合の状態
不正利用に関する苦情は、何よりもまずルーティングの問題です。あるアドレスに関する報告は、そのアドレスの管理責任者に届き、対応できる担当者へ引き継がれます。自分で管理できるのは、連絡先アドレス、ログの保持期間、サービスを IP ごとに分離する方法、返信の速さです。これらを適切に設定すれば、多くの通知は1回のやり取りで終わります。同じ運用習慣によって、VPS ホスティングが安全かどうかという大きな問題にも答えられます。誰も監視していないサーバーは、他者のログに記録される状態になるからです。
FAQ
不正利用の苦情が届いた場合、VPS はハッキングされていますか？
それだけでは判断できません。ただし、最初に除外すべき可能性です。この報告から分かるのは、あなたの IP からトラフィックが送信されたことだけです。送信スパムやポートスキャンは、アカウント所有者よりも、侵害されたアプリケーションやコンテナが原因であることがはるかに多いため、まず sudo postqueue -p でメールキューを、sudo ss -ltnp で待ち受け中のソケットを確認します。著作権およびブロックリストに関する通知は性質が異なります。通常は、意図的に実行しているものが原因です。
不正利用の通知には、どのくらいの期間内に返信する必要がありますか？
期限は受け取った通知に記載されており、ホストやカテゴリによって異なります。著作権およびスパムトラップの報告は、期限が最も短い傾向があります。記載された期限を実際の締め切りとして扱い、原因を調査中であっても、期限前に短い中間報告を送信します。チケットの担当者にとって重要なのは、担当者が対応中であり、トラフィックが停止していることです。
IP がブロックリストに登録されています。ホストに削除してもらえますか？
いいえ。リストからの削除は、そのリストの運営者が自身のサイトで行うため、ホストにはデータベースを操作する権限がありません。一方、ホストは IP の PTR レコード、つまり逆引き DNS 名を管理しています。これは別の依頼になるため、同時に申請する価値があります。削除を依頼する前に、送信の問題を解決してください。あなたを登録したスパムトラップは、次のメッセージを受信すると再び登録するためです。
実際に何が起きたのかを、ホストに伝える必要がありますか？
チケットを終了できるだけの情報、つまり原因と停止時刻を伝える必要があります。フォレンジックレポートやユーザーのデータまで提出する必要はありません。曖昧な返信は、簡潔な返信よりも悪い結果を招きます。何が変わったのかを確認できない担当者には、問題が解決したと判断する理由がないためです。
スキャナーから自動送信された報告は無視できますか？
いいえ。自動報告も件数として記録されます。同じ IP に関する報告が繰り返されると、ホストのアドレスブロック全体に対する評価が悪化し、小さな問題がエスカレーションに発展します。返信は 1 段落で構いません。自動報告の送信元が返信を読むことは通常ありませんが、ホスト側でチケットを担当する人は読みます。その人が、あなたのインスタンスに対する対応を決定します。