Pham Xuan Bach_K51MMT_Khoa Luan Tot Nghiep Dai Hoc

5/14/2018 Pham Xuan Bach_K51MMT_Khoa Luan Tot Nghiep Dai Hoc - slidepdf.com

http://slidepdf.com/reader/full/pham-xuan-bachk51mmtkhoa-luan-tot-nghiep-dai-hoc 1/60

1

ĐẠI HỌC QUỐC GIA HÀ NỘI

TRƯỜNG ĐẠI HỌC CÔNG NGHỆ

Phạm Xuân Bách

PHÒNG CHỐNG TẤN CÔNG TỪ CHỐI DỊCH VỤPHÂN TÁN VÀO CÁC WEBSITE

KHOÁ LUẬN TỐT NGHIỆP ĐẠI HỌC HỆ CHÍNH QUY

Ngành: Công nghệ thông tin

HÀ NỘI - 2010



2

ĐẠI HỌC QUỐC GIA HÀ NỘI

TRƯỜNG ĐẠI HỌC CÔNG NGHỆ

Phạm Xuân Bách

PHÒNG CHỐNG TẤN CÔNG TỪ CHỐI DỊCH VỤPHÂN TÁN VÀO CÁC WEBSITE

KHOÁ LUẬN TỐT NGHIỆP ĐẠI HỌC HỆ CHÍNH QUY

Ngành: Công nghệ thông tin

Cán bộ hướng dẫn: TS. Nguyễn Đại Thọ

HÀ NỘI - 2010



LỜI CẢM ƠN

Lời đầu tiên em xin bày tỏ lòng biết ơn sâu sắc đến thầy giáo TS. Nguyễn Đại Thọ

đã hướng dẫn chỉ bảo em rất tận tình trong suốt năm học vừa qua.

Em xin bày tỏ lòng biết ơn đến các thầy cô giáo trong khoa Công nghệ thông tin,

trường Đại học Công nghệ, Đại học Quốc gia Hà Nội. Các thầy cô đã dạy bảo, chỉ dẫn

em trong suốt bốn năm học tại trường Đại học Công nghệ, tạo điều kiện tốt nhất giúp

em hoàn thành khóa luận tốt nghiệp.

Tôi xin cảm ơn các bạn sinh viên K51 trường Đại học Công nghệ, đặc biệt là các

bạn sinh viên lớp K51CA và K51MMT cùng các thành viên cùng phòng 202B kí túc xá

ngoại ngữ đã đoàn kết, giúp đỡ cùng tôi theo học các bộ môn bổ ích và thú vị trongchương trình học đại học tại trường.

Cuối cùng, con xin gửi tới bố, chị gái, mẹ nuôi cùng gia đình lòng biết ơn và tình

cảm yêu thương.

Hà Nội, ngày 19/05/2010

Phạm Xuân Bách

i



TÓM TẮT

Phòng chống tấn công từ chối dịch vụ, đặc biệt là các cuộc tấn công từ chối dịch

vụ phân tán vào các Website vẫn đang là đề tài nhận được rất nhiều quan tâm của các

nhà nghiên cứu. Bên cạnh những khó khăn do cơ sở hạ tầng mạng còn yếu kém, sự pháttriển không ngừng của các công cụ và phương pháp tấn công khiến cho việc phòng và

chống tấn công từ chối dịch vụ trở thành một vấn đề rất nan giải. Khóa luận này sẽ trình

bày về một phương pháp phòng chống tấn công từ chối dịch vụ hiệu quả bằng cách sử

dụng một kiến trúc mạng bao phủ để bảo vệ Website. Trong kiến trúc này, một nhóm

các SOAP, secure overlay Access Point, sẽ thực hiện chức năng kiểm tra và phân biệt

người truy cập với các chương trình độc hại của những kẻ tấn công, để đưa yêu cầu của

người dùng hợp lệ đến các node bí mật trong mạng bao phủ bằng kết nối SSL thông quamạng đó. Sau đó các node bí mật sẽ chuyển tiếp yêu cầu người dùng, qua một vùng lọc,

đến với Server đích. Việc dùng các bộ lọc mạnh để lọc các yêu cầu độc hại gửi trực tiếp

đến Server đích, chỉ cho phép các node bí mật được truy cập, cùng với việc sử dụng

mạng bao phủ để che giấu các node bí mật, và nhóm các SOAP trong mạng bao phủ có

thể bị tấn công để sẵn sàng được thay thế bằng các SOAP khác, giúp cho Website được

bảo vệ và hạn chế tối đa tác động của các cuộc tấn công. Tuy vậy kiến trúc tỏ ra bất lực

khi một hoặc một số các node trong mạng bao phủ bị chiếm dụng trở thành node gây hại

và tấn công mạng. Khóa luận đã thực hiện các cải tiến, để có thể phát hiện tình huống

node gây hại tấn công, và tự động chuyển hướng truy vấn để tránh khỏi sự tấn công gây

hại. Sau khi xây dựng một kịch bản tấn công, kiến trúc cải tiến đã được kiểm tra cho

thấy kết quả rất khả quan.

Từ khóa: Denial of Service, overlay node, Graphic Turing Test

ii



MỤC LỤC

LỜI CẢM ƠN.............................................................................................. i

TÓM TẮT.................................................................................................... ii

MỤC LỤC................................................................................................... iii

MỞ ĐẦU..................................................................................................... 1

Chương 1: CÁC CÁCH THỨC TẤN CÔNG TỪ CHỐI DỊCH VỤ.......... 3

1.1 Thiết lập nên mạng Agent................................................................ 31.1.1 Tìm kiếm các máy dễ bị tổn thương........................................ 3

1.1.2 Đột nhập vào máy dễ bị tổn thương......................................... 3

1.1.3 Phương pháp lây truyền .......................................................... 4

1.2 Điều khiển mạng lưới máy Agent.................................................... 5

1.2.1 Gửi lệnh trực tiếp..................................................................... 5

1.2.2 Gửi lệnh gián tiếp..................................................................... 5

1.2.3 Unwitting Agent....................................................................... 6

1.2.4 Thực hiện tấn công................................................................... 7

1.3 Các cách thức tấn công từ chối dịch vụ............................................ 8

1.3.1 Khai thác các điểm yếu của mục tiêu....................................... 8

1.3.2 Tấn công vào giao thức............................................................ 8

1.3.3 Tấn công vào Middleware........................................................ 10

1.3.4 Tấn công vào ứng dụng............................................................ 10

1.3.5 Tấn công vào tài nguyên.......................................................... 11

1.3.6 Pure Flooding........................................................................... 11

1.4 IP Spoofing....................................................................................... 12

1.5 Xu hướng của DoS........................................................................... 13

iii



Chương 2: CÁC BIỆN PHÁP PHÒNG CHỐNG TRUYỀN THỐNG..... . 14

2.1 Biện pháp pushback.......................................................................... 14

2.2 Biện pháp Traceback........................................................................ 15

2.3 Biện pháp D-WARD........................................................................ 18

2.4 Biện pháp NetBouncer...................................................................... 19

2.5 Biện pháp “Proof of Work”.............................................................. 20

2.6 Biện pháp DefCOM.......................................................................... 21

2.7 Biện pháp COSSACK...................................................................... 22

2.8 Biện pháp Pi..................................................................................... 23

2.9 Biện pháp SIFF................................................................................. 24

2.10 Biện pháp lọc đếm chặng HCF....................................................... 25

Chương 3: SOS VÀ WEBSOS.................................................................... 27

3.1 Giao thức Chord............................................................................... 27

3.2 Kiến trúc SOS................................................................................... 29

3.3 Kiến trúc WebSOS........................................................................... 313.3.1 Giải pháp đề xuất..................................................................... 31

3.3.2 Kiến trúc của WebSOS............................................................ 31

3.3.3 Cơ chế của WebSOS................................................................ 32

3.3.3.1 Cơ chế chung.................................................................... 32

3.3.3.2 Cơ chế định tuyến............................................................. 34

3.3.4 Cơ chế bảo vệ........................................................................... 34

3.3.5 Đánh giá ưu, nhược điểm của kiến trúc WebSOS.................. 36

Chương 4: THỰC NGHIỆM, CẢI TIẾN VÀ KẾT QUẢ........................... 37

4.1 Môi trường thực nghiệm................................................................... 37

4.2 Cài đặt kiến trúc WebSOS................................................................ 37

4.3 Kiểm tra độ trễ của các kết nối......................................................... 38

iv



4.4 Đề xuất cải tiến................................................................................. 39

4.4.1 Vấn đề về mạng bao phủ của WebSOS .................................. 39

4.4.2 Đề xuất cải tiến........................................................................ 40

4.4.3 Thực thi đề xuất....................................................................... 42

4.4.3.1 Kịch bản thử nghiệm......................................................... 42

4.3.3.2 Kết quả thử nghiệm........................................................... 43

4.3.3.2.1 Với chương trình gốc................................................. 43

4.3.3.2.2 Với chương trình cải tiến........................................... 44

4.4.4 Đánh giá hiệu năng của chương trình cải tiến.................... 46

Chương 5: KẾT LUẬN............................................................................... 50

5.1 Các kết quả đã đạt được................................................................... 50

5.2 Các kết quả hướng tới....................................................................... 50

TÀI LIỆU THAM KHẢO........................................................................... 52

v



MỞ ĐẦU

Tấn công từ chối dịch vụ (Dos, Denial of Services) đã ngày càng trở thành một

mối đe dọa lớn đối với sự tin cậy của mạng internet. Là các cuộc tấn công sử dụng

nhiều cách thức tổ chức và thực hiện khác nhau, từ việc dùng chỉ một máy tới việc thu

thập các máy agent dưới quyền với số lượng lên đến hàng chục ngàn máy phục vụ tấn

công, mục đích của các cuộc tấn công là làm tê liệt các ứng dụng, máy chủ, toàn bộ

mạng lưới, hoặc làm gián đoạn kết nối của người dùng hợp pháp tới Website đích. Một

nghiên cứu tại UCSD [23] đã chỉ ra rằng ngay từ đầu thập niên này các cuộc tấn công từ

chối dịch vụ đã diễn ra với một tỷ lệ lên tới 4000 cuộc tấn công mỗi tuần. Trong năm

2002, một cuộc tấn công từ chối dịch vụ [22] đã làm sập tới 9 trong số 13 máy chủ DNS

root của toàn thế giới. Mức độ ảnh hưởng nghiêm trọng của các cuộc tấn công từ chốidịch vụ, mà đặc biệt được nhắc đến nhiều nhất là tấn công từ chối dịch vụ phân tán

DDoS, đã dẫn đến một loạt các nghiên cứu nhằm hiểu rõ hơn về các cơ chế tấn công, để

đưa tới các cách thức giúp có thể phòng chống ảnh hưởng tiêu cực của nó. Có nhiều

phương pháp đã được đề xuất nhằm chống lại các cuộc tấn công từ chối dịch vụ, từ việc

lọc các gói tin để tránh giả mạo địa chỉ nguồn, chuyển hướng tấn công, đẩy ngược luồng

giao thông tấn công trở lại mạng, cách ly để phân biệt máy khách và giao thông máy

chủ, … Mỗi giải pháp đó đều rất tốt, và cung cấp kĩ thuật giúp chúng ta định vị vấn đềtấn công từ chối dịch vụ. Song các phương pháp chỉ có thể bảo vệ lại từng khía cạnh của

tấn công từ chối dịch vụ. Khóa luận của tôi trình bày một phương pháp phòng chống tấn

công từ chối dịch vụ phân tán rất hiệu quả và toàn diện hơn thế. Đó là việc áp dụng kiến

trúc mạng bao phủ, để bảo vệ mục tiêu khỏi sự tiếp cận của kẻ tấn công. Dựa trên kiến

trúc mạng bao phủ, có một số đề xuất được đưa ra đó là kiến trúc SOS và WebSOS.

Kiến trúc SOS sử dụng một mạng bao phủ để chỉ cho các truy vấn hợp pháp đã qua xác

thực được phép đến server đích. Dựa vào việc sử dụng các node bí mật, và chỉ có giao

thông từ các node này mới có thể đến được server đích, kiến trúc tỏ ra khá hiệu quả

trong việc bảo vệ Website. Kế thừa kiến trúc SOS, WebSOS triển khai mạng bao phủ

với một số cơ chế cải tiến như xác thực người dùng thông qua bài kiểm tra CAPTCHA,

kết nối thông qua proxylet cùng với việc xác thiết lập kết nối SSL và xác thực X.509,

nhằm tăng mức độ bảo mật hơn cho hệ thống. Để giúp cho WebSOS có thể tránh được

cả các trường hợp các node trong mạng bao phủ bị chiếm dụng trở thành nguồn tấn

công, chúng tôi đưa ra các đề xuất cải tiến nhằm tự động phát hiện, và thay đổi truy vấn

để tránh được cuộc tấn công như vậy.

1



Phần tiếp theo của khóa luận được tổ chức như sau:

Chương 1: Các phương thức tấn công từ chối dịch vụ nêu lên một cách tổng quan

về các cách thức một kẻ tấn công phải thực hiện nhằm tạo ra một cuộc tấn công từ chối

dịch vụ.Chương 2: Các phương pháp phòng chống tấn công từ chối dịch vụ đã được đề

xuất trước đây. Nhiều phương pháp hiện nay vẫn là những nghiên cứu đáng quan tâm

trong lĩnh vực phòng chống tấn công từ chối dịch vụ. Các phương pháp lọc, với sự phát

triển của cơ sở hạ tấng mạng, nếu được thực hiện đồng bộ có thể giảm thiểu nguy cơ tấn

công từ chối dịch vụ cho các Website.

Chương 3: SOS và WebSOS, giới thiệu về cơ chế của hai kiến trúc bảo vệ Website

khỏi tấn công từ chối dịch vụ thông qua việc sử dụng mạng bao phủ và node bí mật. Từđó nêu lên các đặc điểm cốt lỗi được tôi sử dụng để tham gia vào kiến trúc được cải tiến

nhằm phòng chống tấn công từ chối dịch vụ.

Chương 4: Thực nghiệm, cải tiến và kết quả nêu lên những kết quả của tôi trong

việc thực hiện triển khai mô hình kiến trúc WebSOS và các phân tích nhằm đưa ra cải

tiến giúp hệ thống trở lên mạnh mẽ hơn chống lại các cuộc tấn công ngay từ trong các

node thuộc mạng bao phủ khi một số node bị chiếm dụng trở thành nguồn tấn công.

Chương 4 cũng đưa ra các kết quả đánh giá hiệu năng của kiến trúc nguồn WebSOS vàkiến trúc cải tiến thông qua kịch bản tấn công được xây dựng và qua việc đo một số

thông số về độ trễ truy vấn thực hiện qua mô hình các kiến trúc này.

Chương 5: Kết luận tổng kết lại các kết quả đã đạt được, cùng với các kết quả mà

nghiên cứu khóa luận hướng tới nhằm hoàn thiện mô hình để hướng tới mục tiêu có thể

triển khai thực hiện.

2



Chương 1: CÁC CÁCH THỨC TẤN CÔNG TỪ

CHỐI DỊCH VỤ

Một cuộc tấn công DDoS cần phải được chuẩn bị kỹ lưỡng bởi kẻ tấn công. Trước

tiên là bước chiếm dụng các máy khác làm lực lượng cho bản thân. Việc này được thực

hiện bằng cách tìm máy dễ bị tổn thương, sau đó đột nhập vào chúng, và cài đặt mã tấn

công. Tiếp theo đó, kẻ tấn công thiết lập các kênh giao tiếp giữa các máy, để chúng có

thể được kiểm soát và tham gia cuộc tấn công một cách có phối hợp. Việc này được

thực hiện bằng cách sử dụng một kiến trúc handler/agent hoặc một điều khiển và kênh

điều khiển thông qua mạng IRC. Một khi các mạng DDoS được xây dựng, nó có thể

được sử dụng để tấn công nhiều lần, chống lại các mục tiêu khác nhau

.

1.1 Thiết lập nên mạng Agent.

Tùy vào mỗi kiểu tấn công từ chối dịch vụ, kẻ tấn công cần tìm kiếm và thiết lập

cho mình một mạng lưới lớn các máy tính để dùng cho việc tấn công. Việc này có thể

thực hiện thủ công, bán tự động hoặc là tự động hoàn toàn. Trong các trường hợp của

hai DDoS công cụ nổi tiếng trước đây, trinoo và Shaft, chỉ quá trình cài đặt được tự

động, trong khi phát hiện và chiếm dụng các máy dễ bị tổn thương được thực hiện một

cách thủ công. Hiện nay, những kẻ tấn công thường sử dụng script để tự động hóa toàn

bộ quá trình.

1.1.1 Tìm kiếm các máy dễ bị tổn thương

Quá trình tìm kiếm dễ bị tổn thương được gọi là quét - scanning. Kẻ tấn công sẽ gửi một

gói vài mục tiêu lựa chọn để xem liệu nó có còn sống và dễ bị tổn thương. Nếu nhận

thấy máy phù hợp, những kẻ tấn công sẽ cố gắng đột nhập vào máy.

1.1.2 Đột nhập vào máy dễ bị tổn thương

Kẻ tấn công cần phải khai thác một lỗ hổng trong máy mà hắn đang có ý địnhtuyển dụng để được truy cập vào và “sở hữu” chúng. Phần lớn các lỗ hổng bảo mật cung

cấp cho một kẻ tấn công quyền truy cập vào hệ thống với quyền cao nhất -

administrator, và hắn có thể thêm/ xóa/ thay đổi các tập tin hoặc hệ thống cài đặt theo ý

thích. Và để tạo thuận lợi cho việc truy nhập vào máy tính bị sở hữu trong tương lai, kẻ

tấn công thường cho chạy một chương trình cố gắng lắng nghe kết nối đến từ một cổng

nhất định. Chương trình này được gọi là backdoor. Kết nối thông qua backdoor một số

