Kết nối mơ phỏng giải pháp với thiết bị thực

Một phần của tài liệu Nghiên cứu phát triển giải pháp nâng cao an toàn trong mạng internet of things (Trang 74)

Chú thích trong Hình 2.5, thiết bị được đánh số 1 là thiết bị kết nối qua cổng

ttyUSB0 đĩng vai trị nút Coordinator, thiết bị được số 2 và số 3 là thiết bị kết nối qua

cổng ttyUSB1 và ttyUSB2 đĩng vai trị là nút Cảm biến và thiết bị được số 4 là thiết bị kết nối qua cổng ttyUSB3 đĩng vai trị là nút Cảm biến trong kịch bản KB1, đĩng vai trị là nút Bots trong Kịch bản KB2 và KB3. Hình dưới đây là sơ đồ kết nối các thiết bị mơ phỏng.

(a) WSN khơng cĩ nút Bots (b) WSN cĩ nút Bots Hình 2.6. Sơ đồ kết nối các thiết bị mơ phỏng

64

Trong Hình 2.6, các thiết bị Zolertia được đánh định danh theo cổng USB bao gồm ttyUSB0, ttyUSB1, ttyUSB2, ttyUSB3 kết nối được ký hiệu là các hình trịn mà trong đĩ, nút Coordinator cĩ màu đen, nút cảm biến cĩ màu trắng cịn Bots cĩ họa tiết gạch chéo. Các thiết bị cảm biến được đặt ngẫu nhiên trong khơng gian ba chiều và cĩ thể kết nối trực tiếp với nhau bằng kết nối khơng dây mà ký hiệu là mũi tên nét đứt. Các thiết bị đĩng vai trị nút Cảm biến sẽ gửi đều đặn các gĩi tin cho thiết bị đĩng vai trị nút Coordinator. Ngồi ra, các thiết bị Zolertia đều kết nối qua dây cáp chuẩn USB 3.0 mà ký hiệu là đường nét liền tới một chiếc máy tính cá nhân để phục vụ tải mã nguồn cũng như truy cập lấy dữ liệu từ thiết bị. Ở WSNs cĩ nút Bots thì nút Bots sẽ gửi thực hiện tấn cơng DoS vào nút Coordinator gây tắc nghẽn mạng. Mỗi thí nghiệm thực hiện trong 10 tiếng, kết quả sẽ lấy kết quả trung bình của cả 4 thiết bị.

Do đã cĩ sẵn các tệp mã nguồn C mà được kiểm chứng thơng qua giả lập Cooja nên việc cần làm là sao chép mã nguồn thư mục ra tệp “examples/zolertia/zoul/” là thư mục chứa file cấu hình tương tác với các thiết bị thực tế qua cổng USB. Để tránh nhầm lẫn với các tệp mã nguồn C trong giả lập Cooja thì các tệp mã nguồn C sẽ được đổi tên bằng cách thêm tiền tố “zoul-” ở phía trước. Như vậy, ba tệp mã nguồn C cấu hình là zoul-server.c, zoul-Client.c và zoul-malicious.c.

Như đã đề cập, quá trình tương tác với các thiết bị sẽ bao gồm hai cơng đoạn là tải mã nguồn lên và lấy dữ liệu từ mã nguồn. Tải mã nguồn lên Z1 với câu lệnh (xem tại Phụ lục Hình 3 (PL)).

Nhiệm vụ là tham chiếu đến tệp “zoul” cũng như tải mã nguồn lên thiết bị qua cổng USB ttyUSB0 (xem Phụ lục Hình 4(PL)).

Tiếp theo sẽ tải mã nguồn lên các thiết bị khác. Ở kịch bản KB1, tất cả các thiết bị cịn lại qua cổng ttyUSB1, ttyUSB2, ttyUSB3 đều đĩng vai trị nút cảm biến. Vị trí gõ lệnh là ở trong thư mục “zoul” (xem Phụ lục Hình 5 (PL)).

Sang đến kịch bản KB2, thiết bị kết nối qua cổng ttyUSB3 đĩng vai trị Bots vì vậy sẽ phải tải lại mã nguồn lên thiết bị qua các lệnh (xem Phụ lục Hình 6 (PL)).

