Dấu vân tay TCP làm lộ trình thu thập dữ liệu của bạn như thế nào

Tại sao ngay cả một trình duyệt chống phát hiện hoàn hảo vẫn là chưa đủ

Để hiểu quy mô thực sự của vấn đề, trước tiên chúng ta hãy nhớ lại cách thiết lập chống chặn tiêu chuẩn hoạt động như thế nào.

Lịch sử cho thấy, việc thu thập dữ liệu (scraping) đã phát triển thành một cuộc chạy đua vũ trang ở cấp độ HTTP và JavaScript. Khi các máy chủ bắt đầu chặn các tiêu đề mặc định như python-requests, các nhà phát triển bắt đầu sử dụng chuỗi User-Agent từ các trình duyệt thực. Khi các hệ thống chống gian lận bắt đầu kiểm tra các thuộc tính bộ điều hướng, chúng tôi đã chuyển sang các trình duyệt không đầu (headless browser) được sửa đổi thông qua Giao thức Chrome DevTools (CDP) hoặc các giải pháp trình duyệt chống phát hiện có sẵn.

Chúng tôi đã quen với việc kiểm soát tầng ứng dụng (Tầng 7). Đây là tầng mà HTTP hoạt động, cookie và tiêu đề được truyền đi, và JavaScript thực thi.

Vấn đề là một yêu cầu HTTP không tự gửi đi. Nó được đóng gói bên trong một giao thức vận chuyển (TCP—Tầng 4), sau đó lại được đóng gói bên trong một giao thức mạng (IP—Tầng 3). Đây là nơi cạm bẫy kiến trúc chính ẩn nấp:

• L7 (tầng ứng dụng) được kiểm soát hoàn toàn bởi ứng dụng của bạn—kịch bản (script) của bạn, Puppeteer, hoặc trình duyệt chống phát hiện.

• L3 và L4 (tầng mạng và vận chuyển) được kiểm soát bởi nhân hệ điều hành nơi mã chạy vật lý (hoặc nơi lưu lượng được định tuyến qua). Một lệnh gọi socket connect() chỉ đơn giản là chuyển giao quyền kiểm soát cho ngăn xếp mạng của Linux hoặc Windows, và từ thời điểm đó, hệ điều hành sẽ xây dựng các gói tin theo các quy tắc nội bộ, được mã hóa cứng của riêng nó.

Các hệ thống chống gian lận hiện đại biết điều này và sử dụng các kỹ thuật lấy dấu vân tay thụ động để phân tích chính xác cách kết nối TCP được thiết lập trước khi yêu cầu HTTP đầu tiên được gửi đi.

Nếu User-Agent của bạn ở L7 tuyên bố là Chrome trên Windows, nhưng máy chủ nhìn thấy cấu trúc gói TCP SYN đặc trưng của Linux ở L4, hệ thống chống gian lận sẽ coi đây là một sự bất thường rõ ràng. Từ góc độ máy chủ, một máy Windows thực tế không thể tạo ra gói mạng như vậy. Do đó, đó là một bot đang chạy trên máy chủ Linux nhưng lại giả vờ là một người dùng bình thường. Hệ thống chống gian lận sau đó sẽ hoạt động theo chính sách của riêng nó: Ví dụ, Google Maps có thể trả về một trang web đơn giản hóa, yêu cầu xác thực và bắt bạn giải CAPTCHA.

Giải phẫu gói TCP SYN: cách máy chủ xác định hệ điều hành thực của bạn

Mọi kết nối HTTP(S) đều bắt đầu bằng việc thiết lập kết nối TCP—cái gọi là cái bắt tay ba bước (three-way handshake). Gói tin đầu tiên được gửi đến tài nguyên đích là một gói mạng có cờ SYN được thiết lập. Gói tin nhỏ bé này chứa mọi thứ cần thiết để lấy dấu vân tay hệ điều hành thụ động. Các hệ thống bảo mật thậm chí không cần đợi tiêu đề HTTP của bạn. Họ kiểm tra các trường dịch vụ bên trong gói SYN và xác định với độ chính xác đáng kinh ngạc xem nhân hệ điều hành nào đã tạo ra nó.

Có ba dấu hiệu chính:

1. Time To Live (TTL)

TTL là bộ đếm giảm đi một đơn vị mỗi khi gói tin đi qua một bộ định tuyến trên đường đến máy chủ. Các hệ điều hành khác nhau sử dụng các giá trị khởi đầu mặc định khác nhau:

• Linux và macOS: TTL mặc định là 64.

• Windows: TTL mặc định là 128.

Nếu hệ thống chống gian lận của Google nhận được một gói tin có TTL là 54, nó có thể tự tin kết luận rằng nguồn là Linux hoặc macOS. Nếu nhận được giá trị 115, rất có thể đó là Windows.

2. TCP Window Size

Về cơ bản đây là kích thước của bộ đệm nhận. Nó cho biết lượng dữ liệu mà một thiết bị sẵn sàng chấp nhận cùng một lúc.

Vì dữ liệu được truyền đi dưới dạng các phân đoạn khoảng 1.460 byte, các hệ điều hành thường phân bổ bộ nhớ theo bội số của kích thước đó. Tuy nhiên, mỗi hệ điều hành lại thực hiện khác nhau.

Linux thường phân bổ cửa sổ ban đầu dựa trên một số lượng gói tin cố định:

• 5840 = 4 gói × 1460

• 14600 = 10 gói × 1460

• 29200 = 20 gói × 1460

Khi các hệ thống chống gian lận nhìn thấy 29200, họ nhận ra một mô hình điển hình của nhân Linux.

Windows có xu hướng lúy thừa của hai hoặc các giá trị tối đa:

• 8192 = 8 KB

• 65535 = giá trị tối đa khớp vào trường kích thước Cửa sổ 16-bit

• 64240 = một cách tiếp cận kết hợp được sử dụng bởi các phiên bản Windows hiện đại (44 gói × 1460)

Các hệ thống chống gian lận so sánh các giá trị này với User-Agent của bạn. Nếu bạn tuyên bố là Chrome trên Windows nhưng kích thước cửa sổ của bạn là 29200, sự không khớp là quá rõ ràng.

3. Thứ tự các tùy chọn TCP (TCP Options order)

Đây là cơ chế lấy dấu vân tay mạnh mẽ nhất.

Các gói SYN bao gồm các tham số bổ sung như MSS, Window Scaling, SACK Permitted, Timestamps, v.v. Bản thân các giá trị có thể thay đổi, nhưng thứ tự xuất hiện của chúng được mã hóa cứng vào nhân hệ điều hành.

Ví dụ:

• Vân tay điển hình của Windows:

MSS → NOP → Window Scaling → NOP → NOP → SACK Permitted

• Vân tay điển hình của Linux:

MSS → SACK Permitted → Timestamps → NOP → Window Scaling

Những chi tiết này có vẻ không quan trọng, nhưng bất kỳ hệ thống chống gian lận tiên tiến nào cũng sẽ xác định được những điểm không nhất quán này, hạn chế các phiên làm việc và ngăn chặn việc thu thập dữ liệu ổn định.

Bẫy proxy trung tâm dữ liệu: tại sao hệ điều hành cục bộ của bạn không còn quan trọng nữa

Nếu lấy dấu vân tay TCP/IP là vấn đề, một giải pháp hợp lý có vẻ là chạy trình thu thập dữ liệu trên một máy chủ Windows Server.

Giả sử bạn khởi chạy trình thu thập dữ liệu của mình trên một máy Windows sạch. Hệ điều hành tạo ra các gói TCP SYN có TTL=128, kích thước cửa sổ phù hợp và thứ tự tùy chọn chính xác. Tuy nhiên, CAPTCHA và các gián đoạn phiên làm việc vẫn xuất hiện. Lý do nằm ở cách hoạt động của các máy chủ proxy.

Các hoạt động thu thập dữ liệu nghiêm túc hầu như luôn dựa vào proxy. Trong hầu hết các thiết lập tự động hóa, proxy trung tâm dữ liệu được sử dụng vì chúng rẻ, nhanh và ổn định. Điều đáng nói là phần lớn các máy chủ proxy này chạy các bản phân phối Linux như Ubuntu, Debian hoặc CentOS.

Khi bạn sử dụng một proxy, không có kết nối mạng trực tiếp nào giữa thiết bị của bạn và máy chủ của Google. Quá trình này được chia thành hai kết nối độc lập:

1. Kết nối A (Máy tính của bạn → Máy chủ proxy)

Máy Windows của bạn thiết lập kết nối TCP đến proxy.

2. Kết nối B (Máy chủ proxy → Google)