được bảo vệ bởi mật khẩu mạnh, một số lại mở và chấp nhận mọi kết nối bên ngoài.

3



Thường các lỗ hổng bảo mật sao khi được phát hiện sẽ được giảm nhẹ bởi các bản

vá – patch. Tuy vậy các kẻ tấn công luôn cố gắng khai thác, tìm kiếm các lỗ hổng khác

mà máy có thể có. Và có một lỗ hổng không thể giảm nhẹ, hoặc được sửa bởi bản vá, đó

là một mật mã truy nhập máy tính yếu. Một số chương trình khai thác có chứa các từ

điển mật khẩu chung thường được sử dụng. Chúng thử các mật khẩu trong danh sách đó

để đột nhập vào máy tính. Có thể mất nhiều thời gian, song trong nhiều trường hợp

chúng cũng khai thác được các mật khẩu yếu của người dùng và đạt được quyền truy

nhập hợp lệ đến máy người đó. Người dùng thường nghĩ rằng không đặt mật khẩu cho

tài khoản Administrator là hợp lý, hoặc cho rằng, "password" hoặc một số từ đơn giản

khác là đủ để bảo vệ tài khoản. Và đó là những nhầm lẫn nghiêm trọng có thể khiến họ

phải trả giá đắt.

1.1.3 Phương pháp lây truyền

Kẻ tấn công cần phải quyết định một mô hình phát tán cho việc cài đặt phần mềm

độc hại của mình. Một mô hình đơn giản là kho lưu trữ trung ương, hoặc bộ nhớ cache,

với cách tiếp cận: Kẻ tấn công lưu các phần mềm độc hại trong một kho lưu trữ tập tin

(ví dụ, một máy chủ FTP) hoặc trang web của một Web, và các máy truy cập sẽ bị

nhiễm mã từ kho này. Kẻ tấn công cài đặt trinoo và Shaft sử dụng phương pháp tiếp cận

tập trung như vậy trong những ngày đầu. Năm 2001, sâu W32/Leaves sử dụng một biến

thể của các trang web bị cấu hình lại làm bộ nhớ cache của nó, cũng như các sâu W32/

SoBig gửi thư hàng loạt trong năm 2003. Với người phòng chống, phương pháp này có

thuận lợi đó là dễ dàng trong việc nhận diện để loại bỏ nguồn tập trung mã độc của kẻ

tấn công.

Một mô hình khác là back-chaining, hay là kéo-pull, trong đó những kẻ tấn công

mang công cụ của mình từ một máy chủ lưu trữ ban đầu bị tổn hại đến máy chủ để

chiếm dụng máy mới, cứ như vậy thành một chuỗi nối tiếp.

Cuối cùng, phương pháp chủ động, push, hay lan truyền thẳng kết hợp giữa việc

khai thác và lây truyền trong cùng một tiến trình. Điểm khác biệt so với back-chaining

đó là trong ngay chính tiến trình khai thác đã chứa các mã độc để lan truyền đến máy bị

tốn hại, chứ không phải là copy mã độc đó sau khi đã chiếm dụng các máy tổn hại.

1.2 Điều khiển mạng lưới máy Agent

4



Khi mạng lưới các agent lớn dần, kẻ tấn công cần giao tiếp với các máy này để

điều khiển chúng cho hoạt động tấn công. Mục đích của việc giao tiếp này nhằm giúp kẻ

tấn công có thế đưa ra lệnh bắt đầu/ kết thúc các cuộc tấn công cụ thể cũng như giúp

hắn có thể lấy những số liệu cụ thể về hành vi của các máy agent.

1.2.1 Gửi lệnh trực tiếp

[17] Một số các công cụ DDoS như trinoo xây dựng một mạng lưới handler/agent.

Đây là kiến trúc các lớp bao phủ giúp kẻ tấn công có thể che giấu định danh của bản

thân. Hắn sẽ sử dụng một, hoặc một vài máy để chuyển các lệnh điều khiển mạng DDoS

đến các máy nạn nhân – agents. Các máy này được gọi là các handler, hay master. Các

câu lệnh có thể là các văn bản không được mã hóa, hay được mã hóa, hoặc các chuỗi

byte nhị phân. Phân tích lệnh và điều khiển giao thông giữa các handler và các agent cóthể cho cái nhìn sâu sắc khả năng của những công cụ mà không cần phải truy cập vào

các phần mềm độc hại hay mã nguồn của nó.

Để các handler và agent, theo các công cụ như trinoo, Stacheldraht, và Shaft có thể

hoạt động, các handler phải biết địa chỉ của các agent và nhớ được chúng sau khi hệ

thống hoặc chương trình khởi động lại. Các công cụ DDoS trước đây thường mã hóa

chúng lại, rồi gửi thông báo với handler trong khi chiếm dụng máy agent. Các handler sẽ

lưu giữ chúng trong một file để duy trì thông tin về mạng lưới DDoS. Trong vài trườnghợp các handler còn không chứa cơ chế xác thực, nghĩa là bất kì máy nào cũng có thể

gửi lệnh đến cho handler. Các nghiên cứu trước đây về một số công cụ như trinoo, TFN,

Stacheldraht, Shaft, và mstream đều cho thấy các handler và agent đều có thể bị phát

hiện và điều khiển lại. Điều này khiến một số kẻ tấn công có thể sử dụng mạng lưới

DDoS của kẻ khác, cũng như giúp một số người phòng thủ có thể điều khiển ngược lại

các handler để ngừng cuộc tấn công. Một số các công cụ DDoS dùng kiến trúc handler/

agent bảo vệ truy cập đến các handler bằng mật khẩu, hoặc mật khẩu mã hóa, hoặc mã

hóa danh sách các agent để tránh việc phát hiện ra địa chỉ, và điều khiển các agent khi

handler bị phát hiện.

1.2.2 Gửi lệnh gián tiếp

[17] Truyền thông trực tiếp gây ra một vài nhược điểm cho những kẻ tấn công. Vì

handler cần thiết để lưu định danh của các agent, và thường xuyên, một máy tính

handler sẽ lưu định danh của các agent này, một khi chúng ta phát hiện và nắm giữ một

máy, mạng máy DDoS toàn có thể được xác định. Hơn nữa, mô hình truyền thông trực

5



tiếp đã tạo ra sự kiện bất thường có thể dễ dàng phát hiện khi kiểm soát mạng. Do cơ

chế của tryền thông trực tiếp là handler và agent phải sẵn sàng chấp nhận lắng nghe trên

một cổng nhất định, vì vậy khi kiểm tra bỗng nhiên thấy máy khởi tạo kết nối đến một

máy khác trên một cổng lạ là có thể phát hiện việc máy bị chiếm dụng. Kiểm tra các gói

tin gửi và nhận qua kết nối này, người quản trị mạng có thể xác định địa chỉ của máy

mình kết nối. Ngay cả khi không có kết nối, dựa vào việc giám sát các cổng mở trên

máy cũng có thể phát hiện được các tiến trình của handler hoặc agent. Cuối cùng, kẻ tến

công cũng phải viết các mã riêng của mình cho việc truyền các lệnh và điều khiển.

Đó là lý do các kẻ tấn công chuyển sang việc truyền thông qua các IRC. Lúc này

cả kẻ tấn công và các agent sẽ kết nối đến một IRC server nào đó, vì vậy nó là hợp lệ và

không tạo ra một sự kiện bất thường nào cả. Vai trò của hanlder giờ được thực hiện bởi

một kênh đơn lẻ trên IRC server, và thường được bảo vệ bởi password. Thông thường

có một kênh mã hóa cứng vào trong các con bot trong máy nạn nhân, nơi mà nó kết nối

vào ban đầu để tìm hiểu xem kênh điều khiển thực sự nằm ở đâu. Và sau đó nó sẽ kết

nối vào trong kênh điều khiển đó. Việc nhảy kênh thậm chí cũng có thể thực hiện trong

mạng IRC thông qua cách này. Từ đó, con bot có thể nhận lệnh của kẻ tấn công đến qua

kênh điều khiển mà nó tìm được và kết nối đến, để thực hiện lệnh, như quét tìm máy

agent khác, tấn công DDoS, update, …

Việc gửi lệnh gián tiếp có rất nhiều ưu điểm. Server thì vẫn tồn tại mà được duy trì

bởi người khác, còn kẻ tấn công chỉ cần một kênh thông tin của server trong hàng ngàn

kênh chat khác, nên sẽ rất khó để phát hiện, dù cho là nó có thể trở thành một kênh khác

lạ khi có tới hàng ngàn, chục ngàn người đột nhiên tham gia chỉ trong vài phút. Thậm

chí khi bị phát hiện thì cũng cần phải tiếp xúc được với người quản lý server mới có thể

dừng kênh truyền, trong khi server IRC rất có thể lại là một server nước ngoài nào đó.

Hơn nữa, theo cơ chế phân tán của IRC, không cần tất cả các client phải truy cập vào

cùng một server IRC mới có thể tham gia vào kênh handler, mà chỉ cần truy cập vào mộtserver trong cùng mạng. Hầu hết các công cụ xuất hiện sau Trinity đều lợi dụng cơ chế

truyền thông này.

1.2.3 Unwitting Agent

[17] Ngoài ra còn có một lớp của các cuộc tấn công DDoS với lực lượng tham gia

là các máy tính có lỗ hổng bảo mật mà việc khai thác không nhất thiết đòi hỏi phải cài

đặt bất kỳ phần mềm độc hại trên máy tính này, nhưng, thay vào đó cho phép kẻ tấn

công kiểm soát các máy chủ để làm cho chúng tạo ra các giao thông tấn công. Kẻ tấn

6



công tập hợp một danh sách các hệ thống dễ bị tổn thương và, tại thời điểm vụ tấn công,

có các agent thông qua danh sách này gửi các lệnh để bắt đầu khai thác các luồng giao

thông. Các lưu lượng truy cập tạo ra là hợp pháp. Ví dụ, kẻ tấn công có thể lợi dụng một

lỗ hổng hiện nay tại một máy chủ Web để làm nó để chạy chương trình PING.EXE.

Một số nhà nghiên cứu đã gọi là các unwitting agent.

Sử dụng các unwitting agent, thay vì phải cài đặt mã độc trên máy nạn nhân, kẻ tấn

công sử dụng các lỗ hổng bảo mật để thâm nhập vào máy và chạy các phần mềm hợp

pháp sẵn có trên hệ thống, vì vậy việc chống trả lại hành động tấn công này trở nên rất

khó và phức tạp. Do trên máy nạn nhân không chứa mã độc hại, nên các chương trình

quét cổng truy cập, quét file hệ thống, hoặc quét virus không thể phát hiện.Thường chỉ

có thể phát hiện thông qua việc giám sát lưu lượng mạng, các chương trình quét lỗ hổng

bảo mật như Nessus. Và chỉ có cách vá các lỗi bảo mật mới giúp việc bị lạm dụng máy

và các phần mềm hợp pháp trong máy được hạn chế, giảm thiểu nguy cơ bị chiếm dụng

máy làm agent cho cuộc tấn công.

1.2.4 Thực hiện tấn công

Một số cuộc tấn công được lên lịch trước và mã hóa trong mã độc truyền đến các

agent, và định sẵn một thời điểm thì sẽ hoạt động, đồng loạt tấn công vào một mục tiêu

nào đó. Tuy nhiên, hầu hết các cuộc tấn công xảy ra khi kẻ tấn công phát đi một lệnh từcác handler đến các agent. Trong vụ tấn công, giao thông điều khiển hầu hết đều giảm.

Tùy thuộc vào loại công cụ tấn công được sử dụng, những kẻ tấn công có thể hoặc

không có khả năng phát lệnh dừng cuộc tấn công. Thời hạn của cuộc tấn công thường

được quy định tại lệnh của kẻ tấn công hay kiểm soát bởi các thiết lập mặc định biến.

Một điểm khá tốt cho việc phòng thủ nếu kẻ tấn công rời khỏi mạng tấn công vào thời

điểm tấn công tràn ngập đã bắt đầu. Tuy nhiên, có khả năng là kẻ tấn công là quan sát

các cuộc tấn công liên tục, tìm kiếm ảnh hưởng của nó vào các mục tiêu thử nghiệm.

Một số công cụ, như Shaft, có khả năng cung cấp phản hồi về thống kê tấn công tràn

ngập. Những kẻ tấn công đang thử nghiệm một số loại tấn công, chẳng hạn như tấn

công tràn gói tin ICMP, TCP SYN, và UDP, trước khi chính thức tấn công thực sự nhằm

vào nhiều mục tiêu .

1.3 Các cách thức tấn công từ chối dịch vụ

7



Có một số phương pháp gây ra từ chối dịch vụ. Tạo ra một hiệu ứng DoS là tất cả

các cách có thể để phá hỏng hoặc làm cho hệ thống ngừng hoạt động. Có nhiều cách để

làm một hệ thống ngừng hoạt động, và thường sẽ tồn tại nhiều lỗ hổng trong hệ thống

để những kẻ tấn công sẽ cố gắng khai thác hoặc định vị để tấn công vào trong chúng cho

đến khi hắn nhận được kết quả mong muốn: mục tiêu bị phải chuyển sang trạng thái

offline.

1.3.1 Khai thác các điểm yếu của mục tiêu

Việc tấn công bằng cách khai thác các điểm yếu của mục tiêu bao gồm việc gửi

các gói tin khai thác các lỗ hổng tồn tại trong máy mục tiêu đó. Ví dụ, có một lỗi trong

Windows 95 và NT, và một số hạt nhân Linux, trong việc xử lý không đúng các gói

phân mảnh. Thông thường, khi một gói tin quá lớn cho một mạng nào đó, nó được chiathành hai (hoặc hơn) các gói nhỏ hơn, và mỗi phần trong số họ được đánh số thứ tự

phân mảnh. Việc đánh dấu chỉ ra thứ tự của byte đầu tiên và byte cuối cùng trong gói

tin, đối với bản gốc. Tại máy nhận các gói tin, chúng được hợp lại thành các gói dữ liệu

gốc thông qua việc nối các gói tin theo số thứ tự đã đánh. Tuy vậy các lỗ hổng trong hạt

nhân trên đã khiến cho máy trở nên không ổn định khi nhận các gói tin không đúng số

thứ tự phân mảnh, khiến nó có thể treo, sụp đổ, hoặc khởi động lại. Điểm dễ bị tổn

thương này có thể được khai thác bằng cách gửi gói tin UDP với số thứ tự lặp cho nạn

nhân. Có một số biến thể của việc khai thác này – gửi các mảnh có số thứ tự chồng

nhau, một gói tin có offset chồng lên gói thứ hai trước khi bắt đầu tiêu đề trong gói đầu

tiên, và như vậy. Chúng được biết đến như là các khai thác bonk, boink, teardrop, và

newtear.

Các cuộc tấn công đặc biệt dễ gây tổn thương xấu bởi vì chúng có thể làm sụp đổ hay

treo máy bằng việc chỉ cần gửi lặp lại một hoặc hai gói tin được chọn lựa cẩn thận. Tuy

nhiên, một khi lỗ hổng được vá, các cuộc tấn công ban đầu trở nên hoàn toàn không

hiệu quả.

1.3.2 Tấn công vào giao thức

[17][18]Một ví dụ lý tưởng của các cuộc tấn công giao thức đó là tấn công tràn

ngập gói TCP SYN. Một phiên kết nối TCP bắt đầu với việc bắt tay ba bước giữa một

máy khách và máy chủ. Khách hàng gửi một gói tin TCP SYN đến máy chủ, yêu cầu

một số dịch vụ. Trong phần đầu gói SYN, khách hàng cung cấp số thứ tự - sequence

number của mình, một uniqueper- số kết nối sẽ được sử dụng để đếm dữ liệu được gửi

đến máy chủ (vì vậy các máy chủ có thể nhận ra và xử lý mất tích, thứ tiệu dữ liệu

8



không đúng, hoặc dữ liệu lặp đi lặp lại). Khi nhận được gói SYN, máy chủ cấp phát một

khối điều khiển truyền dẫn (TCB), lưu trữ thông tin về khách hàng. Sau đó nó trả lời

bằng một SYN-ACK, thông báo cho khách hàng có yêu cầu rằng dịch vụ của nó sẽ được

cấp, ghi nhận số thứ tự của khách hàng và gửi thông tin về số thứ tự ban đầu của máy

chủ. Các khách hàng, khi nhận được gói SYN-ACK, cũng cấp phát một khối điều khiển

truyền dẫn, sau đó trả lời với một gói ACK đến máy chủ, để hoàn thành việc mở kết nối.

Tiềm năng lạm dụng nằm trong việc cấp phát nguồn tài nguyên của máy chủ ngay

từ khi nhận được gói SYN. Khi máy chủ giao TCB của mình và trả lời bằng một SYN-

ACK, kết nối được cho là nửa mở. Nghĩa là tài nguyên máy chủ cấp phát sẽ được giữ để

dành cho kết nối với khách hàng, cho đến khi khách hàng gửi một gói tin ACK, đóng

kết nối (bằng cách gửi gói tin RST) hoặc cho đến khi hết hạn chờ và server ngắt kết nối,

giải phóng không gian đệm. Và cho dù khách hàng có gửi lại gói tin khác, hay không,

thì tài nguyên đó sẽ được cấp phát giữ trong một khoảng thời gian nhất định. Trong một

cuộc tấn công tràn gói tin TCP SYN, kẻ tấn công tạo ra vô số các kết nối nửa mở bằng

cách sử dụng giả mạo IP nguồn. Những yêu cầu nhanh chóng vắt kiệt bộ nhớ TCB của

máy chủ, và khi đó máy chủ sẽ không còn có thể chấp nhận yêu cầu kết nối đến nữa. Để

có thể giữ cho tình trạng này được kéo dài như mong muốn, kẻ tấn công cần phải tạo ra

một dòng đều đặn các gói SYN đối với nạn nhân (để giành lấy những tài nguyên đã

được giải phóng bởi thời gian tạm ngưng hoặc hoàn thành các phiên TCP).

