Nhà phát triển của bạn thêm dải VPN văn phòng vào danh sách cho phép của nhà cung cấp SaaS vào thứ Sáu. Vào thứ Hai, một trợ lý khởi động lại bộ định tuyến văn phòng trong khi sửa máy in, địa chỉ công cộng thay đổi, và nhóm mất quyền truy cập vào bảng điều khiển quản trị. Quy tắc tường lửa không bị lỗi. Giả định rằng một địa chỉ mạng sẽ giữ nguyên đã sai.
Danh sách trắng IP vẫn hữu ích để hạn chế các cổng quản trị, API, máy chủ, relay mail và tích hợp đối tác. Nó cũng trở nên mong manh khi có sự tham gia của cloud egress, mạng di động, proxy ngược và cập nhật từ nhà cung cấp SaaS. Thách thức thực tiễn không chỉ là cách cho phép một địa chỉ. Đó là quyết định địa chỉ nào đại diện cho một nguồn đáng tin cậy, nơi nào để thực thi quy tắc và cách giữ cho quyền truy cập hoạt động khi nguồn đó thay đổi.
Ý nghĩa thực sự của việc danh sách trắng địa chỉ IP
Danh sách trắng IP là một danh sách kiểm soát truy cập rõ ràng. Một dịch vụ được bảo vệ chấp nhận kết nối từ các địa chỉ hoặc dải nguồn đã được phê duyệt và từ chối các nguồn khác theo mặc định. Danh sách đen áp dụng cách tiếp cận ngược lại, cho phép truy cập chung trong khi từ chối các địa chỉ liên quan đến hoạt động không mong muốn. Danh sách trắng mặc định từ chối thu hẹp con đường truy cập cho các dịch vụ nhạy cảm, nhưng người dùng hợp pháp có thể bị khóa khi điều kiện mạng của họ thay đổi.
Cụm từ danh sách trắng địa chỉ IP thường đề cập đến một chính sách áp dụng cho một địa chỉ nguồn công cộng, subnet riêng tư hoặc dải CIDR. CIDR, hay Lập tuyến giữa các miền không phân lớp, diễn đạt phạm vi đó mà không cần quy tắc riêng cho mỗi máy chủ. RFC 4632 từ IETF mô tả CIDR như một cách để bảo tồn không gian IPv4 32-bit hiện có và hạn chế sự phát triển trong các bảng định tuyến toàn cầu.
Bốn lớp thực thi
Danh sách cho phép sản xuất có thể được thực thi tại một số điểm:
- Tường lửa máy chủ: Linux hoặc Windows lọc lưu lượng truy cập đến một máy.
- Tường lửa mạng: Một nhóm bảo mật đám mây, tường lửa subnet, hoặc thiết bị biên lọc lưu lượng trước khi nó đến máy chủ.
- Lớp ứng dụng: Một proxy ngược, máy chủ web, cổng API, hoặc ứng dụng đánh giá địa chỉ nguồn rõ ràng.
- Bảng điều khiển nhà cung cấp SaaS: Một dịch vụ được lưu trữ áp dụng chính sách mạng của riêng nó trước khi cấp quyền truy cập.
Các lớp này duy trì các quy tắc riêng biệt. Một nhóm bảo mật đám mây có thể cho phép một địa chỉ mà máy chủ web từ chối, trong khi một bảng điều khiển SaaS có thể từ chối lưu lượng đã vượt qua mọi tường lửa nội bộ. Tải công việc đám mây thường rời khỏi qua các địa chỉ egress chia sẻ hoặc thay đổi, các nhà cung cấp SaaS có thể yêu cầu cập nhật danh sách cho phép của riêng họ, và các nhà mạng di động có thể gán các địa chỉ công cộng luân phiên. Do đó, một quy tắc tĩnh cần một chủ sở hữu, một quy trình cập nhật và một con đường dự phòng.
Định tuyến proxy thêm một kiểm tra khác. Xác nhận xem điểm thực thi có thấy nguồn gốc mạng hay địa chỉ khách hàng được chuyển tiếp hay không, và xem xét hướng dẫn này về giả mạo địa chỉ IP trước khi tin tưởng vào các tiêu đề do proxy cung cấp.
Quy tắc thực tiễn: Danh sách trắng dải nhỏ nhất có thể hoạt động. Tài liệu nơi mỗi mục tồn tại, ai sở hữu nó, lý do tồn tại và cách thu hồi nó.
Giữ một con đường quản trị ngoài băng, chẳng hạn như một kênh quản lý riêng hoặc quyền truy cập vào bảng điều khiển, để một địa chỉ egress thay đổi không biến một sự kiện mạng thông thường thành một sự cố. Một danh sách cho phép kiểm soát khả năng tiếp cận mạng. Nó không thay thế xác thực, kiểm tra thiết bị, ghi nhật ký, hoặc quản lý thay đổi.
Đọc ký hiệu CIDR mà không mắc lỗi
Một tiền tố bị gõ sai có thể mở ra toàn bộ mạng hoặc chặn một tải công việc đám mây hợp pháp. Ký hiệu CIDR làm rõ phạm vi: một địa chỉ cơ sở, một dấu gạch chéo, và một độ dài tiền tố. Độ dài tiền tố cho biết bao nhiêu bit đầu tiên xác định mạng. Các quản trị viên cũng có thể diễn đạt cùng một ranh giới bằng một mặt nạ mạng thập phân dấu chấm, nhưng ký hiệu gạch chéo phổ biến hơn trong các quy tắc tường lửa, bảng điều khiển đám mây và tài liệu của nhà cung cấp.
Ba ví dụ về IPv4
203.0.113.7/32 xác định một máy chủ IPv4. Mỗi bit địa chỉ thuộc về phần mạng, làm cho /32 trở thành mục danh sách trắng IPv4 hẹp nhất. Sử dụng nó cho một quản trị viên, cổng, hoặc địa chỉ egress ổn định.
203.0.113.0/24 chứa 256 địa chỉ tổng cộng và 254 máy chủ có thể sử dụng. Dải đó có thể phù hợp với một văn phòng, VPN, hoặc subnet đám mây được kiểm soát, nhưng nó vẫn có thể bao gồm các hệ thống không liên quan đến dịch vụ đang được bảo vệ.
203.0.0.0/16 chứa 65,536 địa chỉ tổng cộng và 65,534 máy chủ có thể sử dụng. Một tiền tố như vậy có thể đại diện cho một phân bổ được quản lý có chủ đích, nhưng một lỗi ở đây sẽ phơi bày một tập hợp nguồn rộng hơn nhiều. Một /8 bao phủ 16,777,216 địa chỉ, so với 256 cho một /24. Phê duyệt các tiền tố rộng một cách có chủ đích, và xác minh dải kết quả trước khi lưu quy tắc.
| Tiền tố | Địa chỉ | Sử dụng điển hình |
|---|---|---|
/32 |
Một máy chủ IPv4 | Một quản trị viên hoặc cổng cố định duy nhất |
/24 |
256 tổng cộng, 254 máy chủ có thể sử dụng | Một subnet hoặc dải văn phòng được kiểm soát |
/16 |
65,536 tổng cộng, 65,534 máy chủ có thể sử dụng | Một phân bổ lớn được quản lý |
IPv6 sử dụng cùng một nguyên tắc. Một máy chủ cá nhân thường được viết là /128, trong khi một mạng được ủy quyền có thể sử dụng /64. IPv4 và IPv6 yêu cầu các mục chính sách riêng biệt và các bài kiểm tra riêng biệt.
Các lỗi gây ra sự cố
- Nhầm lẫn
/0: Điều này khớp với toàn bộ không gian địa chỉ IPv4 và làm thất bại một hạn chế nguồn hẹp. - Căn chỉnh cơ sở sai: Địa chỉ cơ sở phải nằm trên ranh giới mạng được xác định bởi tiền tố. Kết hợp một địa chỉ máy chủ với một tiền tố rộng có thể tạo ra một dải khác với dải dự định.
- Các gia đình địa chỉ hỗn hợp: Một quy tắc IPv4 không lọc lưu lượng IPv6. Nếu cả hai giao thức đều hoạt động, hãy tạo các chính sách tương đương và kiểm tra từng con đường.
- Giả định egress động: Một
/32chỉ hoạt động khi địa chỉ vẫn ổn định. Các thay đổi NAT đám mây, danh sách cho phép SaaS, và các gán của nhà mạng di động có thể làm vô hiệu hóa nó. Một dải được giới hạn có chủ đích có thể sống sót qua việc luân chuyển, nhưng nó cũng cấp quyền truy cập cho nhiều nguồn hơn.
Chọn tiền tố nhỏ nhất hỗ trợ sự kiện DHCP, egress đám mây, hoặc sự kiện đánh số lại của nhà mạng. Sau đó kiểm tra cả một địa chỉ nên vượt qua và một địa chỉ nên thất bại.
Danh sách trắng trên tường lửa Linux và Windows
Tường lửa máy chủ là hàng phòng thủ cuối cùng, không phải là nơi đầu tiên để giải quyết mọi vấn đề truy cập. Áp dụng các hạn chế cấp mạng khi có thể, sau đó sử dụng tường lửa máy chủ để giới hạn sự tiếp xúc nếu một dịch vụ có thể truy cập thông qua một giao diện hoặc con đường định tuyến khác.
Lựa chọn Linux
Đối với một máy chủ cũ hoặc một quy tắc cần kiểm tra trực tiếp ở cấp kernel, iptables vẫn quen thuộc:
sudo iptables -A INPUT -s 203.0.113.0/24 -j ACCEPT
Lệnh đó chấp nhận lưu lượng từ dải đã chỉ định, nhưng nó không tạo ra một chính sách mặc định từ chối hoàn chỉnh tự nó. Đặt một quy tắc từ chối hoặc bỏ sau các quy tắc cho phép cần thiết, và kiểm tra thứ tự quy tắc trước khi thực hiện thay đổi vĩnh viễn.
Đối với các triển khai mới hơn, nftables là khung lọc gói hiện đại và hỗ trợ các tập hợp để quản lý nhiều địa chỉ một cách hiệu quả. Một tập hợp dễ cập nhật hơn một chuỗi dài các quy tắc riêng lẻ, đặc biệt khi một nhà cung cấp công bố các dải thay đổi.
Các quản trị viên Ubuntu thường chọn ufw, một lớp bọc thân thiện hơn:
sudo ufw allow from 203.0.113.0/24 to any port 22 proto tcp
Sử dụng ufw khi nhóm muốn các lệnh dễ đọc và chính sách dịch vụ không phức tạp. Các hồ sơ ứng dụng của nó có thể đơn giản hóa các định nghĩa dịch vụ phổ biến, nhưng hãy xem xét các quy tắc được tạo ra thay vì giả định rằng một hồ sơ phù hợp với sự tiếp xúc mà bạn dự định.
Giữ quy tắc sống sót sau khi khởi động lại
Một quy tắc thời gian chạy biến mất sau khi khởi động lại tạo ra cảm giác bảo vệ sai. Lưu cấu hình tường lửa bằng cơ chế bền vững phù hợp với phân phối, hoặc quản lý nó thông qua tự động hóa cấu hình để quy tắc, chủ sở hữu và ngày xem xét vẫn là một phần của trạng thái đã khai báo của hệ thống.
Đối với một máy chủ quản lý cố định duy nhất, hãy ưu tiên sử dụng /32. Chỉ sử dụng một subnet khi quản trị viên mạng có thể giải thích lý do tại sao mọi địa chỉ trong subnet đó nên truy cập vào dịch vụ. Nguyên tắc tương tự cũng áp dụng cho SSH, cổng cơ sở dữ liệu, bảng điều khiển nội bộ và điểm cuối triển khai.
Các quản trị viên Windows có thể sử dụng bảng điều khiển tường lửa đồ họa hoặc PowerShell:
New-NetFirewallRule -DisplayName "Office SSH" -Direction Inbound -RemoteAddress 203.0.113.0/24 -Action Allow -Protocol TCP -LocalPort 22
Giữ quy tắc gắn liền với một mục đích, không phải một nhãn không chính thức như “truy cập tạm thời.” Nếu quy trình làm việc của bạn phụ thuộc vào một cổng proxy, hãy tài liệu hóa hành vi ra ngoài của cổng và xem xét các nguyên tắc cấu hình máy chủ proxy trước khi thêm các dải nguồn.
Kiểm tra từ một máy chủ bên ngoài mà nên được cho phép và một máy chủ khác mà nên bị từ chối. Kiểm tra SSH từ localhost chỉ chứng minh rằng máy có thể truy cập vào chính nó. Nó không nói gì về đường dẫn, địa chỉ nguồn, hoặc thứ tự quy tắc mà một khách hàng bên ngoài thấy.
Cho phép IP trong AWS, Azure và GCP
Việc cho phép trong đám mây theo một mẫu lặp lại. Xác định đối tượng ranh giới chính xác, thêm một quy tắc vào trong hẹp cho địa chỉ nguồn hoặc CIDR, duy trì tư thế từ chối theo mặc định, sau đó xác thực từ đường dẫn mạng. Phần khó khăn thường là chọn đối tượng chính xác, không phải viết quy tắc.
Tìm ranh giới trước khi chỉnh sửa nó
Trong AWS, sử dụng nhóm bảo mật cho một phiên bản hoặc bộ cân bằng tải. Một ACL mạng áp dụng ở cấp độ subnet và sử dụng các quy tắc không trạng thái, trong khi một tập hợp IP WAF AWS xử lý lọc lớp 7 cho lưu lượng web tại các bề mặt biên và cân bằng tải được hỗ trợ.
Azure sử dụng các nhóm bảo mật mạng cho lưu lượng VM và subnet. Các hạn chế tầng web cũng có thể tồn tại trong một chính sách WAF biên hoặc một hạn chế truy cập Dịch vụ Ứng dụng, tùy thuộc vào nơi ứng dụng nhận lưu lượng.
GCP sử dụng các quy tắc tường lửa VPC cho lưu lượng vào, thường được thu hẹp với các thẻ mục tiêu. Lưu lượng bộ cân bằng tải HTTP(S) có thể nhận một chính sách tầng web bổ sung thông qua một dịch vụ bảo mật biên.
| Nhà cung cấp | Quy tắc cấp mạng | Danh sách cho phép tầng web | Sai lầm phổ biến |
|---|---|---|---|
| AWS | Các nhóm bảo mật hoặc ACL mạng | Tập hợp IP WAF | Chỉnh sửa nhóm sai gắn với giao diện sai |
| Azure | Các nhóm bảo mật mạng | Hạn chế WAF biên hoặc Dịch vụ Ứng dụng | Hạn chế VM trong khi ứng dụng được công khai ở nơi khác |
| GCP | Các quy tắc tường lửa VPC vào và thẻ mục tiêu | Chính sách biên cho các bộ cân bằng tải HTTP(S) | Tạo một quy tắc không nhắm đến khối lượng công việc phục vụ |
Xác thực đường đi thực tế
Ghi lại địa chỉ nguồn hiển thị tại điểm thực thi. Một yêu cầu từ máy tính xách tay của nhà phát triển có thể xuất hiện như một cổng VPN, cổng NAT, đầu ra proxy, hoặc nhảy bộ cân bằng tải thay vì địa chỉ cục bộ của máy tính xách tay. Cho phép địa chỉ mà dịch vụ thấy, không phải địa chỉ hiển thị bởi một giao diện mạng không liên quan.
Sử dụng một yêu cầu như curl từ nguồn bên ngoài được phê duyệt, sau đó kiểm tra phản hồi và nhật ký truy cập. Lặp lại từ một nguồn bị từ chối. Nếu bạn đang kiểm tra một ứng dụng web, hãy xác minh cả chính sách biên và chính sách nguồn, vì một phản hồi biên thành công không chứng minh rằng nguồn được bảo vệ khỏi truy cập trực tiếp.
Không bao giờ để 0.0.0.0/0 ở lại sau khi kiểm tra. Truy cập rộng tạm thời là một mẹo khắc phục sự cố phổ biến, nhưng nó trở thành một lỗ hổng vĩnh viễn khi không ai sở hữu nhiệm vụ theo dõi. Ghi lại quy tắc trong hệ thống vé hoặc mã hạ tầng, yêu cầu xem xét đồng nghiệp cho các dải rộng, và đính kèm một ngày hết hạn hoặc ngày xem xét.
Một danh sách cho phép nhà cung cấp có thể lớn hơn nhiều so với một quy tắc đám mây. Một phân tích năm 2026 về các danh sách cho phép nhà cung cấp SaaS đã tìm thấy 66 dịch vụ công bố các dải chính thức, 38 khuyên khách hàng không nên gán IP tĩnh, và 27,513 khối CIDR được công bố trên các nhà cung cấp đó. Phân tích cũng cho thấy chỉ 8 trong số 66 dịch vụ cung cấp một tín hiệu thay đổi có thể theo dõi, trong khi 28 trong số 66 không có điểm cuối có thể đọc bằng máy và 43 trong số 66 không công bố bất kỳ dải IPv6 nào. Tài liệu CIDR có sẵn cung cấp bối cảnh tiêu chuẩn cơ bản để diễn giải các dải đó, nhưng bài học vận hành thì rộng hơn. Tài liệu của nhà cung cấp, tín hiệu cập nhật, và phạm vi IPv6 phải được coi là các phụ thuộc bảo trì.
Cài đặt Quy tắc IP trong Cloudflare, Nginx và Apache
CDN và lớp reverse-proxy là nơi nhiều quyết định cho phép sản xuất có hiệu lực. Một quy tắc biên có thể từ chối một yêu cầu trước khi nó đến nguồn, nhưng nguồn vẫn cần được bảo vệ nếu ai đó có thể kết nối trực tiếp với nó.
Các kiểm soát truy cập IP kiểu Cloudflare có thể cho phép, chặn, thách thức, hoặc áp dụng các hành động bảo mật khác cho một CIDR IPv4 hoặc IPv6, ASN, hoặc quốc gia. Định hình chính sách cho khu vực hoặc tài khoản dự kiến, và xác nhận xem yêu cầu có đến qua proxy hay không. Một quy tắc cho phép biên không đủ nếu địa chỉ công khai của nguồn vẫn có thể truy cập bên ngoài con đường đó.
Thứ tự Nginx quan trọng
Nginx hỗ trợ các chỉ thị allow và deny bên trong các khối http, server, hoặc location:
allow 203.0.113.7;
deny all;
Đặt quy tắc cho phép hẹp trước sự từ chối rộng. Nginx đánh giá các chỉ thị truy cập phù hợp theo thứ tự, vì vậy một quy tắc rộng ở vị trí sai có thể tạo ra một kết quả không mong đợi. Sử dụng geo khi chính sách cần một quyết định dựa trên biến, nhưng giữ danh sách nguồn được quản lý trung tâm.
Nếu một CDN hoặc reverse proxy nằm ở phía trước, hãy cấu hình các địa chỉ proxy đáng tin cậy trước khi sử dụng các tiêu đề khách hàng được chuyển tiếp cho các quyết định truy cập. Tin tưởng vào các giá trị X-Forwarded-For tùy ý cho phép một người yêu cầu tạo ra địa chỉ nguồn rõ ràng.
Apache theo cùng một mô hình
Cú pháp ủy quyền hiện tại của Apache sử dụng các chỉ thị như:
Require ip 203.0.113.7
Require all denied
Bạn có thể đặt những điều này trong một khối thư mục hoặc cấu hình truy cập phù hợp. Các ví dụ cũ về Order, Allow, và Deny vẫn xuất hiện trong tài liệu cũ, nhưng các triển khai mới hơn nên sử dụng khung ủy quyền được hỗ trợ bởi phiên bản đã cài đặt.
Bảo vệ nguồn: Hạn chế lưu lượng nguồn trực tiếp đến con đường proxy đáng tin cậy, sau đó thực thi xác thực người dùng và ủy quyền ứng dụng sau khi kiểm tra mạng.
Các kéo nguồn đã xác thực hoặc TLS tương hỗ thêm một bằng chứng riêng giữa biên và nguồn. Điều này quan trọng vì một địa chỉ IP xác định nguồn mạng, không phải một người dùng, thiết bị, hoặc quyền hạn. Giữ quy tắc CDN, tường lửa nguồn, chính sách reverse-proxy, và nhật ký ứng dụng đồng bộ để một thay đổi ở một lớp không bỏ qua lớp khác.
Danh sách cho phép cho Máy chủ Mail và Bảng điều khiển Quản trị SaaS
Một relay mail có thể hoạt động vào ngày quy tắc danh sách cho phép được thêm vào, sau đó ngừng chấp nhận lưu lượng sau khi nhà cung cấp thay đổi con đường ra của nó. Sự cố tương tự xuất hiện trong các bảng điều khiển quản trị SaaS khi một nhân viên từ xa thay đổi mạng hoặc một tích hợp bắt đầu rời đi qua một cổng khác. Hãy coi việc cho phép như một quy trình vận hành, không phải là một mục nhập một lần trong một màn hình cấu hình.
Các hệ thống mail thường xác định các nguồn relay đáng tin cậy thông qua danh sách mạng, ACL, hoặc các kết nối nhận. Kết hợp các kiểm soát đó với SPF, DKIM, và DMARC. Một quy tắc IP xác định một mạng mong đợi, nhưng nó không thể chứng minh rằng chủ sở hữu miền đã ủy quyền cho một tin nhắn hoặc rằng một người có quyền gửi. Xác thực người gửi và ủy quyền ứng dụng bao phủ những câu hỏi riêng biệt đó.
Gán cho mỗi mục một chủ sở hữu
Các bảng điều khiển quản trị SaaS thường đặt các hạn chế mạng dưới cài đặt bảo mật hoặc truy cập mạng. Các kế hoạch doanh nghiệp có thể chấp nhận các dải CIDR cùng với SSO được thực thi, mặc dù mỗi dịch vụ có giao diện và quy trình cập nhật riêng. Xác minh dải đã công bố thay vì giả định rằng nó vẫn đầy đủ, hiện tại, hoặc có sẵn trên IPv4 và IPv6.
Ghi lại những chi tiết này cho mỗi quy tắc:
- Mục đích kinh doanh: Nêu rõ quy trình làm việc, chẳng hạn như quản lý tài chính, truy cập API đối tác hoặc chuyển tiếp thư.
- Chủ sở hữu chịu trách nhiệm: Giao cho một nhóm, không phải một nhân viên đơn lẻ có thể rời đi.
- Phạm vi nguồn: Ghi lại địa chỉ chính xác hoặc CIDR và đường dẫn tạo ra nó.
- Ngày xem xét: Lên lịch xem xét định kỳ và đặt thời hạn cho quyền truy cập tạm thời.
- Phương pháp phục hồi: Tài liệu cách một quản trị viên khôi phục quyền truy cập sau khi địa chỉ thay đổi.
Các dải nhà cung cấp có thể được phân tán trên tài liệu, thông báo hỗ trợ và API. Một số nhà cung cấp công bố danh sách địa chỉ mà không có điểm cuối có thể đọc được bằng máy hoặc thông báo thay đổi, điều này khiến việc xác thực tự động trở nên khó khăn. RFC 4632 giải thích ký hiệu CIDR, nhưng không cung cấp quản trị nhà cung cấp hoặc phát hiện thay đổi đáng tin cậy.
Việc thoát đám mây động làm cho điều này trở nên khó khăn hơn. Nhân viên từ xa di chuyển giữa các nhà mạng và ISP, trong khi một khối lượng công việc có thể thoát qua một cổng khác với môi trường lưu trữ của nó. Xem xét các dải nhà cung cấp theo một nhịp độ xác định, kiểm tra luồng thư sau khi cập nhật, loại bỏ các mục không còn hiệu lực, và ghi lại mỗi thay đổi trước khi nó trở thành một sự cố truy cập hoặc tuân thủ. Đối với các IP proxy luân phiên, hãy sử dụng một nhóm được kiểm soát, tài liệu hoặc một kiểm soát dựa trên danh tính khác thay vì theo đuổi các địa chỉ riêng lẻ.
Danh sách trắng các IP Proxy Di động đúng cách
Các proxy di động làm phức tạp các danh sách cho phép tĩnh vì một địa chỉ nhà mạng 4G hoặc 5G thường đại diện cho một điểm thoát chia sẻ thay vì một thiết bị. Carrier-Grade NAT, hay CGNAT, đặt nhiều thuê bao phía sau các địa chỉ công cộng, và RFC 6598 định nghĩa không gian chia sẻ 100.64.0.0/10 được sử dụng cho mục đích này. Hướng dẫn kỹ thuật về hành vi proxy di động, dân cư và trung tâm dữ liệu lưu ý rằng hàng ngàn người dùng có thể chia sẻ một IP nhà mạng cùng một lúc.
Sự chia sẻ đó làm cho các dải di động khó bị chặn mà không ảnh hưởng đến người dùng hợp pháp. Các hệ thống chống bot thường đối xử với các IP nhà mạng một cách khoan dung hơn so với các địa chỉ nhà cung cấp lưu trữ vì việc chặn toàn bộ dải nhà mạng tạo ra thiệt hại không mong muốn. Đây là một lý do mà kết nối di động phù hợp với xác minh quảng cáo hợp pháp, QA khu vực, quy trình truyền thông xã hội và nghiên cứu thị trường công khai nơi mà một lộ trình mạng di động tự nhiên là quan trọng. Một so sánh về các loại proxy giải thích sự đánh đổi này mà không làm cho các IP di động trở thành sự thay thế cho xác thực hoặc tuân thủ nền tảng.
Xây dựng quy tắc xung quanh phiên làm việc
Bắt đầu với địa chỉ nguồn mà dịch vụ mục tiêu thấy. Ghi lại một mẫu từ bảng điều khiển proxy hoặc nhật ký phiên, xác định nhà mạng và ASN, sau đó xác minh phân bổ liên quan thông qua một cơ quan đăng ký Internet khu vực hoặc dịch vụ WHOIS. Đừng tự động gửi một khối nhà mạng lớn. Dải phải đủ rộng để bao phủ nhóm thoát được tài liệu của nhà cung cấp trong khi vẫn đủ hẹp cho chính sách bảo mật của mục tiêu.
Một quy trình làm việc thực tế trông như thế này:
- Ghi lại lối thoát quan sát được: Ghi lại địa chỉ công cộng được trình bày bởi phiên hoạt động.
- Xác định mạng: Kiểm tra ASN và phân bổ nhà mạng thay vì tin tưởng vào một nhãn trong nhật ký ứng dụng.
- Chọn phạm vi: Sử dụng CIDR được tài liệu hóa nhỏ nhất bao gồm nhóm được phê duyệt. Một
/32đơn lẻ thường quá mong manh cho một dịch vụ di động luân phiên. - Chọn hành vi phiên: Sử dụng một phiên dính khi trạng thái đăng nhập, cookie, hoặc một quy trình QA dài phải giữ trên một địa chỉ. Sử dụng luân phiên khi quy trình hợp pháp yêu cầu quan sát mạng riêng biệt.
- Kiểm tra và giám sát: Xác nhận mục tiêu chấp nhận nguồn, sau đó theo dõi nhật ký truy cập bị từ chối và thông báo thay đổi của nhà cung cấp.
Luân phiên và tính dính giải quyết các vấn đề khác nhau. Hướng dẫn phiên proxy mô tả luân phiên là thay đổi địa chỉ thoát theo lịch trình hoặc kích hoạt, trong khi các phiên dính giữ một địa chỉ lâu hơn để giảm thiểu sự thay đổi phiên. Không chế độ nào làm cho một IP trở thành một danh tính. HTTP và SOCKS5 là các phương thức vận chuyển, trong khi nhắm mục tiêu địa lý chọn một vị trí hoặc lộ trình nhà mạng. Nhận thức ASN cho bạn biết mạng nào sở hữu nguồn rõ ràng, nhưng nó không xác lập rằng người dùng được ủy quyền.
Kết nối dân cư có thể phù hợp với nghiên cứu cần các đặc điểm ISP hộ gia đình, trong khi các địa chỉ trung tâm dữ liệu có thể phù hợp cho thử nghiệm hạ tầng được kiểm soát nơi danh tính mạng không phải là một phần của thử nghiệm. Di động 4G hoặc 5G phù hợp hơn khi bạn đang xác thực hành vi phụ thuộc vào nhà mạng, kiểm tra việc giao hàng quảng cáo khu vực, hoặc thử nghiệm một trải nghiệm hướng di động. Sử dụng tự động hóa chỉ trong các luật, quy tắc nền tảng và ranh giới quyền hạn áp dụng.
Evoproxy cung cấp quyền truy cập proxy di động với các cổng cá nhân và chia sẻ, luân phiên có thể cấu hình, và phê duyệt IP nguồn cho các quy trình làm việc cần quyền truy cập được kiểm soát đến một lộ trình thoát di động đang thay đổi. Để biết chi tiết triển khai, hãy xem hướng dẫn về quản lý IP proxy di động trước khi chọn phạm vi CIDR hoặc chế độ phiên.
Evoproxy cung cấp kết nối proxy di động 4G/LTE với các cổng cá nhân hoặc chia sẻ, luân phiên có thể cấu hình, và quyền truy cập IP nguồn đã được phê duyệt cho quản lý truyền thông xã hội hợp pháp, xác minh quảng cáo, nghiên cứu thị trường và QA phụ thuộc vào địa lý. Truy cập Evoproxy để xem các phiên di động có sẵn và chọn một thiết lập phù hợp với danh sách cho phép và yêu cầu phiên của bạn.
