Kiến trúc hệ thống mới

Một phần của tài liệu Giảm thiểu ảnh hưởng của các tấn công từ chối dịch vụ phân tán vào các website (Trang 57)

3.3.1 Kiến trúc cơ bản

Kế thừa kiến trúc từ mô hình xử lý của Doron [4], chúng tôi xây dựng kiến trúc mới với các thành phần xử lý điều kiện mới và mô hình dữ liệu khởi tạo cũng đƣợc thay đổi. Cụ thể các thành phần khác nhau giữa hai hệ thống đƣợc thống kê thông qua bảng bên dƣới:

Các thành phần thay đổi Phƣơng pháp của Doron [4] Phƣơng pháp của chúng tôi Dữ liệu thống kê hành vi ngƣời dùng Sử dụng thống kê của Choi&Lim(1999) Sử dụng thống kê của Lee&Gupta(2012)

Cơ chế bẫy thời gian Có Có nhƣng cách xử lý

khác – tham khảo 3.2.1

Bẫy tần suất gửi tin Không có Có

Trạng thái tối thiểu Có Có nhƣng thay điều kiện

đi vào trạng thái tối thiểu

Hàng đợi ƣu tiên Có Có và giống Doron

Lƣu lƣợng hợp lệ hỗ trợ Ajax

Không Có

Cơ chế tăng giảm điểm đối với các kết nối

Không Có

58 Kiến trúc tổng thể của bộ lọc TLF01 chúng tôi thiết kế:

Hình 29 Kiến trúc bộ xử lý lọc thế hệ mới Trong đó:

- ĐK1: kiểm tra điều kiện bẫy thời gian - ĐK2: kiểm tra điều kiện bẫy tần suất

- ĐK3: kiểm tra điều kiện bẫy trạng thái tối thiểu

- Tăng giảm điểm: Là thành phần chọn giá trị ƣu tiên dựa theo kết quả đầu ra của các biểu thức điều kiện.

Khi giá trị đầu vào là những gói tin đi vào bộ lọc, chúng sẽ đƣợc kiểm tra dựa trên các điều kiện đã đƣa ra ở phần 3.2. Sau khi đi qua các luật kiểm tra này, gói tin sẽ đƣợc gán nhãn và trọng số ƣu tiên thuộc một trong hai dạng: Gói tin có mức ƣu tiên cao (H) hoặc gói tin có mức ƣu tiên thấp (L) để đi tiếp vào hàng đợi ƣu tiên. Tại hàng đợi ƣu tiên sẽ thực hiện việc quyết định chuyển tiếp gói tin đến địa chỉ đích là máy chủ Web. Với những gói tin đang chờ ở hàng đợi ƣu tiên cao sẽ đƣợc ƣu tiên chuyển tiếp trƣớc và sẽ đƣợc server trả lời trƣớc. Những gói tin ở hàng đợi ƣu tiên thấp sẽ phải đợi cho đến khi các gói tin ở hàng đợi cao đã chuyển xong hoặc không còn gói tin nào nữa thì mới đƣợc phép chuyển tiếp. Nếu trong trƣờng hợp yêu cầu chuyển tiếp trong bộ nhớ của cả High Queue và Low Queue đều lớn và không thể nhận đƣợc thêm gói tin nữa thì hàng đợi ƣu tiên Low Queue sẽ phải tìm cách loại bỏ

59 dần các gói tin đang lƣu tạm trong đó để dành bộ nhớ phục vụ những gói tin tiếp theo.

3.3.2 So sánh với các kiến trúc khác

Để hình dung kiến trúc chúng tôi xây dựng tƣơng quan với các giải pháp đã nghiên cứu, chúng tôi mô tả kiến trúc nguyên gốc của phƣơng pháp mà chúng tôi từ đó cải tiến thêm hoặc thay đổi một số thành phần xử lý. Sự khác biệt cơ bản ở các kiến trúc này là cách sắp đặt các thành phần xử lý và bộ kiểm soát điều kiện.

Thành phần Phƣơng pháp của Doron [4] Phƣơng pháp của chúng tôi TLF01 Phƣơng pháp khác [12]

