Khiếu nại lạm dụng VPS là gì và cách xử lý hiệu quả

Khiếu nại lạm dụng VPS thực chất là gì

Khiếu nại lạm dụng VPS là một báo cáo về lưu lượng truy cập xuất phát từ địa chỉ IP của bạn. Báo cáo này được gửi đến đầu mối liên hệ lạm dụng đã công bố cho dải IP đó, sau đó nhà cung cấp host sẽ chuyển tiếp cho bạn kèm theo thời hạn phản hồi. Đầu mối liên hệ đã công bố thuộc về công ty sở hữu không gian địa chỉ, vì vậy người đầu tiên đọc báo cáo về máy chủ của bạn hầu như không bao giờ là bạn. Nhà cung cấp host sẽ đối chiếu IP và dấu thời gian với tài khoản của bạn rồi chuyển tiếp thông tin đó.

Thông báo này không phải là bằng chứng cho thấy bạn đã cố tình thực hiện bất kỳ hành động nào. Địa chỉ IP là định danh duy nhất mà người báo cáo có. Một ứng dụng bị compromised gửi spam lúc 03:00 tạo ra báo cáo giống hệt như một người gửi spam lúc 03:00. Đây là lý do tại sao phần phản hồi mới là phần quan trọng. Bạn đang được yêu cầu giải trình nguồn gốc của lưu lượng đó là gì và bạn đã thực hiện thay đổi nào.

Ai gửi báo cáo và làm thế nào nó đến được máy chủ của bạn

Mỗi dải IP công cộng đều được đăng ký với một cơ quan đăng ký internet khu vực (RIR): RIPE NCC, ARIN, APNIC, LACNIC hoặc AFRINIC. Mỗi bản ghi đều công bố một địa chỉ liên hệ lạm dụng (abuse contact), và đó là nơi các báo cáo được gửi đến. Bạn có thể đọc chính bản ghi mà người báo cáo đã đọc:

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

Các bản ghi RIPE chứa một đối tượng abuse-c: role với một dòng abuse-mailbox:. Các bản ghi ARIN chứa OrgAbuseEmail:. Bất kỳ địa chỉ nào được công bố ở đó đều nhận được khiếu nại, đó là lý do tại sao báo cáo về máy chủ của bạn lại đến máy chủ lưu trữ (host) thay vì vào hộp thư đến của bạn.

Bên gửi báo cáo thường là một hệ thống tự động. Bốn loại dưới đây bao quát hầu hết mọi trường hợp bạn sẽ gặp:

• Các trình quét tự động và honeypot. Một hệ thống ghi lại nỗ lực kết nối từ IP của bạn và gửi báo cáo kèm theo đoạn log trích dẫn.
• Các vòng lặp phản hồi (FBL) do các nhà cung cấp dịch vụ hộp thư vận hành. Người nhận nhấn nút báo cáo thư rác và một bản sao của tin nhắn được gửi lại dưới định dạng ARF (abuse reporting format), một định dạng thư có cấu trúc được xây dựng để máy tính phân tích.
• Các đại lý bản quyền. Họ theo dõi các swarm torrent hoặc thu thập dữ liệu từ các URL công cộng, sau đó gửi thông báo DMCA (đạo luật bản quyền thiên niên kỷ kỹ thuật số) nêu tên tệp tin, IP của bạn và dấu thời gian theo chuẩn UTC.
• Các nhà vận hành danh sách chặn (blocklist) và kỹ sư mạng, những người gửi một email ngắn kèm theo các dòng vi phạm từ log của chính họ.

Vì hầu hết các báo cáo đầu tiên đều được tạo tự động, việc tranh luận trong thư phản hồi sẽ không mang lại kết quả gì. Một sự thật mới là thứ giải quyết được vấn đề: cái gì đã chạy và khi nào nó dừng lại.

Tại sao thông báo lại đi kèm thời hạn

Máy chủ của bạn cũng là một khách thuê. Không gian địa chỉ của nó nằm sau các nhà mạng thượng nguồn và bên trong các cơ sở dữ liệu uy tín do người khác vận hành. Các báo cáo không được phản hồi sẽ làm tăng điểm xấu cho toàn bộ dải IP thay vì chỉ riêng địa chỉ của bạn, vì vậy thời hạn bạn nhận được là áp lực được chuyển xuống từ phía trên. Hãy đọc khoảng thời gian được nêu trong thông báo và coi đó là thời hạn thực tế.