Đây là một cuộc tấn công đặc biệt nguy hiểm, khi mà máy chủ nhận được một số

lượng lớn các gói SYN hợp pháp và không thể dễ dàng phân biệt các gói từ khách hàng

hợp pháp với các gói từ giao thông tấn công.

Để thực hiện thành công một cuộc tấn công tràn ngập gói SYN, kẻ tấn công cần

xác định vị trí cổng mở trên máy của nạn nhân. Sau đó, chỉ cần gửi một lưu lượng gói

tin nhỏ, tầm 10 gói SYN/ phút là có thể dần dần vắt kiệt tài nguyên của nạn nhân. Một

kiểu tấn công SYN ít phổ biến hơn đó là tấn công tràn gói SYN với cổng ngẫu nhiên.Trong đó, kẻ tấn công tạo ra một khối lượng lớn các gói tin TCP SYN nhắm mục tiêu

cổng ngẫu nhiên của nạn nhân, với mục tiêu áp đảo tài nguyên mạng của nạn nhân, hơn

là làm đầy bộ nhớ đệm của nạn nhân.

Tấn công vào giao thức rất khó để có thể chống lại bằng phương pháp sửa chữa,

tạo bản vá. Bởi tạo bản vá yêu cầu phải thay đổi giao thức, trong khi thực tế cho thấy

việc thay đổi giao thức internet gần như là bất khả thi. Trong một số trường hợp, việc sử

9



dụng giao thức hiện tại một cách thông mình có thể giải quyết vấn đề. Như việc sử dụng

TCP SYN cookies có thể giải quyết được tấn công tràn gói SYN mà chỉ cần thay đổi

cách server xử lý kết nối đến.

1.3.3 Tấn công vào MiddlewareCác cuộc tấn công có thể được thực hiện trên các thuật toán, chẳng hạn như hàm

băm mà thông thường sẽ thực hiện các hoạt động của mình trong thời gian tuyến tính

cho mỗi mục tiếp theo. Bằng cách chèn các giá trị mà tạo ra các trường hợp xấu nhất,

kẻ tấn công có thể khiến các ứng dụng thực hiện chức năng của mình trong thời gian

tiếp theo hàm mũ đối với mỗi tham số nhập vào.

Khi kẻ tấn công có thể tự do gửi dữ liệu được xử lý bằng cách sử dụng hàm băm dễ bị

tổn thương, hắn có thể gây ra việc CPU của máy chủ bị sử dụng quá năng lực khiến chonhững hoạt động bình thường chỉ tốn vài phần của giây để xử lý, giờ phải mất vài phút

để hoàn thành. Và nó cũng không cần đến một số lượng lớn request để thực hiện cũng

có thể làm quá tải các ứng dụng, khiến nó không còn năng lực để phục vụ được người

dùng hợp pháp.

1.3.4 Tấn công vào ứng dụng

Những kẻ tấn công có thể nhắm mục tiêu một ứng dụng cụ thể và gửi gói tin để

đạt tới giới hạn của yêu cầu dịch vụ ứng dụng này có thể xử lý. Ví dụ, các máy chủ web phải mất một thời gian nhất định để phục vụ yêu cầu trang Web bình thường, và do đó

sẽ tồn tại một số hữu hạn các yêu cầu tối đa cho mỗi giây mà họ có thể duy trì. Nếu

chúng ta giả định rằng các máy chủ Web có thể xử lý 1.000 yêu cầu mỗi giây để tải các

file tạo nên trang chủ của một công ty, do đó nhiều nhất là 1.000 yêu cầu của khách

hàng có thể được xử lý đồng thời. Chúng ta giả định là máy chủ Web này bình thường

xử lý hàng ngày là 100 yêu cầu / giây (một phần mười công suất).

Nhưng nếu kẻ tấn công điều khiển 10.000 máy agent, và có khả năng mỗi một máytrong số đó có thực hiện một yêu cầu mỗi 10 giây đến máy chủ Web? Đó là tần suất

1.000 yêu cầu / giây, cộng thêm vào giả định giao thông bình thường nữa trở thành

110% công suất của máy chủ. Bây giờ một phần lớn các yêu cầu hợp pháp sẽ không thể

thông qua bởi vì máy chủ bị bão hòa.

Cũng như các cuộc tấn công vào middle ware, một cuộc tấn công ứng dụng có thể

không làm tê liệt toàn bộ máy chủ lưu trữ hoặc xuất hiện như một số lượng lớn các gói

10



tin gửi tới server. Vì vậy, một lần nữa, nhiều cách phòng thủ không thể giúp bảo vệ

chống lại loại hình tấn công này.

1.3.5 Tấn công vào tài nguyên

Những kẻ tấn công có thể nhắm mục tiêu một tài nguyên cụ thể như chu kỳ CPUhoặc khả năng chuyển đổi router. Trong tháng 1 năm 2001, Microsoft phải chịu một lỗi

mất điện được báo cáo gây ra bởi một lỗi cấu hình mạng. Điều này đã phá vỡ một số

lượng lớn tài sản của Microsoft. Khi tin tức về cuộc tấn công được công bố, người ta đã

phát hiện ra rằng tất cả các máy chủ DNS của Microsoft ở trên cùng một network

segment, phục vụ bởi cùng một router. Sau đó kẻ tấn công nhắm vào cơ sở hạ tầng định

tuyến ở phía trước của các máy chủ và đánh sập tất cả các dịch vụ trực tuyến của

Microsoft.Microsoft nhanh chóng di chuyển để giải tán các máy chủ tên miền của họ đi nơi

khác và cung cấp định tuyến đường dẫn dự phòng đến các máy chủ để gây khó khăn cho

kẻ tấn công trong việc phá hoại hoạt động dịch vụ của họ. Loại bỏ tắc nghẽn và nâng

cao năng lực có thể giải quyết các cuộc tấn công tài nguyên, tuy nhiên kẻ tấn công có

thể đáp lại bằng các cuộc tấn công mạnh mẽ hơn nữa. Và đối với các công ty có nguồn

tài nguyên ít hơn so với Microsoft, vượt quá khả năng cung cấp và dịch vụ phân tán về

mặt địa lý có thể không phải là một lựa chọn khả thi về tài chính.1.3.6 Pure Flooding

Với một số lượng đủ lớn các agent, kẻ tấn công chỉ cần gửi bất kì loại gói tin nào

đến mục tiêu, càng nhanh càng tốt từ mỗi máy là đủ tiêu thụ hết băng thông mạng của

mục tiêu. Đây được gọi là cuộc tấn công tiêu thụ băng thông. Nạn nhân không thể một

mình chống đỡ lại được cuộc tấn công này, vì các gói tin hợp pháp được gửi vào liên kết

giữa nhà cung cấp dịch vụ và mạng của nạn nhân. Vì vậy, nạn nhân thường phải yêu

cầu sự giúp đỡ của các ISP để lọc ra các gói tin tấn công gửi tới.

Trong các trường hợp đó, thường các ISP cũng bị ảnh hưởng bởi cuộc tấn công, ít

nhất là trên router kết nối giữa mạng của ISP và của nạn nhân. Thường chính họ cũng

cần phải lọc lại trên router và thậm chí còn phải yêu cầu nhà cung cấp đường truyền

upstream lọc các giao thông đến mạng của họ. Trong vài trường hợp, các gói tin tấn

công là đơn giản để lọc như các gói tin UDP đến các cổng không được sử dụng, các gói

tin với giá trị IP 255. Ở trường hợp khác, các gói tin rất khó để lọc, như gói DNS query,

http request… thì việc lọc sẽ loại cả các gói tin hợp lệ, do đó sau khi lọc thì giao thông

11



gửi tới khách hàng của nạn nhân sẽ trở về không, kẻ tấn công đạt được kết quả của tấn

công DoS.

1.4 IP Spoofing

Một chiến thuật được sử dụng trong các cuộc tấn công nguy hiểm, đặc biệt ở DDoS đó là IP Spoofing, hay IP giả mạo. Trong các gói tin mạng bình thường, trường

tiêu đề sẽ là nơi chứa địa chỉ IP của máy nguồn, địa chỉ máy đích. Giả mạo IP diễn ra

khi một phần mềm độc hại tạo ra các gói tin riêng và thay thế địa chỉ IP nguồn bằng một

địa chỉ IP nào khác, thông qua việc tạo và thiết lập các raw socket, socket do người dùng

định nghĩa.

Có một vài mức giả mạo ip khác nhau:

- Giả mạo IP một cách ngẫu nhiên: phần mềm sẽ tạo ra một địa chỉ IPv4 ngẫu

nhiên trong khoảng từ 0.0.0.0 đến 255.255.255.255. Trong một số trường hợp, nó sẽ tạo

ra các địa chỉ IPv4 sai, như địa chỉ thuộc miền 192.168.0.0 là miền dùng cho mạng cá

nhân, hoặc địa chỉ multicast, broastcast, địa chỉ không tồn tại (như 0.1.2.3). Tuy vậy

trong hầu hết trường hợp thì nó đều tạo được địa chỉ IP hợp lệ và có thể định tuyến

được.

- Giả mạo mặt nạ mạng: Nếu một máy thuộc mạng 192.168.1.0/24 thì nó dễ dàng

giả mạo một máy nào khác ở trong cùng một mạng, ví dụ như máy 192.168.1.34 có thể

giả mạo dễ dàng máy 192.168.1.35 hoặc 192.168.1.99.

- Giả mạo chính địa chỉ của nạn nhân: Đây là một kiểu giả mạo rất nguy hiểm nếu

như máy chủ nạn nhân không có được những thiết lập phòng chống. Kẻ tấn công chỉ

cần đơn giản giả mạo địa chỉ của máy nạn nhân, gửi một gói tin request, ví dụ như gói

tin TCP SYN, và nếu máy nạn nhân không có một cơ chế lọc tốt, nó sẽ nhận gói tin, cấp

phát tài nguyên cho request và gửi trả lời lại cho chính nó. Điều này dẫn tới một vòng

lặp vô tận trong chính máy nạn nhân, giữa một bên cần nhận thông tin phản hồi còn một bên thì không bao giờ gửi thông tin phản hồi đó cả.

Trong thực tế, giả mạo địa chỉ IP không phải là cần thiết cho một cuộc tấn công

DDoS thành công, bởi vì kẻ tấn công có thể vắt kiệt tài nguyên và khả năng xử lý của

nạn nhân với một lượng lớn các gói tin mà không cần liên quan gì đến địa chỉ nguồn cả.

Tuy vậy một số kẻ tấn công sử dụng IP Spoofing cho một vài lý do, như để che giấu địa

chỉ của các agent, từ đó che giấu được địa chỉ của handler và của kẻ tấn công tốt hơn,

hoặc sử dụng cho tấn công phản xạ nhiều vùng DRDoS là hình thức tấn công mạnh nhất

12



hiện nay giả mạo địa chỉ IP của nạn nhân để yêu cầu một số server lớn gửi các truy vấn

hợp pháp đến server nạn nhân, kết quả là nạn nhân bị tấn công các server lớn trên thế

giới, và không thể nào chống đỡ nổi. IP Spoofing cũng giúp kẻ tấn công vượt qua cơ

chế bảo vệ của một số máy chủ khi họ lưu địa chỉ các khách hàng thường xuyên và dùng

nó làm danh sách địa chỉ tin cậy ưu tiên truy cập trong trường hợp bị tấn công.

1.5 Xu hướng của DoS

Có một cuộc chạy đua liên tục giữa những kẻ tấn công và người phòng thủ. Ngay

sau khi có một phương thức hiệu quả bảo vệ chống lại một loại tấn công, những kẻ tấn

công thay đổi chiến thuật, tìm kiếm một cách để vượt qua những biện pháp bảo vệ này.

An ninh mạng được nâng cao, kẻ tấn công càng cải thiện công cụ của họ, thêm các tùy

chọn chỉ định cấp giả mạo hoặc mặt nạ mạng giả mạo. Một số lượng lớn các cuộc tấncông giả mạo ngày nay sử dụng subnet, vượt qua được hầu hết các bộ lọc giả mạo ip.

Các kỹ thuật mới trong chống phân tích khiến việc phát hiện ra nhiệm vụ của công cụ

tấn công khó khăn hơn. Việc che giấu mã thực thi bằng mã hóa thực hiện trong cả hệ

điều hành Windows và Unix. Các mã che giấu như burneye, Shiva, và burneye2 đang

được giám sát bởi các nhà phân tích an ninh để giải mã được chúng.

Xu hướng phát triển các công cụ tấn công DDoS theo các chiến lược nâng cao

phản ứng phòng thủ sẽ vẫn tiếp tục. Điều này được dự báo trong phân tích trinoo gốc,và xu hướng sẽ tiếp tục không suy giảm. Có rất nhiều kịch bản tiềm năng của DDoS rất

khó khăn cho cơ chế bảo vệ để xử lý.

Chương 2: CÁC BIỆN PHÁP PHÒNG CHỐNG

TRUYỀN THỐNG

Ngay sau khi các cuộc tấn công quy mô lớn đầu tiên, nhiều nghiên cứu đã được

dành riêng cho các vấn đề mới về ngăn chặn, loại bỏ, và bằng cách nào đó lọc ra các

cuộc tấn công DoS nhằm vào các hệ thống đầu cuối host. Trong khi DDoS là một vấn

đề tương đối mới, các nghiên cứu liên quan đã tồn tại trong lĩnh vực kiểm soát tắc

13



nghẽn, giảm nhẹ các cuộc tấn công DoS đơn giản, dung thứ lỗi, và duy trì hoạt động của

node trong mạng.

Nhiều nghiên cứu đã cố gắng tiếp cận để giải quyết bài toán con nhỏ hơn của vấn

đề phức tạp này. Do tính chất nhạy cảm của dữ liệu trong mạng và sự phức tạp của hiệntượng này, thật khó để hiểu một cách đầy đủ ảnh hưởng của DDoS. Nhiều nguyên mẫu

được kiểm tra trong các môi trường phòng thí nghiệm mà không có nền hay giao thông

hoạt động. Một số ý tưởng cho rằng giao thông tấn công chủ yếu là giả mạo, và điều này

rõ ràng là sai lầm, và những người khác cho rằng kiến thức nhất định về topology của

mạng, hoặc truy cập vào cơ sở dữ liệu có thể nhận biết được lưu lượng truy cập là

DDoS hay không. Những người khác yêu cầu sửa đổi đáng kể về cơ sở hạ tầng Internet,

điều có thể làm cho nó trở thành không tương thích với các giao thức hiện tại và các ứng

dụng của khách hàng, hoặc là không thực tế về kỹ thuật, chính sách, hoặc lý do chính

trị.

Chương 2 này sẽ thảo luận về một số phương pháp tiếp cận nghiên nghiên cứu đã

được thực hiện và triển khai.

2.1 Biện pháp pushback

Pushback, đề xuất của Mahajan [19] vào tháng 7 năm 2002 , nổi lên từ các cuộc

thảo luận trong nhóm nghiên cứu DDoS tại hội thảo DSIT, Trung tâm Điều phối CERT.Ý tưởng, lấy từ thực tế, là nhà quản trị mạng cố gắng để đẩy lùi các giao thông tấn công

trở lại nguồn của nó, hoặc bằng cách rút một cáp mạng trong các bộ định tuyến và xem

liệu lưu lượng truy cập có dừng lại không, hay bằng cách quan sát lưu lượng mạng trên

các thiết bị giám sát. Giới hạn tỷ lệ gửi gói tin ra ngoài từ nạn nhân (pushback), sau đó

giảm bớt áp lực vào nạn nhân, cho phép nó trao đổi lưu lượng truy cập và tồn tại hiệu

quả trong một thời điểm khi các nguồn tấn công ngừng hoặc gỡ bỏ. Trường hợp này với

giả định rằng các vi phạm giao thông phân bố không đều trên tất cả các điểm có thểthâm nhập.

Có hai kỹ thuật sử dụng ở đây: Điều khiển tắc nghẽn tổng hợp (ACC) cấp địa phương

và pushback. Điều khiển tắc nghẽn tổng hợp cấp đại phương phát hiện ra tắc nghẽn ở

cấp router và đặt một tín hiệu tấn công (hoặc nhiều hơn trong từng bối cảnh thích hợp),

một tín hiệu tắc nghẽn, mà có thể được dịch ra trong một bộ lọc router. Các tín hiệu

định nghĩa ra một tập hợp băng thông cao, một tập hợp con của lưu lượng mạng, và điều

khiển tắc nghẽn tổng hợp địa phương xác định tỷ lệ giới hạn thích hợp cho tập hợp này.

Pushback sau đó gửi tỉ lệ giới hạn này ngay lập tức đến những giao thông upstream lân

14



cận, nơi đóng góp số lượng lớn của giao thông tổng hợp. Cơ chế này hoạt động tốt nhất

chống lại kiểu tấn công gửi tràn DDoS và flash, vì chúng chia sẻ những đặc điểm chung,

và cố gắng để xử lý những hiện tượng từ góc độ của công việc kiểm soát tắc nghẽn.

Việc đặt ra giới hạn tỷ lệ quá cao có thể khiến các giao thông hợp lệ cũng bị giới hạn,

mất mát, còn việc đặt ra giới hạn quá thấp có thể khiến kẻ tấn công vượt qua được sự

bảo vệ.Nói chung, pushback dường như đòi hỏi các mô hình triển khai tiếp cận tới

router. Phương pháp tiếp cận hiện tại không thể đẩy tỷ lệ giới hạn qua một router mà

không hiểu phương pháp pushback. Pushback cũng yêu cầu các router duy trì các trạng

thái về luồng giao thông, đó là một gánh nặng thêm về cơ sở hạ tầng mạng của phương

pháp.

2.2 Biện pháp Traceback

Các đề xuất đầu tiên cho việc bảo vệ chống lại DDoS bao gồm phương pháp