Bẫy thời gian Có Có Có

Bẫy tần suất Không Có Không

Bẫy trạng thái tối thiểu Có Có Không Sử dụng cơ chế RED chống tấn công dạng Low- rate Không Có Có Sử dụng hàng đợi ƣu tiên 2 hàng đợi High Q và Low Q 2 hàng đợi High Q và Low Q 3 hàng đợi High Q, Low Q, Min Q Chống hiệu quả các dạng tấn công - Simple Flood - HighBurst Slow - LowBurst Fast - Simple Flood - HighBurst Slow - LowBurst Fast - Low-rate - Random attack - Simple Flood - HighBurst Slow - LowBurst Fast - Low-rate Tiến hành kiểm tra

rồi đến lọc

Đúng Đúng Không đúng -

bị lặp bộ kiểm tra điều kiện

Khởi đầu tác giả Doron đã đƣa ra kiến trúc lý thuyết khi tiến hành xây dựng WDA [4], một phƣơng pháp đƣợc chứng minh lý thuyết và mô phỏng là hiệu quả

60 trong trƣờng hợp các đặc tính dữ liệu tuân theo đúng các kết quả thống kê của mô hình Choi&Lim [15].

Hình 30 Kiến trúc WDA chống tấn công các dạng tấn công

Tuy nhiên kiến trúc WDA bộc lộ nhiều điểm hạn chế khi không thể chống hiệu quả dạng tấn công Low-rate, nếu mô hình dữ liệu không tuân theo mô hình ON – OFF thì căn cứ tính toán và xác định ngƣỡng lƣu lƣợng mỗi phiên truy vấn là không còn chính xác dẫn đến sai số lớn trong việc phân biệt các dạng truy vấn thông thƣờng của ngƣời dùng với các dạng lƣu lƣợng do kẻ tấn công sinh ra.

Cũng có một số phƣơng pháp giải quyết hạn chế của WDA trƣờng hợp Low rate Attack hay “Low-burst-slow”. Hình 30 minh họa kiến trúc của một tác giả khác khi đề xuất sử dụng cơ chế Robust RED [12] vào thuật toán phát hiện tấn công Low- burst slow.

Hình 31 Kiến trúc của khối RWDA chống tấn công Low-burst-slow hiệu quả Điểm khác biệt so với WDA [4] là tác giả đã chèn thêm một hàng đợi có trọng số ƣu tiên siêu cao Super Q. Cụ thể ý tƣởng là thêm bộ lọc và phát hiện đặt trƣớc Policer trong WDA và sau khi một gói tin bị loại bỏ bởi High Queue, chỉ những gói

61 tin nào đến trong khoảng thời gian từ 1 giây đến AOP_Sus_TH giây mới có thể vào đƣợc hàng đợi Super queue. Nếu nhƣ kẻ tấn công chủ động giảm thời gian nghỉ xuống mức nhỏ hơn AOP_Sus_TH giây thì cũng chỉ có gói tin đầu tiên là vào đƣợc hàng đợi Super queue, còn các gói tin còn lại của phiên đó vẫn sẽ phải qua sự kiểm tra của khối Policer mới có thể vào đƣợc các hàng đợi.. Tuy nhiên điều này có thể dẫn đến hệ quả là gói tin đầu tiên của mỗi phiên của các hình thức tấn công có giai đoạn ON-OFF nhƣ “High-burst slow”, “Low-burst fast”… sẽ có khả năng cũng vào đƣợc hàng đợi này, do lƣợng gói tin bị hủy của các hình thức tấn công trên là khá lớn. Cũng nhƣ điểm yếu cố hữu của phƣơng pháp này đó là phải thực hiện kiểm tra hai lần. Bộ lọc và phát hiện thực hiện kiểm tra nhanh gói tin trƣớc rồi Policer lại thực hiện kiểm tra gói tin đó với các điều kiện khác. Rõ ràng phép kiểm tra lại này sẽ làm tăng độ trễ khi xử lý, tăng bộ nhớ dùng để kiểm tra lên gấp đôi.

3.4 Thiết kế giải thuật 3.4.1 Giải thuật 3.4.1 Giải thuật

