Chương 2: GIẢI PHÁP CHỐNG TẤN CÔNG GIAO THỨC ĐỊNH TUYẾN AODV TRONG MẠNG MANET
2.3. Giải pháp giám sát chống tấn công flooding RREQ trong giao thức 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.
Sử dụng ba giá trị (Có thể sử dụng nhiều hơn):
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.
LƯU ĐỒ THUẬT TOÁN
Nhận RREQ
Có phải flooder không?
Làm mới danh sách chặn
Nút nguồn hoặc nút hàng xóm có trong
danh sách chặn?
không?
Xác thực chữ ký
#1 Nút nguồn đã đƣợc
theo dõi chƣa?
Bổ sung vào danh sách theo dõi Xác thực hop count
Hủy gói
Hủy gói
Hủy gói Hủy gói
Xử lý RREQ
Có
Không
Có
Không
Sai
Sai Đúng
Đúng
Chƣa
Rồi
Hình 2.8: Lưu đồ thuật toán xử lý khi nhận một gói RREQ
Level 1 >= RREQ_BLACKLIST1
|| Level 2 >= REQ_BLACKLIST2
|| Level 3 >= REQ_BLACKLIST3
Nguồn đã bị chặn lần nào chƣa?
Đƣa vào danh sách chặn
- Tăng số lần chặn - Lưu thời gian chặn
Reset lại các biến đếm
Xử lý RREQ
#1
Kiểm tra tần suất gửi gói tin
theo các mức:
- Làm mới các biến đếm Level1, Level2, Level3 - Tăng các biến đếm lên 1
Sai
Đúng
Chƣa
Rồi
2.4. Mức độ an ninh của giao thức định tuyến AODVLV
Giao thức định tuyến AODVLV sử dụng chứng chỉ số để xác thực nên nó có thể chống được tương đối nhiều kiểu tấn công. Sau đây sẽ là phân tích khả năng chống tấn công đối với một vài kiểu tấn công cơ bản:
- Đối với kiểu tấn công sửa đổi (Attack using Modification), kẻ tấn công thực hiện thay đổi một hoặc một số trường trong gói tin như sửa đổi sequence number, sửa đổi hop count, sửa đổi nguồn,…Nhƣ vậy giao thức AODVLV có thể chống đƣợc kiểu tấn công này do việc một nút thay đổi bất kỳ thông tin nào cũng làm cho chữ ký bị sai khi xác thực.
- Đối với kiểu tấn công đóng giả (Attacks using Impersonation), kẻ tấn công tấn công vào tính xác thực và tính bí mật của mạng. Nó thực hiện giả làm một nút khác để thực hiện trả lời một gói tin tìm đường hoặc phát ra một gói tin tìm đường nhằm thay đổi hình trạng mạng hoặc tham gia vào tuyến đường truyền thông,… Trong giao thức AODVLV, do một nút khi tham gia vào mạng nó sẽ được CA cấp cho một chứng chỉ, tương ứng với địa chỉ IP của nó. Kẻ tấn công không thể tự tạo được cho nó chứng chỉ tương ứng với một địa chỉ IP nào khác để có thể tham gia xác thực trong mạng đƣợc. Vậy giao thức AODVLV có thể chống đƣợc kiểu tấn công này.
- Đối với kiểu tấn công chế tạo (Attacks using Fabrication): Kẻ tấn công thực hiện “bơm” vào mạng những gói tin giả, gói tin định tuyến sai để làm sai lệch thông tin định tuyến. Kiểu tấn công này rất khó phát hiện nếu không có một cơ chế xác thực. Trong giao thức AODVLV, một nút không thể tạo ra một gói tin giả mạo làm một nút khác do không thể tự tạo chứng chỉ số.
- Đối với kiểu tấn công lỗ đen ( Blackhole attack): Kẻ tấn công thực hiện trả lời ngay lập tức khi nhận được một gói tin tìm đường với sequence number đủ lớn và hop count đủ nhỏ để nút nguồn tưởng rằng đó là đường đi mới nhất và ngắn nhất đi đến đích. Trong giao thức AODVLV, nút nguồn chỉ thiết lập đường đi tới đích khi nhận và xác thực gói tin trả lời từ nút đích. Giao thức AODVLV chống đƣợc kiểu tấn công lỗ đen.
- Đối với kiểu tấn công grayhole, cũng là một loại tấn công từ chối dịch vụ. Tấn công grayhole là kiểu tấn công mở rộng của tấn công blackhole. Kẻ tấn công chủ động tấn công và hành vi của nó không thể đoán trước. Nó thực hiện chuyển tiếp gói tin định tuyến như hành vi của nút bình thường và thực hiện hủy
gói tin vào một thời điểm nào đó. Kẻ tấn công cũng chỉ chủ động tấn công vào một vài điạ chỉ xác định, ngoài ra nó vẫn chuyển tiếp các gói tin từ các địa chỉ khác như bình thường. Tuy nhiên cũng giống như kiểu tấn công blackhole, tấn công grayhole cũng phải thực hiện gửi gói tin trả lời tuyến đường với sequence number đủ lớn và hop count đủ nhỏ để tham gia được vào tuyến đường. Vậy giao thức AODVLV chống đƣợc kiểu tấn công này.
- Đối với kiểu tấn công flooding: có thể là flooding RREQ hoặc flooding dữ liệu. Nhƣ mô tả ở phần trên, giao thức AODVLV có cài đặt một cơ chế giám sát số lƣợng gói tin RREQ đến từ một nguồn trong toàn mạng dựa trên chứng thực chữ ký số nên có thể hạn chế kiểu tấn công flooding RREQ và hạn chế một nút di chuyển tới vị trí khác để tiếp tục cuộc tấn công. Đối với tấn công flooding dữ liệu thì giao thức AODVLV chƣa cài đặt cơ chế để chống kiểu tấn công này.
- Đối với kiểu tấn công wormhole: Đây là một kiểu tấn công rất đặc biệt, kẻ tấn công sử dụng 2 nút kết hợp: khi nhận đƣợc gói tin ở một đầu nó sẽ
“tunnels” những gói tin này tới đầu kia, sau đó phát lại vào mạng. Nhƣ vậy nó có nhiều cơ hội tham gia vào tuyến đường truyền thông hơn các nút khác do có metric tốt hơn. Đây là kiểu tấn công rất khó phát hiện do kẻ tấn công không làm thay đổi thông tin trong gói tin. Có một vài giải pháp chống wormhole đã đƣợc nghiên cứu nhƣ: giải pháp Packet Leashes [29]. Giao thức AODVLV không chống đƣợc kiểu tấn công wormhole.