Lưu ý, cơ chế tải mã nguồn lên thiết bị là cơ chế ghi đè, nghĩa là xĩa mã nguồn cũ và ghi hồn tồn mã nguồn mới lên.

Ở Tình huống TH3 là kịch bản cĩ Overhearing, tiến hành sao chép hai tệp là

65

overhearing-Client.c. Hai tệp mã nguồn này đã được chèn code thực thi thuật tốn

Overhearing lên. Sau đĩ sẽ ghi đè hai tệp mã nguồn này lên các thiết bị. Tệp zoul- overhearing-server.c sẽ ghi đè lên thiết bị kết nối qua cổng ttyUSB0 là thiết bị đĩng

vai trị nút Coordinator. Trong khi đĩ Tệp zoul-overhearing-Client.c sẽ ghi đè lên thiết bị kết nối qua cổng ttyUSB1 và ttyUSB2 là thiết bị đĩng vai trị nút cảm biến.

Riêng thiết bị kết nối qua cổng ttyUSB3 vẫn đĩng vai trị nút Bot nên khơng cần ghi đè.

Sang đến Bước thu thập dữ liệu, việc cần làm là truy cập tới các thiết bị thơng qua 4 Terminal tương ứng với các thiết bị. Lệnh sau được sử dụng với Terminal thực hiện kết nối với thiết bị đĩng vai trị nút Coordinator (xem Phụ lục Hình 7 (PL)).

Với các Terminal thì vẫn sử dụng câu lệnh tương tự, chỉ thay bằng tên cổng USB tương ứng với tên các thiết bị mà Terminal sẽ trỏ đến. Sau đĩ thì các bản tin gửi nhận của các nút sẽ được in ra Terminal tương tự như Mote Output trong thí nghiệm giả lập với Cooja đã trình bày ở phần trước. Do nhu cầu thu thập dữ liệu, các thiết bị thường xuyên được kết nối với máy tính, năng lượng liên tục được bổ sung nên việc đo đạc năng lượng tiêu thụ là khơng cần thiết. Do vậy thơng số đo đạc sẽ chỉ bao gồm tỉ lệ truyền nhận thành cơng và độ trễ.

Dữ liệu được thu thập từ Terminal sẽ được chạy trong đoạn mã nguồn

javascript phân tích gĩi tin đã sử dụng ở Simulation Script Editor. Cụ thể, đoạn mã

nguồn javascript tính PDR cũng như Độ trễ sẽ được lưu lại thành tệp “calculate-

measurement.js”. Tệp javascript sẽ được thực thi thơng qua cơng cụ biên dịch mã

nguồn Javascript nodejs trên Hệ điều hành Contiki. Tệp sẽ nhận đầu vào dữ liệu từ

Terminal thơng qua thao tác Copy/ Paste sau đĩ xuất đầu ra là kết quả tính tốn qua file “output.csv” tương tự như với thí nghiệm giả lập.

Cũng tương tự như kịch bản mơ phỏng, trong kịch bản thực tế, tất cả các nút Client sẽ gửi một bản tin cho nút Server trong khoảng thời gian 10s. Bản tin này được giả định là mang thơng tin cụ thể thu thập từ mơi trường xung quanh tùy thuộc vào nhiệm vụ cụ thể của mỗi nút cảm biến (nhiệt độ, độ ẩm). Như vậy, với thời gian thí nghiệm là 10 tiếng, về mặt lý thuyết một nút cĩ khả năng gửi tối đa 3600 bản tin. Tuy nhiên, trong hầu hết trường hợp, các nút phải xây dựng cây DAG trước khi thiết lập ổn định mạng WSN trong khoảng từ 20 – 50 phút đầu nên trong trường hợp mạng

66

bình thường, một nút sẽ gửi khoảng 3300 – 3400 bản tin.

Theo mơ hình RPL, khi các nút Client ở xa sẽ truyền cho các nút Client gần nút Server hơn đến khi tới nút Client cĩ thể truyền tới nút Server.

2.4.3. Kết quả mơ phỏng tấn cơng, so sánh đánh giá

a. Kịch bản 1: Thí nghiệm mơ phỏng trên Hệ điều hành Contiki

