Hai giờ sáng, đội ngũ bảo mật của một nền tảng tài chính vừa hoàn tất chuyển đổi sang CDN tích hợp chống DDoS. Người dùng đã có thể truy cập website bình thường qua CDN; các chính sách chống DDoS, chống HTTP flood và quy tắc WAF đều đã được bật.

Đúng lúc đội kỹ thuật tưởng có thể tạm yên tâm, băng thông tại máy chủ gốc đột ngột bị bão hòa.

Kẻ tấn công không tiếp tục nhắm vào tên miền website. Chúng bỏ qua CDN và gửi lưu lượng tấn công thẳng đến IP thực của hệ thống giao dịch. Các điểm biên chống DDoS không nhận được lưu lượng này nên không thể lọc. Chỉ vài phút sau, API dữ liệu thị trường bắt đầu hết thời gian chờ, người dùng không đăng nhập được, còn API giao dịch liên tục trả lỗi 502 và 504.

Tình huống này không hiếm gặp.

Triển khai CDN tích hợp chống DDoS mới là bước đầu tiên để ẩn IP máy chủ gốc. Nếu lịch sử DNS, cấu hình ứng dụng, tên miền phụ của API, máy chủ email, môi trường thử nghiệm hoặc quy tắc tường lửa vẫn làm lộ địa chỉ thực, kẻ tấn công có thể vượt qua lớp bảo vệ ở biên và đánh thẳng vào máy chủ gốc của nền tảng tài chính.

Với các nền tảng chứng khoán, hợp đồng tương lai, quỹ đầu tư và công nghệ tài chính, bảo vệ máy chủ gốc hiệu quả đòi hỏi tập trung các điểm tiếp nhận lưu lượng công khai, thay IP đã lộ và giới hạn truy cập bằng danh sách cho phép. Đồng thời cần dọn dẹp tên miền không còn sử dụng, tách biệt hệ thống quản trị và liên tục giám sát nguy cơ lộ địa chỉ.

Vì sao hệ thống giao dịch tài chính cần bảo vệ IP máy chủ gốc?

Nguyên tắc của CDN tích hợp chống DDoS là đưa cả lưu lượng hợp lệ lẫn lưu lượng tấn công qua các điểm biên của CDN trước khi đến máy chủ gốc.

Tại biên, CDN lọc lưu lượng DDoS, nhận diện HTTP flood, áp dụng quy tắc WAF và kiểm soát truy cập API. Chỉ những yêu cầu vượt qua bước kiểm tra bảo mật mới được chuyển đến máy chủ gốc của nền tảng tài chính.

Luồng truy cập dự kiến:Người dùng hoặc lưu lượng tấn công → điểm biên chống DDoS của CDN07 → kiểm tra bảo mật và lọc lưu lượng → máy chủ gốc của nền tảng tài chính

Nếu IP thực của máy chủ gốc bị lộ, kẻ tấn công có thể bỏ qua CDN:Lưu lượng tấn công → IP thực của nền tảng tài chính

Dù CDN có đủ năng lực giảm thiểu tấn công, nó cũng không thể lọc lưu lượng không đi qua mình.

Kẻ tấn công không cần xâm nhập máy chủ. Chỉ cần làm cạn băng thông, số kết nối hoặc bảng phiên của tường lửa tại máy chủ gốc cũng có thể gây ra:

• Không thể đăng nhập website hoặc ứng dụng;
• API dữ liệu thị trường phản hồi chậm;
• Hàng loạt kết nối WebSocket bị ngắt;
• API gateway liên tục hết thời gian chờ;
• Yêu cầu đặt hoặc hủy lệnh thất bại;
• Kết nối với cơ sở dữ liệu và dịch vụ nội bộ gặp lỗi;
• Nhà cung cấp dịch vụ đám mây áp dụng blackholing hoặc giới hạn lưu lượng;
• Máy chủ gốc chính và dự phòng cùng bị tấn công.

Với nền tảng tài chính, bảo vệ IP máy chủ gốc là điều kiện để CDN chống DDoS phát huy tác dụng, không phải một bước tối ưu tùy chọn.

Vì sao IP thực vẫn bị lộ sau khi triển khai CDN chống DDoS?

Nhiều nền tảng cho rằng trỏ tên miền chính về CDN là đủ để ẩn IP máy chủ gốc. Nhưng kẻ tấn công không chỉ xem bản ghi DNS hiện tại của tên miền chính.