Khi một trường hợp không được phản hồi dẫn đến hậu quả, thường đó là null route, nghĩa là lưu lượng truy cập đến IP đó bị chặn ở thượng nguồn, hoặc là tạm ngưng instance. Tác nhân kích hoạt thường là sự im lặng, không phải sự kiện ban đầu. Những gì một nhà cung cấp cụ thể thực hiện và thời điểm thực hiện đều được ghi trong chính sách của họ và trong chính thông báo đó. Hai tài liệu này là những thứ duy nhất đáng để trích dẫn, vì vậy đừng hành động dựa trên những gì diễn đàn tuyên bố về việc nhà cung cấp cho phép làm gì.

Spam outbound: tại sao VPS của bạn lại gửi email mà bạn không hề gửi

Báo cáo cho biết IP của bạn đã gửi email đến một spam trap, hoặc người nhận đánh dấu email của bạn là rác. Bốn nguồn sau đây chiếm phần lớn các trường hợp: một ứng dụng web có form gửi mail nhưng không giới hạn tốc độ (rate limit), thông tin đăng nhập SMTP bị lộ và đang bị kẻ khác sử dụng, một mail server cho phép relay cho các host không được phép, và tài khoản bị đánh cắp trên một ứng dụng gửi bản tin (newsletter). Hãy bắt đầu với hàng đợi (queue), vì một người gửi bị chiếm quyền thường hiển thị rõ ở đó:

sudo postqueue -p | tail -n 20
sudo postqueue -p | grep -c '^[0-9A-F]'

Một hàng đợi chứa hàng ngàn tin nhắn gửi đến các địa chỉ bạn không nhận ra nghĩa là máy chủ đang gửi spam. Tiếp theo, hãy tìm xem ai đã xác thực:

sudo grep -o 'sasl_username=[^ ]*' /var/log/mail.log | sort | uniq -c | sort -rn | head

Một tài khoản có số lượng gửi vượt xa các tài khoản khác chính là thông tin đăng nhập bị lộ. Nếu /var/log/mail.log không tồn tại, hệ thống không cài đặt rsyslog và các dòng tương tự sẽ nằm trong journal: sudo journalctl -t postfix --since '2 days ago'.

Nếu không có tài khoản nào xác thực, người gửi là một tiến trình cục bộ. Hãy kiểm tra các quy tắc relay và các kết nối đang mở:

sudo postconf -n | grep -E 'mynetworks|inet_interfaces|relay'
sudo ss -tnp state established '( dport = :25 )'

Postfix mặc định trên Debian hoặc Ubuntu không relay cho người lạ. Nó trở thành open relay khi mynetworks bị sửa đổi thủ công để mở rộng cho toàn bộ subnet của nhà cung cấp dịch vụ, vì khi đó mọi khách hàng khác trên subnet đó đều được tin tưởng để gửi mail qua bạn. Bất kỳ kết nối nào đến cổng 25 mà không thuộc về mail server của bạn đều là một script đang tự gửi mail, đây là hành vi thường thấy của một ứng dụng PHP bị chiếm quyền.

Hãy dừng luồng gửi mail trước khi điều tra và giữ lại bằng chứng:

sudo systemctl stop postfix
sudo tar czf /root/mailqueue.tgz -C /var/spool postfix

sudo postsuper -d ALL sẽ làm trống hàng đợi, nhưng nó cũng xóa sạch hồ sơ về những gì đã được gửi, vì vậy hãy sao lưu trước. Sau đó, thay đổi mọi thông tin đăng nhập mà ứng dụng đang sử dụng, cập nhật ứng dụng và tìm kiếm những gì kẻ xâm nhập để lại. Sự cố spam và việc bị chiếm quyền thường là cùng một sự kiện, vì vậy hãy thực hiện theo các bước khôi phục cho VPS bị hack thay vì chỉ xóa hàng đợi.

Quét cổng và tấn công brute force: dấu hiệu của một container bị chiếm quyền

Báo cáo này chứa các dòng log từ một nhà vận hành khác, và chúng trông như thế này:

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

Nguyên nhân hầu như luôn là một dịch vụ mà bạn tin rằng đã được firewall chặn. Docker là trường hợp thường gặp nhất. Việc publish một cổng bằng -p 6379:6379 sẽ ghi các quy tắc vào chuỗi DOCKER-USER và nat, và các quy tắc này được đánh giá trước cả quy tắc của ufw, vì vậy ufw deny 6379 không chặn được nó và cơ sở dữ liệu sẽ phản hồi toàn bộ Internet.

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

