Tổng quan về hành vi người dùng và vấn đề an ninh bảo mật trong mạng IOT; xây dựng giả lập một hệ sinh thái IOT; giả lập hình thức tấn công từ đầu cuối người dùng trong mạng IOT; giải pháp phát hiện và giảm thiểu tấn công.
TRƢỜNG ĐẠI HỌC BÁCH KHOA HÀ NỘI LUẬN VĂN THẠC SĨ Nghiên cứu an ninh mạng đƣờng truyền vô tuyến mạng IOT dân dụng VŨ VIỆT ĐỨC Ngành Kỹ thuật Viễn Thông Giảng viên hƣớng dẫn: PGS TS Trương Thu Hương Viện: Điện Tử - Viễn Thông Chữ ký GVHD HÀ NỘI, 10/2020 CỘNG HÒA XÃ HỘI CHỦ NGHĨA VIỆT NAM Độc lập – Tự – Hạnh phúc BẢN XÁC NHẬN CHỈNH SỬA LUẬN VĂN THẠC SĨ Họ tên tác giả luận văn: Vũ Việt Đức Đề tài luận văn: Nghiên cứu an ninh mạng đường truyền vô tuyến mạng IOT dân dụng Chuyên ngành: Kỹ Thuật Viễn Thông Mã số SV: CA190151 Tác giả, Người hướng dẫn khoa học Hội đồng chấm luận văn xác nhận tác giả sửa chữa, bổ sung luận văn theo biên họp Hội đồng ngày 30/10/2020 với nội dung sau: - Bổ sung xếp thuật ngữ viết tắt theo thứ tự A-B-C - Hiệu chỉnh lỗi soạn thảo in ấn - Việt hóa vẽ lại hình vẽ mờ - Bổ sung số liệu lưu lượng công - Đưa chế phát công Ngày 16 tháng 11 năm 2020 Giáo viên hƣớng dẫn Tác giả luận văn PGS TS Trương Thu Hương Vũ Việt Đức CHỦ TỊCH HỘI ĐỒNG PGS TS Nguyễn Tài Hưng LỜI CẢM ƠN Lời đầu tiên, xin gửi lời cảm ơn tới Viện Điện tử - Viễn thông, Đại học Bách Khoa Hà Nội, nơi tạo điều kiện hội cho tham gia học tập để hồn thành chương trình cao học bậc Thạc Sỹ Xin gửi lời cảm ơn chân thành sâu sắc tới PGS TS Trương Thu Hương, người tận tình định hướng, giúp đỡ hướng dẫn tơi q trình thực luận văn Củng cố thêm kiến thức chuyên ngành phương pháp làm việc nghiên cứu Bên cạnh xin gửi lời cảm ơn tới nhóm bạn sinh viên phòng nghiên cứu Future Internet Lab, Viện Điện tử - Viễn thông tạo điều kiệu cho sử dụng sở vật chất Lab để phục vụ q trình hồn thiện luận văn, hỗ trợ giúp đỡ qn trình xây dựng mơ hình giả lập để lấy kết đánh giá thực tế Nhờ có giúp đỡ giúp tơi hồn thiện luận văn ngày hôm Xin chân thành cảm ơn! Hà Nội, ngày 16 tháng 11 năm 2020 Học viên Vũ Việt Đức i LỜI CAM ĐOAN Tôi Vũ Việt Đức, mã học viên CA190151, học viên lớp cao học CH2019A Đai học Bách Khoa Hà Nội Người hướng dẫn PGS TS Trương Thu Hương Tôi xin cam đoan tồn nội dung tơi trình bày luận văn “Nghiên cứu an ninh mạng đường truyền vô tuyến mạng IOT dân dụng” kết trình tìm hiểu nghiên cứu tôi, hướng dẫn PGS TS Trương Thu Hương, với hỗ trợ giúp đỡ thành viên nhóm nghiên cứu an ninh mạng IoT phòng nghiên cứu Future Internet Lab , Viện Điện Tử - Viễn Thông, Đại học Bách Khoa Hà Nội Các số liệu kết luận văn hoàn toàn trung thực, phản ánh kết thực tế Mọi thơng tin trích dẫn tuân thủ quy định sở hữu trí tuệ, tài liệu tham khảo liệt kê rõ nguồn gốc Tơi xin chịu hồn tồn trách nhiệm với nội dung viết luận văn Hà Nội, ngày 16 tháng 11 năm 2020 Người cam đoan Vũ Việt Đức ii TÓM TẮT LUẬN VĂN IoT mạng kết nối hàng tỷ thiết bị, với tảng liên kết chặt chẽ, cốt lõi giá trị hệ thống tập liệu khổng lồ Có thể thấy rằng, hệ sinh thái IoT ngày da dạng phát triển không ngừng Trong tương lai, tất vật, thiết bị kết nối với trở thành IoE (Internet of Everything) IoT thúc đẩy việc số hóa thơng minh ngành, tầng lớp xã hội, trở thành động lực thúc đẩy chuyển đổi số khắp giới, mang lại giá trị kinh tế lớn Bên cạnh đó, ln tiềm ẩn điểm yếu nguy vấn đề bảo mật an ninh mạng Một nguyên nhân lớn điểm yếu đến từ hành vi bảo mật người dùng mơi trường mạng IoT, vơ hình chung tạo hội cho kẻ công thực ý đồ biến thành nạn nhân cơng Do đó, hệ thống IoT địi hỏi phải có chế phát cơng cách xác, nhanh chóng kịp thời Bởi vầy để nghiên cứu tiếp cận vấn đề này, luận văn đưa hướng tiếp cận xây dựng mơ hình giả lập hệ sinh thái IoT với đầy đủ thành phần nhất, phục vụ cho trình đánh giá khảo sát vấn đề bảo mật hệ thống IoT Cùng với việc thực giả lập lại số kịch công nhận diện cơng mơ hình xây sựng đề xuất, phạm vi luận văn tập trung vào loại công TCP SYN Flood Các kết đạt cho thấy giải pháp logic đưa hoàn toàn phù hợp với lý thuyết thử nghiệm tốt mơ hình xây dựng iii MỤC LỤC LỜI CẢM ƠN i LỜI CAM ĐOAN ii TÓM TẮT LUẬN VĂN iii DANH MỤC BẢNG BIỂU vi DANH MỤC HÌNH VẼ vii DANH MỤC KÝ HIỆU VÀ CHỮ VIẾT TẮT viii PHẦN MỞ ĐẦU ix CHƢƠNG HÀNH VI NGƢỜI DÙNG VÀ VẤN ĐỀ AN NINH BẢO MẬT TRONG MẠNG IOT 1.1 Giới thiệu chung 1.2 Vấn đề an ninh bảo mật mạng IoT 1.2.1 Tổng quan công từ chối dịch vụ phân tán 1.2.2 Cơ chế hình thức cơng TCP SYN Flood 1.3 Kết luận 12 CHƢƠNG XÂY DỰNG GIẢ LẬP MỘT HỆ SINH THÁI IOT 13 Thành phần hệ sinh thái IoT 13 2.1 2.1.1 Kiến trúc mạng IoT 13 2.1.2 Cơ sở hạ tầng 18 2.1.3 Giao thức truyền thông 20 2.1.4 Cloud dịch vụ 26 Đề xuất xây dựng mơ hình giả lập 27 2.2 2.3 2.2.1 Tổng quan mơ hình giả lập hệ thống IoT 27 2.2.2 Các thành vật lý mơ hình 29 2.2.3 Các giao thức kết nối 31 Kết luận 32 iv CHƢƠNG GIẢ LẬP HÌNH THỨC TẤN CƠNG TỪ ĐẦU CUỐI NGƢỜI DÙNG TRONG MẠNG IOT 33 3.1 Giả lập nguồn công môi trường mạng IoT 33 3.2 Công cụ sử dụng xây dựng giả lập nguồn phát công 35 3.2.1 TCPrewrite 35 3.2.2 TCPreplay 36 3.2.3 Resmon 37 3.2.4 Wireshark 38 3.3 Kết luận 38 CHƢƠNG GIẢI PHÁP PHÁT HIỆN VÀ GIẢM THIỂU TẤN CÔNG 39 Phương pháp xây dựng giải pháp 39 4.1 4.1.1 Phân tích tracefile liệu mạng IoT 40 4.1.2 Cơ chế giảm thiểu luồng công 46 Kết triển khai kịch đánh giá 46 4.2 4.3 4.2.1 Đánh giá hiệu hệ thống 48 4.2.2 Đánh giá độ xác phương pháp phát giảm thiểu công 51 Kết luận 53 KẾT LUẬN 54 Kết luận chung 54 Hướng phát triển 54 TÀI LIỆU THAM KHẢO 56 v DANH MỤC BẢNG BIỂU Bảng 2.1 Luồng kết nối với QoS = 0[9] 24 Bảng 2.2 Luồng kết nối với QoS = 1[9] 24 Bảng 2.3 Luồng kết nối với QoS = 2[9] 25 Bảng 4.1 Thống kê lưu lượng công TCP SYN Flood 42 Bảng 4.2 Số lượng gói tin với cờ tương ứng 43 Bảng 4.3 Tỉ lệ cặp quan hệ SYN/FIN, ACK/SYN 44 Bảng 4.4 Bảng thống kê số lượng gói tin với cờ SYN, FIN 52 Bảng 4.5 Số lượng gói tin thuộc loại lưu lượng điểm hệ thống 52 Bảng 4.6 Tỉ lệ phát xác loại lưu lượng 53 vi DANH MỤC HÌNH VẼ Hình 1.1 Các thành phần kiến trúc IoT[2] Hình 1.2 Kiến trúc mạng Botnet[3] Hình 1.3 Phân loại cơng DDoS Hình 1.4 Cấu trúc TCP header Hình 1.5 Quá trình bắt tay bước TCP 10 Hình 1.6 Kịch công TCP SYN Flood 11 Hình 2.1 Kiến trúc tham chiếu WSO2[6] 14 Hình 2.2 Kiến trúc Microsoft Azure[7] 17 Hình 2.3 Raspberry Pi 19 Hình 2.4 Mơ hình Master/Slave[13] 21 Hình 2.5 Giao thức CoAP[8] 22 Hình 2.6 Mơ hình giao thức MQTT[9] 23 Hình 2.7 Mơ hình hệ thống 28 Hình 2.8 Raspberry Pi Model B+[11] 30 Hình 2.9 Thiết bị IoT với NodeMCU, cảm biến bụi mịn, nhiệt độ, độ ẩm áp suất 31 Hình 2.10 Mosquitto Server 32 Hình 3.1 Mơ hình hệ thống giả lập cơng 34 Hình 3.2 Giao diện Wireshark 38 Hình 4.1 Phân bố thời gian tồn luồng (trạng thái bình thường) 40 Hình 4.2 Phân bố thời gian tồn luồng (trạng thái cơng) 41 Hình 4.3 Số lượng luồng trạng thái công 42 Hình 4.4 Sơ đồ nhận biết công 45 Hình 4.5 Hệ thống triển khai thực tế 47 Hình 4.6 Số lượng luồng qua Gateway hai trường hợp 49 Hình 4.7 Tài nguyên chiếm dụng Raspberry Pi trường hợp chưa có module 50 Hình 4.8 Tài nguyên chiếm dụng Pi trường hợp có module 51 vii DANH MỤC KÝ HIỆU VÀ CHỮ VIẾT TẮT Kí hiệu chữ viết tắt CoAP DoS Thuật ngữ tiếng Anh Constrained Application Giao thức ứng dụng ràng Protocol buộc Denial of Services Tấn công từ chối dịch vụ DDoS Distributed Denial of Services HTTP HyperText Transfer Protocol IoT Thuật ngữ tiếng Việt Tấn công từ chối dịch vụ phân tán Internet of Things Mạng kết nối vạn vật Message Queuing Telemetry Truyền tin dùng chế Transport hàng đợi QoS Quality of Service Chất lượng dịch vụ TCP Transmission Control Protocol UDP User Datagram Protocol MQTT Botnet Mạng máy tính ma Máy chủ dịch vụ MQTT Broker (MQTT) Publisher (MQTT) Subscriber (MQTT) Thiết bị với nhiệm vụ gửi tin lên tới server Thiết bị nhận tin gửi từ server viii Để có kết phát cơng đồng thời sử dụng cơng cụ wireshark để bắt gói tin qua gateway, giám sát tiến trình luồng công TCP từ nhiều địa IP khác file cơng Nhìn vào hình ta thấy luồng lưu lượng công hay luồng trạng thái chờ (half-open) trì vịng 60s, khoảng thời gian dài công xảy ra, mà hệ thống có trạng thái lưu lượng cao gây tình trạng chiếm dụng cạn kiệt tài nguyên để xử lý tác vụ khác, làm giảm khả đáp ứng hệ thống Hầu hết luồng có gói tin tin SYN (cờ SYN TCP header set) Như ta biết, mở đầu cho kết nối TCP trình bắt tay ba bước với với đặc trưng xuất trạng thái cờ SYN, SYN/ACK, ACK kết thúc cho phiên TCP cờ FIN xuất hiện, dựa vào kết hợp với phân bố khoảng thời gian tồn luồng TCP ta biết đâu kết nối TCP hoàn chỉnh đâu kết nối trạng thái chờ Chi tiết hơn, học viên thống kê tổng số lượng gói tin với cờ đặc trưng (SYN, FIN, ACK) có xuất phần TCP header hai trạng thái lưu lượng cơng bình thường thể Bảng 4.2 Bảng 4.2 Số lượng gói tin với cờ tương ứng Loại lƣu lƣợng FIN SYN ACK Bình thường 238 240 918 Tấn cơng 12 38 497 14 Dựa vào bảng ta thấy mối tương quan số lượng gói tin với cờ đặc trưng hai trạng thái lưu lượng Theo với lưu lượng bình thường tổng số gói tin có cờ SYN FIN tương đương nhau, kết nối TCP lưu lượng thường có thời gian tồn ngắn kết nối hồn chỉnh nên có đầy đủ trình bắt tay ba bước kết thúc đóng phiên TCP Cùng với số lượng ACK lớn, phiên TCP thiết lập kết nối diễn trình trao đổi liệu số lượng ACK tăng theo Ngược lại, với lưu lượng cơng ta thấy phần lớn tin có cờ SYN = 1, số lượng gói tin có FIN ACK so với SYN Với số lượng cờ FIN ít, thể có nhiều yêu cầu kết nối 43 gửi đi, nhiên trình gửi liệu chưa diễn (số lượng ACK ít) kết nối trạng thái chờ hồn thành kết nối đóng phiên làm việc ( số lượng gói tin có cờ FIN ít) Từ ta rút yếu tố giúp nhận biết hai trạng thái bình thường cơng tỉ lệ số lượng cặp quan hệ (SYN, FIN) (SYN, ACK) Để nhận biết cơng cần đặt mức tỉ lệ làm chuẩn cho thông số tỉ lệ số lượng cặp cờ Như kết trình bày phía ta thấy có khác thời gian tồn luồng, với liệu bình thường cỡ 0.35s cịn công 7s Học viên tiến hành đặt khoảng thời gian xét (cửa sổ giám sát lưu lượng) khác để thống kê chênh lệch cặp quan hệ cờ Kết thể Bảng 4.3 Bảng 4.3 Tỉ lệ cặp quan hệ SYN/FIN, ACK/SYN Trạng thái bình thƣờng Thời Trạng thái công SYN_FIN SYN_ACK SYN_FIN SYN_ACK (SYN/FIN) (ACK/SYN) (SYN/FIN) (ACK/SYN) 0.35 0.983 496.566 3208 0.00036 0.5 0.985 500.58 3265 0.00033 0.95 505.48 3290 0.0003 0.955 515.56 3512 0.00022 0.953 530.57 3800 0.00015 0.982 548.12 3910 0.0001 0.964 555.89 4251 0.00005 0.965 562.11 4536 0.000012 0.97 570.74 4812 0.000009 gian xét (s) Nhìn vào Bảng 4.3 ta thấy với ngưỡng cửa sổ thời gian xét khác nhau, tỉ lệ cặp SYN/FIN trạng thái bình thường xấp xỉ ngưỡng 0.95-1.0 trạng thái công số lượng cờ SYN gấp nhiều lần so với cờ FIN kết nối trạng thái chờ khơng thực truyền liệu đóng kết nối Ngược lại với tỉ lệ cặp ACK/SYN trạng thái bình thường lại lớn nhiều 44 lần so với trạng thái công mà trạng thái bị công số lượng tin ACK phiên TCP chưa thiết lập nên khơng có q trình truyền liệu Từ kết phân tích học viên đề xuất chế giám sát phát công nhờ vào việc thiết lập cửa sổ thời gian giám sát 7s (vì hầu hết luồng cơng TCP SYN Flood tồn vịng 7s trình bày trên) Trong khoảng thời gian tiến hành thống kê số lượng gói tin có cờ SYN, ACK FIN, sau đưa cặp tỉ lệ SYN/FIN ACK/SYN Qúa trình phát công theo quy tắc thời gian giám sát 7s tỉ lệ SYN/FIN nằm khoảng từ 0.95 tới tức toàn luồng kết bối bình thường, trình bắt tay ba bước thành cơng truyền liệu hồn thành cờ FIN (mỗi FIN tương ứng với SYN) Ngược lại, tỉ lệ SYN/FIN không nằm khoảng bình thường này, xét điều kiện ACK/SYN < luồng khoảng thời gian xét cơng số lượng SYN cao ACK lại nhỏ chứng tỏ kết nối chờ kẻ công gửi tới Mặt khác xét điều kiện ACK/FIN giúp ta tránh trường hợp mà người dùng có phiên kết nối dài, số lượng cờ FIN so với SYN có nhiều ACK người dùng hợp pháp gửi liệu cho phiên kết nối Hình 4.4 Sơ đồ nhận biết cơng 45 4.1.2 Cơ chế giảm thiểu luồng công Với hai tiêu chí đặt giảm số lượng luồng cơng lên Cloud, giải phóng băng thơng đường truyền gateway với cloud có cơng xảy ra, đường truyền trao đổi cloud với thiết bị IoT lấy liệu phục vụ cho ứng dụng dịch vụ khác nên khơng cho phép có gián đoạn Nếu cơng xảy có nhiều luồng với vơ số gói tin gửi lên Cloud thơng qua gateway, điều làm cho băng thông đường truyền bị cạn kiệt, dẫn tới người dùng truy cập để lấy liệu kiểm sốt mơ hình, trạng mạng Vì cần phải có chế giám sát giảm thiểu luồng công trực tiếp lên cloud hay server, thực thiết bị Raspberry PI giả lập SmartGateway Dựa vào kết phân tích thực tế mơ hình từ file liệu có sẵn xác định giá trị ngưỡng chịu tải hệ thống có cơng xảy Theo trạng thái tài nguyên hệ thống mức tối đa lúc số luồng cơng đến hệ thống tới 2500 luồng, cụ thể công TCP SYN Flood, luồng cơng luồng có gói trạng thái half-open mà khơng phải thiết lập kết nối Bằng việc áp dụng giải pháp đặt cửa sổ giám sát 7s để giám sát lưu lượng mạng kết đánh giá tỉ lệ số lượng gói tin với cặp cờ SYN/FIN ACK/SYN giúp ta phát đâu luồng công Sau đưa cảnh báo có cơng mạng thiết bị Gateway hủy tồn luồng có tin SYN mà khơng có FIN tồn hệ thống Cùng với trường hợp trạng thái SYN trì khơng có ACK, luồng bị hủy không cho qua Gateway 4.2 Kết triển khai kịch đánh giá Dưới hướng dẫn PGS TS Trương Thu Hương với hỗ trợ từ nhóm Security Future Internet Lab, học viên xây dựng thành cơng mơ hình giả lập đề xuất thực tế, với đầy đủ thành phần chức mơ tả (Hình 4.5) 46 Hình 4.5 Hệ thống triển khai thực tế Máy công có chức tạo luồng lưu lượng mạng bao gồm lưu lượng bình thường xen lẫn lưu lượng công qua Smart Gateway tới máy Server Trong mơ hình này, máy cơng thiết lập đại diện cho nhóm thiết bị IoT với nhiều địa IP khác thành phần botnet bị chiếm quyền điều khiển thực phát cơng Trong mơ hình này, ta sử dụng máy cơng với cấu sau: • CPU: i5-4570 @ 3.2GHz x • RAM: 8GB • Hệ điều hành: Kali Linux 2020 64bit • Cơng cụ: Wireshark, TCPrewrite, TCPreplay Dựa mơ hình tiến hành thử nghiệm đánh giá bao gồm đánh giá mặt hiệu hệ thống đánh giá độ xác phương pháp phát giảm thiểu công sử dụng.theo hai trường hợp: Hệ thống không sử dụng giải pháp chống công hệ thống có sử dụng giải pháp chống công TCP SYN Flood 47 4.2.1 Đánh giá hiệu hệ thống Trong luận văn này, hiệu hệ thống đánh giá qua tiêu chí mức độ tiêu tốn tài nguyên RAM CPU thiết bị gateway nơi mà triển khai giải pháp phát giảm thiểu công CPU (Central Processing Unit) xử lý trung tâm máy tính CPU xử lý tất lệnh mà nhận từ phần cứng phần mềm chạy máy tính CPU chiếm dụng nhiều cho thấy hệ thống phải làm việc nhiều tiêu tốn nhiều công suất RAM (Random Access Memory) định nghĩa cách ngắn gọn nhớ tạm máy tính giúp lưu trữ thơng tin hành để CPU truy xuất xử lý Máy tính nạp liệu ứng dụng hoạt động RAM để truy xuất nhanh hơn, RAM có tốc độ nhanh gấp hàng chục tới hàng trăm lần so với ổ cứng truyền thống RAM lưu trữ liệu ngừng cung cấp nguồn cho Nếu máy tính bị nguồn, tắt máy liệu Ram bị xóa Tương tự CPU, RAM bị chiếm dụng nhiều tức hệ thống phải làm việc vất vả Với mục tiêu kẻ công nhằm vào tài nguyên hệ thống để làm cạn kiệt nguồn lực xử lý gián đoạn ứng dụng dịch vụ triển khai ta cần tính tốn mức độ sử dụng tài ngun thể tính hiệu hệ thống Đồ thị Hình 4.6 thể số lượng luồng tới trường hợp có sử dụng module khơng sử dụng module 48 Hình 4.6 Số lượng luồng qua Gateway hai trường hợp Từ Hình 4.6 cho ta thấy khác biệt trường hợp áp dụng trường hợp không áp dụng giải pháp Gateway sử Từ đồ thị ta thấy rằng, tốc độ phát 150 gói tin/s phát 20s không sử dụng module, số lượng flow trạng thái half_open gateway lớn lớn xấp xỉ 2500 flow kết trình bày phần khảo sát thời gian tồn flow kéo dài tới 60s Điều gây tốn tài nguyên cloud gateway công với cường độ lưu lượng lớn dẫn tới thiết bị khơng cịn khả xử lý Trong khi sử dụng giải pháp đưa với điều kiện cơng sau khoảng thời gian 7s số lượng flow giảm mạnh công xảy đạt giá trị lớn khoảng gần 500 flows Ngoài trạng thái luồng kết nối chờ tồn ngắn khoảng hai lần so với trường hợp không sử dụng giải pháp Giúp cho hệ thống giảm tình trạng q tải cạn kiệt tài nguyên Về vấn đề đánh giá mức độ chiếm dụng tài nguyên hệ thống thực gateway cụ thể thiết bị Raspberry PI Luận văn thực theo dõi hai thông số RAM CPU gateway trường hợp có công lúc không chạy giải pháp phát giảm thiểu lúc có kết hợp giải 49 pháp Đây yếu tố quan trọng việc đánh giá hiệu hệ thống Tài nguyên chiếm dụng 45 40 35 30 % 25 20 15 10 5 11 13 15 17 19 21 23 25 27 29 31 33 35 37 39 41 43 45 47 49 51 53 55 57 59 61 Thời gian (s) %CPU %RAM Hình 4.7 Tài nguyên chiếm dụng Raspberry Pi trường hợp chưa có module 50 Tài nguyên chiếm dụng 50 45 40 35 % 30 25 20 15 10 5 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 Thời gian (s) Series1 Series2 Hình 4.8 Tài nguyên chiếm dụng Pi trường hợp có module Từ Hình 4.7 Hình 4.8 ta thấy hai trường hợp khơng có áp dụng module giải pháp phát phịng chống cơng mức độ tiêu tốn tài nguyên thiết bị gateway khơng có thay đổi nhiều, cỡ khoảng 5% Chứng tỏ giải pháp khả thi triển khai thiết bị IoT bị hạn chế lực xử lý khả lưu trữ 4.2.2 Đánh giá độ xác phƣơng pháp phát giảm thiểu công Để đánh giá độ xác giải pháp để xuất, học viên tiến hành đồng thời việc sử dụng công cụ wireshark để thu lại lưu lượng thiết bị gateway Lưu lượng thu hai vị trí đầu vào đầu gateway Thu thập lưu lượng đầu gateway để đánh giá hiệu giải pháp phát giảm thiểm công đưa Thống kê số lượng gói tin chuyển tiếp lên server sau xử lý module phát công Với liệu thu đầu gateway, trước tiên thống kê số lượng tin tương ứng có xuất cờ FIN SYN 51 Bảng 4.4 Bảng thống kê số lượng gói tin với cờ SYN, FIN Loại lƣu lƣợng Số lƣợng gói tin SYN FIN 658 627 Ta thấy số lượng tin SYN thu sau gateway 658 số lượng FIN 627 (tỉ lệ SYN/FIN = 1.16), nằm mức ngưỡng đặt từ trước, điều chứng tỏ có số lượng gói tin công bị phân loại nhầm, tức gateway cho qua Để có thống kê chi tiết số lượng, ta tiến hành đối chiếu với liệu thu đầu vào gateway Ở đây, lưu lượng bình thường sinh trực tiếp từ thiết bị IoT nên ta khơng thể kiểm sốt có gói phát đi, luận văn lấy số lượng gói tin bình thường thu gateway để phục vụ cho việc đánh giá Việc đếm số lượng gói tin thu loại (tấn cơng/bình thường) dựa trường địa IP nguồn Trong mơ hình giả lập ta biết địa IP thiết bị IoT bình thường, xác định đâu gói xuất phát từ nguồn cơng đâu gói tin xuất phát từ nguồn bình thường Bảng 4.5 Số lượng gói tin thuộc loại lưu lượng điểm hệ thống Loại lƣu lƣợng Bình thƣờng Tấn cơng Tổng số Số gói tin Số gói thu đƣợc Số gói thu đƣợc phát đầu vào Gateway đầu Gateway - 518 132 48 103 44 815 753 - 50 733 885 Dựa vào Bảng 4.5, thấy tỉ lệ số gói cơng thu so với số phát đạt 93.12% (44 815 gói) Như phân tích chênh lệch số lượng cờ SYN FIN phía trên, thơng quan kết Bảng 4.5 ta thấy có 753 gói tin cơng bị bỏ xót, tỉ lệ 8.37% (tức 91,63% phát gói cơng) Đối với lưu lượng bình thường tỉ lệ phát đạt 91.46% 52 Bảng 4.6 Tỉ lệ phát xác loại lưu lượng Loại lƣu Số gói thực tế lƣợng Số phát Số phát Tỉ lệ phát nhầm (%) Bình thƣờng 518 132 386 91.46% Tấn cơng 44 815 41 062 753 91.63% Nhìn chung với hai loại lưu lượng tỉ lệ phát xác đạt 91.61%, nhiên tỉ lệ phát phân loại nhầm lưu lượng cơng cịn khác cao cần phải cải thiện Các kết bước đầu cho thấy giải pháp đưa có hiệu việc phát giảm thiểu cơng 4.3 Kết luận Nội dung chương trình bày trình đưa giải pháp phát giảm thiểu công thực thiết bị IoT gateway, điều giúp cho hệ thống phản hồi nhanh có công xảy Thông qua việc triển khai mô hình giả lập luận văn áp dụng chế phát giảm thiểu công thực tế, đánh giá hiệu hệ thống thông qua thông số độ tiêu tốn tài nguyên RAM CPU Các kết đạt loại cơng TCP SYN cho thấy có sử dụng giải pháp tài nguyên hệ thống trì ổn định khơng biến động nhiều so với trường hợp khơng có giải pháp Số lượng luồng giảm thiểu đáng kể, độ xác đạt 91,61% cho hai loại lưu lượng bình thường công 53 KẾT LUẬN Kết luận chung Với nội dung trình bày luận văn, ta thấy vấn đề an ninh mạng IoT vấn đề nhiều nan giải, mối nguy hại lớn xuất phát từ thiếu kiểm soát hành vi người dùng truy cập sử dụng ứng dụng hệ thống IoT Chính việc nghiên cứu phát triển giải pháp phát phòng giảm thiểu công mạng IoT vô quan trọng Luận văn đề xuất mơ hình giả lập hệ thống IoT mơ lại hình thức công từ đầu cuối người dùng Dựa việc phân tích file liệu cơng có sẵn công mạng IoT để đưa ngưỡng giá trị ngưỡng hệ thống trạng thái công từ ta áp dụng vào mơ hình giả lập thực tế Kết đạt cho thấy luồng công giảm thiểu đáng kể, giảm số lượng kết nối chờ công TCP SYN Flood, việc triển khai không làm ảnh hưởng nhiều tới tiệu thụ tài nguyên hệ thống so với trường hợp thông thường, phù hợp với loại thiết bị IoT bị hạn chế lực phần cứng khả xử lý Vị trí triển khai thiết bị gateway, gần nguồn cơng giúp cho q trình phát đưa cảnh báo nhanh hơn, bảo vệ cloud hệ thống an tồn Bên cạnh phương pháp đề xuất luận văn nhiều nhược điểm chưa có chế đánh giá độ xác việc chặn luồng tới hệ thống, chưa khảo sát với loại công khác triển khai mơ hình rộng Hƣớng phát triển Trong tương lại, để có xây dựng hệ thống cách tồn diện triển khai môi trường thực tế Học viên tiếp tục nghiên cứu cụ thể hình thức cơng từ chối dịch vụ khác triển khai thử nghiệm mơ hình Đưa quy tắc chung để phát nhiều loại hình cơng khác khơng cơng TCP SYN Flood Tối ưu cải tiến phương pháp phát giảm thiểu công cách áp dụng kỹ thuật tiên tiến học máy Triển khai đánh giá nhiều kịch Do hạn chế thời gian kiến thức lực nghiên cứu, luận văn khó tránh khỏi thiếu xót, mong nhận góp ý nhận xét 54 từ thầy (cô) Hội đồng để học viên chỉnh sửa thực tốt tương lai Một lần xin gửi lời cảm ơn tới PGS TS Trương Thu Hương với tập thể sinh viên nhóm an ninh mạng IoT FIL Lab nhiệt tình giúp đỡ để học viên hồn thành luận văn 55 TÀI LIỆU THAM KHẢO [1] The Growth in Connected IoT Devices Is Expected to Generate 79.4ZB of Data in 2025, According to a New IDC Forecast , 18 June 2019 URL https://www.idc.com/getdoc.jsp?containerId=prUS45213219#:~:text=A%20new %20forecast%20from%20International,these%20devices%20will%20also%20gr ow Truy cập lần cuối 05/10/2020 [2] Internet of things (IoT) URL: https://internetofthingsagenda.techtarget.com/definition/Internet-of-Things-IoT , truy cập lần cuối 5/10/2020 [3] WHAT IS A BOTNET? https://www.security-audit.com/what-is-a-botnet/ Truy cập lần cuối 06/10/2020 [4] http://www.mystown.com/2015/12/cac-ki-thuat-tan-cong-ddos-drdos- va.html truy cập lần cuối vào ngày 07/10/2020 [5] HP Study Reveals 70 Percent of Internet of Things Devices Vulnerable to Attack https://www8.hp.com/sg/en/hp-news/pressrelease.html?id=1744676#.XvlwHSgzZEZ Truy cập lần cuối 07/10/2020 [6] WSO2, "White paper: A reference architecture for the Internet of Things", 2015 [7] Microsoft Azure, "Microsoft Azure IoT services Reference Architecture", 2016 [8] Carsten Bormann et al, "CoAP: An Application Protocol for Billions of Tiny Internet Nodes", IEEE Computer Society, Vol 16, No 2, pp 62-67, Mar-Apr 2012 [9] OASIS, "MQTT Version 3.1.1 Committee Specification Draft 02 /Public Review Draft 02", 2014 [10] Dinesh Thangavel et al, "Performance Evaluation of MQTT and CoAP via a Common Middleware", Intelligent Sensors, Sensor Networks and Information Processing (ISSNIP), Singapore, 21-24 April 2014 [11] https://www.raspberrypi.org/, truy nhập lần cuối ngày 05/10/2020 [12] https://vi.wikipedia.org/wiki/IEEE_802.11 truy cập lần cuối 05/10/2020 56 [13] https://www.bluetooth.com/, truy nhập lần cuối ngày 05/10/2020 [14] Hyunjae Kang, Dong Hyun Ahn, Gyung Min Lee, Jeong Do Yoo, Kyung Ho Park, Huy Kang Kim, “IoT network intrusion dataset”, IEEE Dataport, 2019 [Online] Available: http://dx.doi.org/10.21227/q70p-q449 Accessed: Oct 16, 2020 57 ... ? ?Nghiên cứu an ninh mạng đường truyền vô tuyến mạng IOT dân dụng? ?? kết trình tìm hiểu nghiên cứu tôi, hướng dẫn PGS TS Trương Thu Hương, với hỗ trợ giúp đỡ thành viên nhóm nghiên cứu an ninh mạng IoT. .. VĂN THẠC SĨ Họ tên tác giả luận văn: Vũ Việt Đức Đề tài luận văn: Nghiên cứu an ninh mạng đường truyền vô tuyến mạng IOT dân dụng Chuyên ngành: Kỹ Thuật Viễn Thông Mã số SV: CA190151 Tác giả,... mục đích xấu, nhằm phá hoại quan tổ chức doanh nghiệp 1.2 Vấn đề an ninh bảo mật mạng IoT Vấn đề bảo mật an ninh mạng IoT coi vấn đề lớn với IoT Những cảm biến mạng IoT thực thu thập liệu số có