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

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.. Lịch sử của DoS được ghi nhận vào nh

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

i

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

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

iii

DANH MỤC CÁC KÝ HIỆU, CÁC CHỮ 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

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ữ

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

1

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

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

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ể

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

5

- 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

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

7

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

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

9

- 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, anti-mailware, 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

đ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

11

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ạ

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

13

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

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

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

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

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

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

19

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:

match => { "message" => "%{COMBINEDAPACHELOG}" }

File cấu hình trên mô tả như sau:

- 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.

- 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

- 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

- 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 webserver-%{+YYY.MM.dd} (index được tự động rotate theo ngày)

logstash 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:

21

bin/logstash -f logstash-filter.conf

4.2 Log Center

Log Center là máy chủ cài đặt Elasticsearch[2] để lưu trữ dữ liệu log và cung cấp

cơ chế để giúp người quản trị hệ thống phân tích dữ liệu log

a Tổng quan về Elasticsearch

Elasticsearch[2] là một search engine mã nguồn mở được xây dựng dựa trên Apache Lucene, một thư viện full-text search engine Lucene được đánh giá là một thư viện full-text search engine có hiệu năng cao và đầy đủ các tính năng nhất hiện nay Tuy vậy Lucene chỉ đơn thuần là một thư viện Để khai thác hết các khả năng của nó, người sử dụng phải làm việc với Java và tích hợp Lucene trực tiếp vào trong ứng dụng, điều này yêu cầu hiểu biết rất sâu về hoạt động của Lucene, trong khi đó Lucene lại rất phức tạp

Elasticsearch cũng được xây dựng bằng Java và sử dụng Lucene cho các thao tác index và search, tuy vậy nó hướng tới ẩn tính phức tạp của Lucene bằng cách cung cấp cho người dùng một bộ API đơn giản và nhất quán để thao tác với dữ liệu Ngoài ra, Elasticsearch còn có thêm các tính năng sau:

- Khả năng lưu trữ phân tán theo thời gian thực, mọi trường dữ liệu đều có thể được index và tìm kiếm

- Phân tích dữ liệu theo thời gian thực

- Khả năng mở rộng lên tới hàng trăm server với lượng dữ liệu có cấu trúc và không cấu trúc rất lớn

b Mô hình dữ liệu của Elasticsearch

Đơn vị dữ liệu nhỏ nhất trong Elasticsearch[2] là một field, thuộc một kiểu dữ liệu định sẵn Một field có một giá trị đơn, như kiểu số hay kiểu string, hoặc là một danh sách các giá trị thuộc cùng một kiểu, như mảng

Document là một tập hợp bao gồm các field, tạo thành đơn vị cơ bản được lưu trữ trong Elasticsearch, tương đương với một dòng trong cơ sở dữ liệu quan hệ Document được coi là đơn vị dữ liệu cơ bản của Elasticsearch là do mọi thao tác cập nhật trên field cũng sẽ cập nhật hoàn toàn một document Elasticsearch là một

hệ thống hướng document: không chỉ lưu trữ chúng, Elasticsearch index toàn bộ nội dung của document theo thứ tự để chúng có thể được tìm kiếm

Elastichsearch sử dụng JSON làm định dạng dữ liệu chính JSON được hỗ trợ bởi hầu hết các ngôn ngữ lập trình và đã trở thành định dạng chuẩn cho cơ sở dữ liệu NoSQL bởi tính đơn giản, ngắn gọn và dễ sử dụng Một document thể hiện thông tin của một cá nhân được mô tả như sau:

Document hỗ trợ tất cả các tính năng thuộc về JSON Ở ví dụ trên, trường info

có giá trị là một object, trong đó trường interests có giá trị là một mảng các string Trường _id là một trong những trường đặc biệt trong Elasticsearch: nó là định danh duy nhất cho từng document và được tạo ra một cách hoàn toàn tự động,

nó tương tự như khóa chính trong cơ sở dữ liệu quan hệ

c Tìm kiếm và phân tích dữ liệu từ Elasticsearch

Elasticsearch[2] là một cơ sở dữ liệu, một search server, để giao tiếp với nó, người dùng gửi các HTTP request và nhận các HTTP response trả về, xử lý để lọc

28/08/2015, với địa chỉ IP của Elasticsearch server là 10.0.0.27, port là 9200

Một request phức tạp hơn, liệt kê ra các địa chỉ IP và số request gửi tới web server trong khoảng thời gian 15’ trước tính từ hiện tại:

{

"key": "72.162.36.14", "doc_count": 177 },

{

"key": "178.19.247.73", "doc_count": 133 },

{

"key": "45.55.41.166", "doc_count": 106 },

{

"key": "192.168.1.75", "doc_count": 76 }

]

}

}

}

Mặt khác, đối với quá trình phân tích log để phát hiện tấn công DoS, một số các thao tác thường được lặp đi lặp lại nhiều lần Chính vì các lí do trên, một thư viện

hỗ trợ giao tiếp với Elasticsearch, giúp đơn giản hóa các công việc của người phân tích log là cần thiết

2 Tổng quan về thư viện

Là một lớp giao tiếp giữa người sử dụng và Elasticsearch, thư viện được thiết kế dựa trên những khái niệm cơ bản nhất của Elasticsearch, đó là Document, Type và Index

- Document là đơn vị dữ liệu cơ bản nhất được index trong Elasticsearch Ví

dụ một Document của một sản phẩm, chứa những thông tin về sản phẩm đó; một Document về một khách hàng; về một đơn hàng,…Document được thể hiện dưới dạng JSON (JavaScript Object Notation), là một định dạng giao tiếp dữ liệu phổ biến trên internet Khái niệm Document có thể hiểu tương đương với khái niệm Row trong cơ sở dữ liệu quan hệ Ví dụ một Document

về thông tin khách hàng có dạng như sau:

{

"_index": "company",

"_type": "customers",

"_id": "AU9dQ-FMDOK0hvvrYOGH",