VPS abuse complaint 是什麼意思？

VPS abuse complaint 實際代表的內容

VPS abuse complaint 是針對從您的 IP 位址發出的網路流量所提出的報告。報告會寄送至該 IP 位址區段公開的 abuse contact，再由主機代管商轉交給您，並提供回覆期限。公開的聯絡窗口屬於持有該位址空間的公司，因此第一個讀到您伺服器相關報告的人，幾乎不會是您本人。主機代管商會比對 IP 位址與時間戳記，確認對應的帳戶後再轉寄給您。

這份通知不代表您是故意從事相關行為。對方能取得的唯一識別資訊是 IP 位址。遭入侵的應用程式在 03:00 發送垃圾郵件，與人在 03:00 發送垃圾郵件時產生的報告完全相同。因此，回覆內容才是重點。對方要求您說明來源，以及您採取了哪些變更。

誰會寄送報告，以及報告如何到達您的主機

每個公開 IP 區段都會向區域網際網路註冊管理機構（RIR）註冊：RIPE NCC、ARIN、APNIC、LACNIC 或 AFRINIC。每筆註冊資料都會公布 abuse contact，報告會寄送至該地址。您可以查看與報告寄件者相同的註冊資料：

whois 203.0.113.10 | grep -iE 'netname|descr|abuse'

RIPE 記錄包含 abuse-c: role object，其中列有 abuse-mailbox:。ARIN 記錄則包含 OrgAbuseEmail:。該處公布的地址會收到投訴，因此針對您伺服器的報告會送達您的主機，而不是您的收件匣。

提出報告的一方通常是機器。您遇到的情況幾乎都可歸入以下 4 類：

• 自動掃描器與 honeypot。機器記錄來自您 IP 的連線嘗試，並附上日誌摘錄提出報告。
• 由 mailbox provider 運作的 feedback loop（FBL）。收件者按下垃圾郵件按鈕後，系統會以 ARF（abuse reporting format）格式回傳郵件副本。這是一種專為機器解析而設計的結構化郵件格式。
• 著作權代理人。他們監控 torrent swarm 或巡覽公開 URL，接著傳送 DMCA（digital millennium copyright act）通知，列出檔案、您的 IP 及 UTC 時間戳記。
• blocklist operator 與網路工程師。他們會附上自己日誌中的違規行，寄送簡短郵件。

由於大多數初次報告都是自動產生的，回信爭辯不會有任何作用。有效的是事實：當時正在執行什麼，以及何時停止。

為什麼通知會附帶期限

你的主機同樣是租用的資源。它的位址空間位於上游電信商的網路後方，也會出現在其他人維護的信譽資料庫中。未獲回覆的通報會影響整個網段的評分，而不只是你的單一位址，因此你收到的期限，是上游要求逐層轉交的壓力。請閱讀通知中列出的處理期限，並確實遵守。

未回覆的案件通常會導致 null route，也就是上游丟棄前往該單一 IP 的網路流量，或是暫停該 instance。通常觸發處置的是保持沉默，而不是原始事件本身。特定主機必須採取哪些措施，以及何時採取，會寫在該主機適用的政策與通知中。只有這兩份文件具備引用價值，因此不要依據論壇所聲稱的 provider 允許事項採取行動。

外寄垃圾郵件：為什麼我的 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 postfix

sudo postsuper -d ALL 會清空佇列，也會破壞已寄送郵件的紀錄，因此請先建立副本。接著輪替應用程式持有的所有憑證、更新應用程式，並尋找入侵者留下的痕跡。垃圾郵件事件與主機遭入侵在多數情況下是同一事件，因此請依照 遭駭 VPS 的復原步驟 處理，不要只清空佇列。

連接埠掃描與暴力破解：遭入侵的容器會呈現什麼樣子

這份報告擷取了另一名管理員的日誌內容，呈現如下：

sshd[2841]: Invalid user admin from 203.0.113.10 port 51992

