Git.kernel.org bị AI crawler tấn công: Việc render commit ngốn CPU hơn cả truy cập hợp pháp

Có lẽ bạn đã từng nghe tôi phàn nàn về các "AI crawler" trước đây, nhưng giờ đây tôi thực sự có những con số cụ thể để cho thấy tác động của chúng. Nói ngắn gọn, tình hình tệ đến mức tạo ra một "bức xạ nền" liên tục gây tải cho hệ thống, chiếm dụng vĩnh viễn một phần năng lực xử lý chỉ để tạo ra kết quả phục vụ cho một mục đích duy nhất — cung cấp dữ liệu cho mô hình học máy.

Tóm tắt: chúng tôi tốn nhiều chu kỳ CPU để render các commit cho các trình thu thập dữ liệu (scraper) hơn là cho tất cả các loại truy cập hợp lệ khác cộng lại, bao gồm cả git clone. Tại bất kỳ thời điểm nào, trên 5 node phân tán địa lý, luôn có 14 nhân CPU không làm gì khác ngoài việc render các git commit dưới dạng html.

Tại sao git.kernel.org lại "thú vị" đối với các crawler?

Quá trình phát triển Linux diễn ra công khai — từ các kho lưu trữ git mà bạn có thể clone, cho đến các kho lưu trữ thảo luận mà bạn có thể theo dõi theo thời gian thực. Đối với một mô hình ngôn ngữ lớn (LLM), đây là một mỏ vàng dữ liệu học tập, vì tất cả những nội dung này không chỉ có sẵn ngay lập tức mà còn dễ dàng lọc để đảm bảo là nội dung thuần túy, chưa bị AI can thiệp. Việc huấn luyện một LLM trên nội dung do chính LLM tạo ra sẽ khiến nó mắc phải thứ tương đương với bệnh prion kỹ thuật số, vì vậy khi một nguồn dữ liệu được đảm bảo không chứa nội dung AI, như toàn bộ lịch sử các commit của kernel, thì nó quý giá như vàng đối với dữ liệu huấn luyện.

Cách làm ngu ngốc nhất

Chúng tôi làm cho hầu hết mọi thứ đều có thể clone được, vì này — chúng tôi có thể không tồn tại mãi mãi, nên đây — hãy clone các repo đi. Ngoài ra, hãy clone cả các kho lưu trữ nữa. Hãy lấy một bản sao để chúng tôi không phải là những người duy nhất sở hữu tất cả. Nghiêm túc mà nói, chỉ cần một lệnh "git clone" là bạn sẽ có toàn bộ lịch sử.

Ví dụ, bạn có biết rằng bạn có thể clone toàn bộ LKML và sau đó làm bất cứ điều gì bạn muốn với nó không? Nó chỉ là các git repo nối tiếp nhau mà thôi.

Vì vậy, bạn sẽ nghĩ rằng thứ gì đó tự xưng là "Trí tuệ nhân tạo" sẽ sử dụng cách hiệu quả nhất để tận dụng dữ liệu của chúng tôi cho mục đích huấn luyện, phải không? Clone các repo, duyệt qua từng commit. Xong.

Nhưng không, hãy chọn cách ngu ngốc nhất có thể — bằng cách render mọi thứ dưới dạng HTML cho từng commit một rồi phân tích cú pháp (parse) nó.

Tại thời điểm viết bài, linux.git có khoảng 1,48 triệu commit. Ồ, và chúng tôi có khoảng 922 bản fork của nó trên git.kernel.org — nhưng đừng lo, thực tế thì backend xử lý cực kỳ hiệu quả vì hầu hết các đối tượng trong mỗi bản fork đều giống nhau.

Trừ khi, tất nhiên, bạn là một scraper, trong trường hợp đó bạn có, ồ, vài TỶ URL hợp lệ để scrape, chỉ để nhận về 922 bản sao của cùng 1,48 triệu commit đó — đó chính xác là những gì các scraper đang làm.

Nhưng khoan đã, không chỉ có các commit. Bạn cũng có thể yêu cầu các bản vá (patch), bản render thuần túy, sự khác biệt (diff) giữa các commit bất kỳ — cgit sẵn lòng cho phép bạn làm điều đó, điều này rất hoàn hảo cho những thời điểm Internet dành cho con người hoặc các crawler tuân thủ robots.txt, nhưng lại là THẢM HỌA vào lúc này, vì chúng tôi có thể tạo ra 1,2 TỶ TỶ URL hợp lệ chỉ cho một bản fork duy nhất của linux.git.

Chặn chúng lại

Ban đầu, đây là giải pháp — xem qua nhật ký (log), tìm xem IP nào là bot scraper rõ ràng và dùng fail2ban để chặn chúng. Lúc đầu, việc này rất dễ dàng vì các bot đã giúp đỡ bằng cách tự khai báo danh tính thông qua user-agent. Sau đó, chúng trở nên khôn ngoan hơn và bắt đầu giả dạng thành các trình duyệt thông thường ngẫu nhiên.

Vì vậy, chúng tôi bắt đầu chặn chúng theo IP — xét cho cùng, thật dễ dàng để nhận ra rằng một IP đang cố gắng lấy mọi commit có thể trong một bản fork linux bị bỏ hoang từ 8 năm trước không thực sự là một người dùng Chrome trên Windows nào đó đang điên cuồng nhấp vào mọi liên kết xuất hiện trên màn hình của họ.

