Khóa luận Phòng chống tấn công từ chối dịch vụ phân tán vào các website

giám sát, một plug-in cho hệ thống phát hiện xâm nhập Snort, phát hiện một cuộc tấn công bằng cách phân tích và tương ứng lưu lượng truy cập qua mạng nguồn. Căn cứ vào mối tương quan (thời gian, loại hình giao thông), việc tương ứng thực thể có thể ngăn chặn lưu lượng truy cập tương tự và đồng thời như là một hành động nhóm, chính là các giao thông tấn công gửi đến. Kỹ thuật này thực thi tại mạng nguồn, kích hoạt bởi một thông báo từ các mục tiêu của một cuộc tấn công DDoS, bằng cách lọc ra các vi phạm giao thông rõ ràng. Tuy nhiên, nếu lưu lượng truy cập hợp pháp được xuất hiện bởi các động cơ tương quan, dẫn đến một sai lầm chủ quan, thì sau đó lưu lượng truy cập hợp pháp sẽ bị loại bỏ bởi Cozak. Một giả định chính của kỹ thuật này là việc triển khai các cơ quan giám sát tại nguồn mạng. Nguồn mạng đang được ngăn cản khỏi nguồn tấn công, nhưng một mạng lưới mà không có cơ quan giám sát vẫn có thể tham gia vào một cuộc tấn công DDoS. Hạn chế này là phổ biến cho các hệ thống đòi hỏi phải có nguồn cấp triển khai. Không yêu cầu sửa đổi ở mức giao thức hoặc áp dụng cho các nguồn mạng. Các thông tin liên lạc giữa các nhà kiểm soát không có khả năng mở rộng, vì họ sử dụng truyền thông multicast. 2.8 Biện pháp Pi Pi, đề xuất của Yaar [2], là một hệ thống bảo vệ mục tiêu nạn nhân, xây dựng trên kỹ thuật đánh dấu gói tin đã đề cập ở biện pháp traceback, chèn vào định danh đường dẫn vào mục chưa sử dụng trong phần header của gói tin IP. Ý tưởng chính là những định danh đường dẫn hoặc dấu vân tay xác thực được chèn vào bởi các router dọc theo đường mạng. Các mục tiêu hoặc nạn nhân sau đó sẽ từ chối các gói tin với định danh đường dẫn phù hợp với các gói tin đã được xác định rõ ràng như một phần của cuộc tấn công. Trong đề án đánh dấu Pi cơ bản, từng router tham gia đánh dấu bit nhất định trong trường nhận dạng IP của gói tin IP. Các vị trí của kí hiệu trong trường này được xác định bởi giá trị của trường TTL (time to live) của gói tin. Kí hiệu là một phần của bảng băm của địa chỉ IP của router. Vì giá trị TTL được giảm đi tại mỗi router, một con đường tiếp giáp của gói tin được xây dựng khi nó đến gần hơn với nạn nhân. Người ta có thể quyết định ngừng đánh dấu trong một khoảng cách chặng nhất định của mạng nạn nhân để tăng khả năng tới đích của gói tin trong đề án này. Bộ lọc Pi có thể xảy ra một khi chương trình đánh dấu đã được cài đặt trong cơ sở hạ tầng. Đề án này giả định rằng nạn nhân biết làm thế nào để xác định số lượng lớn của lưu lượng truy cập tấn công, ví dụ, bằng cách chọn một phần lớn của lưu lượng truy cập đến mang nhãn hiệu tương tự. Các bộ lọc sau đó ném bỏ tất cả lưu lượng với nhãn hiệu nhất định. Vô tình, một số lưu lượng truy cập hợp pháp chia sẻ nhãn hiệu với các cuộc tấn công (vì nó cũng chia sẻ đường dẫn đến các nạn nhân do sự dao động và tính chất thích nghi của mạng) cũng sẽ bị giảm xuống, mất mát. 2.9 Biện pháp SIFF Yaar [3] đề xuất để giảm thiểu ngập lụt tấn công DDoS bằng cách sử dụng một cơ chế trong khả năng của host cuối có thể phân chia lưu lượng truy cập Internet tách thành hai lớp: đặc quyền và không đặc quyền. Host cuối có thể trao đổi capabilities sẽ được sử dụng trong giao thông đặc quyền. Router sau đó sẽ xác minh những capabilities này một cách không trạng thái. Những capabilities này được giao trong một động cơ chế, vì vậy máy cư xử sai trái (máy tấn công) có thể có khả năng bị thu hồi capabilities. Trái ngược với cách tiếp cận khác, kế hoạch này không đòi hỏi một cơ chế che phủ, nhưng nó có yêu cầu sửa đổi của máy khách và máy chủ, cũng như cả ở router nữa. Các máy khách sẽ sử dụng một giao thức bắt tay vào khả năng trao đổi, và sau đó là lưu lượng truy cập đặc quyền sẽ được giải quyết nhanh của mạng, trái ngược với giao thông không có đặc quyền mà sẽ không nhận được ưu tiên. Có quy định tại chỗ để ngăn chặn tấn công gửi tràn với lưu lượng truy cập đặc quyền của một người trái phép, ví dụ, bởi một người cố gắng tạo ra capabilities (thực hiện bằng cách đánh dấu trong mỗi gói). Nếu một máy khách với capabilities bắt đầu ngập lụt, sau đó các thông tin cho lưu lượng truy cập đặc quyền có thể bị thu hồi với máy khách đó. Các tác giả của cơ chế này đề xuất hai con đường: một là cơ chế Internet thế hệ tiếp theo kết hợp những kỹ thuật này và một là cơ chế cho các giao thức mạng hiện nay ở IPv4. Đó là còn chưa rõ ràng rằng những con đường sẽ chứng minh hiệu quả hay không. Tóm lại, kỹ thuật này cũng chấp nhận nhiều giả thiết, trong đó có giả định là máy khách và máy chủ cập nhật các phần mềm theo giao thức TCP / IP để kết hợp sửa đổi cần thiết cho các capabilities mới. Ưu điểm là không cần thiết phải có-liên-ISP hay hợp tác giữa các ISP. Tuy nhiên, nó cũng giả định rằng giả mạo là hạn chế, và việc xử lý và duy trì trạng thái được yêu cầu tại từng router. Các giao thức mạng mới yêu cầu đánh dấu không gian trong tiêu đề gói IP, hợp tác của khách hàng và máy chủ, mỗi router phải đánh dấu các gói tin, và tuyến đường giữa các máy trên mạng vẫn ổn định. Các giả định này là khá hạn chế, so với những gì có thể xảy ra trong một mạng thực sự. 2.10 Biện pháp lọc đếm chặng HCF Lọc đếm chặng, Hop-Count Filtering, được đề xuất bởi Jin [7], là một dự án nghiên cứu tại Đại học Michigan, nhằm bảo vệ chống lại DDoS bằng cách quan sát các giá trị TTL (thời gian để sinh sống, số lượng các chặng hoặc router mà một gói tin sẽ đi qua trước khi đến đích, hoặc bị bỏ đi để tránh chặng đường quá dài hoặc lặp lại, giá trị được giảm đi ở mỗi router các gói tin đi qua) trong các gói tin inbound. Triển khai tại các mạng mục tiêu, nó quan sát giá trị TTL cho bất kỳ địa chỉ nguồn trên mạng mà đi qua mạng mục tiêu, cố gắng để suy luận một số hop đếm số chặng (có nghĩa là, khoảng cách của người gửi đến máy phòng thủ) và xây dựng bảng mà ràng buộc một IP cho trước với số chặng. Hệ thống này tạo nên dự đoán của chặng đếm bắt đầu với giá trị TTL quan sát và đoán giá trị TTL ban đầu đã được đặt trong gói tin ở người gửi. Chỉ có một vài giá trị như hệ điều hành sử dụng và họ là khá khác nhau, tạo điều kiện đoán chính xác. Số chặng sau đó được tính bằng sự chênh lệch giữa TTL ban đầu và các giá trị quan sát được. Số chặng Hop-count phân phối theo phân phối chuẩn (chuông đường cong), vì có sự biến đổi đủ trong giá trị TTL. Nếu kẻ tấn công muốn đạt được điều này, hắn sẽ phải đoán đúng giá trị TTL để chèn vào một gói tin giả mạo, để số chặng suy luận phù hợp với giá trị mong đợi. Giả mạo trở nên khó khăn, vì kẻ tấn công giờ phải giả mạo giá trị TTL chính xác để liên kết với một địa chỉ nguồn được giả mạo và, tăng cường số chặng khác biệt thích hợp giữa kẻ tấn công và địa chỉ giả mạo, giao thông độc hại trở nên một mô hình dễ dàng hơn. Trong các hoạt động chung, các bộ lọc đếm chặng là thụ động trong khi nó đang phân tích lưu lượng và nối nó với các bảng tính đến thành lập các giả định hop. Nếu số lượng bất xứng hợp vượt qua một ngưỡng thành lập, chương trình bắt đầu lọc. Các bàn đến đều được cập nhật liên tục bằng cách kiểm tra một ngẫu nhiên kết nối TCP đến một trang web trong mạng được bảo vệ. Lưu ý rằng chương trình này cố gắng để ngăn chặn lưu lượng truy cập giả mạo. Không có gì ngăn cản kẻ tấn công khỏi việc phát động một cuộc tấn công bằng các nguồn thực và mang giá trị TTL chính xác, và do đó các cuộc tấn công bằng cách sử dụng các mạng bot lớn hoặc sâu với DDoS, mà không cần phải mạo địa chỉ nguồn để thành công, vẫn sẽ là một vấn đề. Vì các loại tấn công trở nên dễ dàng ngày hôm nay, những kẻ tấn công chỉ cần áp dụng phương pháp này trên giả mạo địa chỉ nguồn để có thể vượt qua phòng thủ như vậy. Giống như những cuộc phòng thủ phía nạn nhân, phương pháp này không thể giúp bảo vệ chống lại các cuộc tấn công quy mô lớn dựa trên việc gửi tràn tới liên kết tới vào máy thực hiện việc kiểm tra các giá trị TTL. Chương 3: SOS VÀ WEBSOS 3.1 Giao thức Chord Cả hai kiến trúc SOS và WebSOS đều sử dụng một kĩ thuật đó là định tuyến theo cấu trúc, hay bảng băm phân tán DHT – Distributed Hash Tables, qua việc xây dựng một mạng bao phủ có ứng dụng giao thức Chord, vì vậy trước tiên chúng ta sẽ tìm hiểu về giao thức Chord này. Giao thức Chord là một giao thức tìm kiếm phân tán được đề xuất bởi Stoica và các đồng nghiệp [14] tại hội nghị ACM Sigcomm diễn ra vào 8/2001 qua bài báo “Chord: A Scalable Peer-to-peer Lookup Service for Internet Applications”. Chord cung cấp hỗ trợ cho một hoạt động duy nhất: cho một giá trị key, nó sẽ ánh xạ giá trị key đó tới một node trong mạng. Ở đây việc ánh xạ giá trị key đến node trong mạng được thực hiện bởi một hàm băm nhất quán, băm giá trị key để cho ra một giá trị băm, chính giá trị băm này sẽ tương ứng với node tương ứng trong mạng. Từ đó việc lưu trữ và tìm kiếm dữ liệu trong mạng sẽ dễ dàng được thực hiện thông qua việc liên kết mỗi key với các đơn vị dữ liệu để lưu trữ cặp key/ dữ liệu đó tại node mà key ánh xạ đến. Trong mạng Chord, mỗi node được cấp phát một định danh ID thông qua một hàm băm nhất quán trong khoảng [0, 2m] với một giá trị m định trước. Các node trong mạng bao phủ được sắp xếp thứ tự theo định danh của chúng, và được tổ chức theo vòng, thuận chiều kim đồng hồ. Hình 1: Định tuyến theo Chord [14]. Mỗi node sẽ duy trì một bảng gọi là finger table, chứa đựng định danh của m node trong mạng bao phủ. Giá trị ở hàng thứ i trong bảng finger table của node có định danh x, là node có định danh nhỏ nhất mà lớn hơn hoặc bằng x + 2i-1. ( (mod 2m)), như hình. Khi node x nhận được gói tin có đích là node định danh y, nó gửi gói tin đến node trong mạng theo bảng finger table của nó sao cho node này có định danh lớn nhất mà còn nhỏ hơn y. Như ở trên hình, nếu node có định danh 7 nhận được gói tin mà đích đến có định danh là 18, gói tin sẽ được định tuyến từ node 7 đến node 16, sau đó đến node 17. Khi gói tin đến node 17, node tiếp theo trong mạng bao phủ là node 22, vì vậy node 17 biết rằng node 22 là node chịu trách nhiệm cho định danh 20. Như vậy thuật toán định tuyến của Chord sẽ khiến gói tin được chuyển trong mạng đến với node đích qua khoảng O(m) node. Chord chính là một giải pháp tốt cho rất nhiều vấn đề: cân bằng tải, phân tán, linh hoạt, có khả năng mở rộng. Nó cũng có thể xử lý tốt khi các node tham gia và rời khỏi mạng một cách thường xuyên. 3.2 Kiến trúc SOS SOS được Keromytis và các đồng nghiệp của ông [4] đề xuất trong bài báo : “SOS: Secure Overlay Services” vào ngày 21/08/2002 trong hội thảo ACM Sigcomm 2002. Ý tưởng chính của bài báo là xây dựng nên một kiến trúc tầng bao phủ quanh server đích, nhằm ngăn chặn kẻ tấn công khỏi việc tiếp cận để tấn công phá hoại server và chỉ cho phép người dùng đã được xác định – confirm user, mới có thể kết nối đến server. Kiến trúc SOS được thể hiện như hình vẽ dưới. Hình 2: Kiến trúc cơ bản của SOS [4] Trong kiến trúc này, yêu cầu của khách hàng từ source point sẽ đi vào một lớp bao phủ qua một node là SOAP – Secure Overlay Access Point. Do tính chất của SOS, nên node này sẽ làm nhiệm vụ kiểm tra người dùng này có hợp lệ hay không, qua một cơ chế xác thực, như là login. Sau khi xác thực xong người dùng, yêu cầu sẽ được chuyển tiếp qua mạng bao phủ. Mạng bao phủ này đóng vai trò một firewall phân tán, được xây dựng theo giao thức Chord với kĩ thuật định tuyến theo cấu trúc, sử dụng bảng băm phân tán DHT. Giao thức Chord sẽ được mô tả trong phần tiếp theo. , và trong mạng bao phủ, các node có thể đóng một trong các vai trò sau: SOAP: Secure Overlay Access Point: là các điểm truy cập cho khách hàng. Secret Servlet: Các node đặc biệt, mà chỉ có kết nối đến từ các node này mới được server đích chấp nhận. Beacon: Các node đặc biệt trong mạng bao phủ bởi nó biết được vị trí của các secret servlet, nhờ thông báo định kì từ các secret servlet gửi tới chúng. Overlay Node: các node bình thường khác trong mạng. Sau khi node SOAP đã xác thực xong người dùng, nó sẽ lấy địa chỉ Server đích trong gói tin yêu cầu, sử dụng hàm băm của chord để đạt được một giá trị băm. Giá trị băm này sẽ cho biết vị trí của một Beacon, nhờ đó SOAP chuyển tiếp yêu cầu người dùng đến node Beacon đó. Khi Beacon nhận được gói tin, nó lại đọc địa chỉ Server đích, và sau đó chuyển tiếp gói tin đến Secret Servlet của server đích. Secret Servlet nhận được gói tin từ Beacon, nó cũng tiếp tục chuyển tiếp gói tin đến Server đích tương ứng. Vấn đề đặt ra là làm thế nào để Beacon biết được địa chỉ của Secret Servlet tương ứng với Server đích? Điều này được thực hiện thông qua việc định kì, các Secret Servlet tương ứng với Server đích sẽ sử dụng hàm băm của Chord với địa chỉ Server đích, nhờ đó lấy được giá trị băm và biết được vị trí của Beacon cần biết nó. Ngay sau đó nó gửi một thông báo đến Beacon đó, và như vậy Beacon này sẽ nhận thông báo và biết được Secret Servlet ứng với một Server đích. Còn với các Server đích, cơ chế của chúng đó là install một bộ lọc ở router gần nó nhất, và lựa chọn một số node trong mạng bao phủ SOS để làm Secret Servlet của mình, và cho phép chuyển tiếp kết nối thông qua các bộ lọc đến Server đích. Các router ở quanh Server đích cũng được cấu hình để chỉ chấp nhận kết nối đến từ Servlet của nó. Với kiến trúc đề xuất như vậy, SOS được tin tưởng rằng sẽ trở thành một phương pháp tiếp cận mới và mạnh mẽ trong phương pháp chủ động phòng và chống tấn công từ chối dịch vụ. 3.3 Kiến trúc WebSOS 3.3.1 Giải pháp đề xuất WebSOS được đề xuất bởi D. L. Cook, Morein, Keromytis cùng các đồng nghiệp [10] qua bài báo “WebSOS: Protecting Web Servers from DDoS attacks” vào tháng 9-2003 tại hội thảo quốc tế lần thứ 11 của IEEE về lĩnh vực mạng ICON2003, và bài báo: “WebSOS: An Overlay-Based System for Protecting Web Servers from Denial of Service Attacks” viết vào năm 2005 [6]. Với nhiều biện pháp đã trình bày ở chương 2, cách phòng chống tấn công DDoS đưa ra theo một cách thức bị động, khi mà tổ chức quan sát giao thông tại một điểm nào đó, đợi tấn công xảy ra, sau đó mới phân tích các gói tin gửi đến nhằm đặt ra các cơ chế lọc phù hợp để ngăn chặn giao thông của kẻ tấn công. Cách tiếp cận này có hai vấn đề khá lớn. Thứ nhất đó là sự chính xác giữa việc phân biệt giao thông tấn công với giao thông hợp lệ. Với D-Ward, DefCom, Cossack, Pi, khi một sai lầm chủ quan trong việc phân biệt giao thông tấn công xảy ra, các giao thông hợp lệ sẽ bị loại bỏ, khách hàng sẽ không thể truy cập vào Server đích được. Thứ hai, là việc tạo ra một cơ chế thiết lập bộ lọc đủ sâu để có thể hạn chế tác hại của cuộc tấn công đến mức độ tối thiểu. WebSOS dựa trên ý tưởng của SOS để xây dựng nên một kiến trúc phòng chống tấn công từ chối dịch vụ, giúp cung cấp được kết nối đến máy chủ đích ngay cả khi hệ thống đang là mục tiêu của một cuộc tấn công. Cải tiến ý tưởng của SOS, WebSOS sử dụng hệ thống kiếm tra CAPTCHA để phân biệt người dùng hợp lệ với các autobot, truyền các yêu cầu người dùng trong mạng bao phủ thông qua web proxy, xác thực khách hàng qua giao thức SSL/TLS, mà không cần yêu cầu việc thay đổi hạ tầng cơ sở mạng sẵn có. 3.3.2 Kiến trúc của WebSOS Về cấu trúc mạng bao phủ, WebSOS thừa kế từ mô hình SOS như ở hình 2. Các node trong mạng bao phủ vẫn đóng một trong các vai trò: SOAP, overlay node, Beacon, Secret Servlet. Tuy vậy, khi không có tấn công từ chối dịch vụ, các máy khách có thể kết nối trực tiếp đến máy chủ đích mà không thông qua mạng bao phủ WebSOS. Chỉ khi hệ thống bị tấn công, nhờ các router chất lượng cao đã được cài đặt bộ lọc địa chỉ IP, các kết nối đến từ bên ngoài sẽ bị lọc và từ chối kết nối đến các máy chủ đích, chỉ có các Secret Servlet mới có quyền truy cập đến các máy chủ này, lúc đó mạng bao phủ WebSOS mới thực sự hoạt động, và người dùng muốn truy nhập vào máy chủ đích phải kết nối thông qua mạng bao phủ này. Các SOAP là được cài đặt Web server nhằm tạo ra và thực hiện xác thực người dùng hợp lệ thông qua bài kiểm tra CAPTCHA. Cũng trên các web server SOAP, các applet được lưu trữ để người dùng có thể tải về và chạy proxy applet sau khi vượt qua bài kiểm tra CAPTCHA đó. Hình 3: Bài kiểm tra người truy cập sử dụng CAPTCHA. Từ khóa kiểm tra trong trường hợp này là “zbyc”. Vùng lọc xung quanh Server đích vẫn là các router mạnh được install các bộ lọc IP để có thể lọc mọi kết nối đến Server trong thời gian diễn ra cuộc tấn công, và chỉ cho phép kết nối từ các Secret Servlet đến được Server đích. 3.3.3 Cơ chế của WebSOS 3.3.3.1 Cơ chế chung Việc kết nối thông qua mạng bao phủ WebSOS được thực hiện như hình: Hình 4: Cơ chế truy cập và xác thực của người dùng [6] Đầu tiên, người dùng cần biết một SOAP và truy cập đến nó. SOAP này sẽ được cài đặt một webserver để thực hiện chức năng kiểm tra CAPTCHA hay Graphic Turing Test- GTT, để xác nhận truy cập thực hiện bởi con người. CAPTCHA- Completely Automated Public Turing test to tell Computers and Human Apart, là một chương trình có thể tạo ra bài kiểm tra mà hầu hết con người đều có thể vượt qua, trong khi chương trình tự động thì không. Trong WebSOS, CAPTCHA được tạo ra bởi chương trình GIMPY. Khi người truy cập đã vượt qua bài kiểm tra GTT, SOAP sẽ cấp cho người dùng một chứng thực X.509 ngắn hạn, có mã hóa ip của người truy cập vào để làm chứng thực cho việc truy cập vào dịch vụ web, nhằm tránh việc sử dụng lại cho agent với ip khác tấn công. Sau đó, SOAP sẽ yêu cầu người dùng chạy một chương trình proxy applet (signed applet) để browser của người dùng kết nối đến Server đích thông qua proxy applet đó, từ đó tạo kết nối SSL đến SOAP. SOAP nhận kết nối này, và chuyển tiếp kết nối qua mạng bao phủ đến Beacon thích hợp, để Beacon sẽ chuyển tiếp đến Secret Servlet. Từ Secret Servlet, yêu cầu được chuyển qua vùng lọc đến Server đích. Router ở vùng lọc nhận thấy IP của Secret Servlet hợp lệ nên chấp nhận cho kết nối đến Server. Điều này khiến kết nối của người dùng trở nên an toàn, và cũng khiến tuyến đường định tuyến tăng lên, gây ra một độ trễ nhất định. 3.3.3.2 Cơ chế định tuyến Trong mô hình WebSOS, giao thông từ một nguồn tới server đích sẽ đi qua các node theo thứ tự: nguồn, SOAP, Beacon, Servlet và Server đích. Cơ chế định tuyến thông thường được sử dụng để người dùng kết nối tới SOAP. Hơn nữa, do Beacon đã biết các Servlet xác định tương ứng với các Server, cũng như Servlet cũng biết vị trí của Server, vì vậy cơ chế định tuyến thông thường cũng được sử dụng giữa Beacon và Servlet, giữa Servlet và Server đích. Còn giữa SOAP với Beacon, một cơ chế định tuyến của lớp bao phủ được sử dụng. Nhằm giảm quãng đường định tuyến giữa chúng, nhờ đó giảm quãng đường tổng từ nguồn tới Server đích, thuật toán Chord được sử dụng trong trường hợp này. Trong mô hình SOS gốc, quãng đường thiết lập từ người dùng đến Server đích qua mạng bao phủ có thể khác với quãng đường ngược lại từ Server đích tới người dùng. Hơn nữa, response từ Server đích có thể gửi trực tiếp đến người dùng mà không qua lại mạng bao phủ, bởi các kênh truyền thông là song công, và trong các cuộc tấn công DDoS thì chỉ có kết nối tới các Server đích mới là bị tắc nghẽn. Cách thức có những thuận lợi khá lớn trong việc giảm độ trễ của mạng, vì hầu hết các kết nối client/server hiện nay là không đối xứng do các client thường nhận response nhiều hơn là gửi đi các request. Trong WebSOS, định tuyến được thực hiện với từng kết nối cơ bản. Mỗi request tiếp theo trong cùng một kết nối và các response từ Server đích có thể đi theo quãng đường ngược lại trong mạng bao phủ. Trong khi cơ chế này làm cho việc áp dụng trở nên đơn giản, nó cũng gây nên hậu quả làm cho độ trễ tăng lên đáng kể, vì hầu hết các response đều đi qua mạng bao phủ với nhiều chặng, hơn là việc đi trực tiếp đến máy khách để giảm quãng đường trong mạng phủ. 3.3.4 Cơ chế bảo vệ Cơ chế bảo vệ được giả định trong trường hợp kẻ tấn công không đủ mạnh mẽ để tấn công gửi tràn làm quá tải hoạt động của vùng lọc xung quanh các Server đích, cũng như không đủ mạnh tới mức tấn công tràn làm quá tải tất cả các SOAP trong mạng bao phủ. Khi không có cuộc tấn công nào diễn ra, các khách hàng, cũng như các xử lý tự động như chương trình đánh chỉ mục của google có thể truy cập Website một cách trực tiếp như các Website khác. Khi có dấu hiệu của một cuộc tấn công từ chối dịch vụ phân tán, vùng lọc xung quanh các Web Server được kích hoạt, các kết nối đến Website đều bị loại bỏ, ngoại trừ các kết nối đến từ các Servlet tương ứng với các Web Server đích. Như vậy, tác hại của một cuộc tấn công từ chối dịch vụ trực tiếp đến các Server đích bị làm giảm đến mức thấp nhất nhờ các bộ lọc mạnh mẽ này. Kẻ tấn công muốn tiếp tục phá hoại Website chỉ còn cách kết nối đến các Server đích qua mạng bao phủ, để thực hiện tấn công. Khi kết nối đến mạng bao phủ, thông qua việc sử dụng bài kiểm tra Graphic Turing Test hiện đại, giao thông từ con người sẽ được phân biệt chính xác với giao thông từ các chương trình máy tự động do sự đảm bảo của các chương trình CAPTCHA hiện đại có thể khiến các chương trình nhận dạng chữ viết tự không thể thực hiện chính xác. Vì vậy, các chương trình độc hại của kẻ tấn công sẽ bị giới hạn, không thể tiếp cận để gửi gói tin phá hoại tới Server đích được. Thêm vào đó, WebSOS sử dụng SSL qua mỗi chặng trong mạng bao phủ, nhằm mục đích để xác thực chặng trước đó, nhằm tránh việc kẻ tấn công có thể phát hiện được một số node trong lớp bao phủ WebSOS và thực hiện giả dạng các node đó. Với thực tế rằng chi phí về thời gian tạo và chứng thực mã hóa với thuật toán RC4 là rất nhỏ (như ở phần 4 sẽ đề cập đến), các node trong mạng bao phủ không cần thiết phải được cài đặt thêm chức năng đặc biệt khác, và khách hàng thì đơn giản chỉ cần được cấp một chứng thực phù hợp từ quản trị của WebSOS. Hơn nữa, nhằm tránh việc kẻ tấn công sử dụng IP Spoofing gửi gói tin tấn công có IP nguồn trùng với IP của các Servlet đến Server đích, WebSOS đề xuất sử dụng cơ chế GRE: “Generic Routing Encapsulation” theo Farinacci và các đồng nghiệp vào tháng 3-2000, và Dommety, tháng 9-2000. Theo đó, kẻ tấn công muốn giả mạo Secret Servlet ngoài việc cần đoán được IP của Servlet, còn phải đoán được cả giá trị khóa của GRE. Với việc sử dụng khóa phức tạp, thì việc giả mạo Servlet là vô cùng khó khăn đối với kẻ tấn công. Cuối cùng, nếu như kẻ tấn công có thực sự giả mạo được một vài Servlet đi nữa, thì dựa vào việc phân tích các gói tin đến nhiều từ một vài Servlet, Server đích hoàn toàn có thể chọn lại tập các Servlet cho mình, gửi thông báo mới đến chúng và các bộ lọc ở router. Tổng kết: Như vậy chúng ta đã xây dựng xong kiến trúc WebSOS cho việc bảo vệ các WebSite khỏi tác động của các cuộc tấn công từ chối dịch vụ. Kiến trúc này sẽ triển khai qua các hoạt động chính là xác nhận người dùng hợp lệ qua bài kiểm tra Graphic Turing Test, thực hiện kết nối SSL thông qua một proxy applet qua mạng bao phủ đến một Servlet, và từ Servlet qua một vùng lọc đến được Server đích. 3.3.5 Đánh giá ưu, nhược điểm của kiến trúc WebSOS Trong khi nhiều đề xuất khác xây dựng nên một hệ thống chống lại tấn công từ chối dịch vụ một cách bị động, thì WebSOS đã đưa ra một kiến trúc chủ động đối phó với DDoS. Người dùng có thể truy cập trực tiếp vào Website khi không có tấn công DDoS, giúp làm giảm độ trễ của truy cập. Khi phát hiện ra một cuộc tấn công, hệ thống được kích hoạt để hoạt động. Nhờ vào bài kiểm tra Graphic Turing Test, việc phân loại giao thông hợp lệ và giao thông bất hợp pháp đến từ các chương trình tự động có độ chính xác cao, giúp loại bỏ giao thông không hợp lệ khỏi việc tiếp cận và tấn công Server đích. Việc kết nối sử dụng SSL, và việc sử dụng GRE giúp tăng cường bảo mật trong mạng bao phủ và đồng thời giúp chống lại việc kẻ tấn công giả mạo các Servlet để gửi gói tin tràn ngập đến Server đích. Ứng dụng của giao thức Chord giúp việc định tuyến trong mạng bao phủ trở nên nhanh chóng, hơn nữa cung cấp tính cân bằng tải, linh hoạt, khả năng phân tán, mở rộng cho các node trong mạng bao phủ cũng như xử lý tốt việc các node trong mạng bao phủ có thể gia nhập và rời khỏi mạng một cách thường xuyên. Tuy vậy, một số nhược điểm còn tồn tại của WebSOS đó là độ trễ còn cao do việc yêu cầu người dùng phải thông qua nhiều chặng trung gian trong mạng bao phủ. Một điểm nữa đó là chưa xử lý được trường hợp một node trong mạng bao phủ bị chiếm dụng và trở thành agent của kẻ tấn công. Hoặc kẻ tấn công cũng hoàn toàn có thể bỏ qua mạng bao phủ, và thực hiện tấn công trực tiếp vào Server đích qua vùng lọc, làm cho vùng lọc bị vô hiệu hóa bởi việc xử lý các gói tin tràn ngập. Chương 4: THỰC NGHIỆM, CẢI TIẾN VÀ KẾT QUẢ Thực nghiệm được tiến hành nhằm xây dựng nên một Website với sự bảo vệ của lớp mạng bao phủ WebSOS. Đây là thực nghiệm nhằm triển khai giải pháp WebSOS đã đề ra ở chương 3, đồng thời kiểm tra độ trễ của yêu cầu khách hàng khi sử dụng mạng bao phủ WebSOS so với việc kết nối trực tiếp đến với server đích. 4.1 Môi trường thực nghiệm Kiến trúc mạng bao phủ WebSOS được cài đặt trên mạng lưới các máy ảo với hệ điều hành CentOS 5, máy tính 3.0 GHz, RAM 1GB. Chương trình có 3 module chính. Module CAPTCHA được cài đặt trên WebServer Xampp. Module Secure Tunnel Proxylet được viết bởi ngôn ngữ Java. Communication Control Module và module Overlay Network (Chord) được viết bởi java, và C, tương ứng. Website cần bảo vệ là một máy có cài đặt WebServer Xampp. 4.2 Cài đặt kiến trúc WebSOS 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 ”, 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 ” 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 từ client đến server đích. Do đường dẫn không còn đi qua node bị chiếm dụng nữa, nên ảnh hưởng của hành vi tấn công không còn. Đồng thời proxy applet tự động gửi lại yêu cầu qua SOAP mới và nhận response, khiến trang web được load thành công sau khoảng thời gian chờ probeResponse mà không có trả lời. Và do đã chuyển SOAP với đường dẫn định tuyến mới, các truy vấn sau này cũng thực hiện bình thường, không còn hiện tượng không có response đến Browser nữa. Cần nhấn mạnh trường hợp trên là trường hợp xấu nhất khi người dùng mới truy cập đã gặp phải node độc hại trên đường dẫn định tuyến của mình. Ở trường hợp tốt hơn, khi người dùng đang truy cập chẳng hạn, thì một node trong đường dẫn định tuyến bị chiếm dụng và tấn công. Lúc này do probeRequest và probeResponse vẫn đang được gửi, và bị hủy để không nhận được, sau một khoảng thời gian khoảng 12 giây (lần thứ 4 gửi probeRequest), proxy applet sẽ nhận ra node độc hại và thay đổi SOAP. Trong khoảng thời gian này có thể người dùng vẫn chưa chuyển trang khác trong Website, ví dụ như người dùng đang đọc báo chẳng hạn, nên người dùng sẽ không cảm nhận được rằng SOAP bị thay đổi, khi vào trang web khác người dùng không nhận thấy sự chậm trễ nào cả. - Kịch bản 2: Khi thực hiện kịch bản thứ hai với chương trình cải tiến, hiện tượng xảy ra đó là lúc người dùng load một trang web nhưng không thể kết nối đến trang web, hoặc trang web bị mất quá nhiều phần do bị hủy số lượng lớn gói tin. Do giả định cơ chế probeRequest và probeResponse bị vô hiệu hóa vì node tấn công vô tình không hủy bỏ 3 gói tin probe liên tiếp nào, hoặc kẻ tấn công tinh vi tới mức cho phép các gói probe đi qua mặc cho nỗ lực giấu gói probe của chúng ta, vì vậy chúng ta cần đưa ra giải pháp cho kịch bản này. Giải pháp được đưa ra đó là giải pháp đếm số lượng gói tin request mà không có được response. Chúng ta đã đưa ra tỉ lệ khi cứ trong 10 gói tin request mà có tới 3 gói tin không nhận được response (tỉ lệ này có thể thay đổi cho phù hợp với từng mạng) thì proxy applet cũng coi như có tấn công hủy gói tin, và thực hiện thay đổi SOAP cho client. Vì vậy trong trường hợp này người dùng sẽ cảm thấy khó khăn hơn, bởi vì cơ chế đếm số request không được trả lời, nên người dùng phải qua ba lần request server mà không nhận được load được trang web. Đến lần thứ tư trở về sau, người dùng có thể truy vấn bình thường do proxy applet đã chuyển đổi SOAP giúp người dùng không còn bị tấn công hủy gói tin từ node độc hại nữa. Ở trường hợp tốt hơn, khi người dùng gửi yêu cầu một trang web, giả sử response cho yêu cầu đầu tiên đó không bị hủy, do trang web thường có nhiều thành phần, nên một số lượng lớn các request tiếp theo sẽ được Browser tự động gửi lên server để download các thành phần này về Browser. Vì vậy tấn công sẽ chỉ khiến người dùng cảm thấy trang web đó thiếu nhiều thành phần, tuy vậy đến trang web sau proxy applet đã nhận ra có node độc hại, và chuyển SOAP, vì vậy người dùng lại cảm thấy thoải mái và truy cập Website bình thường. 4.4.4 Đánh giá hiệu năng của chương trình cải tiến Để đánh giá hiệu năng của chương trình cải tiến so với chương trình gốc, ta thực hiện so sánh thời gian truy cập của hai chương trình vào một số địa chỉ khác nhau. Cụ thể, qua việc đo thời gian truy cập trung bình vào một số trang web, ta được kết quả như bảng dưới: Địa chỉ Truy cập trực tiếp Phiên bản gốc Phiên bản cải tiến 0.48 1.34 1.27 0.84 2.97 3.12 1.42 2.31 2.25 Hình 7: Thời gian truy vấn trung bình của các chương trình vào một số trang web. Các chương trình đều được chạy với kiến trúc mạng bao phủ gồm có 3 node. Thực hiện đánh giá hiệu năng của chương trình cải tiến so với chương trình gốc thông qua việc so sánh thời gian truy cập trong trường hợp bị tấn công theo các kịch bản 1 và 2, ta được kết quả như sau: Địa chỉ Trực tiếp Phiên bản gốc (cả hai kịch bản) Phiên bản cải tiến (kịch bản 1) lần truy cập đầu tiên Phiên bản cải tiến (kịch bản 2) từ lần thứ 4 news4st.htm_local 0.48 Không kết nối 14.53 2.46 test.htm_local 0.84 Không kết nối 15.19 3.57 www.google.com 1.42 Không kết nối 16.34 3.22 Hình 8: Thời gian truy vấn trung bình của các chương trình vào một số trang web khi thực hiện chạy với kịch bản 1 và 2. Với phiên bản gốc, kết quả luôn là không thể kết nối. Kiến trúc mạng bao phủ gồm 3 node. Với kịch bản 1 cơ chế phát hiện để thay đổi mất 12 giây. Với kịch bản 2 từ lần thứ 4 truy vấn mới thành công. Các đo đạc cho thấy rõ sự bất lực của kiến trúc gốc khi 100% thử nghiệm đều không thể kết nối với trường hợp node trong mạng bao phủ bị chiếm dụng và tấn công hệ thống. Cơ chế cải tiến cho thấy một kết quả chấp nhận được và rất khả quan cho triển khai. Chương 5: KẾT LUẬN Qua thời gian nghiên cứu về phòng chống tấn công từ chối dịch vụ, đặc biệt là qua quá trình thực hiện đề tài khóa luận tốt nghiệp: “Phòng chống tấn công từ chối dịch vụ phân tán vào các Website”, tôi đã nắm được những kĩ thuật phòng chống tấn công từ chối dịch vụ và những kiến thức về mạng bao phủ, từ đó xây dựng và triển khai được kiến trúc WebSOS nhằm hạn chế được các tấn công từ chối dịch vụ vào các mục tiêu Website. Những kết quả chính mà tôi đã đạt được cũng như các kết quả hướng tới, có thể được tổng kết lại như dưới đây: 5.1 Các kết quả đã đạt được - Xây dựng được kiến trúc WebSOS với khả năng có thể chống lại mạnh mẽ các cuộc tấn công từ chối dịch vụ. Hệ thống cho phép người dùng truy cập trực tiếp vào Website, và chỉ kích hoạt khi Website bị tấn công từ chối dịch vụ. Với vùng lọc IP mạnh mẽ, cùng cơ chế xác thực người dùng hoàn hảo và việc che giấu các Servlet bí mật, Server đích được cách ly và bảo vệ rất tốt khỏi cuộc tấn công. - Thực hiện các thực nghiệm cho thấy độ trễ của hệ thống phòng chống tấn công từ chối dịch vụ là chấp nhận được, với khả năng triển khai và mở rộng cao cho các Web server công cộng phục vụ người dùng. - Thực hiện cải tiến hệ thống bằng cách đặt giả định một hoặc một vài node trong mạng bao phủ có thể bị chiếm dụng, và tấn công hệ thống bằng hình thức tấn công hủy gói tin hay tấn công toàn vẹn gói tin, khiến người dùng hợp lệ không thể truy cập hệ thống. Cách thức cải tiến cho thấy hiệu quả rõ rệt, và trong suốt với người dùng tạo cảm giác thoải mái cho người dùng cho dù là trong hoàn cảnh hệ thống đang bị tấn công. 5.2 Các kết quả hướng tới - Hướng tới việc xử lý độ trễ của kiến trúc mạng bao phủ, bằng cách phương pháp xây dựng đường đi không đối xứng, hoặc gửi response trực tiếp từ Server đích đến client. - Nằm trong đề xuất cải tiến, giả định đặt ra là một node trong mạng bao phủ có thể bị chiếm dụng và trở thành nguồn tấn công. Khi đó cơ chế xử lý đề ra là khá hiệu quả khi node thực hiện hành vi tấn công hủy gói tin. Song do giả định node trong mạng bao phủ có thể bị chiếm dụng, node đó còn có thể tham gia hành vi tấn công nguy hiểm nữa đó là hành vi tấn công gửi tràn gói tin. Việc xây dựng một cơ chế hiệu quả phát hiện, và loại bỏ các node bị chiếm dụng trong mạng bao phủ chính là mục tiêu cần hướng đến. TÀI LIỆU THAM KHẢO [1] A. C. Snoeren, C. Partridge, L. A. Sanchez, C. E. Jones, F. Tchakountio, S. T. Kent, and W. T. Strayer, "Hash-Based IP Traceback," Proceedings of ACM SIGCOMM 2001, August 2001, pp. 3–14 [2] A. Yaar, A. Perrig, and D. Song, "Pi: A Path Identification Mechanism to Defend Against DDoS Attacks," Proceedings of the IEEE Symposium on Security and Privacy, May 2003, pp. 93–107. [3] A. Yaar, A. Perrig, and D. Song, "SIFF: a stateless Internet flow filter to mitigate DDoS flooding attacks," Proceedings of the IEEE Symposium on Security and Privacy, May 2004, pp. 130–143. [4] Angelos D. Keromytis, Vishal Misra, Dan Rubenstein, SOS: Secure Overlay Services, ACM SIGCOMM 2002. [5] Angelos D. Keromytis, Vishal Misra, Dan Rubenstein, SOS: An Architecture For Mitigating DDoS Attacks, IEEE Journal on Selected Areas of Communications (JSAC), 2003, pages 176-188. [6] Angelos Stavrou, Debra L. Cook, William G. Morein, Angelos D. Keromytis, Vishal Misra, Dan Rubenstein; WebSOS: An Overlay-based System For Protecting Web Servers From Denial of Service Attacks; Computer Networks, Volume 48, Issue 5 (August 2005), pages 781 – 807. [7] C. Jin, H. Wang, and K. G. Shin, "Hop-Count Filtering: An Effective Defense Against Spoofed DDoS Traffic," Proceedings of the 10th ACM Conference on Computer and Communication Security, ACM Press, October 2003, pp 30–41. [8] C. Papadopoulos, R. Lindell, J. Mehringer, A. Hussain, and R. Govindan, "Cossack: Coordinated Suppression of Simultaneous Attacks," Proceedings of 3rd DARPA Information Survivability Conference and Exposition (DISCEX 2003), vol. 2, April 2003, pp. 94–96. [9] D. Farinacci, T. Li, S. Hanks, D. Meyer, P. Traina, Generic Routing Encapsulation (GRE), RFC 2784, IETF (March 2000). URL [10] Debra L. Cook, William G. Morein, Angelos D. Keromytis, Vishal Misra, Daniel Rubenstein; WebSOS: Protecting Web Servers From DDoS; Proceedings of the 11th IEEE International Conference on Networks (ICON) (2003); pages 455–460. [11] E. O'Brien. "NetBouncer: A Practical Client-Legitimacy-Based DDoS Defense via Ingress Filtering," [12] Elaine Shi, Ion Stoica, David Andersen, Adrian Perrig, “OverDoSe: A Generic DDoS Protection Service Using an Overlay Network”, CMU Technical Report CMU-CS-06-114, 2006 [13] G. Dommety, Key and Sequence Number Extensions to GRE, RFC 2890, IETF (September 2000). URL [14] Ion Stoica, Robert Morris, David Karger, M. Frans Kaashoek, Hari Balakrishnan, Chord: A Scalable Peer-to-peer Lookup Service for Internet Applications, ACM Sigcomm 2001. [15] J. Mirkovic, D-WARD: Source-End Defense Against Distributed Denial-of-Service Attacks, PhD thesis, University of California Los Angeles, August 2003, [16] J. Mirkovic, M. Robinson, P. Reiher, and G. Kuenning, "Forming Alliance for DDoS Defenses," Proceedings of the New Security Paradigms Workshop (NSPW 2003), ACM Press, August 2003, pp. 11–18. [17] Jelena Mirkovic, Sven Dietrich, David Dittrich, Peter Reiher; Internet Denial of Service: Attack and Defense Mechanisms.chm ; Prentice Hall PTR; 2004. [18] Michael Glenn; A Summary of DoS/DDoS Prevention, Monitoring and Mitigation Techniques in a Service Provider Environment; SANS Institute; 2003. [19] R. Mahajan, S. M. Bellovin, S. Floyd, J. Ioannidis, V. Paxson, and S.Shenker, "Controlling High Bandwidth Aggregates in the Network," ACM SIGCOMM Computer Communications Review, vol. 32, no. 3, July 2002, pp. 62–73. [20] S. Bellovin, M. Leech, and T. Taylor, "ICMP Traceback Messages," Internet draft, work in progress, October 2001. [21] S. Savage, D. Wetherall, A. Karlin, and T. Anderson, "Practical Network Support for IP Traceback," Proceedings of ACM SIGCOMM 2000, August 2000, pp. 295–306 [22] [23]