Luận văn Biên dịch cài đặt và triển khai hệ thống D-Ward
TRƯỜNG ………………….
KHOA……………………….
-----[\ [\-----
Báo cáo tốt nghiệp
Đề tài:
BIÊN DỊCH CÀI ĐẶT VÀ TRIỂN KHAI HỆ THỐNG D-WARD
LỜI CẢM ƠN
Đầu tiên, em xin gửi lời cảm ơn chân thành tới thày Đoàn Minh Phương đã hướng
dẫn và tạo mọi điều kiện cho em hoàn thành khóa luận này.
Em cũng xin gửi lời cảm ơn tới thày Phùng Chí Dũng, cô Bùi Thị Lan Hương đã
nhiệt tình giúp đỡ em để em có thể hoàn thành tốt khóa luận này.
Em xin cảm ơn các thày cô trong bộ môn Mạng và Truyền Thông máy tính nói riêng
và các thày cô trong trường Đại học Công Nghệ- Đại học Quốc Gia Hà Nội nói chung,
những người đã truyền đạt cho chúng em những kiến thức quý báu trong suốt 4 năm học
vừa qua.
Mặc dù khóa luận đã được hoàn thành với tất cả sự cố gắng của bản thân, nhưng vẫn
không tránh khỏi những sai sót, hạn chế. Vì vậy, em rất mong nhận được những nhận xét,
góp ý của các thày cô giáo và các bạn để đề tài này có thể được hoàn thiện hơn.
Hà Nội, tháng 05/2010
Sinh viên
Trần Tuấn Linh
Tóm tắt khóa luận
Các hệ thống máy tính hiện nay đòi hỏi khả năng bảo mật và khả năng chống đỡ lại
các cuộc tấn công rất cao. Tấn công từ chối dịch vụ là ưu tiên hàng đầu của các cơ quan
doanh nghiệp hoạt động trong lĩnh vực thương mại điện tử. Các cuộc tấn công từ chối
dịch vụ hiện tại trở nên vô cùng phức tạp và khó đoán định từ việc các nguồn tấn công
phân tán.
Đã có nhiều giải pháp được triển khai để ngăn chặn vấn đề này nhưng chưa đạt hiệu
quả cao. Khóa luận này đưa ra ý tưởng về một giải pháp triển khai hiệu quả và chi phí
thấp hơn so với những giải pháp trước đây. Đó là D-WARD nó có thể phát hiện và ngăn
chặn các luồng tấn công bằng cách điều khiển lưu lượng mạng ra ngoài từ mạng nguồn.
Đầu tiên, khóa luận đã biên dịch, cài đặt và triển khai hệ thống
D-WARD trên mô hình
thử nghiệm. Sau đó, cải tiến khả năng phân tích luồng và kết nối của các gói tin đi qua
mạng bằng việc cài đặt mở rộng thêm module cập nhật và truy vấn server quản trị cơ sở
dữ liệu.
MỤC LỤC
Chương 1.Mở đầu........................................................................................................1
1.1. Các cuộc tấn công DOS và DdoS ...........................................................................1
1.1.1. Cuộc tấn công DoS là gì?.................................................................................1
1.1.2. Tấn công DDoS là gì?......................................................................................1
1.2.1. Kịch bản của một cuộc tấn công DDoS:..........................................................2
1.3. Những vị trí triển khai hệ thống phòng chống........................................................5
1.3.1. Hệ thống phòng chống độc lập: .......................................................................5
1.3.2. Hệ thống phòng chống phân tán: .....................................................................8
1.4. Tổng kết: .................................................................................................................9
Chương 2.D-WARD..................................................................................................10
2.1. Tổng quan về D-WARD.......................................................................................10
2.2. Các thuật ngữ và giả thiết .....................................................................................10
2.3. Kiến trúc hệ thống D-WARD ...............................................................................11
2.3.1. Thành phần giám sát ......................................................................................12
2.3.2. Thành phần giới hạn băng thông....................................................................20
2.3.3. Thành phần chính sách lưu lượng..................................................................22
2.4. Các phiên bản D-WARD ......................................................................................22
2.4.1. D-WARD 1. 0 ................................................................................................22
2.4.2. D-WARD 2.0 .................................................................................................23
2.4.3. D-WARD 3.0 .................................................................................................24
2.5. Tổng kết: ...............................................................................................................25
3.1. Triển khai thành phần giám sát.............................................................................26
3.1.1. Bảng băm luồng .............................................................................................26
3.1.4. Phân loại luồng và kết nối..............................................................................28
3.2. Triển khai thành phần giới hạn băng thông ..........................................................29
3.3. Triển khai thành phần chính sách lưu lượng.........................................................30
3.3.1. Tiến trình điều khiển chính sách lưu lượng ...................................................30
3.4. Mở rộng D-WARD ...............................................................................................31
3.4.1. Mục đích của việc mở rộng............................................................................31
3.5. Tổng kết ................................................................................................................32
Chương 4.Cài đặt và các kết quả ...............................................................................32
4.1. Cài đặt hệ thống D-WARD...................................................................................32
4.1.1. Mô hình triển khai..........................................................................................32
4.1.2. Biên dịch và chạy D-WARD..........................................................................34
4.1.3. Kết quả và đánh giá........................................................................................36
4.2. Cài đặt hệ thống mở rộng......................................................................................38
4.2.1. Mô hình triển khai..........................................................................................38
Danh sách các hình ảnh
Hình 1: Mô hình tấn công DDoS.................................................................................1
Hình 2: Các điểm phòng chống...................................................................................5
Hình 3: Hệ thống phòng chống tại mạng đích ...........................................................6
Hình 4: Hệ thống phòng chống tại mạng trung gian ..................................................7
Hình 5 : Phòng chống tại nguồn..................................................................................7
Hình 6: Kiến trúc hệ thống D-WARD........................................................................11
Hình 7: Máy hữu hạn trạng thái DNS .......................................................................15
Hình 8 : Máy hữu hạn trạng thái streaming dữ liệu..................................................17
Hình 9 : Ví dụ về vấn đề phân loại gói tin đầu tiên...................................................18
Hình 10 : Bảng băm luồng.........................................................................................26
Hình 11: Bảng băm kết nối........................................................................................27
Hình 12: : Topo hệ thống D-WARD ..........................................................................33
Hình 13: File debug/class.txt.....................................................................................36
Hình 14: File rlstats.txt..............................................................................................36
Bảng các từ viết tắt
COI
Connection Observation Interval
D-WARD Ddos- network Attack and Recognition Defense
DDOS
DOS
FOI
Distributed Denial Of Service
Denial of Service
Flow Observation Interval
Internet Control Message Protocol
Internet Protocol
ICMP
IP
RTP
Real-time Transport Protocol
Real-time Streaming Protocol
RSTP
TCP
Transmission Control Protocol
Chương 1. Mở đầu
Tấn công từ chối dịch vụ là một lĩnh vực thú vị để nghiên cứu. Cho tới nay đã có
nhiều người tham gia vào nghiên cứu lĩnh vực này. Tuy nhiên, đến hiện tại vẫn chưa có
một cách thật sự hữu hiệu để phát hiện và ngăn chặn kẻ tấn công. Chương này sẽ giới
thiệu về định nghĩa của DoS và DDoS, quá trình diễn ra một cuộc tấn công và tổng quan
về một số thách thức trong phòng chống tấn công DDoS.
1.1. Các cuộc tấn công DOS và DDoS
1.1.1. Cuộc tấn công DoS là gì?
Tấn công từ chối dịch vụ (DoS): là quá trình các yêu cầu được gửi tràn ngập từ một
điểm tấn công riêng lẻ tới một hay nhiều server đích. Và các yêu cầu này thường giả mạo
địa chỉ IP nguồn. Với nhiều yêu cầu được gửi đến như vậy, những yêu cầu hợp lệ không
được đáp ứng và dẫn tới hiện tượng từ chối dịch vụ.
1.1.2. Tấn công DDoS là gì?
Tấn công từ chối dịch vụ phân tán (DDoS): là một cuộc tấn công từ chối dịch vụ
thông thường nhưng nó được thực hiện tại nhiều máy bị kẻ tấn công chiếm quyền điều
khiển (agents/zombie) và các agents này có thể ở các khu vực địa lý khác nhau. Một kẻ
tấn công có thể điều khiển các agents, và thống nhất tất cả các máy agents cùng lúc sinh
ra nhiều gói tin yêu cầu gửi tới đích. Với số lượng lớn các agents, tài nguyên hệ thống của
nạn nhân sẽ nhanh chóng bị cạn kiệt và quá tải. Hình vẽ dưới đây thể hiện mô hình của
cuộc tấn công:
Hình 1: Mô hình tấn công DDoS
1
Đầu tiên attacker sẽ sử dụng một số máy bị chiếm quyền điều khiển làm “handler”
dùng để truyền các thông điệp của cuộc tấn công tới các zombie (agents). Sau đó, đồng
loạt các zombie sẽ gửi truy vấn tới nạn nhân và làm cho tài nguyên hệ thống bị cạn kiệt và
quá tải.
Trong các cuộc tấn công DDoS, các agents thường sử dụng địa chỉ IP nguồn giả
mạo. Attacker giả mạo trường địa chỉ IP nguồn trong tiêu đề của gói tin tấn công. Điều
này sẽ làm cho nạn nhân khó có thể dò ngược ra các máy agent. Bên cạnh đó, việc làm
giả địa chỉ của các máy agent cho phép attacker sử dụng lại chúng trong các cuộc tấn
công trong tương lai. Các gói tin tấn công có nội dung không khác mấy so với các gói tin
hợp lệ cho nên cần phải xây dựng những chính sách lọc chính xác.
1.2. Quá trình diễn ra một cuộc tấn công và những thách thức
trong phòng chống
DDoS xuất hiện như một vấn đề nghiêm trọng trên mạng Internet vào giữa năm
1999. Nó đã trải qua sự phát triển mạnh mẽ về kỹ thuật để chuẩn bị và thực hiện một cuộc
tấn công mà không bị phát hiện. Công nghệ tấn công phân tán không phải là mới, nó quen
thuộc đến mức những attacker bình thường nhất cũng có thể gây ra những hậu quả
nghiêm trọng.
1.2.1. Kịch bản của một cuộc tấn công DDoS:
Có vài bước cần được thực hiện để chuẩn bị và thực hiện một cuộc tấn công DDoS.
Đó là:
Tuyển quân: Attacker chọn một hoặc nhiều máy trên mạng Internet để thực hiện
tấn công. Các máy này thường được gọi là các agents. Thông thường các agents
này:
o Nằm ngoài mạng của nạn nhân để không bị nạn nhân kiểm soát.
o Nằm ngoài mạng của attacker để tránh trách nhiệm pháp lý nếu cuộc tấn
công bị dò ngược.
Các máy agents thường có những lỗ hổng được attacker lợi dụng để truy cập chúng.
Các attacker thích những agents có nhiều tài nguyên để có thể sinh ra luồng tấn công với
2
số lượng lớn. Lúc đầu, công việc lựa chọn các agents này được thực hiện một cách thủ
công nhưng nó đã được nhanh chóng tự động hóa nhờ những công cụ quét cung cấp danh
sách các host có lỗ hổng.
Dàn trận:
Các attacker cướp được quyền truy cập (thường là root) bằng cách thâm nhập các lỗ
hồng bảo mật hoặc là gieo rắc các mã độc. Chúng có thể thực hiện một số bước để đảm
bảo mã độc không bị phát hiện (bằng cách thay đổi tên file, đặt ẩn hoặc là đưa vào thư
mục system) hoặc là vô hiệu hóa (bằng cách thực hiện lập lịch vào hệ thống ví dụ như
trong linux cron để restart lại đoạn mã một cách định kỳ). Các công cụ quét khai thác
những lỗ hổng để cướp quyền truy cập và triển khai mã tấn công, sau đó chúng sẽ đưa ra
một danh sách các host đã được triển khai mã tấn công. Hiện tại, hầu như các công việc
đã được thực hiện tự động bằng việc sử dụng các công cụ tích hợp quét, khai thác, triển
khai và truyền các pha làm cho việc triển khai nhanh của các đoạn mã độc.
Liên lạc:
Các agents báo cáo sự sẵn sàng của nó cho các handlers – các máy được dàn xếp để
điều khiển cuộc tấn công. Những ngày đầu thì địa chỉ IP của các handlers được mã hóa
cứng trong mã tấn công, và các handlers lưu trữ các thông tin được mã hóa của các agent
sẵn sang trong một file. Cho nên việc phát hiện ra một máy đơn trong mạng DDoS đã tiết
lộ tất cả các thành phần khác. Sau đó các kênh truyền Internet Relay Chat (IRC) đã bắt
đầu được sử dụng. Một attacker điều khiển các agents sử dụng các kênh truyền IRC. Cho
nên phát hiện ra một agent không thể đưa ra được kết luận gì về mạng DDoS mà chỉ nhận
ra được một kênh truyền thông qua IRC server được sử dụng trong mạng này mà thôi. Do
vậy, sự phát hiện mạng DDoS phụ thuộc vào khả năng giám sát các agents đang kết nối
tới IRC server. Để tránh bị phát hiện, attacker sử dụng kỹ thuật nhảy kênh truyền trong
một khoảng thời gian ngắn làm cho các IRC server không kịp nhận ra các agents.
Tấn công:
Các attacker thường gia lệnh tấn công thông qua các handlers và các kênh truyền
thông tới các agents. Đích, thời lượng, và đặc điểm của các gói tin tấn công như kiểu, độ
dài, TTL, port number … có thể được tùy chỉnh.
1.2.2. Những thách thức trong phòng chống tấn công DDoS
3
Theo thống kê thường niên về tội phạm công nghệ cao của FBI năm 2009 (2009
CSI/FBI Computer Crime and Security Survey) thì số lượng các cuộc tấn công DDoS
đang có chiều hướng gia tăng từ 21% năm 2008 lên tới 29% vào năm 2009. Các hệ thống
của các cơ quan hành chính, tổ chức kinh tế cần phải hoạt động một cách thường xuyên
và chịu áp lực lớn từ việc truy cập của người dùng. Xuất phát từ yêu cầu này, đã có nhiều
hệ thống được nghiên cứu và triển khai để chống lại những cuộc tấn công từ chối dịch vụ.
Nhưng cho đến nay người ta vẫn chưa thể có một giải pháp hữu hiệu để ngăn chặn hoàn
toàn các cuộc tấn công từ chối dịch vụ. Sở dĩ có hiện tượng đó là vì, các hệ thống gặp
phải những thách thức từ nhiều phía… Cụ thể là: những thách thức về mặt kỹ thuật và
những thách thức về xã hội.
Thách thức về kỹ thuật:
Do tính chất phân tán yêu cầu của các cuộc tấn công DDoS cho nên cần có nhiều bộ
lọc phân tán, có thể kết hợp với nhau và được triển khai tại nhiều điểm trên Internet. Và
do Internet thì không trực tiếp nằm dưới sự vận hành của riêng một tổ chức, cá nhân nào.
Cho nên làm cho việc triển khai hệ thống gặp phải nhiều khó khăn để triển khai một hệ
thống phòng chống hoàn chỉnh. Tiếp đến, đó là sự thiếu thông tin cụ thể về các cuộc tấn
công . Sở dĩ có hiện tượng như vậy là do các tổ chức thường nghĩ rằng việc công bố, báo
cáo chi tiết về cuộc tấn công sẽ làm ảnh hưởng tới uy tín của tổ chức và làm cho hoạt
động kinh doanh bị ảnh hưởng. Cho nên những thông tin cụ thể về các cuộc tấn công như
kiểu tấn công, thời gian bắt đầu, chu kỳ của cuộc tấn công, số lượng agents tham gia (nếu
biết), hậu quả của cuộc tấn công . . . Ba là, thiếu các tiêu chuẩn của một hệ thống phòng
chống. Nó làm cho việc đánh giá hiệu năng của các hệ thống mới không được hiệu quả.
Vì khi một giải pháp mới được đưa ra thường nó là tối ưu nhất đối với những tiêu chuẩn
mà nhà nghiên cứu đề ra. Chúng được triển khai trên hệ thống của họ và cuối cùng đưa ra
đánh giá chứ không được thiết kế theo những yêu cầu chung nào. Cuối cùng, khi đã xây
dựng hệ thống hoàn thiện về mặt lý thuyết nhưng để có một môi trường thử nghiệm lớn là
rất khó.
Thách thức về mặt xã hội:
Một sản phầm để được triển khai một cách rộng rãi thì cần phải có hiệu năng tốt,
đem lại lợi nhuận cho nhà đầu tư, và có khả năng mở rộng triển khai với mô hình lớn
hơn…
4
1.3. Những vị trí triển khai hệ thống phòng chống
Một hệ thống phòng chống DDoS có thể được triển khai như là một hệ thống độc
lập hoặc là một hệ thống phân tán. Các hệ thống độc lập bao gồm một node giám sát tấn
công và phản ứng lại các cuộc tấn công. Các hệ thống phân tán bao gồm nhiều node (có
chức năng giống nhau) được triển khai tại những khu vực khác nhau và nằm trong cùng
một mạng. Các node liên lạc với nhau qua mạng và kết hợp hành động để thu được hiệu
quả tốt hơn.
Hình 2: Các điểm phòng chống
(Nguồn: D-WARD Source-End Defense Against DDoS Attack-Jelena Mirkovic)
1.3.1. Hệ thống phòng chống độc lập:
Như chúng ta đã biết, các dòng tấn công DDoS sinh ra từ các máy phân tán ở nhiều
nơi chuyển qua các router của mạng lõi và hội tụ tại mạng đích của cuộc tấn công. Khóa
luận sẽ thảo luận về vấn đề này xung quanh 3 kiểu mạng là: mạng nguồn gồm những máy
sinh ra các traffic tấn công, mạng trung gian là mạng chuyển các traffic tấn công đến nạn
nhân, và mạng cuối cùng là mạng đích gồm những host là mục tiêu của cuộc tấn công.
Hình trên thể hiện vị trí của 3 mạng này. Tại vị trí của mỗi mạng này đều có thể triển khai
các hệ thống phòng chống tấn công
Phòng chống tại đích:
Tính cho tới thời điểm hiện tại, hầu như các hệ thống phòng chống tấn công từ chối
dịch vụ đều được triển khai tại mạng đích. Điều này hoàn toàn dễ hiểu vì đích là nơi phải
5
gánh chịu hậu quả nặng nề nhất từ cuộc tán công. Một hệ thống chống tấn công được triển
khai ở đây sẽ giúp cho nạn nhân sớm phát hiện ra có tấn công và đưa ra những phản ứng
để ngăn chặn. Tuy nhiên thì khả năng đáp ứng với số lượng lớn các luồng thì không cao.
Một nguyên nhân khiến các hệ thống tại đích được ưa chuộng là vì quản trị viên có thể
điều khiển được hệ thống theo đúng ý của họ. Họ có thể thay thế, điều chỉnh kỹ thuật
phòng chống một cách đơn giản và dễ dàng.
Hình 3: Hệ thống phòng chống tại mạng đích
(Nguồn: Internet Denial of Service: Attack and Defense Mechanism-Jelena
Mirkovic, Sven Dietrich, David Dittrich, Peter Reiher).
Phòng chống tại mạng trung gian:
Để giảm tải cho phương pháp phòng chống tại mạng đích, chúng ta sẽ di chuyển hệ
thống phòng chống ra xa mạng đích hơn. Với phương pháp này chúng ta phải sử dụng các
router ở mạng lõi của Internet làm nhiệm vụ lọc gói tin và đưa ra những phản ứng với
những gói tin vi phạm. Chính điều này đã làm cho phương pháp này không được phổ
biến. Thêm nữa, các router ở mạng lõi của Internet thường xuyên rất bận rộn, và vì thế chi
6
phí cho việc lọc từng gói tin đi qua mạng lõi sẽ làm tăng chi phí của hệ thống. Đặc biệt
nó có thể gây sai lạc khi tăng độ phức tạp của các router lõi. Dưới đây là hình ảnh minh
họa:
Hình 4: Hệ thống phòng chống tại mạng trung gian
(Nguồn: Internet Denial of Service: Attack and Defense Mechanism-Jelena
Mirkovic, Sven Dietrich, David Dittrich, Peter Reiher).
Phòng chống tại mạng nguồn:
Hình 5 : Phòng chống tại nguồn
7
(Nguồn: Internet Denial of Service: Attack and Defense Mechanism-Jelena
Mirkovic, Sven Dietrich, David Dittrich, Peter Reiher).
Chúng ta có thể đạt được hiệu quả tốt nhất khi triển khai hệ thống gần mạng nguồn.
Vì các luồng tấn công nếu có tập trung tại gần nguồn sẽ nhỏ hơn nhiều so với gần đích. Vì
thế, nó cho phép nhiều xử lý cùng lúc như phát hiện và phân tích đối với tất cả những gói
tin đi ra ngoài. Giải pháp này có thể phát hiện và phòng chống tốt hơn. Tuy vậy, nó rất
khó để có thể triển khai trên một mạng rộng. Bởi vì nó gặp phải những thách thức đã nêu
ở trên về mặt kỹ thuật cũng như là xã hội. Thêm nữa là, hệ thống sẽ không phân biệt
được rõ ràng đâu là gói tin thuộc vào luồng tấn công.
1.3.2. Hệ thống phòng chống phân tán:
Các hệ thống phòng chống phân tán thường được triển khai tại các mạng rìa hoặc là
cả mạng rìa lẫn mạng lõi.
Phòng chống phân tán tại lõi của Internet có ưu điểm hơn phòng chống độc lập. Vì,
tại lõi của Internet tập trung những siêu kết nối việc triển khai một chính sách phòng
chống nhỏ cũng có thể giám sát và điều khiển một lượng lớn traffic trên Internet. Ví dụ
trong thí nghiệm của [Park] đã ước lượng ảnh hưởng của các bộ lọc địa chỉ giả mạo được
triển khai tại mạng lõi. Kết quả của chúng chỉ ra rằng chỉ với 18% hệ thống lõi được triển
khai thì hầu hết traffic giả mạo có thể bị phát hiện và hủy bỏ. Cho nên ta cũng có thể đưa
ra một kết luận tương tự với hệ thống phòng chống DDoS rằng: với với một lượng nhỏ
của các router lõi được triển khai hệ thống phòng chống sẽ có tác dụng tới ngăn chặn
được một lượng lớn các cuộc tấn công DDoS.
Các hệ thống phòng chống phân tán được triển khai tại các mạng rìa có ưu thế là dễ
dàng phát hiện tấn công. Vì, hệ thống phòng chống được triển khai tại mạng đích là nơi
phát hiện ra tấn công đáng tin cậy nhất và sẽ sinh ra cảnh báo tấn công với các hệ thống
được triển khai ở vị trí khác. Các hệ thống này sẽ đáp trả lại cuộc tấn công tại các mạng
nguồn. Với hệ thống DWARD chúng ta có thể mở rộng để cho nó thành hệ thống phòng
chống phân tán thì làm cho việc ngăn chặn các cuộc tấn công đem lại hiệu quả cao hơn. Ở
khóa luận này, mới chỉ đưa ra hệ thống phân tán sử dụng D-WARD ở các mạng rìa là
mạng nguồn kết nối tới một server để hỗ trợ quyết định kết nối tới một đích có phải là bị
tấn công hay không. Điều này làm tăng khả năng phát hiện chính xác của hệ thống D-
WARD lên.
8
Chương 2. D-WARD
2.1. Tổng quan về D-WARD
D-WARD là một hệ thống phòng chống DDoS được triển khai tại nguồn. Nó có 2
nhiệm vụ chính đó là:
Phát hiện các cuộc tấn công DDoS và ngăn chặn chúng bằng cách điều khiển
traffic ra ngoài.
Cung cấp dịch vụ tốt đối với traffic hợp lệ giữa mạng triển khai hệ thống và đích
trong quá trình xảy ra cuộc tấn công.
D-WARD có thể đóng vai trò như một hệ thống độc lập hoặc như là một thành phần
trong một hệ thống phòng chống phân tán. Với vai trò là hệ thống độc lập, D-WARD phát
hiện các cuộc tấn công và phản ứng lại cuộc tấn công mà không hề có sự truyền thông hay
liên lạc gì với bất kỳ một đối tượng nào khác. Nếu D-WARD được triển khai trong một
hệ thống phân tán, D-WARD nâng cao khả năng phát hiện của nó bằng cách nhận các tín
hiệu tấn công từ các thành phần khác.
Một điểm yếu của hệ thống D-WARD đó là nó chỉ giám sát với những traffic đi ra
ngoài từ mạng của nó. Các traffic được sinh ra từ mạng khác không phải mạng của nó
relay qua nó thì cũng không bị giám sát. Ngoài ra, đặc điểm này còn có thể khiến router
cài đặt D-WARD là mục tiêu của các cuộc tấn công.
2.2. Các thuật ngữ và giả thiết
Chúng ta biết rằng hệ thống D-WARD được cài đặt tại router nguồn – là router đóng
vai trò như một gateway giữa mạng triển khai (mạng nguồn) và mạng Internet. D-WARD
được cấu hình cho một tập các địa chỉ nguồn nội bộ của một mạng và thực hiện giám sát
đối với tập địa chỉ này. Tập địa chỉ đó gọi là tập địa chỉ giám sát. Tập này D-WARD có
thể lấy được bằng cách thông qua một số giao thức hoặc được cấu hình bằng tay. Sau đó,
D-WARD sẽ giám sát tất cả các traffic của tập địa chỉ này thông qua nội dung của các
luồng và kết nối. Một luồng là tất cả những traffic được sinh ra từ các máy trong tập địa
chỉ giám sát tới một đích ở mạng bên ngoài. Traffic giữa một cặp địa chỉ IP và chỉ số
cổng giữa một địa chỉ IP nằm trong tập địa chỉ giám sát và một địa chỉ ở mạng ngoài được
định nghĩa như một kết nối. D-WARD sẽ giám sát những luồng, kết nối từ tập các địa chỉ
giám sát tới một địa chỉ đích bất kỳ bằng cách so sánh từng gói tin với mẫu được định
10
nghĩa trước. Sau đó, tổng hợp kết quả, đưa ra kết luận về kết nối này và có những hành
động tương ứng với kết luận về kết nối đó.
2.3. Kiến trúc hệ thống D-WARD
Một hệ thống D-WARD gồm có 3 thành phần đó là: thành phần giám sát, giới hạn
băng thông và thành phần chính sách lưu lượng. Và thành phần chính sách lưu lượng
nhất thiết phải cài đặt ở router nguồn. Thành phần giám sát theo dõi tất cả các gói tin đi
qua router nguồn và tổng hợp thống kê những truyền thông 2 chiều giữa tập địa chỉ giám
sát và phần còn lại của Internet.
Hình 6: Kiến trúc hệ thống D-WARD
(Nguồn: D-WARD Source-End Defense Against DDoS Attack-Jelena Mirkovic)
Hình vẽ trên thể hiện các thành phần của kiến trúc D-WARD. Ta có thể thấy rằng,
kiến trúc này giám sát các traffic bằng cách kiểm tra tất cả traffic tại các interfaces của
router nguồn. Những thống kê được so sánh với mô hình hợp lệ một cách định kỳ để phân
loại các luồng và kết nối. Những kết quả phân loại được thành phần giới hạn băng thông
điều chỉnh để tương ứng với các luật. Danh sách các kết nối hợp lệ và các luật giới hạn
băng thông đều được chuyển tới thành phần chính sách lưu lượng – thành phần thực thi
nhiệm vụ giới hạn băng thông và đảm bảo các gói tin hợp lệ được chuyển đi.
11
2.3.1. Thành phần giám sát
Ở thành phần này, những thống kê luồng được lưu tại bảng Flow Table, và những
thống kê kết nối được lưu tại bảng Connection Table. Những cuộc tấn công giả mạo có
thể sinh ra một số lượng lớn các bản ghi vào 2 bảng này để tránh làm tràn hai bảng này
thành phần giám sát thực hiện chính sách xóa định kỳ các bảng này theo 2 phương pháp:
Xóa tất cả những bản ghi đã quá cũ.
Khi các bảng tràn bộ nhớ, các bản ghi ít được sử dụng nhất sẽ bị xóa bỏ.
Việc phân loại luồng và kết nối được thực hiện một cách định kỳ. Trong quá trình
phân loại, D-WARD so sánh những thống kê luồng với mô hình luồng hợp lệ tương ứng
với mỗi trường giao thức. Phân loại luồng được sử dụng để phát hiện ra các cuộc tấn
công. Phân loại kết nối được sử dụng để phát hiện những kết nối hợp lệ và kết nối này vẫn
hoạt động bình thường trong khi kết nối khác có thể bị giới hạn băng thông.
Thống kê luồng và phân loại luồng
Mỗi gói tin đi ra khỏi mạng và đi vào mạng đều ảnh hưởng tới một bản ghi trong
Flow Table. Vì một luồng đi ra khỏi mạng có thể sử dụng những giao thức giao vận khác
nhau của các ứng dụng khác nhau, cho nên mỗi bản ghi luồng trong bảng Flow Table
cũng bao gồm nhiều trường để có thể thống kê theo từng loại giao thức. Có nhiều kiểu
giao vận khác nhau nhưng D-WARD chỉ triển khai trên 3 loại đó là: TCP, UDP và ICMP.
Cho nên các luồng sẽ được thống kê dựa trên 3 kiểu giao vận đó. Các luồng sẽ được phân
loại sau mỗi chu kỳ giám sát luồng(FOI – Flow Observation Internal). Trong quá trinh
phân loại, D-WARD sẽ so sánh những thống kê luồng của mỗi giao thức tương ứng với
các mô hình luồng hợp lệ. Kết quả sẽ rơi vào một trong 3 kiểu sau đậy:
ATTACK: Xảy ra khi các thống kê hoặc một trường không phù hợp với mô hình
tương ứng.
SUSPICIOUS: Xảy ra khi những thống kê hoặc tất cả các trường phù hợp với mô
hình tương ứng nhưng luồng này trước đó vừa được phân loại là “ATTACK”.
NORMAL: nếu thống kê hoặc tất cả mọi trường phù hợp với mô hình tương ứng
và luồng trước đó thì chưa bị xác định là “ATTACK”.
Một luồng sẽ tiếp tục bị phân loại là “ATTACK” nếu trong nó tồn tại tối thiểu một
trong 2 điều kiện sau:
12
Vẫn phát hiện ra những tín hiệu tấn công – dựa vào tỉ lệ đáp ứng so với tỉ lệ yêu
cầu hoặc vấn đề giả mạo địa chỉ nguồn.
Có những gói tin bị hủy trong luồng nguyên nhân là do giới hạn băng thông.
Một cuộc tấn công đã dừng lại, các luồng sẽ được phân loại là “SUSPICIOUS”
trong một khoảng thời gian gọi là Compliance Period. Tức là sau cuộc tấn công băng
thông sẽ được tăng lên một cách từ từ. Nếu cuộc tấn công quay trở lại trước khi khoảng
thời gian bên trên hết hạn, luồng sẽ được phân loại là tấn công trở lại. Ngược lại, luồng đó
sẽ được phân loại là “NORMAL”. Sự khác nhau giữa các luồng “SUSPICIOUS” và luồng
“NORMAL” là cố gắng làm cho mức độ ảnh hưởng của cuộc tấn công lặp lại là thấp nhất.
Quá trình phân loại có thể được thực thi bằng việc sử dụng các mô hình sau đây để so
sánh:
Mô hình luồng TCP hợp lệ: TCP là một giao thức phổ biến trên Internet (chiếm
khoảng 90% traffic). Giao thức TCP sử dụng truyền thông 2 chiều để đạt được độ tin cậy
trong quá trình truyền nhận. Chúng ta có thể thấy rằng trong suốt phiên TCP, luồng dữ
liệu từ host nguồn tới host đích được điều khiển và nếu băng thông gửi giảm xuống tức là
có thể đã xảy ra tắc nghẽn. Cho nên, truyền thông TCP có thể được mô hình hóa bởi tỉ lệ
số gói tin gửi đến một địa chỉ và nhận về từ địa chỉ đó. Chúng ta có thể định nghĩa TCPrto
là tỉ lệ tối đa được phép của số gói tin gửi đi chia cho số gói tin nhận về trong một luồng.
Luồng này sẽ bị phân loại như một luồng “ATTACK” nếu tỉ lệ tổng số gói tin gửi đi chia
cho số gói tin nhận về lớn hơn TCPrto.
Mô hình luồng ICMP hợp lệ: Giao thức ICMP xác định nhiều kiểu thông điệp khác
nhau như “timestamp”, “information request” và “echo” và chúng có các kiểu gói tin
reply tương ứng. Bằng việc sử dụng quan sát này, chúng ta có thể định nghĩa ICMPrto là tỉ
lệ tôi đa được phép của số lượng các goi tin echo, timestamp, request chia cho số lương
các gói tin reply tương ứng trong luồng.
Mô hình luồng UDP hợp lệ: Chúng ta biết rằng giao thức UDP được sử dụng trong
truyền tin không tin cậy. D-WARD định nghĩa 2 ngưỡng trong mô hình luồng UDP hợp
lệ: nconn là số lượng kết nối tối đa được phép tới một đích. pconn là số lượng tối thiểu của
gói tin được phép trên mỗi kết nối. Những ngưỡng đó giúp hệ thống phát hiện một cuộc
tấn công UDP sử dụng các kết nối giả mạo hoặc có nhiều kết nối mà có ít gói tin trên một
kết nối. D-WARD sẽ phân loại một luồng là tấn công khi những ngưỡng đó bị vi phạm.
13
Thống kê kết nối và phân loại kết nối
Mỗi gói tin đi ra hoặc đi vào không chỉ sửa một bản ghi trong bảng Flow Table mà
còn sửa bản ghi trong Connection Table. Một kết nối chỉ có thể mang traffic của một giao
thức và một ứng dụng. D-WARD thực hiện phân loại kết nối sau một khoảng thời gian là
COI (Connection Observation Internal). Trong quá trình phân loại, D-WARD so sánh
những thống kê kết nối tương ứng với mô hình kết nối hợp lệ. Quá trình phân loại sẽ đưa
ra một trong 3 kết quả sau:
GOOD: Xảy ra nếu thống kê phù hợp với mô hình tương ứng.
BAD: Xảy ra nếu thống kê không phù hợp với mô hình tương ứng.
TRANSIENT: Xảy ra nếu không có đủ dữ liệu để thực hiện phân loại.
Các kết nối được phân loại là “GOOD” sẽ được phục vụ với dịch vụ tốt trong khi đó
nếu kết nối bị phân loại là “BAD” hoặc “TRANSIENT” thì sẽ bị đặt giới hạn băng thông.
D-WARD có những chính sách khác nhau với các kết nối đó trong bảng Connection
Table. Cụ thể là, các bản ghi kết nối “BAD” sẽ không bao giờ hết hạn trong khi đó kết nối
“TRANSIENT” sẽ hết hạn sau một khoảng thời gian ngắn.
Cũng tương tự như mô hình luồng hợp lệ, chúng ta cũng xây dựng những mô hình
kết nối hợp lệ. Có 3 mô hình chính D-WARD sử dụng đó là:
Mô hình kết nối TCP hợp lệ: Mô hình kết nối TCP hợp lệ của D-WARD tương tự
với mô hình luồng hợp lệ của nó. Nó cũng sử dụng giá trị TCPrto như là giá trị tỉ lệ tối đa
được phép của số gói tin gửi chia cho số gói tin nhận trong kết nối. Kết nối được phân
loại là “GOOD” nếu tỉ lệ số gói tin gửi chia cho số gói tin nhận trong luồng nhỏ hơn
TCPrto.
Mô hình kết nối ICMP hợp lệ: Hệ thống phòng chống D-WARD không triển khai
các mô hình kết nối ICMP hợp lệ vì traffic ICMP hiếm khi có một kết nối theo đúng
nghĩa của nó. Mặt khác, việc hủy bỏ traffic ICMP hợp lệ trong quá trình tấn công không
gây ra thiệt hại lớn cho các client hợp lệ.
Mô hình kết nối UDP hợp lệ: D-WARD sử dụng mỗi mô hình tương ứng với một
ứng dụng UDP cụ thể. Chúng ta có thể liệt kê một số loại ứng dụng chính sử dụng UDP
như là DNS, NTP, multimedia streaming, VoIP, Internet multi-player game, NFS, ứng
dụng chat…Với mỗi ứng dụng UDP, D-WARD thiết kế một mô hình tương ứng với nó
14
nhưng trong khóa luận này, chúng ta chỉ đề cập tới 3 mô hình cơ bản được sử dụng nhiều
nhất đó là:
DNS (Domain Name Service):
Hình 7: Máy hữu hạn trạng thái DNS
(Nguồn: University of California-Los Angeles)
Giao thức DNS có thể được triển khai cả trên TCP hoặc UDP nhưng thường thì nó
được triển khai trên UDP. Thông thường, DNS traffic sẽ có tỷ lệ là 1:1 giữa gói tin gửi và
gói tin nhận. Trong trường hợp này nếu gói tin trả lời bị mất, DNS client sẽ lặp lại yêu
cầu của nó tới server khác trước khi thử lại với server có gói tin trả lời bị mất đó. Thông
thường khoảng thời gian truyền lại từ 2 đến 5 giây và cỡ của gói tin nằm trong khoảng từ
46 đến 512 byte không tính tiêu đề của gói tin UDP và IP. Các gói tin DNS được xác định
dựa vào trường protocol trong IP header với giá trị là 17 trong khi chỉ số cổng là 53 trong
tiêu đề của gói tin UDP.Các gói tin yêu cầu và đáp ứng yêu cầu được xác định dựa vào bit
đầu đầu tiên của byte thứ 3 của DNS header. Với hình vẽ trên QR=0 là gói tin query,
QR=1 là gói tin response. Một mô hình kết nối DNS hợp lệ được định nghĩa thông qua
máy hữu hạn trạng thái. Kết nối sẽ bắt đầu từ NO_STATE và sau đó khi yêu cầu DNS
15
được gửi tới một host bên ngoài thuộc địa chỉ Internet, kết nối đến trạng thái DNS_REQ
khi yêu cầu được đáp ứng kết nối sẽ tới trở về trạng thái DNS_REP. Kết nối sẽ gửi lại yêu
cầu nếu sau khoảng thời gian là DNS_EXPIRY. Bất kỳ sự vi phạm nào của mô hình đưa
kết nối đó vào trạng thái ERROR và được phân loại là kết nối “BAD”.
Giao thức NTP (Network Time Protocol)
Một kết nối hoạt động bình thường của giao thức NTP thường sẽ có tỉ lệ là 1:1 giữa
các gói tin gửi và các gói tin nhận. Nếu gói tin trả lời bị mất, thông thường NTP client lặp
lại yêu cầu của nó tới server khác trước khi thử lại với server bị mất gói tin trả lời đó.
Khoảng thời gian thu thập nằm trong khoảng từ 64 đến 1024 giây. Cỡ của gói tin khoảng
từ 44 đến 56 byte. D-WARD chỉ thiết kế và triển khai trên các mô hình kết nối NTP
client. Mô hình kết nối NTP hợp lệ được định nghĩa bởi máy hữu hạn trạng thái. Kết nối
bắt đầu từ NO_STATE. Khi một NTP gửi tới một host khác, kết nối ở trạng thái
NTP_SENT. Kết nối có thể điều chỉnh để lặp lại một yêu cầu sau một khoảng thời gian là
NTP_EXPIRY giống như DNS và thường được đặt bằng 60 giây. Nếu có bất kỳ vi phạm
nào của mô hình đều đưa kết nối tới trạngthái ERROR dẫn tới việc kết nối đó sẽ bị phận
loại là “BAD”.
Multimedia streaming:
Các chương trình ứng dụng phổ biến được dùng cho audio và video streaming là
RealPlayer, Window Media Player, Quick-Time… Quicktime và Real Player sử dụng
giao thức giao vận thời gian thực RTP (Real Time Protocol) trên UDP để truyền dữ liệu
và giao thức RTSP (Real-time Streaming Protocol) trên TCP để điều khiển. Windows
Mediao Player sử dụng giao thức MMS (Microsoft Media Server). Giao thức streaming
qua mạng của Microsoft trên cả TCP và UDP đồng thời bao gồm cả những kỹ thuật phân
phối và điều khiển. D-WARD chỉ cung cấp những mô hình cho những ứng dụng chạy
RTP và RTSP (vì MMS là một giao thức có bản quyền, các ứng dụng sử dụng giao thức
này không thể được mô hình hóa). Streaming dữ liệu được gửi từ server tới client thường
nhỏ nó đặt trong gói tin RTP và cỡ của nó vào khoảng từ 12 đến 72 byte. Với một vài gói
tin RTP được nhận, client gửi một gói tin RTP trở lại server. RSTP traffic được gửi thông
qua TCP mỗi khi bắt đầu một phiên streaming dữ liệu và sau mỗi 1 đến 2 giây nhận
những thông báo về tình trạng của phiên làm việc. D-WARD mô hình các kết nối
streaming đa phương tiện bằng việc xem xét hành vi của traffic RTP và RSTP và sử dụng
16
máy hữu hạn trạng thái streaming đa phương tiện. Kết nối RTSP được xác định bằng cách
tìm kiếm một kết nối RTP có cùng địa chỉ nguồn và địa chỉ đích, và cổng đích là 554 là
chỉ số cổng của RSTP. Nếu kết nối RSTP đã tồn tại và nó vẫn hoạt động (nó sẽ được kích
hoạt sau khoảng thời gian là RTSP_ACTIVE giây, hiện tại đặt là 5), kết nối RTP ở trạng
thái STREAMING. Ngược lại nó ở trạng thái ERROR. Khi mà việc phân loại kết nối
đang diễn ra, các kết nối RTP trong trạng thái STREAMING cũng sẽ kiểm tra các giá trị
tỉ lệ cao của số gói tin RTP gửi đi chia cho số gói tin nhận về. Nếu tỉ lệ này thấp hơn
RTPrto (thường được đặt bằng 20) kết nối RTP sẽ được phân loại là “GOOD”. Nếu tỉ lệ
lớn hơn RTPrto hoặc kết nối trong trạng thái ERROR thì nó sẽ bị phân loại là “BAD”
Hình 8 : Máy hữu hạn trạng thái streaming dữ liệu
(Nguồn: University of California-Los Angeles)
Phân loại gói tin đầu tiên:
Trong khi một cuộc tấn công đang diễn ra, D-WARD sẽ khó có thể phân loại kết nối
một cách chính xác dựa trên gói tin đầu tiên đi ra khỏi mạng. Vì, chúng ta không có đủ
thông tin để thực hiện việc phân loại cho gói tin này. Cho nên, kết nối này sẽ được phân
loại là “TRANSIENT” và traffic của nó được điều khiển bởi chính sách giới hạn băng
thông.
17
Hình 9 : Ví dụ về vấn đề phân loại gói tin đầu tiên
(Nguồn: University of California-Los Angeles)
Trong mô hình này, mạng nguồn NetS được D-WARD bảo vệ. Chúng ta giả sử rằng
đang có một cuộc tấn cong TCP SYN sử dụng địa chỉ mạng giả mạo được gửi đi từ host
A tới nạn nhân V. D-WARD phát hiện cuộc tấn công này và sau đó đặt một giới hạn băng
thông trong luồng ra ngoài từ NetS tới nạn nhân V. Các client C1 và C2 là những client
hợp lệ và đã thiết lập kết nối từ trước tới nạn nhân V và những kết nối đó được xác định là
hợp lệ và không phải chịu giới hạn băng thông. Trong quá trình diễn ra cuộc tấn công,
client hợp lệ C3 muốn khởi tạo một kết nối tới nạn nhân V. Bằng việc giám sát, D-
WARD có thể thấy rằng có nhiều gói tin tấn công TCP SYN và một gói tin TCP_SYN
hợp lệ. Tuy nhiên để phân biệt giữa gói tin TCP SYN hợp lệ và tấn công chỉ có thể dựa
vào hoạt động của chúng sau khi thực hiện quá trình bắt tay 3 bước. Nhưng D-WARD
không cho phép thực hiện việc bắt tay 3 bước khi một cuộc tấn công TCP SYN đang xảy
ra. Cho nên, cả kết nối hợp lệ và kết nối tấn công đều sẽ bị phân loại là “TRANSIENT”
và bị giới hạn băng thông.
Vì việc hủy bỏ các gói tin ảnh hưởng đến hiệu năng của kết nối, đặc biệt là các kết
nối TCP. Giao thức TCP cho rằng việc mất gói tin là tín hiệu của sự tắc nghẽn trong mạng
18
và giảm tốc độ gửi xuống. Nếu gói tin mất liên tiếp dẫn tới cỡ của cửa sổ điều khiển
(control window) trong gói tin giảm xuống theo cấp số mũ. Do gói tin bị mất là gói tin bắt
đầu của một kết nối cho nên cửa sổ điều khiển sẽ giảm xuống giá trị thấp nhất. Khi truyền
lại cửa sổ điều khiển sẽ tăng theo cấp số mũ cho đến ngưỡng. Kỹ thuật này rất thành công
trong việc giải quyết tắc nghẽn tạm thời. Tuy nhiên, chúng làm traffic TCP không ưu thế
hơn traffic tấn công để D-WARD có thể phân biệt và cung cấp một dịch vụ tốt cho các kết
nối này. Sau đây, chúng ta sẽ xem xét một số giải pháp để cải thiện vấn đề này.
Đầu tiên, chúng ta có thể giả thiết rằng các cookie TCP SYN có thể được triển khai
tại vị trí của nạn nhân. Tấn công tràn TCP SYN có thể được điều khiển bằng cách sử
dụng TCP SYN cookie. Như chúng ta đã biết, để khởi tạo một kết nối TCP, client gửi một
gói tin TCP SYN tới server. Để đáp ứng lại yêu cầu server gửi một gói tin SYN+ACK trở
lại client. Trong các gói tin này có một trường giá trị là sequence number được sử dụng để
ghép các gói tin trong luồng dữ liệu khi sử dụng giao thức TCP. Mà trường sequence
number đầu tiên này được gửi đi là một giá trị ngẫu nhiên được chọn bởi client hoặc
server. SYN cookie sẽ khởi tạo sequence number được xây dựng dựa theo các yếu tố sau:
t là nhãn thời gian
m là dung lượng tối đa của một segment là giá trị được server lưu ở
hàng đợi SYN.
s là kết quả của hàm bí mật được mã hóa dựa vào địa chỉ IP và chỉ số
cổng của server, client và t. Giá trị của s sẽ có độ dài là 24 bit.
Việc khởi tạo TCP sequence number được SYN Cookie tính toán như sau:
5 bit đầu tiên là: t mod 32
3 bit tiếp theo là: mã hóa giá trị m
24 bit cuối cùng: là giá trị s.
Khi client gửi trả lại gói tin TCP ACK trong quá trình bắt tay 3 bước tới server để
thông báo lại với server rằng gói TCP SYN+ACK đã được client nhận, thì client phải
cộng thêm 1 vào trường sequence number của gói tin SYN+ACK để vào trường
Acknowlegment number của gói tin trả về server đó. Server sẽ trừ đi 1 từ trường
Acknowlegment number của gói tin này để kiểm tra SYN Cookie đã gửi tới client. Quá
trình kiểm tra diễn ra như sau:
19
Kiểm tra giá trị t xem có giống với giá trị t đã được gửi đi trong gói
tin SYN+ACK hay không. Nếu khác tức là gói tin đã hết hạn.
Tính toán lại giá trị s xem đây có quả thật là một SYN Cookie chính
xác hay không.
Giải mã giá trị m từ 3 bit mã hóa trong SYN cookie để so sánh với m
trong hàng đợi SYN.
Nếu tất cả đều chính xác thì gói tin SYN đó là một gói tin hợp lệ. Ngược lại, nó có
thể là nguyên nhân của một cuộc tấn công. Nếu tất cả các host trên mạng đều triển khai
TCP SYN cookie thì D-WARD sẽ không chặn bất kỳ gói tin SYN nào. Nhưng thực tế, có
rất nhiều host không triển khai dịch vụ này, và D-WARD sẽ không thể bảo vệ những host
đó khỏi các cuộc tấn công tràn TCP SYN.
Hai là, chúng ta có thể sử dụng các kết nối proxy TCP tức là D-WARD sẽ triển khai
TCP SYN cookie trên chính nó và thực hiện quá trình bắt tay 3 bước thay vì client phải
bắt tay 3 bước với nạn nhân. Một client hoàn thành việc bắt tay 3 bước, D-WARD sẽ gửi
gói tin TCP SYN tới server và thiết lập kết nối tới server. Tuy nhiên, chúng ta gặp phải
vấn đề là sequence number được chọn đầu tiên của hệ thống phòng chống không giống
như giá trị của trường này được chọn bởi server thật. Để giải quyết vấn đề này, chúng ta
có thể thực hiện theo 2 cách: (1) proxy hoàn toàn kết nối, ghi lại sequence number phù
hợp, hoặc (2) hủy kết nối bằng cách gửi gói tin RST (reset) tới client, và vì gói tin TCP
SYN là hợp lệ cho nên lần sau các gói tin TCP SYN gửi đi sẽ được gửi trực tiếp tới
server. Thông thường người ta thường sử dụng phương pháp thứ nhất nhưng sử dụng
phương pháp này cũng gặp phải hạn chế. Đó là trong khi diễn ra một cuộc tấn công thì D-
WARD vẫn phải giữ quá nhiều thông tin về trạng thái kết nối và sửa mỗi gói tin trong các
kết nối hợp lệ đi qua nó.
2.3.2. Thành phần giới hạn băng thông
Thành phần giới hạn băng thông sẽ điều chỉnh giá trị giới hạn băng thông sau một
khoảng thời gian giám sát luồng (Flow Observation Interval). Để đưa ra một giá trị giới
hạn băng thông cho một luồng đang hoạt động, thành phần này phải đọc các kết quả phân
loại từ thành phần giám sát và băng thông được đặt cho luồng này trước đây là bao nhiêu
từ thành phần chính sách lưu lượng.
20
Đầu tiên, chúng ta xem xét về băng thông được đặt cho luồng này từ trước được lấy
từ thành phần chính sách lưu lượng. Nó được mô tả thông qua 2 chặng: đầu tiên, số byte
của luồng được chuyển tới nạn nhân được gọi là Bsent và số byte của luồng bị hủy gọi là
Bdropped. Hai giá trị này sẽ được xác định trong khoảng thời gian giám sát luồng (Flow
Observation Interval). Để xác định cụ thể, chúng ta định nghĩa một hệ số tuân thủ luồng
fcf (Flow Compliance Factor) là thương của Bsent chia cho tổng Bsent và Bdropped và giá trị
này nằm trong khoảng từ 0 đến 1. Giá trị FCB này càng cao thì số gói tin bị hủy càng
thấp.
Giảm theo hàm mũ:
Khi một luồng được xác định là luồng tấn công lần đầu tiên sau một khoảng thời
gian dài được xác định là luồng bình thường, băng thông của nó bị giới hạn bởi công thức
sau:
Trong đó fdec là một tham số được cấu hình.
Nếu luồng tiếp tục bị phân loại là tấn công thì sẽ giới hạn băng thông giảm theo hàm
mũ theo công thức
Trong đó:
rl: là băng thông giới hạn hiện tại
fcf: là hệ số tuân thủ luồng
Luồng có nhiều gói tin bị hủy tức là fcf << 1 thì sẽ bi giới hạn băng thông về mức
rất thấp một cách nhanh chóng. Ngược lại, luồng có số gói tin bị hủy nhỏ thì fcf ~ 1 thì
việc giới hạn băng thông diễn ra một cách từ từ hơn. Giới hạn băng thông thấp nhất có thể
giới hạn đó là giá trị tham số cấu hình MinRate.
Tăng tuyến tính:
Khi không còn phát hiện ra tín hiệu của cuộc tấn công nữa, luồng được xem như một
luồng khả nghi và băng thông gửi được phục hồi. Pha làm việc này gồm có 2 phần: phục
21
hồi chậm và phục hồi nhanh. Trong quá trình phục hồi chậm giới hạn băng thông sẽ được
tăng tuyến tính theo công thức
Tốc độ khôi phục băng thông phụ thuộc vào tham số rateinc và quá trình diễn ra pha
phục hồi chậm được diễn ra trong khoảng thời gian là giá trị của hằng số Compliance
Period.
Tăng theo cấp số mũ:
Khi một luồng được phân loại là “NORMAL”, quá trình phục hồi nhanh sẽ được
thực hiện. Trong pha phục hồi nhanh, băng thông gửi tăng theo cấp số mũ theo công thức:
rl = rl*(1+finc*fcf)
Tốc độ khôi phục phụ thuộc vào giá trị của tham số finc băng thông sẽ tăng cho tới
khi nào đạt giá trị MaxRate. Ngay sau khi giới hạn băng thông lớn hơn MaxRate, pha
phục hồi sẽ kết thúc và giới hạn băng thông sẽ bị xóa.
2.3.3. Thành phần chính sách lưu lượng
Nhiệm vụ của thành phần chính sách lưu lượng là tiếp nhận một cách định kỳ về
giới hạn băng thông từ thành phần giới hạn băng thông và thông tin phân loại kết nối từ
thành phần giám sát và sau đó đưa ra quyết định hoặc là chuyển tiếp hoặc là hủy.
2.4. Các phiên bản D-WARD
D-WARD được triển khai ở 2 mức: người dùng và kernel. Đầu tiên, chúng ta sẽ
triển khai thành phần giám sát và thành phần giới hạn băng thông ở mức người dùng và
sau đó triển khai module nhân của thành phần chính sách lưu lượng. Sự tách biệt các
chức năng của 2 phiên bản trước đã được chỉnh sửa để đạt được hiệu năng tốt hơn và dễ
dàng triển khai hơn ở phiên bản 3.1.
2.4.1. D-WARD 1. 0
Ở phiên bản này, tất cả các thành phần đều được triển khai hoàn toàn ở mức người
dùng. Vì thành phần giám sát truyền thông cần truy cập trực tiếp tới các gói tin chuyển
qua router để quyết định xem là nên chuyển tiếp hay là hủy, các gói tin bị kiểm tra khi đi
22
qua kernel và được copy lại một bản ra mức người dùng. Công việc này được thực hiện
bởi module IP_queue ở nhân Linux.
Module ip_queue được nạp, các gói tin IP có thể được chọn cùng với iptables và xếp
hàng để xử lý tiến trình mức người dùng. Sau khi xử lý, các gói tin được trở lại tiến trình
mức kernel cùng với quyết định đính kèm như NF_ACCEPT để chấp nhận gói tin hay
NF_DROP để hủy gói tin. Bên cạnh đó, ip_queue cũng đưa ra tất cả những chức năng cần
thiết cho thành phần chính sách lưu lượng. Tuy vậy, việc copy các gói tin (cả header lẫn
dữ liệu) tới không gian người dùng là nguyên nhân gây ra tràn bộ nhớ và nó có thể trở
thành vấn đề nghiêm trọng khi số lượng gói tin tăng lên. Cho nên, D-WARD 1.0 chỉ có
thể giải quyết được 1000 gói tin trên 1 giây, điều này làm cho hệ thống không thể được
triển khai ở ngoài thực tế được. Cho nên, thành phần chính sách lưu lượng cần phải được
đưa vào mức kernel để không phải copy lại các gói tin đi qua kernel nữa.
2.4.2. D-WARD 2.0
Ở phiên bản này thành phần chính sách lưu lượng nằm ở trong kernel và 2 thành
phần còn lại là giám sát và giới hạn băng thông nằm ở mức người dùng. Để truyền thông
giữa 2 mức thì chúng ta sử dụng những lời gọi hệ thống của linux.
Thành phần chính sách lưu lượng được triển khai như một module kernel nạp trực
tiếp. Tại mức nhân, các gói tin có thể bị theo dõi bởi netfilter hooks. Các module kernel
có thể đăng ký để lắng nghe các “hook” của các giao thức khác nhau. Khi một gói tin đi
tới netfilter framework ( gặp phải một trong các “hook”), netfilter sẽ kiểm tra nếu giao
thức và “hook” này đã được đăng ký. Các module kernel có thể loại bỏ gói tin (trả về giá
trị NF_DROP cho framework), cho phép đi qua (trả về giá trị NF_ACCEPT), thông báo
với netfilter bỏ qua gói tin (trả về giá trị NF_STOLEN), hỏi netfilter về hàng đợi gói tin
trong không gian người dùng hoặc kiểm tra lại “hook” (trả về giá trị NF_REPEAT).
Các module mức người dùng (thành phần giám sát và giới hạn băng thông) chuyển
danh sách kết nối hợp lệ và các luật giới hạn băng thông tới kernel. Các module giám sát
nhận thống kê gói tin sử dụng mã tcpdump đã được chỉnh sửa. tcpdump sử dụng tiện ích
lọc gói tin Berkeley (BPF) và thư viện pcap để bắt tiêu đề (và một phần nội dung) của các
gói tin phù hợp với chính sách lọc đã đưa ra.
D-WARD 2.0 có thể xử lý một số lượng lớn các gói tin ( tầm 10000 gói tin trên
giây) nhưng nó có một số giới hạn. libpcap copy tiêu đề gói tin(và nội dung) trong mỗi
23
Tải về để xem bản đầy đủ
49 trang
12/05/2025
160
Bạn đang xem 30 trang mẫu của tài liệu "Luận văn Biên dịch cài đặt và triển khai hệ thống D-Ward", để tải tài liệu gốc về máy hãy click vào nút Download ở trên.
File đính kèm:
- luan_van_bien_dich_cai_dat_va_trien_khai_he_thong_d_ward.pdf