Địa chỉ thực thường bị lộ qua những nguồn sau.

Lịch sử DNS tiết lộ địa chỉ máy chủ gốc cũ

Trước khi dùng CDN, tên miền chính của website tài chính có thể đã trỏ trực tiếp trong thời gian dài đến máy chủ ở Mỹ, Hồng Kông, Singapore hoặc khu vực khác.

Dù nay đã trỏ sang địa chỉ CDN, kết quả phân giải DNS trước đây vẫn có thể được lưu trong cơ sở dữ liệu lịch sử, hệ thống quét mạng hoặc dịch vụ giám sát của bên thứ ba.

Nếu tiếp tục dùng IP máy chủ gốc cũ sau khi triển khai CDN, kẻ tấn công vẫn có thể lần theo các bản ghi đó để tìm máy chủ.

Cách xử lý

Sau khi chuyển sang CDN, hãy sớm thay IP công khai của máy chủ gốc thay vì tiếp tục dùng địa chỉ cũ đã lộ.

Cần xác nhận IP cũ không còn phục vụ hệ thống đang hoạt động và không chuyển tiếp đến máy chủ gốc mới. Nếu giữ điểm truy cập cũ, kẻ tấn công vẫn có thể lần theo để tìm hệ thống.

Tên miền phụ cho API, dữ liệu thị trường và WebSocket chưa đi qua CDN

Website chính có thể đã dùng CDN chống DDoS, nhưng các tên miền dịch vụ khác vẫn trỏ thẳng về máy chủ gốc, chẳng hạn:

• api.example.com
• trade.example.com
• quote.example.com
• account.example.com
• ws.example.com
• download.example.com
• upload.example.com

Chỉ cần một tên miền phụ không đi qua CDN, kẻ tấn công có thể phát hiện IP máy chủ gốc dùng chung với hệ thống giao dịch chính hoặc dải địa chỉ của cùng trung tâm dữ liệu.

Ứng dụng di động đặc biệt dễ bị bỏ sót. Giao diện có thể tải từ tên miền CDN, trong khi yêu cầu đăng nhập, lấy dữ liệu thị trường và giao dịch lại gửi thẳng đến máy chủ API. Website trông như đã được bảo vệ nhưng hệ thống giao dịch cốt lõi vẫn bị lộ.

Cách xử lý

Kiểm kê mọi điểm truy cập công khai trên Internet, không chỉ tên miền website chính.

Website, ứng dụng, API, WebSocket, chức năng tải tệp lên, tải phần mềm xuống và endpoint callback công khai đều cần đi qua dịch vụ chống DDoS phù hợp với giao thức và mục đích sử dụng.

Dịch vụ HTTP và HTTPS có thể được proxy qua CDN chống DDoS. Với dịch vụ TCP không thể dùng proxy HTTP, cần proxy TCP có chống DDoS, chuyển tiếp lớp 4 hoặc giải pháp bảo vệ mạng chuyên dụng.

IP máy chủ được ghi cố định trong ứng dụng

Để giảm thời gian phân giải DNS, một số ứng dụng tài chính đời cũ ghi trực tiếp IP máy chủ vào tệp cấu hình hoặc mã phía máy khách. Một số ứng dụng khác lưu cả tên miền lẫn IP và tự chuyển sang IP dự phòng khi không phân giải được tên miền.

Cách làm này có vẻ tăng khả năng dự phòng, nhưng lại có thể làm lộ trực tiếp máy chủ gốc.

Nếu thiết bị người dùng lấy được IP đó, kẻ tấn công cũng có thể tìm thấy nó trong gói cài đặt công khai, yêu cầu mạng hoặc nhật ký lỗi.

Cách xử lý

Ứng dụng không nên kết nối trực tiếp đến IP máy chủ gốc. Mọi yêu cầu công khai cần đi qua tên miền dịch vụ được bảo vệ để vào mạng chống DDoS của CDN07.

Nếu cần điểm truy cập dự phòng, hãy cấu hình nhiều tên miền hoặc địa chỉ truy cập đều được chống DDoS, thay vì để máy chủ gốc thực làm phương án dự phòng trên thiết bị người dùng.

