Internet không còn là nơi trú ẩn an toàn nữa

 (brainbaking.com)
9 điểm bởi GN⁺ 2025-11-17 | 1 bình luận | Chia sẻ qua WhatsApp
  • Đã xảy ra trường hợp máy chủ cá nhân bị sập do bot cào dữ liệu AI gửi yêu cầu quá mức
  • Kết quả phân tích log xác nhận các nỗ lực truy cập tập trung từ dải IP được lưu trữ tại Singapore của Alibaba(US) Technology (47.79.*)
  • Do sử dụng User-Agent giả mạo dạng Mozilla/5.0, các hệ thống phát hiện bot thông thường bị vô hiệu hóa
  • Hệ thống chặn tự động của Fail2ban và Nginx bị quá tải, buộc phải chặn thủ công toàn bộ dải IP
  • Trước các cuộc tấn công lặp đi lặp lại, môi trường tự vận hành máy chủ của các quản trị viên máy chủ cá nhân bị thu hẹp, và họ bị đẩy về các nền tảng tập trung

Nguyên nhân máy chủ bị sập và phản ứng ban đầu

  • Vài ngày trước, máy chủ nhỏ đang lưu trữ trang web đã bị gián đoạn tạm thời do cuộc tấn công từ bot cào dữ liệu
    • Trước đây cũng từng có các cuộc tấn công tương tự, và đang cân nhắc áp dụng công cụ phòng thủ mạnh hơn như Anubis
    • Các cuộc tấn công lặp lại khiến động lực sáng tạo và niềm vui mang tính sở thích của nhà phát triển cá nhân suy giảm
  • Sau khi truy cập máy chủ bị chậm, kiểm tra bằng lệnh top cho thấy Gitea và Fail2ban chiếm gần như toàn bộ CPU
    • Ngay cả khi dừng tiến trình Gitea, tải của Fail2ban vẫn không giảm, và log truy cập Nginx đang tăng vọt

Phân tích log và mẫu tấn công

  • Trong log ghi lại nhiều yêu cầu HTTP 502 nhắm vào đường dẫn /commit/
    • Trong header yêu cầu có User-Agent ngụy trang thành trình duyệt thông thường như Mozilla/5.0 (Macintosh; Intel Mac OS X 10_15_7)
    • Phần lớn công cụ kiểm tra User-Agent nhận diện đây là lưu lượng bình thường nên né được phát hiện
  • IP tấn công không đến từ một nguồn duy nhất mà từ nhiều địa chỉ khác nhau, nhưng đều dùng dải 47.79.*
    • Tra cứu qua ipinfo.io cho thấy dải này thuộc sở hữu của Alibaba(US) Technology Co., Ltd.
    • Trên các diễn đàn như PhpBB cũng đã có báo cáo tấn công từ cùng dải IP này

Biện pháp phòng thủ và giới hạn

  • Fail2ban đã phân tích log Nginx theo thời gian thực để áp dụng quy tắc chặn, nhưng xử lý bị chậm do log bùng nổ
    • Đã chạy script chặn ngay các IP truy cập /commit/, nhưng vẫn có giới hạn về tốc độ
    • Cuối cùng phải dùng lệnh iptables để chặn thủ công toàn bộ dải 47.79.0.0/16
  • Những biện pháp này chỉ là giải pháp tạm thời, và vẫn có khả năng các cuộc tấn công sẽ tiếp tục từ các dải IP mới
    • Đang cân nhắc dùng dịch vụ bảo vệ bên ngoài như Cloudflare hoặc hệ thống phòng thủ nâng cao như Anubis
    • Tuy nhiên, vẫn do dự vì không muốn đi qua máy chủ tại Mỹ có tính năng theo dõi

Khó khăn khi vận hành máy chủ cá nhân

  • Đang cân nhắc chuyển instance Gitea sang Codeberg
    • Các quản trị viên máy chủ cá nhân có xu hướng từ bỏ tự lưu trữ và chuyển sang nền tảng tập trung vì các cuộc tấn công lặp lại
    • Xu hướng này dẫn đến sự suy yếu của tính phân tán và tính tự chủ của Internet
  • Các blogger khác cũng báo cáo bị tấn công tương tự, và vấn đề đang lan rộng thành bài toán chung của các nhà vận hành web quy mô nhỏ

Lưu lượng bất thường khác được quan sát

  • Phát hiện header Referer giả mạo trỏ tới các tên miền doanh nghiệp lớn như bioware.com, mcdonalds.com, microsoft.com
    • Thực tế các trang đó không hề cung cấp liên kết, và hiện tượng tăng lưu lượng này có mục đích không rõ ràng
  • Dù các cuộc tấn công có lặp lại, tác giả vẫn bày tỏ ý chí không từ bỏ tự lưu trữ
    • Ở cuối bài, câu “Get Hostin’ Or Die Tryin’” được dùng để nhấn mạnh quyết tâm tiếp tục tự vận hành máy chủ