Dựa trên ý tƣởng thuật toán gốc đƣợc mô tả trong phƣơng pháp lọc của Doron [4], chúng tôi tiến hành cải tiến: thay đổi cách hành xử của lƣu lƣợng hợp lệ, thay thế điều kiện kiểm tra cũ bằng điều kiện kiểm tra mới, bổ sung các điều kiện kiểm tra mở rộng, cách đánh giá giá trị ƣu tiên mới – chi tiết trong bảng 1. Những phần mã lệnh đóng vai trò chuyển tiếp gói tin sau khi đã quyết định, chúng tôi giữ nguyên nhƣ mã nguồn gốc.

Thuật toán cải tiến có thể đƣợc minh họa cơ bản nhƣ sau:

Procedure TLF01( packet *p) // giá trị đầu vào là gói tin cần kiểm tra

62 TE = Tend – Tstart; //(tham khảo công thức ở 3.2.1) , Điều kiện 1 - kiểm tra thời gian reading time

Davg(i) = DMax * F(i); // (tham khảo công thức ở 3.2.1) ,Điều kiện 1 - kiểm tra lƣu lƣợng trung bình của phiên

If(Davg(i) <= DMax ) then

F = random(0.75;1); // đặt giá trị F > 0,75 nhƣng < 1; Else

F = 0; // ƣu tiên thấp nhất

End if;

Cập nhật F(i) vào cơ sở dữ liệu;

DRequest_avg = F*( DReceived/ PRequest ); // (tham khảo công thức ở 3.2.2), Điều kiện 2 - kiểm tra lƣu lƣợng truy vấn trung bình

If( DRequest_avg <= DRequest_max) ) then // Kiểm tra truy vấn có vƣợt ngƣỡng cho phép? F = random(F;1); // nếu bình thƣờng sẽ tăng điểm lên nhƣng không vƣợt quá 1

else

F = 0;

End if;

Sử dụng cơ chế trạng thái tối thiểu; // Điều kiện 3 – tham khảo cách xác định và giá trị tính ở 3.2.3

// nếu độ ƣu tiên lớn hơn 0 , thông thƣờng là lớn hơn 0.75 thì quyết định đẩy gói tin

đang đƣợc kiểm tra vào High Queue, ngƣợc lại thì đẩy gói tin đang đƣợc kiểm tra vào Low Queue

If(F > 0) then

Đẩy gói tin vào hàng đợi ƣu tiên cao;

Else

Đẩy gói tin vào hàng đợi ƣu tiên thấp;

End if;

End procedure;

63

Giải thích thuật toán:

- Đầu vào: Gói tin vào từ mạng, trƣớc khi đƣợc đặt vào bộ đệm của Router xử lý chuyển tiếp đến Web bên trong Webfarm thì cần thông qua bộ lọc này ( do bộ lọc đƣợc đặt ở trƣớc Router – tham khảo hình 32)

