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.
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 WebSOS3.3.1 Giải pháp đề xuất 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ó. (adsbygoogle = window.adsbygoogle || []).push({});
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