MỞ ĐẦU
1. Tính cấp thiết của đề tài
Tấn công từ chối dịch vụ (Denial of Service - DoS) là một dạng tấn công mạng nguy
hiểm mà tin tặc thường sử dụng để làm gián đoạn hoạt động của một hệ thống thông
tin. Để thực hiện một cuộc tấn công từ chối dịch vụ hiệu quả, có thể vượt qua sự
phòng chống của đối tượng bị tấn công, tin tặc thường tổ chức cuộc tấn công với sự
tham gia đồng thời từ nhiều máy tính khác nhau; hình thức này thường được gọi là
tấn công từ chối dịch vụ phân tán (Distributed Denial of Service -DDoS).
Trong thời gian vừa qua, với sự phát triển và ứng dụng rộng rãi công nghệ thông tin
và truyền thông, đặc biệt là trong giai đoạn bùng nổ công nghệ 4.0, ngành công nghệ
thông tin và truyền thông đã mang lại nhiều lợi ích to lớn cho cơ quan, tổ chức trong
các lĩnh vực chính trị, kinh tế, xã hội. Tuy nhiên, bên cạnh những lợi ích to lớn ngành
công nghệ thông tin và truyền thông mang lại thì việc này cũng kéo theo các nguy cơ
mất an toàn thông tin mà các cơ quan, tổ chức phải đối mặt. Một trong những nguy
cơ đó là các cuộc tấn công mạng, đặc biệt là tấn các cuộc tấn công DDoS. Ảnh hưởng
của một cuộc tấn công DDoS quy mô lớn có thể làm dừng hoạt động của hạ tầng
mạng của một quốc gia, gây gián đoạn công tác chỉ đạo điều hành của Chính phủ,
ngừng hoạt động của các hạ tầng trọng yếu (điện, nước, giao thông, tài chính…) làm
ảnh hưởng nghiêm trọng đến trật tự an toàn xã hội, lợi ích công cộng, quốc phòng, an
ninh.
Từ đó, chúng ta có thể thấy rằng việc đưa ra các phương pháp phòng chống tấn công
DDoS hiệu quả nhằm bảo đảm an toàn thông tin cho cơ quan, tổ chức trước các cuộc
tấn công mạng là vấn đề quan trọng và cấp bách.
Nguyên nhân dẫn tới những cuộc tấn công DDoS ngày càng trở nên nguy hiểm là
việc số lượng các thiết bị đầu cuối, IoT kết nối mạng ngày càng nhiều trong thời kỳ
công nghệ 4.0. Những điểm yếu an toàn ở các thiết bị này cho phép tin tặc có thể
chiếm quyền điều khiển và huy động nó trở thành thành viên của mạng máy tính ma
(botnet). Bằng cách này, tin tặc có thể xây dựng một mạng lưới botnet, tập hợp các
máy tay sai, với kích thước lớn, từ đó phát động tấn công DDoS hết sức nguy hiểm.
Trên thực tế đã có nhiều công trình nghiên cứu liên quan đến phát hiện và phòng
chống dạng tấn công DDoS, nhưng thực tế đều cho thấy dạng tấn công này vẫn hiệu

NCS tập trung vào hai dạng tấn công này là vì đây là những dạng tấn công đang xảy
ra phổ biến và được coi là thực sự nguy hiểm.
Các phương pháp phát hiện và phòng chống hai dạng tấn công TCP Syn Flood và
Web App-DDoS được đề xuất ở trên là các phương pháp được triển khai ở phía gần
máy chủ bị tấn công. Lý do đề xuất là vì: Đối tượng bị tấn công DDoS của tin tặc có
thể là hạ tầng mạng hoặc máy chủ. Trường hợp, đối tượng bị tấn công DDoS là hạ
tầng mạng, thì tin tặc có thể sử dụng hình thức tấn công Volumetric (hình thức tấn
công làm cạn kiệt băng thông kết nối Internet của đối tượng cần bảo vệ với các ISP).
Đối với dạng tấn công này, thì phương pháp chặn lọc hiệu quả chỉ có thể thực hiện ở
hệ thống của các ISP. Thêm nữa, để thực hiện hình thức tấn công Volumetric hiệu
quả, tin tặc cũng phải sử dụng nguồn tài nguyên rất lớn (cần một mạng botnet đủ lớn)
để thực hiện tấn công. Trường hợp, đối tượng bị tấn công DDoS là máy chủ, thì tin
tặc có thể sử dụng hình thức tấn công DDoS dạng làm cạn kiệt tài nguyên trên máy
chủ.
Trên thực tế, đối tượng tấn công là máy chủ xảy ra thường xuyên và phổ biến hơn,
bởi vì các máy chủ là lộ mặt trực tiếp ngoài Internet nên đối tượng tấn công dễ xác
định hơn và tin tặc cũng không cần tài nguyên quá lớn mà vẫn có thể làm đối bị tấn
công rơi vào trạng thái từ chối dịch vụ.
Khi đối tượng tấn công là máy chủ thì phương pháp phòng chống được triển khai
phía gần đích là phù hợp và hiệu quả hơn. Khi đó, nếu phương pháp chặn lọc hiệu
quả, băng thông kết nối Internet vẫn còn thì máy chủ vẫn có thể cung cấp dịch vụ mà
không bị rơi vào trạng thái từ chối dịch vụ.
Tin tặc thường sử dụng hai dạng tấn công TCP Syn Flood và Web App-DDoS để tấn
công các Server. Hai dạng tấn công này thường được thực hiện trên cơ sở khai thác
điểm yếu của giao thức hay nguyên lý hoạt động của giao thức mà máy chủ sử dụng.
Về phương pháp nghiên cứu, NCS kết hợp giữa lý thuyết, kinh nghiệm và những
quan sát thực tế để tìm ra các vấn đề cần phải giải quyết. Trên cơ sở đó, NCS đề xuất
phương pháp phù hợp để giải quyết các vấn đề đặt ra.