Kết quả mơ phỏng bao gồm 2 phần là thống kê số gĩi tin mỗi nút mạng gửi nhận trong quá trình hoạt động của mạng cảm biến và hiệu năng tồn mạng với các trường hợp khác nhau.

- Thống kê số gĩi tin gửi nhận trong mỗi nút mạng.

Bảng 2.3 thống kê số gĩi tin mà mỗi nút mạng nhận được cũng như số gĩi tin mà mỗi nút mạng đã gửi trong suốt quá trình truyền tin của mạng. Lấy hai tình huống là TH1 và TH2 để thống kê số gĩi tin, do TH1 đã cài giải pháp Overhearing nên đảm bảo tính trực quan và bám sát thực tế, trong khi TH2 là cuộc tấn cơng DoS khơng được ngăn chặn bởi giải pháp Overhearing nên cĩ thể dễ dàng nhận biết thay đổi trong số gĩi tin các nút gửi nhận trong quá trình tấn cơng DoS.

Bảng 2.3. Thống kê số gĩi tin gửi nhận trung bình trong mỗi nút mạng a. Mơ hình Lưới 4 x 4: a. Mơ hình Lưới 4 x 4:

Nút TH1 TH2

Số gĩi tin gửi Số gĩi tin nhận Số gĩi tin gửi Số gĩi tin nhận

2 45 80 76 80 3 147 71 160 104 4 139 92 67 40 5 97 63 75 70 6 80 144 230 149 7 341 88 745 39 8 234 107 84 39 9 129 66 203 96 10 245 85 301 111 11 249 65 259 146 12 195 55 124 92 13 93 52 110 69 14 97 30 216 81 15 194 41 246 61 16 56 38 78 74 TB 228 282 + Giá trị trung bình: TH1: µ1= 228; TH2: µ2=282

67

+ Độ lệch chuẩn đối với trường hợp 1: 𝜎1 = 91 + Độ lệch chuẩn với trường hợp 2: 𝜎2 =167

+ Trong TH1, ngưỡng 1 với K1 = µ1 + 𝜎1 = 319; K2 = µ1 + 2 ∗ 𝜎1 = 410; K3 = µ1 + 3 ∗ 𝜎1=501

+ Trong TH2, ngưỡng 1 với K1: µ2 + 𝜎2 = 449; K2: µ2 + 2 ∗ 𝜎2 = 616; K3: µ2 +

3 ∗ 𝜎2=783.

+ Trong TH1, mạng hoạt động bình thường, khơng cĩ xuất hiện Bot.

+ Trong TH2 cĩ thể xác định được nút 07 là nút Bot vì số lượng gĩi tin là 784 > k3.

b. Mơ hình Lưới 5 x 5

Nút TH1 TH2

Số gĩi tin gửi Số gĩi tin nhận Số gĩi tin gửi Số gĩi tin nhận

2 42 75 59 64 3 166 76 165 96 4 49 49 213 83 5 35 13 64 85 6 61 55 97 95 7 60 109 187 136 8 280 88 275 123 9 156 80 805 53 10 110 14 138 78 11 145 58 187 71 12 275 99 277 101 13 315 88 235 117 14 257 81 201 136 15 100 49 139 83 16 163 52 175 64 17 240 67 259 91 18 263 89 719 35 19 233 92 242 85 20 112 50 134 65 21 52 22 71 55 22 149 59 95 52 23 120 70 139 32 24 138 41 135 73 25 51 16 69 44

Tương tự như tính tốn tương tự như trường hợp trên cho thấy nút 9 và 18 là các nút Bot.

68

c. Mơ hình Lưới 6 x 6

Nút TH1 TH2

Số gĩi tin gửi Số gĩi tin nhận Số gĩi tin gửi Số gĩi tin nhận