原因幾乎總是出在某個你以為已由防火牆保護的服務。Docker 是常見原因。使用 -p 6379:6379 發布連接埠時，Docker 會將規則寫入 DOCKER-USER 與 nat 鏈。這些鏈會在 ufw 規則之前進行評估，因此 ufw deny 6379 不會阻擋該連接埠，資料庫也就會回應整個網際網路的請求。

sudo ss -ltnp
sudo iptables -S DOCKER-USER
docker ps

ss -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 client 在下載完成後仍持續 seeding。

將時間戳記與 access log 比對。nginx combined log format 將 status 放在第 9 個欄位，request path 放在第 7 個欄位：

sudo grep '14/Aug/2026:03' /var/log/nginx/access.log | awk '{print $9, $7}' | sort | uniq -c | sort -rn | head

在判定沒有提供任何檔案前，先確認時鐘設定。通知使用 UTC，而您的 log 使用伺服器時區。因此，數小時的時差可能讓您查錯時間範圍，並回報錯誤的 negative result：

timedatectl
sudo timedatectl set-timezone UTC

接著修正原因。移除或限制該檔案，在 nginx location block 中使用 autoindex off; 關閉 directory listing，並將 torrent client 綁定至非公開介面的 interface。回覆時列出檔案名稱、所做的變更，以及完成變更的時間。若您認為該主張本身有誤，這是您與寄件者之間的法律問題，通知中會說明提出異議的方式。您的 host 並非裁定該問題的當事方，因此提交爭辯主張內容的 ticket 不會有結果。

封鎖清單項目：為什麼對外寄信突然停止

這類問題通常完全不會寄信通知你。對外郵件會直接停止接受，而退信中會附上原因：

554 5.7.1 Service unavailable; Client host [203.0.113.10] blocked using zen.spamhaus.org

將 IP 的 4 個八位元組反轉，再查詢該清單的 zone，即可確認是否列入清單：

dig +short 10.113.0.203.zen.spamhaus.org

查詢沒有回應內容，表示你未列在該清單中。回應為 127.0.0.x，表示你已列入清單，最後一個八位元組則表示符合哪個子清單。回應落在 127.255.255.x 範圍，表示查詢遭拒，而不是查詢成功，通常是因為查詢經由大型公開解析器送出，而該免費服務不提供這類解析器的查詢。請改用伺服器自己的解析器再次執行，才能取得實際結果。

移除清單項目必須在清單營運者的網站上進行，不能透過主機商處理。而且只有先修正來源問題才有效，因為將你列入清單的陷阱會在下一封郵件送出時再次將你列入。郵件之後能否正常傳送，還取決於另外兩件事。你的 PTR 記錄，也就是該 IP 的反向 DNS 名稱，由主機商管理，因此請他們設定一個能解析回相同位址的名稱，並將該名稱用作 HELO。若 IP 位址是從前一位租戶回收而來，可能帶有你未造成的歷史紀錄；在花一週重新設定 DNS 之前，值得先詢問這件事。正確設定 SPF（sender policy framework）與 DKIM（domainkeys identified mail）記錄，以及將兩者串接起來的 DMARC policy，請參閱使用 Mailcow 執行自有郵件伺服器的指南。

Relay infrastructure，其中包含濫用郵件是日常工作的一部分

如果您執行 Tor exit node、公開 VPN，或供他人使用的 proxy，收到並非由您產生之網路流量的投訴，是正常的營運成本。重點是讓服務明顯呈現為 relay，而不是遭入侵的伺服器。請將 reverse DNS 設定為具描述性的名稱，在 port 80 提供簡短的 notice page，說明該 IP 位址的用途，並迅速以相同說明回覆 abuse mail；此外，使用軟體提供的政策設定，丟棄最常引發通報的連接埠。請使用獨立的 IP 位址，最好也使用獨立的 instance，這樣即使該位址遭 null route，也不會連帶使 Web 應用程式停止運作。開始前請先詢問 host，因為允許的內容會依公司及 IP block 而異；這應直接向對方確認，而不是在論壇討論串中詢問。在 VPS 上執行 Tor exit node 詳細說明 exit policy 與 notice page。