traceback, thực hiện lần dấu ngược lại đến địa chỉ các agent trong mạng lưới DDoS để

tìm ra vị trí của kẻ tấn công. Giả định này dựa trên một số công cụ DDoS giả mạo các

nguồn tương đối ít về số lượng các agent (100-2,500). Đến nay, khi số lượng các agent

tham gia tấn công có thể thường xuyên lên tới con số hàng vạn, thì phương pháp

traceback vẫn có thể giúp chúng ta có thể truy ngược lại subnet của kẻ tấn công, từ đó

nhờ vào việc block traceback từ kẻ tấn công, tác hại của cuộc tấn công sẽ bị hạn chế

đáng kể.

Một đề xuất sớm đó là Traceback qua gói ICMP bởi S.Bellovin [20] vào tháng 11-

2001, thông qua việc gửi gói tin ICMP, xác suất mỗi n gói (trong đề xuất ban đầu

n=20.000), chứa một phần của gói tin bị bắt, từ các router quan sát đến đích. Điểm bất

lợi là khi bị tấn công nặng nề với số lượng gói tin gửi đến quá lớn, một mục tiêu có thể

bị mất những gói do tắc nghẽn của các thiết bị mạng, và một số mạng không cho phép

gói ICMP được đi qua biên giới router của họ. Thậm chí các gói ICMP cũng sẽ tạo ra

lưu lượng truy cập bổ sung hướng đến nạn nhân, góp phần thêm vào tắc nghẽn này.

Đề nghị sau đó được sử dụng một kỹ thuật được gọi là đánh dấu gói dựa theo xác

suất (PPM, Probabilistic Packet Marking

). Một lần nữa, mỗi 20.000 gói gửi đến đích,

một router sẽ đánh dấu một gói tin với một tham chiếu đến chính nó.Một tần số lấy mẫu

thấp đã được lựa chọn để tránh một gánh nặng về cơ sở hạ tầng định tuyến do đánh dấu

một khối lượng lớn truy cập trong một cuộc tấn công gửi tràn gói tin. Bằng cách phân

tích một số gói dữ liệu được đánh dấu từ một nguồn nhất định, các nạn nhân của cuộc

tấn công sẽ cố gắng xây dựng một con đường quay trở lại kẻ tấn công, hoặc ít nhất là tới

15



mép gần nhất với người tấn công vào cơ sở hạ tầng đánh dấu. Đề nghị ban đầu của

Savage, 8-2000, đã không có bất kỳ quy định để xác thực đối với những dấu hiệu,

nhưng sau đó đã có thêm kĩ thuật sử dụng một đề nghị xác thực và toàn vẹn kiểm tra do

D.X.Song nêu lên vào tháng 3-2001 tại IEEE INFOCOM 2001.

Traceback dựa trên kĩ thuật băm, đề xuất bởi A.C.Snoeren vào tháng 8-2001 yêu

cầu router tham gia để ghi nhớ mỗi gói đi qua nó, nhưng trong một thời gian hạn chế.

Điều này cho phép truy tìm các cuộc tấn công một gói như "Ping of Death", nhưng chỉ

khi truy vấn nhanh. Các bộ máy cô lập nguồn (SPIE, Source Path Isolation Engine) nhớ

các gói thông qua việc tính toán hàm băm với các phần bất biến của một tiêu đề IP (ví

dụ, TTL và checksum). Để tăng thêm không gian bổ sung, hàm băm yếu, thay vì băm

mã hóa mạnh, được triển khai dưới hình thức các bộ lọc Bloom Filter. Những bản ghi

thụ động không cần phải tồn tại bên trong các router ngay cả khi các thiết kế phần cứng

để đưa chúng vào các router đã được thảo luận. Các nhà thiết kế SPIE nghĩ ra một cách

để đặt một bản ghi bị động trên mỗi giao diện của router. Một số người khi đó đã chỉ

trích và cho rằng nó sẽ là quá đắt để thêm một thiết bị cho mỗi giao diện, do đó, thiết bị

SPIE đã được mở rộng để có một SPIEDER với nhiều kết nối cho mỗi giao diện trên

router. Mặc dù hàm băm yếu cho phép có lỗi, chúng sẽ nhanh chóng được định hướng

qua nhiều hàm băm được áp dụng tại các bộ định tuyến khác nhau khi khoảng cách tăng

dần từ nạn nhân. Nạn nhân khởi tạo một yêu cầu traceback thông qua một mạng lướithay thế (thật hay ảo) kết nối các nhà quản lý traceback, các agent sinh dữ liệu, và các

bộ định tuyến. Do khối lượng giao thông lớn trên các mạng xương sống, thời gian giữa

việc nhận một gói tin vi phạm và yêu cầu cho traceback sẽ mất khoảng một vài phút, tùy

thuộc vào năng lực và mạng lưới giao thông.

Một kĩ thuật thứ tư sử dụng traceback, do D.Dean và các đồng nghiệp của ông đề

xuất vào tháng 2 năm 2001, là một cách tiếp cận đại số đối với vấn đề traceback. Tương

tự một phương pháp của Savage và đồng nhiệp tại ACM SIGCOMM tháng 8-2000, kỹthuật này một nhúng phần thông tin lần vết vào các gói tin IP ở cấp bộ định tuyến. Đề

án này mới sử dụng các kỹ thuật đại số để mã hóa thông tin đường dẫn thành các gói và

để tái tạo lại chúng vào trang web của nạn nhân. Các tác giả hy vọng sẽ đạt được sự linh

hoạt hơn trong việc thiết kế và cải tiến trong loại bỏ thông tin thừa kẻ tấn công tạo ra và

cung cấp khả năng traceback đa tuyến.

PPM và đề xuất traceback với cách tiếp cận đại số cùng theo một số giả định như

sau:

16



- Kẻ tấn công có thể gửi bất kỳ gói tin.

- Nhiều kẻ tấn công có thể hành động với nhau.

- Kẻ tấn công nhận thức được sự hoạt động của các chương trình traceback.

- Kẻ tấn công phải gửi ít nhất là hàng ngàn gói.

- Tuyến đường giữa các máy nói chung là ổn định, nhưng các gói tin có thể bị sắp

xếp lại hoặc bị mất.

- Router không thể thực hiện nhiều tính toán cho mỗi gói tin.

- Router giả định là không thể bị chiếm dụng, nhưng không phải tất cả router đều

phải tham gia traceback.

Những giả định phân biệt rõ ràng những kỹ thuật này với một kỹ thuật đơn góinhư traceback dựa trên kĩ thuật băm. D.Dean và đồng nghiệp thảo luận về hiệu quả so

với Savage, khi những yêu cầu không gian khác nhau giữa 18 và 21 bit. Trong một số

trường hợp, họ đạt được kết quả tốt hơn một chút cho việc tái tạo lại đường đi, nhưng số

trường hợp tính toán sai vẫn còn cao. Ngoài việc đánh dấu gói tin, một đề án out-of-

packet đã được đề xuất, tương tự như Bellovin vào tháng 8-2001. Các tác giả nhận ra

rằng việc cải tiến thuật toán là cần thiết, và việc tìm ra các tối ưu khác cần được khám

phá. Khái niệm này cần cải tiến hơn nữa, nhưng có thể phát triển thành một khái niệmđầy hứa hẹn trong thời gian dài.

2.3 Biện pháp D-WARD

D -WARD, đề xuất của Mirkovic và các đồng nghiệp [15] vào tháng 8-2003,

được phát triển tại UCLA dưới tài trợ của chương trình DARPA Fault Tolerant Network

(FTN). Hệ thống này dựa trên mạng nguồn nhằm mục đích phát hiện các cuộc tấn công

trước hoặc khi chúng rời khỏi mạng lưới DDoS của các agent. Nó là một hệ thống nội

tuyến, trong suốt với người sử dụng trên mạng, thông qua việc tập hợp số liệu thống kê

giao thông hai chiều từ các router biên tại các mạng nguồn và so sánh chúng với các mô

hình giao thông mạng xây dựng dựa trên giao thức ứng dụng và giao vận, phản ánh sự

bình thường (hợp pháp), nghi ngờ, hoặc hành vi tấn công Dựa trên mô hình ba tầng này

(tấn công, nghi ngờ, bình thường), D-WARD áp dụng tỷ lệ giới hạn tại router ở tất cả

các giao thông đi ra của một đích cho trước, ưu tiên giao thông kết nối hợp pháp, hơi

17



làm chậm lại lưu lượng truy cập đáng ngờ, và làm chậm lại các kết nối tấn công mà nó

cảm nhận. Tỷ lệ giới hạn năng động và thay đổi theo thời gian, dựa trên quan sát của tín

hiệu tấn công và các chính sách hạn chế về giao thông tiêu cực. Ít giao thông tiêu cực sẽ

làm giảm nhẹ các chính sách hạn chế.

Giống như hầu hết các hệ thống nghiên cứu, D-WARD đã được thử nghiệm với một

homegrown thiết lập các tiêu chí chuẩn DDoS, và giống như hầu hết các hệ thống

nghiên cứu, nó hoạt động tốt theo các tiêu chí chuẩn. Tuy nhiên, hệ thống D-WARD

cũng trải qua nhiều thử nghiệm độc lập vào cuối chu kỳ chương trình DARPA FTN.

Những thí nghiệm chỉ ra rằng D-WARD có khả năng để nhanh chóng phát hiện những

vụ tấn công tạo ra dị thường ở giao thông hai chiều, chẳng hạn như tấn công gửi tràn

nặng nề. D-WARD kiểm soát hiệu quả tất cả các giao thông, trong đó có giao thông tấncông, và có thiệt hại và một mức độ sai lầm chủ động thấp. Nó kịp thời khôi phục hoạt

động bình thường khi kết thúc cuộc tấn công. Bằng cách giới hạn tỷ lệ lưu lượng tấn

công hơn là ngăn chặn nó, hệ thống này một cách nhanh chóng phục hồi từ các sai lầm

chủ động . Theo thiết kế, nó ngừng các cuộc tấn công tại nguồn mạng, do đó, nó yêu cầu

việc triển khai trên rộng (bao gồm một phần lớn các nguồn thực tế) để đạt được hiệu

quả mong muốn. Trừ khi có một hình phạt cho các các hosting của DDoS agent đặt ra

đối với các mạng nguồn, đây không phải là một hệ thống mà nhà khai thác mạng sẽ hămhở triển khai, bởi D-WARD không cung cấp một lợi ích đáng kể cho các nhà triển khai

này. Tuy nhiên, nó có thể được thể tích hợp nó với cơ chế bảo vệ khác (như Cossack tại

mục 2.7) mà có yêu cầu hành động từ mạng nguồn, để cung cấp các response chọn lọc

cho request.

Tóm lại, lợi thế của D-WARD nằm trong việc phát hiện và kiểm soát các cuộc tấn

công, giả định rằng giao thông tấn công thay đổi đầy đủ so với các mô hình giao thông

bình thường. Theo thực tế rằng D-WARD chọn lọc giới hạn tỷ lệ lưu lượng truy cập, nó

có thiệt hại thấp, và đáp ứng tấn công tương đối nhanh. Mặt khác, những kẻ tấn công

vẫn có thể thực hiện các cuộc tấn công thành công từ các mạng không được trang bị với

hệ thống này.

2.4 Biện pháp NetBouncer

NetBouncer, đề xuất của O'Brien [11], cũng nổi lên từ chương trình DARPA FTN.

Đây là một cơ chế xác thực người dùng khi đứng ở trên mạng của Server mục tiêu. Lý

tưởng nhất, nó được định vị tại điểm nút của mạng lưới và nhằm mục đích chỉ cho phép

18



các gói tin đến từ khách hàng hoặc người sử dụng "hợp pháp". Một số thử nghiệm cho

tính chính đáng được thực hiện trên máy khách, ví dụ, một gói ping (ICMP Echo) thử

nghiệm được gửi để xem liệu có một khách hàng thực sự đằng sau những gói đã được

nhận được bởi Server đích, và cũng là một Reverse Turing Test, kiểm tra phân biệt giữa

người và máy. Người đọc có thể đã xem như một bài kiểm tra khi đăng ký một tài khoản

e-mail trên các dịch vụ e-mail Yahoo: khách hàng được yêu cầu nhập một cụm từ hay

chữ bị biến dạng, hiển thị trong một hình ảnh nền làm cho nó trở nên khó đọc, một bài

kiểm tra mà thường chỉ một con người có thể làm , không phải là một máy hay chương

trình tự động. Và nếu bài kiểm tra được vượt qua, chứng tỏ người dùng là “hợp pháp”,

thì yêu cầu đến Server đích được tiếp tục. Nếu không, NetBouncer chấm dứt kết nối.

Một ví dụ tương tác của một Reverse Turing Test có thể được tìm thấy trên trang

CAPTCHA tại http://www.captcha.net/.

Một khi các khách hàng đã chứng tỏ rằng người đó thực sự là hợp pháp, họ được

thêm vào danh sách của khách hàng hợp pháp và được cho ưu đãi đối với khách hàng

chưa được hợp pháp. Danh sách này được quản lý bằng kỹ thuật quản lý dịch vụ chất

lượng và đảm bảo chia sẻ công bằng các tài nguyên giữa tất cả các khách hàng hợp

pháp. Để ngăn chặn một cuộc tấn công từ việc kế thừa các thông tin của một khách hàng

hợp pháp, tính hợp pháp hết hạn sau một thời gian nhất định và cần phải được đánh giá

lại bằng cách sử dụng cùng một hoặc một vài bài kiểm tra khác nhau.

Như vậy cách tiếp cận có thể làm việc? Nó có thể đánh bại nhiều cuộc tấn công giả

mạo, bởi những bài kiểm tra challenge phải tiếp cận nguồn gốc thực sự của các gói tin

để giao dịch hoàn thành. Các tài nguyên mạng sẵn có được chia sẻ một cách công bằng

giữa các khách hàng đã được chứng minh tính hợp pháp của họ.

Tuy nhiên, NetBouncer giả định những thuộc tính nhất định của khách hàng,

chẳng hạn như khả năng để trả lời cho ping (ví dụ, để kiểm tra sự hiện diện của một

khách hàng), mà không phải tất cả khách hàng đều hỗ trợ, đặc biệt là những người có

cài tường lửa hay bộ định tuyến DSL có bật tính năng an ninh bổ sung. Mặc dù khách

hàng là hợp pháp, hệ thống không được bảo vệ chống lại các cuộc tấn công mạo danh,

nghĩa là, một kẻ tấn công có thể lợi dụng thực tế là một khách hàng hợp pháp đã thực

hiện tất cả các công việc cần thiết để chứng minh tính hợp pháp của mình với

NetBouncer và sau đó tấn công mạng nhờ việc giả mạo địa chỉ IP hợp pháp của khách

hàng. Ngoài ra, hệ thống không phải là miễn dịch với nguồn tài nguyên cạn kiệt do một

19

http://www.captcha.net/

http://www.captcha.net/



số lượng lớn các khách hàng hợp pháp. Hơn nữa, giống như tất cả phòng thủ phía mục

tiêu, nó có thể bị tràn ngập bởi khối lượng của các gói trên đường truyền đến.

Giống như tất cả các phương án phòng thủ tốt chống lại DDoS, NetBouncer có lợi

thế và hạn chế của nó. Về mặt tích cực, nó xuất hiện để cung cấp dịch vụ tốt cho kháchhàng hợp pháp trong phần lớn các trường hợp. Vì nó nằm nội tuyến trên mạng, có nghĩa

là nó không có một sự hiện diện có thể nhìn thấy trên mạng giống như một cầu nối

mạng, nó không yêu cầu sửa đổi cho các máy chủ và khách hàng trên mạng được bảo vệ

hoặc các máy chủ kết nối với nhau. Các địa điểm triển khai gần nạn nhân và nó không

yêu cầu hợp tác với NetBouncers khác. Về mặt tiêu cực, những kẻ tấn công có thể thực

hiện các cuộc tấn công thành công vào nạn nhân / mục tiêu bằng cách mạo nhận hợp

pháp hoặc tuyển dụng một số lượng lớn các agent, cả hai đều là dễ dàng đạt được thông

qua giả mạo và tuyển dụng đủ, tương ứng. Ngoài ra, NetBouncer đặt ra các giả định

nhất định về các khách hàng hợp pháp mà không phải luôn luôn được chia sẻ bởi tất cả

các khách hàng và như vậy sẽ làm cho họ bị loại trừ khỏi truy cập vào tài nguyên được

bảo vệ. Các bài kiểm tra tính hợp pháp đặt một gánh nặng đáng kể đến chính

NetBouncer và có thể gây cạn kiệt nguồn lực của các cơ chế bảo vệ.

2.5 Biện pháp “Proof of Work”

Một cách khác để tiếp cận vấn đề DDoS là để xem xét các bài toán con của cuộctấn công suy giảm kết nối. Nhiều kết nối được khởi tạo bởi kẻ tấn công để triệt tiêu số

lượng kết nối mở mà một máy chủ có thể duy trì. Một mục tiêu trong phòng chống là để

bảo tồn các nguồn lực này trong các cuộc tấn công như vậy. Là người bảo vệ, máy chủ

bắt đầu giao ra những bài kiểm tra challenge, không khác so với NetBouncer, cho khách

hàng yêu cầu kết nối. Điều này xảy ra tại mức giao thức TCP / IP, bởi hệ thống cần tập

trung vào việc bảo vệ các nguồn tài nguyên liên quan đến kết nối mạng. Các máy chủ

phân phối một câu đố mã hóa nhỏ cho các khách hàng yêu cầu kết nối, và chờ đợi một

giải pháp. Nếu khách hàng giải quyết các câu đố trong một cửa sổ thời gian nhất định,

các tài nguyên thích hợp sau đó được phân bổ trong cùng bộ nhớ đệm của mạng(phần

của hệ điều hành xử lý các giao tiếp mạng). Khách hàng mà không giải quyết được câu