- Quy trình xử lý

 Bộ lọc sẽ khởi tạo các giá trị ban đầu. Những giá trị này bao gồm: ngƣỡng kích cỡ truy vấn tối đa cho phép(150KB), ngƣỡng thời gian đọc một trang Web trung bình(10s), kích cỡ gói tin(200bytes), trọng số bộ nhớ dành cho hàng đợi High Queue và Low Queue(4:1)…

 Căn cứ vào thời gian đến của gói tin cuối cùng của truy vấn đến trang đang đọc, tổng dữ liệu của Web-request này, thời gian kết thúc của phiên Web- request tính toán đƣợc thời gian đọc trang và lƣợng dữ liệu nhận đƣợc của phiên đó từ đó so sánh với các ngƣỡng cho phép. Nếu các ngƣỡng băng thông phiên này vƣợt qua ngƣỡng cho phép khi khởi tạo thì rõ ràng cần đặt biến ƣu tiên F=0 và đẩy luôn gói tin từ địa chỉ IP nguồn của phiên này vào hàng đợi ƣu tiên thấp. Kiểu kiểm tra này sẽ phục vụ cho phát hiện các dạng tấn công Simple Flooding (đã trình bày chi tiết trong phần 3.2.1).

 Căn cứ vào tần suất truy vấn dữ liệu trong khoảng thời gian nghỉ reading time chúng ta có thể sử dụng cơ chế bẫy tần suất để loại bỏ các dạng tấn công High-Burst-Slow. Nếu tần suất không đều và có sự ngẫu nhiên thì lƣu lƣợng là bình thƣờng, ngƣợc lại tần suất gửi tin có chu kỳ lặp đi lặp lại thì chắc chắn đó là lƣu lƣợng tấn công.

 Ngoài ra chúng tôi còn sử dụng cơ chế trạng thái tối thiểu. Phần này thiết kế không khác nhiều phƣơng pháp của E.Doron sử dụng [4].

 Giá trị F cuối cùng sẽ là căn cứ để quyết định xem gói tin của phiên hiện tại có phải là từ nguồn lƣu lƣợng tấn công hay không. Nếu phải sẽ bị gửi xuống hàng đợi ƣu tiên thấp và tất nhiên kết nối đó sẽ bị hoãn lại chƣa phục vụ cho đến khi hàng đợi ƣu tiên cao không còn dữ liệu để xử lý. Nhƣ vậy trong các trƣờng hợp tấn công DDoS xảy ra, rõ ràng cách phân loại này sẽ giúp bộ lọc hạn chế đáng kể các lƣu lƣợng tấn công truy vấn hoàn thành kết nối tới máy chủ Web. Giá trị F [0.75:1] là cặp giá trị cận dƣới và cận trên tối ƣu nhất mà

64 chúng tôi tìm ra sau nhiều kết quả thử nghiệm Heuristic để xác suất phân loại đúng đạt giá trị cao trên 90%.

- Đầu ra: Quyết định chuyển gói tin vào loại hàng đợi xử lý nào.

3.4.2 Độ phức tạp của thuật toán

Với n giá trị đầu vào, khi thực hiện thuật toán ngoài các phép gán để tính toán tìm giá trị cơ bản của phiên và các lệnh điều kiện quyết định có độ phức tạp O(n), phép cập nhật vào cơ sở dữ liệu, không tồn tại một vòng lặp nào nên độ phức tạp tổng thể của thuật toán là O(n).

3.4.3 Độ tin cậy của phƣơng pháp

Độ tin cậy của phƣơng pháp phụ thuộc vào hai yếu tố:

1) Độ tin cậy của tham số thống kê đặc tính hành vi ngƣời dùng trong mô hình dữ liệu

2) Những sai số trong phép tính toán lại ngƣỡng và tỉ lệ phát hiện đúng trong trƣờng hợp đúng là hành vi tấn công và trong trƣờng hợp là hành vi ngƣời dùng hợp lệ không đƣợc dƣới 95% hoặc tỉ lệ phát hiện sai ngƣời dùng hợp pháp là tấn công hoặc kẻ tấn công là ngƣời dùng hợp pháp phải dƣới 5%. Yếu tố thứ nhất 1) đƣợc chứng minh trong bài báo của Lee & Gupta thông qua các thống kê toán học và xác suất xuất hiện dữ liệu bất kỳ so với giá trị đề xuất. Tác giả cũng đƣa ra những biên độ sai số những kết quả thống kê thực tế so với thống kê trong mô hình theo mức chấp nhận đƣợc. Dĩ nhiên trong thực tế không thể có trƣờng hợp nào mà chúng ta đo đƣợc chính xác hoàn toàn những thuộc tính hành vi đó. Yếu tố thứ hai 2) để chứng minh, chúng tôi tìm cách thực hiện những thực nghiệm heuristic để tính toán kết quả thu đƣợc, sau đó so sánh tỉ lệ sai sót khi tiến hành nhiều phiên thực nghiệm khác nhau.

3.4.4 Sơ đồ hoạt động cơ bản

Với tất cả những phân tích ở trên, thuật toán thực hiện đƣợc thiết kế nhƣ sau: Dữ liệu gói tin đi vào đƣợc kiểm tra các điều kiện là các điều kiện bẫy thời gian, bẫy tần suất, trạng thái tối thiểu. Tùy theo kết quả kiểm tra sau cùng của các điều kiện trên mà hệ thống sẽ sinh ra giá trị ƣu tiên F(i) cho mỗi kết nối phù hợp. Dựa theo giá