Bất kỳ thứ gì trong ss -ltnp bind vào 0.0.0.0 hoặc [::] đều đang lắng nghe trên địa chỉ công cộng. Hãy publish vào địa chỉ loopback thay thế, -p 127.0.0.1:6379:6379, khi chỉ host cần truy cập nó. Việc quyết định nơi đặt cơ sở dữ liệu là một vấn đề riêng biệt, và chạy cơ sở dữ liệu trong Docker hay trên host sẽ giải quyết sự đánh đổi đó.

Để xem máy của bạn có đang thực hiện quét ngay lúc này không:

sudo ss -tnp state syn-sent

Nhiều kết nối bán mở (half-open) đến nhiều đích khác nhau là dấu hiệu một cuộc quét outbound đang diễn ra. Một log kernel đầy các dòng nf_conntrack: table full, dropping packet cũng cho thấy điều tương tự từ một góc độ khác: có thứ gì đó đang mở nhiều kết nối hơn mức cần thiết cho máy chủ này.

Hãy rebuild lại container bị chiếm quyền thay vì cố gắng làm sạch nó. Bạn không thể chứng minh được những gì khác đã bị thay đổi bên trong, vì vậy hãy rebuild từ một image mà bạn tin tưởng, chỉ khôi phục dữ liệu mà bạn tin tưởng, và rotate các key mà container đó đã lưu giữ.

Thông báo bản quyền: họ thực sự đã thấy file nào

Một thông báo DMCA sẽ nêu tên một URL hoặc info hash của torrent, địa chỉ IP của bạn và dấu thời gian theo chuẩn UTC. Hai nguyên nhân chiếm gần như toàn bộ các trường hợp này: một thư mục chứa các file media mà web server đang liệt kê công khai, và một torrent client vẫn đang seeding sau khi quá trình tải xuống hoàn tất.

Hãy đối chiếu dấu thời gian với access log. Định dạng log kết hợp (combined log format) của Nginx đặt mã trạng thái ở trường thứ 9 và đường dẫn yêu cầu ở trường thứ 7:

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

Trước khi kết luận rằng không có dữ liệu nào được gửi đi, hãy kiểm tra đồng hồ hệ thống. Thông báo được ghi theo giờ UTC trong khi log của bạn sử dụng múi giờ của máy chủ, vì vậy chênh lệch vài giờ sẽ khiến bạn tìm kiếm sai khoảng thời gian và báo cáo kết quả âm tính giả:

timedatectl
sudo timedatectl set-timezone UTC

Sau đó, hãy khắc phục nguyên nhân. Xóa hoặc hạn chế quyền truy cập file, tắt tính năng liệt kê thư mục bằng autoindex off; trong block location của Nginx, và bind torrent client vào một interface không phải là interface công cộng. Hãy phản hồi bằng cách nêu tên file, thay đổi đã thực hiện và thời điểm bạn thực hiện thay đổi đó. Nếu bạn cho rằng bản thân khiếu nại là sai, đó là vấn đề pháp lý giữa bạn và bên gửi, và thông báo đã nêu rõ cách thức tranh chấp. Nhà cung cấp dịch vụ của bạn không phải là bên đưa ra quyết định, vì vậy việc gửi ticket tranh luận về tính đúng sai của khiếu nại sẽ không mang lại kết quả gì.

Danh sách chặn: tại sao email gửi đi của tôi ngừng hoạt động

Vấn đề này thường xảy ra mà không có thông báo nào gửi đến bạn. Email gửi đi đơn giản là bị từ chối, và thông báo trả về (bounce) sẽ nêu rõ lý do:

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

Kiểm tra một danh sách bằng cách đảo ngược bốn octet của địa chỉ IP và truy vấn zone của danh sách đó:

dig +short 10.113.0.203.zen.spamhaus.org

Kết quả trống nghĩa là bạn không nằm trong danh sách đó. Kết quả 127.0.0.x nghĩa là bạn đã bị liệt kê, và octet cuối cùng cho biết sublist nào đã khớp. Kết quả trong dải 127.255.255.x nghĩa là truy vấn bị từ chối thay vì được trả lời, thường là do bạn thực hiện qua một public resolver lớn mà dịch vụ miễn phí đó không hỗ trợ. Hãy chạy lại lệnh từ chính resolver của máy chủ để nhận kết quả chính xác.