如何回覆才能結案

• 公開一個有人會閱讀的聯絡信箱。RFC 2142 規定，您網域上的 abuse@ 和 postmaster@ 是通報者最先嘗試的地址。請將該信箱託管在受其保護的伺服器以外，因為遭停權的執行個體無法寄送通知，告知您它已遭停權。
• 保留足夠長時間的日誌，才能確實回覆。若日誌在 7 天後輪替，對於 12 天前的流量通報就無從回覆。檢查 journalctl --disk-usage，在 /etc/systemd/journald.conf 中設定 MaxRetentionSec=90d，然後執行 sudo systemctl restart systemd-journald。Web 和 mail 日誌會依 /etc/logrotate.d/ 的排程自行輪替。
• 讓伺服器使用 UTC，這樣通報中的時間戳記就能直接對應日誌中的時間戳記，不必另外換算。
• 將容易引發投訴的服務，與不可遺失的服務分開。讓 mail 使用一個地址，Web 應用程式使用另一個地址，relay 服務則放在各自的執行個體上。針對 IP 採取的措施，會影響該 IP 後方的所有服務。
• 即使調查尚未完成，也要在期限內回覆。附上預計時間的暫時回覆，就足以完成第一輪回覆。

第一封能讓大多數 ticket 結案的回覆，應簡短且具體：

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 hosting。在非託管方案中，租戶就是安全團隊。

順利運作時的情況

濫用申訴首先是路由問題。針對某個位址的報告會送達該位址的負責方，再轉交給能夠修正問題的人員。您能控制的部分包括聯絡位址、日誌保留期限、服務如何分配到不同 IP，以及回覆速度。這些部分處理妥當後，大多數通知往來一次就會結束。相同的做法也能解答 VPS 託管是否安全 這個更大的問題，因為沒有人監控的伺服器，最後往往會出現在其他人的日誌中。

FAQ

滥用申訴是否表示我的 VPS 已遭駭客入侵？

不一定，但這是首先要排除的可能性。報告只能證明流量從您的 IP 發出。外寄垃圾郵件和連接埠掃描更常是遭入侵的應用程式或容器所造成，而不是帳戶擁有者刻意執行。因此，應先使用 sudo postqueue -p 檢查郵件佇列，並使用 sudo ss -ltnp 檢查監聽中的 socket。著作權與封鎖清單通知的性質不同：這類通知通常表示問題來自您刻意執行的服務。

我有多少時間可以回覆滥用通知？

您收到的通知會載明期限，期限會依主機商和事件類別而異。著作權與 spam trap 報告通常給予最短的期限。即使您仍在追查原因，也應將通知中的期限視為實際期限，並在期限前寄出簡短的暫時回覆。負責處理工單的人員重視的是有人已著手處理，以及流量已經停止。

我的 IP 列在封鎖清單上。主機商可以替我移除嗎？

不行。移除列管項目必須由該清單的營運者在其網站上處理，主機商無法控制對方的資料庫。不過，主機商可以控制 PTR 記錄，也就是您 IP 的反向 DNS 名稱；這是值得同時提出的另一項請求。請先修正寄信問題，再申請移除列管，因為將您列入清單的 spam trap 會在下一封訊息出現時再次將您列入清單。

我是否必須告訴主機商實際發生了什麼事？

您必須提供足以結案的資訊：來源為何，以及何時停止。您不必提交鑑識報告，也不必提供使用者資料。含糊的回覆比簡短但具體的回覆更糟，因為處理人員看不出哪些事項已變更，就沒有理由將案件視為已解決。

我可以忽略掃描器傳送的自動化報告嗎？

不行。自動化報告會被計入紀錄；同一個 IP 持續收到報告，會提高主機商整個位址區段的風險評分，這可能使小型事件升級。您的回覆可以只有一段。自動化報告的寄件系統通常不會閱讀回覆，但主機商負責處理工單的人員會閱讀，而這正是決定您的執行個體後續處置方式的人。