65 trị ƣu tiên mà hệ thống sẽ quyết định đẩy gói tin đó vào hàng đợi High Queue hay Low Queue.

Để minh họa đƣợc tốt nhất hiệu quả của thuật toán mới trên mô hình dữ liệu mới sẽ thể hiện ra sao trong trƣờng hợp website có tấn công xảy ra. Chúng tôi dựa trên các kiểu tấn công đã biết [4] nhƣng có chỉnh sửa để phù hợp với mô hình dữ liệu mới – do không tuân theo mô hình ON – OFF nên các ngƣỡng và cách tham chiếu các giá trị sẽ có sự khác biệt. Ta giả sử tất cả các kiểu tấn công, hacker có thể dễ dàng bắt chƣớc – do kẻ tấn công có thể tái tạo lại gói tin, tốc độ gửi dƣới bất kỳ dạng nào. Có tất cả bốn dạng tấn công chúng tôi tập trung thử nghiệm: “Simple flooding”, “High-burst slow”, “Low-burst fast”, “Low rate DDoS” hay Shrew Attack.

Với mỗi kiểu tấn công, sẽ có sự khác nhau về tần suất truyền tin, thời gian truyền tin cũng nhƣ cách tổ chức các nhóm nhỏ máy tính zombie tấn công cũng khác

66 nhau. Chúng tôi đi chi tiết vào mỗi dạng tấn công cụ thể, đặc điểm chi tiết nhận dạng chúng.

67

CHƢƠNG IV: MÔ PHỎNG VÀ ĐÁNH GIÁ 4.1 Thực hiện mô phỏng

4.1.1 Mô hình mô phỏng

Để phục vụ phép thử nghiệm ngắn gọn và tập trung vào tƣơng tác giữa trình duyệt và máy chủ web, chúng tôi chọn mô hình mô phỏng có cấu trúc cơ bản nhƣ hình 32. Sở dĩ chúng tôi chọn mô hình đơn giản nhƣ vậy trong khi thực tế từ ngƣời dùng đến máy chủ web, gói tin phải đi qua rất nhiều chặng mạng với cấu trúc khác nhau, mạng chứa máy chủ Web cũng có thể trang bị nhiều các lớp bảo vệ, các thiết bị hỗ trợ cân bằng tải…. tuy nhiên chúng không làm suy giảm lƣu lƣợng cần truyền tải thực sự từ trình duyệt lên web mà chỉ tăng độ trễ của gói tin. Theo những thống kê nghiên cứu thì độ trễ này (~20ms – 60ms) không đáng kể so với thời gian ngƣời dùng đọc dữ liệu. Do đó chúng tôi giả sử các chặng đƣờng mạng đó là môi trƣờng Internet chung trong mô hình chúng tôi sử dụng và không tính thêm thời gian trễ vào các ngƣỡng thời gian thử thách của giải pháp. Trong mô hình mô phỏng này chúng tôi cũng giả sử máy chủ Web có hỗ trợ Cache.

Hình 32 Mô hình mô phỏng

4.1.2 Chƣơng trình mô phỏng, yêu cầu thiết bị và cấu hình

Tất cả các nghiên cứu thực nghiệm chúng tôi đều tiến hành trên máy tính với các chƣơng trình mô phỏng bằng phần mềm. Thông số cơ bản của máy tính chúng tôi dùng là:

68  CPU: Intel Core i5-3210M 2.5 Ghz

 RAM: 4 GB

 Hệ điều hành: Ubuntu 12.04 LTS Precis Pangolin  Video Card onboard

Để có thể mô phỏng đƣợc tất cả các tham số về độ trễ, thời gian gửi tin, độ lớn mỗi gói, có sinh dữ liệu tự động, mô phỏng cả trƣờng hợp Webserver có hỗ trợ

Một phần của tài liệu Giảm thiểu ảnh hưởng của các tấn công từ chối dịch vụ phân tán vào các website (Trang 57)