V là tập các thuật toán kiểm thử.
2.3. Giải pháp giám sát chống tấn công flooding RREQ trong giao thức AODVL
AODVLV
Trong thiết kế giao thức AODV, các nút phải phát quảng bá gói tin RREQ khi cần truyền dữ liệu đến một đích nào đó mà nó không tìm thấy đƣờng đi trong bảng định tuyến. Và một nút không nên tạo vƣợt quá RREQ_RATELIMIT trong một giây. Tuy nhiên một nút độc hại có thể bỏ qua giới hạn này và bơm vào mạng một lƣợng lớn gói tin giả RREQ tới một địa chỉ đích không xác định, dẫn tới việc:
- Các nút liên tục phải xử lý tiêu hao năng lƣợng.
- Tiêu tốn bộ nhớ khi phải duy trì thông tin định tuyến cho các yêu cầu giả.
- Băng thông mạng bị chiếm dụng, dẫn tới dịch vụ bị ngƣng trệ.
- Các tuyến đƣờng tìm đƣợc của các yêu cầu tìm đƣờng hợp pháp có thể dài hơn, dẫn đến tiêu tốn băng thông, năng lƣợng mạng.
Khi số lƣợng gói tin tăng lên đủ lớn, băng thông mạng tắc nghẽn, năng lƣợng nút cạn kiệt và đánh sập cả mạng. Đây là kiểu tấn công flooding RREQ.
Giải pháp an ninh sử dụng chữ ký số sẽ dẫn tới chi phí cho việc tìm đƣờng cao hơn nhiều khi phải xác thực tại mỗi nút nhận, kích thƣớc của gói tin cũng tăng hơn rất nhiều do phải gửi kèm chứng chỉ số để xác thực, càng dẫn tới việc dễ bị tấn công flooding RREQ. Vậy cần thiết phải bổ sung cơ chế chống tấn công flooding RREQ cho giao thức AODVLV.
Một số giải pháp trƣớc đó:
Trong [17], tác giả đƣa ra cách tiếp cận sử dụng hai giới hạn: RATE_LIMIT và BLACKLIST_LIMIT. Nếu số RREQ của bất cứ nút nào nhỏ hơn RARE_LIMIT thì xử lý yêu cầu, nếu vƣợt quá BLACKLIST_LIMIT thì chặn xử lý yêu cầu của từ nút. Nhƣng nếu số RREQ lớn hơn RATE_LIMIT và nhỏ hơn BLACKLIST_LIMIT thì đặt RREQ vào hàng đợi và xử lý sau thời gian xảy ra time out hàng đợi.
Trong [5], tác giả đề xuất thuật toán:
L= RREQ_RATELIMIT LT= RREQ_ACCEPT_LIMIT M= RREQ_BLACKLIST_LIMIT
Mỗi khi một nút nhận một gói RREQ từ hàng xóm của nó: Tăng giá trị rreq_count cho nút hàng xóm đó.
If (rreq_count < LT)
Xử lý gói RREQ Else if (rreq_count > M)
Đưa vào danh sách blacklist, khai báo là nút
độc hại
If (nút bị khai báo là độc hại)
Drop dữ liệu nhận được từ nó. Else if (rreq_count > L)
Bỏ qua tất cả các gói RREQ
Mỗi nút sẽ lƣu một biến đếm số lƣợng gói RREQ mà nó nhận đƣợc từ mỗi hàng xóm của nó. Mỗi lần nhận đƣợc một gói RREQ, nó tăng biến đếm lên một. Nếu biến đếm này nhỏ hơn RREQ_ACCEPT_LIMIT, gói RREQ đƣợc xử lý. Nếu biến đếm lớn hơn RREQ_BLACKLIST_LIMIT, đƣa hàng xóm vào danh sách chặn xử lý RREQ, khai báo là nút độc hại, hủy bỏ tất cả gói tin nhận
đƣợc từ nút độc hại. Nếu biến đếm lớn hơn RREQ_RATELIMIT thì bỏ qua không xử lý RREQ.
Ngoài ra còn một số đề xuất tƣơng tự khác, đặc điểm chung của các đề xuất này là giám sát số gói tin RREQ trong khoảng thời gian một giây có vƣợt quá giới hạn RREQ_BLACKLIST_LIMIT, nếu vƣợt quá thì sẽ đƣa vào danh sách chặn xử lý RREQ. Một số bài báo giả định giá trị RREQ_BLACKLIST_LIMIT bằng RREQ_RATELIMIT và bằng 10 (giá trị tham số mặc định của giao thức định tuyến AODV). Nhƣ vậy nếu một nút nhận từ hàng xóm của nó từ 10 gói RREQ trở lên thì sẽ bị đƣa vào danh sách chặn.Vậy nếu một kẻ tấn công nghiên cứu về giao thức và nó thay đổi cách tấn công bằng cách gửi 9 gói trong vòng 1 giây chẳng hạn thì trong vòng 10 giây nút tấn công gửi đƣợc 90 gói, cứ thế số lƣợng gói tin trong mạng cực kỳ lớn dẫn tới, các nút mạng liên tục phải xử lý tiêu tốn năng lƣợng toàn mạng mà vẫn không phát hiện đƣợc nút tấn công.
Nếu áp dụng phƣơng pháp này trong một mạng sử dụng chữ ký số thì những tấn công flooding RREQ ở tần số thấp hơn cũng có thể gây tê liệt mạng. Ngoài ra các phƣơng pháp này đều theo dõi các hàng xóm của nó nên khi đƣa vào danh sách chặn có thể chƣa chặn đƣợc nút tấn công, điều này dẫn tới việc nút tấn công có thể di chuyển sang vị trí khác vẫn tiếp tục thực hiện đƣợc cuộc tấn công. Đến một lúc nào đó, có thể làm cho hoạt động mạng bị ngƣng trệ do các nút không phải nút tấn công bị chặn.
Trong khuôn khổ luận văn, tác giả có đƣa ra một đề xuất nhỏ có thể giảm thiểu kiểu tấn công flooding RREQ ở tần suất thấp hơn và hạn chế đƣợc khả năng nút tấn công di chuyển sang vị trí khác để tiếp tục tấn công.
ĐỀ XUẤT
Do sử dụng chữ ký số nên khi nhận gói RREQ ta có thể chắc chắn đƣợc nút nguồn phát RREQ. Thế nên thay vì theo dõi số gói tin RREQ của các nút hàng xóm của nó ta sẽ theo dõi nút nguồn phát RREQ, điều này giúp việc ngăn chặn tận gốc nguồn tấn công và hạn chế khả năng tấn công khi nó di chuyển sang vị trí khác.
RREQ_BLACKLIST1 : Số lƣợng gói tin RREQ tối đa một nút nguồn phát trong vòng 1 giây.
RREQ_BLACKLIST2 : Số lƣợng gói tin RREQ tối đa một nút nguồn phát trong vòng 2 giây.
RREQ_BLACKLIST3 : Số lƣợng gói tin RREQ tối đa một nút nguồn phát trong vòng 3 giây.
BLACKLIST_TIMEOUT: Thời gian bị đƣa vào danh sách chặn lần đầu tiên. Mỗi lần sau bị chặn thời gian sẽ đƣợc tăng lên gấp 2 lần.
Trong đó:
RREQ_BLACKLIST1 = RREQ_RATELIMIT = 10
RREQ_BLACKLIST2 = 2 * ( RREQ_RATELIMIT – 1) – 1 = 17 RREQ_BLACKLIST3 = 3 * ( RREQ_RATELIMIT – 2) – 1 = 23
Nhƣ vậy:
- Nếu một nút cứ đều đều gửi 10 gói/1s thì vƣợt quá RREQ_BLACKLIST1 (10gói/1s), nút nguồn phát sẽ bị chặn.
- Nếu một nút cứ đều đều gửi 9 gói/1s thì trong vòng 2 giây nó gửi 18gói/2s vƣợt quá RREQ_BLACKLIST2 (17 gói/2s), nút nguồn phát sẽ bị chặn. - Nếu một nút cứ đều đều gửi 8 gói/1s thì trong vòng 2 giây nó gửi 24gói/3s vƣợt quá RREQ_BLACKLIST3(23 gói/3s), nút nguồn phát sẽ bị chặn.