đố các kết nối của họ sẽ bị bỏ qua.

Cách tiếp cận này buộc kẻ tấn công để dành nhiều thời gian và nguồn lực trước khi

đạt được một kết nối thành công đến một máy chủ hoặc mục tiêu, và làm chậm tốc độ

mà anh ta có thể làm cạn kiệt các nguồn tài nguyên của máy chủ từ bất kỳ máy nào.

Trong khi điều này có overhead thấp (máy chủ vẫn phải tạo ra và xác minh các câu đố),

20



thực tế giao thức TCP / IP thực hiện trên cả hai đầu (client và máy chủ) phải được sửa

đổi cho phương pháp này để làm việc. Cách phòng chống này này không xử lý được vấn

đề như các cuộc tấn công phân tán trong đó kẻ tấn công tạo ra các yêu cầu đủ để vắt kiệt

các tài nguyên máy chủ hoặc tấn công vắt kiệt tài nguyên cho việc tạo puzzle hay tiêu

thụ băng thông của đường mạng dẫn đến máy chủ.

2.6 Biện pháp DefCOM

DefCOM, đề xuất của Mirkovic [16]. Nó là một hệ thống phân tán kết hợp bảo vệ

nguồn cấp, nạn nhân, và lõi mạng. Nó phát hiện một cuộc tấn công đến và đáp ứng bằng

việc hạn chế tỷ lệ giao thông, trong khi vẫn cho phép lưu thông hợp pháp đi qua hệ

thống. Nó bao gồm ba loại nút (router hoặc host): node phát cảnh báo phát hiện một

cuộc tấn công, node hạn chế tỷ lệ thi hành giới hạn tốc độ trên tất cả lưu lượng đi đếnmục tiêu của cuộc tấn công, và node phân loại giới hạn tỷ lệ giao thông, phân chia các

gói tin hợp pháp với các gói tin đáng ngờ đồng thời đánh dấu mỗi gói với phân loại của

nó. Node phát cảnh báo và các node phân loại được thiết kế cho mạng lưới cạnh việc

triển khai, trong khi node hạn chế tỷ lệ được thiết kế cho phần lõi triển khai của hệ

thống.

Trong trường hợp bị tấn công, điểm phát hiện có khả năng sẽ ở các node phát cảnh

báo trong mạng nạn nhân, và node phân loại có khả năng gần với mạng lưới nguồn.DefCOM lần dấu vết các cuộc tấn công từ nạn nhân đến tất cả các nguồn lưu lượng truy

cập hoạt động (lưu lượng tấn công hoặc hợp pháp) sử dụng một mạng lưới che phủ và

thống kê trao đổi giữa các nút bảo vệ. Giới hạn tỷ lệ được triển khai bắt đầu từ nạn

nhân, và lan truyền đến các lá trên cây giao thông (phân loại gần các nguồn). Gói tin

được đánh dấu, phân loại, chuyển tải thông tin về tính hợp pháp của mỗi gói đi đến các

node hạn chế tỷ lệ. Các node hạn chế tỷ lệ cấp phát băng thông giới hạn ưu tiên cho

các gói tin được đánh dấu hợp pháp, sau đó đến những gói tin đánh dấu đáng ngờ, và

cuối cùng để các gói tin không được đánh dấu. Điều này tạo ra ba cấp độ của dịch vụ,

tạo ra dịch vụ tốt nhất với các gói tin hợp pháp.

Bất kỳ tường lửa có thể thực hiện chức năng của node phát cảnh báo. Router lõi

sẽ phải được tăng cường với một khả năng quan sát đánh dấu để thực hiện chức năng

của node hạn chế tỷ lệ. D-WARD được mô tả như là một ứng cử viên có khả năng cho

chức năng của node phân loại . Tuy nhiên, việc phân chia giao thông hợp pháp với giao

thông tấn công không cần phải được tốt như D-WARD. Một node phân loại có thể đơn

giản đánh dấu giao thông nó xét thấy quan trọng đối với khách hàng của mạng là nguồn

21



hợp pháp. Miễn là tuân theo phân loại tỷ lệ hạn yêu cầu, giao thông này sẽ không làm

tổn thương các nạn nhân.

Tóm lại, thiết kế của DefCOM là giúp phát hiện giao thông bất hợp pháp tại mục

tiêu, giới hạn tỷ lệ ở lõi, và ngăn chặn lưu lượng truy cập đáng ngờ/ lưu lượng tấn côngtại mạng lưới nguồn. Sử dụng D-WARD như hệ thống phân loại ban đầu của nó,

DefCOM cũng vươn ra xa hơn vào cốt lõi để xử lý các cuộc tấn công từ các mạng

không được trang bị node phân loại giao thông không hợp pháp. DefCOM xử lý lũ lụt,

trong khi gây ra ít sự cản trở, hoặc là vô hại cho giao thông hợp pháp. Do tính chất che

phủ của hệ thống, DefCOM tự nó tạo nên một giải pháp mở rộng và không cần tiếp cận

với triển khai thêm nhờ vào việc sử dụng kiến trúc peer-to-peer, nhưng nó yêu cầu triển

khai rộng hơn phòng thủ của nạn nhân. Theo một nhược điểm, xử lý bị hư hỏng hoặc

phá vỡ các nút trong mạng che phủ có thể khá khó khăn, và DefCOM có khả năng hoạt

động tồi tệ nếu không được xử lý.

2.7 Biện pháp COSSACK

Cozak, đề xuất của Papadopoulos [8] và phát triển bởi Đại học Nam California /

ISI, nhằm mục đích ngăn chặn các cuộc tấn công từ lúc rời khỏi nguồn mạng, nghĩa là,

các mạng lưới chứa chấp các DDoS agent. Còn gọi là watchdogs - các cơ quan giám sát,

một plug-in cho hệ thống phát hiện xâm nhập Snort, phát hiện một cuộc tấn công bằngcách phân tích và tương ứng lưu lượng truy cập qua mạng nguồn. Căn cứ vào mối tương

quan (thời gian, loại hình giao thông), việc tương ứng thực thể có thể ngăn chặn lưu

lượng truy cập tương tự và đồng thời như là một hành động nhóm, chính là các giao

thông tấn công gửi đến.

Kỹ thuật này thực thi tại mạng nguồn, kích hoạt bởi một thông báo từ các mục tiêu

của một cuộc tấn công DDoS, bằng cách lọc ra các vi phạm giao thông rõ ràng. Tuy

nhiên, nếu lưu lượng truy cập hợp pháp được xuất hiện bởi các động cơ tương quan, dẫnđến một sai lầm chủ quan, thì sau đó lưu lượng truy cập hợp pháp sẽ bị loại bỏ bởi

Cozak.

Một giả định chính của kỹ thuật này là việc triển khai các cơ quan giám sát tại

nguồn mạng. Nguồn mạng đang được ngăn cản khỏi nguồn tấn công, nhưng một mạng

lưới mà không có cơ quan giám sát vẫn có thể tham gia vào một cuộc tấn công DDoS.

Hạn chế này là phổ biến cho các hệ thống đòi hỏi phải có nguồn cấp triển khai. Không

yêu cầu sửa đổi ở mức giao thức hoặc áp dụng cho các nguồn mạng. Các thông tin liên

22



lạc giữa các nhà kiểm soát không có khả năng mở rộng, vì họ sử dụng truyền thông

multicast.

2.8 Biện pháp Pi

Pi, đề xuất của Yaar [2], là một hệ thống bảo vệ mục tiêu nạn nhân, xây dựng trên

kỹ thuật đánh dấu gói tin đã đề cập ở biện pháp traceback, chèn vào định danh đường

dẫn vào mục chưa sử dụng trong phần header của gói tin IP. Ý tưởng chính là những

định danh đường dẫn hoặc dấu vân tay xác thực được chèn vào bởi các router dọc theo

đường mạng. Các mục tiêu hoặc nạn nhân sau đó sẽ từ chối các gói tin với định danh

đường dẫn phù hợp với các gói tin đã được xác định rõ ràng như một phần của cuộc tấn

công.

Trong đề án đánh dấu Pi cơ bản, từng router tham gia đánh dấu bit nhất định trongtrường nhận dạng IP của gói tin IP. Các vị trí của kí hiệu trong trường này được xác

định bởi giá trị của trường TTL (time to live) của gói tin. Kí hiệu là một phần của bảng

băm của địa chỉ IP của router. Vì giá trị TTL được giảm đi tại mỗi router, một con

đường tiếp giáp của gói tin được xây dựng khi nó đến gần hơn với nạn nhân. Người ta

có thể quyết định ngừng đánh dấu trong một khoảng cách chặng nhất định của mạng

nạn nhân để tăng khả năng tới đích của gói tin trong đề án này.

Bộ lọc Pi có thể xảy ra một khi chương trình đánh dấu đã được cài đặt trong cơ sở hạ tầng. Đề án này giả định rằng nạn nhân biết làm thế nào để xác định số lượng lớn của

lưu lượng truy cập tấn công, ví dụ, bằng cách chọn một phần lớn của lưu lượng truy cập

đến mang nhãn hiệu tương tự. Các bộ lọc sau đó ném bỏ tất cả lưu lượng với nhãn hiệu

nhất định. Vô tình, một số lưu lượng truy cập hợp pháp chia sẻ nhãn hiệu với các cuộc

tấn công (vì nó cũng chia sẻ đường dẫn đến các nạn nhân do sự dao động và tính chất

thích nghi của mạng) cũng sẽ bị giảm xuống, mất mát.

2.9 Biện pháp SIFFYaar [3] đề xuất để giảm thiểu ngập lụt tấn công DDoS bằng cách sử dụng một cơ

chế trong khả năng của host cuối có thể phân chia lưu lượng truy cập Internet tách thành

hai lớp: đặc quyền và không đặc quyền. Host cuối có thể trao đổi capabilities sẽ được sử

dụng trong giao thông đặc quyền. Router sau đó sẽ xác minh những capabilities này một

cách không trạng thái. Những capabilities này được giao trong một động cơ chế, vì vậy

máy cư xử sai trái (máy tấn công) có thể có khả năng bị thu hồi capabilities. Trái ngược

23



với cách tiếp cận khác, kế hoạch này không đòi hỏi một cơ chế che phủ, nhưng nó có

yêu cầu sửa đổi của máy khách và máy chủ, cũng như cả ở router nữa.

Các máy khách sẽ sử dụng một giao thức bắt tay vào khả năng trao đổi, và sau đó

là lưu lượng truy cập đặc quyền sẽ được giải quyết nhanh của mạng, trái ngược với giaothông không có đặc quyền mà sẽ không nhận được ưu tiên. Có quy định tại chỗ để ngăn

chặn tấn công gửi tràn với lưu lượng truy cập đặc quyền của một người trái phép, ví dụ,

bởi một người cố gắng tạo ra capabilities (thực hiện bằng cách đánh dấu trong mỗi gói).

Nếu một máy khách với capabilities bắt đầu ngập lụt, sau đó các thông tin cho lưu

lượng truy cập đặc quyền có thể bị thu hồi với máy khách đó.

Các tác giả của cơ chế này đề xuất hai con đường: một là cơ chế Internet thế hệ

tiếp theo kết hợp những kỹ thuật này và một là cơ chế cho các giao thức mạng hiện nayở IPv4. Đó là còn chưa rõ ràng rằng những con đường sẽ chứng minh hiệu quả hay

không.

Tóm lại, kỹ thuật này cũng chấp nhận nhiều giả thiết, trong đó có giả định là máy

khách và máy chủ cập nhật các phần mềm theo giao thức TCP / IP để kết hợp sửa đổi

cần thiết cho các capabilities mới. Ưu điểm là không cần thiết phải có-liên-ISP hay hợp

tác giữa các ISP. Tuy nhiên, nó cũng giả định rằng giả mạo là hạn chế, và việc xử lý và

duy trì trạng thái được yêu cầu tại từng router. Các giao thức mạng mới yêu cầu đánh

dấu không gian trong tiêu đề gói IP, hợp tác của khách hàng và máy chủ, mỗi router

phải đánh dấu các gói tin, và tuyến đường giữa các máy trên mạng vẫn ổn định. Các giả

định này là khá hạn chế, so với những gì có thể xảy ra trong một mạng thực sự.

2.10 Biện pháp lọc đếm chặng HCF

Lọc đếm chặng, Hop-Count Filtering, được đề xuất bởi Jin [7], là một dự án

nghiên cứu tại Đại học Michigan, nhằm bảo vệ chống lại DDoS bằng cách quan sát các

giá trị TTL (thời gian để sinh sống, số lượng các chặng hoặc router mà một gói tin sẽ điqua trước khi đến đích, hoặc bị bỏ đi để tránh chặng đường quá dài hoặc lặp lại, giá trị

được giảm đi ở mỗi router các gói tin đi qua) trong các gói tin inbound. Triển khai tại

các mạng mục tiêu, nó quan sát giá trị TTL cho bất kỳ địa chỉ nguồn trên mạng mà đi

qua mạng mục tiêu, cố gắng để suy luận một số hop đếm số chặng (có nghĩa là, khoảng

cách của người gửi đến máy phòng thủ) và xây dựng bảng mà ràng buộc một IP cho

trước với số chặng.

24



Hệ thống này tạo nên dự đoán của chặng đếm bắt đầu với giá trị TTL quan sát và

đoán giá trị TTL ban đầu đã được đặt trong gói tin ở người gửi. Chỉ có một vài giá trị

như hệ điều hành sử dụng và họ là khá khác nhau, tạo điều kiện đoán chính xác. Số

chặng sau đó được tính bằng sự chênh lệch giữa TTL ban đầu và các giá trị quan sát

được.

Số chặng Hop-count phân phối theo phân phối chuẩn (chuông đường cong), vì có

sự biến đổi đủ trong giá trị TTL. Nếu kẻ tấn công muốn đạt được điều này, hắn sẽ phải

đoán đúng giá trị TTL để chèn vào một gói tin giả mạo, để số chặng suy luận phù hợp

với giá trị mong đợi. Giả mạo trở nên khó khăn, vì kẻ tấn công giờ phải giả mạo giá trị

TTL chính xác để liên kết với một địa chỉ nguồn được giả mạo và, tăng cường số chặng

khác biệt thích hợp giữa kẻ tấn công và địa chỉ giả mạo, giao thông độc hại trở nên một

mô hình dễ dàng hơn.

Trong các hoạt động chung, các bộ lọc đếm chặng là thụ động trong khi nó đang

phân tích lưu lượng và nối nó với các bảng tính đến thành lập các giả định hop. Nếu số

lượng bất xứng hợp vượt qua một ngưỡng thành lập, chương trình bắt đầu lọc. Các bàn

đến đều được cập nhật liên tục bằng cách kiểm tra một ngẫu nhiên kết nối TCP đến một

trang web trong mạng được bảo vệ. Lưu ý rằng chương trình này cố gắng để ngăn chặn

lưu lượng truy cập giả mạo. Không có gì ngăn cản kẻ tấn công khỏi việc phát động một

cuộc tấn công bằng các nguồn thực và mang giá trị TTL chính xác, và do đó các cuộc

tấn công bằng cách sử dụng các mạng bot lớn hoặc sâu với DDoS, mà không cần phải

mạo địa chỉ nguồn để thành công, vẫn sẽ là một vấn đề. Vì các loại tấn công trở nên dễ

dàng ngày hôm nay, những kẻ tấn công chỉ cần áp dụng phương pháp này trên giả mạo

địa chỉ nguồn để có thể vượt qua phòng thủ như vậy.

Giống như những cuộc phòng thủ phía nạn nhân, phương pháp này không thể giúp bảo

vệ chống lại các cuộc tấn công quy mô lớn dựa trên việc gửi tràn tới liên kết tới vào máythực hiện việc kiểm tra các giá trị TTL.

25



Chương 3: SOS VÀ WEBSOS

3.1 Giao thức Chord

Cả hai kiến trúc SOS và WebSOS đều sử dụng một kĩ thuật đó là định tuyến theo

cấu trúc, hay bảng băm phân tán DHT – Distributed Hash Tables, qua việc xây dựng

một mạng bao phủ có ứng dụng giao thức Chord, vì vậy trước tiên chúng ta sẽ tìm hiểu

về giao thức Chord này.

Giao thức Chord là một giao thức tìm kiếm phân tán được đề xuất bởi Stoica và

các đồng nghiệp [14] tại hội nghị ACM Sigcomm diễn ra vào 8/2001 qua bài báo“Chord: A Scalable Peer-to-peer Lookup Service for Internet Applications”. Chord cung

cấp hỗ trợ cho một hoạt động duy nhất: cho một giá trị key, nó sẽ ánh xạ giá trị key đó

tới một node trong mạng. Ở đây việc ánh xạ giá trị key đến node trong mạng được thực

hiện bởi một hàm băm nhất quán, băm giá trị key để cho ra một giá trị băm, chính giá trị

băm này sẽ tương ứng với node tương ứng trong mạng. Từ đó việc lưu trữ và tìm kiếm

dữ liệu trong mạng sẽ dễ dàng được thực hiện thông qua việc liên kết mỗi key với các

đơn vị dữ liệu để lưu trữ cặp key/ dữ liệu đó tại node mà key ánh xạ đến.

26



Trong mạng Chord, mỗi node được cấp phát một định danh ID thông qua một hàm

băm nhất quán trong khoảng [0, 2m] với một giá trị m định trước. Các node trong mạng

bao phủ được sắp xếp thứ tự theo định danh của chúng, và được tổ chức theo vòng,

thuận chiều kim đồng hồ.

Hình 1: Định tuyến theo Chord [14].

Mỗi node sẽ duy trì một bảng gọi là finger table, chứa đựng định danh của m node

trong mạng bao phủ. Giá trị ở hàng thứ i trong bảng finger table của node có định danh

x, là node có định danh nhỏ nhất mà lớn hơn hoặc bằng x + 2i-1. ( (mod 2m)), như hình.

