Báo cáo 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. 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 ...... 2 1.2.1. Kịch bản của một cuộc tấn công DDoS: .......................................................... 2 1.2.2. Những thách thức trong phòng chống tấn công DDoS .................................... 3 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 Chương 3.Cơ sở lý thuyết của kiến trúc triển khai và mở rộng DWARD ................ 26 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.2. Bảng băm kết nối: .......................................................................................... 26 3.1.3. Lấy thông tin gói tin ....................................................................................... 28 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.4.2. Kết nối D-WARD với mô hình client-server ................................................. 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 4.2.2. Mở rộng của hệ thống: ................................................................................... 38 Chương 5.Tổng kết .................................................................................................... 41 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 Hình 15: File conn.txt ................................................................................................ 37 Hình 16: Topo thử nghiệm ......................................................................................... 38 Bảng các từ viết tắt COI Connection Observation Interval D-WARD Ddos- network Attack and Recognition Defense DDOS Distributed Denial Of Service DOS Denial of Service FOI Flow Observation Interval ICMP Internet Control Message Protocol IP Internet Protocol RTP Real-time Transport Protocol RSTP Real-time Streaming Protocol TCP Transmission Control Protocol 1 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 2 Đầ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 3 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 4 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… 5 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 6 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 7 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 8 (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. 9 1.4. Tổng kết: Trong chương này, khóa luận đề cập tới những kiến thức cơ bản về DoS và DDoS, những thách thức trong phòng chống tấn công từ chối dịch vụ qua đó cũng trình bày về những vị trí triển khai hệ thống phòng chống. 10 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 11 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. 12 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: 13  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. 14  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ó 15 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 16 đượ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 17 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. 18 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 19 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: 20  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. 21 Đầ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 22 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 23 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 24 gói tin cơ sở. Cho nên khi số lượng gói tin tăng lên thì vấn đề lưu trữ và xử lý là cực kỳ khó khăn. Với số lượng gói tin lớn hơn 1000 thì libpcap không thể bắt được thông tin của tất cả các gói tin đi qua nó. Trong khi D-WARD vẫn hoạt động, dẫn tới việc mất thông tin bao gồm cả thông tin của những gói tin hợp lệ và ảnh hưởng đến hiệu năng của D- WARD. Giới hạn khác của D-WARD 2.0 là khó cài đặt. D-WARD 2.0 thêm những lệnh hệ thống mới vào Linux kernel, nó yêu cầu chỉnh sửa kernel để cài đặt sẽ rất phức tạp và mất thời gian. Hơn nữa, việc thêm những lệnh hệ thống mới hoặc sửa những cái cũ có thể gây ra một lỗ hổng bảo mật trong trong Linux kernel. 2.4.3. D-WARD 3.0 Hệ thống được triển khai với thành phần chính sách lưu lượng nằm ở mức kernel và các thành phần giám sát và giới hạn băng thông nằm ở mức người dùng giống như D- WARD 2.0. Tuy nhiên, việc truyền thông giữa 2 mức này được thực hiện thông qua các hàm ioctl. Nó cho phép truyền thông 2 chiều giữa các tiến trình người dùng và nhân một cách dễ dàng và làm cho quá trình cài đặt dễ dàng. Việc cài đặt yêu cầu 2 thiết bị phải được khởi tạo:  Thiết bị dward: được sử dụng cho truyền thông 2 chiều giữa các thành phần giám sát, thành phần giới hạn băng thông trong một vùng với thành phần chính sách lưu lượng trong một vùng khác.  Thiết bị sniff: được sử dụng để theo dõi thông tin gói tin đưa nó tới thành phần giám sát. Sau đó các tiến trình kernel tổng hợp thông tin cần thiết và lưu nó lại, trong khi các thành phần giám sát và giới hạn băng thông thực hiện các lệnh ioctl để lấy những thông tin cần thiết. D-WARD 3.1 bổ sung thêm 2 đặc điểm quan trọng ảnh hưởng tới hiệu năng của hệ thống:  Khởi tạo chuỗi số dự đoán: Không có phiên bản nào của D-WARD trước đó sử dụng kỹ thuật dự đoán giá trị. Cho nên các phiên bản đó đã hủy các gói tin kết nối mới trong quá trình tấn công, và hiệu năng của chúng phụ thuộc trực tiếp vào tần số của việc khởi tạo kết nối và độ dài kết nối. Để khắc phục vấn đề này, kỹ thuật khởi tạo chuỗi số dự đoán đã được phát triển và triển khai trên D-WARD 3.1. 25  Các mô hình kết nối UDP hợp lệ: Các mô hình kết nối UDP hợp lệ chỉ được triển khai trên D-WARD 3.1. 2.5. Tổng kết: Chương 3 của khóa luận đưa ra cách nhìn tổng quan về D-WARD, kiến trúc, và các phiên bản của D-WARD. Qua đó chúng ta có thể thấy mối quan hệ của chúng làm nền tảng cho việc triển khai và mở rộng hệ thống phòng thủ. 26 Chương 3. Cơ sở lý thuyết của kiến trúc triển khai và mở rộng DWARD Như đã giới thiệu ở chương trước, phiên bản mới nhất của D-WARD hiện nay là D- WARD 3.1. Chương này sẽ mô tả chi tiết về kiến trúc triển khai của hệ thống D-WARD và hướng mở rộng của hệ thống này. 3.1. Triển khai thành phần giám sát Chúng ta biết rằng thành phần giám sát lưu những thống kê luồng và kết nối trong các bảng băm với mục đích truy cập nhanh. 3.1.1. Bảng băm luồng Bảng băm luồng được đánh chỉ mục bằng địa chỉ IP đích và bao gồm các trường trong hình vẽ sau: Hình 10 : Bảng băm luồng (Nguồn: University of California – Los Angeles) 3.1.2. Bảng băm kết nối: Bảng băm kết nối sử dụng cả địa chỉ IP nguồn, chỉ số cổng nguồn, địa chỉ IP đích, chỉ số cổng đích để đánh chỉ mục. Bảng bao gồm các trường được mô tả trong hình vẽ sau: 27 Hình 11: Bảng băm kết nối (Nguồn: University of California-Los Angeles) Do cỡ của bảng băm thì luôn luôn nhỏ hơn số lượng entry có thể, xung đột sẽ xảy ra khi một số entry cố gắng để thêm vào bảng. Để giải quyết vấn đề này, bảng băng sử dụng hàm băm kép để giảm xác suất xung đột xuống. Hàm băm kép sử dụng 2 hàm: h1(x) và h2(x) để tính toán chỉ mục cho khóa x. Chỉ mục đầu tiên sẽ được tính toán như sau: index = h1(x). Nếu xảy ra xung đột, các chỉ mục sẽ được tính toán lại như sau index = h1(x) + trial*h2(x), trong đó trial là số xung đột gặp phải cho tới thời điểm hiện tại. Ý tưởng của phương pháp này là nếu 2 đối tượng đều băm ra cùng một giá trị là h1, chúng sẽ có các giá trị băm h2 khác nhau. Các chỉ mục băm luồng được tính toán bằng việc sử dụng các hàm băm sau: k = IP đích h1(k) = k%size h2(k) = 1 + ( k % (size – 1)) Các chỉ mục băm kết nối được tính toán bằng các hàm: k = IP đích + IP nguồn + Cổng đích + Cổng nguồn h1(k) = k % size h2(k) = 1 + (k % (size -1)) 28 Để tránh lãng phí tài nguyên trong quá trình tìm kiếm một đối tượng trong bảng băm, số trial tối đa là 3 và nếu sau 3 trial một đối tượng không được tìm thấy, thì quá trình tìm kiếm sẽ bị hủy bỏ. Trước khi một bản ghi được thêm vào bảng băm, cỡ của bảng băm cần phải được kiểm tra xem có bị tràn hay không. Nếu bảng băm gần đầy, chúng sẽ xóa một bản ghi để có không gian cho các bản ghi mới. Sau đây là một số tiêu chuẩn được sử dụng để xác định bản ghi nào sẽ bị xóa:  Đối với bản ghi luồng: Chúng ta có thể xóa nếu số gói tin gửi ít hơn SP và số byte gửi ít hơn SB với SP và SB là 2 tham số được cấu hình và được tăng lên gấp đôi sau khi mỗi luồng đi qua.  Đối với bản ghi kết nối: Chúng ta có thể xóa bản ghi nếu số gói tin gửi ít hơn SP và số byte gửi ít hơn SB và kết nối được phân loại là “TRANSIENT”. SP và SB là những tham số cấu hình và cũng được tăng lên gấp đôi sau khi mỗi kết nối đi qua. 3.1.3. Lấy thông tin gói tin Tiến trình get_packet_info liên tục yêu cầu thông tin của gói tin từ module kernel gst. Tuy nhiên, để tăng hiệu suất việc copy dữ liệu giữa kernel và không gian người dùng sẽ bị hạn chế. Cho nên, thông tin gói tin chỉ được copy khi bộ đệm kernel đã chứa hơn 1/3 hoặc sau một số lần yêu cầu copy bị từ chối. Khi tiến trình get_packet_info nhận dữ liệu nó sẽ lấy thông tin trong mỗi gói tin và cập nhật vào các entry tương ứng trong các bảng băm luồng và bảng băm kết nối. 3.1.4. Phân loại luồng và kết nối Các luồng và kết nối được phân loại định kỳ bằng hàm process và gọi hàm rate_limit để xác định giới hạn băng thông tương ứng. Một luồng sẽ bị phân loại là “ATTACK” nếu ít nhất nó gặp phải một trong các điều kiện sau:  Tỉ lệ gói tin TCP gửi và nhận lớn hơn TCPrto.  Tỉ lệ gói tin ICMP gửi và nhận lớn hơn ICMPrto.  Số kết nối UDP lớn hơn nconn và tỉ lệ số gói tin UDP gửi trên số kết nối UDP thấp hơn pconn. Nếu luồng không gặp phải bất kỳ một điều kiện nào bên trên, luồng sẽ được phân loại là “SUSPICIOUS” nếu thời gian nó thỏa mãn điều kiện là không phạm phải bất kỳ 29 điều kiện nêu trên ít hơn khoảng thời gian Compliance Period hoặc số lượng bytes bị hủy khác 0. Ngược lại luồng sẽ được phân loại là “NORMAL”. Về việc phân loại kết nối, kết nối sẽ bị phân loại là “TRANSIENT” nếu nó gặp phải một trong các điều kiện sau: (1) là kết nối TCP và có ít hơn 3 gói tin được gửi đi, hoặc (2) là kết nối ICMP và có ít hơn 2 gói tin được gửi đi, hoặc (3) là kết nối UDP và không có các mô hình mức ứng dụng. Một kết nối sẽ được phân loại là “GOOD” nếu có một trong các điều kiện sau đây:  Là kết nối TCP và có tỉ lệ số gói tin gửi trên số gói tin nhận nhỏ hơn TCPrto.  Là kết nối ICMP và tỉ lệ gói tin gửi và nhận nhỏ hơn ICMPrto.  Là kết nối UDP và có mô hình mức ứng dụng và kết nối ở trạng thái thỏa mãn mô hình đó. Trong trường hợp khác, một kết nối được xem như là được phân loại “BAD”. Cả kết nối TCP và UDP nếu đã được phân loại là hợp lệ thì đề được thêm vào danh sách kết nối hợp lệ (Legitimate Connection List) và sau đó gửi tới module kernel rl bằng việc sử dụng các lệnh ioctl. Sau khi một kết nối được phân loại, các thống kê về số lượng các gói tin và byte của kết nối đó sẽ bị xóa hết. Kết nối này được tiếp tục kiểm tra trạng thái tạm ngừng hoạt động của nó bằng cách so sánh nhãn thời gian hoạt động cuối cùng với khoảng tạm ngừng hoạt động tốt (Good Inactive Period) cho các kết nối tốt, hoặc khoảng thời gian tạm ngừng hoạt động tạm thời ( Transient Inactive Period) cho những kết nối tạm thời. Các kết nối bị phân loại là “BAD” không được kiểm tra tạm ngừng hoạt động như kết nối được phân loại là “GOOD”. Với các kết nối này, các kết nối tạm ngừng hoạt động sẽ bị xóa ngay lập tức. 3.2. Triển khai thành phần giới hạn băng thông Sau khi phân loại luồng và kết nối hoàn thành, thành phần giới hạn băng thông được gọi từ hàm process. Thành phần giới hạn băng thông sẽ nhận được thông tin về luồng bị hủy từ module rl sử dụng các lệnh ioctl và định nghĩa luồng phù hợp với các giới hạn về tốc độ. Sau đó, các luồng bị giới hạn băng thông được thêm vào bảng băng giới hạn băng thông sử dụng địa chỉ IP đích và thông tin về giới hạn băng thông hiện tại để đánh chỉ số. Nội dung này của bảng sau đó được đưa tới module rl bằng việc sử dụng các lệnh ioctl. 30 Những thống kê về số gói tin và byte cũng sẽ bị xóa sau khi đặt giới hạn băng thông. Thêm nữa là, luồng được kiểm tra bằng việc so sánh nhãn thời gian cuối cùng mà luồng còn hoạt động với khoảng thời gian luồng tạm ngừng hoạt động (Flow_Inactive_Period) cho các luồng được phân loại là “NORMAL”. Chúng ta không kiểm tra sự hoạt động của các luồng “ATTACK” và “SUSPICIOUS” bởi vì chúng sẽ được phân loại là “NORMAL” sau khi tạm dừng hoạt động. Cuối cùng, các luồng tạm dừng hoạt động sẽ bị xóa. 3.3. Triển khai thành phần chính sách lưu lượng Tiến trình điều khiển chính sách lưu lượng được triển khai trong module rl bằng việc sử dụng các netfilte hooks. Thông tin về các luồng bị giới hạn băng thông trong bảng băm luồng bị giới hạn và thông tin về những kết nối “GOOD” trong bảng băm kết nối tốt được lưu trong module rl. Các bảng này được tổ chức giống như các bảng băm luồng và kết nối trong thành phần giám sát. Một bản ghi trong bảng băm luồng bị giới hạn có các trường:  Số byte đã gửi  Số byte đã gửi trong các kết nối “GOOD”  Số byte gửi phù hợp với dải sequence number được đặt trước.  Số byte bị hủy  Giới hạn băng thông hiện tại  Ước lượng tải của “good” traffic. 3.3.1. Tiến trình điều khiển chính sách lưu lượng D-WARD thực hiện điều khiển chính sách lưu lượng với mỗi gói tin đi ra theo các cách sau:  Nếu gói tin có địa chỉ IP nguồn không nằm trong tập các địa chỉ IP được giám sát thì gói tin sẽ bị hủy.  Nếu luồng liên quan không nằm trong bảng băm luồng bị giới hạn, gói tin sẽ được chuyển tiếp.  Nếu kết nối liên quan nằm trong bảng băm kết nối “GOOD”, chuyển tiếp gói tin và cập nhật số byte tốt đã gửi vào bản ghi luồng tương ứng với kết nối đó trong bảng băm luồng bị giới hạn. 31  Nếu gói tin là TCP, nó phù hợp với dải sequence number được đặt trước và tổng của các byte đặt trước đã gửi và độ dài gói tin không lớn hơn tham số Early Packet Rate Limit, chuyển tiếp gói tin và cập nhật số byte đã gửi phù hợp với sequence number đặt trước. 3.4. Mở rộng D-WARD Do hệ thống D-WARD thường được triển khai và xây dựng như một hệ thống độc lập, hoạt động một cách riêng lẻ. Ý tưởng được đưa ra là xây dựng một server cơ sở dữ liệu tập trung để lưu những thông tin về luồng và kết nối. Cho phép các router cài đặt D- WARD có thể thêm và lấy thông tin cập nhật từ các router khác thông qua server này. 3.4.1. Mục đích của việc mở rộng Mở rộng hệ thống D-WARD theo hướng kết nối các router cài đặt D-WARD với một server cơ sở dữ liệu sẽ có những lợi ích:  Tăng khả năng phân loại chính xác luồng và kết nối.  Hệ thống sẽ được triển khai một cách hiệu quả hơn trên một mô hình mạng lớn. 3.4.2. Kết nối D-WARD với mô hình client-server  Mô tả chung về hệ thống: Triển khai hệ thống với một server chạy MySQL và các router chạy D-WARD sẽ được kết nối trực tiếp đến server này. Trong server MySQL chúng ta tạo ra một bảng lưu trữ các dữ liệu về: thời gian, địa chỉ IP D-WARD, địa chỉ IP đích, và xác suất tấn công của luồng tới địa chỉ IP đích đó. Sau mỗi chu kỳ giám sát luồng ( Flow Observation Interval) thông tin tổng hợp tại mỗi router sẽ được gửi lên server MySQL. Khi quá trình phân loại diễn ra router D-WARD sẽ gửi truy vấn tới server cơ sở dữ liệu hỏi xem các router D-WARD khác về xác suất tấn công của các luồng trong miền quản lý của các router đó. Sau đó, tính toán lại xác xuất tấn công của luồng đó trong miền quản lý của mình để đưa ra một quyết định chính xác hơn.  Cơ sở lý thuyết: Chúng ta dựa tỉ lệ số gói tin gửi đi trên số gói tin đáp ứng theo mô hình của từng loại gói tin cụ thể. 32 Các router sẽ lấy giá trị ratio của các router khác về luồng cần giám sát, tính toán lại bằng cách lấy giá trị trung bình. Sau đó, kết hợp giá trị này với các mô hình các gói tin hợp lệ để đưa ra phân loại cho luồng đó. 3.5. Tổng kết Trong chương này, khóa luận đã kiến trúc triển khai của hệ thống D-WARD version 3.1. Đồng thời, nó cũng đưa ra một hướng mở rộng cho D-WARD đó là kết nối với mô hình client-server; sử dụng một server cơ sở dữ liệu để nâng cao hiệu năng của hệ thống. Chương 4. Cài đặt thử nghiệm 4.1. Cài đặt hệ thống D-WARD 4.1.1. Mô hình triển khai 33 Hình 12: : Topo hệ thống D-WARD Chúng ta sẽ cài đặt hệ thống với địa chỉ IP, subnet mask, và default gateway như topo trên như sau:  Subnet: 192.168.2.0/24, Default gateway: 192.168.2.1/24 o Các máy tấn công: 192.168.2.2/24 (A1), 192.168.2.4(A2) o Các client hợp lệ: 192.168.2.3/24 (C1)  Subnet: 192.168.3.0/24, Default gateway: 192.168.3.1/24 o Các máy tấn công: 192.168.3.2/24 (A3) o Các client hợp lệ: 192.168.3.3/24 (C2), 192.168.3.4/24(C3)  Subnet: 192.168.4.0/24, Default gateway: 192.168.4.1/24 o Các máy tấn công: 192.168.4.2/24 (A4), 192.168.4.3/24 (A5) o Các máy hợp lệ: Không có  Subnet: 192.168.5.0/24, Default gateway: 192.168.5.1/24 o Máy tấn công: 192.168.5.3 (A6) o Máy hợp lệ: 192.168.5.2 (C4). 34  Các router R2-D, R3-D, R4-D và R5-D là các router nguồn được triển khai D-WARD. Và có địa chỉ IP, subnet mask như hình vẽ.  Router R1 là router gần đích không được triển khai D-WARD  Host V là nạn nhân của cuộc tấn công DDoS có địa chỉ IP là 10.0.0.254, subnetmask: 255.255.255.0, default gateway: 10.0.0.1 4.1.2. Biên dịch và chạy D-WARD Chúng ta sẽ biên dịch và chạy D-WARD trên các router R2-D, R3-D, R4-D và R5- D theo topo đã đưa ra ở phần trên. Đầu tiên, chúng ta download mã nguồn D-WARD mới nhất tại địa chỉ: . Sau đó, giải nén mã nguồn và biên dịch. Mã nguồn sử dụng sử dụng thư viện lập trình của kernel 2.4 cho nên hệ điều hành được sử dụng là Red Hat 8. Ngoài ra để biên dịch mã nguồn cần phải cài trình biên dịch GCC. Mã nguồn D-WARD bao gồm cả module module ứng dụng và module kernel. Module ứng dụng sẽ thực hiện phát hiện các cuộc tấn công và tính toán các giới hạn băng thông trong khi module kernel sẽ thực hiện điều khiển chính sách lưu lượng. Sau khi biên dịch xong mã nguồn, chúng ta có thể thấy 2 module “gst.o” và “rl.o”. Module “rl.o” sẽ đặt các giới hạn băng thông cho các traffic đi ra ngoài và module “gst.o” kiểm tra những gói tin trong đường truyền và đưa thông tin tiêu đề đến module ứng dụng để tổng hợp và thống kê.  Quá trình biên dịch D-WARD: Chúng ta xem xét 2 file “Makefile” và “kernel/Makefile” các giá trị tham số được sử dụng để biên dịch một cách kỹ lưỡng. Sau đó, chỉnh sửa file cấu hình trong “prefix.config” và “dward.config” để tùy chỉnh hệ thống phù hợp với mạng triển khai. Sau khi đã chỉnh sửa các tham số cần thiết, chúng ta di chuyển vào thư mục dward và gõ 3 lệnh: make depend make make install 35 Khởi tạo các thiết bị thành phần cho D-WARD. Chúng ta chạy các câu lệnh sau: mkdir /dev/dward mkdir /dev/sniff mknod /dev/dward c 146 0 // Tạo một thiết bị dward mknod /dev/sniff c 147 0 // Tạo một thiết bị sniff Cài đặt module kernel gst.o và rl.o Chạy 2 câu lệnh: insmod kernel/gst.o plen=20 insmod kernel/rl.o drop=1 mark=255 LOCAL_ADDRESS=x.x.x.x LOCAL_MASK=y (trong đó x.x.x.x là địa chỉ mạng mà hệ thống dward của chúng ta sẽ triển khai, y là độ dài của số bit phần host trong địa chỉ IP). Module “gst” có plen là một tham số tùy chọn chỉ ra xem có bao nhiêu bytes trong một gói tin sẽ được đưa tới ứng dụng để thực hiện việc thống kê tổng hợp. Mặc định giá trị này là 40. Module “rl” có các tham số tùy chọn drop, mark và LOCAL_MASK. Các giá trị mặc định của nó là 1, 255 và 0. LOCAL_ADDRESS phải được định nghĩa nếu không module sẽ không được nạp vào nhân. LOCAL_ADDRESS và LOCAL_MASK định nghĩa không gian địa chỉ mạng nguồn. Tham số drop quy định việc có hay không hủy gói tin. Nếu tham số này được đặt bằng 1 (giá trị mặc định) các gói tin bị nghi là tấn công sẽ bị hủy. Nếu tham số này được đặt bằng 0, các gói tin sẽ không bị hủy. Tham số mark có tác dụng nếu bạn chạy các thí nghiệm D-WARD và muốn đo hiệu quả của nó. Khi phát sinh một traffic tấn công đặt một số vào trường TOC của gói tin tấn công (với câu lệnh trên thì đó là 255). D-WARD sẽ không sử dụng giá trị của trường này để đưa ra quyết định nhưng sẽ tổng hợp xem có bao nhiêu gói tin hợp lệ hay không hợp lệ. Thống kê này có thể tìm thấy trong file “stats.txt” trong thư mục “stats”. Chạy hệ thống D-WARD Sau khi hoàn thành quá trình biên dịch, bạn có thể chạy ứng dụng D-WARD. Tài liệu hướng dẫn cụ thể bạn có thể đọc trong “man dward”. 36 4.1.3. Kết quả và đánh giá Thí nghiệm của chỉ được thực hiện với 2 loại tấn công là ICMP và TCP. Và sau đây là một số kết quả thu được Kết quả của thí nghiệm với gói tin ICMP và TCP  Một số hình ảnh về file debug và stats Hình 13: File debug/class.txt File class.txt lưu lại các phân loại luồng và kết nối của hệ thống bao gồm: địa chỉ IP nguồn: cổng nguồn, IP đích: cổng đích, số gói tin gửi, số gói tin trả lời, phân loại luồng/kết nối. Hình 14: File rlstats.txt 37 File rlstats.txt là file lưu lại giá trị giới hạn băng thông cho một luồng. Ở hình trên đó là luồng tới host đích 10.0.0.254. Với gói tin TCP: Hình 15: File conn.txt File conn.txt ghi lại thông tin như các kết nối được đưa vào bảng băm kết nối. Và chúng sẽ bị reset ngay sau khi chúng được phân loại. Cũng tương tự như ICMP chúng ta cũng các file phân loại kết nối, thống kê giới hạn băng thông ở trong các thư mục debug và stats. Chúng lần lượt là những file: class.txt, rlstats.txt, stats.txt… Đánh giá thí nghiệm: Với kết quả của thí nghiệm như trên, chúng ta có thể đưa ra một số nhận xét sau: o Hệ thống phòng chống D-WARD đã chạy đúng với mô hình lý thuyết của nó. Bên cạnh đó, nó cũng phân loại luồng và kết nối chính xác. o Với các địa chỉ IP không thuộc tập các địa mạng giám sát, hệ thống sẽ ngay lập tức hủy bỏ bởi thành phần quản lý chính sách lưu lượng. o Hệ thống D-WARD có thê chạy trên nhiều kiểu gói tin như TCP, ICMP, UDP… 38 o Hệ thống D-WARD có thể triển khai một cách rộng rãi không chỉ dừng lại ở một mạng riêng lẻ. 4.2. Cài đặt hệ thống thử nghiệm 4.2.1. Mô hình triển khai Gần giống với topo mạng triển khai bên trên nhưng bây giờ các router nguồn được kết nối tới một server cơ sở dữ liệu tập trung. Hình 16: Topo thử nghiệm 4.2.2. Mở rộng của hệ thống:  Ưu điểm: Hệ thống (Hình 16) khắc phục được điểm yếu của D-WARD khi triển khai một cách riêng lẻ. Đó là kết hợp khả năng đánh giá phân loại từ các router nguồn triển khai D- WARD khác. Cuối cùng có thể đưa ra được một phân loại chính xác hơn cho luồng và kết nối đi ra từ hệ thống của mình. Chi phí cho việc xác thực cũng không cao bằng việc triển khai trực tiếp một kết nối giữa 2 router trong hệ thống phân tán. Vì cơ chế xác thực đã được MySQL thiết kế một cách khá ổn định. 39 Hiệu năng của hệ thống sẽ được tăng lên rõ rệt. Trong một mạng có thể xảy ra cùng lúc nhiều host cùng truy cập vào một dịch vụ nào đó trên mạng nhưng chưa chắc đó là luồng tấn công. Nếu không kết hợp để đánh giá thông qua server cơ sở dữ liệu thì rất có thể D-WARD sẽ giới hạn băng thông và ngăn cản truy cập tới dịch vụ đó. Điều này làm giảm hiệu năng của hệ thống. Nhưng khi triển khai mô hình này, nó sẽ giải quyết vấn đề nêu trên một cách tốt hơn.  Hạn chế: Yêu cầu sự hợp tác của nhiều nhà quản lý router nguồn. Điều này thường rất khó đạt được vì mỗi nơi đều sử dụng những chính sách về bảo mật và phòng chống tấn công khác nhau. Cần có một server cơ sở dữ liệu chung. Chi phí cho server này thường rất khó có một tổ chức nào đứng ra chịu trách nhiệm vì kết quả của việc phòng chống này không có tác dụng một cách trực tiếp đến cơ quan doanh nghiệp. 4.2.3. Cài đặt  Thủ tục: Nếu tỉ lệ số gói tin gửi chia cho số gói tin nhận vượt quá giới hạn cho phép của kiểu gói tin đó (ICMP, TCP, UDP) hoặc đang bị phân loại là SUSPICIOUS hoặc timestamp của luồng lớn hơn hoặc bằng 5 giây thì thực hiện các lệnh: o Gửi câu lệnh cập nhật tỉ lệ của luồng lên server MySQL o Lấy thông tin về luồng để thực hiện việc tính toán o Tính lại tỉ lệ và so sánh với các giá trị rto của mỗi từng kiểu gói tin. Nếu thỏa mãn rto cho phép thì phân loại là NORMAL. Nếu ngược lại bị phân loại là ATTACK và chuyển đến thành phần quản lý giới hạn băng thông thực hiện giới hạn băng thông. Giả mã: if(tỷ lệ số gói tin gửi/số gói tin nhận > types_rto hoặc SUSPICIOUS hoặc timestamp >= 5s) { if(mysql_query(conn,update_query)){ 40 fprintf(stderr,“%s\n”,mysql_error(conn)); return 0; }; // conn là kết nối tới MySQL server, query là truy // vấn cập nhật các trường trong cơ sở dữ liệu. // types_rto tỷ lệ được phép tối đa của kiểu gói tin mysql_query(conn, get_infor); // lấy thông tin về luồng bị cho là tấn công ở //router này bằng cách gửi truy vấn lên CSDL ratio = trung bình cộng của các tỉ lệ mà MySQL server thống kê được từ các hệ thống D-WARD khác về luồng đang xét; if(ratio > type_rto) return (fs-> classification = ATTACK); else return (fs-> classification = NORMAL); } 41 Chương 5. Tổng kết Trong khóa luận này, chúng tôi đã chỉ ra các vấn đề liên quan việc triển khai hệ thống phòng chống DDoS và mở rộng triển khai nó với mô hình client-server. Khóa luận cung cấp một cái nhìn tổng quan trong phòng chống tấn công từ chối dịch vụ. Đó là hiệu quả của việc triển khai hệ thống phòng chống tại nguồn là rẻ và cao hơn hẳn. Nó cũng đưa ra giải pháp triển khai hệ thống tại nguồn để giúp nguồn nhanh chóng phát hiện và dập tắt một cuộc tấn công ngay khi nó bị kẻ tấn công nhen nhóm. Chúng tôi đã đưa ra một số kịch bản để kiểm tra hệ thống gần giống với thực tế và thu được một số kết quả cũng như thống kê của các kịch bản đó. Cuối cùng, chúng tôi đã thảo luận về việc sử dụng mô hình client – server để triển khai hệ thống D-WARD. Bằng cách thông qua server cơ sở dữ liệu để thực hiện việc tính toán và phân loại luồng một cách chính xác để việc phân loại trở nên hiệu quả hơn. Trong quá trình nghiên cứu vấn đề này, chúng tôi đã gặp và thấy được nhiều thứ cần phải được chỉnh sửa ví dụ khả năng phân loại vẫn chưa được tốt, việc giới hạn băng thông không linh hoạt…Trong tương lại, chúng tôi sẽ cố gắng hoàn thiện để có thể triển khai một hệ thống hoàn thiện và ít mắc lỗi hơn. 42 Tài liệu tham khảo [1]CSI Computer Crime and Security Survey 2009 [2]Document in Linux Redhat 8.0 kernel 2.4.18 [3]DDoS Network Attack and Recognition Defense [4]Denial of service attack [5] D-WARD, DDoS and Three Network Administrative Domains [6] Doan Cao Thanh, Deploying System for DDoS Defense, Thesis, the summer in 2008 [7] Jelena Mirkovic, D-WARD: Source-End Defense Against Distributed Denial of Service Attacks, 2003 [8] Jelena Mirkovic, Sven Dietrich, David Dittrich, Peter Reiher. Internet Denial of Service: Attack and Defense Mechanism. Prentice Hall PTR, December 30, 2004. [9] Katerina Argyraki, David R.Cheriton. Active Internet Traffic Filtering: Real- Time Response to Denial of Service Attacks. [10] K.Park and H.Lee. On the Effectiveness of Route-Based Packet Filtering for Distributed DoS Attack Prevention in Power-Law Internets. In Proceedings of ACM SIGCOMM 2001, August 2001. [11] SYN cookies [12] Lawrence Chung, Slide Client-Server Architecture, The University of Texas, Dallas