2

các gói tin IP khi được gửi ra từ cùng một máy tính. Dựa vào kinh nghiệm chuyên
môn và quan sát thực tế, NCS quan sát thấy rằng các gói tin được gửi ra ngoài từ một
máy tính thì có giá trị trường Identification (PID) tăng liên tục cách nhau một đơn vị
(sở cứ cho phát hiện này, được luận án trình bày chi tiết ở các phần sau). Tuy nhiên,
việc phát hiện các gói tin có giá PID tăng liên tiếp ở phía máy chủ bị tấn công không
hề đơn giản. Bởi vì, mỗi máy tính khi tham gia tấn công DDoS đều chạy song song
nhiều ứng dụng với các kết nối mạng khác nhau, có nghĩa là các gói tin gửi ra khỏi
máy tính sẽ đi nhiều hướng khác nhau mà không phải chỉ mỗi hướng đến máy chủ bị
tấn công. Do đó, từ phía máy chủ bị tấn công, chúng ta chỉ thu được các gói tin có giá
trị PID tăng liên tục, ngắt quãng.
Bên cạnh đó, khi tấn công TCP Syn Flood xảy ra thì ở phía máy chủ sẽ nhận được số
lượng rất lớn các gói tin SYN. Do đó, việc xử lý các gói tin SYN này như thế nào thật
nhanh, để máy chủ giảm thiểu thời gian rơi vào trạng thái từ chối dịch vụ, cũng là
một vấn đề lớn khác đặt ra đối với các phương pháp mà chúng tôi đề xuất.
Để giải quyết hai vấn đề đặt ra đối với bài toán thứ nhất, NCS đề đề xuất 02 giải pháp
[108, 110] trên cơ sở giả thuyết là trường thông tin PID của các gói tin không bị giả
mạo. Giải pháp thứ nhất [108], NCS sử dụng thuật toán DBSCAN để nhóm các gói
3


tin SYN có giá trị PID tăng liên tiếp vào từng nhóm. Trong mỗi nhóm đó, chúng tôi
xác định một giá trị PID của gói tin giả mạo tiếp theo sẽ gửi đến hệ thống.
Điểm hạn chế của giải pháp sử dụng thuật toán DBSCAN là phải cần một khoảng
thời gian ban đầu nhất định cho việc thu thập các gói tin SYN đầu tiên, làm thông tin
đầu vào cho thuật toán DBSCAN để xác định dấu hiệu của các gói tin giả mạo tiếp
theo gửi đến. Trong thời gian này, máy chủ bị tấn công vẫn phải hứng chịu các gói tin
tấn công gửi đến. Thêm nữa, phương pháp này cũng yêu cầu phải cập nhật liên tục
trạng thái các nhóm của thuật toán DBSCAN khi có gói tin hay nhóm mới được tạo
ra. Điều này làm ảnh hưởng lớn đến tốc độ xử lý chung của cả phương pháp.
Để giải quyết các hạn chế của phương pháp thứ nhất, NCS đề xuất giải pháp thứ hai

Cluster.
Bài toán thứ hai mà NCS phải giải quyết là phát hiện và phòng chống tấn công Web
App-DDoS. Trong thực tế, tin tặc cũng có thể sử dụng tấn công TCP Syn Flood để
tấn công ứng dụng Web. Tuy nhiên, tin tặc thường sử dụng tấn DDoS ở lớp ứng dụng
để thực hiện tấn công Web App-DDoS với mức độ tinh vi và nguy hiểm hơn dạng tấn
4


công TCP Syn Flood. Thêm nữa, việc phát hiện và phòng chống tấn công Web AppDDoS có những đặc trưng và thách thức riêng.
Để giải quyết bài toán thứ hai, NCS đề xuất phương pháp phát hiện nhanh các nguồn
gửi yêu cầu tấn công Web App-DDoS ngay khi tấn công xảy ra trong nghiên cứu
[111]. Đề xuất này cũng đưa ra một mô hình mở cho phép kết hợp, bổ sung nhiều tiêu
chí khác nhau để phát hiện và xác định nguồn gửi yêu cầu tấn công. Trong đó, có tiêu
chí cho phép phát hiện ngay ra các nguồn gửi yêu cầu tấn công mà không phải trải
qua quá trình máy học/huấn luyện như các phương pháp khác.
Trong nghiên cứu [111], NCS sử dụng 02 tiêu chí (tiêu chí về tần suất truy cập và
tiêu chí về tương quan giữa các yêu cầu gửi đến máy chủ) để xác định các nguồn gửi
yêu cầu tấn công. Tuy nhiên, trong nghiên cứu này, các tiêu chí NCS đưa ra và thực
hiện ở mức độ rất cơ bản để đánh giá mô hình và phương pháp đề xuất.
Trong quá trình hoàn thiện luận án và sau khi luận án được Hội đồng đánh giá cấp cơ
sở thông qua, NCS tiếp tục đi sâu nghiên cứu, đề xuất giải pháp cụ thể hơn cho 02
tiêu chí chúng tôi đã sử dụng trong nghiên cứu [111]. Cụ thể:
Đối với tiêu chí về tần suất truy nhập, NCS đề xuất giải pháp cho phép tìm ra tần suất
truy cập từ các IP nguồn gửi yêu cầu theo thời gian thực. Giải pháp đề xuất cần rất ít
tài nguyên để lưu trữ và xử lý. Tần suất xác định được sẽ là dữ liệu đầu vào cho thuật
toán của tiêu chí về tần suất. Bên cạnh đó, trong nghiên cứu này NCS cũng đề xuất
một giải pháp mới để xác định các nguồn gửi yêu cầu tấn công thay cho phương pháp
sử dụng DBSCAN trong nghiên cứu [111]. Kết quả nghiên cứu được chúng tôi gửi
đăng tại Hội nghị IEEE RIVF 2019.
Đối với tiêu chí về mối quan hệ tương quan giữa các yêu cầu gửi đến máy chủ từ một