Việc gỡ bỏ khỏi danh sách (delisting) được thực hiện trên trang web của đơn vị vận hành danh sách, không phải thông qua nhà cung cấp host của bạn. Việc này chỉ có hiệu lực nếu nguồn gốc vấn đề đã được khắc phục trước, vì cái bẫy đã liệt kê bạn sẽ tiếp tục liệt kê bạn ở tin nhắn tiếp theo. Hai yếu tố khác quyết định việc email có lưu thông sau đó hay không. Bản ghi PTR, tên reverse DNS cho IP, được kiểm soát bởi nhà cung cấp host của bạn, vì vậy hãy yêu cầu họ thiết lập một bản ghi phân giải ngược về đúng địa chỉ đó và sử dụng tên đó làm HELO. Ngoài ra, một địa chỉ IP được tái sử dụng từ người thuê trước có thể mang theo lịch sử mà bạn không tạo ra; đây là điều đáng hỏi trước khi bạn dành cả tuần để cấu hình lại DNS. Việc thiết lập đúng các bản ghi SPF (sender policy framework) và DKIM (domainkeys identified mail), cùng với chính sách DMARC liên kết chúng, đã được hướng dẫn chi tiết trong hướng dẫn tự vận hành máy chủ mail với Mailcow.

Hạ tầng relay, nơi email lạm dụng là một phần công việc

Nếu bạn vận hành một Tor exit node, một VPN công cộng hoặc proxy cho người khác, các khiếu nại về lưu lượng mà bạn không tạo ra là chi phí vận hành bình thường. Công việc ở đây là làm cho hệ thống trông giống một relay thay vì một máy chủ bị compromised. Hãy thiết lập reverse DNS thành một cái tên mang tính mô tả, phục vụ một trang thông báo ngắn trên cổng 80 giải thích địa chỉ này là gì, phản hồi email lạm dụng nhanh chóng với cùng lời giải thích đó, và sử dụng bất kỳ chính sách nào mà phần mềm cung cấp để chặn các cổng tạo ra nhiều báo cáo nhất. Hãy chạy nó trên một địa chỉ IP riêng, và lý tưởng nhất là trên một instance riêng, để việc null route địa chỉ đó không làm sập ứng dụng web của bạn. Hãy hỏi nhà cung cấp hosting trước khi bắt đầu, vì những gì được phép sẽ khác nhau tùy theo công ty và đôi khi là tùy theo dải IP, và đó là câu hỏi dành cho họ thay vì một chủ đề trên diễn đàn. Chạy một Tor exit node trên VPS sẽ đi sâu vào chi tiết về chính sách exit và trang thông báo.

Cách phản hồi để đóng ticket

• Công khai một địa chỉ liên hệ mà con người có thể đọc được. RFC 2142 quy định abuse@ và postmaster@ trên domain của bạn là những địa chỉ mà người báo cáo sẽ thử đầu tiên. Hãy host hộp thư đó ở một nơi khác với máy chủ mà nó bảo vệ, vì một instance bị treo sẽ không thể gửi thông báo cho bạn biết rằng nó đã bị tạm ngưng.
• Lưu log đủ lâu để có thể trả lời. Một báo cáo về lưu lượng từ mười hai ngày trước sẽ không thể giải quyết nếu log đã xoay vòng sau bảy ngày. Kiểm tra journalctl --disk-usage, thiết lập MaxRetentionSec=90d trong /etc/systemd/journald.conf, sau đó chạy sudo systemctl restart systemd-journald. Log web và mail tự xoay vòng theo lịch trình riêng trong /etc/logrotate.d/.
• Giữ máy chủ ở múi giờ UTC, để timestamp trong báo cáo khớp với timestamp trong log mà không cần phải tính toán chênh lệch.
• Tách biệt những thứ dễ gây khiếu nại khỏi những thứ quan trọng không thể mất. Mail trên một địa chỉ, ứng dụng web trên một địa chỉ khác, các dịch vụ relay trên một instance riêng. Hành động xử lý nhắm vào một IP là hành động xử lý nhắm vào mọi thứ phía sau nó.
• Phản hồi trong thời hạn quy định ngay cả khi quá trình điều tra chưa hoàn tất. Một phản hồi tạm thời có kèm theo mốc thời gian là câu trả lời đầy đủ cho vòng đầu tiên.

Một phản hồi đầu tiên giúp đóng hầu hết các ticket thường ngắn gọn và cụ thể:

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.