Sau khi nhận được yêu cầu của bạn, proxy sẽ tạo một kết nối TCP hoàn toàn mới đến máy chủ đích thay cho bạn.

Vì máy chủ proxy chạy Linux, ngăn xếp mạng Linux sẽ tạo ra gói SYN được gửi đến Google.

Do đó, hệ thống chống gian lận của Google nhìn thấy một kết nối TCP rõ ràng được tạo ra bởi Linux (TTL 64, kích thước cửa sổ kiểu Linux, thứ tự tùy chọn TCP của Linux). Tuy nhiên, bên trong kết nối đó (cấp độ L7), nó lại thấy các tiêu đề HTTP tuyên bố là Chrome trên Windows.

Proxy trung tâm dữ liệu làm lộ dấu vân tay lớp vận chuyển cục bộ của bạn. Ngay cả khi bạn vận hành một hệ thống lớn gồm các máy Windows thực đắt tiền, việc định tuyến lưu lượng qua các proxy trung tâm dữ liệu chuẩn chạy Linux sẽ khiến tất cả lưu lượng của bạn hiển thị là Linux đối với máy chủ đích.

Đây là một trong những lý do tại sao proxy dân cư là lựa chọn tốt hơn cho việc thu thập dữ liệu.

Cách kiểm tra vân tay của bạn

Luôn kiểm tra các kịch bản của bạn trong điều kiện thực tế. Hãy thử đánh giá trình thu thập dữ liệu của bạn từ góc độ của hệ thống chống gian lận.

Định tuyến lưu lượng của trình thu thập dữ liệu qua BrowserLeaks và cuộn xuống phần TCP/IP Fingerprint. Nếu cấu hình Puppeteer của bạn sử dụng một User-Agent Windows nhưng dịch vụ báo cáo OS Fingerprint: Linux/Android, bạn đang đối mặt với chính xác sự không khớp được thảo luận trong bài viết này.

Các giải pháp khả thi: làm thế nào để ngụy trang Linux

Vậy làm thế nào để trình thu thập dữ liệu của bạn vượt qua được các hệ thống bảo vệ chống gian lận nghiêm ngặt?

Tùy chọn 1. Thay đổi loại proxy

Vì các proxy trung tâm dữ liệu có thể làm hỏng dấu vân tay của bạn bởi nhân Linux của chúng, giải pháp đáng tin cậy nhất là dừng sử dụng chúng và chuyển sang proxy dân cư.

Proxy dân cư định tuyến lưu lượng qua các thiết bị của phân khúc người dùng thực (PC chạy Windows hoặc macOS tại nhà, bộ định tuyến gia đình). Điểm cuối thiết lập kết nối TCP với máy chủ của Google không còn là máy chủ Linux trong trung tâm dữ liệu mà là máy tính thực.

Khi lưu lượng đi qua các thiết bị này, máy chủ đích sẽ nhìn thấy một dấu vân tay TCP hợp pháp từ thiết bị của người dùng thực, khớp hoàn hảo với dấu vân tay L7 của bạn. Vấn đề không khớp sẽ tự động biến mất.

Nếu bạn mua proxy di động (hoạt động qua một mạng lưới các điện thoại thông minh 4G thực), điểm cuối sẽ là thiết bị Android hoặc iOS. Android dựa trên nhân Linux. Nếu bạn chạy một trình thu thập dữ liệu máy tính để bàn với User-Agent Windows 11 qua proxy di động, hệ thống chống gian lận sẽ nhận được gói tin từ Android và phát hiện ra sự không nhất quán.

Loại hồ sơ L7 của bạn trong trình duyệt chống phát hiện phải khớp nghiêm ngặt với loại điểm cuối proxy. Với proxy di động, hãy bật giả lập Chrome di động. Với proxy dân cư, hãy tìm kiếm các nhóm cung cấp IP Windows cho máy tính để bàn.

Tùy chọn 2. Tinh chỉnh nhân Linux

Nếu bạn chạy các kịch bản trực tiếp từ máy chủ Linux không qua proxy (hoặc vận hành proxy riêng mà bạn có quyền kiểm soát hoàn toàn), bạn sẽ cần ngụy trang ngăn xếp mạng của hệ điều hành.

Cấp độ 1. Điều chỉnh cơ bản (TTL)