Khi cập nhật cấu hình ứng dụng, cần tính đến người dùng còn chạy phiên bản cũ. Chỉ sửa phiên bản mới nhất sẽ không ngăn phiên bản cũ tiếp tục làm lộ hoặc truy cập trực tiếp máy chủ gốc.

Dịch vụ email, hỗ trợ và tệp dùng chung IP với hệ thống giao dịch

Để tiết kiệm tài nguyên máy chủ, một số nền tảng tài chính đặt website, email, hệ thống hỗ trợ khách hàng, dịch vụ tải tệp và API giao dịch trên cùng một IP công khai.

Ngay cả khi website đã qua CDN, bản ghi MX của máy chủ email, hệ thống hỗ trợ hoặc máy chủ tệp vẫn có thể công khai chính IP đó.

Kẻ tấn công không cần tìm qua tên miền giao dịch. Chỉ cần phát hiện dịch vụ khác dùng chung địa chỉ là có thể bỏ qua CDN.

Cách xử lý

Không nên dùng chung IP tiếp nhận lưu lượng của hệ thống giao dịch với:

• Máy chủ gửi và nhận email;
• Hệ thống quản trị website doanh nghiệp;
• Hệ thống hỗ trợ trực tuyến;
• Môi trường phát triển và thử nghiệm;
• Dịch vụ truyền tệp;
• Cổng quản trị từ xa;
• Nền tảng giám sát và nhật ký;
• Dịch vụ callback của bên thứ ba.

Email đối ngoại, hệ thống quản trị, hệ thống nội bộ và dịch vụ giao dịch nên dùng mạng và địa chỉ công khai riêng biệt. Một hệ thống ít quan trọng hơn bị lộ không được kéo theo IP máy chủ gốc của hệ thống giao dịch.

Môi trường thử nghiệm và tên miền tạm làm lộ máy chủ đang hoạt động

Nhóm phát triển có thể đã tạo tên miền thử nghiệm, triển khai theo giai đoạn, API tạm hoặc phiên bản cũ. Nếu bản ghi không được xóa sau khi đưa hệ thống vào hoạt động, chúng có thể vẫn trỏ về máy chủ gốc đang chạy.

Những trường hợp thường gặp gồm:

• Tên miền thử nghiệm trỏ trực tiếp đến IP hệ thống đang hoạt động;
• Tên miền triển khai theo giai đoạn không đi qua CDN;
• Tên miền dành cho phiên bản ứng dụng cũ vẫn hoạt động;
• Tên miền gỡ lỗi do đội vận hành tạo tạm nhưng bị giữ lại lâu dài;
• Dịch vụ giám sát bên thứ ba sử dụng tên miền kết nối trực tiếp;
• Có thể truy cập tên miền của máy chủ gốc dự phòng từ Internet.

Các điểm truy cập này hầu như không có người dùng hợp lệ nên đội bảo mật dễ bỏ qua.

Cách xử lý

Lập danh mục đầy đủ các tên miền và kiểm tra định kỳ bản ghi DNS, chứng chỉ, bộ cân bằng tải trên đám mây và IP công khai.

Ngừng sử dụng tên miền tạm ngay khi hoàn thành công việc. Giám sát nội bộ và kiểm tra tình trạng hệ thống nên đi qua mạng chuyên dụng, địa chỉ riêng hoặc điểm truy cập có xác thực chặt chẽ. Đừng giữ một tên miền kết nối trực tiếp công khai chỉ để tiện giám sát.

Kết nối từ máy chủ gốc đến dịch vụ bên thứ ba làm lộ IP nguồn

Máy chủ gốc của nền tảng tài chính có thể chủ động kết nối đến dịch vụ thanh toán, nền tảng email, nhà cung cấp dữ liệu thị trường, dịch vụ SMS hoặc hệ thống quản trị rủi ro.

Nếu lưu lượng đi ra và dịch vụ tiếp nhận lưu lượng đi vào dùng cùng một IP công khai, địa chỉ đó có thể xuất hiện trong nhật ký, thông báo lỗi hoặc cấu hình callback của bên thứ ba.

Khi hệ thống bên thứ ba, đối tác có bảo mật yếu hoặc tài khoản liên quan bị xâm nhập, IP máy chủ gốc cũng có nguy cơ bị lộ.

Cách xử lý

Tách IP tiếp nhận kết nối khỏi IP dùng cho kết nối đi ra của máy chủ gốc.

