Trong một cluster có nhiều nút có thể kết hợp cả nút chủ động và nút thụ
động. Trong những mơ hình loại này việc quyết định một nút được cấu hình là chủ động hay thụ động rất quan trọng. Để hiểu lý do tại sao, hãy xem xét các tình huống
CHƯƠNG 4: CÁC GIẢI PHÁP BẢO MẬT CHO HỆ THỐNG
- Nếu một nút chủ động bị sự cố và có một nút thụ động đang sẵn sàng, các
ứng dụng và dịch vụ đang chạy trên nút hỏng có thể lập tức được chuyển sang nút
thụ động. Vì máy chủ đóng vai trị nút thụ động hiện tại chưa chạy ứng dụng hay dịch vụ gì cả nên nó có thể gánh tồn bộ cơng việc của máy chủ hỏng mà khơng ảnh
hưởng gì đến các ứng dụng và dịch vụ cung cấp cho người dùng cuối (Ngầm định
rằng các các máy chủ trong cluster có cấu trúc phần cứng giống nhau).
- Nếu tất cả các máy chủ trong cluster là chủ động và có một nút bị sự cố, các
ứng dụng và dịch vụ đang chạy trên máy chủ hỏng sẽ phải chuyển sang một máy
chủ khác cũng đóng vai trị nút chủ động. Vì là nút chủ động nên bình thường máy chủ này cũng phải đảm nhận một số ứng dụng hay dịch vụ gì đó, khi có sự cố xảy ra thì nó sẽ phải gánh thêm cơng việc của máy chủ hỏng. Do vậy để đảm bảo hệ thống hoạt động bình thường kể cả khi có sự cố thì máy chủ trong cluster cần phải có cấu hình dư ra đủ để có thể gánh thêm khối lượng công việc của máy chủ khác khi cần.
- Trong cấu trúc cluster mà mỗi nút chủ động được dự phòng bởi một nút thụ
động, các máy chủ cần có cấu hình sao cho với khối lượng cơng việc trung bình
chúng sử dụng hết khoảng 50% CPU và dung lượng bộ nhớ. Trong cấu trúc cluster mà số nút chủ động nhiều hơn số nút bị động, các máy chủ cần có cấu hình tài nguyên CPU và bộ nhớ mạnh hơn nữa để có thể xử lý được khối lượng cơng việc cần thiết khi một nút nào đó bị hỏng.
Các nút trong một cluster thường là một bộ phận của cùng một vùng (domain) và có thể được cấu hình là máy điều khiển vùng (domain controllers) hay máy chủ thành viên. Lý tưởng nhất là mỗi cluster nhiều nút có ít nhất hai nút làm
máy điều khiển vùng và đảm nhiệm việc failover đối với những dịch vụ vùng thiết
yếụ Nếu không như vậy thì khả năng sẵn sàng của các tài nguyên trên cluster sẽ bị phụ thuộc vào khả năng sẵn sàng của các máy điều khiển trong domain.
4.2.7 Network Load Balancing của Goole và Yahoo! trong việc phòng chống DoS DoS
4.2.7.1 Cơ chế chung
Khi connect tới server, Round Robin DNS Load Balancing sẽ phân giải domain thành nhiều địa chỉ IP khác nhau và sử dụng cấp thứ 1của load balancing là gửi tới các cluster khác nhau, các cluster này thực chất là các server cache của nhau, dữ liệu của chúng được đồng bộ lẫn nhau thông qua giao thức HTTP.
Mỗi server cluster có hàng ngàn server để gửi các query tới web server Server load balancer lấy request của user và chuyển tiếp nó tới 1 trong các
web servers nhờ vào Squid proxy servers
Squid proxy server nhận request của client load balancer và trả về kết quả nếu có trong cache ngược lại thì chuyển tiếp tới web servers
Web server định vị tọa độ thực thi các queries của user và định dạng kết quả
CHƯƠNG 4: CÁC GIẢI PHÁP BẢO MẬT CHO HỆ THỐNG
4.2.7.2 Giải pháp thực tế của Google
Sử dụng các NetScaler 9800 Secure Application Switches
NetScaler có thể tải hàng trăm megabits trong 1 giây của tầng 4 đến tầng 7
lưu lượng sử dụng
Tại dữ liệu trung tâm, các máy chủ sử dụng các Apache Server và các ứng
dụng Web Server do chính Google thiết kế
Cách thức NetScaler phịng chống DoS là nó đóng vai trị như 1 firewall dự phòng của hệ thống firewall của công ty
Các load balancer được thiết kế chỉ chấp nhận các luồng thông tin qua cổng
80, nếu thông tin không đi qua một cổng được chỉ định, hoặc không bắt nguồn từ 1 IP, chúng sẽ bị hủy lập tức
Với tính năng "SYN cookies", NetScaler có thể đáp ứng các SYN messages - packets khởi đầu cho 1 TCP/IP connection(được sử dụng trong "SYN flood" DoS attack) mà không xung đột với tài ngun của chính nó
Với NetScaler, Google phòng chống được DoS attack từ tầng 4, đối với tầng
7 đã có cơng cụ được cài trên các Web server xử lý
Thiết lập kiến trúc cân bằng tải cho các server trọng điểm sẽ làm gia tăng thời gian chống chọi của hệ thống với cuộc tấn công ĐoS
4.3 Phương pháp bảo mật cho bản tin báo hiệu của hệ thống
Bản tin báo hiệu là một thành phần rất quan trọng trong các cuộc gọi VoIP của hệ thống Call Center, vì nó chứa các thơng tin liên quan đến người sử dụng, các thơng số để thiết lập và giải phóng cuộc gọi nên nó thường trở thành mục tiêu tấn cơng, cũng vì thế đã có nhiều phương pháp bảo mật cho các bản tin báo hiệu nàỵ
4.3.1 Phương pháp chứng thực 2 chiều TLS (Transport Layer Security)
TLS là một giao thức bảo mật ở tầng chuyển vận (lớp 4 trong mơ hình OSI),
được định nghĩa trong RFC 4346, nó cung cấp khả năng chứng thực chung cho cả
client và server, tính tin cậy cũng như toàn vẹn của các bản tin. Giao thức này được chia làm 2 giao thức nhỏ: TLS bản ghi ( TLS Record Protocol) và TLS bắt tay (TLS
Handshake Protocol).
4.3.1.1 TLS bản ghi ( hay TLS RP - TLS Record Protocol )
Nhằm mục đích duy trì một kết nối bảo mật giữa hai điểm (ví dụ client và
server). Quá trình thương lượng về các cơng cụ bảo mật (ví dụ phương pháp mã hóa
hay trao đổi khóa) cho kết nối được thực hiện bởi TLS bắt tay hay TLS HP.
4.3.1.2 TLS bắt tay (hay TLS HP – TLS Handshake Protocol )
Được sử dụng để chứng thực cả client và server và thương lượng cách thức
bảo mật giữa client và server (ví dụ thuật tốn mã hóa và keys). Q trình bắt tay (TLS Handshake) phải được thực hiện thành cơng trước khi q trình truyền dẫn dữ liệu diễn rạ Sau đây là một ví dụ về TLS Handshake:
CHƯƠNG 4: CÁC GIẢI PHÁP BẢO MẬT CHO HỆ THỐNG