Bạn có thể thay đổi TTL mặc định để khớp với Windows bằng một lệnh iptables duy nhất. Nhân hệ điều hành sẽ ghi đè giá trị TTL của gói tin ngay trước khi truyền đi:

iptables -t mangle -A POSTROUTING -j TTL --ttl-set 128

Cấp độ 2. Sửa đổi sâu (Kích thước cửa sổ và tùy chọn TCP)

Việc giả mạo kích thước cửa sổ ban đầu và thứ tự tùy chọn TCP khó hơn nhiều. Các thiết lập sysctl cơ bản là không đủ vì cấu trúc gói tin được mã hóa cứng vào mã nguồn nhân Linux.

Để ngụy trang Linux thành Windows ở cấp độ Các tùy chọn TCP (TCP Options), bạn có thể sử dụng cơ chế NFQueue. Đây là cách nó hoạt động:

1. Các gói tin đi ra bị nhân hệ điều hành chặn lại và chuyển tiếp đến không gian người dùng.

2. Một công cụ đặc biệt (được viết bằng C hoặc Python bằng thư viện Scapy) sẽ chụp lại chúng.

3. Chương trình phân tích tiêu đề TCP, thay đổi kích thước cửa sổ thành 65535 hoặc 64240, sắp xếp lại các tùy chọn (MSS, NOP, Window Scale, v.v.) theo thứ tự mong muốn, tính toán lại checksum, và trả gói tin về nhân để truyền đi.

Có các công cụ có sẵn (như p0f-obfuscator và các mô-đun từ các dự án tránh DPI) có thể thực hiện những sửa đổi này một cách nhanh chóng. Việc thiết lập rất phức tạp và có thể làm giảm hiệu suất mạng, nhưng nó làm cho máy chủ Linux của bạn trở nên vô hình trước các kỹ thuật lấy dấu vân tay thụ động.

Tùy chọn 3. Di chuyển sang cơ sở hạ tầng Windows

Cách tiếp cận đơn giản nhất hoàn toàn không phải là ẩn Linux, mà là chạy toàn bộ cơ sở hạ tầng thu thập dữ liệu của bạn trên Windows Server.

Bạn có thể chuyển mã của mình sang máy Windows và gửi lưu lượng trực tiếp. Trong trường hợp này, ngăn xếp mạng gốc của Microsoft tự tạo ra các gói tin tự nhiên với:

• TTL 128,

• kích thước cửa sổ thích hợp,

• và thứ tự tùy chọn TCP Windows chuẩn tắc.

Tuy nhiên, cách tiếp cận này có những hạn chế:

Chi phí. Các máy chủ Windows luôn có giá thuê đắt hơn.

Tiêu thụ tài nguyên. Bản thân hệ điều hành đòi hỏi một lượng RAM và tài nguyên CPU đáng kể cho các tiến trình chạy ngầm.

Khả năng mở rộng. Việc triển khai, cập nhật và mở rộng quy mô một hệ thống các trình thu thập thông tin trên Windows khó khăn hơn nhiều so với việc khởi chạy hàng chục container Docker nhẹ trên Ubuntu.

Kết luận

Việc chỉ giả mạo User-Agent, Canvas, WebGL, và navigator.platform không còn đủ để đảm bảo thành công, đặc biệt là khi đối phó với các nền tảng được bảo vệ nghiêm ngặt như Google, Cloudflare, Akamai hoặc DataDome. Các hệ thống chống gian lận hiện đại đã học cách phân tích không chỉ dữ liệu bạn gửi là gì, mà còn cách bạn phân phối nó ở cấp độ mạng cơ bản như thế nào.

Nếu bạn đang gặp sự cố khi thu thập dữ liệu và không thể xác định nguyên nhân, đã đến lúc xem xét tính nhất quán của tất cả các tầng trong mô hình OSI. Nếu tầng ứng dụng của bạn không khớp về mặt logic hoặc toán học với tầng vận chuyển và tầng mạng (L3/L4), vấn đề có thể nằm ở đó.

Nếu thiết lập được cấu hình cẩn thận của bạn—với trình duyệt chống phát hiện chất lượng cao và các proxy đắt tiền—bắt đầu nhận được các lỗi 403 không rõ nguyên nhân, phân phát phiên bản trang tối giản hoặc kích hoạt CAPTCHA, hãy dừng việc thay đổi liên tục dấu vân tay JavaScript. Hãy thử nhìn sâu hơn một tầng.