Khi node x nhận được gói tin có đích là node định danh y, nó gửi gói tin đến node trongmạng theo bảng finger table của nó sao cho node này có định danh lớn nhất mà còn nhỏ

hơn y. Như ở trên hình, nếu node có định danh 7 nhận được gói tin mà đích đến có định

danh là 18, gói tin sẽ được định tuyến từ node 7 đến node 16, sau đó đến node 17. Khi

gói tin đến node 17, node tiếp theo trong mạng bao phủ là node 22, vì vậy node 17 biết

rằng node 22 là node chịu trách nhiệm cho định danh 20. Như vậy thuật toán định tuyến

của Chord sẽ khiến gói tin được chuyển trong mạng đến với node đích qua khoảng O(m)

node.

27



Chord chính là một giải pháp tốt cho rất nhiều vấn đề: cân bằng tải, phân tán, linh

hoạt, có khả năng mở rộng. Nó cũng có thể xử lý tốt khi các node tham gia và rời khỏi

mạng một cách thường xuyên.

3.2 Kiến trúc SOS

SOS được Keromytis và các đồng nghiệp của ông [4] đề xuất trong bài báo :

“SOS: Secure Overlay Services” vào ngày 21/08/2002 trong hội thảo ACM Sigcomm

2002.

Ý tưởng chính của bài báo là xây dựng nên một kiến trúc tầng bao phủ quanh

server đích, nhằm ngăn chặn kẻ tấn công khỏi việc tiếp cận để tấn công phá hoại server

và chỉ cho phép người dùng đã được xác định – confirm user, mới có thể kết nối đến

server.

Kiến trúc SOS được thể hiện như hình vẽ dưới.

Hình 2: Kiến trúc cơ bản của SOS [4]

28



Trong kiến trúc này, yêu cầu của khách hàng từ source point sẽ đi vào một lớp bao

phủ qua một node là SOAP – Secure Overlay Access Point. Do tính chất của SOS, nên

node này sẽ làm nhiệm vụ kiểm tra người dùng này có hợp lệ hay không, qua một cơ

chế xác thực, như là login. Sau khi xác thực xong người dùng, yêu cầu sẽ được chuyển

tiếp qua mạng bao phủ. Mạng bao phủ này đóng vai trò một firewall phân tán, được xây

dựng theo giao thức Chord với kĩ thuật định tuyến theo cấu trúc, sử dụng bảng băm

phân tán DHT. Giao thức Chord sẽ được mô tả trong phần tiếp theo. , và trong mạng

bao phủ, các node có thể đóng một trong các vai trò sau:

- SOAP: Secure Overlay Access Point: là các điểm truy cập cho khách hàng.

- Secret Servlet: Các node đặc biệt, mà chỉ có kết nối đến từ các node này mới

được server đích chấp nhận.- Beacon: Các node đặc biệt trong mạng bao phủ bởi nó biết được vị trí của các

secret servlet, nhờ thông báo định kì từ các secret servlet gửi tới chúng.

- Overlay Node: các node bình thường khác trong mạng.

Sau khi node SOAP đã xác thực xong người dùng, nó sẽ lấy địa chỉ Server đích

trong gói tin yêu cầu, sử dụng hàm băm của chord để đạt được một giá trị băm. Giá trị

băm này sẽ cho biết vị trí của một Beacon, nhờ đó SOAP chuyển tiếp yêu cầu người

dùng đến node Beacon đó. Khi Beacon nhận được gói tin, nó lại đọc địa chỉ Server đích,và sau đó chuyển tiếp gói tin đến Secret Servlet của server đích. Secret Servlet nhận

được gói tin từ Beacon, nó cũng tiếp tục chuyển tiếp gói tin đến Server đích tương ứng.

Vấn đề đặt ra là làm thế nào để Beacon biết được địa chỉ của Secret Servlet tương

ứng với Server đích? Điều này được thực hiện thông qua việc định kì, các Secret Servlet

tương ứng với Server đích sẽ sử dụng hàm băm của Chord với địa chỉ Server đích, nhờ

đó lấy được giá trị băm và biết được vị trí của Beacon cần biết nó. Ngay sau đó nó gửi

một thông báo đến Beacon đó, và như vậy Beacon này sẽ nhận thông báo và biết đượcSecret Servlet ứng với một Server đích.

Còn với các Server đích, cơ chế của chúng đó là install một bộ lọc ở router gần nó

nhất, và lựa chọn một số node trong mạng bao phủ SOS để làm Secret Servlet của mình,

và cho phép chuyển tiếp kết nối thông qua các bộ lọc đến Server đích. Các router ở

quanh Server đích cũng được cấu hình để chỉ chấp nhận kết nối đến từ Servlet của nó.

29



Với kiến trúc đề xuất như vậy, SOS được tin tưởng rằng sẽ trở thành một phương

pháp tiếp cận mới và mạnh mẽ trong phương pháp chủ động phòng và chống tấn công

từ chối dịch vụ.

3.3 Kiến trúc WebSOS

3.3.1 Giải pháp đề xuất

WebSOS được đề xuất bởi D. L. Cook, Morein, Keromytis cùng các đồng nghiệp

[10] qua bài báo “WebSOS: Protecting Web Servers from DDoS attacks” vào tháng 9-

2003 tại hội thảo quốc tế lần thứ 11 của IEEE về lĩnh vực mạng ICON2003, và bài báo:

“WebSOS: An Overlay-Based System for Protecting Web Servers from Denial of Service Attacks” viết vào năm 2005 [6].

Với nhiều biện pháp đã trình bày ở chương 2, cách phòng chống tấn công DDoS

đưa ra theo một cách thức bị động, khi mà tổ chức quan sát giao thông tại một điểm nào

đó, đợi tấn công xảy ra, sau đó mới phân tích các gói tin gửi đến nhằm đặt ra các cơ chế

lọc phù hợp để ngăn chặn giao thông của kẻ tấn công. Cách tiếp cận này có hai vấn đề

khá lớn. Thứ nhất đó là sự chính xác giữa việc phân biệt giao thông tấn công với giao

thông hợp lệ. Với D-Ward, DefCom, Cossack, Pi, khi một sai lầm chủ quan trong việc

phân biệt giao thông tấn công xảy ra, các giao thông hợp lệ sẽ bị loại bỏ, khách hàng sẽ

không thể truy cập vào Server đích được. Thứ hai, là việc tạo ra một cơ chế thiết lập bộ

lọc đủ sâu để có thể hạn chế tác hại của cuộc tấn công đến mức độ tối thiểu.

WebSOS dựa trên ý tưởng của SOS để xây dựng nên một kiến trúc phòng chống

tấn công từ chối dịch vụ, giúp cung cấp được kết nối đến máy chủ đích ngay cả khi hệ

thống đang là mục tiêu của một cuộc tấn công. Cải tiến ý tưởng của SOS, WebSOS sử

dụng hệ thống kiếm tra CAPTCHA để phân biệt người dùng hợp lệ với các autobot,

truyền các yêu cầu người dùng trong mạng bao phủ thông qua web proxy, xác thực

khách hàng qua giao thức SSL/TLS, mà không cần yêu cầu việc thay đổi hạ tầng cơ sở

mạng sẵn có.

3.3.2 Kiến trúc của WebSOS

Về cấu trúc mạng bao phủ, WebSOS thừa kế từ mô hình SOS như ở hình 2. Các

node trong mạng bao phủ vẫn đóng một trong các vai trò: SOAP, overlay node, Beacon,

Secret Servlet. Tuy vậy, khi không có tấn công từ chối dịch vụ, các máy khách có thể

30



kết nối trực tiếp đến máy chủ đích mà không thông qua mạng bao phủ WebSOS. Chỉ khi

hệ thống bị tấn công, nhờ các router chất lượng cao đã được cài đặt bộ lọc địa chỉ IP,

các kết nối đến từ bên ngoài sẽ bị lọc và từ chối kết nối đến các máy chủ đích, chỉ có

các Secret Servlet mới có quyền truy cập đến các máy chủ này, lúc đó mạng bao phủ

WebSOS mới thực sự hoạt động, và người dùng muốn truy nhập vào máy chủ đích phải

kết nối thông qua mạng bao phủ này.

Các SOAP là được cài đặt Web server nhằm tạo ra và thực hiện xác thực người

dùng hợp lệ thông qua bài kiểm tra CAPTCHA. Cũng trên các web server SOAP, các

applet được lưu trữ để người dùng có thể tải về và chạy proxy applet sau khi vượt qua

bài kiểm tra CAPTCHA đó.

Hình 3: Bài kiểm tra người truy cập sử dụng CAPTCHA. Từ khóa kiểm tra

trong trường hợp này là “zbyc”.

Vùng lọc xung quanh Server đích vẫn là các router mạnh được install các bộ lọc IP

để có thể lọc mọi kết nối đến Server trong thời gian diễn ra cuộc tấn công, và chỉ cho

phép kết nối từ các Secret Servlet đến được Server đích.

31



3.3.3 Cơ chế của WebSOS

3.3.3.1 Cơ chế chung

Việc kết nối thông qua mạng bao phủ WebSOS được thực hiện như hình:

Hình 4: Cơ chế truy cập và xác thực của người dùng [6]

Đầu tiên, người dùng cần biết một SOAP và truy cập đến nó. SOAP này sẽ được

cài đặt một webserver để thực hiện chức năng kiểm tra CAPTCHA hay Graphic Turing

Test- GTT, để xác nhận truy cập thực hiện bởi con người. CAPTCHA- Completely

Automated Public Turing test to tell Computers and Human Apart, là một chương trình

có thể tạo ra bài kiểm tra mà hầu hết con người đều có thể vượt qua, trong khi chương

trình tự động thì không. Trong WebSOS, CAPTCHA được tạo ra bởi chương trình

GIMPY.

Khi người truy cập đã vượt qua bài kiểm tra GTT, SOAP sẽ cấp cho người dùng

một chứng thực X.509 ngắn hạn, có mã hóa ip của người truy cập vào để làm chứng

thực cho việc truy cập vào dịch vụ web, nhằm tránh việc sử dụng lại cho agent với ip

khác tấn công.

Sau đó, SOAP sẽ yêu cầu người dùng chạy một chương trình proxy applet (signed

applet) để browser của người dùng kết nối đến Server đích thông qua proxy applet đó,

từ đó tạo kết nối SSL đến SOAP. SOAP nhận kết nối này, và chuyển tiếp kết nối qua

mạng bao phủ đến Beacon thích hợp, để Beacon sẽ chuyển tiếp đến Secret Servlet. Từ

Secret Servlet, yêu cầu được chuyển qua vùng lọc đến Server đích. Router ở vùng lọc

32



nhận thấy IP của Secret Servlet hợp lệ nên chấp nhận cho kết nối đến Server. Điều này

khiến kết nối của người dùng trở nên an toàn, và cũng khiến tuyến đường định tuyến

tăng lên, gây ra một độ trễ nhất định.

3.3.3.2 Cơ chế định tuyến

Trong mô hình WebSOS, giao thông từ một nguồn tới server đích sẽ đi qua các

node theo thứ tự: nguồn, SOAP, Beacon, Servlet và Server đích. Cơ chế định tuyến

thông thường được sử dụng để người dùng kết nối tới SOAP. Hơn nữa, do Beacon đã

biết các Servlet xác định tương ứng với các Server, cũng như Servlet cũng biết vị trí của

Server, vì vậy cơ chế định tuyến thông thường cũng được sử dụng giữa Beacon và

Servlet, giữa Servlet và Server đích. Còn giữa SOAP với Beacon, một cơ chế định tuyếncủa lớp bao phủ được sử dụng. Nhằm giảm quãng đường định tuyến giữa chúng, nhờ đó

giảm quãng đường tổng từ nguồn tới Server đích, thuật toán Chord được sử dụng trong

trường hợp này.

Trong mô hình SOS gốc, quãng đường thiết lập từ người dùng đến Server đích qua

mạng bao phủ có thể khác với quãng đường ngược lại từ Server đích tới người dùng.

Hơn nữa, response từ Server đích có thể gửi trực tiếp đến người dùng mà không qua lại

mạng bao phủ, bởi các kênh truyền thông là song công, và trong các cuộc tấn côngDDoS thì chỉ có kết nối tới các Server đích mới là bị tắc nghẽn. Cách thức có những

thuận lợi khá lớn trong việc giảm độ trễ của mạng, vì hầu hết các kết nối client/server

hiện nay là không đối xứng do các client thường nhận response nhiều hơn là gửi đi các

request.

Trong WebSOS, định tuyến được thực hiện với từng kết nối cơ bản. Mỗi request

tiếp theo trong cùng một kết nối và các response từ Server đích có thể đi theo quãng

đường ngược lại trong mạng bao phủ. Trong khi cơ chế này làm cho việc áp dụng trở nên đơn giản, nó cũng gây nên hậu quả làm cho độ trễ tăng lên đáng kể, vì hầu hết các

response đều đi qua mạng bao phủ với nhiều chặng, hơn là việc đi trực tiếp đến máy

khách để giảm quãng đường trong mạng phủ.

3.3.4 Cơ chế bảo vệ

Cơ chế bảo vệ được giả định trong trường hợp kẻ tấn công không đủ mạnh mẽ để

tấn công gửi tràn làm quá tải hoạt động của vùng lọc xung quanh các Server đích, cũng

33



như không đủ mạnh tới mức tấn công tràn làm quá tải tất cả các SOAP trong mạng bao

phủ.

Khi không có cuộc tấn công nào diễn ra, các khách hàng, cũng như các xử lý tự

động như chương trình đánh chỉ mục của google có thể truy cập Website một cách trựctiếp như các Website khác.

Khi có dấu hiệu của một cuộc tấn công từ chối dịch vụ phân tán, vùng lọc xung

quanh các Web Server được kích hoạt, các kết nối đến Website đều bị loại bỏ, ngoại trừ

các kết nối đến từ các Servlet tương ứng với các Web Server đích. Như vậy, tác hại của

một cuộc tấn công từ chối dịch vụ trực tiếp đến các Server đích bị làm giảm đến mức

thấp nhất nhờ các bộ lọc mạnh mẽ này. Kẻ tấn công muốn tiếp tục phá hoại Website chỉ

còn cách kết nối đến các Server đích qua mạng bao phủ, để thực hiện tấn công.Khi kết nối đến mạng bao phủ, thông qua việc sử dụng bài kiểm tra Graphic

Turing Test hiện đại, giao thông từ con người sẽ được phân biệt chính xác với giao

thông từ các chương trình máy tự động do sự đảm bảo của các chương trình CAPTCHA

hiện đại có thể khiến các chương trình nhận dạng chữ viết tự không thể thực hiện chính

xác. Vì vậy, các chương trình độc hại của kẻ tấn công sẽ bị giới hạn, không thể tiếp cận

để gửi gói tin phá hoại tới Server đích được.

Thêm vào đó, WebSOS sử dụng SSL qua mỗi chặng trong mạng bao phủ, nhằmmục đích để xác thực chặng trước đó, nhằm tránh việc kẻ tấn công có thể phát hiện

được một số node trong lớp bao phủ WebSOS và thực hiện giả dạng các node đó. Với

thực tế rằng chi phí về thời gian tạo và chứng thực mã hóa với thuật toán RC4 là rất nhỏ

(như ở phần 4 sẽ đề cập đến), các node trong mạng bao phủ không cần thiết phải được

cài đặt thêm chức năng đặc biệt khác, và khách hàng thì đơn giản chỉ cần được cấp một

chứng thực phù hợp từ quản trị của WebSOS.

Hơn nữa, nhằm tránh việc kẻ tấn công sử dụng IP Spoofing gửi gói tin tấn công cóIP nguồn trùng với IP của các Servlet đến Server đích, WebSOS đề xuất sử dụng cơ chế

GRE: “Generic Routing Encapsulation” theo Farinacci và các đồng nghiệp vào tháng 3-

2000, và Dommety, tháng 9-2000. Theo đó, kẻ tấn công muốn giả mạo Secret Servlet

ngoài việc cần đoán được IP của Servlet, còn phải đoán được cả giá trị khóa của GRE.

Với việc sử dụng khóa phức tạp, thì việc giả mạo Servlet là vô cùng khó khăn đối với kẻ

tấn công. Cuối cùng, nếu như kẻ tấn công có thực sự giả mạo được một vài Servlet đi

nữa, thì dựa vào việc phân tích các gói tin đến nhiều từ một vài Servlet, Server đích

34



hoàn toàn có thể chọn lại tập các Servlet cho mình, gửi thông báo mới đến chúng và các

bộ lọc ở router.

Tổng kết: Như vậy chúng ta đã xây dựng xong kiến trúc WebSOS cho việc bảo vệ

các WebSite khỏi tác động của các cuộc tấn công từ chối dịch vụ. Kiến trúc này sẽ triểnkhai qua các hoạt động chính là xác nhận người dùng hợp lệ qua bài kiểm tra Graphic

Turing Test, thực hiện kết nối SSL thông qua một proxy applet qua mạng bao phủ đến

một Servlet, và từ Servlet qua một vùng lọc đến được Server đích.

3.3.5 Đánh giá ưu, nhược điểm của kiến trúc WebSOS

Trong khi nhiều đề xuất khác xây dựng nên một hệ thống chống lại tấn công từ

chối dịch vụ một cách bị động, thì WebSOS đã đưa ra một kiến trúc chủ động đối phó

với DDoS. Người dùng có thể truy cập trực tiếp vào Website khi không có tấn côngDDoS, giúp làm giảm độ trễ của truy cập. Khi phát hiện ra một cuộc tấn công, hệ thống

được kích hoạt để hoạt động. Nhờ vào bài kiểm tra Graphic Turing Test, việc phân loại

giao thông hợp lệ và giao thông bất hợp pháp đến từ các chương trình tự động có độ

chính xác cao, giúp loại bỏ giao thông không hợp lệ khỏi việc tiếp cận và tấn công

Server đích. Việc kết nối sử dụng SSL, và việc sử dụng GRE giúp tăng cường bảo mật

