Một giải pháp kỹ thuật trong việc phát hiện tấn công dos bằng phương pháp phân tích log
Bạn đang xem bản rút gọn của tài liệu. Xem và tải ngay bản đầy đủ của tài liệu tại đây (1.24 MB, 61 trang )
BỘ GIÁO DỤC VÀ ĐÀO TẠO
TRƯỜNG ĐẠI HỌC BÁCH KHOA HÀ NỘI
---------------------------------------
BÙI THANH HIỀN
MỘT GIẢI PHÁP KỸ THUẬT TRONG VIỆC PHÁT HIỆN
TẤN CÔNG DOS BẰNG PHƯƠNG PHÁP PHÂN TÍCH LOG
CHUYÊN NGÀNH: CÔNG NGHỆ THÔNG TIN
LUẬN VĂN THẠC SĨ KỸ THUẬT
CÔNG NGHỆ THÔNG TIN
NGƯỜI HƯỚNG DẪN KHOA HỌC:
TS. NGUYỄN KHANH VĂN
HÀ NỘI – NĂM 2015
MỤC LỤC
Danh mục các ký hiệu, các chữ viết tắt ..................................................................... iii
Danh mục các hình vẽ, đồ thị .................................................................................... iv
MỞ ĐẦU .....................................................................................................................1
CHƢƠNG 1 – TỔNG QUAN VỀ DOS .....................................................................3
1.
DoS là gì? ......................................................................................................3
2.
Phân loạ DoS .................................................................................................4
3.
Phát hiện và phòng chống DoS .....................................................................9
CHƢƠNG 2 – PHÁT HIỆN TẤN CÔNG DOS BẰNG PHƢƠNG PHÁP PHÂN
TÍCH LOG ................................................................................................................12
1.
Giới thiệu .....................................................................................................12
2.
Mô hình chung .............................................................................................13
3.
Lựa chọn giải pháp cho các thành phần ......................................................14
4.
Hoạt động của từng thành phần ...................................................................16
CHƢƠNG 3 – THƢ VIỆN HỖ TRỢ PHÂN TÍCH LOG VÀ THỬ NGHIỆM .......25
1.
Lý do cần có thƣ viện hỗ trợ ........................................................................25
2.
Tổng quan về thƣ viện .................................................................................25
3.
Cấu trúc của thƣ viện ...................................................................................27
4.
Thử nghiệm..................................................................................................30
5.
Đánh giá .......................................................................................................37
KẾT LUẬN ...............................................................................................................38
TÀI LIỆU THAM KHẢO .........................................................................................39
PHỤ LỤC A – CHI TIẾT THƢ VIỆN HỖ TRỢ PHÂN TÍCH LOG ......................40
PHỤ LỤC B – CÁC CẤU HÌNH VÀ SCRIPT SỬ DỤNG KHI THỬ NGHIỆM ..53
i
LỜI CAM ĐOAN
Trƣớc tiên tôi xin chân thành gửi lời cảm ơn và lòng biết ơn sâu sắc tới TS
Nguyễn Khanh Văn – Viện Công nghệ Thông tin – Truyền thông, ngƣời đã tận tình
hƣớng dẫn, chỉ bảo tôi trong suốt quá trình hoàn thiện luận văn. Đồng thời tôi cũng
xin bày tỏ lòng biết ơn các thầy cô giáo trong Viện Công nghệ Thông tin – Truyền
thông nói riêng và Đại học Bách Khoa Hà Nội nói chung đã chỉ dạy, cung cấp
những kiến thức quý báu cho tôi trong suốt quá trình học tập và nghiên cứu tại
trƣờng.
Tôi xin gửi lời cảm ơn sâu sắc tới gia đình, bạn bè, những ngƣời luôn quan
tâm và giúp đỡ tôi trong suốt thời gian học tập và hoàn thành luận văn.
Tôi cam đoan đây là công trình nghiên cứu của riêng tôi.
Các số liệu, kết quả trong luận văn là trung thực và chƣa từng đƣợc ai công bố
trong bất kỳ công trình nào khác.
ii
DANH MỤC CÁC KÝ HIỆU, CÁC CHỮ VIẾT TẮT
STT
Giải nghĩa
Từ viết tắt
1
DoS
Denial of Service: Tấn công từ chối dịch vụ
2
DDoS
Distributed Denial of Service: Tấn công từ chối
dịch vụ phân tán
3
TCP
Transmission Control Protocol: Giao thức ở tầng
Transport của bộ giao thức TCP/IP
4
UDP
User Datagram Protocol: Giao thức ở tầng
Transport của bộ giao thức TCP/IP
5
ICMP
Internet Control Message Protocol: Giao thức ở
tầng Network của bộ giao thức TCP/IP
6
IP
Internet Protocol: Giao thức ở tầng Network của
bộ giao thức TCP/IP
7
DNS
Domain Name System: Giao thức ở tầng
Application của bộ giao thức TCP/IP
8
HTTP
Hypertext Transfer Protocol: Giao thức ở tầng
Application của bộ giao thức TCP/IP
9
SYN
Synchronize: Cờ trạng thái của gói tin TCP
10
FIN
Finish: Cờ trạng thái của gói tin TCP
11
ACK
Acknowledge: Cờ trạng thái của gói tin TCP
12
JSON
JavaScript Object Notation: Định dạng trao đổi dữ
liệu
13
API
Application Programming Interface: Giao diện lập
trình ứng dụng
14
IIS
Internet Information Services: Web server của
Microsoft
15
CSDL
Cơ sở dữ liệu
iii
DANH MỤC CÁC HÌNH VẼ, ĐỒ THỊ
Hình 1. Quá trình bắt tay ba bƣớc ...............................................................................5
Hình 2. Mô hình tấn công SYN Flood ........................................................................5
Hình 3. Mô hình tấn công Smurf ................................................................................6
Hình 4. Mô hình Botnet ..............................................................................................7
Hình 5. Chi tiết một phần log của firewall ................................................................12
Hình 6. Mô hình giải pháp ........................................................................................14
Hình 7. Luồng xử lý sự kiện của Logstash ...............................................................16
Hình 8. Cấu trúc phân cấp của nhóm class LogDoc .................................................28
Hình 9. Cấu trúc phân cấp của nhóm class LogType................................................29
Hình 10. Quan hệ giữa 3 class chính của thƣ viện ....................................................29
Hình 11. Mô hình thử nghiệm ...................................................................................31
Hình 12. Danh sách các Index trong CSDL Elasticsearch ........................................32
Hình 13. Tấn công HTTP Flood sử dụng LOIC .......................................................32
Hình 14. Trạng thái của Apache khi bị tấn công HTTP Flood .................................33
Hình 15. Phát hiện tấn công HTTP Flood .................................................................34
Hình 16. Tấn công SYN Flood sử dụng hping .........................................................35
Hình 17. Phát hiện tấn công SYN Flood ...................................................................36
iv
MỞ ĐẦU
Tấn công từ chối dịch vụ (Denial of Service – DoS) đã và đang là một trong vấn
đề làm đau đầu các nhà quản trị hệ thống và các chuyên gia an ninh mạng. Nó luôn
là một trong những hình thức tấn công mạng khó chống đỡ nhất. Ngày nay, việc sở
hữu và sử dụng các botnet trở nên dễ dàng hơn đã khiến cho các cuộc tấn công từ
chối dịch vụ ngày càng phát triển và khó kiểm soát. DoS không chỉ gây thiệt hại về
kinh tế mà còn gây ra những tổn thất nghiêm trọng về uy tín, danh dự mỗi khi một
tổ chức nào đó bị tấn công. Trong những năm vừa qua, rất nhiều cơ quan, tổ chức,
các báo điện tử lớn tại Việt Nam bị tấn công DoS, gây thiệt hại rất lớn cho các tổ
chức này.
Để chống lại những cuộc tấn công DoS, rất nhiều các giải pháp kỹ thuật đã đƣợc
nghiên cứu và áp dụng trên thực tế. Hiện nay, ngoài các biện pháp nhƣ tăng năng
lực xử lý, tối ƣu hóa phần mềm, load balacing cho hệ thống,… các nhà quản trị
thƣờng lựa chọn một trong hai giải pháp chính: sử dụng thiết bị chống tấn công
DoS, hoặc sử dụng các dịch vụ chống tấn công DoS.
Đối với giải pháp thứ nhất, một thiết bị chuyên dụng sẽ đƣợc đặt trƣớc mạng cần
đƣợc bảo vệ. Thiết bị này có nhiệm vụ theo dõi lƣu lƣợng mạng, phát hiện và ngăn
chặn các gói tin tấn công vào hệ thống theo thời gian thực. Các gói tin sẽ phải đi
qua thiết bị này trƣớc khi đi vào trong hệ thống. Việc lắp đặt thiết bị gần nhƣ không
ảnh hƣởng tới hoạt động của hệ thống.
Ở giải pháp thứ hai, bằng cách sử dụng DNS, toàn bộ lƣu lƣợng mạng trƣớc đi
tới hệ thống sẽ phải qua hạ tầng mạng của nhà cung cấp dịch vụ chống tấn công. Tại
đây, các gói tin tấn công sẽ đƣợc loại bỏ, chỉ những gói tin bình thƣờng mới đƣợc
chuyển tới hệ thống đƣợc bảo vệ. Giải pháp này dựa trên năng lực đáp ứng khá lớn
của nhà cung cấp nên khả năng bảo vệ cho hệ thống sẽ cao nếu khả năng lọc, phân
biệt gói tin tốt/xấu của nhà cung cấp tốt.
1
Cả hai giải pháp trên đều có ƣu điểm là: (1) cơ chế phân tích và lọc bỏ gói tin
theo thời gian thực giúp phát hiện và ngăn chặn sớm đƣợc cuộc tấn công, (2) việc
triển khai nhanh chóng, thuận tiện và không cần hiểu biết nhiều về hệ thống cần
đƣợc bảo vệ. Tuy nhiên chúng cũng có một nhƣợc điểm là thành phần phát hiện và
ngăn chặn tấn công đôi khi lại tạo ra một nút thắt cổ chai cho toàn bộ hệ thống.
Trong khuôn khổ của luận văn này, tôi xin trình bày một hƣớng tiếp cận khác
trong việc phát hiện các cuộc tấn công DoS, đó là phát hiện tấn công dựa trên việc
phân tích log. Đối với ngƣời quản trị hệ thống, log là một trong những thành phần
rất quen thuộc trong công việc hàng ngày. Chúng lƣu trữ thông tin về hầu hết các
hoạt động diễn ra trong hệ thống. Dựa vào các thông tin đó, ta có thể trích xuất ra
dữ liệu nhằm phát hiện ra nhiều cuộc tấn công an ninh mạng vào hệ thống, trong đó
có tấn công DoS.
Nội dung chính của giải pháp sẽ đƣợc trình bày chi tiết ở chƣơng 2 và chƣơng 3
của luận văn. Trong đó, chƣơng 2 giới thiệu tổng quan về giải pháp; cách thức thu
thập và lƣu trữ dữ liệu log; cách thức phân tích log để phát hiện tấn công; cũng nhƣ
việc lựa chọn công nghệ và nguyên lý hoạt động của từng thành phần. Ngoài ra, do
việc phát triển các đoạn mã phân tích log thƣờng phức tạp và mất nhiều thời gian,
luận văn cũng đề xuất một thƣ viện hỗ trợ ngƣời phân tích nhằm đơn giản hóa toàn
bộ quá trình này, đƣợc giới thiệu chi tiết tại chƣơng 3. Chƣơng này cũng trình bày
mô hình, kịch bản thử nghiệm, kết quả thu đƣợc và đánh giá giải pháp.
2
CHƯƠNG 1 – TỔNG QUAN VỀ DOS
1. DoS là gì?
Denial of Service[8] – tấn công từ chối dịch vụ là một hình thức tấn công nhằm
ngăn chặn những ngƣời dùng hợp lệ truy cập, sử dụng những dịch vụ mạng nhƣ
website, webservice hay một hệ thống máy tính nào đó. Về bản chất, DoS không
đánh cắp thông tin hay làm mất mát dữ liệu mà chỉ làm gián đoạn hoạt động bình
thƣờng của hệ thống. Tuy nhiên, nếu một hệ thống tồn tại mà không thể cung cấp
thông tin, dịch vụ cho ngƣời sử dụng, thì sự tồn tại là vô nghĩa. Vì thế thiệt hại do
các cuộc tấn công từ chối dịch vụ gây ra là không nhỏ, đặc biệt với các hệ thống
lớn.
Lịch sử của DoS đƣợc ghi nhận vào những năm 90, bắt nguồn từ khi một số
chuyên gia bảo mật phát hiện ra một điểm yếu trên hệ điều hành Windows 98, đó là
chỉ cần gửi một gói ping với kích thƣớc lớn tới một máy tính chạy Windows 98 có
thể khiến cho máy tính đó không xử lý đƣợc và bị tê liệt. Phát hiện này ngay sau đó
đƣợc các hacker lợi dụng để tấn công vào các hệ thống. Từ đó, hình thức sơ khai
của DoS đã ra đời.
Hình thức tấn công DoS nhƣ trên dựa vào một điểm yếu trong thiết kế của hệ
thống, kẻ tấn công chỉ cần gửi một hoặc một số ít gói tin để làm tê liệt mục tiêu.
Trên thực tế, kiểu tấn công này không phổ biến bằng cách tấn công gửi một số
lƣợng lớn các gói tin tới hệ thống, làm cạn kiệt tài nguyên, băng thông, năng lực xử
lý của hệ thống. Distributed Denial of Service[8] (DDoS) – tấn công từ chối dịch vụ
phân tán sử dụng botnet, một mạng lƣới gồm rất nhiều các máy tính tay sai để tiến
hành tấn công vào mục tiêu. Việc sử dụng mạng lƣới tay sai này đem lại năng lực
tấn công cực lớn và khả năng ẩn danh tốt do việc điều tra kẻ chỉ huy từ các máy tính
tay sai không phải đơn giản.
Vào tháng 2 năm 2000, một trong những cuộc tấn công DDoS lớn là cuộc tấn
công vào Yahoo.com, khiến cho trang web này tê liệt trong vòng 2 giờ và không thể
3
phục vụ hàng ngàn ngƣời dùng trên toàn thế giới, gây thiệt hàng trăm nghìn USD.
Tại Việt Nam, vào tháng 12 năm 2005, website của cộng đồng bảo mật HVA bị tấn
công DDoS bằng phƣơng thức X-flash, đây đƣợc cho là vụ tấn công DDoS đầu tiên
tại Việt Nam. Từ đó đến nay, rất nhiều cuộc tấn công khác đƣợc ghi nhận, điển hình
là những cuộc tấn công vào các báo điện tử lớn nhƣ dantri.com, vietnamnet.vn gây
thiệt hại khá lớn cho các công ty này.
Dựa vào mức độ phổ biến và khả năng gây thiệt hại cho nạn nhân, các nghiên
cứu về DoS chủ yếu tập trung vào DDoS, hình thức tấn công sử dụng số lƣợng lớn
các máy tính trung gian làm cạn kiệt tài nguyên của hệ thống. Luận văn cũng giới
hạn nghiên cứu trong hình thức tấn công này.
2. Phân loại DoS
Có nhiều tiêu chí để phân loại DoS, dƣới đây là cách phân loại dƣới góc nhìn
của ngƣời quản trị hệ thống, dựa vào giao thức thực hiện tấn công.
2.1. Tấn công DoS ở tầng Network/Transport
Những kiểu tấn công này đƣợc thực hiện bằng các gửi đi các gói tin TCP, UDP,
ICMP hay IP. Có bốn loại tấn công[7]:
a. Tấn công gây tràn: Kẻ tấn công làm gián đoạn các kết nối của ngƣời dùng
hợp lệ bằng cách làm tràn băng thông mạng. Kiểu tấn công này bao gồm UDP
Flood, ICMP Flood, DNS Flood, VoIP Flood có hoặc không giả mạo địa chỉ IP,...
b. Tấn công dựa trên điểm yếu của giao thức: Kẻ tấn công khai thác một vài
điểm yếu của giao thức đƣợc sử dụng để làm cạn kiệt tài nguyên của hệ thống.
Ví dụ điển hình của kiểu tấn công này là TCP SYN Flood[8]. Thông thƣờng khi
bắt đầu một phiên kết nối TCP, client và server phải trải qua quá trình bắt tay ba
bƣớc[4] nhƣ sau:
-
Client yêu cầu kết nối bằng cách gửi một gói SYN tới server
-
Server xác nhận yêu cầu này bằng cách gửi lại mộ gói SYN-ACK
4
-
Client gửi lại server một gói ACK, kết nối đƣợc thiết lập
Hình 1. Quá trình bắt tay ba bước
Tấn công SYN Flood đƣợc thực hiện bằng cách client không trả lời server bằng
gói tin ACK ở bƣớc cuối cùng. Server sẽ chờ gói ACK này trong một khoảng thời
gian định trƣớc, đồng thời cấp phát sẵn một số tài nguyên cho kết nối này. Nếu số
gói SYN đủ lớn, lƣợng tài nguyên cấp phát cho các kết nối không hợp lệ sẽ vƣợt
quá khả năng của server, khiến nó không thể phục vụ cho ngƣời dùng hợp lệ nữa.
Hình 2. Mô hình tấn công SYN Flood
c. Tấn công dựa trên phản xạ: Kẻ tấn công gửi gói tin giả mạo địa chi IP nguồn
là địa chỉ của server nạn nhân tới các máy reflector. Các reflector này sẽ gửi gói tin
trả lời tới server nạn nhân, làm cho nó bị tê liệt.
5
Ví dụ điển hình của kiểu tấn công này là Smurf Attack[8]. Smurf Attack dựa vào
địa chỉ IP broadcast để thực hiện tấn công. Mô hình của Smurf Attack gồm có:
-
Kẻ tấn công
-
Mạng trung gian
-
Nạn nhân
Hình 3. Mô hình tấn công Smurf
Kẻ tấn công sẽ gửi một loạt các gói ICMP ECHO REQUEST tới địa chỉ
broadcast của mạng trung gian, địa chỉ nguồn là địa chỉ của nạn nhân. Gói tin này sẽ
đƣợc tiếp tục gửi tới toàn bộ máy tính trong dải địa chỉ broadcast, mỗi máy khi nhận
đƣợc gói tin này sẽ gửi trả lại gói tin tới ICMP ECHO REPLY về địa chỉ của nạn
nhân. Nhƣ vậy kẻ tấn công hoàn toàn đƣợc ẩn danh, nạn nhân chỉ nhận đƣợc toàn
bộ các gói tin đến từ mạng trung gian.
d. Tấn công dựa trên khuếch đại: Kẻ tấn công lợi dụng các service để khuếch
đại số lƣợng gói tin lên gấp nhiều lần và hƣớng traffic đó tới nạn nhân. Ví dụ Smurf
Attack[8] ở trên đã sử dụng cả kỹ thuật phản xạ và khuếch đại. Botnet cũng đƣợc sử
dụng cho hai mục đích này.
6
Hình 4. Mô hình Botnet
2.2. Tấn công DoS ở tầng Application
Các kỹ thuật tấn công ở tầng Application[7] hiện nay đang phát triển rất nhanh.
Chúng thƣờng tập trung vào việc làm cạn kiệt tài nguyên của server nhƣ CPU,
memory, disk/database bandwidth hay IO bandwitdh. Nó ít khi tiêu tốn băng thông
mạng nên khó phát hiện hơn các kiểu tấn công ở tầng Network/Transport[7] và hay
bị nhầm lẫn với Flash Crowd.
a. Tấn công dựa trên phản xạ/khuếch đại: Các kiểu tấn công này sử dụng cùng
kỹ thuật nhƣ các kiểu tấn công ở tầng network/transport, nghĩa là gửi các gói tin ở
tầng application với địa chỉ nguồn giả mạo tới một lƣợng lớn các reflectors.
7
Ví dụ nhƣ DNS Flooding Attack[7] sử dụng cả kỹ thuật phản xạ và khuếch đại.
Kẻ tấn công (thƣờng là các zombie) sinh các query DNS với địa chỉ IP nguồn là của
nạn nhân, từ đó có thể tạo ra lƣợng traffic lớn hƣớng về nạn nhân, do các dung
lƣợng các DNS response trả về lớn hơn nhiều so với các query.
Một ví dụ khác là VoIP Flooding[7]. Kiểu tấn công này là một biến thể của UDP
flooding. Kẻ tấn công gửi các gói VoIP giả mạo địa chỉ nguồn với dải IP rất rộng tới
nạn nhân, ở một tần suất rất lớn. VoIP server phải phân biệt đƣợc kết nối nào đã
đăng ký, kết nối nào chƣa, việc phân biệt này tốn rất nhiều tài nguyên và vì thế
server bị quá tải.
b. Tấn công HTTP: Đây là loại tấn công DOS phổ biến nhất trên tầng
Application. Loại tấn công này bao gồm các kiểu:
-
Session Flooding Attacks[7]: Trong kiểu tấn công này, attacker tạo ra rất
nhiều phiên kết nối đến server nạn nhân, khiến server tốn nhiều tài nguyên để
xử lý và bị quá tải. Phổ biến nhất là tấn công bằng các gói HTTP get/post. Kẻ
tấn công thƣờng dùng botnet để tiến hành cuộc tấn công. Do mỗi máy tay sai
có thể sinh ra lƣợng lớn các request hợp lệ (thƣờng nhiều hơn 10 request mỗi
giây) nên không cần nhiều máy tay sai để có thể khiến cuộc tấn công thành
công. HTTP get/post flooding attacks là kiểu tấn công không giả mạo địa chỉ
nguồn.
-
Request Flooding Attacks[7]: Trong kiểu tấn công này, kẻ tấn công gửi nhiều
request tới server nạn nhân nhƣng trong cùng một phiên kết nối. Vì thế, kẻ
tấn công có thể giới hạn số lƣợng kết nối để vƣợt qua cơ chế phòng thủ của
server mà vẫn làm cho server tê liệt.
-
Multiple VERB Single Request[7]: Trong kiểu tấn công này, kẻ tấn công cũng
tạo nhiều request tới server nạn nhân nhƣng không gửi nó lần lƣợt mà gộp
chung vào trong cùng một packet. Điều này làm cho số lƣợng gói tin gửi tới
server nạn nhân thấp, qua mặt đƣợc các bộ lọc gói tin mà vẫn tạo ra tải lớn
trên server.
8
-
Slow Request/Response Attacks[7]: Trong kiểu tấn công này, kẻ tấn công tạo
nhiều kết nối tới server nạn nhân và giữ chúng tồn tại lâu nhất có thể.
Điển hình của kiểu tấn công này là Slowloris Attack: kẻ tấn công gửi liên tục
từng phần của HTTP request nhƣng không bao giờ hoàn thành các request
đó. Server nạn nhân mở quá nhiều kết nối mà không giải phóng chúng, khiến
cho không còn chỗ cho các kết nối của ngƣời dùng hợp lệ.
Một kiểu tấn công khác là Slowreading Attack[7]: thay vì gửi các request đi
thật chậm, kiểu tấn công này lại chậm chạp trong việc xử lý các response trả
về. Để làm đƣợc điều này, phía client thiết lập kích thƣớc cửa sổ nhận
(receive window-size) thấp hơn kích thƣớc buffer gửi đi (send buffer) của
server. Giao thức TCP duy trì kết nối kể cả khi không có dữ liệu đƣợc trao
đổi, khiến cho server bị quá tải.
3. Phát hiện và phòng chống DoS
3.1. Trước tấn công
Hiện nay phần lớn các cuộc tấn công DoS đƣợc thực hiện bằng botnet[8]. Nó
đem lại một năng lực tấn công cực lớn và khả năng ẩn danh tốt. Vì vậy, hạn chế sự
phát triển của botnet cũng góp phần làm giảm tấn công DoS và những thiệt hại mà
nó gây ra.
Đầu tiên là cần ngăn chặn các máy tính tham gia vào botnet. Trách nhiệm này
thuộc về các quản trị mạng và từng ngƣời sử dụng máy tính. Các máy tính tham gia
vào mạng Internet phải đƣợc đảm bảo cài đặt đầy đủ các bản vá, anti-virus, antimailware, firewall cá nhân, cấp quyền sử dụng tối thiểu cho ngƣời dùng,...Firewall,
IDS, IPS trong hệ thống cũng phải có khả năng bảo vệ cho các máy tính trong nội
bộ. Một việc cũng rất quan trong đó là đào tạo nhận thức cho ngƣời dùng.
Biện phát thứ hai, quan trọng hơn nhƣng cũng phức tạp hơn, đó là phát hiện,
theo dõi và bóc gỡ các botnet. Việc phát hiện hoạt động của một botnet phải đƣợc
bắt đầu từ việc phát hiện từng thành phần của nó, từ các máy bị nhiễm bot, các máy
9
điều khiển (handler) tới máy chỉ huy (master), từ đó phân tích các mẫu bot để loại
bỏ. Một số hệ thống theo dõi và bóc gõ botnet điển hình trên thế giới nhƣ của Hàn
Quốc, đƣợc xây dựng khi có rất nhiều các cuộc tấn công DDoS xảy ra tại đất nƣớc
này; hay hệ thống phản ứng với botnet của Nhật Bản có tên là “Cyber Clean
Center”, còn gọi là CCC, đƣợc xây dựng từ năm 2006 và hoạt động từ tháng 3 năm
2011. Trên thực tế, khó có một giải pháp đơn lẻ đối phó với botnet toàn diện và hiệu
quả, vì vậy khi đối phó với botnet cần tiếp cận theo nhiều hƣớng khác nhau, bao
gồm: giải pháp kỹ thuật, pháp luật, đào tạo nhận thức.
Đối phó với botnet là rất cần thiết và quan trọng, tuy vậy, khi xét tới việc chống
tấn công DoS, biện pháp này chỉ mang tính vĩ mô, không hiệu quả và khó thực hiện
khi bảo vệ một hệ thống cụ thể.
3.2. Trong tấn công
Việc chuẩn bị và áp dụng các biện pháp đối phó khi có tấn công DoS xảy ra
đƣợc xem là quan trọng nhất, bao gồm: tối ƣu hiệu năng hệ thống, phát hiện tấn
công và lọc[8], honey pot[8].
Tối ƣu và cải thiện hoạt động của hệ thống bao gồm tùy chỉnh lại cấu hình hệ
thống, nâng cấp phần cứng, áp dụng load balancing[8] để phân tải,... Tuy nhiên
phƣơng pháp này chỉ có tác dụng trong trƣờng hợp một cuộc tấn công với lƣu lƣợng
vừa phải. Một cuộc tấn công lớn sẽ nhanh chóng làm sụp đổ hệ thống.
Phát hiện tấn công và lọc bỏ các gói tin tấn công là phần quan trọng nhất. Tùy
vào từng kiểu tấn công cụ thể mà áp dụng các phƣơng pháp khác nhau. Một vấn đề
thƣờng gặp là các cuộc tấn công DoS thƣờng giả mạo địa chỉ IP nguồn, do đó phải
phát hiện đƣợc các gói tin giả mạo này để loại bỏ, không xử lý.
Honeypot[8] là một hệ thống đƣợc cài đặt với mức độ security thấp, sử dụng để
làm lệch hƣớng các cuộc tấn công DoS khỏi hệ thống chính, đồng thời lƣu trữ thông
tin về cuộc tấn công nhƣ loại tấn công, phần mềm sử dụng,… để phục vụ cho mục
đích ngăn chặn các cuộc tấn công sau này.
10
Hiện nay một số công ty về bảo mật cung cấp các dịch vụ DDoS Mitigation,
điển hình là CloudFlare. Các dịch vụ chống tấn công DoS này hoạt động bằng cách
thay đổi nameserver của các website đƣợc bảo vệ, từ đó hƣớng toàn bộ traffic tới
các data center của dịch vụ. Tại đây traffic đƣợc phân tích, lọc bỏ và chỉ những
traffic của ngƣời dùng hợp lệ mới đƣợc chuyển tiếp về server đích. Phƣơng pháp
này tạo ra sự tiện lợi do không phải thay đổi cấu hình hay cài đặt thêm thành phần
nào trên hệ thống đƣợc bảo vệ.
3.3. Sau tấn công
Các giải pháp sau tấn công có mục đích chính là phòng bị cho các cuộc tấn công
có thể có sau này. Với các thông tin thu đƣợc từ cuộc tấn công, ngƣời quản trị hệ
thống tiến hành tối ƣu lại hệ thống, cập nhật module phát hiện, bộ lọc gói tin, honey
pot,...Vì vậy việc có các module monitor, log tập trung trong hệ thống là rất cần
thiết.
Ngoài ra, các phƣơng pháp truy vết[8] ra nguồn tấn công cũng thƣờng đƣợc sử
dụng, mặc dù trong một số trƣờng hợp nó không khả thi do gói tin đã bị NAT hoặc
thay đổi khi qua các firewall, hay không có tác dụng đối với một cuộc tấn công DoS
phản xạ.
11
CHƯƠNG 2 – PHÁT HIỆN TẤN CÔNG DOS BẰNG
PHƯƠNG PHÁP PHÂN TÍCH LOG
1. Giới thiệu
Log là những file ghi lại những sự kiện xảy ra trong một hệ điều hành, một phần
mềm ứng dụng; hoặc ghi lại những thông điệp giao tiếp giữa các hệ thống với nhau.
Đối với ngƣời quản trị hệ thống, file log là nguồn tài nguyên rất có giá trị, giúp họ
có đầy đủ thông tin để phân tích và ra quyết định, đặc biệt khi xảy ra các sự cố trên
hệ thống mạng.
Một điều hiển nhiên là một cuộc tấn công DoS (hay DDoS) sẽ để lại những dấu
vết trên các file log. Hình dƣới đây là một phần nội dung log của firewall:
Hình 5. Chi tiết một phần log của firewall
Ta nhận thấy chỉ trong 1s từ một địa chỉ IP có rất nhiều gói tin SYN đƣợc gửi tới
port 80 của máy chủ 10.0.53.58 (web server). Phần nội dung không đƣợc hiển thị ở
hình trên còn cho ta biết đƣợc sau khi máy chủ 10.0.53.58 gửi lại gói tin SYN-ACK
thì không thấy địa chỉ IP này gửi lại gói ACK để hoàn thành quá trình bắt tay ba
bƣớc[4]. Hành vi này rõ ràng là bất thƣờng và ta hoàn toàn có thể kết luận IP này là
một phần của một cuộc tấn công SYN Flood nhắm vào hệ thống. Địa chỉ IP này cần
đƣợc đƣa vào bộ lọc của firewall, nhằm giảm mức độ ảnh hƣởng cho web server ở
bên trong.
12
Ví dụ trên cho ta thấy, hoàn toàn có thể sử dụng dữ liệu trong log file để phát
hiện tấn công DoS và trích xuất ra những thông tin cần thiết để ngăn chặn tấn công.
Giải pháp đƣợc trình bày trong đề tài này đi theo tƣ tƣởng đó.
2. Mô hình chung
Một nguyên tắc của thu thập dữ liệu là càng lấy đƣợc nhiều dữ liệu càng tốt, do
các kiểu tấn công là đa dạng nên ta không thể biết đƣợc dữ liệu nào cần thiết, dữ
liệu nào là không. Trên thực tế, một hệ thống mạng của doanh nghiệp/tổ chức bao
gồm rất nhiều thành phần: web server, mail server, DNS server, file sharing
system,…mỗi thành phần đều có hệ thống log của các ứng dụng chạy trên nó. Tất
cả các dữ liệu này, nếu ta tiến hành phân tích dữ liệu tại chỗ đôi khi sẽ không đầy
đủ thông tin để phát hiện tấn công và rất khó quản lý. Mặt khác, khi log file lớn,
việc phân tích sẽ tiêu tốn tài nguyên và ảnh hƣởng tới hiệu năng của chính máy chủ
hiện tại. Vì vậy, phân tích dữ liệu tập trung và phân tách quá trình phân tích ra khỏi
hoạt động của hệ thống sẽ là một hƣớng đi đúng đắn hơn.
Giải pháp đề xuất ở đây bao gồm hai thành phần chính: Log Center và các Log
Collector. Log Collector có nhiệm vụ thu thập các log file của hệ thống, trong khi
đó Log Center lƣu trữ toàn bộ các dữ liệu này và tiến hành phân tích để phát hiện
tấn công và trích xuất dữ liệu cần thiết cho quá trình ngăn chặn.
13
Servers &
Applications
Log collector
Firewalls
Log collector
Log center
Routers
& Switches
Log collector
Hình 6. Mô hình giải pháp
3. Lựa chọn giải pháp cho các thành phần
3.1. Log Collector
-
Nhiệm vụ: thu thập log file từ mọi nguồn trong hệ thống.
-
Yêu cầu:
o Đa nền tảng: do log file có ở khắp nơi, trên rất nhiều các nền tảng khác
nhau, theo nhiều chuẩn log khác nhau nên log collector phải hỗ trợ hầu
hết các nền tảng hệ điều hành và chuẩn log hiện nay.
o Real-time: log collector phải theo dõi sự thay đổi của file log ngay tức thì
để chuyển dữ liệu về log center, nhằm giảm tối đa độ trễ trong việc phát
hiện tấn công.
o Dữ liệu trên log file ở dạng thô, để thuận tiện cho quá trình lƣu trữ và
phân tích, log collector phải có khả năng chuyển đổi chúng sang dữ liệu
có cấu trúc.
14
-
Giải pháp lựa chọn: Logstash[3]. Đây là phần mềm mã nguồn mở chuyên
dùng để thu thập dữ liệu từ file log, có các tính năng thỏa mãn yêu cầu đặt ra
ở trên:
o Viết bằng Java nên có thể chạy trên mọi hệ điều hành, chỉ cần cài đặt
Java Runtime Enviroment.
o Có khả năng thu thập dữ liệu real-time.
o Hỗ trợ viết thêm plugin để tùy biến quá trình thu thập log: điều này rất
quan trọng vì mỗi loại log lại có một cấu trúc khác nhau; hoặc đôi khi
một phần nào đó của log ta biết chắc chắn là không cần thiết nên cần
chỉnh sửa bộ lọc để loại bớt phần dữ liệu dƣ thừa.
3.2. Log Center
-
Nhiệm vụ: Lƣu trữ và phân tích log.
-
Yêu cầu: Do dữ liệu thu thập đƣợc sẽ là rất lớn nên Log center cần đáp ứng
hai tiêu chí:
o Khả năng tìm kiếm nhanh trên nguồn dữ liệu lớn.
o Khả năng mở rộng (scalability).
-
Giải pháp lựa chọn: Elasticsearch[2]. Đây cũng là một phần mềm mã nguồn
mở, một server tìm kiếm đƣợc xây dựng trên engine là Lucene, một thƣ viện
full text search khá phổ biến. Elasticsearch đáp ứng đƣợc yêu cầu trên dựa
vào các tính năng:
o Toàn bộ dữ liệu trong Elasticsearch đều đƣợc index, quá trình tìm kiếm
là thực hiện trên dữ liệu đã index.
o Là Near Real-time Platform: có độ trễ rất nhỏ từ lúc dữ liệu đƣợc index
tới khi nó searchable.
o Hỗ trợ Cluster, Node, Shard, Replication,… giúp lƣu trữ và tìm kiếm dữ
liệu phân tán. Đáp ứng khả năng mở rộng theo cả chiều ngang lẫn chiều
dọc.
15
4. Hoạt động của từng thành phần
4.1. Log Collector
Log Collector là các Logstash agent đƣợc cài đặt tại những nơi cần thu thập log.
Các agent này đƣợc cấu hình để thu thập log theo thời gian thực, cấu trúc hóa dữ
liệu log và đẩy log về hệ thống lƣu trữ là Elasticsearch. Phần này mô tả chi tiết tiến
trình đó.
a. Mô hình hoạt động của Logstash
Mỗi một phần dữ liệu log thu thập đƣợc, Logstash[3] coi nhƣ là nó xử lý một sự
kiện. Toàn bộ quá trình xử lý sự kiện của Logstash trải qua ba giai đoạn: inputs →
filters → outputs. Các input thu thập log, sinh ra sự kiện, các filter chỉnh sửa chúng
và các output vận chuyển các sự kiện đến một nơi nào đó (ở đây là Elasticsearch).
Ngoài ra, các input và output cũng hỗ trợ các codec, cho phép encode và decode dữ
liệu mà không cần thiết phải sử dụng thêm các filter.
Hình 7. Luồng xử lý sự kiện của Logstash
-
Inputs: sử dụng để lấy dữ liệu vào Logstash. Logstash hỗ trợ nhiều cơ chế
input nhƣ:
o file: đọc dữ liệu từ file trên hệ thống tƣơng tự nhƣ lệnh tail –f trên
Unix
16
o syslog: listen trên port 514 các syslog messages và xử lý theo định dạng
RFC3164
o Microsoft Windows EventLog: đọc dữ liệu trên hệ thống log của
Windows
o TCP/UDP: đọc dữ liệu đến từ luồng TCP/UDP
-
Filters: khi log đƣợc input thu thập, có một loạt các filter cho phép ngƣời
dùng chỉnh sửa, thay đổi, trích xuất một phần dữ liệu. Có thể kết hợp sử dụng
nhiều filter cùng lúc. Một số các filter hữu ích là:
o grok: giúp phân tích và cấu trúc hóa dữ liệu văn bản bất kỳ. Hiện tại grok
là cách tốt nhất trong Logstash để xử lý những dữ liệu thô, biến chúng
thành dữ liệu có cấu trúc và có thể tìm kiếm đƣợc. Grok cũng có sẵn các
mẫu để áp dụng cho một số loại log phổ biến.
o mutate: thực hiện thay đổi, chỉnh sửa trên dữ liệu
o drop: bỏ qua hoàn toàn dữ liệu
o clone: copy dữ liệu, có thể thêm hoặc xóa bớt các trƣờng
o geoip: thêm những thông tin về vị trí địa lý của địa các địa chỉ IP
-
Outputs: có tác dụng chuyển dữ liệu log sau khi xử lý bởi filter, tới đích. Một
sự kiện có thể đƣợc chuyển tới nhiều đích khác nhau. Khi sử dụng các
output, ngƣời dùng có thể tích hợp Logstash với các hệ thống cảnh báo, giao
diện thống kê đồ họa, cơ sở dữ liệu hay các đích tùy chọn khác của ngƣời
dùng. Một số các output hay đƣợc sử dụng là:
o Elasticsearch: gửi dữ liệu đến Elasticsearch. Đây cũng là output đƣợc sử
dụng trong giải pháp.
o file: ghi dữ liệu ra file trên hệ thống
-
Codecs: ngoài sử dụng filter để lọc và chỉnh sửa dữ liệu, Logstash còn hỗ trợ
các codec. Codecs về cơ bản là các stream filter có thể thực thi nhƣ một phần
của inputs hoặc outputs. Các codec thƣờng gặp là:
o json: encode hoặc decode dữ liệu ở định dạng JSON
17
o multiline: gộp dữ liệu nhiều dòng nhƣ java exception hay stack message
thành một dòng
b. Khả năng chịu lỗi
Trong Logstash[3], sự kiện đƣợc truyền từ module này tới module thông qua các
hàng đợi sự kiện. Logstash đặt kích thƣớc của các hàng đợi này là 20, nghĩa là có
tối đa 20 sự kiện đƣợc chờ để đƣợc xử lý. Khi các hàng đợi này đầy, mọi thao tác
ghi lên chúng đều bị block. Điều này giúp tránh bị mất mát dữ liệu và làm Logstash
hoạt động giống nhƣ một hệ thống lƣu trữ dữ liệu tạm thời.
Kích thƣớc hàng đợi nhỏ này khiến cho Logstash chỉ đơn giản là block và tạm
ngừng hoạt động một cách an toàn khi tải quá lớn hoặc hàng đợi xử lý gặp một vấn
đề nào đó. Một vài phƣơng án khác có thể là thiết lập các hàng đợi không giới hạn
kích thƣớc hay loại bỏ sự kiện đến khi xảy ra sự cố, tuy nhiên chúng đều không
thực sự hợp lý. Một hàng đợi không giới hạn kích thƣớc có thể gây ra cạn kiệt bộ
nhớ, trong khi đó việc bỏ qua các sự kiện là điều không đƣợc mong đợi.
Một output có thể gặp vấn đề, do ổ đĩa của đích đầy, nghẽn mạng, không có đủ
quyền…Một khi gặp sự cố, output sẽ tạm dừng và đợi cho tới khi nó có thể tiếp tục
gửi message. Điều đó có nghĩa là nó sẽ ngừng đọc dữ liệu từ hàng đợi, làm cho
hàng đợi output bị đầy, dẫn tới các hàng đợi filter và input cũng đầy, Logstash sẽ
tạm dừng đọc dữ liệu từ nguồn. Trƣờng hợp này có thể xảy ra khi hệ thống bị tấn
công DoS, do lƣợng log sinh ra sẽ rất lớn. Khi đó, cơ chế hàng đợi này giúp cho
Logstash vẫn hoạt động bình thƣờng và không bị mất mát dữ liệu.
c. Hiệu năng và tiêu tốn tài nguyên
Mô hình luồng của Logstash[3] nhƣ sau:
input threads | filter worker threads | output worker
Các filter có thể tùy chọn, trong trƣờng hợp không sử dụng filter, mô hình đơn
giản sẽ là:
input threads | output worker
18
Mỗi input đƣợc thiết lập chạy trên một luồng riêng biệt, giúp cho các input khi
hoạt động không gây ảnh hƣởng đến nhau, mà trƣờng hợp hay gặp là một input bị
quá tải khiến cho tất cả các input khác phải dừng hoạt động theo.
Các filter cũng hoạt động theo mô hình đa luồng, tuy vậy mỗi luồng sẽ nhận một
sự kiện theo thứ tự và áp dụng tất cả các filter lên sự kiện đó, trƣớc khi chuyển tiếp
tới hàng đợi output. Theo mặc định, số luồng filter đƣợc thiết lập là 1.
Các output lại hoạt động trên cùng một luồng đơn, nhận sự kiện lần lƣợt theo
thứ tự đƣợc ngƣời dùng thiết lập. Output có cơ chế xử lý theo lô: lƣu trữ tạm thời
các sự kiện và gửi tới đích tất cả trong một lần. Cơ chế này giúp cải thiện hiệu năng
do Logstash không phải mất nhiều thời gian chờ phản hồi từ đích.
Nhƣ vậy, thông thƣờng Logstash sẽ sử dụng ít nhất 3 luồng, một luồng input,
một luồng filter và một luồng output. Vì thế khi hoạt động có thể Logstash sẽ sử
dụng đồng thời nhiều CPU, giúp cải thiện hiệu năng so với việc chỉ sử dụng một
luồng đơn. Mặt khác, do có hạn chế kích thƣớc của các hàng đợi nên Logstash sẽ
không tiêu tốn quá nhiều tài nguyên của hệ thống, một điều khá quan trọng đối với
các máy chủ chịu trực tiếp cuộc tấn công DoS.
d. Ví dụ: Sử dụng Logstash để thu thập Apache log
Đây là nội dung file cấu hình của Logstash[3] để lấy những đoạn Apache log thỏa
mãn một số yêu cầu và đƣa dữ liệu thu thập đƣợc tới Elasticsearch, đồng thời hiển
thị ra màn hình:
input {
file {
1
path => "/var/log/httpd/access_log"
start_position => "beginning"
}
}
filter {
grok {
2
19
match => { "message" => "%{COMBINEDAPACHELOG}" }
}
mutate {
3
replace => { "time_stamp" => "%{+YYYY-MM-dd'T'hh:mm:ss}" } }
}
output {
Elasticsearch {
4
host => "192.168.10.3"
index => "logstash-webserver-%{+YYY.MM.dd}"
}
5
stdout { codec => rubydebug }
}
File cấu hình trên mô tả nhƣ sau:
-
1
Input plugin file sẽ theo dõi thay đổi của file tại đƣờng dẫn
/var/log/httpd/access_log, bắt đầu từ vị trí beginning.
-
2
Filter plugin grok có nhiệm vụ lọc ra những message có định dạng
đƣợc mô tả bằng xâu "%{COMBINEDAPACHELOG}" và phân tích message
thành dữ liệu có cấu trúc. Xâu này đƣợc định nghĩa chi tiết trong grok, nó
match với định dạng request thông thƣờng của Apache log.
-
3
Filter plugin mutate có nhiệm vụ chuyển đổi trƣờng time_stamp
thành định dạng YYYY-MM-dd'T'hh:mm:ss.
-
4
Output plugin Elasticsearch sẽ chuyển message từ các filter tới máy
chủ Elasticsearch tại địa chỉ 192.168.10.3, lƣu trữ tại index logstashwebserver-%{+YYY.MM.dd} (index đƣợc tự động rotate theo ngày)
-
5
Output plugin stdout in message ra màn hình theo định dạng đã đƣợc
xử lý bởi codec rubydebug.
Để chạy Logstash với cấu hình này, sử dụng lệnh:
20