2 105 68 113 87 3 126 51 205 92 4 157 54 182 93 5 150 39 212 106 6 50 19 85 52 7 42 73 70 81 8 74 115 145 138 9 245 93 346 140 10 148 76 307 95 11 163 46 254 93 12 149 26 191 107 13 105 54 203 89 14 186 70 382 106 15 216 86 269 104 16 153 44 232 121 17 117 42 729 66 18 129 44 213 93 19 97 26 165 32 20 143 40 326 130 21 135 50 236 110 22 155 64 609 84 23 157 60 254 94 24 60 20 175 89 25 83 21 104 24 26 58 22 278 117 27 61 22 729 109 28 206 56 123 65 29 198 39 209 80 30 75 25 166 50 31 55 8 72 15 32 54 17 130 66 33 86 21 101 69 34 145 52 142 79 35 112 62 173 82 36 73 12 100 33

Tương tự như các tính tốn trên, cĩ thể xác định được nút 17, 22, 27 là các nút Bot.

69

Từ các kết quả trên, cho thấy thuật tốn đã chỉ ra được các nút Bot, từ đĩ cĩ thể thấy giải pháp Overhearing đề xuất là khả thi.

- Đo đạc hiệu năng tồn mạng

Với thiết bị Tmote Sky thì các hằng số tính năng lượng từ Cơng thức (3) Phần

2.3 sẽ cĩ giá trị như sau dựa trên thơng số kỹ thuật của hãng Moteiv[55]: Et = 19.5;

Er = 21.8; Eo = 1.8; EI = 0.545 và τ = 2345+2

Bảng 2.4 chỉ ra kết quả thí nghiệm kịch bản mơ phỏng tấn cơng DoS với thời gian chạy mơ phỏng Cooja là 50 phút (thời gian vừa đủ để cĩ thể theo dõi được hậu quả của tấn cơng DoS). Cĩ 3 mơ hình lưới, mỗi mơ hình lưới cĩ 4 Tình huống.

Tổng cộng sẽ cĩ 12 thí nghiệm phải thực hiện với tổng thời gian là 600 phút.

Bảng 2.4. Kết quả thơng số thí nghiệm kịch bản thí nghiệm mơ phỏng

Mơ hình Kịch bản PDR (%) Latency (ms/m) Energy (mJ)

Lưới 4x4 TH0 95.13 674.92 139.05 TH1 94.98 796.55 148.46 TH2 13.59 56480.86 1204.05 TH3 91.34 1076.25 201.04 Lưới 5x5 TH0 97.03 618.76 127.66 TH1 96.31 642.23 132.27 TH2 15.83 51317.93 1185.78 TH3 93.69 983.27 195.13 Lưới 6x6 TH0 99.02 399.26 117.15 TH1 98.74 431.22 128.98 TH2 17.02 45208.63 1142.13 TH3 95.11 892.10 169.74

Sau đây là những nhận định được rút ra từ Bảng 2.3 và Bảng 2.4 trên thí nghiệm kịch bản mơ phỏng:

+ Trong trường hợp mạng bình thường ở TH1, khơng tấn cơng DoS, số lượng các gĩi tin gửi hoặc nhận của các nút mạng khơng cĩ độ chênh lệch lớn, trong khi ở TH2, khi quá tải vì ảnh hưởng từ cuộc tấn cơng DoS, số gĩi tin cả gửi lẫn nhận ở các nút Bot tăng đột biến. Việc gia tăng đột biến số lượng gĩi tin gửi hoặc nhận ở một nút mạng là một chỉ số quan trọng và tin cậy để xác định nút đĩ là nút Bot, đang phát động các cuộc tấn cơng DoS. Thuật tốn phát hiện Bot dựa trên sự gia tăng bất thường của tham số là số lượng gĩi tin gửi hoặc nhận ở một nút mạng là phù hợp.

70

+ Hiệu năng của mạng khi khơng cài giải pháp Overhearing cải tiến tốt hơn so với mạng đã cài giải pháp này. Điều này chứng tỏ giải pháp đã tiêu thụ tài nguyên và gây ảnh hưởng tới các hoạt động khác của mạng, làm hiệu năng mạng bị giảm. Ta cĩ thể thấy mọi thơng số của mạng ở TH0 (khơng cài giải pháp Overhearing) đều tốt hơn TH1 (cài Overhearing).

+ Hậu quả của cuộc tấn cơng DoS rất nghiêm trọng đối với cơ sở hạ tầng IoT. Cĩ thể thấy chỉ trong thời gian rất ngắn (30 phút thí nghiệm) mà các thơng số đo đạc từ các kịch bản cĩ tấn cơng (TH2 và TH3 đã thay đổi nhanh chĩng theo chiều hướng xấu đi). Ở kịch bản 3, hiệu năng mạng chỉ cịn 20%, xem như mạng bị tê liệt.

