"Có nên đặt một CDN ở phía trước không?" là câu hỏi đầu tiên hầu hết mọi người đặt ra ngay sau khi mua một server offshore, và nó không có một câu trả lời duy nhất, bởi thực chất đó là hai câu hỏi khoác chung một chiếc áo. Chống đỡ một cuộc tấn công và giữ mình không thể bị tìm ra là hai vấn đề khác nhau với hai giải pháp khác nhau, và cách bố trí giải quyết vấn đề này có thể âm thầm phá hỏng vấn đề kia.
Sự nhầm lẫn này tốn kém theo cả hai hướng. Có người đặt một CDN lớn của Mỹ ở phía trước đúng loại nội dung mà họ đã chọn hosting bỏ qua DMCA để lưu trữ, và tự tay trao lại một bàn tiếp nhận khiếu nại cho đúng loại trung gian mà họ đang cố tránh. Những người khác thì bỏ qua tất cả, hứng chịu một đợt lũ ở tầng ứng dụng mà việc lọc mạng chưa từng được thiết kế để nhìn thấy, rồi kết luận rằng biện pháp chống DDoS chỉ là lời hứa suông. Hướng dẫn này tách hai vấn đề đó ra, nói rõ mỗi lớp thực sự làm được gì, và dành phần lớn nội dung cho phần quyết định kết quả trong cả hai trường hợp: sáu cách một địa chỉ origin vẫn rò rỉ dù mọi thứ khác đã được cấu hình đúng.
Hai vấn đề trông như một
Bất cứ thứ gì bạn đặt trước một server đều đang làm một trong hai việc: giữ một cuộc tấn công tránh xa nó, hoặc giữ địa chỉ của nó không ai biết. Hai việc này chồng lấn đủ để bị nhầm lẫn, và khác nhau đủ để giải quyết nhầm việc là phí tiền.
| Điều bạn đang lo lắng | Điều thực sự giải quyết được nó | Điều không giải quyết được |
|---|---|---|
| Một đợt lũ khối lượng lớn làm đầy đường truyền của bạn (tầng 3 và 4) | Lọc ở biên mạng tại host, đã bao gồm trong mọi gói ở đây | Bất cứ thứ gì bạn cài trên server — vì lúc đó đường truyền đã đầy rồi |
| Một đợt lũ ứng dụng gồm các request trông như thật (tầng 7) | Một CDN hoặc WAF, cache, giới hạn tốc độ, các endpoint rẻ hơn | Lọc gói tin, vốn nhìn thấy HTTP hợp lệ và cho nó đi qua |
| Không ai được phép chạm trực tiếp vào máy | Một lớp mặt tiền (CDN hoặc node của riêng bạn) cộng với một firewall chỉ chấp nhận nó | Chỉ riêng một CDN, nếu origin vẫn trả lời cả internet |
| Không ai được biết ai đang vận hành nó | Đăng ký không-KYC, quyền riêng tư thanh toán, kỷ luật tài khoản | Bất kỳ lượng hạ tầng nào — đây là câu hỏi về danh tính |
| Nội dung phải sống sót qua các khiếu nại | Khu vực pháp lý, và một host không hành động theo khiếu nại | Một CDN, thứ thêm vào một kênh khiếu nại thay vì gỡ bỏ nó |
Hãy đọc lại hàng cuối hai lần, vì đó là hàng khiến người ta mắc bẫy. Mọi thứ khác trên trang này là kỹ thuật. Hàng đó thì không.
Những gì host của bạn đã làm sẵn, và nó dừng lại ở đâu
Lọc ở tầng 3 và tầng 4 đã được bao gồm trong mọi gói chúng tôi bán, không tính thêm phí, và nó chạy ở biên mạng chứ không phải trên server của bạn — đó là nơi duy nhất nó có thể hoạt động, vì một uplink đã bão hòa thì không có gì chạy phía sau nó có thể sửa được. Băng thông không giới hạn, nên một cuộc tấn công không biến thành một hóa đơn. Với phần lớn những gì người ta gọi là "một cuộc DDoS", đó là toàn bộ câu chuyện.
Điều nó không nhìn thấy được là loại còn lại. Năm trăm request mỗi giây tới một endpoint tìm kiếm từ bốn mươi nghìn địa chỉ dân dụng không phải là traffic dị dạng; đó là traffic. Các kết nối Slowloris nhỏ giọt từng header sau mỗi vài giây, xét riêng lẻ, đều lịch sự. Một form đăng nhập bị dội bom bằng các POST body thật không thể phân biệt được ở cấp gói tin với một ngày thứ Hai bận rộn. Không bộ lọc gói tin nào giúp được, vì bản thân các gói tin đó chẳng có gì sai.
Có một hướng traffic mà chúng tôi thực sự hành động, và điều này đáng nói thẳng: các cuộc tấn công và spam hàng loạt xuất phát từ mạng của chúng tôi có thể bị null-route để giữ cho phần còn lại của hạ tầng khỏe mạnh. Đó là một biện pháp vận hành, không phải một biện pháp về nội dung — sự phân biệt mà hướng dẫn hosting bỏ qua DMCA của chúng tôi trình bày chi tiết hơn.
Những gì một CDN che giấu, và bàn tiếp nhận khiếu nại bạn thừa hưởng
Cơ chế này đơn giản và thực sự hiệu quả. Domain của bạn phân giải tới các địa chỉ của nhà cung cấp, client kết nối tới đó, và nhà cung cấp lấy dữ liệu từ origin của bạn. Địa chỉ thật không bao giờ xuất hiện trong kết nối của client, nên không ai chỉ biết domain có thể tấn công được nó. Cùng một thủ thuật đó là lý do vì sao việc đặt CDN trước hoạt động tốt cho các proxy chống kiểm duyệt: một cơ quan kiểm duyệt chỉ thấy traffic tới một địa chỉ mà họ không đủ khả năng chặn.
Ba thứ đi kèm theo đó, và không thứ nào bị giấu trong chữ nhỏ:
- Biên (edge) kết thúc TLS của bạn tại đó. Traffic là plaintext bên trong mạng của nhà cung cấp, theo đúng thiết kế — đó là cách caching và filtering hoạt động. Bất cứ điều gì người dùng của bạn gõ vào đều đến một bên thứ ba trước khi đến được bạn.
- Một kênh khiếu nại chưa từng tồn tại trước đó. Khiếu nại có thể được nộp thẳng tới CDN, và một CDN sẽ trả lời chúng: bằng cách chuyển tiếp cho bạn, nêu tên nhà cung cấp hosting của bạn, hoặc chấm dứt dịch vụ với bạn. Nếu lý do bạn chọn offshore là vì khiếu nại chẳng đi đến đâu, thì việc đặt một trung gian ở Mỹ ra phía trước sẽ nối lại đúng sợi dây bạn đã trả tiền để cắt đứt.
- Một tài khoản. Email, phương thức thanh toán, thường cả số điện thoại, gắn với domain của bạn và được giữ lại vô thời hạn. Nói thêm bên dưới, vì đây thường là mắt xích yếu nhất trong toàn bộ cách bố trí này.
Không điều nào ở trên khiến việc dùng CDN là sai. Nó biến CDN thành một quyết định có hai mặt: tuyệt vời cho một cửa hàng hay một ứng dụng có người dùng thật và áp lực tầng 7 thật, nhưng phản tác dụng rõ rệt với việc xuất bản nội dung dễ bị yêu cầu gỡ bỏ. Câu trả lời của chính chúng tôi cho câu hỏi trên trang hosting bỏ qua DMCA luôn là phiên bản ngắn gọn của điều này: để chống lại việc gỡ bỏ nội dung, hãy dùng lớp lọc mạng bạn đã có sẵn và bỏ qua CDN.
Sáu cách một địa chỉ origin vẫn rò rỉ
Đây là phần quan trọng nhất, vì sự che giấu không phải một sản phẩm bạn mua — đó là một đặc tính bạn hoặc duy trì, hoặc đánh mất, thường chỉ trong vài ngày, vì một trong sáu điều sau. Các origin bị tìm ra mỗi ngày, ngay phía sau những cấu hình CDN hoàn toàn ổn.
- Log Certificate Transparency. Mọi chứng chỉ được tin cậy công khai cấp cho domain của bạn đều được công bố lên các log công khai, vĩnh viễn, có thể tra cứu, trong vòng vài phút. Chúng không công bố địa chỉ của bạn; chúng công bố hostnames của bạn —
staging,mail,vpn, subdomain bạn từng dựng một lần vào năm 2024. Mỗi cái là một ứng viên để phân giải, và chỉ cần một bản ghi không trỏ vào lớp mặt tiền là đủ để kết thúc trò chơi. - Lịch sử DNS. Các dịch vụ passive-DNS lưu lại mọi địa chỉ mà domain của bạn từng phân giải tới. Chuyển ra sau một CDN về sau không xóa được những gì đã được ghi lại — sự che giấu phải bắt đầu trước khi domain phân giải lần đầu tiên, nếu không bạn cần một địa chỉ mới, chứ không phải một lớp mặt tiền mới.
- Các bản ghi không thể proxy được, và những cái bạn đã quên. Mail exchanger phải trỏ vào thứ gì đó có thể chạm tới được. Một bản ghi
AAAAbị bỏ sót khi bạn chỉ proxy IPv4 cũng vậy, cũng như một hostname FTP hay panel cũ, một wildcard, hay cái host phát triển "tạm thời" giờ đã ba năm tuổi. - Bất cứ thứ gì server gửi đi. Mail từ origin mang địa chỉ của nó trong các header
Received— một email đặt lại mật khẩu là hành vi tự tiết lộ. Webhook, các lượt lấy ảnh gửi ra ngoài, link preview, pingback, kiểm tra cập nhật và trình báo lỗi (crash reporter) đều liên lạc ra ngoài từ địa chỉ thật, và bất kỳ ai khiến ứng dụng của bạn nói chuyện với một host họ kiểm soát đều biết được nó. - Quét toàn bộ internet. Mọi địa chỉ IPv4 đều bị quét và lập chỉ mục liên tục bởi các dịch vụ công khai, và kết quả có thể tra cứu trong vài giây. Nếu origin của bạn trả lời trên cổng 443 bằng chứng chỉ của bạn, hoặc phục vụ trang chủ của bạn cho bất kỳ Host header nào, việc khớp nó chỉ là một truy vấn dựa trên hash nội dung, dấu vân tay chứng chỉ, hay hash favicon. Đây là cách phần lớn các origin bị tìm ra, và nó không tốn gì của người tìm.
- Ứng dụng tự nói về chính nó. URL tuyệt đối và redirect chứa địa chỉ thô, các endpoint status hay metrics bị để hở, stack trace chi tiết nêu tên các host nội bộ, header tiết lộ backend, và virtual host mặc định vui vẻ phục vụ site của bạn cho bất kỳ ai hỏi bằng địa chỉ.
Khóa chặt origin để chỉ lớp mặt tiền mới chạm tới được
Sự che giấu phụ thuộc vào việc không ai đoán ra địa chỉ thì không phải là che giấu. Cách bố trí này chỉ đứng vững khi origin từ chối nói chuyện với bất kỳ ai ngoài lớp mặt tiền, để một địa chỉ bị rò rỉ chỉ là chuyện phiền toái chứ không phải một sự cố.
- Mặc định từ chối, rồi cho phép lớp mặt tiền. Chỉ chấp nhận cổng 80 và 443 từ các dải địa chỉ đã công bố của nhà cung cấp, và tự động làm mới danh sách đó — các dải địa chỉ thay đổi, và một danh sách cũ sẽ fail open hoặc fail closed vào đúng thời điểm tệ nhất. Mọi thứ khác, kể cả SSH, thuộc về một tunnel hoặc một địa chỉ quản trị riêng, như trong checklist gia cố giờ đầu tiên của chúng tôi.
- Xác thực lớp mặt tiền. Chứng chỉ client giữa CDN và origin của bạn — thường gọi là authenticated origin pulls — nghĩa là ngay cả một địa chỉ đúng cộng một Host header đúng cũng chẳng lấy được gì nếu thiếu chứng chỉ.
- Tốt hơn: không mở cổng inbound nào cả. Một tunnel chỉ-outbound từ origin tới edge, dù là connector của chính CDN hay WireGuard tới một node bạn tự chạy, nghĩa là origin không bao giờ lắng nghe trên một interface công khai. Quét không thể tìm thấy thứ không trả lời, và đây là phiên bản mạnh nhất của cách bố trí này.
- Một virtual host, một Host header. Server mặc định phải không trả về bất cứ thứ gì hữu ích. Nếu site của bạn tải được khi gọi bằng địa chỉ, nó sẽ bị một scanner khớp trúng trong vòng một tuần.
- Chuyển mail ra khỏi origin web. Mail phải chạm tới được và phải tự nhận diện; hãy giữ nó trên một máy riêng, như hướng dẫn thiết lập mail server giả định.
- Xác minh từ bên ngoài. Mọi kiểm tra trong danh sách này đều vô nghĩa nếu chạy từ chính server. Hãy kiểm tra từ một mạng không phải của bạn.
Node mặt tiền của riêng bạn thay vì một CDN
Lựa chọn thứ ba thường bị bỏ qua vì nó không có ngân sách tiếp thị: một VPS nhỏ làm bộ mặt công khai, một tunnel mã hóa nối về máy giữ dữ liệu, và nginx hoặc HAProxy chuyển tiếp traffic giữa chúng. Nhìn từ bên ngoài, nó giống hệt một web server bình thường. Máy thật nằm ở nơi khác, không mở cổng inbound nào cả.
Thứ bạn nhận được là sự che giấu mà không có ai khác tham gia vào cách bố trí — không tài khoản bên thứ ba, không bàn khiếu nại bên ngoài, không người lạ nào kết thúc TLS của bạn. Bạn còn có được một sự phân tách khu vực pháp lý mà bằng cách khác rất khó mua được: lớp mặt tiền ở nơi có người dùng, dữ liệu ở nơi luật pháp phù hợp với bạn, chọn từ bảy địa điểm của chúng tôi. Và vì không có danh tính nào được gắn vào lúc đăng ký, lớp mặt tiền này có thể vứt bỏ được — một địa chỉ bị lộ được thay thế trong vài phút thay vì phải đàm phán.
Thứ bạn không nhận được là năng lực anycast. Một node chỉ có năng lực của một node, và trong khi lớp lọc mạng của chúng tôi bảo vệ nó y hệt như bảo vệ bất kỳ server nào khác, một cuộc tấn công khối lượng lớn thực sự là một cuộc thi băng thông mà một mạng lưới toàn cầu sẽ thắng. Định vị trung thực: một node mặt tiền là câu trả lời đúng để che giấu một backend nặng hoặc đắt tiền — một mảng lưu trữ, một hộp GPU, một mail server, một database — và để phân tách khu vực pháp lý. Nó không thay thế được một CDN dưới áp lực tầng 7 kéo dài.
Chọn lựa, trong một bảng
| Tình huống của bạn | Cách bố trí | Lý do |
|---|---|---|
| Xuất bản nội dung dễ bị yêu cầu gỡ bỏ | Trực tiếp, không CDN, tại một khu vực pháp lý được chọn có chủ đích | Một CDN thêm vào một bàn khiếu nại mà host của bạn cố tình không có |
| Cửa hàng hoặc SaaS có người dùng thật và áp lực tầng 7 | CDN ở phía trước, origin bị khóa chỉ cho các dải địa chỉ của nó | Tầng 7 chính là vấn đề mà một CDN thực sự được xây ra để giải quyết |
| Endpoint lách kiểm duyệt tại một quốc gia bị kiểm duyệt | Đặt CDN ở phía trước | Cơ quan kiểm duyệt chỉ thấy một địa chỉ họ không đủ khả năng chặn |
| Traffic tĩnh hoặc media lớn | CDN để giảm tải cache | Băng thông và độ trễ mới là trọng tâm; che giấu chỉ là hệ quả phụ |
| Ẩn danh là yêu cầu hàng đầu | Node mặt tiền của riêng bạn, hoặc không có gì ở phía trước cả | Một tài khoản bên thứ ba là một hồ sơ danh tính mà trước đó bạn chưa từng có |
| Backend nặng đáng để che giấu | Node mặt tiền cộng một tunnel chỉ-outbound | Cỗ máy đắt tiền không bao giờ xuất hiện trên internet công khai |
Tài khoản thường là mắt xích yếu nhất
Hãy hình dung điều gì xảy ra khi hạ tầng hoàn hảo còn giấy tờ thì không. Server được trả bằng Monero, không giấy tờ tùy thân, không địa chỉ email — cách bố trí được mô tả trong các trang hosting không-KYC của chúng tôi. Sau đó một tài khoản CDN được mở bằng thẻ ngân hàng, địa chỉ cá nhân và số điện thoại, ghi rõ domain mà nó bảo vệ. Tài khoản đó là một hồ sơ danh tính mạnh hơn, bền hơn bất cứ thứ gì trên server, do một công ty nắm giữ và công ty đó tuân theo trát đòi hầu tòa — và nó phá hỏng hoàn toàn quyền riêng tư thanh toán vừa có được.
Cách khắc phục không phức tạp, chỉ dễ bị quên: nếu mục tiêu là ẩn danh, thì hoặc lớp mặt tiền thuộc về chính bạn, hoặc tài khoản đứng trước nó phải vứt bỏ được và không thể quy về ai, y hệt như server phía sau nó. OpSec máy chủ trình bày kỷ luật này một cách bài bản, và câu trả lời trung thực của chúng tôi về tính ẩn danh của offshore hosting nói thẳng mắt xích nào trong chuỗi thường đứt trước tiên. Gần như không bao giờ là mắt xích kỹ thuật.
Tự kiểm toán mức độ lộ diện của bạn trong mười phút
Mỗi mục dưới đây là thứ mà một bên quan tâm sẽ kiểm tra trong vài phút đầu tiên. Hãy tự chạy chúng, từ một máy không phải server, trước khi bạn cần đến câu trả lời.
- Liệt kê mọi hostname bạn từng cấp chứng chỉ. Tìm apex domain của bạn trong một công cụ tìm kiếm Certificate Transparency và phân giải từng kết quả. Bất cứ thứ gì không trỏ vào lớp mặt tiền đều là một lỗ rò, kể cả các host bạn không còn dùng nữa.
- Đọc lại lịch sử DNS của chính bạn. Một tra cứu passive-DNS cho thấy các địa chỉ mà domain của bạn từng phân giải tới trước khi có CDN. Nếu origin của hôm qua vẫn là origin của hôm nay, sự che giấu chưa bao giờ là thật.
- Hỏi thẳng origin.
curl -sI --resolve example.com:443:198.51.100.10 https://example.com/— nếu site trả lời, firewall của bạn không giới hạn chỉ cho lớp mặt tiền, và bất kỳ ai có một địa chỉ nghi vấn cũng có thể xác nhận điều đó chỉ bằng một request. - Hỏi nó một cách sỗ sàng.
curl -skI https://198.51.100.10/phải không trả về gì có thể nhận diện được. Một virtual host mặc định phục vụ trang chủ của bạn là lỗi đơn lẻ phổ biến nhất trên trang này. - Kiểm tra mọi loại bản ghi, không chỉ A.
dig +short AAAA example.com,dig +short MX example.com, và tương tự cho mọi subdomain mà các log transparency đã tiết lộ. IPv6 bị bỏ quên không proxy là một lỗi kinh điển. - Tự gửi mail từ ứng dụng của bạn. Kích hoạt một lượt đặt lại mật khẩu và đọc toàn bộ chuỗi
Received. Nếu địa chỉ origin nằm trong đó, thì nó cũng nằm trong mọi email bạn từng gửi. - Xác nhận các cổng đã đóng. Từ một mạng không liên quan,
nmap -Pn -p80,443 198.51.100.10phải hiện filtered, không phải open. - Tìm trên các scanner. Tra dấu vân tay chứng chỉ và hash favicon trang chủ của bạn trong một chỉ mục quét internet công khai. Nếu origin của bạn bị lập chỉ mục, đó chính là cách nó sẽ bị tìm ra.
Khi địa chỉ đã bị lộ
Hãy coi như nó lộ vĩnh viễn. Một địa chỉ đã xuất hiện trong passive DNS và trong các chỉ mục quét đã nằm trong hồ sơ công khai vĩnh viễn, và không thay đổi cấu hình nào rút lại được điều đó. Phản ứng đúng đắn là làm theo quy trình chứ không phải làm gì đó khôn khéo.
- Vá lỗ rò trước tiên. Xoay sang một địa chỉ mới mà không bịt lỗ hổng sẽ lặp lại tình huống này trong vài ngày, và bạn sẽ chỉ mất công di chuyển mà chẳng học được gì.
- Rồi mới xoay vòng. Triển khai một bản thay thế — ở một khu vực pháp lý khác nếu lý do là pháp lý chứ không phải kỹ thuật — khôi phục dữ liệu, rồi chuyển hẳn sang. Vì không có danh tính nào gắn với server đầu tiên, đây là một khởi đầu mới chứ không phải một cuộc đàm phán — đó là cái lợi thực tế, chẳng có gì hào nhoáng, của việc mua server mà không cần lịch sử tài khoản.
- Chuẩn bị việc chuyển đổi trước khi có sự cố khẩn cấp. Một TTL DNS ngắn, cấu hình bạn có thể triển khai lại từ một repository, và một quy trình khôi phục đã được kiểm thử biến một buổi chiều tồi tệ thành hai mươi phút. Không ai chuẩn bị việc này trong lúc đang bị tấn công.
- Loại bỏ địa chỉ cũ đúng cách. Đừng để server cũ tiếp tục phục vụ cùng nội dung trên địa chỉ cũ; đó là một xác nhận sống cho bất kỳ ai đang theo dõi, và nó giữ cho hồ sơ luôn mới.
Phiên bản ngắn gọn
Lọc ở cấp mạng xử lý các cuộc tấn công khối lượng lớn, đi kèm sẵn với server và không tốn thêm phí. Một CDN xử lý tầng ứng dụng và che giấu origin, với cái giá là một trung gian kết thúc TLS của bạn, trả lời khiếu nại và biết bạn là ai. Node mặt tiền của riêng bạn mua được sự che giấu mà không cần trung gian, nhưng không có năng lực toàn cầu. Khu vực pháp lý quyết định câu hỏi pháp lý và không cái nào trong ba lựa chọn trên chạm tới nó. Và cả ba đều có thể bị phá hỏng chỉ bởi một bản ghi chưa proxy, một email từ origin, hoặc một virtual host mặc định.
Hãy quyết định theo mục tiêu chứ không theo thói quen, rồi dành mười phút cho việc kiểm toán — nó tìm ra nhiều lỗ hổng thật hơn bất kỳ gói nâng cấp nào. Nếu bạn muốn kiến trúc này mà không cần bên thứ ba, một VPS nhỏ làm lớp mặt tiền và phần việc thật trên phần cứng dedicated phía sau là cách bố trí chúng tôi thấy phổ biến nhất ở những người đã từng bị tìm ra một lần.