6.1. Tiêu chí và phương pháp đánh giá
Dé xác định và đánh giá hiệu suất, hiệu quả của giải pháp bộ khung, chúng tôi thực hiện đánh giá dựa trên các tiêu chí sau: chức năng, hiệu suất và phân tích khả
năng bảo mật.
Dé đánh giá tiêu chí chức năng của bộ khung, chúng tôi sẽ triển khai thu thập bang chứng số trên môi trường SDN và kiểm thử hoạt động của bộ khung đối với các mau bang chứng. Cụ thé, chúng tôi sẽ triển khai môi trường giả lập mạng SDN với các đầy đủ các thành phan cho một cuộc tan công từ chối dịch vụ DoS đơn giản bao gồm Attacker machine, Web server, IDS va Log server. Hệ thong phát hiện xâm nhập IDS sẽ ghi nhận lưu lượng tan công DoS và lưu lai bằng chứng dưới dạng file log dé chuyên về Log server, phục vụ tải lên bằng chứng cho bộ khung. Tiếp theo, chúng tôi tiến hành kiểm tra khả năng hoạt động các chức năng quan trọng của bộ khung bang cách kiểm tra các chức năng tạo và chuyền giao đối với mẫu bang chứng được thu thập. Ngoài ra còn kiểm tra thêm chức năng truy vét về nguồn gốc của các đối tượng và tính năng kiểm soát truy cập theo thuộc tính dé làm rõ lợi ich của việc áp dụng Blockchain vào quá trình điều tra.
Hiệu suất của bộ khung sẽ được đánh giá thông qua các tiêu chí độ trễ và thông lượng, chúng tôi đã sử dụng Hyperledger Caliper làm công cụ đánh giá hiệu suất. Công việc đánh giá hiệu suất của Blockchain được thực hiện với máy số 1. Chúng tôi
đã mô phỏng lại các thao tác, hành vi của nguyên mẫu cụ thể là thực hiện việc thay đổi những thông tin của bang chứng nhăm mục đích đánh giá độ trễ trung bình và
thông lượng trong các vòng khác nhau của mô hình mạng được đưa ra tương ứng.
Ngoài ra, việc tính toán mức độ sử dụng tài nguyên hệ thống cũng cần được tiến hành
dé đánh giá trọn vẹn hiệu suất của giải pháp.
Tính năng bảo mật được cung cấp trong bộ khung được đề xuất này được đánh giá bằng khả năng Thu thập bằng chứng an toàn (Evidence Acquisition), Truy vết nguồn gốc đầy đủ (Full provenance), Môi trường chống gian lận (Tamper-Proof
75
Environment), Tính toàn vẹn liên tục (Continuous Integrity) và Kiểm soát truy cập
(Access control).
6.2. Thực nghiệm và kiểm thử
6.2.1. Kiểm thử chức năng
6.2.1.1. - Triển khai môi trường tấn công
Chúng tôi xây dựng môi trường thu thập chứng cứ trong môi trường SDN trên
máy số 03. Chúng tôi giả lập môi trường SDN sử dụng bộ điều khiển Ryu và Containernet với sự hỗ trợ của công nghệ ảo hoá Docker. Chúng tôi xây dựng những Docker Image cho mục đích chuyên biệt để triển khai sử dụng như các thành phần đầu cuối (host) trong môi trường SDN.
e Ryu là bộ điều khiên SDN mã nguồn mở được thiết kế dé tăng tính linh hoạt
của mạng bang cách dễ dang quản lý và điều chỉnh cách xử lý lưu lượng truy
cập.
¢ Containernet là một nhánh của trình giả lập mạng nổi tiếng Mininet, b6 sung
thêm chức năng sử dung Docker Container như một host trong mang gia lập.
switch3 SWICHZ switch1
x — br =›
Ss
CI = El C1
logserver ids nee attacker
Hình 6-1: Mô hình mang SDN triển khai thu thập bằng chứng
Chúng tôi thử nghiệm với một cuộc tan công SYN Flood đơn giản với mục dich chính là dé IDS phát hiện và tạo log. Mô hình được xây dựng gồm 4 thành phan đầu cuối là Attacker, Web Server, snort3 IDS và Log Server được kết nối với nhau như
Hình 6-1. Các thành phan đầu cuối này là những Docker Container khởi chạy từ các Docker Image mà chúng tôi đã xây dựng từ Image gốc ubuntu:trusty và IDS được tùy chỉnh từ Docker Image ciscotalos/snort3’ của tác giả ciscotalos xây dựng dé triển
khai được nhanh chóng.
Ở ngữ cảnh tan công DOS SYN Flood, kẻ tan công dùng công cụ hping3 dé liên tục gửi các gói TCP SYN đến địa chỉ của Web Server trên công 80, gây tắc nghẽn
lưu lượng mạng. Web Server chúng tôi cài đặt Apache và sử dụng trang web mặc
định trên công 80 để phục vụ các yêu cầu, làm đích đến cho các cuộc tấn công. Switch2 sẽ day toàn bộ traffic trong mạng đến IDS dé phân tích và phát hiện tấn công. Toàn bộ phát hiện tấn công từ IDS được phát hiện sẽ được đây về logserver và ở đây thực hiện việc gửi yêu cầu tạo bằng chứng mới vào hệ thống Blockchain.
Chúng tôi thực hiện kiểm thử chức năng của bộ khung với dữ liệu phát hiện tấn
công tu IDS dưới dạng các file log dạng text và được đặt tên theo dạng “ids-
$Timestamp” với Timestamp là thời điểm phát hiện tan công và dữ liệu ghi lại phát hiện của cuộc tan công sẽ có nội dung được ghi nhận như ở Phụ lục 8-2. Theo đó, người thu thập bằng chứng có thé cấu hình cho phép thu thập tự động một cách định
kỳ va tải bang chứng đó lên hệ thống BbF nhờ bộ plugin module Bbfscript bao gồm
các file tại Bảng 6-1.
Bảng 6-1: Plugin module Bbfscript
Tén cac files M6 ta
collect.sh Thu thập bang chứng từ các nguồn dữ liệu
Xử lý các thông tin về thời gian, địa chỉ host name, IP nơi ghi nhận bằng chứng và tên bằng chứng
Là file thực thi chính, gọi uploadEvidence.py thực hiện tải
lên bằng chứng cho BbF
7 Mã nguồn: https://hub.docker.com/r/ciscotalos/snort3
77
uploadEvidence.py Thực hiện quy trình đăng nhập (/ogin.py), tải lên bang chứng
(uploadFile.py) và tạo băng chứng (createEvidence.py) login.py Goi API thực hiện đăng nhập, trả về token cho người ding
uploadFile.py Gọi API thực hiện tải lên băng chứng, mã hóa và lưu trữ trên
IPFS
createEvidence.py Gọi API thực hiện yêu cầu tao bang chứng trên hệ thống
Blockchain
Module plugin của bộ khung Bbf được dùng dé tiếp nhận và xử ly bang chứng
trước khi lưu trữ trên cơ sở dữ liệu phân tán (Distributed File Storage) và mạng
Blockcham. Bộ module bao gồm file thực thi chính là collect.sh được cấu hình thực thi định kỳ sau một khoảng thời gian (chúng tôi đang kiêm thử định kỳ mỗi 1 phút). collect.sh thu thập bang chứng từ các nguồn dữ liệu (log tan công từ Log server), xử
lý các thông tin về dữ liệu bang chứng như thời gian ghi nhận, vi tri ghi nhận (thông tin máy host bi tấn công), địa chỉ nơi ghi nhận (địa chỉ IP) và tên của bằng chứng sau
đó gọi file python uploadEvidence.py dé thực hiện tải lên bang chứng. Bang chứng
được tải lên (nhờ 2 file uploadFile.py và createEvidence.py) cùng với token lưu trong
token.txt. Mỗi lần tạo bằng chứng mới, chương trình sẽ ghi danh với tư cách là một người dùng trong hệ thống (có thé là quản trị viên của hệ thống trong tổ chức) dé lay token và thực hiện quá trình băng chứng.
6.2.1.2. Kiém thử các chức năng
e _ Chức năng tạo bằng chứng: sau khi thực hiện tan công trên SDN, file bằng chứng
được trích xuất tại một thời điểm và được gửi lên hệ thống BbF để các điều tra viên thực hiện quá trình điều tra. Kết quả thu thập bằng chứng cho thấy file bằng chứng ma ids phát hiện được lưu trên hệ thống BbF với định danh bằng chứng là
Evi-20210614101701 (Hình 6-2).
Collection Date:
CaselD
Creator: userl
Owner: userl
Decription: Attack detected log
Status: Collected
Edit Evidence Information
Evidence File:1623640622059-ids-2021-06-14-10:17:01
File Hash: d2accfi3tla747eeba85419402a4 1f6e03a49'2e8137158707 7d0td2302a5d2e
Hình 6-2: Kết qua thu thập bằng chứng tir SDN
Sau khi bang chứng được tao trên Blockchain, điều tra viên cần xem được nội dung file bang chứng dé có thé điều tra. Việc tải về file băng chứng cần được đảm bao. Hình 6-3 cho thấy chức năng tải về và xem nội dung file bằng chứng hoạt động tốt,
nội dung các đoạn log được giữ nguyên vẹn.
79
Evidence File:1623640622059-ids-2021-06-14-10:17:01
File Hash: d2accff3f1a747eeba854f9402a41f6e03a49f2e8137f587077d0fd2302a5d2e
1623640622059-ids-2021-06-14-10_17_01.txt re
~/Downloads
1{ "seconds" : 1623640608, "timestamp" : "06/14-03:16:48.248808", "action" : "allow", "class" :
"Generic ICMP event", "dir" : "C2S", "dst_addr" : "10.0.0.3", "dst ap" : "10.0.0.3:0", "eth dst" :
"26:81:FO:BA:5B:45", "eth Len" : 42, "eth src" : "9E:33:55:81:95:C7", "eth type" : "9x899", "gid" : , "icmp code" : 0, "icmp_id" : 16384, "tcmp seq" : 62465, "tcmp type" : 8, "iface" : "ids-etho",
: 57442, "ip_len" : 8, "msg" ", "mpls" : 9, "pkt gen" : "raw",
; "priority" : 3, "proto" mm " : "1:1000001:1 : 1000001, "src_addr" + + . F " : "2,213.185.42:0", "
H > ":0}
2{ "seconds" : 1623640608, "timestamp" : "06/14-03:16:48.248889", "action" : "allow", "class" :
"Generic ICMP event", "dir" : "C2S", "dst addr" : "10.0.0.3", "dst_ap" : "10.0.0.3:0", "eth_dst" :
"26:81:F9:BA:5B:45", "eth_len" : 42, "eth_src” "9E:33:55:81:95:C7", "eth_type" : "Ox800", "gid" :
1, "icmp_code" : 9, "icmp_id" : 16384, "icmp_seq" : 62721, "icmp_type" : 8, "tface" : "ids-etho",
: 10774, "ip_len" : 8, "msg" MP flood", "mpls" : 6, "pkt_gen" : "raw", "pkt_len" : 28,
; "priority" : 3, "proto" ICMP", "rev" : 1, “rule” "l:1000001:1", "service" :
" ; 1000001, "src_addr" 72.138.113.194", "src ap” : "72.138.113.194:0", "tos" : 0,
E An ":0}
3{ "seconds" : 1623640608, "timestamp" : "06/14-03:16:48.248930", "action" : "allow", "class" :
"Generic ICMP event", "dir" : "C2S", "dst addr" : "10.0.0.3", "dst_ap" : "10.0.0.3:0", "eth_dst" :
"26:81:F9:BA:5B:45", "eth_len" : 42, "eth_src" : "9E:33:55:81:95:C7", "eth type" : "9x899", "gid" :
Open yr fm = - : -
"Generic ICMP event", "dir" : "C2S", "dst_addr" : "10.0.0.3", "dst ap" : "10.0.0.3: "eth_dst" :
Plain Text ằ Tab Width: 8 x Ln 2, Col 565 ba INS
Hình 6-3: Tải về và xem nội dung file bằng chứng
e Chức năng chuyên giao bằng chứng tự động: theo như dữ liệu bang chứng được
lưu tại Evi-20210614101701, chủ sở hữu hiện tại của bang chứng là userl cũng chính là người tạo bằng chứng. Cũng theo như thứ tự của chuỗi hành trình, chủ
sở hữu tiếp theo sẽ là user2. Nếu như thực hiện chuyên giao xuôi dòng bang chứng Evi-20210614101701 mà chủ sở hữu tiếp theo là user2 thì chức năng chuyên giao bang chứng hoạt động đúng như thiết kế. Hình 6-4 là kết quả sau khi chọn chuyền giao cho chủ sở hữu tiếp theo. Bang chứng Evi-20210614101701 lúc này đã có chủ sở hữu mới là user2. Lịch sử chuyên giao và lịch sử sự kiện cũng cập nhật quá trình chuyền giao băng chứng này, giúp ich cho tat cả điều tra viên dé dang theo dõi quá trình chuyên giao bằng chứng trong quá trình điều tra.
Receiver List receiver Time
10004
Collection Date: 2021-06-14 03:17:(
Subject Operation Object
CaselD:
Creator: use
‘Owner: user2
Decription: Attac
Hình 6-4: Kết quả chuyển giao bằng chứng
Chức năng truy vết về nguồn gốc của các đối tượng: vì BbF ứng dụng công nghệ Blockchain, nó ghi lại mọi phiên bản của số cái và cách mà số cái thay đổi qua các giao dịch. Từ đó, ta có thê truy xuất về những giá trị trước đó của đối tượng. Điều này hữu ích vì nó không chỉ giúp khôi phục lại dữ liệu mà còn giúp cho điều tra viên biết hiéu được lịch sử thay đổi của đối tượng và đảm bảo khả năng chống chối bỏ của dit liệu. Việc truy hồi nguồn sốc có thê thực hiện qua một chaincode đặc biệt của Hyperledger Fabric chỉ cần định danh của đối tượng. Kết quả lay về
là một chuỗi các giao dịch trong đó mỗi phiên bản giá trị của đối tượng lại tương ứng với một giao dịch đã tao ra phiên ban đó. Hình 6-5 thé hiện khả năng truy hồi lại giá trị các phiên bản trước đó của bang chứng Evi-20210614101701 khi chủ
sở hữu của bằng chứng vẫn còn thuộc về userl tương ứng với giao dịch tao bằng
chứng.
81
e Kiểm soát truy cập theo thuộc tính: Thay đổi thuộc tính evidence_transfer của
user2 về giá tri false và thực hiện chuyền giao bằng chứng Evi-20210614101701. Lúc này, đối với đối tượng “băng chứng”, user2 không còn khả năng thực hiện hành động chuyên giao. Hình 6-6 cho thấy mặc dù user2 là chủ sở hữu của bằng chứng nhưng vì không có quyền chuyển giao nên user2 không thể tạo giao dịch chuyên giao bằng chứng. Thông báo lỗi trả về từ hai peer node của 2 tổ chức có nội dung thông báo người gửi giao dịch không được phép thực thi chuyên giao bằng chứng.
Gender: Male
Birthday: 16/08/2021
See History Value of user2
Edit Profile
Case Creator Evidence Creator
Case Updator Evidence Updator
Case Finisher Evidence Uploader
Case Deletor Evidence Transferer
Transfer Backward Transfer Forward
Hình 6-6: Kết quả kiểm thử chức năng kiểm soát truy cập
6.2.2. Kiểm thử hiệu suất
Dé xác định hiệu quả giao dịch của mô hình đề xuất, một tệp thử nghiệm được
thiết kế nhằm kiểm thử những chức năng liên quan nhất đến bằng chứng của mô hình
là cập nhật thông tin cho bằng chứng, lý do là những chức năng này tham gia trực tiếp vào việc sửa đôi trạng thái bằng chứng trên Blockchain, có thê thực hiện nhiều lần và ít bị giới hạn bởi những quyền hạn và chính sách. Việc kiểm thử được thiết kế
sẽ kiểm tra trong 10 vòng với 5 clients gửi giao dịch đồng thời với số lượng giao dịch
và tỉ lệ gửi giao dịch thay đổi. Số lượng giao dịch tại vòng thứ nhất là 2000 và tăng dần 2000 qua mỗi vòng, tối đa thử nghiệm là 20000 giao dịch tại vòng thứ 10. Tỉ lệ gửi cũng thay đổi từ 60 TPS đến 240 TPS với bước nhảy là 20 qua từng vòng. Thử
83
nghiệm được chạy nhiều lần để đạt được giá trị trung bình của các chỉ số hiệu suất với xác suất sai sót ít hơn.
Kết quả đánh giá độ trễ và thông lượng được đánh giá tại Bảng 6-2. Biêu đồ tương quan lần lượt giữa Send rate với Avg Latency và throughput được thê hiện
trong Hình 6-7 và Hình 6-8.
Bảng 6-2: Kết quả đánh giá hiệu suất
Send Max Min Avg Throughput
Round | Succ | Fail | Rate | Latency | Latency | Latency mS)
(TPS) (s) (s) (s)
1 1059 | 941 59.8 0.43 0.01 0.07 59.8
2 2406 | 1594 | 79.8 0.48 0.01 0.09 79.8
3 3633 | 2367 | 99.8 0.59 0.01 0.11 99.7
4 4421 | 3579 | 119.7. | 1.08 0.01 0.16 119.7
5 5365 | 4635 ne 1.66 0.01 0.22 139.6
| P|
6 6447 | 5553 | 159.6 | 3.57 0.01 0.79 159.4
7 7416 | 6584 | 179.6 | 10.25 0.02 3.09 176.7
8 3713 | 12287 | 97.2 107.05 0.02 29.65 92
9 1835 | 16165 | 198.5 | 32.95 0.04 21.72 170.2
10 1536 | 18464 | 188.1 | 34.05 0.03 23.69 167.2
Chu thích:
e TPS: Transaction Per Second, số giao dịch trên giây
e Succ: số lượng giao dich được gửi thành công
e Fail: số lượng giao dịch gửi đi thất bại
Send Rate (TPS): tỉ lệ gửi giao dịch, được đo băng số lượng giao dịch trên giây Max Latency va Min Latency lần lượt là độ trễ lớn nhất và độ trễ nhỏ nhất
Avg Latency: độ trễ trung bình tính bằng đơn vị giây
Throughput (TPS): số lượng giao dich trong một giây mà bộ khung có thé xử lý.
Transaction send rate vs Avg Latency
Average Latency (seconds) md rR N N w w fo) uw Oo uw © uw
ow
59.8 79.8 99.8 119.7 139.6 159.6 179.6 97.2 198.5 188.1
Send rate (TPS)
=@— Transaction send rate vs Avg Latency
Hình 6-7: Biểu đồ tương quan giữa Send rate va Avg Latency
Transaction send rate vs throughput
200 180 160 140 120 100 80 60 40 20
Throughput (TPS)
59.8 79.8 99.8 1197 1396 1596 1796 97.2 198.5 188.1
Send rate (TPS)
==®=Transaction send rate vs throughput
Hình 6-8: Biểu đồ trơng quan giữa Send rate va Throughput
85
Kết quả đánh giá hiệu suất cho thay rằng hệ thông đạt đỗ trễ xử lý thấp với số lượng giao dịch thấp hơn 16000 và tỉ lệ gửi thấp hon 180 TPS (Round 7). Khi có trên
16000 giao dịch và tỉ lệ gửi trên 180 TPS thì đỗ trễ sẽ tăng lên đột ngột khiến cho tỉ
lệ gửi thực tế giảm xuống. Từ 16000 giao dịch trở lên, đỗ trễ trung bình sẽ nằm trong khoảng từ 20-30s mỗi vòng. Đối với thông lượng, hệ thống cho thấy khả năng xử lý
ồn định (thông lượng có giá trị xấp xi tỉ lệ gửi) trong khoảng từ 2000 — 16000 giao
dịch với tỉ lệ gửi nhỏ hon 180 TPS. Từ sau mức 18000 giao dịch và 200 TPS tại
Round 8, thông lượng của đo được cho thấy tỉ lệ gửi và thông lượng đã có sự chênh lệch lớn. Hệ thống đạt tới thông lượng tối đa là 176.7 TPS. Số lượng giao dịch được
xử lý thành công ít đi và số lượng giao dịch thất bại tăng lên. Tóm lại, với mô hình mạng đã triển khai trên ha tang các máy, hệ thong cho thấy khả năng xử lý khối lượng tương đối lớn các giao dịch với độ trễ trung bình thấp và thông lượng cao.
Bên cạnh đánh giá về hiệu suất, đánh giá tài nguyên sử dụng (mức độ sử dụng CPU trung bình và bộ nhớ trung bình) của các thành phần mạng Blockchain được thể
hiện tại Bảng 6-3.
Bảng 6-3: Bộ nhớ và CPU sử dụng trong mô hình mạng Blockchain
Name CPU%(avg) _ lee
dev-peer1.org1.forennet.com-forensic_1-...933 | 9.75 50.5
dev-peer1.org2.forennet.com-forensic_1-...933 | 0.00 16.6
dev-peer2.org2.forennet.com-forensic_1-...933 | 0.00 16.6
dev-peer2.org1.forennet.com-forensic_1-...933 | 8.76 51.8
peer1.org1.forennet.com 29.71 282
peer1.org2.forennet.com 5.38 141
peer2.org2.forennet.com 5.74 148
peer2.org1.forennet.com 31.09 281
orderer3.orderers.forennet.com 0.57 73.5
orderer2.orderers.forennet.com 0.42 72.8
orderer1.orderers.forennet.com 0.66 93.1
couchdb_peer2.org2.forennet.com 1.65 60.9
couchdb_peer1.org2.forennet.com 2.38 62.2
couchdb_peer2.org1.forennet.com 14.96 109
couchdb_peer1.org1.forennet.com 14.43 109
rca.org2.forennet.com 0.00 9.20
rca.org1.forennet.com 0.00 10.2
rca.orderer.forennet.com 0.00 5.78
tls-ca.org2.forennet.com 0.00 6.11
tls-ca.org1.forennet.com 0.00 6.10
tls-ca.orderer.forennet.com 0.00 6.01
6.2.3. Danh gia bao mat
Bộ khung dé xuất được thiết kế hiệu quả dé hỗ trợ tăng cường bảo mật cho quá trình thu thập, bảo quản và điều tra bằng chứng. Phân tích bảo mật cho bộ khung đề
xuât được mô tả như sau:
e Thu thập bằng chứng an toàn (Evidence Acquisition): BbF đảm bảo tat cả
dữ liệu quan trọng với công việc điều tra được lưu trữ trong bộ khung mà điều tra viên có thé truy cập va xử lý. Bang chứng được tải lên hệ thống sẽ được bảo vệ tính bi mật bang các phương pháp mã hóa.
e Truy vết nguồn gốc day đủ (Full provenance): Bộ khung cho phép truy
nguyên nguồn gốc của bất kỳ sự kiện hoặc hành động nào ở nơi ban đầu nó
tham gia vào quy trình bảo quản và xử lý. Dưới logic ứng dụng của các hợp
đồng thông minh, thông tin nguồn gốc của sự kiện được truy xuất đầy đủ tùy theo các thuộc tính của sự kiện bao gồm thời gian, chi tiết hành động,
87