công DDoS.
Ý nghĩa thực tiễn:
Kết quả nghiên cứu của luận án cũng đã đóng góp vào hai đề tài nghiên cứu khoa
học: (1) Đề tài nghiên cứu khoa học cấp Bộ, mã số B2016-BKA-06 về “Xây dựng hệ
thống xử lý tấn công từ chối dịch vụ và mạng botnet”; (2) Đề tài nghiên cứu khoa học
cấp quốc gia mã số KC.01.05/16-20 về “Nghiên cứu, phát triển hệ thống phân tích vết
truy cập dịch vụ cho phép phát hiện, cảnh báo hành vi bất thường và nguy cơ mất an
toàn thông tin trong Chính phủ điện tử”.
Xây dựng được một hệ thống phòng chống tấn công DDoS thực sự và đang được
triển khai thử nghiệm tại trường Đại học Bách Khoa Hà Nội.
Xây dựng được một mạng botnet trên môi trưởng ảo hóa cho phép thực hiện nhiều
hình thức tấn công DDoS khác nhau để tạo ra các dữ liệu kiểm thử cho các nghiên
cứu khác nhau..
5. Điểm mới của Luận án
- Đề xuất phương pháp mới trong việc phát hiện và loại bỏ các gói tin giả mạo trong
tấn công TCP SYN Flood (tấn công tràn ngập gói tin TCP SYN).
- Đề xuất mô hình khung phòng chống tấn công DDoS-Web , có tính mở, cho phép
kết hợp nhiều tiêu chí phát hiện để làm tăng hiệu quả, mức độ chính xác trong việc
phát hiện và phòng chống tấn công.
- Xây dựng 02 tiêu chí phát hiện nhanh cho phép loại bỏ tức thời các nguồn gửi yêu
cầu khả nghi tấn công và xác minh các nguồn gửi yêu cầu bình thường trong tấn công
DDoS-Web. Các thuật toán đề xuất trên cơ sở sử dụng các tiêu chí này cho phép sử
dụng tức thời vào chống tấn công (không cần thời gian chuẩn bị, huấn luyện dữ liệu),
xử lý lọc bỏ nhanh và cần ít tài nguyên lưu trữ.
- Xây dựng hệ thống mô phỏng và dữ liệu phục vụ kiểm thử cho hai dạng tấn công có
đặc trưng riêng là TCP SYN Flood và tấn công DDoS-Web trên môi trường ảo hóa.
CHƯƠNG I. TỔNG QUAN VỀ TẤN CÔNG DDOS VÀ PHƯƠNG PHÁP
PHÒNG CHỐNG
Trong chương 1, luận án đưa ra các nội dung tổng quan về tấn công và phòng chống
tấn công DDoS. Nội dung nghiên cứu trong chương này là cơ sở cho nghiên cứu, đề

Để có cơ sở đánh giá thực nghiệm, tôi cũng khảo sát kinh nghiệm của các tác giả có
các công trình nghiên cứu liên quan để từ đó đề xuất mô hình và phương pháp đánh
giá hiệu quả của các phương pháp do tôi đề xuất.
CHƯƠNG II. PHÓNG CHỐNG TẤN CÔNG TCP SYN FLOOD
Trong chương 2, luận án đã đưa ra những nội dung nghiên cứu chính như sau:
2.1. Giới thiệu bài toán
2.1.1. Tổng quan về nội dung nghiên cứu trong chương 2
Trong chương này, tôi đi sâu vào giải quyết bài toán thứ nhất đặt ra là phát hiện và
phòng chống tấn công TCP Syn Flood. Dạng tấn công này là một trong những dạng
tấn công phổ biến và khó phòng chống nhất ở lớp mạng. Bởi vì, với dạng tấn công
này, tin tặc thường giả mạo ngẫu nhiên địa chỉ IP nguồn, trong khi các trường thông
tin khác của gói tin hoàn toàn như các gói tin bình thường làm máy chủ bị tấn công
không có cách nào phát hiện gói tin giả mạo nếu xử lý riêng rẽ từng gói tin.
Mục tiêu của các phương pháp đề xuất là làm tăng cường tối đa khả năng phòng
chống và chịu đựng tấn công TCP Syn Flood và giảm thiểu khả năng rơi vào trạng
thái từ chối dịch vụ của hệ thống cần bảo vệ. Do đó, vấn đề mà các phương pháp cần
phải giải quyết ngoài việc tìm ra các gói tin giả mạo thì còn phải có cơ chế xử lý loại
bỏ thật nhanh các gói tin giả mạo này.
Phương pháp mà tôi đề xuất xuất phát từ việc đi tìm các mối liên hệ giữa các gói tin
IP khi chúng được gửi đi từ cùng một máy tính.
Tuy nhiên việc khai thác tính chất tăng liên tiếp của trường PID để phát hiện dòng
thác SYN tấn công không hề đơn giản: ta sẽ không hề thấy có dãy PID tăng liên tục
này khi quan sát ở máy nạn nhân (máy bị tấn công).
Nguyên do là vì: mỗi máy tính tham gia tấn công thường là một máy tay sai (của một
botnet nào đó) đều phải tham gia nhiều hoạt động giao dịch mạng khác nhau, có thể
7