Bài viết liên quan

1 bình luận

 
GN⁺ 2025-11-17
Ý kiến trên Hacker News

  • Có cảm giác internet không còn là không gian an toàn cho các lập trình viên phần mềm làm dự án như một thú vui nữa
    Tôi tự vận hành máy chủ từ khoảng năm 2005, và từ khoảnh khắc máy chủ lên mạng là luôn bị tấn công
    Đặc biệt, nếu gán tên DNS hoặc dùng chứng chỉ TLS thì có vẻ các cuộc tấn công còn nặng hơn do bị lộ trong nhật ký minh bạch chứng chỉ
    Khi công khai website thì lưu lượng độc hại tràn tới, và nếu chọc giận một tổ chức nào đó thì có vẻ họ sẽ thuê người để thử DDoS
    Crawler, botnet, tấn công tự động, cả những người đang bực tức nữa — năm nào cũng gặp
    Tôi đã dùng nhiều nhà cung cấp hosting khác nhau nhưng kết quả đều tương tự

    • Ngày trước, cuốn sổ lưu bút PHP sơ sài do tôi tự làm từng biến thành trang spam XSS chỉ sau vài ngày
      Khi không cập nhật WordPress, chỉ vài giờ sau đã bị nhiễm spam SEO, còn khi lỡ để Redis lộ ra ngoài thì bị cài botnet RAT
      Nhưng tôi không nghĩ những chuyện đó có nghĩa là internet “nguy hiểm”
      Ngược lại, đó là những trải nghiệm cho tôi biết mình cần học gì
      Từ đó về sau tôi dùng star-cert để không hiện trong nhật ký chứng chỉ, thêm xác thực cơ bản, duy trì sao lưu và vận hành cẩn thận
      Điều thực sự nguy hiểm là những người không hiểu công nghệ cài bừa file exe nào đó, rồi giao toàn bộ thông tin của mình cho Facebook hay TikTok
    • Tôi cũng đang vận hành một tên miền cá nhân, nhưng dù ngoài tôi ra chẳng ai ghé thăm thì các đợt tấn công bot vẫn không dừng lại
      Phần lớn là các yêu cầu nhắm vào lỗ hổng WordPress, dù tôi chưa từng dùng WordPress
      Lúc mới xem log thì thấy sốc, nhưng giờ tôi coi đó chỉ là chuyện thường ngày
    • Để trêu chọc kẻ tấn công, tôi đã làm một thứ gọi là ‘HTTP Adventure’ và cài ở các địa chỉ quản trị nổi tiếng
      Ví dụ: https://www.masswerk.at/wp-admin
    • Khoảng năm 2008, tôi từng vận hành một website doanh nghiệp có PageRank 6, và từ lúc đó số vụ tấn công của Script Kiddies tăng bùng nổ
      Đó là thời kỳ các công cụ quét dải IP và tự động tìm lỗ hổng lan rộng
      Tôi nhớ thời web giai đoạn 1995~2008, khi còn có Web Rings, Technorati và các fansite
      Tham khảo: wiki Script Kiddie
    • Có lẽ thay vì nói “luôn bị tấn công”, đúng hơn là lưu lượng truy cập trên thực tế đã bị ‘kiếm tiền hóa (monetised)’

  • Trước đây tôi từng dùng zipbomb để chặn bot và thấy có hiệu quả
    Nhưng sau khi đăng chuyện đó lên HN, bot mới kéo tới khiến máy chủ $6 không chịu nổi
    Không thể nào phục vụ 100.000 request mỗi ngày với payload 1~10MB được
    Sau đó tôi chỉ nhắm vào một số bot nhất định, tạo honeypot để thu thập IP rồi trả về 403
    Sau vài tháng, lưu lượng đã trở lại mức bình thường

    • Các kỹ thuật chặn bot kiểu này có vẻ có tiềm năng thương mại
      Chỉ là tôi không rõ khách hàng mục tiêu sẽ là ai. Đa số người tự host không có nhiều tiền

  • Máy chủ cgit của tôi cũng đã bị scraper truy cập liên tục suốt 1 năm nay
    Tuy vậy, chỉ 2~3 request mỗi phút nên là một con bot khá “lịch sự”
    Điều buồn cười là toàn bộ mã tôi đăng lên đều có thể clone trực tiếp từ upstream, vậy mà chúng vẫn cứ cào kiểu này
    Nhìn log thì đúng là tự động hóa cực kỳ kém hiệu quả

  • Nếu tự cấu hình tính năng rate-limiting của Nginx thì có thể xử lý đơn giản hơn Fail2ban
    Blog tham khảo: https://blog.nginx.org/blog/rate-limiting-nginx

  • Khó áp dụng với dịch vụ công khai như blog, nhưng nếu là tự host phục vụ cá nhân thì tôi khuyên nên cấu hình xác thực mTLS ở reverse proxy
    Các request không có chứng chỉ sẽ bị chặn ngay, và chỉ thiết bị của tôi mới truy cập được
    Thiết lập một lần rồi sau đó gần như không phải bận tâm nữa

    • Tuy vậy tôi nghĩ Wireguard còn tốt hơn
      Cấu hình đơn giản và hoạt động tốt trên Android, iOS
      Hiện tại tôi đã thiết lập để mọi dịch vụ tự host chỉ có thể truy cập trong VPN Wireguard, còn firewall chỉ mở cổng của Wireguard
    • Nhưng với các dịch vụ mà người khác cũng cần truy cập như blog thì mTLS là không thực tế

  • Anubis đang chơi khá tốt trò “mèo vờn chuột” với bot
    Nhưng chỉ những nơi như Cloudflare, có dữ liệu lưu lượng ở quy mô lớn, mới chặn tốt dựa trên uy tín IP
    Các nhà vận hành nhỏ buộc phải chặn cả dải IP, điều này rất kém hiệu quả
    Cần một giải pháp như Crowdsec để chia sẻ dữ liệu uy tín, chặn IP độc hại và cung cấp thử thách đơn giản không cần JS
    Nếu làm được theo hướng này thì có lẽ các lập trình viên làm dự án như thú vui cũng sẽ dễ vận hành dịch vụ trở lại

  • Instance Gitea của tôi gần đây cũng bị scrape thông qua các IP và ASN phân tán
    Nếu là các công ty AI nhiều tiền thì có lẽ ngay cả Anubis cũng khó chặn
    Vì vậy tôi đang cân nhắc “đầu độc scraper (poisoning)” — tức là trả về dữ liệu rác thay vì mã nguồn

    • Dạo này còn xuất hiện cả các dịch vụ proxy tự nhận là dùng IP “được cung ứng có đạo đức (residential)”
      Những dịch vụ như vậy khiến việc chống scraping càng khó hơn

  • Những gì trở nên phổ biến cuối cùng cũng sẽ rơi vào tay đám đông rồi bị làm hỏng trong một vòng lặp
    Vì thế cảm giác như cách giải duy nhất là liên tục chuyển sang những vùng đất mới

  • Sau khi chuyển DNS sang Cloudflare, các gói SYN lạ cứ liên tục đổ tới
    Cứ mỗi giây lại có request vào cổng 443 hoặc 22, nhưng sau SYN-ACK thì không có phản hồi
    Có vẻ phần lớn đến từ các nhà cung cấp VPS/hosting máy chủ game ở Brazil và những nơi tương tự
    Vì vậy tôi chụp bắt các gói SYN, tra RDAP rồi chặn toàn bộ subnet của tổ chức đó
    Hiện tôi chỉ giữ Google trong whitelist
    Digital Ocean có vẻ là một trong những nguồn lưu lượng độc hại lớn

    • Đây là một dạng tấn công phản xạ SYNACK
      Ngăn xếp mạng sẽ retry, khiến lưu lượng được khuếch đại rồi chuyển tới nạn nhân
    • Có lẽ đây là các cuộc tấn công liên quan đến game như DDoS máy chủ Minecraft
      Vì thường có giả mạo src IP, nên khuyên nên đặt rp_filter ở strict 
      net.ipv4.conf.all.rp_filter = 1
net.ipv4.conf.default.rp_filter = 1
    • Nhưng việc ISP kiểm duyệt hành vi của người dùng là nguy hiểm
      Cũng như công ty điện lực không cấm dùng bóng đèn đỏ, việc nhà cung cấp dịch vụ kiểm soát lưu lượng là điều không đáng mong muốn

  • Lý do tôi đồng cảm với bài viết này không phải vì internet an toàn, mà vì nó đã ghi chép lại thực tế này
    Tôi cũng đang chặn Alibaba /16 và toàn bộ dải AWS

    • Thay vì tự chặn từng dải IP, chặn theo đơn vị ASN sẽ hiệu quả hơn
      Tôi dùng một script chạy cron hằng ngày để lấy dữ liệu RouteViews và áp vào iptables
      Mã ví dụ: 
      iptables -A BAD_AS -s $ROUTE -j DROP;
    • Tham khảo thêm, từ năm 2014 AWS đã công khai dải IP ở dạng JSON
      Mong là các cloud khác cũng cung cấp theo cách này