+ Quy mơ mạng càng lớn, thì hậu quả của tấn cơng DoS càng ít nghiêm trọng. Các chỉ số của các kịch bản trên Mơ hình lưới 6x6 (36 nút) tốt hơn lưới 5x5 (25 nút) và lưới (5x5) sẽ lại tốt hơn lưới 4x4 (16 nút), cho dù trong thí nghiệm, số nút Bot tăng khi quy mơ mạng tăng. Điều này cũng cĩ thể giải thích được do quy mơ mạng càng lớn thì các nút càng cĩ thể bổ trợ cho nhau tốt hơn, tỉ lệ bị ảnh hưởng của tấn cơng cĩ thể xem là thấp hơn.

+ Giải pháp Overhearing đã gĩp phần giảm thiểu đi rất nhiều tác động của cuộc tấn cơng DoS. Các thơng số ở TH3 đều tốt hơn so với thơng số ở TH2 (khơng áp dụng Overhearing).

+ Tuy nhiên, khi so sánh với TH1 (khơng tấn cơng), hiệu năng mạng vẫn kém hơn ít nhiều. Lý giải cho hiện tượng này, ta lưu ý, giải pháp Overhearing khơng phải giải pháp phịng chống mà chỉ là giải pháp phát hiện và ngăn chặn, giảm thiểu thiệt hại của tấn cơng. Khoảng thời gian từ khi bắt đầu tấn cơng đến khi tất cả các nút hàng xĩm của Bot phát hiện và từ chối giao dịch, cuộc tấn cơng DoS vẫn gây thiệt hại cho mạng mơ phỏng.

Từ những kết quả trên, cĩ thể thấy, hậu quả của cuộc tấn cơng DoS là khác nhau, phụ thuộc vào vị trí của nút Bots trong mạng cảm biến cũng như quy mơ của mạng này, khi bị tấn cơng hiệu năng của mạng suy giảm mạnh. Thí nghiệm cho thấy sự khả thi và hiệu quả của giải pháp Overhearing cũng như thuật tốn phát hiện Bot dựa trên sự gia tăng bất thường của số lượng gĩi tin gửi hoặc nhận của các nút.

71

b. Kịch bản 2: Thí nghiệm mơ phỏng trên thiết bị thực tế Zolertia

Bảng 2.5 đưa ra sự so sánh kết quả thí nghiệm với thiết bị thực tế ở cả bốn kịch bản TH0: mạng khơng cĩ cài đặt gì, TH1: mạng hoạt động bình thường, TH2: mạng bị tấn cơng DoS và TH3 mạng bị tấn cơng DoS nhưng đã cài Overhearing. Thời gian diễn ra với mỗi thí nghiệm là 10 tiếng.

Bảng 2.5. Kết quả thí nghiệm với các thiết bị thực tế

Kịch bản PDR (%) Latency (ms/m)

TH0 95.67 763.45

TH1 93.96 910.77

TH2 11.84 89453.14

TH3 91.02 1057.08

Từ Bảng 2.5 rút ra một số nhận xét như sau về thí nghiệm kịch bản thực tế: + Thí nghiệm trên thiết bị thực tế đã tuân theo mơ hình dự đốn rút ra từ thí nghiệm giả lập, như kịch bản TH2, khi mạng bị tấn cơng DoS cĩ hiệu năng của mạng đã suy yếu đến mức khơng thể hoạt động bình thường ở TH3, khi các thiết bị Zolertia được cài Overhearing cải tiến thì mạng dù bị suy yếu dưới tác động của cuộc tấn cơng DoS nhưng vẫn duy trì hiệu năng ở mức hoạt động ổn định.

+ Hiệu năng trung bình của mạng với các thiết bị thực tế thấp hơn Hiệu năng

Một phần của tài liệu Nghiên cứu phát triển giải pháp nâng cao an toàn trong mạng internet of things (Trang 74)

Tải bản đầy đủ (PDF)

(150 trang)