mở nhiều liên kết TCP đồng thời thông qua nhiều tiến trình song song, trong đó chỉ
có 1 là với máy chủ nạn nhân. Cơ chế phát sinh PID sẽ hoạt động dạng round robin

IP nguồn được tôi đề xuất trong nghiên cứu [109]. Trong đề xuất này, tôi đưa ra
phương pháp pháp hiện khi nào tấn công xảy ra và cơ chế xác thực các IP sạch để cho
phép kết nối nhanh vào hệ thống khi tấn công xảy ra.
Để có cơ sở đánh giá hiệu quả phương pháp đề xuất và so sánh với các phương pháp
khác, tôi cũng đã xây dựng một hệ môi trường thực nghiệm và tạo ra dữ liệu kiểm thử
tương tự như các tác giả khác đã thực hiện đối với các đề xuất của họ.
2.1.2. Phạm vi của bài toán
Phương pháp chung của các giải pháp phòng chống tấn công TCP Syn Flood tôi đề
xuất dựa trên giả định rằng: Mặc dù tin tặc thực hiện tấn công TCP Syn Flood có khả
năng cao là sinh giả mạo địa chỉ IP nguồn và (có thể các trường thông tin khác) để
che giấu nguồn gốc, nhưng trường PID của gói tin IP là giá trị được phát sinh tự
động tăng liên tục mặc định theo nguyên lý chung của các hệ điều hành. Nói cách
khác phương pháp đề xuất dựa trên giả định là hầu hết các máy tấn công là máy tay
8


sai (cũng là một dạng nạn nhân “ngây thơ” bị khai thác) và vẫn có các tầng thấp của
hệ điều hành là sạch (có thể có bị lây nhiễm mã độc nhưng chỉ ở các tầng cao hơn)
Tất nhiên thay đổi giả mạo trường thông tin PID có thể thực hiện được, nếu tin tặc có
thể chiếm được quyền cao nhất của máy tính nạn nhân (và do đó can thiệp sâu các
tầng bên dưới của hệ điều hành). Tuy nhiên, để có thể xây dựng một đội quân tay sai
cỡ lớn đều có thể can thiệp giả mạo PID thì tin tặc phải có khả năng chiếm quyền
điều khiển của cả đội quân đông đảo máy tính tay sai này. Việc này là rất khó thực
hiện khi các hãng cung cấp sản phẩm luôn cập nhật bản vá lỗ hổng và phần mềm
phòng chống mã độc ngày càng tinh vi, hiệu quả hơn.
Cũng cần nói thêm, việc giả mạo địa chỉ IP nguồn thì dễ dàng thực hiện hơn nhiều,
bởi vì bản thân giao thức IP cũng cho phép thay đổi IP nguồn hoặc đích khi gói tin đi
từ nguồn đến đích. Trường hợp điển hình là các gói tin đi từ mạng Private ra ngoài
Internet thì phải chuyển đổi địa chỉ IP nguồn thành địa chỉ Public thông qua giao thức
NAT. Việc thay đổi IP nguồn cũng dễ dàng thực hiện bởi các ngôn ngữ lập trình như

mạo khi quan sát riêng rẽ từng gói tin.
9


Tin tặc thực hiện tấn công TCP Syn Flood thông qua việc khai thác điểm yếu của
giao thức giao vận TCP trong quá trình bắt tay ba bước (3-way handshake subprotocol).
Các gói tin giả mạo được tạo ra với các trường thông tin giống như của gói tin thông
thường, nhưng với địa chỉ IP nguồn giả mạo (sinh ngẫu nhiên). Nếu không có cơ chế
theo dõi đặc biệt, máy chủ không thể phân biệt được gói tin nào là gói tin thực hay
giả mạo
2.3. Mô hình phương pháp phát hiện và phòng chống tấn công TCP Syn Flood
2.3.1. Mô hình tổng thể và các thành phần cơ bản
Hệ thống phát hiện và phòng chống tấn công TCP Syn Flood, tôi thiết kế thành phần
TCP Syn Flood Defence bao gồm 04 chức năng chính:
▪ Chức năng xây dựng danh sách các địa chỉ IP sạch IP white-list;
▪ Chức năng phát hiện tấn công TCP Syn Flood;
▪ Chức năng phát hiện và loại bỏ gói tin giả mạo;
▪ Chức năng xác thực địa chỉ IP nguồn

Black list
White list

Black-List

