Luận văn Biên dịch cài đặt và triển khai hệ thống D-WARD

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