Embed Size (px)
Citation preview
1
LỜI CAM ĐOAN
Tôi xin cam đoan đây là tìm hiểu và nghiên cứu của riêng tôi .
Các số liệu nêu trong luận văn là trung thực và có cơ sở lý thuyết tham khảo.
Kết quả đạt được trong luận văn là chưa từng nơi nào công bố.
Tác giả
Nguyễn Huy Lợi
2
MỤC LỤC
Chương 1. Giới thiệu chung ........................................................................... 5
1.1. Đặt vấn đề ............................................................................................ 5
1.2. Mục tiêu ............................................................................................... 6
1.3 Phạm vi của đề tài ................................................................................ 6
1.4. Tóm tắt kết quả .................................................................................... 6
1.5. Cấu trúc luận văn ................................................................................ 7
Chương 2. Tổng quan về DDoS ...................................................................... 8
2.1. Giới thiệu chung về DDoS ................................................................... 8
2.2. Phân loại các kiểu tấn công DDoS ...................................................... 8
2.2.1 Tấn công làm cạn kiệt băng thông ................................................. 9
2.2.2 Tấn công làm cạn kiệt tài nguyên ................................................ 14
2.3. Sơ đồ mạng Botnet ............................................................................. 17
2.3.1 Sơ đồ Handler-Agent .................................................................. 17
2.3.2 Sơ đồ IRC Base ........................................................................... 18
2.4. Các phương pháp xây dựng tài nguyên tấn công .............................. 20
2.4.1 Cách thức cài đặt DDoS Agent .................................................... 20
2.4.2. Giao tiếp trên mạng Botnet........................................................ 22
2.5. Một số kiểu tấn công DDoS và các công cụ tấn công DDoS ............ 22
2.5.1 Một số kiểu tấn công DDoS ......................................................... 22
2.5.2 Một số công cụ tấn công DDoS ................................................... 23
Chương 3. Phòng thủ DDoS ......................................................................... 29
3.1 Tại sao DDoS khó giải quyết .............................................................. 29
3.2 Những thách thức khi xây dựng hệ thống phòng thủ DDoS .............. 30
3.3. Một số giải pháp phòng thủ DDoS .................................................... 37
3.3.1. Giải pháp dành cho doanh nghiệp cung cấp Hosting ................ 37
3.3.2. Giải pháp sử dụng IPS để lọc gói tin .......................................... 37
3.3.3. GeoIP DNS ................................................................................. 38
3.3.4. HAProxy ...................................................................................... 39
Chương 4. Cài đặt, thử nghiệm .................................................................... 41
4.1. Giải pháp dành cho doanh nghiệp cung cấp Hosting ....................... 41
4.1.1. Litespeed ..................................................................................... 41
4.1.2 CloudLinux ................................................................................... 43
4.1.3 ConfigServer Security & Firewall (CSF) .................................... 45
4.1.4. Thử nghiệm ................................................................................. 47
4.2. Giải pháp sử dụng IPS để lọc gói tin ................................................. 51
4.2.1 Snort ............................................................................................. 52
4.2.2 Thử nghiệm .................................................................................. 58
Kết luận: ........................................................................................................ 67
Tài liệu tham khảo ........................................................................................ 68
3
Danh mục các ký hiệu và chữ viết tắt (nếu có)
STT Phần viết tắt Phần viết đầy đủ
1 Server Máy chủ
2 DDoS Tấn công từ chối dịch vụ
3 Client Máy trạm
4 Agent Máy tính bị chiếm quyền điều khiển
5 Traffic Lưu lượng
6 Packet Gói tin
7 Message Bản tin
8 Protocol Giao thức
9 Reply Phản hồi
10 Router Thiết bị định tuyến
11 Subnet Mạng con
12 Broadcast Quảng bá
13 Port Cổng
14 IPS Hệ thống ngăn chặn xâm nhập
4
Danh mục các hình ảnh, đồ thị.
Hình 2.1 Phân loại các kiểu tấn công DDoS .................................................. 9
Hình 2.2: Mô hình mạng Amplifier ............................................................... 11
Hình 2.3 Trả lời truy vấn DNS ..................................................................... 13
Hình 2.4 Quá trình bắt tay ba bước .............................................................. 14
Hình 2.5 Tấn công TCP SYN Attack ............................................................. 15
Hình 2.6 :Sơ đồ mạng Botnet ........................................................................ 17
Hình 2.7 Sơ đồ IRC Base .............................................................................. 18
Hình 2.8 Các phương pháp xây dựng tài nguyên tấn công .......................... 20
Hình 2.9 Mô hình tấn công DDoS thông thường .......................................... 25
Hình 2.10 Mô hình tấn công X-Flash ........................................................... 27
Hình 3.1 Phương pháp đặt gần victim .......................................................... 34
Hình 3.2 Phương pháp đặt gần attacker ...................................................... 35
Hình 3.3 Phương pháp đặt tại phần lõi của Internet ................................... 36
Hình 3.4 Phương pháp kết hợp nhiều vị trí .................................................. 37
Hình 3.5 Mô hình sử dụng IPS để lọc gói tin ............................................... 38
Hình 3.6 Mô hình sử dụng GeoIP DNS ........................................................ 39
Hình 3.7 Mô hình sử dụng HAProxy và Keepalived .................................... 40
Hình 4.1 Máy chủ chạy apache .................................................................... 42
Hình 4.2 Máy chủ chạy litespeed .................................................................. 43
Hình 4.3 Mô hình hosting chia sẻ truyền thống ........................................... 44
Hình 4.4 Mô hình LVE của CloudLinux OS ................................................. 44
Hình 4.5: Các thông số cấu hình CloudLinux .............................................. 45
Hình 4.6: Cấu hình CloudLinux ................................................................... 48
Hình 4.8 Thông số của website ..................................................................... 49
Hình 4.9 Tấn công bằng tool ab ................................................................... 50
Hình 4.10 Thông số của website trong khi bị tấn công ................................ 51
Hình 4.11 Giới hạn tài nguyên ..................................................................... 51
Hình 4.12: Cấu trúc của Snort ..................................................................... 52
Hình 4.13 Mô hình thử nghiệm sử dụng IPS để lọc gói tin .......................... 59
5
Chương 1. Giới thiệu chung
1.1. Đặt vấn đề
Năm 2011, lấy lý do ủng hộ Wikileaks, các nhóm Hacktivism (là một
thuật ngữ diễn tả hành động tấn công, đột nhập vào một hệ thống máy tính
nhằm mục đích chính trị hoặc xã hội) như Anonymous, LulzSec, hay
TeaMp0isoN tiến hành nhiều hoạt động khác nhau chống lại các cơ quan
luật pháp, ngân hàng, chính phủ, các công ty bảo mật và những nhà cung cấp
phần mềm như tấn công lỗ thủng an ninh các hệ thống của Tổ chức Liên
hiệp quốc (UN), cơ quan tình báo bảo mật Straffor, CIA… Cho đến nay,
danh sách nạn nhân của các nhóm Hacktivism ngày một dài thêm, từ các
website của chính phủ Mỹ, Ukraine, Anh, Israel, Indonesia, Mexico, Hy
Lạp, Syria, Thổ Nhĩ Kỳ, … cho đến các ngân hàng như Bank of America,
Nova Ljubljanska Banka's (ngân hàng lớn nhất của Slovenia)..., các công ty
như Visa inc, Paypal inc, MasterCard, Oracle, NASA, …
Các nhóm Hacktivism sử dụng nhiều phương pháp tấn công khác nhau
nhưng phương pháp hay được sử dụng nhất là DDoS. Tuy đây không phải là
phương pháp mới nhưng nó vẫn đem lại hiệu quả cao, gây ảnh hưởng không
nhỏ đến các công ty, tổ chức kinh doanh đặc biệt là kinh doanh trên Internet.
Việt Nam hiện nay đang ở giai đoạn đầu của thương mại điện tử, việc
một công ty thương mại điện tử bị tấn công DDoS làm ảnh hưởng không chỉ
là hình ảnh, uy tín của công ty mà còn ảnh hưởng trực tiếp đến doanh thu,
lợi nhuận của mình. Trong quá trình công tác, tôi đã tiếp xúc với nhiều
trường hợp các công ty bị chính đối thủ cạnh tranh tấn công DDoS, một số
trường hợp bị ảnh hưởng đến mức gần như không thu được lợi nhuận trong
thời gian dài. Thực tế, cũng đã có nhiều giải pháp về phòng chống DDoS,
6
tuy nhiên, các giải pháp về phần cứng thì khá đắt đỏ, các giải pháp về phần
mềm thì rời rạc, chưa tổng hợp. Vì vậy, tôi đã lựa chọn đề tài : “Tìm hiểu
DDoS và xây dựng biện pháp phòng thủ DDoS cho webserver”, với mục
đích xây dựng, kiểm thử một số giải pháp sử dụng phần mềm mã nguồn mở
để các công ty vừa và nhỏ có thể triển khai dễ dàng.
1.2. Mục tiêu
Luận văn có 2 mục tiêu chính :
- Nghiên cứu tìm hiểu về DDoS, phân loại DDoS, giới thiệu một số
công cụ tấn công DDoS và các giải pháp phòng thủ DDoS mà về
mặt chủ quan cá nhân tôi nhận thức được.
- Dựa trên các giải pháp đã trình bày nói trên xây dựng một số kịch
bản kiểm thử.
1.3 Phạm vi của đề tài
Trong phạm vi của đề tài, tôi sẽ trình bày một cái nhìn tổng quan về
DDoS và một số giải pháp dựa trên phần mềm mã nguồn mở. Từ đó tôi cài
đặt và kiểm thử hai giải pháp có giá thành rẻ, dễ triển khai với các doanh
nghiệp vừa và nhỏ.
1.4. Tóm tắt kết quả
Theo yêu cầu đặt ra ban đầu là “Tìm hiểu DDoS và triển khai hệ
thống phòng thủ DDoS ”, cho đến thời điểm hiện tại, luận văn đã làm được
những nội dung sau
I. Tìm hiểu DDoS bao gồm
a. Tìm hiểu được những kiểu tấn công của DDoS.
b. Tìm hiểu được mô hình mạng Botnet (mô hình, cách cài đặt,
giao tiếp).
c. Một số công cụ tấn công DDoS.
II. Giới thiệu một số giải pháp phòng thủ DDoS.
III. Cài đặt và thử nghiệm 2 giải pháp phòng thủ DDoS.
7
1.5. Cấu trúc luận văn Luận văn có 4 chương bao gồm :
Chương 1. Giới thiệu chung.
Chương này tập trung xây dựng tính cấp thiết của việc thực hiện
nghiên cứu, mục tiêu và tóm tắt kết quả của đề tài.
Chương 2. Tổng quan về DDoS.
Chương này giới thiệu về DDoS, mô hình, một số công cụ tấn công
DDoS
Chương 3. Phòng thủ DDoS.
Chương này làm rõ tại sao DDoS khó giải quyết đồng thời đưa ra một
vài giải pháp phòng thủ DDoS dựa trên phần mềm mã nguồn mở.
Chương 4. Cài đặt, thử nghiệm.
Cài đặt thử nghiệm những giải pháp đã nêu ra ở chương 3
8
Chương 2. Tổng quan về DDoS
2.1. Giới thiệu chung về DDoS
DDoS (distributed denial-of-service attack) là một kiểu tấn công đưa
một hệ thống cung cấp dịch vụ đến mức hoạt động tới hạn về tài nguyên,
hay gây nhầm lẫn logic dẫn đến hệ thống ngừng hoạt động .
Khác với DoS (denial-of-service attack) là chỉ cần một máy để tấn
công, DDoS sử dụng nhiều máy tính bị chiếm quyền điều khiển kết nối với
nhau (mạng Botnet) để tấn công nên sức hủy hoại là rất lớn.
2.2. Phân loại các kiểu tấn công DDoS
Nhìn chung, có rất nhiều cách để phân loại các kiểu tấn công DDoS
nhưng theo tôi cách phân loại theo mục đích tấn công là khá đầy đủ, đơn
giản và dễ hiểu. Dưới đây là sơ đồ mô tả sự phân loại các kiểu tấn công
DDoS dựa theo mục đích tấn công: làm cạn kiệt băng thông và làm cạn kiệt
tài nguyên hệ thống.
9
Hình 2.1 Phân loại các kiểu tấn công DDoS
2.2.1 Tấn công làm cạn kiệt băng thông
Tấn công làm cạn kiệt băng thông được thiết kế nhằm làm tràn ngập
mạng mục tiêu với những traffic không cần thiết, với mục địch làm giảm tối
thiểu khả năng của các traffic hợp lệ đến được hệ thống cung cấp dịch vụ
của mục tiêu.
Có hai loại tấn công làm cạn kiệt băng thông :
+ Flood attack: Điều khiển các Agent gửi một lượng lớn traffic đến hệ
thống dịch vụ của mục tiêu, làm dịch vụ này bị hết khả năng về băng thông.
+ Amplification attack: Điều khiển các Agent hay Client tự gửi packet
đến một địa chỉ IP broadcast, làm cho tất cả các máy trong subnet này gửi
packet đến hệ thống dịch vụ của mục tiêu. Phương pháp này làm gia tăng
traffic không cần thiết, làm suy giảm băng thông của mục tiêu.
2.2.1.1 Flood attack:
Trong phương pháp này, các Agent sẽ gửi một lượng lớn IP traffic
làm hệ thống dịch vụ của mục tiêu bị chậm lại, hệ thống bị treo hay đạt đến
10
trạng thái hoạt động bão hòa. Làm cho những người dùng thực sự của hệ
thống không sử dụng được dịch vụ.
Ta có thể chia Flood Attack thành hai loại:
+ UDP Flood Attack: do tính chất kết nối không cần bắt tay của
UDP, hệ thống nhận UDP message chỉ đơn giản nhận vào tất cả các packet
mình cần phải xử lý. Một lượng lớn các UDP packet được gửi đến hệ thống
dịch vụ của mục tiêu sẽ đẩy toàn bộ hệ thống đến ngưỡng tới hạn.
+ Các UDP packet này có thể được gửi đến nhiều port tùy ý hay chỉ
duy nhất một port. Thông thường là sẽ gửi đến nhiều port làm cho hệ thống
mục tiêu phải căng ra để xử lý phân hướng cho các packet này. Nếu port bị
tấn công không sẵn sàng thì hệ thống mục tiêu sẽ gửi ra một ICMP packet
loại “destination port unreachable”. Thông thường các Agent sẽ dùng địa chỉ
IP giả để che giấu hành tung, cho nên các packet trả về do không có port xử
lý sẽ dẫn đến một địa chỉ IP khác. UDP Flood attack cũng có thể làm ảnh
hưởng đến các kết nối xung quanh mục tiêu do sự hội tụ của packet diễn ra
rất mạnh.
+ ICMP Flood Attack: được thiết kế nhằm mục đích quản lý mạng
cũng như định vị thiết bị mạng. Khi các Agent gửi một lượng lớn
ICMP_ECHO_REPLY đến hệ thống mục tiêu thì hệ thống này phải reply
một lượng tương ứng Packet để trả lời, sẽ dẫn đến nghẽn đường truyền.
Tương tự trường hợp trên, địa chỉ IP của các Agent có thể bị giả mạo.
2.2.1.2 Amplification Attack:
Amplification Attack nhắm đến việc sử dụng các chức năng hỗ trợ địa
chỉ IP broadcast của các router nhằm khuyếch đại và hồi chuyển cuộc tấn
công. Chức năng này cho phép bên gửi chỉ định một địa chỉ IP broadcast cho
toàn subnet bên nhận thay vì nhiều địa chỉ. Router sẽ có nhiệm vụ gửi đến
tất cả địa chỉ IP trong subnet đó packet broadcast mà nó nhận được.
11
Attacker có thể gửi broadcast packet trực tiếp hay thông qua một số
Agent nhằm làm gia tăng cường độ của cuộc tấn công. Nếu attacker trực tiếp
gửi packet, thì có thể lợi dụng các hệ thống bên trong broadcast network như
một Agent.
Hình 2.2: Mô hình mạng Amplifier
Có thể chia amplification attack thành hai loại, Smuft va Fraggle
attack:
+ Smuft attack: trong kiểu tấn công này attacker gửi packet đến
network amplifier (router hay thiết bị mạng khác hỗ trợ broadcast), với địa
chỉ của nạn nhân. Thông thường những packet được dùng là ICMP ECHO
REQUEST, các packet này yêu cầu yêu cầu bên nhận phải trả lời bằng một
ICMP ECHO REPLY packet. Network amplifier sẽ gửi đến ICMP ECHO
Attacker/Agent VICTIM
Host
Host
Host
Host
Amplifie
r
Amplifier Network System
12
REQUEST packet đến tất cả các hệ thống thuộc địa chỉ broadcast và tất cả
các hệ thống này sẽ REPLY packet về địa chỉ IP của mục tiêu tấn công
Smuft Attack.
+ Fraggle Attack: tương tự như Smuft attack nhưng thay vì dùng
ICMP ECHO REQUEST packet thì sẽ dùng UDP ECHO packet gửi đến
mục tiêu. Thật ra còn một biến thể khác của Fraggle attack sẽ gửi đến UDP
ECHO packet đến chargen port (port 19/UNIX) của mục tiêu, với địa chỉ
bên gửi là echo port (port 7/UNIX) của mục tiêu, tạo nên một vòng lặp vô
hạn. Attacker phát động cuộc tấn công bằng một ECHO REQUEST với địa
chỉ bên nhận là một địa chỉ broadcast, toàn bộ hệ thống thuộc địa chỉ này lập
tức gửi REPLY đến port echo của nạn nhân, sau đó từ nạn nhân một ECHO
REPLY lại gửi trở về địa chỉ broadcast, quá trình cứ thế tiếp diễn. Đây chính
là nguyên nhân Flaggle Attack nguy hiểm hơn Smuft Attack rất nhiều.
+ DNS Amplification: Ta xem xét một truy vấn DNS như sau:
dig ANY isc.org @x.x.x.x
với x.x.x.x là IP của một máy chủ DNS
Ta sẽ nhận được trả lời từ máy chủ DNS như sau:
; <<>> DiG 9.7.3 <<>> ANY isc.org @x.x.x.x
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 5147
;; flags: qr rd ra; QUERY: 1, ANSWER: 27, AUTHORITY: 4, ADDITIONAL: 5
;; QUESTION SECTION:
;isc.org. IN ANY
;; ANSWER SECTION:
isc.org. 4084 IN SOA ns-int.isc.org. hostmaster.isc.org. 2012102700 7200 3600 24796800 3600
isc.org. 484 IN NSEC _kerberos.isc.org. A NS SOA MX TXT AAAA NAPTR
RRSIG NSEC DNSKEY SPF
isc.org. 4084 IN DNSKEY 256 3 5
BQEAAAAB2F1v2HWzCCE9vNsKfk0K8vd4EBwizNT9KO6WYXj0oxEL4eOJ
aXbax/BzPFx+3qO8B8pu8E/JjkWH0oaYz4guUyTVmT5Eelg44Vb1kssy
q8W27oQ+9qNiP8Jv6zdOj0uCB/N0fxfVL3371xbednFqoECfSFDZa6Hw jU1qzveSsW0=
13
isc.org. 4084 IN DNSKEY 257 3 5
BEAAAAOhHQDBrhQbtphgq2wQUpEQ5t4DtUHxoMVFu2hWLDMvoOMRXjGr
hhCeFvAZih7yJHf8ZGfW6hd38hXG/xylYCO6Krpbdojwx8YMXLA5/kA+
u50WIL8ZR1R6KTbsYVMf/Qx5RiNbPClw+vT+U8eXEJmO20jIS1ULgqy3
47cBB1zMnnz/4LJpA0da9CbKj3A254T515sNIMcwsB8/2+2E63/zZrQz
isc.org. 4084 IN NS ord.sns-pb.isc.org.
isc.org. 4084 IN NS sfba.sns-pb.isc.org.
;; AUTHORITY SECTION:
isc.org. 4084 IN NS ns.isc.afilias-nst.info.
isc.org. 4084 IN NS ams.sns-pb.isc.org.
isc.org. 4084 IN NS ord.sns-pb.isc.org.
isc.org. 4084 IN NS sfba.sns-pb.isc.org.
;; ADDITIONAL SECTION:
mx.ams1.isc.org. 484 IN A 199.6.1.65
mx.ams1.isc.org. 484 IN AAAA 2001:500:60::65
mx.pao1.isc.org. 484 IN A 149.20.64.53
mx.pao1.isc.org. 484 IN AAAA 2001:4f8:0:2::2b
_sip._udp.isc.org. 4084 IN SRV 0 1 5060 asterisk.isc.org.
;; Query time: 176 msec
;;SERVER: x.x.x.x#53(x.x.x.x)
;; WHEN: Tue Oct 30 01:14:32 2012
;; MSG SIZE rcvd: 3223
Hình 2.3 Trả lời truy vấn DNS
Gửi một truy vấn 64 bytes nhận được kết quả là 3223 bytes trả về, hay
nói cách khác, thông qua hệ thống DNS này, kẻ tấn công có thể tăng lưu
lượng tấn công lên 50 lần. Độ lớn của gói tin trả về phụ thuộc vào
DNSKEY, là giao thức được thiết kế để hệ thống DNS trở nên an toàn.
Một cách đơn giản, kẻ tấn công gửi các truy vấn DNS (sử dụng giao
thức UDP) đến một máy chủ DNS trên Internet nhưng dùng địa chỉ nạn nhân
giả mạo thành nguồn gốc của truy vấn đó.
Khi máy chủ DNS phản hồi trở lại (thường có kích thước gấp nhiều
lần truy vấn gửi đi), nạn nhân sẽ hứng chịu "phản hồi" đó. Hàng trăm ngàn
truy vấn sẽ liên tục gửi đến máy chủ DNS để "mượn tay" tấn công hệ thống
nạn nhân khiến hệ thống bị nghẽn do lưu lượng dữ liệu gửi đến quá lớn "như
một cơn lũ".
Hiện có 27 triệu máy chủ DNS trên mạng Internet và chúng có thể bị
tấn công để trở thành "vũ khí mạng" của tội phạm.
14
Ngày 28/3/2013, một nhóm tin tặc đã sử dụng phương pháp này tấn
công vào tổ chức chống thư rác Spamhaus, dữ liệu ước tính lên đến khoảng
300 gigabyte dữ liệu (GB)/giây, gấp 6 lần so với các cuộc tấn công DDoS
thông thường (vào khoảng 50 gigabyte dữ liệu/giây).
2.2.2 Tấn công làm cạn kiệt tài nguyên
Resource Deleption Attack là kiểu tấn công trong đó Attacker gửi
những packet dùng các protocol sai chức năng thiết kế, hay gửi những
packet với dụng ý làm tắt nghẽn tài nguyên mạng làm cho các tài nguyên
này không phục vụ những người dùng thông thường khác được.
2.2.2.1 Protocol Exploit Attack
+ TCP SYN Attack: Transfer Control Protocol (TCP) hỗ trợ truyền
nhận với độ tin cậy cao nên sử dụng phương thức bắt tay giữa bên gửi và
bên nhận trước khi truyền dữ liệu. Bước đầu tiên, bên gửi gửi một SYN
REQUEST packet (Synchronize). Bên nhận nếu nhận được SYN REQUEST
sẽ trả lời bằng SYN/ACK REPLY packet. Bước cuối cùng, bên gửi sẽ truyên
packet cuối cùng ACK và bắt đầu truyền dữ liệu.
Hình 2.4 Quá trình bắt tay ba bước
Nếu bên server đã trả lời một yêu cầu SYN bằng một SYN/ACK
REPLY nhưng không nhận được ACK packet cuối cùng sau một khoảng
TCP
Client
Client Port
1024-65535
TCP
Server
Service Port
1-1023
SYS
ACK
SYN/ACK
80
15
thời gian quy định thì nó sẽ resend lại SYN/ACK REPLY cho đến hết thời
gian timeout. Toàn bộ tài nguyên hệ thống “dự trữ” để xử lý phiên giao tiếp
nếu nhận được ACK packet cuối cùng sẽ bị “phong tỏa” cho đến hết thời
gian timeout.
Hình 2.5 Tấn công TCP SYN Attack
Nắm được điểm yếu này, attacker gửi một SYN packet đến nạn nhân
với địa chỉ bên gửi là giả mạo, kết quả là nạn nhân gửi SYN/ACK REPLY
đến một địa chỉ khá và sẽ không bao giờ nhận được ACK packet cuối cùng,
cho đến hết thời gian timeout nạn nhân mới nhận ra được điều này và giải
phóng các tài nguyên hệ thống. Tuy nhiên, nếu lượng SYN packet giả mạo
đến với số lượng nhiều và dồn dập, hệ thống của nạn nhân có thể bị hết tài
nguyên.
+ PUSH Attack: Trong TCP protocol, các packet được chứa trong
buffer, khi buffer đầy thì các packet này sẽ được chuyển đến nơi cần thiết.
Tuy nhiên, bên gửi có thể yêu cầu hệ thống unload buffer trước khi buffer
đầy bằng cách gửi một packet với PUSH và ACK mang giá trị là 1. Những
packet này làm cho hệ thống của nạn nhân unload tất cả dữ liệu trong TCP
buffer ngay lập tức và gửi một ACK packet trở về khi thực hiện xong điều
Malicious
TCP
Client
Victim
TCP
Server
SYS/ACK
SYN
80
?
16
này, nếu quá trình được diễn ra liên tục với nhiều Agent, hệ thống sẽ không
thể xử lý được lượng lớn packet gửi đến và sẽ bị treo.
2.2.2.2 Malformed Packet Attack
Malformed Packet Attack là cách tấn công dùng các Agent để gửi các
packet có cấu trúc không đúng chuẩn nhằm làm cho hệ thống của nạn nhân
bị treo.
Có hai loại Malformed Packet Attack:
+ IP address attack: dùng packet có địa chỉ gửi và nhận giống nhau
làm cho hệ điều hành của nạn nhân không xử lý nổi và bị treo.
+ IP packet options attack ngẫu nhiên hóa vùng OPTION trong IP
packet và thiết lập tất cả các bit QoS lên 1, điều này làm cho hệ thống của
nạn nhân phải tốn thời gian phân tích, nếu sử dụng số lượng lớn Agent có
thể làm hệ thống nạn nhân hết khả năng xử lý.
17
2.3. Sơ đồ mạng Botnet
2.3.1 Sơ đồ Handler-Agent
Hình 2.6 :Sơ đồ mạng Botnet
Botnet là một mạng gồm từ hàng trăm tới hàng triệu máy tính bị điều
khiển hoàn toàn bởi hacker.
Mạng Botnet thông thường bao gồm 3 thành phần : Agent, Client và
Handler. Trong đó :
+ Client: Là phần mềm cơ sở để hacker điều khiển mọi hoạt động của
mạng Handler-Agent.
+ Handler: Là một phần mềm trung gian giữa Agent và Client.
+ Agent: Là một thành phần software thực hiện sự tấn công mục
tiêu,nhận điều khiển từ Client thông quan các Handler.
18
Attacker sẽ từ Client giao tiếp với Handler để xác định số lượng các Agent
đang online, điều chỉnh thời điểm tấn công và cập nhật các Agent. Tuỳ theo
cách attacker cấu hình mạng Botnet , các Agent sẽ chịu sự quản lý của một
hay nhiều Handler.
Thông thường Attacker sẽ đặt các Handler trên một Router hay Server
có lượng lưu thông lớn.Việc này nhằm làm cho các giao tiếp giữa Client,
Handler và Agent khó bị phát hiện.Các giao thức này thường diễn ra trên các
giao thức TCP,UDP, hay ICMP.Chủ nhân thực sự của các Agent thường
không biết họ bị lợi dụng trong các cuộc tấn công DDos, do họ không đủ
kiến thức hoặc các chương trình Backdoor Agent chỉ sử dụng rất ít tài
nguyên hệ thống làm cho hầu như không thể thấy ảnh hưởng gì đến hiệu
năng của hệ thống.
2.3.2 Sơ đồ IRC Base
Hình 2.7 Sơ đồ IRC Base
19
Internet Relay Chat(IRC) là một hệ thống online chat nhiều người.
IRC cho phép người sử dụng tạo một kết nối đến nhiều điểm khác với nhiều
người sử dụng khác nhau và chat thời gian thực. Kiến trúc cũ của IRC
network bao gồm nhiều IRC server trên khắp Internet, giao tiếp với nhau
trên nhiều kênh (channnel).IRC network cho phép user tao ba loại channel:
Public, Private và Secrect.Trong đó :
+ Public channel: Cho phép user của channel đó thấy IRC name và
nhận được message của mọi user khác trên cùng channel
+ Private channel: Được thiết kế để giao tiếp với các đối tượng cho
phép.Không cho phép các user không cùng channel thấy IRC name và
message trên channel. Tuy nhiên , nếu user ngoài channel dùng một số lệnh
channel locator thì có thể biết được sự tồn tại của private channel đó.
+ Secrect channel: Tương tự private channel nhưng không thể xác
định bằng channel locator.
Mạng IRC-based cũng tương tự như mạng Agent-Handler nhưng mô
hình này sử dụng các kênh giao tiếp IRC làm phương tiện giao tiếp giữa
Client và Agent(không sử dụng Handler).Sử dụng mô hình này, attacker còn
có thêm một số lợi thế khác như :
+ Các giao tiếp dưới dạng chat message làm cho việc phát hiện chúng
là vô cùng khó khăn.
+ Lưu thông IRC có thể di chuyển trên mạng với số lượng lớn mà
không bị nghi ngờ.
+ Không cần phải duy trì danh sách các Agent, hacker chỉ cần logon
vào IRC server là đã có thể nhận được report về trạng thái các Agent do các
channel gửi về.
+ Sau cùng: IRC cũng là một môi trường chia sẻ file tạo điều kiện
phát tán các Agent code lên nhiều máy khác.
20
2.4. Các phương pháp xây dựng tài nguyên tấn công
Có rất nhiều điểm chung của các công cụ DDoS attack. Có thể kể ra
một số điểm chung như: cách cài chương trình Agent, phương pháp giao tiếp
giữa các Attacker, Handler và Agent, điểm chung về loại hệ điều hành hỗ trợ
các công cụ này. Sơ đồ sau mô tả sự so sánh tương quan giữa các công cụ
tấn công DDoS này.
Hình 2.8 Các phương pháp xây dựng tài nguyên tấn công
2.4.1 Cách thức cài đặt DDoS Agent
Attacker có thể dùng phương pháp active và passive để cài đặt chương
trình Agent lên các máy khác nhằm thiết lập mạng tấn công kiểu Agent-
Handler hay IRC-based.
Các cách cài đặt sử dụng phương pháp active như:
+ Scaning: dùng các công cụ như Nmap, Nessus để tìm những sơ hở
trên các hệ thống đang online nhằm cài đặt chương trình Agent. Chú ý,
Nmap sẽ trả về những thông tin về một hệ thống đã được chỉ định bằng địa
21
chỉ IP, Nessus tìm kiếm từ những địa chỉ IP bất kỳ về một điểm yếu biết
trước nào đó.
+ Backdoor: sau khi tìm thấy được danh sách các hệ thống có thể lợi
dụng, attacker sẽ tiến hành xâm nhập và cài chương trình Agent lên các hệ
thống này. Có rất nhiều thông tin sẵn có về cách thức xâm nhập trên mạng,
như site của tổ chức Common Vulnerabilities and Exposures (CVE), ở đây
liệt kê và phân loại trên 4.000 loại lỗi của tất cả các hệ thống hiện có. Thông
tin này luôn sẵn sàng cho cả giới quản trị mạng lẫn hacker.
+ Trojan: là một chương trình thực hiện một chức năng thông thường
nào đó, nhưng lại có một số chức năng tiềm ẩn phục vụ cho mục đích riêng
của người viết mà người dùng không thể biết được. Có thể dùng trojan như
một chương trình Agent.
+ buffer Overflow(tràn bộ đệm): tận dụng lỗi buffer overflow,
attacker có thể làm cho chu trình thực thi chương trình thông thường bị
chuyển sang chu trình thực thi chương trình của hacker (nằm trong vùng dữ
liệu ghi đè). Có thể dùng cách này để tấn công vào một chương trình có
điểm yếu buffer overflow để chạy chương trình Agent.
Cách cài đặt passive:
+ Bug Website: attacker có thể lợi dụng một số lỗi của trình duyệt
web để cài chương trình Agent vào máy của người truy cập. Attacker sẽ tạo
một website mang nội dung tiềm ẩn những code và lệnh để đặt bẫy người
dùng. Khi người dùng truy cập nội dung của website, thì trang web tự động
tải và cài đặt chương trình Agent một cách bí mật. Microsoft Internet
Explorer thường là mục tiêu của cách cài đặt này, với các lỗi của ActiveX
có thể cho phép IE brower tự động download và cài đặt code trên máy của
người dùng duyệt web.
22
+ Corrupted file: một phương pháp khác là nhúng code vào trong các
file thông thường. Khi người đọc hay thực thi các file này, máy của họ lập
tức bị nhiễm chương trình Agent software. Một trong những kỹ thuật phổ
biến là đặt tên file rất dài, do mặc định của các hệ điều hành chỉ hiển thị
phần đầu của tên file nên attacker có thể gửi kèm theo email cho nạn nhân
file như sau: iloveyou.txt_hiiiiiii_NO_this_is_DDoS.exe, do chỉ thấy phần
“Iloveyou.txt” hiển thị nên user sẽ mở file này để đọc và lập tức file này
được thực thi và Agent code được cài vào máy nạn nhân. Ngoài ra còn nhiều
cách khác như ngụy trang file, ghép file…
2.4.2. Giao tiếp trên mạng Botnet
Protocol: giao tiếp trên mạng Botnetcó thể thực hiện trên nền các
protocol TCP, UDP, ICMP.
Mã hóa các giao tiếp: một vài công cụ DDoS hỗ trợ mã hóa giao tiếp
trên toàn bộ mạng botnet. Tùy theo giao thức được sử dụng để giao tiếp sẽ
có các phương pháp mã hóa thích hợp. Nếu mạng Botnet ở dạng IRC-based
thì private và secrect channel đã hỗ trợ mã hóa giao tiếp.
Cách kích hoạt Agent: có hai phương pháp chủ yếu để kích hoạt
Agent. Cách thứ nhất là Agent sẽ thường xuyên quét thăm dò Handler hay
IRC channel để nhận chỉ thị (active Agent). Cách thứ hai là Agent chỉ đơn
giản là “nằm vùng” chờ chỉ thị từ Handler hay IRC Channel.
2.5. Một số kiểu tấn công DDoS và các công cụ tấn
công DDoS
2.5.1 Một số kiểu tấn công DDoS
- HTTP Flood
- SYN Flood
- ICMP Flood
23
- SSH Process Table
- TCP Reset
- UDP Flood
2.5.2 Một số công cụ tấn công DDoS
2.5.2.1 Trinoo
Trinoo là một công cụ tấn công từ chối dịch vụ bằng kĩ thuật UDP
Flood được kết hợp từ nhiều nguồn.
Một cuộc tấn công DDoS bằng Trinoo được thực hiện bởi kết nối của
attacker đến Một hay nhiều Trinoo Master và chỉ dẫn cho Master phát động
tấn công DDoS đến một hoặc nhiều mục tiêu. Master sẽ liên lạc với các
daemons để ra lệnh cho các daemons gửi các UDP packet đến mục tiêu.
Mô hình :
attacker(s)-->Master(s)-->daemon(s)-->victim(s)
Attacker -----> Master : port 27665/TCP
Master -----> Deamons : port 27444/UDP
Daemon ------> Master : port 31335/UDP
Deamon -----> UDP Flood đến mục tiêu (random port) .
2.5.2.2 Tribe Flood Network (TFN/TFN2K)
Tương tự như Trinoo nhưng Tribe Flood Network còn cho phép
attacker sử dụng thêm ICMP flood, SYN flood, và Smurf .
Mô hình :
attacker(s)-->client(s)-->daemon(s)-->victim(s)
2.5.2.3 Stacheldraht
Stacheldraht là sự kết hợp các tính năng của Trinoo và TFN, bên cạnh
đó còn thêm khả năng mã hóa giao tiếp giữa attacker và stacheldraht
masters.
24
Stacheldraht cung cấp cho attacker khá nhiều phương thức tấn công từ
chối dịch vụ : ICMP flood, SYN flood, UDP flood, và Smurf .
Mô hình :
client(s)-->handler(s)-->agent(s)-->victim(s)
Client ---> handler(s) : port 16660/tcp
Handler <----> agent(s): port 65000/tcp,
ICMP_ECHOREPLY
2.5.2.4 Trinity
Trinity có hầu hết các kỹ thuật tấn công bao gồm: UDP, TCP SYS,
TCP ACK, TCP fragment, TCP NULL, TCP RST, TCP random flag, TCP
ESTABLISHED packet flood. Nó có sẵn khả năng ngẫu nhiên hóa địa chỉ
bên gởi. Trinity cũng hỗ trợ TCP flood packet với khả năng ngẫu nhiên tập
CONTROL FLAG. Trinity có thể nói là một trong số các công cụ DDoS
nguy hiểm nhất.
2.5.2.5 Shaft
Shaft có các kĩ thuật tấn công UDP, ICMP và TCP flood. Có thể tấn
công phối hợp nhiều kiểu cùng lúc. Có thống kê chi tiết cho phép attacker
biết tình trạng tổn thất của nạn nhân, mức độ quy mô của cuộc tấn công để
điều chỉnh số lượng Agent.
Mô hình :
client(s)-->handler(s)-->agent(s)-->victim(s)
Client ----> handler(s): port 20432/tcp
Handler ---> agent(s): port 18753/udp
Agent ---> handler(s): port 20433/udp
25
2.5.2.6 X-Flash
Vấn đề then chốt của hacker tấn công bằng hình thái cổ điển là nắm
quyền điều khiển càng nhiều máy tính càng tốt, sau đó anh ta sẽ trực tiếp
phát động tấn công hàng loạt từ xa thông qua một kênh điều khiển. Với quy
mô mạng lưới tấn công bao gồm vài trăm nghìn máy, hình thái này có thể
đánh gục ngay lập tức bất cứ hệ thống nào. Phối hợp với khả năng giả mạo
địa chỉ IP, kiểu tấn công này sẽ rất khó lần theo dấu vết.
Hình 2.9 Mô hình tấn công DDoS thông thường
Mô hình này có một số nhược điểm:
- Mạng lưới tấn công là cố định và tấn công xảy ra đồng loạt nên rất
dễ điều tra ngược tìm manh mối.
26
- Software cài lên các Infected Agent là giống nhau và có thể dùng
làm bằng chứng kết tội hacker.
- Phía nạn nhân có thể điều chỉnh hệ thống phòng vệ để ngăn chặn vì
mạng lưới tấn công là “khả kiến”.
- Hacker buộc phải trực tiếp kết nối đến mạng lưới các máy tấn công
tại thời điểm tấn công để điều khiển nên rất dễ lần ra thủ phạm.
X-Flash xuất hiện sau khi DantruongX và nhóm BeYeu phát hiện ra
những lỗ hổng bảo mật của IE và Flash. Nó chỉ bằng cách đơn giản là gửi
yêu cầu tới web server dạng HTTP Request ( yêu cầu dạng POST hay GET)
với một tốc độ cực kì nhanh khiến web serivces bị treo.
Cách tấn công : Hacker treo một file flash trên một website trung gian
có nhiều người truy xuất, người dùng truy xuất website này file flash sẽ
được tải về máy và được chương trình Flash thực thi. Từ đây vô số các yêu
cầu truy xuất sẽ gởi đến website mục tiêu.
27
Hình 2.10 Mô hình tấn công X-Flash
Flash DDOS có một số đặc tính khiến cho việc ngăn chặn và phát hiện
gần như là không thể.Do mạng lưới tấn công phức tạp và tự hình thành :
+ Không cần thiết phải nắm quyền điều khiển và cài DDOS software
vào các infected agent. Thay vào đó mọi user với một trình duyệt có hỗ trợ
nội dung Flash (có Flash player) sẽ trở thành công cụ tấn công.
+ Số lượng attack agent tùy thuộc vào số lượng user truy xuất các
website đã bị hacker “nhúng” nội dung flash, số lượng này thay đổi theo thời
gian và hoàn toàn không thể nhận biết địa chỉ IP nguồn, vì đây là các user
thông thường.
+ Không hề có quá trình gởi lệnh và nhận báo cáo giữa hacker và
mạng lưới tấn công, toàn bộ lệnh tấn công được “nhúng” trong nội dung
28
flash và hacker không cần nhận báo cáo do đây là mô hình tấn công bất đồng
bộ.
+ Tấn công bất đồng bộ: việc tấn công diễn ra không cần có mệnh
lệnh. User truy xuất website, load nội dung flash về trình duyệt và Flash
player thực thi nội dung flash thì ngay lập tức máy của họ trở thành một
attack agent-liên tục gởi hàng trăm request đến webserver nạn nhân.
+ Quy mô tấn công phụ thuộc vào số lượng website bị lợi dụng và số
lượng user thường xuyên truy xuất các website này. Chỉ tính trung bình
hacker lợi dung được 10 website và mỗi website này có số lượng truy xuất
khoảng 100 user tại một thời điểm thì tổng số request mà server nạn nhân
phải hứng chịu tại một thời điểm lên đến con số vài chục ngàn. Đây là một
số liệu kinh hoàng với bất kỳ ai làm quản tri hệ thống của bất cứ website nào
và kết quả thường là hệ thống tê liệt ngay lập tức.
Tuy nhiên, hiện nay chương trình Flash player mới nhất đã được vá
lỗi, cách tấn công Flash hầu như không còn được sử dụng.
29
Chương 3. Phòng thủ DDoS
3.1 Tại sao DDoS khó giải quyết
Thực hiện tấn công DDoS có 2 trường phái chính: đó là nhằm vào
điểm yếu (vulnerability attack) và làm ngập mạng (flooding attack). Do có 1
số đặc tính về kĩ thuật như sau làm ta rất khó giải quyết được triệt để các
cuộc tấn công DDoS:
- Sự đơn giản: Một người bình thường không rành về mạng cung có
thể thực hiện 1 cuộc tấn công từ chối dịch vụ. Bởi vì đã có sẵn rất nhiều
công cụ DDoS trên mạng và cả hướng dẫn sử dụng đầy đủ từ a-z để thực
hiện.
- Sự đa dạng của các gói tin tấn công: Sự giống nhau giữa các traffic
tấn công và các traffic hợp lệ làm quản trị viên khó có thể phân biệt được.
Khác với các nguy cơ bảo mật như virut, worm, adware… cần phải có
những gói tin mánh khóe, mẹo mực lợi dụng vào lỗ hổng, nhưng flood
attack chỉ cần lưu lượng lớn traffic và header cũng như nội dung packet đều
có thể tùy ý theo Attacker
- IP spoofing: Sự giả mạo IP làm cho các traffic attack từ agents đến
như là từ những người dùng hợp lệ. Vì thế quản trị viên rất khó phân biệt để
có thể từ chối phục vụ những request tấn công.
- Lượng traffic lớn, gửi với tần suất cao: Lượng traffic khổng lồ mà
DDoS tạo ra không chỉ làm ngập tài nguyên của Victim, mà còn làm quản trị
viên rất khó mô tả, phân tích và tách biệt được packet hợp lệ và packet tấn
công chúng.
- Số lượng lớn các Agents: Một trong những điểm mạnh của tấn công
DDoS là có thể huy động được 1 số lượng lớn Agent phân tán trên toàn
Internet. Khi đó, luồng tấn công sẽ lan tỏa trên nhiều nhánh tới Victim, điểm
tụ tấn công sẽ gần sát nạn nhân, và hệ thống phòng thủ sẽ rất khó có thể
chống từ phía xa. Ngoài ra, hệ thống Agent phân tán cũng đồng nghĩa với sự
phức tạp, phong phú, khác biệt về mô hình quản lý mạng giữa các ISP khác
nhau, vì thế các cơ cơ chế phòng thủ yêu cầu sự phối hợp từ nhiều nơi sẽ
triển khai khó khăn hơn rất nhiều.
30
- Những điểm yếu trên mô hình mạng Internet: Có những cơ chế, giao
thức mạng mà khi thiết kế người ta chưa lường trước được những điểm yếu
có thể bị lợi dụng (ví dụ TCP SYN, ping of Death, LAND Attack…). Đôi
khi là lỗi của nhà quản trị khi cấu hình các policy mạng chưa hợp lý.
3.2 Những thách thức khi xây dựng hệ thống phòng thủ DDoS
Do những tính chất phức tạp của DDoS như đã trình bày ở trên, nên
xây dựng 1 hệ thống phòng thủ DDoS là không đơn giản. Để làm được điều
đó cần xử lý được cả trên 2 lĩnh vực: kĩ thuật và xã hội.
3.2.1 Những thách thức về mặt kĩ thuật
Cần sự xử lý phân tán từ nhiều điểm trên Internet: Vì attack
traffic xảy ra từ nhiều nguồn khác nhau, đi qua toàn mạng Internet trong khi
thường chỉ có một mình Victim với ít thiết bị, quyền hạn, khả năng xử lý
hạn chế nên không thể đạt được hiệu quả cao. Sự tấn công phân tán thì cần
sự phòng thủ phân tán thì mới giải quyết triệt để được.
Thiếu thông tin chi tiết về các cuộc tấn công thực tế: Có không
nhiều thông tin về tác hại của DDoS gây lên cho các doanh nghiệp, nó
thường chỉ có khi tác hại của nó là rõ ràng và doanh nghiệp không thể tự xử
lý được mà phải báo lên chính quyền. Vì thế lại càng ít các thông tin chi tiết,
như là bản log các traffic, sơ đồ mạng chi tiết của doanh nghiệp.
Khó thử nghiệm trên thực tế: Những hệ thống thử nghiệm DDoS ở
phòng thí nghiệm không thể phản ánh đúng thực tế rộng lớn, phong phú trên
mạng Internet được. Trong khi đó nếu muốn triển khai để thử nghiệm thật
qua Internet thì các điều luật không cho phép, vì tấn công DDoS không chỉ
ảnh hưởng đến Victim, mà còn liên quan đến rất nhiều các thành phần khác
như router, switch… của ISP quản lý ở phần lõi Mạng. Còn nếu thử nghiệm
luôn trên 1 hệ thống thật đang bị tấn công thì lại thiếu thông tin cần đo đạc ở
Agent, Handler, Attacker…
Chưa có chuẩn đánh giá các hệ thống phòng thủ: Có nhiều vendor
đã công bố rằng giải pháp của họ có thể giải quết được DDoS. Nhưng hiện
tại chưa có 1 lộ trình chuẩn nào để kiểm thử các hệ thống phòng thủ DDoS.
Từ đó dẫn đến 2 vấn đề: thứ nhất là những người phát triển hệ thống phòng
thủ tự test chính họ, do đó những thiết kế sẽ luôn phù hợp nhất để hệ thống
31
đó hoạt động thuận lợi. Thứ hai là những nghiên cứu về DDoS không thể so
sánh hiệu suất thực tế của các hệ thống phòng thủ khác nhau, thay vào đó,
họ chỉ có thể nhận xét về từng giải pháp trên môi trường thử nghiệm mà
thôi.
3.2.2 Những thách thức về mặt xã hội
Một thử thách lớn khi muốn giải quyết triệt để vấn nạn tấn công
DDoS là về yếu tố Xã hội. Có rất nhiều điều luật về an ninh, bảo mật của
nhiều đất nước, nhiều ISP khác nhau mà người triển khai khó có thể thỏa
mãn tất cả để thực hiện hệ thống phòng thủ của mình. Ví dụ ISP không cho
bạn sơ đồ chi tiết cấu hình Mạng, không cho phép bạn tự do cài đặt chương
trình trên các router của họ… Đối với các nạn nhân của DDoS, thông thường
là các doanh nghiệp, thì việc đầu tiên là họ sẽ cố gắng tự mình giải quyết,
nếu thành công thì sẽ giấu kín, không công bố cho bên ngoài là mình đang bị
tấn công vì lo ngại ảnh hưởng đến danh tiếng của công ty. Chỉ khi nào dịch
vụ của họ bị chết hẳn, không thể tự cứu thì mới liên hệ với các ISP và chính
quyền.
Một vấn đề khác là đôi khi cần phải sửa đổi một số điểm yếu của các
kiến trúc mạng để giảm tác hại của DDoS, ví dụ như giao thức TCP, IP,
HTTP… Nhưng không dễ làm được điều đó, vì hiện tại đã có rất nhiều hệ
thống xây dựng trên nền tảng cũ, và không thể ngày thay đổi trong ngày một
ngày hai được.
Có một đặc điểm của DDoS là khi Victim bị tấn công, thì nếu muốn
triệt để không còn traffic DDoS nữa, thì phải làm sao yêu hàng nghìn Agent
ngừng tấn công. Chỉ có 1 cách làm được điều này là tại các Agent phải cài
đặt 1 phần mềm, hay hệ thống để ngăn chặn gói tin DDoS ngay khi vừa sinh
ra. Nhưng không dễ thuyết phục được các End User làm điều đó, vì nó
không mang lại lợi ích trực tiếp gì cho bản thân họ, đôi khi còn làm ảnh
hưởng đến hiệu năng mạng của End User.
Yếu tố cuối cùng là thiếu sự thống nhất về các điều luật, chế tài xử phạt
các Attacker, Handler, Agents giữa các bộ luật về Công nghệ thông tin của
các nước và giữa các quy định về bảo mật, an toàn của các Internet Service
Provider.
3.2.3 Mục tiêu khi xây dựng hệ thống phòng thủ
32
Cho dù triển khai hệ thống phòng thủ theo cách thức nào thì cuối cùng
cũng phải hướng tới 4 mục tiêu chính như sau:
Tính hiệu quả: yêu cầu các thành phần tham gia vào hệ thống phòng
thủ: victim, router… đều không phải chịu thêm tải quá nặng. Ví dụ khi bình
thường CPU Usage của Server chỉ chạy 10% để phục vụ cho các Client,
nhưng sau khi cài đặt hệ thống phòng thủ vào, cho dù chưa xảy ra DDoS thì
CPU Usage do phải tính toán thêm nhiều nên đã lên đến 20% là không chấp
nhận được.
Tính trọn vẹn: Một hệ thống phòng thủ tốt cần phải bảo vệ Victim
được khỏi tất cả các kiểu tấn công DDoS. Bởi vì đối với Attacker, một khi
đã điều khiển được mạng botnet thì hắn hoàn toàn có thể sử dụng nhiều kịch
bản tấn công khác nhau, lợi dụng nhiều điểm yếu của giao thức, của mạng
hoặc thay đổi thông số bên trong packet. Vì thế nếu hệ thống chỉ có thể
phòng thủ được 1 số cách tấn công nhất định, thì khi attacker thay đổi, hệ
thống đó sẽ sụp đổ hoàn toàn.
Cung cấp dịch vụ cho tất cả các traffic hợp lệ: đây là yêu cầu quan
trọng nhất khi triển khai một hệ thống phòng thủ DDoS.
Chi phí phát triển và điều hành thấp
3.2.4 Các hướng phòng thủ DDoS
Có thể phân loại các phương pháp giải quyết DDoS theo hai tiêu chí
là thời gian và vị trí. Xét theo thời gian, có hai xu hướng: trước (phòng
ngừa) và sau (phản ứng lại khi cuộc tấn công xảy ra). Xét theo vị trí đặt
trung tâm điều khiển việc xử lý phòng chống DDoS, thì có các vị trí: gần
Victim, gần Attacker, trong phần lõi của Internet hoặc kết hợp nhiều vị trí..
3.2.4.1 Phòng ngừa và phản ứng lại
Phương pháp phòng ngừa áp dụng các chính sách để kẻ tấn công
không thể hoặc khó tấn công hệ thống. Phương pháp này có thể được thực
hiện bằng cách tăng cường sức mạnh của hệ thống: năng lực xử lý các yêu
cầu dịch vụ, băng thông… để giảm thiểu tối đa tác hại của cuộc tấn công
DDoS. Nhưng do mạng lưới tấn công có đặc điểm phân tán, là tập trung của
nhiều máy tính cấu hình trung bình nên dễ tập hợp được số lượng lớn để hội
33
tụ thành một lượng băng thông gấp nhiều lần so với hệ thống của victim. Vì
vậy việc tăng cường sức mạnh không thực sự có hiệu quả.
Phương pháp phản ứng lại chấp nhận cho cuộc tấn công xảy ra, sau đó
truy tìm và tiêu diệt các hướng tấn công, làm giảm thiểu rủi ro hoặc chấm
dứt cuộc tấn công. Bằng cách phát hiện chính xác kẻ tấn công, nạn nhân sẽ
có chính sách cấm những truy nhập, từ đó giảm thiểu được tác hại của cuộc
tấn công. Phương pháp này hiện là hướng nghiên cứu chính trong việc giải
quyết DDoS.
Nhược điểm chung của phương pháp phản ứng lại là việc giải quyết
không triệt để và không chủ động. Nạn nhân bị tấn công đã phải hứng chịu
các hậu quả. Biện pháp này chỉ giúp chấm dứt hậu quả sớm và giảm thiểu
thiệt hại.
3.2.4.2 Vị trí của hệ thống phòng thủ
Phương pháp đặt gần victim là phương pháp đơn giản nhất do ít phụ
thuộc vào các tác nhân khác, nạn nhân tự giải quyết vấn đề. Phương pháp
này thường dùng để phản ứng lại sau khi nạn nhân phát hiện bị tấn công.
Tuy nhiên cách tiếp cận này không thể giải quyết tận gốc, quản trị viên chỉ
có thể giảm thiểu thiệt hại chứ không thể chấm dứt cuộc tấn công.
34
Hình 3.1 Phương pháp đặt gần victim
Phương pháp đặt gần attacker là phương pháp ngăn chặn các gói tin
DDoS ngay khi vừa được sinh ra tại nguồn. Nó có ưu điểm là giảm được tối
đa tác hại của gói tin DDoS, chống được giả mạo IP. Tuy nhiên lại rất khó
thực hiện do phải thay đổi hệ thống mạng trên quy mô lớn. Hiện mới chỉ có
khoảng ba hướng nghiên cứu theo cách tiếp cận này. Trong đó, D-WARD là
có kết quả tốt nhất với khả năng hoạt động độc lập.
35
Hình 3.2 Phương pháp đặt gần attacker
Một vị trí khác là đặt tại phần lõi của Internet. Cách tiếp cận này ít
được quan tâm rộng rãi do để tiếp cận được phần lõi của Internet cần có một
khoản chi phí không nhỏ, cũng như sự đảm bảo chắc chắn về tính hiệu quả
đem lại khi tăng sự phức tạp của phần lõi.
36
Hình 3.3 Phương pháp đặt tại phần lõi của Internet
Phương pháp cuối cùng và hay được nghiên cứu hiện nay là phương
pháp kết hợp nhiều vị trí: nạn nhân phát hiện và bắt đầu xử lý, sau đó cố
gắng đẩy vị trí phòng chống ra hệ thống mạng gần kẻ tấn công nhất có thể,
từ đó giúp giảm tải cho toàn mạng Internet chứ không chỉ cho Victim nữa.
37
Hình 3.4 Phương pháp kết hợp nhiều vị trí
3.3. Một số giải pháp phòng thủ DDoS
Hiện nay, giải pháp phòng thủ DDoS có nhiều, có cả phần cứng và
phần mềm, tuy nhiên trong quá trình nghiên cứu tìm hiểu, tôi đề xuất một số
giải pháp sử dụng các phần mềm mã nguồn mở. Ưu điểm của các phương
pháp này là giá thành rẻ, dễ triển khai và bảo trì.
3.3.1. Giải pháp dành cho doanh nghiệp cung cấp Hosting
Với việc có nhiều trang web trên một máy chủ, doanh nghiệp cung
cấp hosting thường xuyên phải giải quyết việc làm sao để khi một trang web
bị DDoS thì không ảnh hưởng đến các trang web khác cùng nằm trên máy
chủ. Giải pháp hiện nay một số doanh nghiệp cung cấp hosting tại Việt Nam
đã triển khai và rất thành công đó là kết hợp Litespeed, Cloudlinux và
firewall CSF.
3.3.2. Giải pháp sử dụng IPS để lọc gói tin
Phương pháp này sử dụng một máy chủ làm gateway, trên máy chủ
này cài CSF để cản lọc gói tin từ tầng mạng và Snort inline để lọc gói tin
tầng ứng dụng, các gói tin nào hợp lệ sẽ được gửi đến máy chủ phục vụ nằm
phía sau.
38
Snort inline nhận các gói tin từ iptables (không như Snort lấy các gói
tin từ libpcap) sau đó dựa vào các luật đã được định nghĩa để quyết định cấm
hay cho phép gói tin đi qua.
Hình 3.5 Mô hình sử dụng IPS để lọc gói tin
3.3.3. GeoIP DNS
Sử dụng GeoIPDNS ta có thể phân loại người dùng dựa trên vị trí địa
lý, từ đó có thể quy định máy chủ phục vụ một vùng địa lý xác định. Ví dụ:
người dùng thuộc khu vực Hà Nội (dải IP thuộc khu vực Hà Nội) sẽ được
máy chủ HN phục vụ và người dùng thuộc khu vực Hồ Chí Minh sẽ được
máy chủ HCM phục vụ. Nhờ việc phân loại vị trí địa lý, máy chủ sẽ chỉ phục
vụ các IP trong khu vực địa lý nhất định, hạn chế được tình trạng mạng
botnet lớn ở nhiều khu vực địa lý khác nhau tập trung tấn công một máy chủ.
Hiện nay trang web 24h.com.vn đang triển khai theo phương pháp này.
39
Hình 3.6 Mô hình sử dụng GeoIP DNS
3.3.4. HAProxy
HAProxy là một giải pháp cân bằng tải với khả năng mở rộng cao,
được cài đặt cho những website chạy các ứng dụng dựa trên TCP và HTTP.
HAProxy là một giải pháp mã nguồn mở được phát triển trên hệ điều hành
Linux. Trong phiên bản mới nhất, HAProxy hỗ trợ chuyển mạch ngữ cảnh
cho phép người quản trị website có thể thiết đặt các luật của chuyển mạch
trong file cấu hình. Bên cạnh đó, HAProxy còn có số lượng thuật toán phân
tải phong phú, khả năng ngăn chặn các cổng không cần thiết theo nhu cầu
của người quản trị, hỗ trợ các phương pháp cài đặt cookie và khả năng hoạt
động trong suốt giúp tăng tốc độ truyền dẫn dữ liệu.
Có thể kể ra rất nhiều website sử dụng HAProxy như redwall Firewall
(http://www.redwall-firewall.com), Exceliance’s ALOHA Appliance
(http://www.exceliance.fr/en/), http://www.loadbalancer.org, Amazon EC2
(http://aws.amazon.com/ec2/), hay tamtay.vn.
40
Hình 3.7 Mô hình sử dụng HAproxy và Keepalived
Máy chủ HAProxy khi nhận được yêu cầu sẽ căn cứ vào trọng số để
phân chia tải cho 4 máy chủ web.
Mô hình trên còn sử dụng Keepalived để đảm bảo tính sẵn sàng cao
của 2 máy chủ cài HAProxy. Khi sử dụng Keepalived, một máy chủ chạy
HAProxy sẽ ở trạng thái sẵn sàng (active) và máy chủ còn lại sẽ ở trạng thái
chờ (stanby), nếu máy chủ active không hoạt động, máy chủ stanby sẽ
chuyển sang trạng thái active.
41
Chương 4. Cài đặt, thử nghiệm
4.1. Giải pháp dành cho doanh nghiệp cung cấp Hosting
4.1.1. Litespeed
Litespeed (LSWS) một nền tảng Webserver tốt nhất hiện nay thay thế
cho Webserver Apache đã cũ. Litespeed hoạt động một cách mạnh mẽ, hiệu
quả và linh hoạt hơn. Tuy là một phiên bản webserver trả phí khá đắt đỏ so
với Apache miễn phí nhưng trên thị trường Litespeed vẫn chứng tỏ được uy
tín và chất lượng của mình. Một số ưu điểm của Litespeed:
- Tốc độ xử lý file tĩnh của Litespeed có thể nhanh Apache 6 lần.
- Tốc độ xử lý mod_php nhanh hơn đến 50% và nhanh hơn gấp vài lần
với suphp và phpsuexec.
- Hỗ trợ rewrite hiệu quả hơn so với mod_rewrite của Apache do được
viết lại.
- Đưa ra giải pháp bảo mật tốt nhất với PHP suEXEC
- Litespeed hoạt động tốt trên các Hosting Control Panel như: cPanel,
DirectAdmin, Plesk, ISPConfig, H-Sphere, LinuxAdmin và các Control
Panel khác.
- Sử dụng tài nguyên máy chủ linh hoạt và tiết kiệm.
Dưới đây là bản so sánh hiệu năng thực tế giữa hai máy chủ chạy
apache và litespeed có cấu hình như sau: Ram 24G, Cpu 2xE5620 (intel
Xeon quard core 2,4Ghz, 12Mb cache), hiện tại cả hai máy chủ đều có hơn
800 vhost, khoảng 2500 kết nối đồng thời
42
Hình 4.1 Máy chủ chạy apache
43
Hình 4.2 Máy chủ chạy litespeed
Có thể thấy tuy có cùng cấu hình, số lượng truy cập cũng tương
đương nhưng máy chủ chạy Litespeed có load average (tải trung bình) chỉ
bằng 1/3 so với máy chủ chạy apache.
4.1.2 CloudLinux
4.1.2.1 Giới thiệu chung
Cloud Linux là hệ điều hành *Nix đầu tiên, được thiết kế dành riêng
cho nhu cầu lưu trữ web, đặc biệt là phục vụ nhu cầu của các nhà cung cấp
Hosting (Hosting Provider). Cloud Linux sử dụng công nghệ LVE
(Lightweight Virtual Environments - Môi trường ảo hóa) tạo nên sự đột phá
trong việc quản lý, chia sẻ tài nguyên máy chủ cho các tài khoản người
dùng.
Trong trường hợp một số tài khoản hosting có hiện tượng bị tấn công
từ chối dịch vụ (DDOS) hoặc việc mã nguồn chiếm quá nhiều tài nguyên để
xử lý có thể gây ảnh hưởng đến hoạt động của máy chủ thì công nghệ LVE
sẽ giúp hạn chế những tài khoản có chiều hướng gây quá tải, làm giảm thiểu
khả năng gây ảnh hưởng đến sự vận hành chung của hệ thống mà vẫn đảm
bảo hoạt động ổn định thông suốt cho các khách hàng khác trên cùng hệ
thống máy chủ.
44
Hình 4.3 Mô hình hosting chia sẻ truyền thống
Hình 4.4 Mô hình LVE của CloudLinux OS
4.1.2.2 Các thông số cấu hình
Cấu hình Cloudlinux khá đơn giản, chỉ có một vài các thông số như
sau:
- CPU usage: Phần trăm CPU được dùng
- Number of cores for LVE: Số core CPU được dùng
- Virtual Memory: Bộ nhớ ảo được dùng
- Physical memory: Bộ nhớ vật lý được dùng
- Concurrent Connecion (Entry Process): Số process PHP được phép
chạy đồng thời.
- I/O limit: tốc độ đọc ghi tối đa ổ cứng.
45
Hình 4.5: Các thông số cấu hình CloudLinux
4.1.3 ConfigServer Security & Firewall (CSF)
4.1.3.1 Giới thiệu chung
CSF là 1 gói ứng dụng hoạt động trên Linux như là một tường lửa
miễn phí dùng để tăng tính bảo mật cho máy chủ. CSF hoạt động dựa trên
iptables và Login Failure Daemon (ldf) để quyét các file log để phát hiện các
dấu hiệu tấn công bất thường. Một số tính năng của CSF:
- Chống DoS các loại
- Chống Scan Port
- Chống BruteForce Attack
- Chống Syn Flood
- Chống Ping Flood
- Cho phép ngăn chặn truy cập từ 1 quốc gia nào đó bằng cách chỉ định
Country Code chuẩn ISO
- Hỗ trợ IPv6 và IPv4
- Cho phép khóa IP tạm thời và vĩnh viễn ở tầng mạng
4.1.3.2 Các thông số cấu hình CSF
File cấu hình của CSF nằm ở /etc/csf/csf.conf, một số tham số quan
trọng trong file cấu hình CSF là:
- TESTING = "0" : Mặc định khi vừa cài TESTING = "1", với
TESTING = "1" thì LFD daemon (Login Fail Detect daemon) sẽ không hoạt
động, do đó nếu có gì sai sót thì server cũng sẽ không block IP của bạn. Khi
cảm thấy cấu hình đã ổn thì tắt TESTING để LFD bắt đầu hoạt động và chặn
các IP tấn công.
- TESTING_INTERVAL = "5": Thời gian chạy cronjob để clear
iptables nếu như TESTING=1 , tính bằng phút.
46
- AUTO_UPDATES = "1": Bật tự động cập nhật CSF
- TCP_IN = "22,25,53,80,443": Cho phép gói tin TCP đến các
cổng 22 ,25 ,52 ,80 ,443.
- TCP_OUT = "25,80": Cho phép các gói tin TCP đi đến cổng
25,80 của hệ thống khác.
- UDP_IN = "53" : Cho phép các gói tin UDP đến cổng 53
- UDP_OUT = "53": Cho phép các gói tin UDP đi đến cổng 53
- ICMP_IN = "1": Cho phép ping đến máy chủ
- ICMP_IN_RATE = "1/s": Giới hạn số gói tin ping đến server là
1 yêu cầu/s. Nếu ping nhanh hơn tốc độ này sẽ nhận được "Request timeout"
. Trong trường hợp nếu nhiều người cùng ping đến server cùng lúc, thì phần
lớn sẽ nhận được các phản hồi "Request timeout".
- ETH_DEVICE = "eth0": Mặc định CSF sẽ cấu hình iptables để
lọc traffic trên toàn bộ các card mạng, ngoại trừ card loopback . Nếu như
bạn muốn iptables chỉ lọc traffic qua card mạng "eth0" thì khai báo ở đây.
- ETH_DEVICE_SKIP = "eth1": Nếu bạn không muốn iptables
lọc traffic qua card mạng nào thì khai báo ở đây.
- DENY_IP_LIMIT = "500": Giới hạn số lượng IP bị block "vĩnh
viễn" bởi CSF (các IP này được lưu trong file /etc/csf/csf.deny). Khi số
lượng IP bị block vượt qua con số này, csf sẽ tự động unblock IP cũ nhất (IP
ở dòng 1 của file /etc/csf/csf.deny).
- DENY_TEMP_IP_LIMIT = "100" : Giới hạn số lượng IP bị
block tạm thời. Khi số lượng IP bị block vượt qua con số này, csf sẽ tự động
unblock IP cũ nhất (IP ở dòng 1 của file /etc/csf/csf.tempban). Giá trị 0 là
không giới hạn số lượng.
- LF_DAEMON = "1": Bật tính năng Login Fail Detection (phát
hiện đăng nhập sau).
- LF_CSF = "1": Tự động khởi động lại CSF nếu CSF bị treo, tự
động kiểm tra trạng thái của CSF sau mỗi 300s.
- PACKET_FILTER = "1": Lọc các gói tin TCP không hợp lệ
(INVALID state như : sequence number không đúng , kết nối ko thực hiện
đủ ba bước bắt tay, ... )
- SYNFLOOD = "1"; SYNFLOOD_RATE = "30/s";
SYNFLOOD_BURST = "40": Nếu 1 IP gửi 30 gói SYN trong vòng 1s và số
lượng kết nối SYN tồn tại trên máy chủ đạt trên 40 thì hủy những gói SYN
tiếp theo.
- CONNLIMIT = "80;20": Giới hạn số lượng kết nối mới đồng
thời đến server trên mỗi IP. Ví dụ trên có nghĩa là mỗi IP được phép mở 20
kết nối mới đồng thời đến port 80 trên máy chủ.
47
- PORTFLOOD = "80;tcp;20;5": Giới hạn số lượng kết nối đến
một cổng cụ thể trong một khoảng thời gian nhất định. Ví dụ như trên có
nghĩa : nếu nhiều hơn 20 kết nối TCP đến cổng 80 trong vòng 5s thì block
(chặn) IP đó tối thiểu 5s tính từ packet cuối cùng của IP đó. Sau 5s IP đó sẽ
tự động được unlock và truy cập bình thường.
- DROP_NOLOG = "10050,10051": Danh sách các cổng khi bị
hủy (drop) sẽ không cần phải ghi vào log
- CONNLIMIT_LOGGING = "1": Ghi log các IP vượt quá giới
hạn CONNLIMIT cấu hình ở bước trên.
- LF_PERMBLOCK = "1";LF_PERMBLOCK_INTERVAL =
"86400";LF_PERMBLOCK_COUNT = "6"; LF_PERMBLOCK_ALERT =
"1": Bật tính năng block vĩnh viễn một IP. Nếu một IP bị temp ban (khóa
tạm) 6 lần khi vi phạm các luật sẽ block (chặn) ip này 86400s ( 1 ngày) đồng
thời gửi email về cho người quản trị biết.
- CT_LIMIT = "300": Giới hạn số lượng connection từ một IP
đến máy chủ . Nếu số lượng đó vượt quá 300 thì tạm thời block (chặn) IP
đó.
- CT_INTERVAL = "30": Các lần quét để kiểm tra cách nhau
30s.
- CT_EMAIL_ALERT = "1": Gửi email thông báo nếu một IP bị
block bởi connection tracking.
- CT_PERMANENT = "0": Nếu đặt giá trị bằng 1, CSF sẽ block
IP vĩnh viễn, ngược lại, IP sẽ bị block tạm thời và sẽ được unblock sau
CT_BLOCK_TIME giây.
- CT_SKIP_TIME_WAIT = "0": Nếu không muốn đếm số lượng
kết nối đang ở trạng thái TIME_WAIT từ 1 IP đến máy chủ thì đặt giá trị là
1.
- CT_STATES = " SYN_RECV,TIME_WAIT ": Chỉ đếm các
kết nối ở trạng thái SYN_RECV và TIME_WAIT. Nếu muốn đếm tất cả các
trạng thái của kết nối thì để trống.
- CT_PORTS = "80,443": Chỉ áp dụng connection tracking cho
các kết nối đến port 80 và 443.
4.1.4. Thử nghiệm
4.1.4.1 Mô hình
Mô hình sử dụng cho việc kiểm thử này là máy chủ thực tế đang chạy
của một doanh nghiệp cung cấp Hosting trên địa bàn Hà Nội. Máy chủ này
có cấu hình như sau: Ram 24G, chip Cpu 2xE5620 (intel Xeon quard core
2,4Ghz, 12Mb cache). Công cụ để thử nghiệm trong mô hình này là ab
(Apache Benmark).
48
4.1.4.2 Cấu hình Trên máy chủ hosting đã cấu hình CloudLinux với các thông số như
sau: CPU usage: 10%, Vmem:1GB, Pmem:1GB, entry process: 30.
Hình 4.6: Cấu hình CloudLinux
Lựa chọn gói cấu hình Medium của CSF như trong hình
Hình 4.7 : Cấu hình CSF
4.1.4.3 Thử nghiệm
49
Đây là thông số của site trước khi kiểm thử.
Hình 4.8 Thông số của website
Sử dụng tool ab gửi 1000 yêu cầu đến trang web của người dùng
abxewqyu, mỗi lần gửi cùng lúc 25 yêu cầu.
50
Hình 4.9 Tấn công bằng tool ab
Trong quá trình nhận và xử lý request, tài nguyên của site đã dùng hết
(CPU, Vmem)
51
Hình 4.10 Thông số của website trong khi bị tấn công
Vẫn trong quá trình đấy, ta gửi thêm 1000 yêu cầu đến website, nhưng
tài nguyên sử dụng không vượt quá giới hạn đã được cấp.
Hình 4.11 Giới hạn tài nguyên
4.1.4.4. Đánh giá
Giải pháp sử dụng CloudLinux, Litespeed và CSF đối với các doanh
nghiệp cung cấp hosting có những điểm nổi trội hơn so với các giải pháp sử
dụng các phần mềm mã nguồn mở truyền thống khác. Các doanh nghiệp
kinh doanh hosting tại Việt Nam cũng nhận thấy những ưu điểm trên cho
nên mặc dù không miễn phí (CloudLinux: 10$ đến 14$/tháng, LiteSpeed:
350$/năm) nhưng phần lớn các doanh nghiệp đều đang chuyển dần sang giải
pháp này.
4.2. Giải pháp sử dụng IPS để lọc gói tin
Phương pháp này được sử dụng khá rộng rãi. Như trong trường hợp
Vietnamnet bị tấn công DDoS, công ty CMCinfosec đã sử dụng nhiều biện
pháp khác nhau bao gồm việc kết hợp cả phần mềm và phần cứng để hạn
chế DDoS, tuy nhiên ý tưởng chính của phương pháp trên là định tuyến các
yêu cầu của người dùng về hệ thống IPS, tại đây sử dụng CSF để lọc chặn
gói tin ở tầng mạng và sử dụng IPS để lọc gói tin ở tầng ứng dụng, sau đó
các gói tin hợp lệ sẽ được định tuyến đến máy chủ thật. Ưu điểm của phương
pháp này là cản lọc được phần lớn gói tin không hợp lệ, máy chủ web vẫn có
52
khả năng phục vụ mặc dù chịu cường độ DDoS lớn nhưng sẽ làm chậm tốc
độ truy suất của những yêu cầu hợp lệ.
Trong khuôn khổ luận văn của mình, tôi chọn Snort inline để xây
dựng hệ thống IPS.
4.2.1 Snort
4.2.1.1 Giới thiệu
Snort là hệ thống phát hiện và phòng chống xâm nhập mã nguồn mở
được phát triển bởi Sourcefire. Phát hiện và phòng chống xâm nhập dựa trên
ưu điểm của chữ ký, giao thức và kiểm tra sự bất thường, Snort là một trong
những IDS/IPS được triển khai rộng rãi nhất trên thế giới. Với hàng triệu
lượt tải và gần 400.000 người đăng ký, Snort đã trở thành “tiêu chuẩn” cho
IPS.
4.2.1.2 Cấu trúc của Snort
Hình 4.12: Cấu trúc của Snort
Snort bao gồm nhiều thành phần, với mỗi phần có một chức năng
riêng. Các phần chính đó là :
Package Capture : Môđun này lắng nghe trên các cổng được chỉ định
và thu thập các gói tin rồi trao cho môđun giải mã gói tin xử lý.
Decoder (Môđun giải mã gói tin): Tại đây các gói tin được giải mã rồi
chuyển cho môđun tiền xử lý.
Preprocessor (Môđun tiền xử lý): Môđun tiền xử lý là một môđun rất
quan trọng đối với bất kỳ một hệ thống IDS nào để có thể chuẩn bị gói dữ
53
liệu đưa và cho môđun Phát hiện phân tích. Ba nhiệm vụ chính của môđun
này là:
Kết hợp lại các gói tin: Khi một lượng dữ liệu lớn được gửi đi,
thông tin sẽ không đóng gói toàn bộ vào một gói tin mà phải thực hiện việc
phân mảnh, chia gói tin ban đầu thành nhiều gói tin rồi mới gửi đi. Khi
Snort nhận được các gói tin này nó phải thực hiện việc ghép nối lại để có
được dữ liệu nguyên dạng ban đầu, từ đó mới thực hiện được các công việc
xử lý tiếp. Như ta đã biết khi một phiên làm việc của hệ thống diễn ra, sẽ
có rất nhiều gói tin đuợc trao đổi trong phiên đó. Một gói tin riêng lẻ sẽ
không có trạng thái và nếu công việc phát hiện xâm nhập chỉ dựa hoàn
toàn vào gói tin đó sẽ không đem lại hiệu quả cao. Module tiền xử lý
stream giúp Snort có thể hiểu được các phiên làm việc khác nhau (nói cách
khác đem lại tính có trạng thái cho các gói tin) từ đó giúp đạt được hiệu
quả cao hơn trong việc phát hiện xâm nhập.
Giải mã và chuẩn hóa giao thức (decode/normalize): công việc
phát hiện xâm nhập dựa trên dấu hiệu nhận dạng nhiều khi bịthất bại khi
kiểm tra các giao thức có dữ liệu có thể được thể hiện dưới nhiều dạng
khác nhau. Ví dụ: một web server có thể chấp nhận nhiều dạng URL như
URL được viết dưới dạng mã hexa/Unicode, URL chấp nhận cả dấu \ hay
/ hoặc nhiều ký tự này liên tiếp cùng lúc. Chẳng hạn ta có dấu hiệu nhận
dạng “scripts/iisadmin”, kẻ tấn công có thể vượt qua được bằng cách tùy
biến các yêu cấu gửi đến web server như sau: “scripts/./iisadmin”,
“scripts/examples/../iisadmin”. “scripts\iisadmin” ,“scripts/.\iisadmin” hoặc
thực hiện việc mã hóa các chuỗi này dưới dạng khác. Nếu Snort chỉthực
hiện đơn thuần việc so sánh dữ liệu với dấu hiệu nhận dạng sẽ xảy ra tình
trạng bỏ sót các hành vi xâm nhập. Do vậy, môđun tiền xử lý của Snort
phải có nhiệm vụ giải mã và chỉnh sửa, sắp xếp lại các thông tin đầu vào
này để thông tin khi đưa đến môđun phát hiện có thể phát hiện được mà
không bỏ sót.
Phát hiện các xâm nhập bất thường (nonrule /anormal): các
plugin tiền xử lý dạng này thường dùng để đối phó với các xâm nhập
không thể hoặc rất khó phát hiện được bằng các luật thông thường hoặc
các dấu hiệu bất thường trong giao thức. Các môđun tiền xử lý dạng này có
thể thực hiện việc phát hiện xâm nhập theo bất cứ cách nào mà ta nghĩ ra
từ đó tăng cường thêm tính năng cho Snort. Ví dụ, một plugin tiền xử lý có
nhiệm vụthống kê thông lượng mạng tại thời điểm bình thường để rồi khi
có thông lượng mạng bất thường xảy ra nó có thể tính toán, phát hiện và
đưa ra cảnh báo (phát hiện xâm nhập theo mô hình thống kê). Phiên bản
hiện tại của Snort có đi kèm hai plugin giúp phát hiện các xâm nhập bất
thường đó là portscan và bo (backoffice). Portcan dùng để đưa ra cảnh báo
54
khi kẻ tấn công thực hiện việc quét các cổng của hệ thống để tìm lỗ hổng.
Bo dùng để đưa ra cảnh báo khi hệ thống đã bịnhiễm trojan backoffice và
kẻ tấn công từ xa kết nối tới backoffice thực hiện các lệnh từ xa.
Dectection Engine (Môđun phát hiện): Đây là môđun quan trọng nhất
của Snort. Nó chịu trách nhiệm phát hiện các dấu hiệu xâm nhập. Môđun
phát hiện sử dụng các luật được định nghĩa trước để so sánh với dữ liệu thu
thập được từ đó xác định xem có xâm nhập xảy ra hay không. Rồi tiếp theo
mới có thể thực hiện một số công việc như ghi log, tạo thông báo và kết xuất
thông tin. Một vấn đề rất quan trọng trong môđun phát hiện là vấn đề thời
gian xử lý các gói tin: một IDS thường nhận được rất nhiều gói tin và bản
thân nó cũng có rất nhiều các luật xử lý. Có thể mất những khoảng thời gian
khác nhau cho việc xử lý các gói tin khác nhau. Và khi thông lượng mạng
quá lớn có thể xảy ra việc bỏ sót hoặc không phản hồi được đúng lúc. Khả
năng xử lý của môđun phát hiện dựa trên một số yếu tố như: số lượng các
luật, tốc độ của hệ thống đang chạy Snort, tải trên mạng. Một số thử nghiệm
cho biết, phiên bản hiện tại của Snort khi được tối ưu hóa chạy trên hệ thống
có nhiều bộ vi xử lý và cấu hình máy tính tương đối mạnh thì có thể hoạt
động tốt trên cả các mạng cỡ Giga. Một môđun phát hiện cũng có khả năng
tách các phần của gói tin ra và áp dụng các luật lên từng phần nào của gói tin
đó. Các phần đó có thể là:
IP header
Header ở tầng giao vận: TCP, UDP
Header ở tầng ứng dụng: DNS header, HTTP header, FTP
header.
Dữ liệu
Một vấn đề nữa trong Môđun phát hiện đó là việc xử lý thế nào khi
một gói tin bị phát hiện bởi nhiều luật. Do các luật trong Snort cũng được
đánh thứ tự ưu tiên, nên một gói tin khi bị phát hiện bởi nhiều luật khác
nhau, cảnh báo được đưa ra sẽ là cảnh báo ứng với luật có mức ưu tiên lớn
nhất
Output Plug-ins: Module đầu ra hoặc plug-in có thể hoạt động theo nhiều
cách phụ thuộc vào việc bạn muốn lưu các output được tạo ra bằng hệ thống
ghi và tạo cảnh báo như thế nào.
4.2.1.3 Một số tham số cấu hình Snort
File cấu hình (snort.conf) bao gồm:
Thiết lập các biến
Cấu hình môđun giải mã (decoder)
Cấu hình môđun phát hiện (detection)
Cấu hình thư viện liên kết động
55
Cấu hình môđun tiền xử lý
Cấu hình các plugin đầu ra
Tùy biến các luật
4.2.1.4 Cấu trúc luật của Snort
Rules của Snort có hai phần : rule header và rule option. Một Rule có
thể phát hiện một hoặc nhiều kiểu xâm nhập.
Cấu trúc của rule header:
Rule Action Protoco
l
Source Address
và Port
The Direction
Operator
Destination
Address và Port
Alert tcp any 1234 -> 192.168.1.0/24
any
Rule Action là hành động Snort sẽ thực hiện nếu Snort phát hiện thấy
trong gói tin có dấu hiệu khả nghi (có sự trùng nhau giữa nội dung gói tin và
nội dung của rule option). Có 8 loại action mà Snort hỗ trợ:
alert : Tạo ra cảnh báo theo phương thức đã lựa chọn và lưu lại
thông tin packet dựa theo cấu hình output plugin.
log: Lưu thông tin packet .
pass: Bỏ qua packet.
active : Cảnh báo và chuyển sang dynamic rule.
dynamic : Sẽ không hoạt động trừ khi đuợc khởi động bởi một
active rule, sau đó hoạt động như một log rule.
drop : Sử dụng iptables drop packet và lưu log.
reject : Sử dụng iptables drop packet, lưu log và gửi gói tin TCP
reset nếu giao thức là TCP hoặc ICMP port unreachable nếu giao
thức là UDP.
sdrop: Sử dụng iptables drop packet nhưng không lưu log.
Protocol: Snort hỗ trợ 4 giao thức : TCP, UDP, ICMP và IP.
56
Source Address và Port (Destination Address và Port) :
Snort hỗ trợ IP Address dạng CIDR, ví dụ : 192.168.1.0/24, với tất
cả các IP Snort dùng từ khóa any
Snort hỗ trợ cấu hình với một port, một dải port hoặc tất cả các
port.
The Direction Operator : Có 2 loại direction operator là :
-> Chiều đi từ nguồn đến đích , bên trái dấu “->” là địa chỉ IP
nguồn , port nguồn, bên phải dấu “->” là IP đích port đích.
<> Traffic 2 chiều.
Cấu trúc rule option:
Rule option theo sau rule header và được đóng gói trong dấu ngoặc
đơn. Có thể có một hoặc nhiều option, được cách nhau bởi dấu phẩy. Nếu
bạn sử dụng nhiều option, những option hình thành phép logic AND. Một
action trong rule header chỉ được thực hiện khi tất cả các option đều đúng.
Tất cả các option được định nghĩa bằng các từ khóa. Một vài option cũng
chứa các tham số. Thông thường, một option có thể có 2 phần : từ khóa và
đối số. Các đối số được phân biệt với từ khóa bằng dấu hai chấm. Ví dụ:
msg: "Detected confidential";
Trong option này thì msg là từ khóa và "Detected confidential" là đối số của
từ khóa.
Một số từ khóa được sử dụng trong phần option của luật Snort :
msg: < sample message> : Được sử dụng để ghi thông tin vào việc ghi
log và cảnh báo
ack : <Number>: TCP header chứa một trường Acknowledgement
Number dài 32 bit. Trường này chỉ ra rằng sequence number kế tiếp của
người gửi được mong đợi. Trường này chỉ có ý nghĩa khi cờ flag trong
trường TCP được thiết lập.
57
content: “straight text”; content: “|hex data|”: Một đặc tính quan trọng
của Snort là khả năng tìm thấy một mẫu dữ liệu trong một gói tin. Mẫu đó có
thể tồn tại dưới dạng một chuỗi ASCII hoặc là các kí tự thập lục phân. Giống
như virut, những kẻ xâm nhập cũng có các dấu hiệu và từ khóa content để có
thể tìm ra các dấu hiệu trong các gói tin.
offset: < value>: Từ khóa offset được sử dụng kết hợp với từ khóa
content. Sử dụng từ khóa này, bạn có thể bắt đầu tìm kiếm từ một vị trí xác
định so với vị trí bắt đầu của gói tin.
depth: < value> : Từ khóa depth cũng được sử dụng kết hợp với từ
khóa content để xác định giới hạn trên của việc so sánh mẫu. Sử dụng từ
khóa này, bạn có thể xác định một vị trí so với vị trí bắt đầu. Dữ liệu sau vị
trí này sẽ không được tìm kiếm để so mẫu. Nếu bạn dùng cả hai từ khóa
offset và depth thì bạn có thể xác định một khoảng dữ liệu thực hiện việc so
sánh mẫu.
content_list: < filename> : Từ khóa content-list được sử dụng với tên
của một file như là đối số của từ khóa này. File này sẽ chứa một danh sách
các chuỗi sẽ được tìm kiếm trong một gói tin. Mỗi chuỗi được đặt trên các
dòng khác nhau của file.
dsize: [<|>] < number> : Từ khóa dsize được sử dụng để tìm chiều dài
một phần dữ liệu của gói tin. Nhiều cách tấn công sử dụng lổ hổng tràn bộ
đệm bằng cách gửi các gói tin có kích thước lớn. Sử dụng từ khóa này, bạn
có thể tìm thấy các gói tin có chiều dài dữ liệu lớn hoặc nhỏ hơn một số xác
định.
flags: < flags> :Từ khóa flags được sử dụng để tìm ra bit flag nào
được thiết lập trong header TCP của gói tin. Mỗi flag có thể được sử dụng
như một đối số của từ khóa flags trong luật Snort.
58
fragbits: < flag_settings> : Sử dụng từ khóa này, bạn có thể tìm ra
những bit RB (Reserved Bit), DF(Don't Fragment Bit), MF(More Fragments
Bit) trong header IP có được bật lên hay không.
id: < number> : Từ khóa id được sử dụng để đối chiếu trường
fragment ID của header gói tin IP. Mục đích của nó là phát hiện các cách tấn
công sử dụng một số ID cố định.
reference : <id system>,<id> :Từ khóa reference có thể thêm một sự
tham khảo đến thông tin tồn tại trên các hệ thống khác trên mạng. Nó không
đóng một vai trò nào trong cơ chế phát hiện. Có nhiều hệ thống để tham
khảo như CVE và Bugtraq. Những hệ thống này giữ các thông tin thêm về
các kiểu tấn công đã được biết. Bằng việc sử dụng từ khóa này, bạn có thể
kết nối đến các thông tin thêm trong thông điệp cảnh báo.
rev: < revision integer> :Từ khóa rev được thêm vào option của luật
Snort để chỉ ra số revision của luật. Nếu bạn cập nhật luật, bạn có thể sử
dụng từ khóa này để phân biệt giữa các phiên bản. Các module output cũng
có thể sử dụng con số này để nhận dạng số revision.
seq: <hex_value> : Từ khóa seq trong luật Snort có thể được sử dụng
để kiểm tra số thứ tự sequence của gói tin TCP.
4.2.2 Thử nghiệm
4.2.2.1 Mô hình
Mô hình để thử nghiệm gồm có 05 máy tính đóng vai trò tấn công, 02
máy chủ là IPS có cài CSF và Snort inline, 01 máy chủ là máy chủ web đang
chạy một web site sử dụng Joomla 3.1. Tất cả các kết nối trong mô hình đều
có tốc độ 100Mb/s.
Máy chủ IPS sử dụng hai card mạng, trong đó card eth1 có địa chỉ IP
là 172.19.38.164, là card mạng kết nối với 05 máy tính kể trên và card eth0
có địa chỉ 192.168.1.1 kết nối với máy chủ web có IP 192.168.1.2.
Công cụ sử dụng để tấn công là DoSHTTP 2.5.1.
59
Công cụ sử dụng để đo thời gian đáp ứng của máy chủ web là Jmeter
2.9.
Hình 4.13 Mô hình thử nghiệm sử dụng IPS để lọc gói tin
4.2.2.2 Cài đặt
Cài đặt Snort inline
yum -y update
yum -y install gcc flex bison wget make zlib zlib-devel libpcap
libpcap-devel pcre pcre-devel
rpm -Uhv
http://centos.alt.ru/repository/centos/6/i386/libnetfilter_queue-
1.0.2-1.el6.i686.rpm
rpm -Uvh
http://centos.alt.ru/repository/centos/6/i386/libnetfilter_queue-
devel-1.0.2-1.el6.i686.rpm
rpm -Uvh http://download.fedoraproject.org/pub/epel/6/i386/epel-
release-6-8.noarch.rpm
yum -y update
yum -y install libdnet libdnet-devel
cd /root; wget http://www.snort.org/downloads/2311-O daq-
2.0.0.tar.gz
tar xvzf daq-2.0.0.tar.gz
60
cd daq-2.0.0;./configure && make && make install
cd /root; wget http://www.snort.org/downloads/2320 -O snort-
2.9.4.6.tar.gz
tar xvzf snort-2.9.4.6.tar.gz
cd snort-2.9.4.6; ./configure --enable-sourcefire
make && make install
mkdir -p /etc/snort/rules
mkdir –p /var/log/snort
cd /etc/snort
Đăng ký tài khoản tại http://www.snort.org/snort-rules, sau đó tải
rules về. Rule mới nhất (ngày 18/4/2013) dành cho người dùng miễn phí là
snortrules-snapshot-2945.tar.gz.
tar xvzf snortrules-snapshot-2945.tar.gz
mv etc/* /etc/snort/
rmdir /etc/snort/etc
touch /etc/snort/rules/white_list.rules
/etc/snort/rules/black_list.rules
mkdir -p /usr/local/lib/snort_dynamicrules
groupadd -g 40000 snort
useradd snort -g snort -d /var/log/snort -s /sbin/nologin –m
chown -R snort:snort /etc/snort
chown -R snort:snort /var/log/snort
4.2.2.3 Cấu hình
Trên IPS:
Cấu hình cho phép gói tin đi qua
echo “1” > /proc/sys/net/ipv4/ip_forward
Cấu hình Snort (trong file /etc/snort/snort.conf)
ipvar HOME_NET 192.168.1.0/24: địa chỉ mạng cần bảo vệ
ipvar EXTERNAL_NET !$HOME_NET: địa chỉ mạng ngoài
var RULE_PATH rules
var SO_RULE_PATH so_rules
var PREPROC_RULE_PATH preproc_rules
var WHITE_LIST_PATH rules
var BLACK_LIST_PATH rules
config daq: nfq
config daq_mode: inline
config daq_var: queue=0
config snaplen: 65535
Cấu hình CSF (trong file /etc/csf/csf.conf)
61
ETH_DEVICE = eth1 (chỉ lọc ở card external)
SYNFLOOD = "1"
SYNFLOOD_RATE = "30/s"
SYNFLOOD_BURST = "40"
CONNLIMIT = "80;20"
PORTFLOOD = "80;tcp;20;5"
CT_LIMIT = "300"
CT_INTERVAL = "30"
Cấu hình file /etc/csf/csfpost.sh
iptables -P FORWARD ACCEPT
iptables -I FORWARD -i eth0 -p tcp --dport 80 -j NFQUEUE
Chạy snort inline
snort -d -D -c /etc/snort/etc/snort.conf -l /var/log/snort
4.2.2.4 Thử nghiệm
Kịch bản 1: Tấn công máy chủ web khi không có IPS, máy chủ web
cũng không cài CSF
Hình 4.14 Tài nguyên của máy chủ web khi chưa bị tấn công ở
kịch bản 1
Thông tin tài nguyên của máy chủ khi chưa bị tấn công : Có 221 tiến
trình, Load average: 0.05, CPU gần như không phải hoạt động
62
Sử dụng công cụ Jmeter để đo thời gian đáp ứng của máy chủ
Hình 4.15 Thời gian đáp ứng trung bình của máy chủ web khi chưa bị
tấn công ở kịch bản 1
Thời gian đáp ứng trung bình của máy chủ là 220ms.
Thực hiện tấn công máy chủ web, sau 1 phút tấn công thì người dùng
không thể truy cập vào trang demo DDoS, hiện tại đã có 469 tiến trình, load
average (tải trung bình): 97.43, CPU: 90.6%.
63
Hình 4.16 Tài nguyên của máy chủ web khi bị tấn công ở kịch bản 1
Sử dụng công cụ Jmeter để đo thời gian đáp ứng trung bình của máy
chủ, ta được:
Hình 4.17 Thời gian đáp ứng trung bình của máy chủ web khi bị tấn
công ở kịch bản 1
64
Thời gian đáp ứng trung bình của máy chủ trong khi bị tấn công
DDoS là 8248ms.
Nhận xét: Khi bị tấn công, máy chủ phải tạo ra rất nhiều tiến trình
httpd (như trong hình 4.15) để phục vụ yêu cầu từ các máy tấn công. Thời
gian đáp ứng trung bình lên đến 8s/một yêu cầu cho thấy việc phục vụ hết
sức chậm chạp của máy chủ khi đang bị tấn công.
Kịch bản 2: Tấn công máy chủ web khi không có IPS, máy chủ web có sử
dụng CSF
Cấu hình CSF (trong file /etc/csf/csf.conf) như sau
SYNFLOOD = "1"
SYNFLOOD_RATE = "30/s"
SYNFLOOD_BURST = "40"
CONNLIMIT = "80;20"
PORTFLOOD = "80;tcp;20;5"
Thực hiện tấn công DDoS vào máy chủ web, sau 5 phút, thông tin về
tình trạng máy chủ web như sau: có 242 tiến trình, load average 5.82, CPU
73,7%. Đồng thời CSF thông báo đã chặn được các gói tin từ các máy đang
tấn công DDoS vào máy chủ.
Hình 4.18 Tài nguyên và log của máy chủ web sau 5 phút bị tấn công ở
kịch bản 2
Sau khi tấn công 15 phút, ta thấy tài nguyên của máy chủ không quá
khác biệt với thời điểm 5 phút sau khi tấn công.
65
Hình 4.19 Tài nguyên và log của máy chủ web sau 15 phút bị tấn công
ở kịch bản 2
Sử dụng công cụ Jmeter để đo thời gian đáp ứng trung bình của máy
chủ, ta được:
Hình 4.20 Thời gian đáp ứng trung bình của máy chủ web khi bị tấn
công ở kịch bản 2
Nhận xét: Với cấu hình CSF như trên, hệ thống chỉ chặn các gói tin
vượt quá quy định (cho phép 30 gói tin SYN/s, nếu trong hệ thống có 40 kết
nối SYN từ IP đấy thì hủy những gói tin tiếp theo hay chỉ cho phép 20 kết
nối đồng thời từ một IP đến cổng 80), nên máy chủ vẫn phải phục vụ một
phần những yêu cầu không hợp lệ từ các máy tấn công. Chính vì vậy load
average (tải trung bình) của máy chủ vẫn tăng. Tuy nhiên, do CSF đã cản lọc
66
một phần nên load average (tải trung bình) của hệ thống không quá cao và
máy chủ vẫn phục vụ được yêu cầu từ người dùng (thời gian đáp ứng trung
bình 258ms)
Kịch bản 3: Tấn công máy chủ web khi có IPS.
Cấu hình IPS như trên, thêm rule nhận dạng tấn công DDoS bằng
DoSHTTP vào file /etc/snort/rules/local.rules như sau:
drop tcp any any -> any 80 (sid:5;msg:"Detect DoS_HTTP";content:"|57 69
6e 39 38 3b 20 55|";)
Sau 15 phút tấn công, tài nguyên của máy chủ web như sau: có 220
tiến trình, load average (tải trung bình):0.02, CPU gần như không tải.
Hình 4.21 Tài nguyên của máy chủ web và log của Snort sau 15 phút bị
tấn công ở kịch bản 3
Log của Snort ghi nhận đã chặn được các gói tin DDoS vào máy chủ web.
67
Hình 4.22 Thời gian đáp ứng trung bình của máy chủ web khi bị tấn
công ở kịch bản 3
Nhận xét: Khi kết hợp cả CSF và Snort iniline, các gói tin từ các máy
tấn công sẽ bị lọc một phần ở tầng mạng (CSF cản lọc), phần còn lại sẽ bị
Snort inline cản lọc ở tầng ứng dụng. Như vậy chỉ còn các gói tin từ người
dùng hợp lệ đến với máy chủ web. Đó chính là lý do tại sao tài nguyên của
máy chủ web hầu như không thay đổi trước và trong cuộc tấn công DDoS.
Kết luận: Sau khoảng 3 tháng làm luận văn, ít nhiều tôi cũng đã tìm hiểu tương
đối thành công về DDoS và xây dựng được thành công phương pháp phòng
thủ DDoS theo cách hiểu của mình. Qua những gì tìm hiểu được, tôi vẫn
cảm thấy vẫn còn nhiều điều phải làm để có thể hoàn thiện hơn luận văn
cũng như cần có sự hướng dẫn nhiều hơn nữa của các thầy cô và bạn bè.
1. Những kết quả đạt được :
Theo yêu cầu đặt ra ban đầu là “Tìm hiểu DDoS và xây dựng biện
pháp phòng thủ DDoS cho webserver”, cho đến thời điểm hiện tại luận văn
đã đạt được những nội dung sau:
- Tìm hiểu lý thuyết về DDoS
- Tìm hiểu được một số giải pháp thủ DDoS
- Triển khai thành công 02 hệ thống phòng thủ DDoS cho máy
chủ web
2. Hướng phát triển
Do thời gian có hạn nên việc tìm hiểu và xây dựng hệ thống phòng thủ
DDoS vẫn còn nhiều hạn chế và thiếu sót. Tôi hi vọng trong tương lai gần có
thể xây dựng, thử nghiệm hai giải pháp phòng thủ DDoS còn lại và tích hợp
được phương pháp sử dụng IPS, GEOIPDNS và HAPROXY vào một giải
pháp duy nhất để có thể phòng thủ tốt hơn trước các cuộc tấn công DDoS.
68
Tài liệu tham khảo
Tiếng Anh
1. Jelena Mirkovic, Sven Dietrich, David Dittrich, Peter Reiher
(2005), Internet Denial of Service: Attack and Defense
Mechanisms, Prentice Hall PTR.
2. HangChau, Network Security – Defense Against DoS/DDoS Attacks
3. Yonghua You (2007), A Defense Framework for Flooding-based
DDoS Attacks.
4. http://www.litespeedtech.com
5. http://cloudlinux.com
6. http://configserver.com
7. Snort Team (2013), Snort Users Manual.
8. Chris Murphy (2013), An Analysis of the Snort Data Acquisition
Modules, SANS Institute InfoSec Reading Room.
9. http://jmeter.apache.org
Tiếng Việt
6. Hoàng văn Quân (2008), Ngăn chặn Ddos bằng giao thức “lan tỏa
ngược”