trong mạng bao phủ và đồng thời giúp chống lại việc kẻ tấn công giả mạo các Servlet để

gửi gói tin tràn ngập đến Server đích. Ứng dụng của giao thức Chord giúp việc địnhtuyến trong mạng bao phủ trở nên nhanh chóng, hơn nữa cung cấp tính cân bằng tải, linh

hoạt, khả năng phân tán, mở rộng cho các node trong mạng bao phủ cũng như xử lý tốt

việc các node trong mạng bao phủ có thể gia nhập và rời khỏi mạng một cách thường

xuyên.

Tuy vậy, một số nhược điểm còn tồn tại của WebSOS đó là độ trễ còn cao do việc

yêu cầu người dùng phải thông qua nhiều chặng trung gian trong mạng bao phủ. Một

điểm nữa đó là chưa xử lý được trường hợp một node trong mạng bao phủ bị chiếm

dụng và trở thành agent của kẻ tấn công. Hoặc kẻ tấn công cũng hoàn toàn có thể bỏ qua

mạng bao phủ, và thực hiện tấn công trực tiếp vào Server đích qua vùng lọc, làm cho

vùng lọc bị vô hiệu hóa bởi việc xử lý các gói tin tràn ngập.

35



Chương 4: THỰC NGHIỆM, CẢI TIẾN VÀ KẾT

QUẢ

Thực nghiệm được tiến hành nhằm xây dựng nên một Website với sự bảo vệ của

lớp mạng bao phủ WebSOS. Đây là thực nghiệm nhằm triển khai giải pháp WebSOS đã

đề ra ở chương 3, đồng thời kiểm tra độ trễ của yêu cầu khách hàng khi sử dụng mạng

bao phủ WebSOS so với việc kết nối trực tiếp đến với server đích.

4.1 Môi trường thực nghiệm

Kiến trúc mạng bao phủ WebSOS được cài đặt trên mạng lưới các máy ảo với hệ

điều hành CentOS 5, máy tính 3.0 GHz, RAM 1GB. Chương trình có 3 module chính.

- Module CAPTCHA được cài đặt trên WebServer Xampp.

- Module Secure Tunnel Proxylet được viết bởi ngôn ngữ Java.

- Communication Control Module và module Overlay Network (Chord) được viết

bởi java, và C, tương ứng.

Website cần bảo vệ là một máy có cài đặt WebServer Xampp.

4.2 Cài đặt kiến trúc WebSOS

So với đề xuất WebSOS, kiến trúc thực nghiệm được xây dựng với cơ chế có một

số thay đổi. Các Servlet được thiết lập thủ công qua chế độ dòng lệnh chứ không thông

qua việc nhận các thông báo đến từ Server.

Với mỗi máy tính, để tham gia vào mạng bao phủ WebSOS, máy sẽ thực hiện

dòng lệnh trong Communication Control Module và module Overlay Network. Khi tham

gia vào mạng bao phủ, nếu node đó đóng vai trò Servlet, thì nó sẽ khai báo luôn một filechứa IP của các Server đích mà nó làm Servlet tương ứng. Các node khai báo file tương

ứng là file rỗng, sẽ nhận vai trò làm SOAP hoặc Beacon, hay ovelay node thông thường.

Với các máy nhận vai trò làm SOAP, ta cài đặt cho chúng thêm hai module còn lại

là module CAPTCHA để xác nhận người dùng hợp lệ, và module Secure Tunnel

Proxylet để người dùng tải về chạy proxy applet trên trình duyệt của mình.

Với các máy làm Server đích, đơn giản ta cài đặt Xampp và đặt một số file html

lên để làm Website thử nghiệm cho người dùng truy cập thông qua mạng bao phủ.

36



4.3 Kiểm tra độ trễ của các kết nối

Trong khâu kiểm tra độ trễ của các kết nối, nhằm mục đích kiểm tra để đạt được

kết quả như khi kích thước mạng bao phủ là lớn, ta dựa vào kết quả của Chord, đó là với

xác suất cao, khi trong mạng có 2m node, thì việc định tuyến chỉ đi qua m node. Vì vậy

ta tạo nên một topo mạng với m=10 node, vào định tuyến thủ công để yêu cầu người

dùng đi qua 10 node đó. Như vậy kết quả đạt được sẽ tương đương với việc kiểm tra

trong môi trường mạng bao phủ có 2m= 210= 1024 nodes.

Dưới đây là bảng kết quả tổng thời gian từ khi người dùng đưa ra request, đến khi

nhận được kết quả hiển thị trên browser, khi thực hiện định tuyến với quãng đường là

m=0, 1, 4, 7, 10 node (kết nối trực tiếp đến server, kết nối qua mạng bao phủ với quãng

đường 1 node, 4, 7, 10 node).

Server Direct 1 Node 4 Nodes 7 Nodes 10 Nodes

Google.com 1.42 2.07 2.51 2.90 3.49

Coltech.vnu.edu.vn 1.51 2.35 2.76 3.51 4.13

Test.htm (local server) 0.64 1.27 1.35 1.55 1.79

Bảng 1: Độ trễ khi thử nghiệm kết nối đến 1 số trang web

Có thể thấy, độ trễ ở đây ở số nhân 2 hoặc 3, là một độ trễ có thể chấp nhận được

khi một Website nằm trong hoàn cảnh một cuộc tấn công từ chối dịch vụ. Ở đây do việc

định tuyến qua các node thực hiện một cách thủ công, nên thời gian trễ do việc thực

hiện thuật toán định tuyến Chord bị bỏ qua. Ngoài độ trễ do việc định tuyến còn có thời

gian trễ do việc cấp và chứng thực khóa qua kết nối SSL.

Các đo đạc về thời gian xác thực khóa RSA 1024 bit do Stavrou [6] và các đồng

nghiệp sử dụng một máy Linux 3 GHz Pentium IV đo được khi dùng thư viện OpenSSL

V 0.9.7c. Đo đạc cho thấy thời gian sử dụng để xác thực người dùng là rất nhỏ, và qua

tính toán giả sử mỗi khóa xác thực hết hạn sau 30 phút, thì mỗi node có thể xác thực

cho 18 triệu người dùng mỗi giờ, đó là khi chưa cần tới tăng tốc phần cứng.

37



Bảng 2: Thời gian đăng kí và xác thực khóa RSA 1024 bit [6]

Qua các đo đạc trên có thể thấy, dù cho độ trễ là vấn đề lớn nhất của WebSOS, độ

trễ tạo ra trong các thử nghiệm là có thể chấp nhận được. Với việc các khách hàng có

thể truy nhập trực tiếp vào Website trong thời điểm không có cuộc tấn công, chỉ kích

hoạt mạng bao phủ WebSOS trong cuộc tấn công, thì thời gian trễ như vậy là có thể

chấp nhận trong việc triển khai một cách rộng rãi.

4.4 Đề xuất cải tiến

4.4.1 Vấn đề về mạng bao phủ của WebSOS

Trong khi xây dựng kiến trúc WebSOS, các tác giả giả định rằng kiến trúc

WebSOS là ổn định và chắc chắn, nghĩa là các node trong mạng bao phủ WebSOS đều

đáng tin cậy, và không bị chiếm dụng bởi kẻ tấn công, và kẻ tấn công chỉ có thể tấn

công vào hệ thống từ bên ngoài mạng bao phủ.Để nghiên cứu và cải thiện kiến trúc WebSOS, ta giả định trường hợp một, hoặc

một số node trong mạng bao phủ WebSOS bị kẻ tấn công chiếm dụng. Từ node bị

chiếm dụng này, kẻ tấn công có thể thực hiện một trong ba hình thức tấn công sau:

- Tấn công toàn vẹn dữ liệu: Tấn công toàn vẹn dữ liệu có thể trên kênh request,

bằng cách hủy bỏ gói tin hoặc kênh truyền đã thiết lập. Khi node bị chiếm dụng

hủy gói tin trên kênh request, người dùng sẽ nhận thấy rằng mình không thể kết

nối đến server. Khi kẻ node bị chiếm dụng tấn công toàn vẹn dữ liệu trên kênhtruyền đã thiết lập, chúng ta có thể phát hiện ra kiểu tấn công này thông qua giải

pháp cải tiến, hoặc ngay ứng dụng phía người dùng có thể nhận thấy được thông

qua dữ liệu gửi về sai, hoặc qua việc xác thực… để có thể chuyển sang SOAP

khác.

- Tấn công hủy gói tin: tấn công hủy các gói thiết lập kết nối khiến người dùng

không thể kết nối đến server qua node đó. Phân tích sâu hơn trường hợp này, ta

thấy trong kênh truyền đã được thiết lập, kẻ tấn công có thể hủy bỏ các gói tin

38



được truyền giữa người dùng hợp lệ và server. Tương tự kiểu tấn công toàn vẹn

dữ liệu, chúng ta có thể phát hiện kiểu tấn công này thông qua giải pháp cải tiến,

hoặc ứng dụng người dùng cũng có thể nhận thấy qua việc kết nối bị ngừng, hoặc

qua thông lượng thấp của ứng dụng.

- Tấn công gửi tràn gói tin: Một node bị chiếm dụng có thể tham gia tấn công gửi

tràn đến server đích thông qua việc gửi tràn gói tin đến Servlet.

4.4.2 Đề xuất cải tiến

Chúng ta sẽ tập trung vào kiểu tấn công thứ nhất và thứ hai: tấn công hủy gói tin,

và đưa ra giải pháp bằng cách thiết lập một cơ chế nhận diện kiểu tấn công này, và sau

đó thiết lập cho proxylet của người dùng thực hiện thay đổi SOAP để kết nối đến server

qua con đường định tuyến khác không thông qua node bị chiếm dụng. Cơ chế này đượcthực hiện theo ý tưởng bài báo [12] bằng cách gửi một gói tin thăm dò định kì đến

server đích. Áp dụng vào kiến trúc WebSOS, chúng ta sẽ cho proxylet bên người dùng

thực hiện gửi một gói tin thăm dò định kì đến server. Nếu server trả lời gói tin thăm dò

đó sai quy định đã xác định trước, thì chúng ta kết luận là trong con đường định tuyến

có một node đã bị chiếm dụng và thực hiện tấn công hủy gói tin, từ đó ta sẽ cho người

dùng tự động thay đổi SOAP để đi qua con đường định tuyến khác. Cơ chế này là trong

suốt với người dùng và người dùng sẽ không phải thực hiện xác thực hợp lệ qua SOAPmới.

Kẻ tấn công cũng có thể chỉ chặn các yêu cầu hợp lệ, ngoài ra các gói tin thăm dò

và gói tin trả lời thăm dò vẫn được truyền qua node bị chiếm dụng. Để khắc phục

trường hợp này, cơ chế cho phép người dùng khi một số các yêu cầu nhất định không có

trả lời từ phía server, thì proxylet cũng tự động kết nối đến một proxy khác, cho phép

người dùng thiết lập kết nối bình thường, không đi qua node bị chiếm dụng nữa.

Đề xuất cải tiến có thể được thể hiện dưới dạng giả mã như sau:- Đề xuất cải tiến thực hiện tại proxy applet

Thiết lập biến số lượng thăm dò không được trả lời đúng probe=0;

Thiết lập biến số lượng kết nối hỏng numD= 0;

Thiết lập số lượng kết nối thành công numS= 0;

Thiết lập biến kiểm tra kết nối hỏng drop=false;

39



(*) Nếu probe>3, thực hiện thay đổi SOAP cho client và thiết lập lại giá trị các

biến về mặc định.

Nếu numD>= 3 , thực hiện thay đổi SOAP cho client và thiết lập lại các biến về

mặc định.Gửi dữ liệu request.

Gửi dữ liệu probeRequest sau một khoảng thời gian random và tăng probe lên 1.

Kiểm tra nếu drop==true, tăng numD lên 1.

Đặt giá trị drop=true.

Nếu số lượng kết nối thành công numS>7, gán numS= 0 và numD= 0.

Nếu nhận được dữ liệu response, tăng numS lên 1, và đặt lại drop=false.

Nếu dữ liệu response là probeResponse, gán probe= 0 và numD=0;

Quay lại (*)

- Đề xuất cải tiến thực hiện tại Server đích

Nếu nhận được request là probeRequest, xử lý và gửi lại probeResponse

Như vậy theo giả mã, proxylet chạy trên client sẽ kiểm tra nếu cứ 10 lần gửi

request mà có tới 3 lần không nhận được dữ liệu response thì proxylet xem như có hành

động tấn công hủy gói tin và tự động thay đổi SOAP để kết nối đến Server.

Ngoài ra, sau một khoảng thời gian random, một gói tin probeRequest được

proxylet tại client gửi lên Server đích. Nếu như client không nhận được gói

probeResponse phù hợp, nó sẽ tăng một giá trị numD. Khi numD >=3, proxylet sẽ thực

hiện thay đổi SOAP cho client, và gán lại numD=0, tiếp tục quá trình. Còn nếu nhận

được gói tin probeResponse phù hợp, proxylet ghi nhận không có tấn công hủy gói tin,

các biến được reset, quá trình được thực hiện lại từ đầu.

4.4.3 Thực thi đề xuất

40



Để thực thi đề xuất, chúng ta thay đổi cơ chế hoạt động của proxylet, và gửi định

kì gói tin thăm dò đến server, sau đó chờ gói tin trả lời thăm dò. Nếu gói tin trả lời

không đúng, hoặc không có gói tin trả lời thăm dò thì một biến thiết lập sẵn cũng được

tăng dần, đến một giá trị xác định trước, proxylet sẽ tự động kết nối đến một SOAP

khác để đảm bảo truy cập người dùng. Ngoài ra, khi yêu cầu người dùng không nhận

được trả lời từ server, thì biến được thiết lập cũng tăng dần đến giá trị định trước đó.

Khi proxylet kết nối đến SOAP khác, biến đó sẽ được khởi tạo lại giá trị 0. Sau khi thực

nghiệm với hệ thống, tôi thấy hiệu quả của cơ chế là rõ rệt, các trường hợp khi không có

gói tin trả lời thăm dò, hoặc các gói tin trả lời từ server bị hủy bỏ, thậm chí cả khi việc

giữ đường truyền cho các gói thăm dò/ trả lời thăm dò và hủy các gói tin khác, cơ chế

vẫn có thể phát hiện và xử lý hiệu quả qua việc thay đổi SOAP. Danh sách các SOAP để

thay đổi được lưu tại từng SOAP, được proxylet đọc và lưu trong một mảng dùng đểthay đổi SOAP khác khi phát hiện có tấn công hủy gói tin.

4.4.3.1 Kịch bản thử nghiệm

Để thực thi đề xuất và kiểm định các kết quả của cơ chế đề ra, trước hết chúng ta

xây dựng nên hai kịch bản thử nghiệm như sau:

- Kịch bản 1: Giả sử một client kết nối đến một SOAP. Sau khi hoàn tất xác thực

người dùng qua bài kiểm tra CAPTCHA, người dùng download về máy và chạy một proxy applet nhằm kết nối đến SOAP. SOAP tạo chuyển tiếp yêu cầu người dùng qua

mạng WebSOS overlay node đến với Servlet, rồi đến Server đích. Trong tuyến đường từ

SOAP đến Servlet, một node trong đó có thể là một node bị chiếm dụng, và node này sẽ

thực hiện tấn công hủy bỏ gói tin. Bằng việc thực hiện khiến node vẫn gửi yêu cầu

người dùng đến Server đích cũng như lắng nghe thông điệp trả lời từ Server đích, nhưng

lại ngừng ghi vào luồng thông tin gửi ra client, node đó sẽ hủy bỏ mọi gói tin từ Server

gửi đến người dùng. Ở phía người dùng hợp lệ, sự chậm trễ trong việc nhận gói tin dẫn

đến tình trạng trang web load quá lâu, việc mất kết nối hoặc thông lượng ứng dụng thấp.

Dựa trên những biểu hiện này, ta phát hiện ra hiện tượng gói tin bị hủy nhờ vào việc

gửi và nhận gói tin probeRequest, probeResponse, và thực hiện biện pháp đối phó. Đó

là việc cấu hình khiến proxy applet đang chạy trên máy người dùng tự động thay đổi

SOAP khác. Ta thực thi kịch bản xây dựng này với cả chương trình gốc và chương trình

đã cải tiến, nhằm xem xét tác động của hình thức tấn công này với chương trình gốc,

cũng như kiểm tra khả năng của cơ chế cải tiến, xem nó có thể phát hiện và xử lý tốt

hình thức tấn công hủy bỏ gói tin của các node bị chiếm dụng hay không.

41



- Kịch bản 2: Tương tự như kịch bản 1, tuy vậy node tấn công không hủy bỏ toàn

bộ gói tin. Ta giả sử kẻ tấn công tinh vi tới mức phát hiện ra được các gói tin

probeRequest, probeResponse cho dù ta có che giấu chúng trong gói tin gửi đi tốt thế

nào chăng nữa, hoặc là kẻ địch hủy bỏ một số lượng lớn gói tin trong các gói tin nhận

được từ server, chỉ cho một số ít các gói tin đi qua để đánh lừa người dùng rằng vẫn có

kết nối tuy rất chậm, với server và một cách ngẫu nhiên các gói tin chứa probeRequest

và probeResponse đều không bị hủy, hoặc không bị hủy tới 3 gói probeResponse liên

tiếp. Như vậy theo kịch bản 2, cơ chế đề xuất gửi probeRequest và probeResponse bị vô

hiệu hóa, ta sẽ phải sử dụng cách khác để phát hiện ra là các gói tin đang bị hủy bỏ với

số lượng lớn, để biết có tấn công của một node độc hại và thực hiện thay SOAP cho

client.

4.3.3.2 Kết quả thử nghiệm

4.3.3.2.1 Với chương trình gốc

Khi thực thi kịch bản thử nghiệm với chương trình WebSOS gốc, hiện tượng trực