White-List
`

Tab

User

kết nối vào hệ thống thông qua cơ chế xác minh địa chỉ IP nguồn. Khi đó, hệ thống
DDoS-Defence sẽ đại diện máy chủ đang bị tấn công, gửi gói tin SYN, ACK về IP
nguồn để xác minh. Nếu hệ thống DDoS-Defence nhận được gói tin ACK từ IP
nguồn đó thì IP đó sẽ được đưa vào danh sách IP white-list (chi tiết tại mục 2.5.4).
10


Khi phát hiện tấn công DDoS xảy ra (tần suất gửi các gói tin TCP Reset vượt quá
ngưỡng) thì chức năng phát hiện và loại bỏ gói tin giả mạo sẽ được kích hoạt để chặn
các gói tin tấn công gửi đến hệ thống cần bảo vệ.
2.4. Phát hiện tấn công TCP Syn Flood
Việc phát hiện sớm cuộc tấn công DDoS Syn Flood là rất quan trọng trong việc xử lý
và giảm thiểu ảnh hưởng của cuộc tấn công đối với hệ thống. Đối với các phương
pháp sử dụng threshold để phát hiện tấn công DDoS thường gây ra các cảnh báo sai
hoặc không phát hiện ra. Điểm hạn chế của phương pháp sử dụng threshold là tin tặc
có thể thay đổi lưu lượng tấn công về số lượng, tần suất để tránh khỏi sự phát hiện
của hệ thống, do không có cơ chế thay đổi giá trị threshold một cách tự động phù hợp
để mô tả hoạt động thực tế của hệ thống mạng được bảo vệ khi có sự thay đổi. Do đó,
trong nghiên cứu này, tôi đề xuất một phương pháp cho phép theo dõi và tự động cập
nhật giá trị threshold khi số lượng và tần suất truy nhập trên hệ thống thay đổi.
Cơ chế của phương pháp đề xuất là định kỳ theo dõi tần số xuất hiện các gói tin TCP
có cờ (flag) được thiết lập là Reset. Lý do theo dõi các gói tin TCP có flag là Reset là
vì theo nguyên lý hoạt động của giao thức TCP, khi máy chủ nhận được gói tin SYN
giả mạo thì máy chủ sẽ gửi trả lại gói tin ACK tới địa chỉ IP của máy thực (máy bị giả
mạo địa chỉ IP). Khi máy thực nhận được gói tin ACK của máy chủ thì sẽ gửi gói tin
TCP Reset tới máy chủ để hủy kết nối. Đây là điểm khác biệt giữa kết nối mạng
thông thường với kết nối mạng sử dụng trong tấn công DDoS Syn Flood.
User

User


89.6%

84.2%

78.2%

outside.tcpdump

88.6%

82.1%

77.3%

dhbkdata.pcap
90.6%
89.5%
87.5%
Tôi kiểm chứng tỷ lệ các gói tin có ít nhất 02 giá trị tăng liên tục (2-PID); Tỷ lệ các
gói tin có ít nhất 03 giá trị tăng liên tục (3-PID); Tỷ lệ các gói tin có ít nhất 04 giá trị
tăng liên tục (4-PID). Kết quả như sau:
2.5.3. Phương pháp phát hiện và loại bỏ các gói tin giả mạo PIDAD1
Quá trình thiết lập thông tin đầu vào được thực hiện tại thời điểm hệ thống DDoSDefence bắt đầu phát hiện tấn công DDoS. Khi đó, trong khoảng thời gian rất ngắn
phương pháp PIDAD1 thực hiện lấy mẫu các gói tin tấn công đầu tiên tới hệ thống để
thiết lập các tham số của thuật toán DBSCAN. Phương pháp PIDAD1 chỉ tập trung
vào việc phát hiện và loại bỏ các gói tin giả mạo gửi đến hệ thống. Việc phát hiện khi
nào xảy ra tấn công DDoS dạng TCP Syn Flood, luận án trình bày ở trên. Quá trình
thiết lập thông tin đầu vào được thực hiện như sau:
Khi hệ thống phát hiện có tấn công DDoS xảy ra, phương pháp PIDAD1 sẽ thu thập

Permit
5
Negative

Found

New
Packet

1

I0

2
Not Found

I1

Not Found

3

PID-Filter
Positive

4

Deny

Có thể có những IP giả mạo (tạo ngẫu nhiên) trùng khớp với một địa chỉ IP sạch

chuyển khỏi bảng I1 và đưa vào bảng I0.
2.5.5. Phương pháp xác thực địa chỉ IP nguồn
2.6. Đánh giá thực nghiệm
ISP01

ISP01

ISP01

ISP01

ISP01

C&C Server

ISP01

Router
Core 2

Core
Internet

Router
Core 1

Router
Core 3

Web Server

103.192.237.100
80
Enable/disable
Với cấu trúc lệnh trên, Các máy Client sẽ thực hiện tấn công dạng TCP Syn Flood
với địa chỉ IP nguồn giả mạo ngẫu nhiên và địa chỉ máy 103.192.237.100 với cổng
dịch vụ là 80.
Để có dữ liệu kiểm thử, tôi thực hiện tấn công giả lập vào máy chủ trong khoảng thời
gian 03 phút. Tại Web Server, tôi thực hiện lấy mẫu các gói tin SYN gửi đến máy chủ
sử dụng công cụ Tcpdump với câu lệnh: tcpdump -i ens32 tcp port 80 and
14


"tcp[tcpflags] & (tcp-syn|tcp-ack)! = 0" -n -p and ip dst 103.192.237.100 -w
synflood-attack.pcap.
Kết quả tại Web Server, tôi thu được 145.377 gói tin Syn và được lưu trong tệp tin
synflood-attack.pcap [115]. Để có cơ sở đánh giá thực nghiệm, các gói tin SYN được
phân làm hai nhóm, nhóm các gói tin tấn công và nhóm các gói tin bình thường.
Nhóm các gói tin bình thường là nhóm các gói tin có địa chỉ IP nguồn là các địa chỉ
IP của các máy Client, nằm trong dải địa chỉ 103.192.237.0/24. Các gói tin này được
sinh ra khi các máy Client truy cập trang Web trên Web Server. Nhóm các gói tin tấn
công là các gói tin có địa chỉ IP không nằm trong dải địa chỉ ở trên và có giá trị ngẫu
nhiên.
2.6.2. Đánh giá thực nghiệm cho phương pháp PIDAD1 và PIDAD2
100

200
150
Time(s) 100
50
0

Số lượng gói tin nhận được

PIDAD2

Số lượng gói tin nhận được

2.6.3. So sánh hiệu quả của phương pháp PIDAD2 với phương pháp khác
100

1

DR(%) 50

FP(%) 0.5
C4.5

C4.5

0

24229
48459
72688
96918
121147
145377

24229
48459
72688



Để giải quyết bài toán thứ hai, tôi đề xuất phương pháp phát hiện nhanh các nguồn
gửi yêu cầu tấn công Web App-DDoS ngay khi tấn công xảy ra trong nghiên cứu
[111]. Đề xuất này cũng đưa ra một mô hình mở cho phép kết hợp, bổ sung nhiều tiêu
chí khác nhau để phát hiện và xác định nguồn gửi yêu cầu tấn công. Trong đó, có tiêu
chí cho phép phát hiện ngay ra các nguồn gửi yêu cầu tấn công mà không phải trải
qua quá trình máy học/huấn luyện như các phương pháp khác. Kết quả nghiên cứu đã
được tôi công bố tại Hội nghị SoICT năm 2017.
Sau khi luận án được Hội đồng đánh giá cấp cơ sở thông qua, tôi tiếp tục nghiên cứu,
đề xuất phương pháp, thuật toán cụ thể hơn cho 02 tiêu chí tôi đã sử dụng trong
nghiên cứu [111]. Cụ thể: Đối với tiêu chí về tần suất truy nhập, tôi đề xuất giải pháp
cho phép tìm ra tần suất truy cập từ các IP nguồn gửi yêu cầu theo thời gian thực.
Giải pháp đề xuất cần rất ít tài nguyên để lưu trữ và xử lý. Tần suất xác định được sẽ
là dữ liệu đầu vào cho thuật toán của tiêu chí về tần suất. Bên cạnh đó, trong nghiên
cứu này tôi cũng đề xuất một giải pháp mới để xác định các nguồn gửi yêu cầu tấn
công thay cho giải pháp sử dụng DBSCAN trong nghiên cứu [111]. Tôi trình bày cụ
thể tiêu chí này tại mục 3.5.4.1. Kết quả nghiên cứu được tôi gửi đăng tại Hội nghị
IEEE RIVF 2019.
Đối với tiêu chí về mối quan hệ tương quan giữa các yêu cầu gửi đến máy chủ từ một
nguồn, tôi đưa ra giải pháp để thiết lập tập các yêu cầu tương quan trong quá trình
huấn luyện (training). Tập các yêu cầu tương quan được thiết lập dựa trên các điều
kiện để bảo đảm rằng tập các yêu cầu này là sạch và tin tặc rất khó để có thể đưa các
yêu cầu sai lệch vào tập dữ liệu này trong quá trình huấn luyện. Kết quả nghiên cứu
được tôi chuẩn bị gửi đăng tại Tạp chí Khoa học và Công nghệ.
Tôi cũng đề xuất phương pháp phát hiện tấn công Web App-DDoS là một quá trình
độc lập với quá trình xử lý tấn công, cho phép tối ưu và tăng tốc độ xử lý của toàn bộ
giải pháp phòng chống tấn công DDoS đề xuất.
Trong chương này, luận án tập trung trình bày các nội dung chính như sau:
▪ Tổng quan về tấn công Web App-DDoS và phương pháp phòng chống.

băng thông lớn như hình thức tấn công DDoS Volumetric.
Tấn công Web App-DDoS có thể thực hiện bằng nhiều hình thức tinh vi khác nhau để
vượt qua các hệ thống phòng thủ như:
▪ Session flooding attacks - dạng tấn công này, tin tặc gửi số lượng lớn phiên kết
nối tới Server;
▪ Request flooding attacks - dạng tấn công này, tin tặc gửi số lượng lớn các yêu
cầu trong một phiên kết nối tới Server;
▪ Asymmetric attacks - dạng tấn công này, tin tặc gửi phiên kết nối trong đó có
các yêu cầu làm máy chủ tiêu tốn nhiều tài nguyên để xử lý;
▪ Slow request/response attacks - tương tự dạng tấn công Asymmetric attacks,
tin tặc gửi phiên kết nối trong đó có các yêu cầu làm máy chủ tiêu tốn nhiều tài
nguyên để xử lý.
Khi tin tặc sử dụng các yêu cầu có thực để thực hiện tấn công Web App-DDoS, từ
phía máy chủ rất khó để phân biệt yêu cầu nào là yêu cầu được gửi đi từ máy bình
thường. Đặc biệt, khi tấn công DDoS xảy ra, số lượng yêu cầu gửi đến máy chủ là rất
lớn, làm máy chủ càng khó khăn hơn trong việc phát hiện các yêu cầu gửi đi từ mạng
botnet.
Ứng dụng Web là ứng dụng có đặc trưng là dữ liệu cho mỗi ứng dụng Web thay đổi
thường xuyên. Tần suất truy nhập ứng dụng Web phụ thuộc vào nội dung mà ứng
dụng đó cung cấp. Khi có nội dung mới, được sự quan tâm của nhiều người sử dụng,
tần suất truy cập ứng dụng Web tăng đột biến, giống như bị tấn công. Đây cũng là
vấn đề cần giải quyết để có thể phân biệt trường hợp này với một cuộc tấn công thực
sự.
Những điểm yếu an toàn thông tin các hệ điều hành, ứng dụng và các thiết bị IoT
xuất hiện ngày càng nhiều, điều này dẫn tới việc lợi dụng các điểm yếu này để khai
thác chiếm quyền điều khiển và phát tán mã độc trở nên dễ dàng hơn cho tin tặc. Từ
đó, tin tặc có thể xây dựng mạng botnet lớn và có thể thực hiện nhiều hình thức tấn
công DDoS tinh vi khác nhau.
3.3. Mô hình, phương pháp phòng chống tấn công Web App-DDoS
3.3.1. Mô hình tổng thể và các thành phần cơ bản

Requests

Update

Update

DDoS
Detection

DDoS
Prevention

Update

Black List

Lý do tôi phân tách chức năng phát hiện và phòng chống thành hai chức năng độc lập
khác với các nghiên cứu liên quan đến phòng chống tấn công Web App-DdoS trong
mục 3.2.3 là vì: Quá trình phát hiện tấn công và phòng chống tấn công khi thực hiện
độc lập sẽ tối ưu về hiệu năng và hiệu quả hơn. Tài nguyên hệ thống dành cho chức
năng DDoS Detection sẽ ít hơn tài nguyên hệ thống dành cho chức năng DDoS
Prevention. Do đó, chức năng DDoS Detection có thể thực hiện liên tục để kiểm tra
máy chủ có bị tấn công hay không và chức năng DDoS Prevention chỉ được kích hoạt
khi chức năng phát hiện phát hiện tấn công.
Thêm nữa, việc xây dựng chức năng DDoS Detection và DDoS Prevention độc lập
cho phép xây dựng các giải pháp/thuật toán riêng biệt cho từng chức năng giúp hiệu
quả phát hiện và phòng chống tấn công DDoS.
Trên cơ sở đó, thành phần Web App-DDoS Defence được xây dựng dựa trên hai thức
năng DDoS Detection và DDoS Prevention độc lập, có nguyên lý hoạt động như sau:
Khi hệ thống hoạt động ở trạng thái bình thường, hệ thống DDoS-Defence sẽ theo dõi


Update

Attack
Status

Loop Delay

Để phát hiện tấn công Web App-DDoS, định kỳ sau mỗi khoảng thời gian ∆t (được
thiết lập trước), dữ liệu trong CSDL (dữ liệu được lưu trong CSDL có cấu trúc được
mô tả trong hình 24) có thời gian trong khoảng ∆t tính từ thời điểm lấy dữ liệu sẽ
được lấy ra để kiểm tra xem máy chủ có bị tấn công hay không. Dữ liệu này được sử
dụng làm thông tin đầu vào cho các tiêu chí phát hiện tấn công. Nếu dữ liệu đầu vào
thỏa mãn một trong các tiêu chí thì máy chủ được cho là tấn công.
3.5. Phòng chống tấn công Web App-DDoS sử dụng phương pháp FDDA
3.5.1. Ý tưởng cơ bản của phương pháp FDDA
Ý tưởng cơ bản của phương pháp FDDA là khi tấn công xảy ra, thì các yêu cầu gửi
đến máy chủ sẽ bao gồm cả các yêu cầu tấn công và các yêu cầu bình thường. Trong
đó các yêu cầu tấn công chiếm phần lớn. Do đó, vấn đề mà phương pháp FDDA phải
xử lý là tìm ra các nguồn gửi tấn công để đưa vào Black-List và nguồn gửi bình
thường để đưa vào White-List.
Để phân biệt các yêu cầu tấn công và yêu cầu của người sử dụng bình thường, tôi sử
dụng một tập các tiêu chí để loại bỏ ngay các nguồn gửi yêu tần tấn công có tần suất
cao và xác minh nguồn gửi yêu cầu bình thường để cho phép kết nối vào hệ thống. Ý
tưởng cơ bản của phương pháp FDDA được mô tả như hình dưới đây:
Filter & Check

Coming
Requests


chưa xảy ra tấn công, tôi tìm cách xây dựng một tập dữ liệu tương quan (được bày cụ
thể trong phần 3.5.5) cho phép xác định các nguồn gửi yêu cầu tấn công và yêu cầu
bình thường đối với những nguồn gửi yêu cầu không xác định được bởi tiêu chí tần
suất.
3.5.4. Tiêu chí về tần suất truy cập
Ý tưởng cơ bản để xây dựng tiêu chí này là tôi quan sát trường hợp các máy tính tấn
công được điều khiển thông qua máy chủ C&C để thực hiện tấn công thì tần suất cao
và sự đồng đều nhất định, bởi vì chúng cùng nhận lệnh điều khiển giống nhau từ máy
chủ C&C. Trong khi các máy tính bình thường thì tần suất gửi của nó không đồng
đều với các máy tính còn lại. Ví dụ như hình dưới đây:

Vấn đề đặt ra trong việc xây dựng tiêu chí này là làm thế nào để xác định tần suất gửi
yêu cầu theo thời gian thực của các srcIP khi số lượng các yêu cầu gửi đến hệ thống
rất lớn khi tấn công xảy ra.
Để giải quyết vấn đề này, tôi đề xuất giải pháp cho phép xác định tần suất truy cập
của các srcIP theo thời gian thực mà cần ít không gian lưu trữ và thời gian xử lý. Đề
xuất này là một trong những đóng góp chính của tôi trong phương pháp tổng thể
FDDA.
3.5.5. Xây dựng tiêu chí tương quan trong phương pháp FDDA
Tiêu chí về tương quan SAT2 được xây dựng dựa trên ý tưởng cơ bản là với người
dùng bình thường khi truy cập ứng dụng Web thì họ sẽ truy cập các nội dung khác
nhau trên máy chủ (lướt web). Do đó, khi quan sát ở phía máy chủ, chúng ta có thể
thấy được mối quan hệ tương quan của các yêu cầu gửi tới máy chủ từ mỗi IP nguồn.
Ví dụ khi người dùng gửi yêu cầu rA đến máy chủ thì tiếp theo đó họ cũng gửi yêu
cầu rB đến máy chủ.
20


Vấn đề đặt ra là làm thế nào để xây dựng tập dữ liệu tương quan để đảm bảo rằng tin
tặc khó có thể cố tình đưa các yêu cầu sai lệch đến máy chủ trong quá trình hoạt động

No

3
Call SAT2 Yes
(R(k), FA)

No

Delete (S(s,i),R(i),f(i)) from DSus

Delete (S(s,i),R(i),f(i)) from DSus

2

4 Update
White-List

Black-List

Sau mỗi khoảng thời gian ∆Ts, chúng tôi kiểm tra xem với mỗi yêu cầu trong DT có
yêu cầu nào vượt ngưỡng FT hay không. Mỗi yêu cầu trong DInp gửi đến hệ thống với
tần số > FT thì sẽ được đưa vào DSus. Tập các yêu cầu khác nhau trong DSus là tập các
yêu cầu nghi ngờ tấn công cần xác minh RA.
Mỗi yêu cầu trong tập RA có thể được gửi từ nhiều IP nguồn khác nhau. Trong các IP
nguồn gửi yêu cầu có thể có IP nguồn là tấn công và IP nguồn là bình thường. Do đó,
chúng tôi phải tìm cách loại bỏ các yêu cầu là bình thường dựa vào các tiêu chí ở trên
như sau:
▪ Sử dụng tiêu chí tần suất SAT1: Xác định và loại bỏ các nguồn gửi yêu cầu lặp
lại tần suất lớn.
▪ Sử dụng tiêu chí tương quan SAT2: Xác định các nguồn gửi yêu cầu bình thường

dữ liệu được lưu trữ dưới dạng PCAP trong đó có 66.851 gói tin [112]. CSDL thu
được có cấu trúc như bảng 3.1 bao gồm 1.310 yêu cầu, trong đó có cả yêu cầu tấn
công và yêu cầu bình thường và được lưu trữ trong CSDL MySQL [113].
Để đánh dấu các nguồn gửi yêu cầu tấn công phục vụ việc đánh giá thử nghiệm, các
yêu cầu được gửi đi từ các địa chỉ IP trong mạng botnet (trong mô hình thử nghiệm
trên môi trường ảo) sẽ được đánh dấu là các nguồn gửi yêu cầu tấn công. Các IP
nguồn khác không nằm trong dải địa chỉ IP của mạng botnet sẽ được đánh dấu là
nguồn gửi yêu cầu bình thường.
3.6.2. Đánh giá thử nghiệm phương pháp FDDA
Tôi thực hiện đánh giá thực nghiệm với tập dữ liệu [112] sử dụng các tham số dưới
đây được sử dụng như sau:
▪ Ngưỡng phát hiện yêu cầu nghi ngờ tấn công FT (requests/second).
▪ Số lượng yêu cầu trong tập DSus.
▪ Số lượng yêu cầu nghi ngờ tấn công trong tập RA.
▪ Tỷ lệ phát hiện đúng các nguồn gửi tấn công: Detection Rate - DR.
▪ Tỷ lệ phát hiện nhầm các nguồn bình thường là tấn công: False Positive - FP.
Kết quả thực nghiệm cho thấy phương pháp của tôi có tỷ lệ phát hiện cao như trong
bảng dưới đây:
FT
DSus
RA
DR
FP
50
250
185 75.32% 1.28%
100
500
365 92.56% 1.11%
150


22


Kết quả so sánh về thời gian xử lý
140
120
100
80
Time(s)
60
40
20
0

KNN
NB
PIDAD2
250 500 750 10001310
Số lượng yêu cầu nhận được

Kết quả cho thấy, trên cùng tập dữ liệu kiểm thử, phương pháp FDDA có tỷ lệ phát
hiện các yêu cầu tấn công cao hơn (Detection Rate - 93.75%) và tỷ lệ phát hiện nhầm
yêu cầu bình thường là yêu cầu tấn công (False Positive - 0.89%) so với hai phương
pháp được so sánh
KẾT LUẬN VÀ ĐỀ XUẤT
1. Kết luận
Tôi thấy rằng, luận án là một công trình nghiên cứu có ý nghĩa về khoa học và thực
tiễn.
a) Về ý nghĩa khoa học:

khai thử nghiệm tại trường Đại học Bách Khoa Hà Nội.
Bên cạnh đó, tôi cũng đã xây dựng được một mạng botnet trên môi trưởng ảo hóa cho
phép thực hiện nhiều hình thức tấn công DDoS khác nhau để tạo ra các dữ liệu kiểm
thử cho các nghiên cứu khác nhau. Tôi đã tải lên trang mạng trực tuyến và địa chỉ tải
dữ liệu kiểm thử trong phần phụ lục của luận án.
2. Kiến nghị, đề xuất
Tấn công DDoS là một dạng tấn công nguy hiểm với nhiều hình thức tấn công khác
nhau mà tin tặc có thể sử dụng. Trong nghiên cứu này, tôi mới chỉ tập trung giải
quyết hai dạng tấn công DDoS phổ biến TCP Syn Flood và Web App-DDoS. Đây là
hai dạng tấn công có đặc trưng riêng nên nên việc đề xuất ra một phương pháp phòng
chống hiệu quả vẫn đang là thách thức với nhiều nhà nghiên cứu.
Do đó, tôi thấy rằng, cần tiếp tục nghiên cứu để đưa ra các phương pháp phòng chống
tối ưu và hiệu quả hơn cũng như phòng chống các dạng tấn công DDoS khác.
Tuy nhiên, trong phạm vi điều kiện về thời gian, kinh tế và công việc, tôi đã có những
đóng góp nhất định về khoa học và thực tiễn đối với những nghiên cứu của mình.
Trên cơ sở đó, tôi xin kiến nghị, đề xuất Hội đồng tạo điều kiện giúp đỡ tôi góp ý
hoàn thiện và thông qua luận án.
Xin trân thành cảm ơn!

24