Máy chủ đang hoạt động có thể truy cập dịch vụ bên thứ ba qua NAT gateway hoặc proxy đầu ra riêng. Khi đó, ngay cả khi IP nguồn bị ghi lại, nó cũng không trực tiếp chỉ ra địa chỉ máy chủ gốc tiếp nhận lưu lượng người dùng.

Endpoint callback công khai cũng nên dùng tên miền CDN hoặc cổng bảo mật để bên thứ ba không kết nối thẳng tới máy chủ giao dịch cốt lõi.

Trang lỗi và response header tiết lộ cấu trúc mạng

Khi máy chủ trả lỗi, phản hồi có thể chứa:

• Địa chỉ máy chủ nội bộ;
• Tên máy chủ upstream;
• Số cổng thực;
• Thông tin về reverse proxy;
• Đường dẫn gỡ lỗi;
• Vùng triển khai trên đám mây;
• Tên dịch vụ backend.

Dù không trực tiếp chứa IP công khai, những chi tiết này vẫn có thể giúp kẻ tấn công từng bước dựng lại kiến trúc hệ thống.

Cách xử lý

Trong môi trường đang hoạt động, hãy tắt thông tin gỡ lỗi, thống nhất cách hiển thị trang lỗi và loại bỏ các response header không cần công khai.

CDN, reverse proxy và API gateway chỉ nên trả về thông tin lỗi cần thiết cho người dùng. Stack trace chi tiết, địa chỉ upstream và tuyến nội bộ chỉ nên lưu trong hệ thống nhật ký được bảo vệ.

Làm thế nào để bảo vệ IP máy chủ gốc hiệu quả?

Bảo vệ máy chủ gốc không chỉ là đổi DNS một lần. Cần thiết lập mô hình truy cập khép kín như sau:

Người dùng trên Internet chỉ truy cập CDN07; chỉ CDN07 được kết nối đến máy chủ gốc.

Để thực hiện mô hình này, cần hoàn thành các bước quan trọng sau.

Bước 1: Kiểm kê toàn bộ điểm truy cập công khai

Trước hết, hãy lập danh mục đầy đủ tài sản có thể truy cập từ Internet, bao gồm:

• Website và trang dành cho thiết bị di động;
• Tên miền phục vụ tài nguyên tĩnh;
• API đăng nhập và xác thực;
• API tra cứu dữ liệu thị trường;
• Tên miền phân phối dữ liệu thị trường qua WebSocket;
• API tài khoản và vị thế nắm giữ;
• API đặt lệnh, hủy lệnh và tra cứu lệnh;
• Chức năng tải hồ sơ KYC lên;
• Gói cài đặt và dịch vụ cập nhật ứng dụng;
• API callback cho bên thứ ba;
• Hệ thống quản trị và điểm truy cập của đội vận hành;
• Máy chủ gốc chính, máy chủ gốc dự phòng và trung tâm khôi phục sau thảm họa.

Chỉ khi biết mọi điểm truy cập đang hoạt động, nền tảng mới xác định được lưu lượng nào cần đi qua CDN chống DDoS và dịch vụ nào cần chuyển sang truy cập riêng.

Đừng chỉ hỏi “tên miền chính đã dùng CDN chưa”; hãy kiểm tra “còn đường nào cho phép kết nối trực tiếp đến máy chủ gốc không”.

Bước 2: Đưa mọi dịch vụ công khai qua CDN07

Với dịch vụ HTTP và HTTPS, có thể dùng bản ghi DNS hoặc CNAME để đưa lưu lượng vào CDN07.

Tại biên, CDN07 xử lý:

• Kết nối HTTPS;
• Bộ nhớ đệm cho nội dung tĩnh;
• Chuyển tiếp yêu cầu API động;
• Proxy WebSocket;
• Lọc lưu lượng DDoS;
• Phát hiện HTTP flood;
• Bảo vệ ứng dụng bằng WAF;
• Giới hạn tần suất yêu cầu API;
• Phát hiện bot và hành vi bất thường.

Người dùng nhìn thấy địa chỉ điểm biên chống DDoS của CDN07, không phải địa chỉ máy chủ gốc của nền tảng tài chính.