Sau đó, các bot bắt đầu lan rộng ra toàn bộ các dải mạng con (subnet), nhưng điều này vẫn chưa ăn thua, vì rõ ràng một IP đến từ Google Compute chỉ đang giả vờ là người dùng Firefox. Việc chặn toàn bộ ASN là hợp lý, ngay cả khi đôi khi nó vô tình chặn nhầm một instance hợp lệ nào đó đang cố gắng tự động kiểm tra liên kết trong các commit.

Bước vào... chiếc TV của bạn?

Và... đó là lúc mọi thứ trở nên thực sự, thực sự tồi tệ. Đột nhiên, các crawler đến từ hàng triệu IP dân cư hoặc di động ngẫu nhiên, tất cả đều giả vờ là các trình duyệt hiện đại. Một IP như vậy sẽ thực hiện 4-5 yêu cầu rồi không bao giờ xuất hiện trong nhật ký nữa. Chẳng có ích gì khi chặn chúng, vì đến khi bạn nhận ra chúng là bot thì chúng đã hoàn thành công việc rồi. Bạn chỉ làm phình to bộ quy tắc tường lửa một cách vô ích bằng cách thêm vào những IP sẽ không bao giờ quay lại.

Chúng tràn đến như một đàn châu chấu, tấn công mạnh mẽ và nhanh chóng cho đến khi hệ thống sụp đổ rồi chuyển sang mục tiêu tiếp theo cho đến khi bạn phục hồi. Sau đó, chúng quay lại. Lặp lại quy trình.

Chúng vẫn làm như vậy — chào mừng bạn đến với thế giới tuyệt vời của "kiếm tiền từ proxy SDK". Đó là một ngành kinh doanh lớn, và có lẽ chiếc TV của bạn cũng đang làm điều đó.

Bắt chúng phải trả giá

Khi vấn đề này lần đầu xuất hiện, ồ, khoảng một năm trước, chúng tôi đã ngây thơ nghĩ rằng có cách để ngăn chặn nó. Chỉ cần bắt các bot thực hiện một tác vụ làm đảo lộn nền kinh tế của toàn bộ quá trình này bằng cách bắt chúng đốt cháy một vài chu kỳ CPU để thực hiện các phép tính vô nghĩa. Ví dụ: tính toán xem chuỗi nào, khi kết hợp với IP của chính chúng và một bí mật mà chúng tôi cung cấp, sẽ tạo ra một tổng sha256 với 4 số 0 ở đầu.

Nói cách khác, chúng tôi đặt Anubis phía trước mọi thứ.

Nó ngay lập tức cực kỳ hiệu quả — các bot chỉ đơn giản là bỏ cuộc. Trong vài tháng, mọi thứ thật êm đềm: các bot bị chặn ở vành đai và bỏ cuộc, chuyển sang các mục tiêu dễ dàng hơn; người dùng hơi khó chịu một chút nhưng vẫn chấp nhận được, và stack Anubis đủ dễ để triển khai ở mọi nơi.

Vài tháng sau, các bot quay trở lại, giải được độ khó 4. Không vấn đề gì, chúng tôi nói, hãy nâng độ khó lên 5.

Người dùng hợp lệ giờ đây khó chịu hơn. Độ khó 5 mất vài giây để giải trên thiết bị di động, và điện thoại trở nên nóng lên một cách khó chịu khi thực hiện các phép tính đó. Tuy nhiên, nó vẫn hiệu quả và mang lại cho chúng tôi thêm vài tháng bình yên.

Sau đó... các bot bắt đầu giải được độ khó 5.

Chúng ta đang ở đâu hiện tại

Ngày nay, git.kernel.org nhận khoảng 6 triệu yêu cầu mỗi ngày đòi xem các commit ngẫu nhiên. Trong số đó, 66% vẫn bị chặn ngay lập tức bởi thử thách Anubis, nhưng 33% hiện đang giải được các phép toán và truy cập được vào trang web chính — bởi vì rõ ràng những gì chúng tôi cung cấp đáng giá để chúng bỏ ra hàng tấn chu kỳ CPU nhằm tính toán thử thách Anubis.

Không thể biết chắc chắn đâu là bot và đâu là người thật — nhưng khả năng cao là, nếu nó yêu cầu một commit cũ trong một bản fork cũ ngẫu nhiên, thì đó có lẽ không phải là một lập trình viên thực thụ đang cố gắng làm việc của họ.

Với một loạt các giả định hào phóng, các yêu cầu hợp lệ chỉ chiếm khoảng 2% lưu lượng truy cập của git.kernel.org — tất cả những thứ còn lại đều là scraper.

Tệ đến mức nào?

Tại thời điểm này, chúng tôi chưa hoàn toàn bị quá tải — nếu bạn truy cập git.kernel.org, nó có khả năng vẫn sẽ nhanh và phản hồi tốt. Thứ thường khiến chúng tôi sập nguồn không phải là các bot scraper, mà là các hệ thống CI được thiết kế kém, cố gắng làm những việc ngu ngốc như shallow-clone stable.git từ 20 node khác nhau cùng một lúc. (Shallow clone rất tệ. Hãy tự chạy mirror của riêng bạn nếu bạn định làm những việc tồi tệ như vậy.)

Tuy nhiên, bạn nên biết rằng trong tổng số 90 nhân trên 5 node phân tán địa lý, có 14-16 nhân liên tục không làm gì khác ngoài việc render các commit cho scraper. Trung bình, đó là 20% toàn bộ năng lực của chúng tôi — ngoại trừ việc các đàn bot tràn đến theo từng đợt và biểu đồ thực tế có nhiều đỉnh nhọn hơn là một đường thẳng 20%.