2. GIẢI PHÁP OVERHEARING PHỊNG CHỐNG TẤN CƠNG TỪ CHỐ
2.4.2. Xây dựng các mơ hình và tình huống thử nghiệm
Mỗi hình thức thí nghiệm sẽ là một kịch bản với nhiều tình huống khác nhau. Các tính huống này diễn ra trên WSN cĩ hình thái mạng giống nhau, cùng theo mơ
56
hình Coordinator – Sensor, nút đĩng vai trị Coordinator khơng thay đổi, nút đĩng vai trị Sensor cĩ thể được chỉ định thành các đĩng vai trị Bot tùy tình huống cụ thể.
a. Kịch bản 1: Thí nghiệm mơ phỏng trên Hệ điều hành Contiki
Cơng việc mơ phỏng trên Hệ điều hành Contiki bao gồm xây dựng cơ sở cho thí nghiệm như mã nguồn, thuật tốn và thiết lập kịch bản hoạt động bao gồm xây dựng tình huống, hình thái mạng, thiết lập thời gian, cơ chế đo đạc dữ liệu.
Việc xây dựng cơ sở cho thí nghiệm mơ phỏng bao gồm các bước như sau: Xây dựng lại cuộc tấn cơng DoS và xây dựng cơ chế Overhearing.
Contiki-OS khơng cĩ sẵn tấn cơng DoS, cần xây dựng một file mơ phỏng hoạt động của nút Client nhưng cĩ thêm đoạn mã thực hiện chức năng sản sinh và truyền các gĩi tin rác tương tự như nút Client truyền dữ liệu đo đạc. File này được đặt tên là
malicious.c, mã nguồn thêm vào (xem Phụ lục Hình 1 (PL)).
Sau đây là lưu đồ thuật tốn thực hiện:
Khi chạy mơ phỏng trên Cooja, đối với nút Bot, sẽ thao tác tương tự như với các nút Client khác, chỉ cĩ điều thay vì sử dụng file udp-Client.c do Contiki cung cấp mà sử dụng file malicious.c cĩ cấu trúc tương tự file udp-Client.c, nhưng chèn thêm đoạn “mã độc” này vào. Sau đĩ, sẽ mơ phỏng mạng bị nhiễm độc này như bất cứ hệ thống mạng bình thường nào khác trong Contiki-OS.
Sau khi xây dựng một cuộc tấn cơng Botnet, cơng việc tiếp theo là xây dựng giải pháp Overhearing. Quá trình triển khai thuật tốn được chia làm 3 giai đoạn.
57
+ Giai đoạn 1: Đếm số gĩi tin, chỉ đơn giản là tạo 2 mảng, mảng
*arrsender dành cho số gĩi tin gửi đi, mảng *arrreceiver dành cho số gĩi tin mà nút đĩ nhận được. Độ dài mảng chính là tổng số nút trong mơ phỏng. Nút nào khơng phải nút hàng xĩm của nút đang xét sẽ cĩ giá trị là 0. Việc khai báo mảng được tiến hành trong file framer-802154.c và sẽ tham chiếu đến hai file Client.c và malicious.c.
+ Giai đoạn 2: Trong file Client.c và malicious.c, để thực thi thuật tốn này, sử dụng 1 vịng lặp for để tính giá trị trung bình, 1 vịng lặp for để tính phương sai. Sau đĩ dùng hàm sqrt() trong bộ thư viện <math.IoT>. Cuối cùng, dùng if để kiểm tra từng nút một lấy từ file framer-802154.c.
Mã nguồn thực hiện cơng đoạn 1-2 triển khai thuật tốn Overhearing (xem tại Phụ lục Hình 2 (PL)).
Sau đây là lưu đồ thuật tốn thực hiện:
+ Giai đoạn 3: Cấu hình cài đặt giải pháp ngăn chặn Bots.
Cấu hình giải pháp ngăn chặn nút Bots
Khởi tạo thêm 1 mảng nữa cĩ độ dài bằng số nút trong giả lập ở file framer- 802154.c để đánh dấu nút nào là nút Bot. Các giá trị trong mảng được khởi tạo là 0. Trong quá trình mơ phỏng, mảng này sẽ nhận tham chiếu từ thuật tốn ở file Client.c
và malicious.c xem nút nào là Bot để đánh lại giá trị là 1. Sau đĩ, đặt điều kiện if-else
trong file framer-802154.c để trong quá trình giao dịch, nếu phát hiện gĩi tin nút đĩ gửi tới, nĩ sẽ trả về FRAMER_FAILED (tức là từ chối xử lý gĩi tin).
58
Sau cơng đoạn xây dựng cơ sở, thí nghiệm cĩ thể được triển khai với mơ phỏng tấn cơng Botnet cũng như mơ phỏng giải pháp Overhearing.
Tiếp theo là xây dựng kịch bản các tình huống thí nghiệm mơ phỏng này. Về mơ hình mạng, luận án chọn mơ hình lưới vì cĩ tính chịu lỗi cao, một nút sẽ cĩ từ 3 đến 8 nút lân cận (nút hàng xĩm là nút nằm trong phạm vi phủ sĩng), cho phép cĩ lựa chọn tuyến đường truyền tin. Thí nghiệm thực hiện trên ba mơ hình dạng lưới là 4x4 (16 nút), 5x5 (25 nút) và 6x6 (36 nút). Việc đưa ra các kịch bản cĩ số nút khác nhau nhằm so sánh ảnh hưởng của tấn cơng DoS lên các hệ thống mạng với quy mơ khác nhau.
a) b)
59
a) b)
Mơ hình Lưới 5x5
a) b)
Mơ hình Lưới 6x6
Hình 2.3. Tấn cơng DoS và giải pháp Overhearing trên WSN
- Chú thích Hình 2.3:
+ Nút nền đỏ, số màu vàng là nút Coordinator. + Nút nền hồng, số màu đen là nút Client.
+ Nút nền đen, số màu trắng là nút bị nhiễm mã độc (Bot).
+ Các nút trong phạm vi phủ sĩng của một nút là các nút nằm 4 bên cạnh và 4 bên chéo. Như vậy, các nút ở trung tâm sẽ cĩ 8 nút hàng xĩm, nút ở cạnh cĩ 5 nút cịn nút ở gĩc chỉ cĩ 3 nút hàng xĩm. Khoảng cách giữa các nút hàng xĩm trong mơ phỏng: Hai nút bên cạnh nhau cách nhau 30m (khoảng cách mơ phỏng trên Contiki), và theo định lý Pythagoras về tam giác vuơng cân thì hai nút chéo nhau sẽ cách nhau một khoảng bằng căn bậc hai của giá trị, gấp đơi bình phương khoảng cách giữa hai nút cạnh nhau, giá trị này là khoảng 42,4m. Tốc độ truyền của các gĩi tin tuân theo tiêu chuẩn Ethernet được mơ phỏng trong hệ điều hành Contiki là 10 Mb/s. Kích thước gĩi tin tối đa cĩ thể tạo ra và gửi trong hệ điều hành Contiki là 128 byte. Các nút Client đều cĩ khả năng đĩng vai trị Bot đồng nghĩa với nút đĩ cĩ khả năng tạo ra và gửi nhiều bản tin rác trong một thời gian ngắn với giao thức UDP.
60
Truyền thơng giữa các nút được mơ tả như sau: Tất cả các nút Client sẽ gửi một bản tin cho nút Coordinator trong khoảng thời gian 10s. Lưu ý rằng khái niệm
bản tin đề cập là thơng điệp ứng dụng (message), khái niệm chỉ các thơng tin ứng dụng được các nút mạng gửi để phục vụ cơng việc hoặc để tấn cơng DoS. Khái niệm này khác với khái niệm gĩi tin (data packet) là dữ liệu được các nút mạng gửi dưới khái niệm vật lý. Trước khi khi gửi thơng điệp, các nút mạng sẽ chia tách thơng điệp thành các bản tin theo các giao thức phân tầng trong mạng cảm biến trong mơi trường IoT. Cũng theo giao thức RPL thì các gĩi tin sẽ được chuyển tiếp giữa các nút với nhau cho đến khi tới nút root và trong quá trình hoạt động của nút mạng luơn xảy ra trao đổi các gĩi tin với nhau phục vụ các hoạt động cơ bản trong truyền thơng mạng IoT. Như vậy, tần suất gửi và số lượng, kích thước các gĩi tin khơng chỉ phụ thuộc vào chu kỳ gửi thơng điệp mà cịn phụ thuộc vào nhiều yếu tố chủ quan và khách quan như vị trí nút, các hoạt động cơ bản duy trì hệ thống, cùng nhiều yếu tố ngẫu nhiên khác. Vì vậy, mặc dù hoạt động gửi bản tin (message) ở mỗi nút là giống nhau, nhưng hoạt động gửi nhận dữ liệu vật lý là khác nhau. Ngồi ra, mạng cảm biến được thí nghiệm đảm bảo mạng tiêu biểu và xuất hiện phổ biến trong thực tế, khi mà hầu hết các mơ hình mạng cảm biến hiện nay, việc gửi các thơng điệp tuân theo chu kỳ xác định vì các dữ liệu thu thập và thống kê cũng tuân theo một chu kỳ để dễ đồng bộ hĩa. Với mạng cảm biến thí nghiệm khi được triển khai trên thực tế, thơng điệp được gửi về nút root với chu kỳ 10s cĩ thể mang thơng tin của mơi trường xung quanh mà nút cảm biến thu thập được. Các bản tin này được truyền theo mơ hình RPL, khi mà 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. Như vậy, càng gần nút Server thì tần suất trao đổi dữ liệu càng dày và hệ quả là các cuộc tấn cơng DoS vào các nút Client gần Server sẽ gây hậu quả nghiêm trọng hơn các nút Client ở xa.
Về các tình huống thí nghiệm, cĩ bốn tình huống:
+ Tình huống TH0: Hoạt động bình thường, khơng giải pháp Overhearing khơng cĩ sự xuất hiện Bot. Kịch bản sử dụng mơ hình mạng (a) trong Hình 2.3:
+ Tình huống TH1: Hoạt động bình thường, cĩ cài giải pháp Overhearing khơng cĩ sự xuất hiện Bot. Kịch bản sử dụng mơ hình mạng (a) trong Hình 2.3:
61
thấy Mơ hình lưới 4x4 cĩ 1 nút đĩng vai trị Bot, lưới 5x5 cĩ 2 nút và Lưới 6x6 cĩ 3 nút. Các nút này nằm khá gần nút Coordinator nên hậu quả của các cuộc tấn cơng DoS thường nghiêm trọng. Kịch bản sử dụng mơ hình mạng (a) trong Hình 2.3:
+ Tình huống TH3: Tình huống mạng tấn cơng DoS nhưng được cài giải pháp Overhearing. Tình huống sử dụng Mơ hình mạng trong Hình 2.3 nhưng tất cả các nút đều đã cài đặt giải pháp Overhearing cải tiến. Kịch bản sử dụng mơ hình mạng (a) trong Hình 2.3.
Với mỗi kịch bản sẽ đo đạc cả ba tiêu chí là tỉ lệ truyền nhận thành cơng, Độ trễ và năng lượng tiêu thụ. Ngồi ra, nhằm chứng tỏ sự khả thi của việc xác định Bot dựa trên đếm số gĩi tin gửi nhận của mỗi nút mạng xung quanh, tác giả cũng kiểm đếm số gĩi tin từng nút gửi đi và nhận về. Cơng việc này được thực hiện khi tính tốn tỉ lệ truyền nhận thành cơng của mạng.
b. Kịch bản 2: Thí nghiệm với thiết bị thực tế Zolertia
Tương tự thí nghiệm trên Hệ điều hành Contiki, xây dựng cơ sở vật chất cho thí nghiệm cũng như thiết lập kịch bản dữ liệu. Tuy nhiên, trước khi thực hiện hai bước trên, cơng việc cần làm cho kịch bản thí nghiệm trên thiết bị Zolertia là thiết lập mơi trường thực tế bao gồm chuẩn bị và cài đặt thiết bị mơi trường thực địa.
Về việc chuẩn bị và cài đặt thiết bị, xây dựng quá trình tương tác với các thiết bị thực tế của tác giả được thể hiện trong sơ đồ trong Hình 2.4 dưới đây.
(a) (b)
Hình 2.4. Mơ hình tương tác với thiết bị Zolertia
Quá trình tương tác với thiết bị Zolertia bao gồm hai bước. Bước (a) tải mã nguồn từ máy tính cài hệ điều hành Contiki lên thiết bị Zolertia thơng qua mã lệnh trên Terminal và dữ liệu sẽ truyền qua cổng USB. Sau Bước (a), các nút sẽ biên dịch mã nguồn và thực hiện các kịch bản thí nghiệm dựa trên vai trị của mình. Khi đĩ thì máy tính cá nhân vẫn duy trì kết nối USB với các thiết bị nhưng khơng cịn can thiệp
62
vào hoạt động của thiết bị nữa mà nhiệm vụ của máy tính là truy cập vào bên trong các thiết bị để đọc thơng số, phân tích các gĩi tin truyền và nhận của các nút mạng như Bước (b) trong sơ đồ Hình 2.4. Cách tương tác này hiệu quả và thuận tiện vì từ một máy tính cĩ khả năng tải mã nguồn cĩ kịch bản mơ phỏng lên từng thiết bị đồng thời thu thập dữ liệu từ các thiết bị đĩ mà khơng can thiệp vào hoạt động của thiết bị, để đảm bảo tính độc lập như hoạt động các cảm biến IoT trên mơi trường thực tế.
Về mơi trường, các thiết bị được đặt ngẫu nhiên trong mơi trường khơng gian phịng làm việc, điều kiện ngồi trời (khơng cĩ điều hịa) vào mùa hè với khí hậu nĩng ẩm ở miền Bắc Việt Nam, nhiệt độ phịng là 32o
C, độ ẩm 83%. Đây cũng là mơi trường mà hầu hết sẽ triển khai các hệ thống IoT trên lãnh thổ Việt Nam chẳng hạn như bên trong các nhà máy, dưới bĩng râm trong các cảng biển, kho bãi. Khoảng cách giữa các nút là từ 2m đến 5m, các nút hồn tồn cĩ khả năng truyền dữ liệu trực tiếp cho nhau. Đây cũng là mơ hình kết nối của các mạng quy mơ vừa và nhỏ thường phục vụ các phịng làm việc, tổ sản xuất hoặc phịng cách ly tiêu chuẩn trong bệnh viện với số nút từ 4 đến 10 thiết bị, tương ứng với các cảm biến thu thập dữ liệu và một thiết bị đĩng vai trị liên kết với các cổng kết nối. Về mặt kỹ thuật để cĩ thể mơ phỏng sát thực tế nhất, tác giả và các cộng sự đã để khơng cách ly mơi trường thí nghiệm với các thiết bị điện tử xung quanh. Trong phịng làm việc cũng là nơi cĩ chịu tác động các nguồn phát điện từ như mạng khơng dây, hệ thống điện dân dụng tịa nhà như đèn chiếu sáng, tủ lạnh,… điều này sẽ làm ảnh hưởng chất lượng kết nối.
Tương tự thí nghiệm trên Hệ điều hành mơ phỏng Contiki, thí nghiệm với thiết bị thực tế sẽ bao gồm 3 tình huống và 2 mơ hình mạng cĩ hình thái giống nhau. Ba kịch bản bao gồm Tình huống TH1: mạng hoạt động dưới điều kiện bình thường, khơng cài Overhearing cải tiến; Tình huống TH2: mạng hoạt động dưới điều kiện bị tấn cơng DoS, khơng cài Overhearing cải tiến và Tình huống TH3: mạng hoạt động dưới điều kiện bị tấn cơng DoS, cĩ cài Overhearing cải tiến. Hai mơ hình mạng sẽ bao gồm mạng cĩ nút Bots và mạng khơng cĩ nút Bots. Về mặt vật lý, do các thiết bị được kết nối vào máy tính thơng qua cổng USB mà cĩ thể được theo dõi trên máy tính thơng qua tệp /dev trên hệ điều hành Contiki với bốn định danh là ttyUSB0,
ttyUSB1, ttyUSB2 và ttyUSB3. Thiết bị kết nối qua cổng ttyUSB0 đĩng vai trị nút Coordinator, trong khi các thiết bị kết nối qua cổng ttyUSB1, ttyUSB2 và ttyUSB3 sẽ
63
đĩng vai trị là nút Sensor đối với mơ hình mạng khơng cĩ nút Bots. Trong mơ hình mạng cĩ nút Bots thì thiết bị kết nối qua cổng ttyUSB3 sẽ đĩng vai trị nút Bots. Hình 2.5 là vị trí của các thiết bị trong thí nghiệm.
Hình 2.5. Kết nối mơ phỏng giải pháp với thiết bị thực
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