So với đề xuất WebSOS, kiến trúc thực nghiệm được xây dựng với cơ chế có một số thay đổi. Các Servlet được thiết lập thủ công qua chếđộ dòng lệnh chứ không thông qua việc nhận các thông báo đến từ Server.
Với mỗi máy tính, để tham gia vào mạng bao phủ WebSOS, máy sẽ thực hiện dòng lệnh trong Communication Control Module và module Overlay Network. Khi tham gia vào mạng bao phủ, nếu node đó đóng vai trò Servlet, thì nó sẽ khai báo luôn một file chứa IP của các Server đích mà nó làm Servlet tương ứng. Các node khai báo file tương ứng là file rỗng, sẽ nhận vai trò làm SOAP hoặc Beacon, hay ovelay node thông thường.
Với các máy nhận vai trò làm SOAP, ta cài đặt cho chúng thêm hai module còn lại là module CAPTCHA để xác nhận người dùng hợp lệ, và module Secure Tunnel Proxylet để người dùng tải về chạy proxy applet trên trình duyệt của mình.
Với các máy làm Server đích, đơn giản ta cài đặt Xampp và đặt một số file html lên để làm Website thử nghiệm cho người dùng truy cập thông qua mạng bao phủ.
4.3 Kiểm tra độ trễ của các kết nối
Trong khâu kiểm tra độ trễ của các kết nối, nhằm mục đích kiểm tra đểđạt được kết quả như khi kích thước mạng bao phủ là lớn, ta dựa vào kết quả của Chord, đó là với xác suất cao, khi trong mạng có 2m node, thì việc định tuyến chỉđi qua m node. Vì vậy ta tạo nên một topo mạng với m=10 node, vào định tuyến thủ công để yêu cầu người dùng đi qua 10 node đó. Như vậy kết quảđạt được sẽ tương đương với việc kiểm tra trong môi trường mạng bao phủ có 2m= 210= 1024 nodes.
Dưới đây là bảng kết quả tổng thời gian từ khi người dùng đưa ra request, đến khi nhận được kết quả hiển thị trên browser, khi thực hiện định tuyến với quãng đường là m=0, 1, 4, 7, 10 node (kết nối trực tiếp đến server, kết nối qua mạng bao phủ với quãng đường 1 node, 4, 7, 10 node).
Server Direct 1 Node 4 Nodes 7 Nodes 10 Nodes
Google.com 1.42 2.07 2.51 2.90 3.49
Coltech.vnu.edu.vn 1.51 2.35 2.76 3.51 4.13
Test.htm (local server) 0.64 1.27 1.35 1.55 1.79
Bảng 1: Độ trễ khi thử nghiệm kết nối đến 1 số trang web
Có thể thấy, độ trễởđây ở số nhân 2 hoặc 3, là một độ trễ có thể chấp nhận được khi một Website nằm trong hoàn cảnh một cuộc tấn công từ chối dịch vụ. Ởđây do việc định tuyến qua các node thực hiện một cách thủ công, nên thời gian trễ do việc thực hiện thuật toán định tuyến Chord bị bỏ qua. Ngoài độ trễ do việc định tuyến còn có thời gian trễ do việc cấp và chứng thực khóa qua kết nối SSL.
Các đo đạc về thời gian xác thực khóa RSA 1024 bit do Stavrou [6] và các đồng nghiệp sử dụng một máy Linux 3 GHz Pentium IV đo được khi dùng thư viện
OpenSSL V 0.9.7c. Đo đạc cho thấy thời gian sử dụng để xác thực người dùng là rất nhỏ, và qua tính toán giả sử mỗi khóa xác thực hết hạn sau 30 phút, thì mỗi node có
thể xác thực cho 18 triệu người dùng mỗi giờ, đó là khi chưa cần tới tăng tốc phần cứng.
Bảng 2: Thời gian đăng kí và xác thực khóa RSA 1024 bit [6]
Qua các đo đạc trên có thể thấy, dù cho độ trễ là vấn đề lớn nhất của WebSOS,
độ trễ tạo ra trong các thử nghiệm là có thể chấp nhận được. Với việc các khách hàng có thể truy nhập trực tiếp vào Website trong thời điểm không có cuộc tấn công, chỉ
kích hoạt mạng bao phủ WebSOS trong cuộc tấn công, thì thời gian trễ như vậy là có thể chấp nhận trong việc triển khai một cách rộng rãi.
4.4 Đề xuất cải tiến
4.4.1 Vấn đề về mạng bao phủ của WebSOS
Trong khi xây dựng kiến trúc WebSOS, các tác giả giảđịnh rằng kiến trúc
WebSOS là ổn định và chắc chắn, nghĩa là các node trong mạng bao phủ WebSOS đều
đáng tin cậy, và không bị chiếm dụng bởi kẻ tấn công, và kẻ tấn công chỉ có thể tấn công vào hệ thống từ bên ngoài mạng bao phủ.
Để nghiên cứu và cải thiện kiến trúc WebSOS, ta giảđịnh trường hợp một, hoặc một số node trong mạng bao phủ WebSOS bị kẻ tấn công chiếm dụng. Từ node bị
chiếm dụng này, kẻ tấn công có thể thực hiện một trong ba hình thức tấn công sau: - Tấn công toàn vẹn dữ liệu: Tấn công toàn vẹn dữ liệu có thể trên kênh request,
bằng cách hủy bỏ gói tin hoặc kênh truyền đã thiết lập. Khi node bị chiếm dụng hủy gói tin trên kênh request, người dùng sẽ nhận thấy rằng mình không thể kết nối đến server. Khi kẻ node bị chiếm dụng tấn công toàn vẹn dữ liệu trên kênh truyền đã thiết lập, chúng ta có thể phát hiện ra kiểu tấn công này thông qua giải pháp cải tiến, hoặc ngay ứng dụng phía người dùng có thể nhận thấy được thông qua dữ liệu gửi về sai, hoặc qua việc xác thực… để có thể chuyển sang SOAP khác.
- Tấn công hủy gói tin: tấn công hủy các gói thiết lập kết nối khiến người dùng không thể kết nối đến server qua node đó. Phân tích sâu hơn trường hợp này, ta thấy trong kênh truyền đã được thiết lập, kẻ tấn công có thể hủy bỏ các gói tin
được truyền giữa người dùng hợp lệ và server. Tương tự kiểu tấn công toàn vẹn dữ liệu, chúng ta có thể phát hiện kiểu tấn công này thông qua giải pháp cải tiến, hoặc ứng dụng người dùng cũng có thể nhận thấy qua việc kết nối bị
ngừng, hoặc qua thông lượng thấp của ứng dụng.
- Tấn công gửi tràn gói tin: Một node bị chiếm dụng có thể tham gia tấn công gửi tràn đến server đích thông qua việc gửi tràn gói tin đến Servlet.
4.4.2 Đề xuất cải tiến
Chúng ta sẽ tập trung vào kiểu tấn công thứ nhất và thứ hai: tấn công hủy gói tin, và đưa ra giải pháp bằng cách thiết lập một cơ chế nhận diện kiểu tấn công này, và sau
đó thiết lập cho proxylet của người dùng thực hiện thay đổi SOAP để kết nối đến server qua con đường định tuyến khác không thông qua node bị chiếm dụng. Cơ chế
này được thực hiện theo ý tưởng bài báo [12] bằng cách gửi một gói tin thăm dò định kì đến server đích. Áp dụng vào kiến trúc WebSOS, chúng ta sẽ cho proxylet bên người dùng thực hiện gửi một gói tin thăm dò định kì đến server. Nếu server trả lời gói tin thăm dò đó sai quy định đã xác định trước, thì chúng ta kết luận là trong con đường
định tuyến có một node đã bị chiếm dụng và thực hiện tấn công hủy gói tin, từđó ta sẽ
cho người dùng tựđộng thay đổi SOAP đểđi qua con đường định tuyến khác. Cơ chế
này là trong suốt với người dùng và người dùng sẽ không phải thực hiện xác thực hợp lệ qua SOAP mới.
Kẻ tấn công cũng có thể chỉ chặn các yêu cầu hợp lệ, ngoài ra các gói tin thăm dò và gói tin trả lời thăm dò vẫn được truyền qua node bị chiếm dụng. Để khắc phục trường hợp này, cơ chế cho phép người dùng khi một số các yêu cầu nhất định không có trả lời từ phía server, thì proxylet cũng tựđộng kết nối đến một proxy khác, cho phép người dùng thiết lập kết nối bình thường, không đi qua node bị chiếm dụng nữa.
Đề xuất cải tiến có thểđược thể hiện dưới dạng giả mã như sau:
- Đề xuất cải tiến thực hiện tại proxy applet
Thiết lập biến số lượng thăm dò không được trả lời đúng probe=0; Thiết lập biến số lượng kết nối hỏng numD= 0;
Thiết lập số lượng kết nối thành công numS= 0; Thiết lập biến kiểm tra kết nối hỏng drop=false;
(*) Nếu probe>3, thực hiện thay đổi SOAP cho client và thiết lập lại giá trị các biến về mặc định.
Nếu numD>= 3 , thực hiện thay đổi SOAP cho client và thiết lập lại các biến về
mặc định. Gửi dữ liệu request.
Gửi dữ liệu probeRequest sau một khoảng thời gian random và tăng probe lên 1.
Kiểm tra nếu drop==true, tăng numD lên 1.
Đặt giá trị drop=true.
Nếu số lượng kết nối thành công numS>7, gán numS= 0 và numD= 0.
Nếu nhận được dữ liệu response, tăng numS lên 1, và đặt lại drop=false.
Nếu dữ liệu response là probeResponse, gán probe= 0 và numD=0;
Quay lại (*)
- Đề xuất cải tiến thực hiện tại Server đích
Nếu nhận được request là probeRequest, xử lý và gửi lại probeResponse
Như vậy theo giả mã, proxylet chạy trên client sẽ kiểm tra nếu cứ 10 lần gửi request mà có tới 3 lần không nhận được dữ liệu response thì proxylet xem như có hành động tấn công hủy gói tin và tựđộng thay đổi SOAP để kết nối đến Server.
Ngoài ra, sau một khoảng thời gian random, một gói tin probeRequest được proxylet tại client gửi lên Server đích. Nếu như client không nhận được gói probeResponse phù hợp, nó sẽ tăng một giá trị numD. Khi numD >=3, proxylet sẽ
thực hiện thay đổi SOAP cho client, và gán lại numD=0, tiếp tục quá trình. Còn nếu nhận được gói tin probeResponse phù hợp, proxylet ghi nhận không có tấn công hủy gói tin, các biến được reset, quá trình được thực hiện lại từđầu.
4.4.3 Thực thi đề xuất
Để thực thi đề xuất, chúng ta thay đổi cơ chế hoạt động của proxylet, và gửi định kì gói tin thăm dò đến server, sau đó chờ gói tin trả lời thăm dò. Nếu gói tin trả lời không đúng, hoặc không có gói tin trả lời thăm dò thì một biến thiết lập sẵn cũng được tăng dần, đến một giá trị xác định trước, proxylet sẽ tựđộng kết nối đến một SOAP khác đểđảm bảo truy cập người dùng. Ngoài ra, khi yêu cầu người dùng không nhận
được trả lời từ server, thì biến được thiết lập cũng tăng dần đến giá trịđịnh trước đó. Khi proxylet kết nối đến SOAP khác, biến đó sẽđược khởi tạo lại giá trị 0. Sau khi thực nghiệm với hệ thống, tôi thấy hiệu quả của cơ chế là rõ rệt, các trường hợp khi không có gói tin trả lời thăm dò, hoặc các gói tin trả lời từ server bị hủy bỏ, thậm chí cả khi việc giữđường truyền cho các gói thăm dò/ trả lời thăm dò và hủy các gói tin khác, cơ chế vẫn có thể phát hiện và xử lý hiệu quả qua việc thay đổi SOAP. Danh sách các SOAP để thay đổi được lưu tại từng SOAP, được proxylet đọc và lưu trong một mảng dùng để thay đổi SOAP khác khi phát hiện có tấn công hủy gói tin.
4.4.3.1 Kịch bản thử nghiệm
Để thực thi đề xuất và kiểm định các kết quả của cơ chếđề ra, trước hết chúng ta xây dựng nên hai kịch bản thử nghiệm như sau:
- Kịch bản 1: Giả sử một client kết nối đến một SOAP. Sau khi hoàn tất xác thực người dùng qua bài kiểm tra CAPTCHA, người dùng download về máy và chạy một proxy applet nhằm kết nối đến SOAP. SOAP tạo chuyển tiếp yêu cầu người dùng qua mạng WebSOS overlay node đến với Servlet, rồi đến Server đích. Trong tuyến đường từ SOAP đến Servlet, một node trong đó có thể là một node bị chiếm dụng, và node này sẽ thực hiện tấn công hủy bỏ gói tin. Bằng việc thực hiện khiến node vẫn gửi yêu cầu người dùng đến Server đích cũng như lắng nghe thông điệp trả lời từ Server đích, nhưng lại ngừng ghi vào luồng thông tin gửi ra client, node đó sẽ hủy bỏ mọi gói tin từ
Server gửi đến người dùng. Ở phía người dùng hợp lệ, sự chậm trễ trong việc nhận gói tin dẫn đến tình trạng trang web load quá lâu, việc mất kết nối hoặc thông lượng ứng dụng thấp. Dựa trên những biểu hiện này, ta phát hiện ra hiện tượng gói tin bị hủy nhờ
vào việc gửi và nhận gói tin probeRequest, probeResponse, và thực hiện biện pháp đối phó. Đó là việc cấu hình khiến proxy applet đang chạy trên máy người dùng tựđộng thay đổi SOAP khác. Ta thực thi kịch bản xây dựng này với cả chương trình gốc và chương trình đã cải tiến, nhằm xem xét tác động của hình thức tấn công này với chương trình gốc, cũng như kiểm tra khả năng của cơ chế cải tiến, xem nó có thể phát
hiện và xử lý tốt hình thức tấn công hủy bỏ gói tin của các node bị chiếm dụng hay không.
- Kịch bản 2: Tương tự như kịch bản 1, tuy vậy node tấn công không hủy bỏ
toàn bộ gói tin. Ta giả sử kẻ tấn công tinh vi tới mức phát hiện ra được các gói tin probeRequest, probeResponse cho dù ta có che giấu chúng trong gói tin gửi đi tốt thế
nào chăng nữa, hoặc là kẻđịch hủy bỏ một số lượng lớn gói tin trong các gói tin nhận
được từ server, chỉ cho một số ít các gói tin đi qua đểđánh lừa người dùng rằng vẫn có kết nối tuy rất chậm, với server và một cách ngẫu nhiên các gói tin chứa probeRequest và probeResponse đều không bị hủy, hoặc không bị hủy tới 3 gói probeResponse liên tiếp. Như vậy theo kịch bản 2, cơ chếđề xuất gửi probeRequest và probeResponse bị
vô hiệu hóa, ta sẽ phải sử dụng cách khác để phát hiện ra là các gói tin đang bị hủy bỏ
với số lượng lớn, để biết có tấn công của một node độc hại và thực hiện thay SOAP cho client.
4.3.3.2 Kết quả thử nghiệm 4.3.3.2.1 Với chương trình gốc
Khi thực thi kịch bản thử nghiệm với chương trình WebSOS gốc, hiện tượng trực quan đó là ở phía client người dùng, các gói tin request được gửi đi bình thường, vì vậy Browser vẫn chờ các gói response trong khi không hề có gói response nào tới Browser. Trang web vẫn thông báo “Waiting for http://....”, song không thể load được trang kết quả. Sau 20 giây (theo thiết lập tùy biến setSoTimeout trong code chương trình) không nhận được response, Browser thông báo “Internet Explorer cannot display the webpage”.
Hình 5: Kịch bản thử nghiệm được thực thi với chương trình gốc. Các client không thể nhận response khi trên đường định tuyến đến server có một node bị
chiếm dụng thực hiện tấn công hủy gói tin.
Kết quả tất yếu xảy ra đó là khi thực thi kịch bản với chương trình WebSOS gốc, Browser tại client không thể nhận được response từ Server đích, tương đương với việc các người dùng hợp lệ không thể kết nối đến Server đích khi trên đường định tuyến từ
client đến Server đích có một node bị chiếm dụng, và thực hiện hình thức tấn công hủy gói tin. Với kịch bản thứ 2, do hầu hết các gói tin bị hủy, nên người dùng cũng gần như không thể kết nối đến server.
4.3.3.2.2 Với chương trình cải tiến
- Kịch bản 1: Khi thực hiện kịch bản thử nghiệm 1 với chương trình cải tiến, hiện tượng diễn ra ban đầu không khác gì so với chương trình gốc, đó là Browser không thể nhận response từ Server, trang web vẫn chỉ thông báo “Waiting for
http://....” mà không có hiện tượng gì xảy ra. Tuy nhiên, sau một thời gian, khoảng 14 giây thì trang web load bình thường và người dùng truy nhập thành công. Các lần truy vấn tiếp theo trở nên bình thường, không còn có hiện load lâu như lần truy cập trước nữa.
Hình 6: Kịch bản thử nghiệm 1 được thực thi với chương trình cải tiến. Sau 14 giây loading với trường hợp xấu nhất (12 giây thực hiện cơ chế), Browser đã
có thể load trang web. Các request sau, Browser gửi và nhận truy vấn bình thường. Với kịch bản thử nghiệm 2, trường hợp xấu nhất sau 3 lần truy vấn không thành công, lần thứ 4 trởđi Browser cũng gửi nhận truy vấn bình thường.
Nguyên do là bởi cơ chếđề xuất, khi gửi truy vấn đến server thì đồng thời cứ sau 3 giây một probeRequest lại được gửi lên server (thời gian giữa 2 lần gửi
probeRequest có thểđiều chỉnh), và sau 3 lần liên tiếp gửi probeRequest không thành công các proxy applet tựđộng thay đổi SOAP dẫn đến thay đổi đường dẫn định tuyến