Hãy nói những gì bạn biết và những gì bạn chưa tìm ra. Sự im lặng được hiểu là một máy chủ không được bảo trì, và quy trình leo thang tồn tại dành cho các máy chủ không được bảo trì. Việc công việc này có thuộc về bạn hay không phụ thuộc vào sản phẩm bạn đã mua, đây là sự khác biệt thực tế giữa managed và unmanaged VPS hosting. Trên gói unmanaged, người thuê chính là đội ngũ bảo mật.

Kết quả khi mọi thứ vận hành ổn định

Một khiếu nại lạm dụng trước hết là một vấn đề về định tuyến. Báo cáo về một địa chỉ IP sẽ được gửi đến bên chịu trách nhiệm cho địa chỉ đó, sau đó được chuyển tiếp xuống người có khả năng xử lý. Những phần bạn có thể kiểm soát bao gồm địa chỉ liên hệ, thời gian lưu log, cách phân chia dịch vụ trên các IP và tốc độ phản hồi. Nếu làm tốt những việc này, hầu hết các thông báo sẽ kết thúc sau một lần trao đổi. Những thói quen tương tự cũng giải quyết vấn đề lớn hơn về liệu VPS hosting có an toàn hay không, bởi vì một máy chủ không được giám sát chính là máy chủ sẽ xuất hiện trong log của người khác.

FAQ

Khiếu nại lạm dụng có nghĩa là VPS của tôi đã bị hack không?

Không hẳn, nhưng đó là điều đầu tiên cần loại trừ. Báo cáo chỉ chứng minh rằng lưu lượng đã đi ra từ IP của bạn. Spam gửi đi và quét cổng thường xuất phát từ một ứng dụng hoặc container bị chiếm quyền điều khiển hơn là từ chính chủ tài khoản, vì vậy hãy kiểm tra hàng đợi mail bằng sudo postqueue -p và các socket đang lắng nghe bằng sudo ss -ltnp trước khi làm bất cứ việc gì khác. Các thông báo về bản quyền và blocklist có tính chất khác: chúng thường chỉ ra thứ gì đó mà bạn đang chủ động chạy.

Tôi có bao nhiêu thời gian để trả lời thông báo lạm dụng?

Thời hạn được ghi trong thông báo bạn nhận được, và nó thay đổi tùy theo nhà cung cấp và danh mục. Các báo cáo về bản quyền và spam-trap thường có thời hạn ngắn nhất. Hãy coi thời gian đã nêu là thực tế và gửi một phản hồi xác nhận ngắn trước khi hết hạn, ngay cả khi bạn vẫn đang truy vết nguyên nhân. Điều quan trọng đối với người xử lý ticket là có người đang giải quyết vấn đề và lưu lượng độc hại đã dừng lại.

IP của tôi nằm trong blocklist. Nhà cung cấp có thể gỡ bỏ nó không?

Không. Việc gỡ bỏ được thực hiện bởi đơn vị vận hành danh sách đó trên trang web của họ, và nhà cung cấp của bạn không có quyền kiểm soát cơ sở dữ liệu của họ. Nhà cung cấp của bạn chỉ kiểm soát bản ghi PTR, tên reverse DNS cho IP của bạn, đây là một yêu cầu riêng biệt đáng thực hiện cùng lúc. Hãy khắc phục vấn đề gửi mail trước khi yêu cầu gỡ bỏ, vì spam trap đã liệt kê bạn sẽ tiếp tục làm điều đó ở tin nhắn tiếp theo.

Tôi có bắt buộc phải nói với nhà cung cấp những gì đã thực sự xảy ra không?

Bạn phải cung cấp đủ thông tin để họ đóng ticket: nguồn gốc là gì và khi nào nó dừng lại. Bạn không cần phải nộp một báo cáo pháp y hay dữ liệu người dùng của mình. Một câu trả lời mơ hồ còn tệ hơn là một câu trả lời ngắn gọn, vì người xử lý không thấy được thay đổi gì sẽ không có lý do để coi vụ việc đã được giải quyết.

Tôi có thể bỏ qua báo cáo tự động từ trình quét không?

Không. Các báo cáo tự động được thống kê, và các báo cáo lặp lại về một IP sẽ làm tăng điểm xấu cho toàn bộ dải địa chỉ của nhà cung cấp, đó là điều biến một vụ việc nhỏ thành một sự leo thang. Câu trả lời của bạn chỉ cần một đoạn văn. Trình báo cáo tự động thường không bao giờ đọc nó, nhưng người xử lý ticket tại nhà cung cấp của bạn thì có, và đó là người quyết định điều gì sẽ xảy ra với instance của bạn.