Không thể áp dụng một bộ quy tắc giống hệt nhau cho mọi dịch vụ. Website, dữ liệu thị trường, tài khoản và API giao dịch cần các chính sách riêng về bộ nhớ đệm, thời gian chờ, giới hạn tần suất và bảo vệ.

Bước 3: Chuyển sang IP máy chủ gốc mới chưa từng công khai

Nếu IP máy chủ gốc từng phục vụ truy cập trực tiếp từ Internet, hãy coi địa chỉ đó đã bị lộ.

Đừng chỉ đặt IP cũ phía sau CDN. Hãy thực hiện theo trình tự:

1. Kết nối với CDN07 và kiểm thử dịch vụ;
2. Chuẩn bị IP máy chủ gốc mới;
3. Chuyển dịch vụ đang hoạt động sang địa chỉ mới;
4. Cập nhật cấu hình kết nối về máy chủ gốc trên CDN07;
5. Xác nhận máy chủ gốc mới chỉ chấp nhận kết nối từ CDN;
6. Ngừng phục vụ hệ thống đang hoạt động trên IP cũ;
7. Theo dõi xem IP cũ còn bị tấn công hay không.

Không để địa chỉ máy chủ gốc mới xuất hiện trong DNS công khai, mã ứng dụng, cấu hình email, tên miền giám sát hoặc cấu hình callback của bên thứ ba.

Nếu lưu lượng tấn công vẫn tập trung vào IP cũ trong khi máy chủ gốc mới hoạt động ổn định, việc chuyển đổi đã giúp cắt đứt đường lộ IP trước đây.

Bước 4: Chỉ cho phép CDN07 kết nối đến máy chủ gốc qua tường lửa

Giữ kín IP làm giảm khả năng máy chủ gốc bị tìm thấy. Danh sách IP được phép trên tường lửa mới là yếu tố then chốt ngăn việc bỏ qua CDN.

Máy chủ gốc cần từ chối mọi truy cập Internet không cần thiết và chỉ cho phép:

• Các địa chỉ CDN07 dùng để kết nối về máy chủ gốc;
• Dịch vụ nội bộ cần thiết;
• Mạng vận hành đã được cấp quyền;
• Lưu lượng giữa cơ sở dữ liệu chính, dự phòng và các hệ thống nghiệp vụ;
• Hệ thống giám sát đã được xác minh.

Ngay cả khi kẻ tấn công tình cờ tìm ra IP mới, chúng cũng không thể truy cập trực tiếp website hoặc API từ địa chỉ nguồn không có trong danh sách cho phép.

Sau khi cấu hình tường lửa, hãy kiểm tra cả hai chiều: không thể truy cập trực tiếp IP máy chủ gốc từ mạng Internet thông thường, trong khi CDN07 vẫn kết nối về máy chủ gốc bình thường.

Bước 5: Xác thực yêu cầu từ CDN đến máy chủ gốc

Không nên chỉ dựa vào danh sách IP được phép. Có thể bổ sung các biện pháp xác thực cho yêu cầu từ CDN đến máy chủ gốc, chẳng hạn:

• Mã hóa kết nối đến máy chủ gốc bằng HTTPS;
• Kiểm tra chứng chỉ dùng cho kết nối giữa CDN và máy chủ gốc;
• Sử dụng xác thực TLS hai chiều;
• Xác minh header chuyên dụng trong yêu cầu đến máy chủ gốc;
• Kiểm tra chữ ký yêu cầu đối với API nhạy cảm;
• Từ chối Host header và SNI không được nhận diện;
• Định kỳ xoay vòng khóa xác thực máy chủ gốc.

Header chuyên dụng bổ sung một lớp bảo vệ nhưng không thay thế danh sách IP được phép trên tường lửa. Header thông thường có thể bị giả mạo. Hãy kết hợp giới hạn nguồn kết nối ở tầng mạng với xác thực để tạo ranh giới tin cậy cho máy chủ gốc.

Bước 6: Tách hệ thống quản trị khỏi điểm truy cập giao dịch

Không nên cho phép truy cập trực tiếp hệ thống quản trị vận hành, quản trị cơ sở dữ liệu, nền tảng nhật ký hoặc đăng nhập máy chủ từ xa qua tên miền CDN công khai.

Các phương thức truy cập an toàn hơn gồm:

• VPN doanh nghiệp;
• Hệ thống truy cập Zero Trust;
• Máy chủ trung gian quản trị (bastion host);
• Mạng quản trị chuyên dụng;
• Proxy xác thực;
• Xác thực đa yếu tố;
• Kiểm tra mức độ tin cậy của thiết bị.

Mặt phẳng quản trị phải tách khỏi dịch vụ giao dịch dành cho người dùng. Khi website công khai bị tấn công, đội vận hành vẫn cần truy cập công cụ quản trị để xử lý sự cố. Nếu tài khoản quản trị gặp vấn đề, điểm truy cập hệ thống giao dịch cũng không được vì thế mà bị lộ trực tiếp.

Bước 7: Bảo vệ độ tin cậy của thông tin IP người dùng thực

Sau khi triển khai CDN, máy chủ gốc thường thấy địa chỉ kết nối của CDN thay vì IP thực của người dùng. Tuy nhiên, nền tảng tài chính vẫn cần IP khách truy cập để đánh giá rủi ro đăng nhập, nhận diện thiết bị và kiểm toán bảo mật.

CDN07 có thể chuyển IP khách truy cập thực đến máy chủ gốc qua header được kiểm soát. Máy chủ gốc chỉ được tin header đó khi yêu cầu đến từ địa chỉ CDN07 dùng để kết nối về máy chủ gốc.

Nếu bất kỳ yêu cầu nào từ Internet cũng có thể tự khai báo header “IP thực”, kẻ tấn công có thể giả mạo thông tin nhận diện và làm sai lệch kết quả đánh giá rủi ro, nhật ký kiểm toán.

Vì vậy, hãy thiết lập quan hệ tin cậy như sau:

• Lưu lượng từ Internet chỉ đến CDN07;
• Máy chủ gốc chỉ chấp nhận yêu cầu từ các địa chỉ kết nối của CDN07;
• Chỉ tin header IP khách truy cập do CDN07 chuyển đến;
• API gateway ghi nhận thống nhất IP khách truy cập, tài khoản và thông tin thiết bị.

Bước 8: Áp dụng cùng ranh giới bảo mật cho máy chủ gốc chính và dự phòng

Một số nền tảng bảo vệ máy chủ gốc chính nhưng để máy chủ dự phòng có thể truy cập trực tiếp từ Internet.

Nếu tìm thấy máy chủ dự phòng, kẻ tấn công có thể đánh thẳng vào đó, thậm chí khiến hệ thống chính chuyển sang môi trường khôi phục sau thảm họa đã bị làm bão hòa bởi lưu lượng tấn công.

Máy chủ gốc chính, máy chủ gốc dự phòng và trung tâm khôi phục sau thảm họa đều cần:

• Bảo vệ IP thực;
• Chỉ cho phép kết nối từ CDN07 đến máy chủ gốc;
• Dùng HTTPS hoặc TLS hai chiều;
• Đóng các cổng không cần thiết;
• Áp dụng cùng tiêu chuẩn bảo mật;
• Tập trung giám sát và cảnh báo;
• Định kỳ kiểm thử chuyển đổi dự phòng.

Không thể giảm mức bảo vệ cho hệ thống dự phòng chỉ vì ít sử dụng. Hệ thống đó phải luôn sẵn sàng tiếp quản các dịch vụ cốt lõi.

Bảo vệ lưu lượng FIX, TCP và các giao thức ngoài HTTP của nền tảng chứng khoán

Ngoài website và REST API, một số nền tảng chứng khoán còn dùng FIX, giao thức TCP riêng hoặc các kết nối lớp 4 duy trì lâu.

CDN HTTP thông thường không thể proxy loại lưu lượng này. Nếu dịch vụ vẫn mở trực tiếp ra Internet, kẻ tấn công có thể tìm ra hoặc tấn công trung tâm dữ liệu cốt lõi qua chính đường đó.

Tùy theo giao thức, CDN07 có thể cấu hình proxy TCP chống DDoS, chuyển tiếp lớp 4 và điểm truy cập bảo vệ riêng. Người dùng hoặc tổ chức đối tác kết nối trước đến địa chỉ được chống DDoS, sau đó lưu lượng được chuyển qua đường truyền được bảo vệ đến máy chủ thực.

Với API giao dịch dành cho tổ chức dùng FIX hoặc giao thức tương tự, cần kết hợp thêm:

• Danh sách địa chỉ cố định của đối tác được phép kết nối;
• Xác thực chứng chỉ hai chiều;
• Đường truyền riêng hoặc đường hầm mã hóa;
• Phân tách cổng và vùng mạng;
• Xác thực ở cấp phiên;
• Giới hạn số kết nối và tần suất yêu cầu.

Cần thiết kế riêng phương án bảo vệ website cho người dùng phổ thông và kênh giao dịch dành cho tổ chức.

Những quan niệm sai thường gặp về bảo vệ IP máy chủ gốc

Quan niệm 1: Trỏ tên miền về CDN là máy chủ gốc tự động an toàn

Nếu máy chủ gốc vẫn nhận kết nối từ mọi địa chỉ Internet, kẻ tấn công tìm được IP vẫn có thể bỏ qua CDN.

Quan niệm 2: Giữ IP cũ để có thể quay lại khi xảy ra sự cố

Nếu IP cũ vẫn dẫn đến hệ thống mới, nó trở thành đường dự phòng để kẻ tấn công vượt qua mạng chống DDoS. Phương án quay lại nên dùng tên miền và điểm biên dự phòng đã được bảo vệ, thay vì máy chủ gốc cũ công khai.

Quan niệm 3: Chỉ cần bảo vệ website, không cần bảo vệ API

Với nền tảng tài chính, API và hệ thống dữ liệu thị trường có thể quan trọng hơn website. Kẻ tấn công có thể bỏ qua trang chủ và nhắm thẳng vào API đăng nhập, dữ liệu thị trường hoặc giao dịch.

Quan niệm 4: Chỉ cần một header yêu cầu bí mật

Header có thể bị giả mạo. Cần kết hợp danh sách IP được phép trên tường lửa máy chủ gốc, kết nối HTTPS từ CDN đến máy chủ gốc và cơ chế xác thực cần thiết.

Quan niệm 5: Chưa ai biết IP máy chủ gốc nên chưa cần thay

Nếu IP từng được công khai, không thể mặc định rằng không ai lưu lại. Lịch sử DNS, dịch vụ giám sát, ứng dụng và hệ thống bên thứ ba có thể vẫn giữ địa chỉ đó.

Quan niệm 6: Năng lực chống DDoS đủ lớn thì không cần ẩn IP

Dù năng lực giảm thiểu tấn công lớn đến đâu, hệ thống chỉ lọc được lưu lượng đi qua điểm biên bảo vệ. Nếu cuộc tấn công đi thẳng đến máy chủ gốc, năng lực ở biên không phát huy tác dụng.

Cách kiểm tra IP máy chủ gốc đã thực sự được bảo vệ hay chưa

Sau khi triển khai, hãy xác minh độc lập thay vì chỉ dựa vào trạng thái “Kết nối thành công” trên bảng điều khiển CDN.

Các mục cần kiểm tra gồm:

• Tất cả tên miền công khai có trỏ về CDN07 không;
• Tên miền cũ hoặc tạm có còn trỏ về máy chủ gốc mới không;
• Ứng dụng có IP hoặc địa chỉ kết nối trực tiếp được ghi cố định không;
• Toàn bộ lưu lượng API và WebSocket có đi qua điểm biên chống DDoS không;
• Dịch vụ email, hỗ trợ và tải xuống có dùng chung IP với máy chủ gốc giao dịch không;
• Có thể truy cập trực tiếp máy chủ gốc từ mạng Internet thông thường không;
• Yêu cầu thiếu Host header đúng hoặc thông tin xác thực có bị từ chối không;
• Tường lửa máy chủ gốc có chỉ cho phép kết nối từ CDN07 không;
• Cổng quản trị có mở ra Internet không;
• Máy chủ gốc chính và dự phòng có áp dụng cùng chính sách bảo vệ không;
• IP khách truy cập thực có được ghi chính xác trong nhật ký không;
• Dịch vụ trên IP máy chủ gốc cũ đã ngừng hoàn toàn chưa.

Bảo vệ IP máy chủ gốc không phải công việc cấu hình một lần. Thêm tên miền, phát hành phiên bản ứng dụng mới, chuyển trung tâm dữ liệu hoặc tích hợp dịch vụ bên thứ ba đều có thể tạo ra đường lộ IP mới.

CDN07 bảo vệ máy chủ gốc của hệ thống giao dịch tài chính như thế nào?

