AODV là một giao thức định tuyến theo yêu cầu cho mạng ad hoc di động. Mặc dù ban đầu được thiết kế cho mạng ad hoc nhưng hiện nay giao thức này đã được sử dụng cho cả mạng không dây mesh. AODV cho phép các thiết bị không dây có thể trao đổi dữ liệu bằng cách truyền lại các gói dữ liệu thông quá các nút lân cận của chúng nếu chúng không thể trực tiếp liên lạc được với nút đích. Lưu lượng dữ liệu được chuyển đến đích với sự trợ giúp của các thiết bị trung gian có hỗ trợ quá trình định tuyến.
Thông báo điều khiển: để hoạt động, AODV định nghĩa 4 loại thông báo điều khiển UDP, mỗi một loại mang thông tin định tuyến cho một vai trò cụ thể: RREQ - RREP - RERR - RREP ACK.
* Yêu cầu định tuyến (RREQ): yêu cầu được phát quảng bá để khám phá tuyến đường
đến đích khi không có tuyến đường nào được biết (xác định). Nó bao gồm thông tin về nút nguồn, nút đích, thời gian sống của gói tin IP và một định danh duy nhất kết hợp với địa chỉ của người gửi nhằm phát hiện và tránh các vòng lặp và để phân biệt các bản RREQ tràn ngập trên mạng không dây mesh.
Hình 3.1: Quá trình lan truyền thông báo RREQ
* Trả lời định tuyến (RREP): câu trả lời được sinh ra bởi nút đích hoặc bất kỳ một nút
trung gian với tuyến đường được cập nhật đến đích nhưng là một câu trả lời cho thông báo yêu cầu định tuyến.
* Lỗi định tuyến (RERR): thông báo lỗi được phát quảng bá để thông báo điểm đến
không thể truy cập (đạt tới) được. Khi một nút nhận được thông báo lỗi, nó gỡ bỏ tất cả các tuyến đường đã đề cập đến nút này trong bảng định tuyến của mình. Sau đó nó tiếp tục lan truyền tin nhắn này đến những nút trước nó. Nút trước nó là nút lân cận đã chuyển tiếp thông báo yêu cầu định tuyến cho nút đã cho.
* Xác nhận trả lời định tuyến (RREP ACK): là một thông báo không bắt buộc, nó được
sinh ra chỉ khi một yêu cầu rõ ràng cho sự thừa nhận được tạo ra bởi thông báo yêu trả lời định tuyến.
Số tuần tự (Sequence numbers): thông báo AODV được nhúng số tuần tự. Những số này được sử dụng bởi các nút cho trước để đánh giá độ “tươi” của thông tin duy trì cục bộ về các nút lân cận của nó. Mỗi nút lưu một số tuần tự của các nút mà nó giao tiếp. Số càng cao thì các thông tin liên quan đến nó càng mới. Sau khi nhận tin nhắn điều khiển, số tuần tự được đóng gói trong gói tin được so sánh với số tuần tự cuối cùng nút nhận đang lưu trữ về nút truyền tải và quá trình cập nhật xảy ra chỉ khi nếu số nhận được lớn hơn số đang được lưu trữ. Điều kiện này đảm bảo rằng đường truyền mới nhất được lựa chọn, và cũng đảm bảo không bị lặp vòng.
Hình 3.2: Quá trình truyền thông báo RREP và cập nhật số tuần tự 3.1.2 Tấn công lỗ đen trong giao thức AODV [4]-[5]-[13]-[18]
Trong một mạng không dây sử dụng giao thức AODV, một nút Lỗ đen hấp thụ lưu lượng và bỏ tất cả các gói tin. Một cuộc tấn công lỗ đen được mô tả như hình dưới đây:
Ở hình 3.3, giả sử nút 3 là nút độc hại. Khi nút 1 phát tán thông báo yêu cầu định tuyến với nút 4, nút 3 lập từ trả lời nút 1 với thông báo RREP bao gồm số tuần tự lớn nhất của nút 4 như thể nó được đến từ nút 4. Nút 1 cho rằng nút 4 đứng ngay sau nút 3 với khoảng cách 1 chặng và từ chối thông gói tin RREP đến từ nút 2. Sau đó, nút 1 bắt đầu gửi dữ liệu đến nút 3 và tin rằng dữ liệu này sẽ được chuyển đến nút 4 nhưng nút 3 sẽ bỏ tất cả các gói dữ liệu chuyển đến.
Trong một cuộc tấn công lỗ đen, sau một thời gian, nút gửi sẽ nhận ra rằng có lỗi đường truyền vì nút nhận được không gửi các gói tin TCP ACK. Nếu nó gửi đi các gói dữ liệu TCP mới và tìm kiếm tuyến đường mới đến nút đích, nút độc hại vẫn tiếp tục đánh lừa nút gửi. Nếu nút gửi gửi đi các gói dữ liệu UDP thì việc tấn công sẽ khó phát hiện được bởi vì các kết nối dữ liệu UDP không chờ đợi để nhận các gói ACK.
Các kịch bản mô phỏng dưới đây sử dụng các gói tin UDP. Các mô phỏng sử dụng chương trình mô phỏng NS2 sẽ miêu tả ảnh hưởng của hành động tấn công lỗ đen đến giao thức AODV trên một số kịch bản cụ thể.
3.1.3. Bộ mô phỏng mạng NS2 [2]-[21]
NS (Network Simulator) là bộ mô phỏng mạng theo sự kiện rời rạc được phát triển ở trường đại học Berkely bang California đầu tiên bắt nguồn từ dự án VINT được bộ quốc phòng Mỹ cấp kinh phí phát triển. NS được phát triển từ bộ mô phỏng REAL của S. Keshav từ năm 1989, còn REAL thì bắt nguồn từ bộ mô phỏng NEST. Các phiên bản NS version 2 ra đời sau năm 1997 và từ đó người ta thường gọi bộ mô phỏng là NS-2. NS-2 được viết trên hai ngôn ngữ hướng đối tượng là C++ và OTcl. C++ được sử dụng để xây dựng phần nhân của bộ mô phỏng để đảm bảo tốc độ thực hiện cao và thay đổi. OTcl được sử dụng để xây dựng phần giao tiếp với người sử dụng (shell), giúp người sử dụng dễ dàng thiết lập cấu hình mạng, lựa chọn giao thức truyền thông, thiết lập các nguồn sinh lưu lượng, các mô hình sinh lỗi v.v.
Hình 3.4. Mô hình bộ mô phỏng NS-2
NS-2 là kịch bản hướng đối tượng, bộ thông dịch nó chứa bộ lập lịch các sự kiện (Event Scheduler) và thư viện đối tượng các thành phần mô phỏng mạng (Network Component Object), thư viện module thiết lập mạng. Nói cách khác, người dùng NS lập trình bằng ngôn ngữ kịch bản OTcl lập lịch các sự kiện trên một đồ hình mạng cụ thể sau đó chạy mô phỏng mạng, thông qua trình thông dịch trong NS-2 để đưa kết quả ra 2 loại tệp chính: đó là tệp vết (trace file), có tên mở rộng là *.tr, ghi lại tất cả các sự kiện mạng. Loại tệp thứ hai có tên mở rộng là *.nam, có khuôn dạng tương tự tệp vết, được sử dụng
làm đầu vào cho chương trình hiển thị kết quả mô phỏng dưới dạng đồ hoạ là chương trình NAM.
NS được cải tiến và mở rộng không ngừng, trung bình cứ 6 tháng người ta lại đưa ra một phiên bản mới, trong đó đã sửa chữa các khiếm khuyết được cộng đồng sử dụng phát hiện và bổ sung thêm một số khả năng mô phỏng mới. Phiên bản đầu tiên được giới thiệu và sử dụng rộng rãi là NS-2.1b2, phiên bản mới nhất, tính đến giữa năm 2008 là NS-2.34. Ngày nay, cộng đồng sử dụng NS-2 gồm hàng nghìn trường đại học, viện nghiên cứu, công ty… và hàng vạn người trên thế giới. Các kết quả nghiên cứu bằng NS-2 là đáng tin cậy và được cộng đồng nghiên cứu về mạng thừa nhận.
3.2. Mô phỏng tấn công lỗ đen trong chương trình NS-2
Phần này đánh giá sự ảnh hưởng của các tấn công lỗ đen đến các mạng không dây. Chương trình mô phỏng được sử dụng là chương trình NS-2.34. Một giao thức được thiết kế để mô phỏng việc thực hiện tấn công lỗ đen. Giao thức này bỏ tất cả các gói tin sau khi thu hút chúng về mình.
3.2.1. Cài đặt giao thức mô phỏng hành vi lỗ đen vào NS2
Giao thức này sử dụng các nút có biểu hiện hành vi lỗ đen trong mạng không dây sử dụng giao thức AODV. Khi các nút hoạt động như một lỗ đen, chúng sẽ sử dụng một giao thức định tuyến mới có thể tham gia vào thông báo AODV. Trong bộ mô phỏng NS-2.34, giao thức mới blackholeAODV được cài đặt như sau:
- Copy thư mục chứa giao thức AODV và đổi tên thành blackholeaodv.
- Điểm lưu ý là cả giao thức AODV và giao thức blackholeAODV đều gửi các gói tin AODV đến lẫn nhau. Do đó file “aodv_packet.h” sẽ không được sao chép sang thư mục blackholeaodv.
- Đổi tên tất cả các file có tên là aodv trong thư mục thành “blackholeaodv”:
blackholeaodv.cc, blackholeaodv.h, blackholeaodv.tcl, blackholeaodv_rqueue.cc, blackholeaodv_rqueue.h (ngoại trừ file “aodv_packet.h”).
- Thay đổi một số nội dung (lớp, hàm, cấu trúc, biến, hằng,…) trong các file trong thư mục này ngoại trừ tên cấu trúc mã AODV packet.h. Hai giao thức AODV và blackhole AODV được thiết kế để có thể gửi các gói dữ liệu cho nhau, do đó cũng gần tương tự như nhau.
Để các hành vi lỗ đen thực hiện được trong giao thức mới. Ta thêm hành vi lỗ đen vào giao thức blackholeAODV với một số thay đổi trong file
blackholeaodv/blackholeaodv.cc. Quá trình thay đổi được mô tả như sau:
- Khi một gói tin nhận được bởi hàm “recv” của “aodv/aodv.cc”, nó xử lý các gói tin dựa vào dạng của nó. Nếu dạng gói tin là một trong nhiều gói tin quản lý (điều khiển) tuyến đường, nó gửi gói tin đến hàm “recvAODV”.
- Nếu gói tin nhận được là gói dữ liệu, thông thường giao thức AODV sẽ gửi nó đến địa chỉ đích, nhưng nếu là hoạt động lỗ đen, nó sẽ bỏ gói tin dữ liệu miễn là gói tin không
truyền đến chính nó. Câu lệnh dưới đây mô tả: nếu nút đích là chính nó thì nó sẽ nhận gói tin, ngược lại, nó loại bỏ tất cả các gói tin còn lại.
if ( (u_int32_t)ih->saddr() == index)
forward((blackholeaodv_rt_entry*) 0, p, NO_DELAY); else
drop(p, DROP_RTR_ROUTE_LOOP);
- Nếu gói tin là một gói tin điều khiển AODV, hàm “recv” gửi nó đến hàm
“recvblackholeAODV”. Hàm “recvblackholeAODV” kiểm tra loại của gói tin điều khiển và dựa vào mỗi loại gói tin nó sẽ gửi chúng đến các hàm thích hợp với câu lệnh
“case”. Ví dụ, các gói tin RREQ sẽ được gửi đến hàm “recvRequest”, các gói tin RREP sẽ được gửi đến hàm “recvReply”. Câu lệnh “case” như sau:
case AODVTYPE_RREQ: recvRequest(p); break; case AODVTYPE_RREP: recvReply(p); break; case AODVTYPE_RERR: recvError(p); break; case AODVTYPE_HELLO: recvHello(p); break; default:
fprintf(stderr, "Invalid blackholeAODV type (%x)\n", ah>ah_type);
exit(1);
- Trong trường hợp này ta xét đến hàm recvRequest RREQ vì hành động lỗ đen được thực hiện khi các nút độc hại nhận được gói tin RREQ. Khi nút độc hại nhận được một gói tin RREQ, ngay lập từ nó gửi thông báo RREP như là nó đã có đường đến đích. Nút độc hại cố gắng đánh lừa nút gửi bằng gói RREP. Số tuần tự lớn nhất của giao thức AODV là 4294967295 với giá trị số nguyên 32 bít. Số tuần tự được đặt là 4294967295 và số đếm hop được đặt là 1. Thông báo RREP giả trong tấn công lỗ đen được thể hiện như sau:
sendReply(rq->rq_src, // IP Destination 1, // Hop Count
index, // Dest IP Address
4294967295, // Highest Dest Sequence Num MY_ROUTE_TIMEOUT, // Lifetime
rq->rq_timestamp); // timestamp
Sau một số thay đổi như trên, ta tiến hành tích hợp giao thức blackholeAODV vào bộ mô phỏng và biên dịch lại chương trình NS-2 để tạo ra các file đối tượng. Ở một số hướng dẫn tích hợp một giao thức mới vào bộ mô phỏng NS-2 cần phải thay đổi nhiều file để sử dụng được các gói tin của nó. Nhưng trong giao thức blackholeAODV này không cần thiết phải thêm giao thức mới, do đó chỉ cần thay đổi 2 file (Makefile và ns-lib.tcl) của
NS-2. Quá trình thay đổi như sau:
- Đầu tiên ta thay đổi file “\tcl\lib\ ns-lib.tcl”, nơi mà các thực thể (agent) được mã hoá thành các thủ tục. Khi một nút sử dụng giao thức blackholeAODV, agent được ghi ở phần đầu mô phỏng và được gán cho các nút sử dụng giao thức backholeAODV. Những dòng sau sẽ được thêm vào:
blackholeAODV {
set ragent [$self create-blackholeaodv-agent $node] }
…
Simulator instproc create-blackholeaodv-agent { node } { set ragent [new Agent/blackholeAODV [$node node-addr]] $self at 0.0 "$ragent start" # start
BEACON/HELLO Messages
$node set ragent_ $ragent return $ragent
}
- Tiếp theo, ta thay đổi file “\Makefile” trong thư mục gốc “ns-2.34”. Thêm những dòng sau: blackholeaodv/blackholeaodv_logs.o blackholeaodv/blackholeaodv.o \
blackholeaodv/blackholeaodv_rtable.o blackholeaodv/blackholeaodv_rqueue.o \ - Sau khi thực hiện các thay đổi trên, ta dùng các lệnh make clean, make để biên dịch
lại NS2.
3.2.2. Thử nghiệm blackholeAODV
Để thử nghiệm việc thực hiện giao thức blackholeAODV trong NS-2. Hai kịch bản được sử dụng để mô phỏng. Kịch bản thứ nhất không sử dụng nút Black Hole (nút thực hiện tấn công lỗ đen). Kịch bản thứ hai thêm vào nút Black Hole. Chương trình mô phỏng NAM (Network Animator) được sử dụng để so sánh kết quả giữa hai kịch bản mô phỏng.
3.2.2.1. Thông số và các số đo mô phỏng:
Mô phỏng sử dụng giao thức UDP. Nút nguồn duy trì gửi các gói tin UDP, thậm chí cả khi nút độc hại loại bỏ chúng (trong khi đó nút sẽ gửi sẽ ngừng gửi gói tin nếu sử dụng giao thức TCP). Do đó, ta có thể quan sát được dòng kết nối giữa nút gửi và nút nhận trong quá trình mô phỏng. Thêm vào đó ta có thể tính riêng các gói tin gửi và nhận trong kết nối UDP không bị mất trong quá trình mô phỏng. Nếu sử dụng giao thức TCP trong kịch bản mô phỏng, ta không thể tính toán gói tin gửi và nhận khi nút bắt đầu kết nối TCP sẽ kết thúc kết nối sau một thời gian không nhận được gói tin TCP ACK.
Kịch bản tạo ra một mạng nhỏ gồm 7 nút di động (đánh số từ 2 đến 8), 1 nút có dây (Nút 0) và 1 nút Base Station (Nút 1), trong đó nút có dây kết nối với nút Base Station qua một kết nối có dây. Mô phỏng tạo ra kết nối UDP giữa nút Base Station và Nút 3, gắn vào nguồn CBR (Constant Bit Rate) để sinh ra các gói tin không đổi cho kết nối UDP. Kích thước gói tin CBR là 512, tốc độ dữ liệu là 512kb. Trong khoảng thời gian 20 giây, nguồn CBR bắt đầu truyền vào khoảng thời gian 1 giây và tiếp tục truyền đến hết thời gian mô phỏng. Trong một không gian phẳng 500x500m. Vị trí của các nút được đặt thích hợp để
hiển thị dòng dữ liệu và mô phỏng thể hiện sự di chuyển của Nút 6 để chỉ ra sự thay đổi dòng dữ liệu trong mạng.
3.2.2.2. Đánh giá mô phỏng
Kịch bản đầu tiên không có nút Black Hole, kết nối giữa Base Station và Nút 3 sử dụng giao thức AODV.
Hình 3.5: Dữ liệu truyền từ Base Station đến nút 3 bằng giao thức AODV khi nút 6 di chuyển
Trong kịch bản mô phỏng thứ hai, ta thêm nút Black Hole là Nút 2 trong file Tcl bằng 3 dòng lệnh sau:
$ns_ node-config -adhocRouting blackholeAODV set node_(2) [ $ns_ node [lindex $temp 1] ]
$node_(2) set X_ 50.0 $node_(2) set Y_ 420.0 $node_(2) set Z_ 0.0
$ns_ node-config -adhocRouting $opt(adhocRouting) for {set j 3} {$j < [expr $val(nn)+ 2]} {incr j} {
set node_($j) [ $ns_ node [lindex $temp [expr $j- 1]] ] }
- Dòng lệnh “$ns node-config -adhocRouting blackholeAODV” nhằm thêm giao thức blackholeAODV để tạo nút.
- Dòng lệnh thứ hai: định nghĩa Nút 2 là nút Black Hole
- Dòng lệnh thứ ba: chuyển sang tạo các nút bằng giao thức AODV.
Nút 2 là nút Black Hole hấp thụ tất cả các gói tin từ đường truyền từ nút Base Station đến nút 3. Hình dưới đây chỉ ra cách nút blackholeAODV hấp thụ lưu lượng truyền.
Hình 3.6: Nút 2 (nút Black Hole) hấp thụ kết nối từ Base Station đến nút 3
3.3. Giải pháp chống lại tấn công lỗ đen và hiệu quả của nó
3.3.1. Ý tưởng thực hiện
Ở phần trước đã trình bày tấn công lỗ đen, thực hiện tấn công mô phỏng trên NS-2 và trình bày kết quả đạt được của tấn công. Khi kiểm tra tệp vết (trace file) của mô phỏng trong đó có 1 nút Black Hole ta nhận thấy một thời gian sau khi thông báo RREP thứ nhất (thông báo của nút Back Hole) đến nút nguồn thì thông báo RREP thứ hai đến nút nguồn là thông báo của nút đích thực sự.
Qua phân tích tệp vết của kịch bản mô phỏng ở Hình 3.6, với Nút Base Station là nút gửi, Nút 3 là nút nhận và Nút 2 là nút Black Hole. Trong bảng dưới đây, ta dễ dàng nhận thấy có hai thông báo RREP. Thông báo thứ nhất gửi từ nút Blackhole (Nút 2) đến nút nguồn