quan đó là ở phía client người dùng, các gói tin request được gửi đi bình thường, vì vậy

Browser vẫn chờ các gói response trong khi không hề có gói response nào tới Browser.

Trang web vẫn thông báo “Waiting for http://....”, song không thể load được trang kết

quả. Sau 20 giây (theo thiết lập tùy biến setSoTimeout trong code chương trình) khôngnhận được response, Browser thông báo “Internet Explorer cannot display the

webpage”.

42



Hình 5: Kịch bản thử nghiệm được thực thi với chương trình gốc. Các client

không thể nhận response khi trên đường định tuyến đến server có một node bị

chiếm dụng thực hiện tấn công hủy gói tin.

Kết quả tất yếu xảy ra đó là khi thực thi kịch bản với chương trình WebSOS gốc,

Browser tại client không thể nhận được response từ Server đích, tương đương với việc

các người dùng hợp lệ không thể kết nối đến Server đích khi trên đường định tuyến từ

client đến Server đích có một node bị chiếm dụng, và thực hiện hình thức tấn công hủy

gói tin. Với kịch bản thứ 2, do hầu hết các gói tin bị hủy, nên người dùng cũng gần như

không thể kết nối đến server.

4.3.3.2.2 Với chương trình cải tiến

- Kịch bản 1: Khi thực hiện kịch bản thử nghiệm 1 với chương trình cải tiến, hiện

tượng diễn ra ban đầu không khác gì so với chương trình gốc, đó là Browser không thể

nhận response từ Server, trang web vẫn chỉ thông báo “Waiting for http://....” mà không

có hiện tượng gì xảy ra. Tuy nhiên, sau một thời gian, khoảng 14 giây thì trang web load

bình thường và người dùng truy nhập thành công. Các lần truy vấn tiếp theo trở nên

bình thường, không còn có hiện load lâu như lần truy cập trước nữa.

43



Hình 6: Kịch bản thử nghiệm 1 được thực thi với chương trình cải tiến. Sau

14 giây loading với trường hợp xấu nhất (12 giây thực hiện cơ chế), Browser đã

có thể load trang web. Các request sau, Browser gửi và nhận truy vấn bình

thường. Với kịch bản thử nghiệm 2, trường hợp xấu nhất sau 3 lần truy vấn

không thành công, lần thứ 4 trở đi Browser cũng gửi nhận truy vấn bình thường.

Nguyên do là bởi cơ chế đề xuất, khi gửi truy vấn đến server thì đồng thời cứ sau 3

giây một probeRequest lại được gửi lên server (thời gian giữa 2 lần gửi probeRequest có

thể điều chỉnh), và sau 3 lần liên tiếp gửi probeRequest không thành công các proxy

applet tự động thay đổi SOAP dẫn đến thay đổi đường dẫn định tuyến từ client đến

server đích. Do đường dẫn không còn đi qua node bị chiếm dụng nữa, nên ảnh hưởng

của hành vi tấn công không còn. Đồng thời proxy applet tự động gửi lại yêu cầu qua

SOAP mới và nhận response, khiến trang web được load thành công sau khoảng thờigian chờ probeResponse mà không có trả lời. Và do đã chuyển SOAP với đường dẫn

định tuyến mới, các truy vấn sau này cũng thực hiện bình thường, không còn hiện tượng

không có response đến Browser nữa.

Cần nhấn mạnh trường hợp trên là trường hợp xấu nhất khi người dùng mới truy

cập đã gặp phải node độc hại trên đường dẫn định tuyến của mình. Ở trường hợp tốt

hơn, khi người dùng đang truy cập chẳng hạn, thì một node trong đường dẫn định tuyến

bị chiếm dụng và tấn công. Lúc này do probeRequest và probeResponse vẫn đang được

44



gửi, và bị hủy để không nhận được, sau một khoảng thời gian khoảng 12 giây (lần thứ 4

gửi probeRequest), proxy applet sẽ nhận ra node độc hại và thay đổi SOAP. Trong

khoảng thời gian này có thể người dùng vẫn chưa chuyển trang khác trong Website, ví

dụ như người dùng đang đọc báo chẳng hạn, nên người dùng sẽ không cảm nhận được

rằng SOAP bị thay đổi, khi vào trang web khác người dùng không nhận thấy sự chậm

trễ nào cả.

- Kịch bản 2: Khi thực hiện kịch bản thứ hai với chương trình cải tiến, hiện tượng

xảy ra đó là lúc người dùng load một trang web nhưng không thể kết nối đến trang web,

hoặc trang web bị mất quá nhiều phần do bị hủy số lượng lớn gói tin. Do giả định cơ

chế probeRequest và probeResponse bị vô hiệu hóa vì node tấn công vô tình không hủy

bỏ 3 gói tin probe liên tiếp nào, hoặc kẻ tấn công tinh vi tới mức cho phép các gói probe

đi qua mặc cho nỗ lực giấu gói probe của chúng ta, vì vậy chúng ta cần đưa ra giải pháp

cho kịch bản này. Giải pháp được đưa ra đó là giải pháp đếm số lượng gói tin request

mà không có được response. Chúng ta đã đưa ra tỉ lệ khi cứ trong 10 gói tin request mà

có tới 3 gói tin không nhận được response (tỉ lệ này có thể thay đổi cho phù hợp với

từng mạng) thì proxy applet cũng coi như có tấn công hủy gói tin, và thực hiện thay đổi

SOAP cho client. Vì vậy trong trường hợp này người dùng sẽ cảm thấy khó khăn hơn,

bởi vì cơ chế đếm số request không được trả lời, nên người dùng phải qua ba lần request

server mà không nhận được load được trang web. Đến lần thứ tư trở về sau, người dùngcó thể truy vấn bình thường do proxy applet đã chuyển đổi SOAP giúp người dùng

không còn bị tấn công hủy gói tin từ node độc hại nữa.

Ở trường hợp tốt hơn, khi người dùng gửi yêu cầu một trang web, giả sử response

cho yêu cầu đầu tiên đó không bị hủy, do trang web thường có nhiều thành phần, nên

một số lượng lớn các request tiếp theo sẽ được Browser tự động gửi lên server để

download các thành phần này về Browser. Vì vậy tấn công sẽ chỉ khiến người dùng cảm

thấy trang web đó thiếu nhiều thành phần, tuy vậy đến trang web sau proxy applet đãnhận ra có node độc hại, và chuyển SOAP, vì vậy người dùng lại cảm thấy thoải mái và

truy cập Website bình thường.

4.4.4 Đánh giá hiệu năng của chương trình cải tiến

Để đánh giá hiệu năng của chương trình cải tiến so với chương trình gốc, ta thực

hiện so sánh thời gian truy cập của hai chương trình vào một số địa chỉ khác nhau. Cụ

thể, qua việc đo thời gian truy cập trung bình vào một số trang web, ta được kết quả như

bảng dưới:

45



Địa chỉTruy cậptrực tiếp

Phiên bảngốc

Phiên bảncải tiến

http://nhom3.k51mmt.net.vn/main/news4st.htm 0.48 1.34 1.27

http://nhom3.k51mmt.net.vn/main/test.htm 0.84 2.97 3.12http://www.google.com 1.42 2.31 2.25

0

0.5

1

1.5

2

2.5

3

3.5

news4st_test test_local google.com

Trực tiếp

Phiên bản gốc

Phiên bản cảitiến

Hình 7: Thời gian truy vấn trung bình của các chương trình vào một số trang

web. Các chương trình đều được chạy với kiến trúc mạng bao phủ gồm có 3 node.

Thực hiện đánh giá hiệu năng của chương trình cải tiến so với chương trình gốc

thông qua việc so sánh thời gian truy cập trong trường hợp bị tấn công theo các kịch bản

1 và 2, ta được kết quả như sau:

Địa chỉ Trực

tiếp

Phiên bản gốc

(cả hai kịch

Phiên bản cải

tiến (kịch bản 1)

Phiên bản cải

tiến (kịch bản

46



bản)lần truy cập đầu

tiên2) từ lần thứ 4

news4st.htm_local 0.48 Không kết nối 14.53 2.46

test.htm_local 0.84 Không kết nối 15.19 3.57www.google.com 1.42 Không kết nối 16.34 3.22

0

2

4

6

8

10

12

14

16

18

news4st_test test_local google.com

Trực tiếp

Cải tiến_kịch bản1Cải tiến_kịch bản2

Hình 8: Thời gian truy vấn trung bình của các chương trình vào một số trang

web khi thực hiện chạy với kịch bản 1 và 2. Với phiên bản gốc, kết quả luôn là

không thể kết nối. Kiến trúc mạng bao phủ gồm 3 node. Với kịch bản 1 cơ chế

phát hiện để thay đổi mất 12 giây. Với kịch bản 2 từ lần thứ 4 truy vấn mới thành

công.

Các đo đạc cho thấy rõ sự bất lực của kiến trúc gốc khi 100% thử nghiệm đều

không thể kết nối với trường hợp node trong mạng bao phủ bị chiếm dụng và tấn công

47



hệ thống. Cơ chế cải tiến cho thấy một kết quả chấp nhận được và rất khả quan cho triển

khai.

Chương 5: KẾT LUẬN

48



Qua thời gian nghiên cứu về phòng chống tấn công từ chối dịch vụ, đặc biệt là qua

quá trình thực hiện đề tài khóa luận tốt nghiệp: “Phòng chống tấn công từ chối dịch vụ

phân tán vào các Website”, tôi đã nắm được những kĩ thuật phòng chống tấn công từ

chối dịch vụ và những kiến thức về mạng bao phủ, từ đó xây dựng và triển khai được

kiến trúc WebSOS nhằm hạn chế được các tấn công từ chối dịch vụ vào các mục tiêu

Website. Những kết quả chính mà tôi đã đạt được cũng như các kết quả hướng tới, có

thể được tổng kết lại như dưới đây:

5.1 Các kết quả đã đạt được

- Xây dựng được kiến trúc WebSOS với khả năng có thể chống lại mạnh mẽ các

cuộc tấn công từ chối dịch vụ. Hệ thống cho phép người dùng truy cập trực tiếp vào

Website, và chỉ kích hoạt khi Website bị tấn công từ chối dịch vụ. Với vùng lọc IP mạnhmẽ, cùng cơ chế xác thực người dùng hoàn hảo và việc che giấu các Servlet bí mật,

Server đích được cách ly và bảo vệ rất tốt khỏi cuộc tấn công.

- Thực hiện các thực nghiệm cho thấy độ trễ của hệ thống phòng chống tấn công

từ chối dịch vụ là chấp nhận được, với khả năng triển khai và mở rộng cao cho các Web

server công cộng phục vụ người dùng.

- Thực hiện cải tiến hệ thống bằng cách đặt giả định một hoặc một vài node trong

mạng bao phủ có thể bị chiếm dụng, và tấn công hệ thống bằng hình thức tấn công hủygói tin hay tấn công toàn vẹn gói tin, khiến người dùng hợp lệ không thể truy cập hệ

thống. Cách thức cải tiến cho thấy hiệu quả rõ rệt, và trong suốt với người dùng tạo cảm

giác thoải mái cho người dùng cho dù là trong hoàn cảnh hệ thống đang bị tấn công.

5.2 Các kết quả hướng tới

- Hướng tới việc xử lý độ trễ của kiến trúc mạng bao phủ, bằng cách phương pháp

xây dựng đường đi không đối xứng, hoặc gửi response trực tiếp từ Server đích đến

client.

- Nằm trong đề xuất cải tiến, giả định đặt ra là một node trong mạng bao phủ có

thể bị chiếm dụng và trở thành nguồn tấn công. Khi đó cơ chế xử lý đề ra là khá hiệu

quả khi node thực hiện hành vi tấn công hủy gói tin. Song do giả định node trong mạng

bao phủ có thể bị chiếm dụng, node đó còn có thể tham gia hành vi tấn công nguy hiểm

nữa đó là hành vi tấn công gửi tràn gói tin. Việc xây dựng một cơ chế hiệu quả phát

49



hiện, và loại bỏ các node bị chiếm dụng trong mạng bao phủ chính là mục tiêu cần

hướng đến.

TÀI LIỆU THAM KHẢO

50



[1] A. C. Snoeren, C. Partridge, L. A. Sanchez, C. E. Jones, F. Tchakountio,

S. T. Kent, and W. T. Strayer, "Hash-Based IP Traceback," Proceedings of ACM

SIGCOMM 2001, August 2001, pp. 3–14

[2] A. Yaar, A. Perrig, and D. Song, "Pi: A Path Identification Mechanism toDefend Against DDoS Attacks," Proceedings of the IEEE Symposium on Security and

Privacy, May 2003, pp. 93–107.

[3] A. Yaar, A. Perrig, and D. Song, "SIFF: a stateless Internet flow filter to

mitigate DDoS flooding attacks," Proceedings of the IEEE Symposium on Security and

Privacy, May 2004, pp. 130–143.

[4] Angelos D. Keromytis, Vishal Misra, Dan Rubenstein, SOS: Secure

Overlay Services, ACM SIGCOMM 2002.

[5] Angelos D. Keromytis, Vishal Misra, Dan Rubenstein, SOS: An

Architecture For Mitigating DDoS Attacks, IEEE Journal on Selected Areas of

Communications (JSAC), 2003, pages 176-188.

[6] Angelos Stavrou, Debra L. Cook, William G. Morein, Angelos D.

Keromytis, Vishal Misra, Dan Rubenstein; WebSOS: An Overlay-based System For

Protecting Web Servers From Denial of Service Attacks; Computer Networks, Volume

48, Issue 5 (August 2005), pages 781 – 807.

[7] C. Jin, H. Wang, and K. G. Shin, "Hop-Count Filtering: An Effective

Defense Against Spoofed DDoS Traffic," Proceedings of the 10th ACM Conference on

Computer and Communication Security, ACM Press, October 2003, pp 30–41.

[8] C. Papadopoulos, R. Lindell, J. Mehringer, A. Hussain, and R. Govindan,

"Cossack: Coordinated Suppression of Simultaneous Attacks," Proceedings of 3rd

DARPA Information Survivability Conference and Exposition (DISCEX 2003), vol. 2,

April 2003, pp. 94–96.

[9] D. Farinacci, T. Li, S. Hanks, D. Meyer, P. Traina, Generic Routing

Encapsulation (GRE), RFC 2784, IETF (March 2000). URL http://www.rfc-

editor.org/rfc/rfc2784.txt

[10] Debra L. Cook, William G. Morein, Angelos D. Keromytis, Vishal Misra,

Daniel Rubenstein; WebSOS: Protecting Web Servers From DDoS; Proceedings of the

11th IEEE International Conference on Networks (ICON) (2003); pages 455–460.

51

http://www.rfc-editor.org/rfc/rfc2784.txt







[11] E. O'Brien. "NetBouncer: A Practical Client-Legitimacy-Based DDoS

Defense via Ingress Filtering,"

http://www.networkassociates.com/us/_tier0/nailabs/_media/documents/netbouncer.pdf .

[12] Elaine Shi, Ion Stoica, David Andersen, Adrian Perrig, “OverDoSe: AGeneric DDoS Protection Service Using an Overlay Network”, CMU Technical Report

CMU-CS-06-114, 2006

[13] G. Dommety, Key and Sequence Number Extensions to GRE, RFC

2890, IETF (September 2000). URL http://www.rfc-editor.org/rfc/rfc2890.txt

[14] Ion Stoica, Robert Morris, David Karger, M. Frans Kaashoek, Hari

Balakrishnan, Chord: A Scalable Peer-to-peer Lookup Service for Internet Applications,

ACM Sigcomm 2001.

[15] J. Mirkovic, D-WARD: Source-End Defense Against Distributed Denial-

of-Service Attacks, PhD thesis, University of California Los Angeles, August 2003,

http://lasr.cs.ucla.edu/ddos/dward-thesis.pdf .

[16] J. Mirkovic, M. Robinson, P. Reiher, and G. Kuenning, "Forming Alliance

for DDoS Defenses," Proceedings of the New Security Paradigms Workshop (NSPW

2003), ACM Press, August 2003, pp. 11–18.

[17] Jelena Mirkovic, Sven Dietrich, David Dittrich, Peter Reiher; Internet

Denial of Service: Attack and Defense Mechanisms.chm ; Prentice Hall PTR; 2004.

[18] Michael Glenn; A Summary of DoS/DDoS Prevention, Monitoring and

Mitigation Techniques in a Service Provider Environment; SANS Institute; 2003.

[19] R. Mahajan, S. M. Bellovin, S. Floyd, J. Ioannidis, V. Paxson, and

S.Shenker, "Controlling High Bandwidth Aggregates in the Network," ACM

SIGCOMM Computer Communications Review, vol. 32, no. 3, July 2002, pp. 62–73.[20] S. Bellovin, M. Leech, and T. Taylor, "ICMP Traceback Messages,"

Internet draft, work in progress, October 2001.

[21] S. Savage, D. Wetherall, A. Karlin, and T. Anderson, "Practical Network

Support for IP Traceback," Proceedings of ACM SIGCOMM 2000, August 2000, pp.

295–306

[22] http://c.root-servers.org/october21.txt

52

http://www.networkassociates.com/us/_tier0/nailabs/_media/documents/netbouncer.pdf

http://lasr.cs.ucla.edu/ddos/dward-thesis.pdf

http://c.root-servers.org/october21.txt

http://www.networkassociates.com/us/_tier0/nailabs/_media/documents/netbouncer.pdf

http://lasr.cs.ucla.edu/ddos/dward-thesis.pdf

http://c.root-servers.org/october21.txt



[23] http://edition.cnn.com/2001/TECH/internet/05/24/dos.study.idg/

53

http://edition.cnn.com/2001/TECH/internet/05/24/dos.study.idg/

http://edition.cnn.com/2001/TECH/internet/05/24/dos.study.idg/

Documents

Pham Xuan Bach_K51MMT_Khoa Luan Tot Nghiep Dai Hoc