CDN07 không chỉ đặt một lớp proxy trước website tài chính. Dịch vụ giúp thiết lập ranh giới bảo mật từ điểm truy cập công khai đến máy chủ gốc.

Với nền tảng tài chính và chứng khoán, CDN07 có thể cung cấp:

• Bảo vệ tập trung điểm truy cập website, ứng dụng, API và WebSocket qua mạng chống DDoS;
• Lọc lưu lượng DDoS và chống HTTP flood;
• WAF và kiểm soát truy cập API;
• Tăng tốc yêu cầu động và kết nối xuyên biên giới;
• Bảo vệ IP máy chủ gốc;
• Danh sách địa chỉ được phép kết nối về máy chủ gốc;
• Kết nối đến máy chủ gốc được mã hóa bằng HTTPS;
• Xác thực yêu cầu đến máy chủ gốc;
• Kiểm tra tình trạng nhiều máy chủ gốc;
• Tự động chuyển đổi dự phòng;
• Nhật ký và cảnh báo tấn công theo thời gian thực;
• Kết nối chống DDoS cho TCP và các dịch vụ ngoài HTTP.

Nền tảng có thể giữ nguyên máy chủ hiện có tại Mỹ, Hồng Kông, Singapore hoặc khu vực khác và chuyển lưu lượng từng bước qua tên miền. CDN07 có thể thiết lập quy tắc riêng về bộ nhớ đệm, tăng tốc yêu cầu động, bảo vệ và kết nối đến máy chủ gốc cho website, dữ liệu thị trường, đăng nhập, tài khoản và giao dịch.

Với IP cũ đã lộ, CDN07 có thể phối hợp cùng nền tảng thay địa chỉ máy chủ gốc, chuyển lưu lượng theo từng giai đoạn và siết quyền truy cập trên tường lửa. Không cần chuyển toàn bộ dịch vụ giao dịch cùng lúc: có thể bắt đầu từ website và tài nguyên tĩnh, rồi lần lượt đưa dữ liệu thị trường, API và WebSocket vào mạng bảo vệ.

Mục tiêu không chỉ là khiến tên miền không tiết lộ máy chủ gốc, mà là hoàn thiện chuỗi bảo vệ sau:

Lưu lượng tấn công được lọc tại điểm biên chống DDoS của CDN07; yêu cầu hợp lệ đi qua đường kết nối xuyên biên giới được bảo vệ đến máy chủ gốc; máy chủ thực từ chối mọi kết nối Internet chưa được cấp quyền.

Bảo vệ cả hệ thống giao dịch

Rủi ro lớn với nền tảng tài chính và chứng khoán là cho rằng hệ thống đã an toàn chỉ vì đã triển khai CDN.

Chỉ cần một tên miền cũ, bản ghi API, địa chỉ dự phòng trong ứng dụng hoặc máy chủ thử nghiệm còn làm lộ IP thực, kẻ tấn công có thể bỏ qua điểm biên chống DDoS và nhắm thẳng vào hệ thống giao dịch.

Để bảo vệ máy chủ gốc hiệu quả, cần thực hiện đồng thời:

• Đưa toàn bộ lưu lượng công khai qua CDN07;
• Thay IP máy chủ gốc đã lộ;
• Chỉ cho phép CDN07 kết nối từ Internet đến máy chủ gốc;
• Áp dụng biện pháp bảo vệ phù hợp cho website, ứng dụng, API và WebSocket;
• Tách biệt hoàn toàn mặt phẳng quản trị khỏi dịch vụ giao dịch cho người dùng;
• Áp dụng cùng chính sách bảo mật cho máy chủ chính và dự phòng;
• Liên tục giám sát nguy cơ lộ IP mới.

Ngăn kẻ tấn công tìm thấy máy chủ gốc chỉ là bước đầu. Bảo vệ thực sự hiệu quả khi chúng vẫn không thể kết nối trực tiếp, ngay cả nếu tình cờ phát hiện IP mới.

Với nền tảng tài chính không thể chấp nhận ngừng dịch vụ, gián đoạn dữ liệu thị trường hay API giao dịch bị lỗi, giá trị của CDN chống DDoS không chỉ nằm ở ứng phó khi cuộc tấn công đã xảy ra. Điều quan trọng là loại bỏ những điểm có thể bị đánh trực tiếp trước khi cuộc tấn công bắt đầu.