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 tại thời điểm 1.004809200s. Thông báo thứ hai gửi từ nút đích (Nút 3) đến nút nguồn tại thời điểm 1.080309923s.
s -t 1.004809200 -Hs 2 -Hd 4194304 -Ni 2 -Nx 50.00 -Ny 420.00 -Nz 0.00 -Ne -1.000000 -Nl MAC -Nw --- -Ma 13a -Md 0 -Ms 1 -Mt 800 -Is 4194305.255 -Id 4194304.255 -It AODV -Il 102 -If 0 -Ii 0 -Iv 30 -P aodv -Pt 0x4 -Ph 1 -Pd 4194306 -Pds -1 -Pl 10.000000 -Pc REPLY
...
s -t 1.080309923 -Hs 3 -Hd 4194311 -Ni 3 -Nx 480.00 -Ny 50.00 -Nz 0.00 -Ne -1.000000 -Nl MAC -Nw --- -Ma 13a -Md 7 -Ms 2 -Mt 800 -Is 4194306.255 -Id 4194304.255 -It AODV -Il 102 -If 0 -Ii 0 -Iv 30 -P aodv -Pt 0x4 -Ph 1 -Pd 4194306 -Pds 4 -Pl 10.000000 -Pc REPLY
Khi nút Black Hole gửi thông báo RREP không cần kiểm tra bảng định tuyến, ta giả định rằng nhiều khả năng thông báo RREP đầu tiên sẽ đến từ nút Black Hole. Trong một số
trƣờng hợp, ý tƣởng này không thực hiện đƣợc. Ví dụ, thông báo RREP thứ hai có thể đƣợc tiếp nhận ở nút nguồn từ một nút trung gian nào đó mà thông tin không đủ mới (fresh) về nút đích hoặc thông báo RREP thứ hai có thể là thông báo đến từ nút Black Hole nếu nút đích thực sự của nó gần nút nguồn hơn nút Black Hole. Các ví dụ này có thể mở rộng với điều kiện cấu trúc nút mạng nhƣ trên. Do vậy, phƣơng pháp này cố gắng tìm cách giảm thiểu hiệu ứng lỗ đen trong các mạng AODV nếu nó làm giảm hiệu suất mạng.
3.3.2. Cài đặt giao thức giải pháp trên NS-2
Hiệu quả của chống lại tấn công lỗ đen đƣợc đánh giá dựa trên bộ mô phỏng NS-2. Giao thức AODV đƣợc sao chép và đổi tên thành “idsaodv” giống nhƣ thực hiện giao thức
“blackholeaodv” trƣớc đó. Để thực hiện giao thức blackholeAODV, ta thay đổi hàm nhận RREQ (recvRequest) của file blackholeaodv.cc; nhƣng để thực hiện giải pháp cho giao thức idsAODV ta thay đổi hàm nhận RREP (recvReply) và tạo ra cơ chế đệm cho RREP để đếm thông báo RREP thứ hai.
Đoạn mã dƣới đây thể hiện cơ chế đệm RREP. Hàm “rrep_insert” dùng để thêm thông báo RREP, hàm “rrep_lookup” dùng để tìm kiếm bất kỳ thông báo RREP nào nếu nó tồn tại, hàm “rrep_remove” dùng để gỡ bỏ bất kỳ thông báo RREP nào đến từ một nút xác định và hàm “rrep_purge” dùng để xoá định kỳ danh sách đã hết hạn (nếu có). Trong trƣờng hợp này chọn thời gian “BCAST_ID_SAVE” là 6 (có nghĩa là 3 giây).
void
idsAODV::rrep_insert(nsaddr_t id) {
idsBroadcastRREP *r = new idsBroadcastRREP(id); assert(r);
r->expire = CURRENT_TIME + BCAST_ID_SAVE; r->count ++; LIST_INSERT_HEAD(&rrephead, r, link); } idsBroadcastRREP * idsAODV::rrep_lookup(nsaddr_t id) { idsBroadcastRREP *r = rrephead.lh_first; for( ; r; r = r->link.le_next) { if (r->dst == id) return r; } return NULL; } void idsAODV::rrep_remove(nsaddr_t id) { idsBroadcastRREP *r = rrephead.lh_first; for( ; r; r = r->link.le_next) { if (r->dst == id) LIST_REMOVE(r,link); delete r; break; } } void idsAODV::rrep_purge() { idsBroadcastRREP *r = rrephead.lh_first;
idsBroadcastRREP *rn; double now = CURRENT_TIME; for(; r; r = rn) { rn = r->link.le_next; if(r->expire <= now) { LIST_REMOVE(r,link); delete r; } } }
Trong hàm “recvReply”, đầu tiên ta kiểm soát nếu thông báo RREP đến chính nó. Nếu đúng, hàm sẽ tìm kiếm thông báo RREP nếu nó tồn tại; nếu không, nó chèn thông báo thông báo RREP cho địa chỉ đích của nó và trả về hàm. Nếu thông báo RREP đƣợc lƣu trữ trƣớc đó có cùng địa chỉ đích, hàm RREP thông thƣờng đƣợc thực hiện. Sau đó, nếu thông báo RREP không dành cho chính nó, nút sẽ chuyển tiếp thông báo đến nút lân cận thích hợp. Đoạn mã sau đây thể hiện cách hàm nhận thông báo RREP của giao thức
idsAODV thực hiện: idsAODV::recvReply(Packet *p) { idsBroadcastRREP * r = rrep_lookup(rp->rp_dst); if(ih->daddr() == index) { if (r == NULL) { count = 0; rrep_insert(rp->rp_dst); } else { r->count ++; count = r->count; } CẬP NHẬT BẢNG ĐỊNH TUYẾN } else { Forward(p); } }
3.3.3. Thử nghiệm giao thức idsAODV
Giao thức idsAODV đƣợc thực hiện trên bộ mô phỏng NS-2 với kịch bản 7 nút cố định và vị trí nút tƣơng tự nhƣ kịch bản của hình 3.6. Trong mô phỏng này, giao thức idsAODV đƣợc sử dụng thay cho giao thức AODV áp dụng cho tất cả các nút không dây kể cả nút Base Station trừ nút Black Hole (Nút 2). Để chuyển giao thức AODV thành idsAODV ta chỉ cần thay đổi dòng lệnh “$ns node-config -adhocRouting idsAODV”. Khi mô phỏng đƣợc thực hiện, ta sẽ nhận thấy nút gửi gửi thông báo đến nút nhận đúng cách. Hình 3.7 dƣới đây cho biết các gói tin CBR đã đến đích nhƣ mong đợi.
Hình 3.7: Kết quả thực hiện giao thức idsAODV khi có tấn công blackhole