Giám sát an ninh mạng - Bàn về giải pháp chống DDoS

English | Vietnamese

Rules

Main Forum

Portal

Member Listing

Statistics

Search

Reading Room
[Register]

Login [ | https ]

Forum Index

Thảo luận bảo mật

Giám sát an ninh mạng - Bàn về giải pháp chống DDoS

[Discussion] Giám sát an ninh mạng - Bàn về giải pháp chống DDoS	14/12/2009 14:18:03 (+0700) \| #1 \| 200618

mrro
Administrator

Joined: 27/12/2001 05:07:00
Messages: 745
Offline

Hi all,

Đây là essay bài trình bày của tôi tại BarcampSaigon 2009 (và CSO Conference vừa rồi). Slide có thể xem ở http://www.slideshare.net/thaidn/network-security-monitoring-or-how-to-mitigate-a-ddos-attack-in-20

Mình tập trung thảo luận về cách thức chống DDoS mà tôi đề cập ở đoạn in nghiêng nhỉ?

----

Để bắt đầu thì tôi xin chia sẻ một câu chuyện. Cách đây không lâu, web site của một khách hàng bị tấn công từ chối dịch vụ DDoS. Vào lúc cao trào của vụ tấn công, có hơn 10.000 IP đến từ khắp nơi trên thế giới liên tục gửi hàng ngàn yêu cầu mỗi giây đến hệ thống của khách hàng này. Hình ảnh (slide số 4) mà quý vị đang thấy trên màn hình gồm có 2 phần nhỏ. Phần ở trên là lưu lượng dữ liệu ra vào hệ thống lúc bình thường, không bị tấn công. Phần ở dưới là lưu lượng dữ liệu ra vào hệ thống của ngay tại thời điểm đang bị tấn công dữ dội.

Như quý vị cũng thấy, chỉ trong vòng 10', từ lúc 16h10 đến 16h20, lượng dữ liệu ra vào đã tăng đột biến lên gấp gần 10 lần lúc bình thường. Nhưng đồng thời, chỉ trong vòng chưa tới 20', chúng tôi đã kiểm soát được vụ tấn công này, và đưa toàn bộ hệ thống trở lại tình trạng bình thường. Chúng tôi làm được như vậy tất cả là nhờ vào việc đã áp dụng tốt các công nghệ và nguyên tắc của giám sát an ninh mạng.

Nếu quý vị từng phải xử lý một vụ tấn công DDoS, tôi tin chắc có một câu hỏi mà quý vị đã phải tự hỏi nhiều lần: chuyện gì đang diễn ra vậy? Tại sao hệ thống của tôi đang chạy ngon lành tự dưng lại cứng đơ, khách hàng không sử dụng được nữa?

Bản thân tôi cho rằng đây là câu hỏi tối quan trọng mà bất kỳ ai làm việc trong lĩnh vực an ninh mạng đều phải tự hỏi và phải có câu trả lời xác đáng. Ngay tại thời điểm này đây, ngay khi quý vị đang ngồi ở đây nghe tôi trình bày, quý vị có biết ai đang làm gì ở đâu như thế nào trên hệ thống của quý vị hay không?

Tại sao câu hỏi đó quan trọng? Tại sao quý vị cần phải biết được ai đang làm gì ở đâu như thế nào trên hệ thống của quý vị? Đơn giản vì chúng ta không thể bảo vệ một hệ thống nếu chúng ta không biết được trạng thái của hệ thống đó. Và chúng ta chỉ có thể biết được trạng thái của một hệ thống bằng cách theo dõi nó thường xuyên. Nói cách khác, chúng ta phải biết được tất cả các hoạt động đã và đang diễn ra trên hệ thống.

Thử nhìn vào hoạt động của một khách sạn. Để đảm bảo an ninh, người ta phải đặt camera theo dõi ở khắp nơi. Các camera này chắc hẳn sẽ đưa hình ảnh về một địa điểm tập trung, nơi có các chuyên viên theo dõi 24/7 để kịp thời phát hiện và đối phó với các sự cố an ninh.

Tương tự như thế, muốn đảm bảo an ninh thông tin chúng ta cũng phải tiến hành theo dõi 24/7. Nhưng trong thực tế, theo quan sát của tôi, rất ít tổ chức ở VN có một hệ thống giám sát an ninh như thế. Để bảo vệ hệ thống mạng của mình, các doanh nghiệp và các tổ chức công thường triển khai các thiết bị như tường lửa, phần mềm chống và diệt virus, thiết bị phát hiện xâm nhập, thiết bị ngăn chặn xâm nhập. Rõ ràng họ nghĩ rằng, các thiết bị này đảm bảo an ninh mạng cho họ nên họ mới đầu từ nhiều tiền của để triển khai chúng.

Thật tế hầu hết những người giữ quyền quyết định đầu tư cho an toàn thông tin thường hay hành động theo thị trường. Ví dụ như cách đây vài năm, tường lửa là mốt. Ai cũng đầu tư làm hệ thống tường lửa nên chúng ta cũng phải làm tường lửa. Sau đó, các giải pháp phát hiện xâm nhập lên ngôi. Bây giờ cái gì đang là trào lưu quý vị biết không? ISO 27001.

Lãnh đạo doanh nghiệp thấy các các doanh nghiệp khác triển khai ISO 27001 nên họ cũng muốn doanh nghiệp của họ phải đạt được chuẩn này. Tôi không nói rằng tường lửa, thiết bị phát hiện xâm nhập hay đạt được các chuẩn như ISO 27001 và ITIL là không có tác dụng, nhưng câu hỏi chúng ta cần phải tự hỏi là: tại sao sau khi triển khai quá trời thứ đắt tiền và tốn thời gian như thế, chúng ta vẫn bị xâm nhập, chúng ta vẫn bị tấn công? Liệu ISO 27001 hay tường lửa có giúp bạn khắc phục được một vụ tấn công từ chối dịch vụ trong vòng 20'? Rồi khi đã bị xâm nhập, có thiết bị đắt tiền hay tiêu chuẩn nào giúp quý vị biết được hệ thống của quý vị bị xâm nhập khi nào, tại sao và như thế nào hay không?

Chỉ có con người mới có khả năng làm việc đó. Đây là điều tôi muốn nhấn mạnh, các thiết bị hay các tiêu chuẩn sẽ trở nên vô tác dụng nếu chúng ta không có con người thường xuyên theo dõi, giám sát hệ thống. Nghĩa là, chúng ta cần các chuyên gia giám sát hệ thống có chuyên môn cao.

Tại sao chúng ta cần phải có chuyên gia, tại sao tự bản thân các thiết bị hay các tiêu chuẩn không thể bảo vệ hệ thống mạng? Bởi vì những kẻ tấn công rất thông minh, không thể dự đoán và rất có thể có động lực cao nhất là khi thương mại điện tử phát triển như bây giờ. Máy móc và quy trình không thể ngăn chặn được họ, chắc chắn là như thế. Máy móc chắc chắn sẽ thua khi chiến đấu với não người. Đó là lý do chúng ta cần con người, cần những chuyên gia, để biến an ninh mạng thành một cuộc chiến cân sức hơn giữa người và người, thay vì giữa máy và người.

Câu hỏi đặt ra là các chuyên gia an ninh mạng cần gì để có thể phát hiện và xử lý các sự cố an ninh mạng cũng như xây dựng các kế hoạch phòng thủ? Câu trả lời chỉ có một: tất cả dữ liệu mà chúng ta có thể thu thập được trên hệ thống mạng trong khi sự cố xảy ra!

Quý vị còn nhớ ví dụ của tôi v/v làm sao để bảo vệ an ninh cho một khách sạn? Người quản lý cố gắng thu thập tất cả các dữ liệu, ở đây là hình ảnh và âm thanh, bằng các camera đặt khắp nơi trong khách sạn, và họ cần có các chuyên gia lành nghề để phân tích các hình ảnh này để kịp thời xử lý các sự cố. Họ có hệ thống chống và phát hiện cháy, họ có hệ thống chống trộm, nhưng những máy móc đó chỉ là công cụ, phần việc chính vẫn phải do con người, là các chuyên gia thực hiện.

Tóm lại, để đảm bảo an ninh, chúng ta cần phải theo dõi giám sát hệ thống mạng 24/7, và để làm chuyện đó chúng ta cần có các chuyên gia và các chuyên gia cần dữ liệu để thực hiện công việc của họ. Giám sát an ninh mạng chính là phương thức giúp chúng ta có thể thực hiện việc này một cách tối ưu nhất. Vậy giám sát an ninh mạng là gì?

Thuật ngữ giám sát an ninh mạng được chính thức định nghĩa vào năm 2002 và về cơ bản nó gồm 3 bước: thu thập dữ liệu, phân tích dữ liệu và leo thang thông tin.

Để thu thập dữ liệu, chúng ta sẽ sử dụng các phần mềm hay giải pháp có sẵn trên thị trường để thu thập dữ liệu ghi dấu hoạt động của các máy chủ, thiết bị mạng, phần mềm ứng dụng, cơ sở dữ liệu...Nguyên tắc của thu thập dữ liệu là thu thập càng nhiều càng tốt, với mục tiêu là chúng ta phải có đầy đủ thông tin về trạng thái, log file của tất cả các thành phần trong hệ thống cần phải bảo vệ. Bởi vì có muôn hình vạn trạng các loại tấn công và sự cố ATTT, chúng ta không thể biết trước dữ liệu nào là cần thiết để có thể phát hiện và ngăn chặn loại tấn công nào. Nên kinh nghiệm của tôi là nếu mà luật pháp và công nghệ cho phép, cứ thu thập hết tất cả dữ liệu mà quý vị có thể. Nguyên tắc “thà giết lầm còn hơn bỏ sót” có thể áp dụng ở đây.

Nếu phần mềm có thể giúp chúng ta làm công việc thu thập dữ liệu, thì để phân tích dữ liệu và ra quyết định, như đã nói ở trên, chúng ta cần có chuyên gia, bởi chỉ có chuyên gia mới có thể hiểu rõ ngữ cảnh của dữ liệu mà phần mềm đã thu thập được. Ngữ cảnh là tối quan trọng. Một dữ liệu được thu thập trong ngữ cảnh A có thể sẽ có ý nghĩa rất khác với cùng dữ liệu đó nếu nó thuộc về ngữ cảnh B. Ví dụ như một ngày đẹp trời hệ thống thu thập dữ liệu cảnh báo rằng một số file chương trình trên một máy chủ quan trọng đã bị thay đổi. Nếu như xét ngữ cảnh A là máy chủ đó đang được nâng cấp phần mềm, thì thông tin này không có nhiều ý nghĩa. Nhưng nếu như ở ngoài ngữ cảnh A đó, nói cách khác, không có một yêu cầu thay đổi phần mềm nào đang được áp dụng cho máy chủ đó cả, thì rõ ràng rất có thể máy chủ đó đã bị xâm nhập. Và chỉ có những chuyên gia mới có thể cung cấp được những ngữ cảnh như thế.

Quy trình giúp cho chúng ta leo thang thông tin. Leo thang thông tin là việc các chuyên gia báo cáo lên trên cho những người có quyền quyết định những vấn đề mà họ cho là quan trọng, cần phải điều tra thêm. Những người có quyền quyết định là những người có đủ thẩm quyền, trách nhiệm và năng lực để quyết định cách đối phó với các sự cố ANTT tiềm tàng. Không có leo thang thông tin, công việc của các chuyên gia sẽ trở thành vô ích. Tại sao phải phân tích để phát hiện các sự cố ANTT tiềm tàng nếu như chẳng có ai chịu trách nhiệm cho việc xử lý chúng?

Quay trở lại với câu chuyện vụ tấn công từ chối dịch vụ mà tôi chia sẻ ban đầu. Hệ thống giám sát an ninh mạng của chúng tôi thu thập tất cả dữ liệu liên quan đến hoạt động của các thiết bị như tường lửa, máy chủ proxy, máy chủ web, các ứng dụng web chạy trên các máy chủ web. Dựa vào nguồn dữ liệu phong phú này, các chuyên gia của chúng tôi đã không mất quá nhiều thời gian để phân tích và nhận ra các dấu hiệu bất thường trên hệ thống. Họ leo thang thông tin bằng cách thông báo cho tôi, và tôi quyết định kích hoạt quá trình đối phó với sự cố ANTT, ở đây là đối phó khi bị tấn công từ chối dịch vụ.

Về mặt kỹ thuật, chúng tôi đã cài đặt sẵn các biện pháp kiểm soát tự động trên hệ thống giám sát an ninh mạng, nên các chuyên gia của tôi chỉ phải theo dõi vụ tấn công xem có diễn tiến gì bất thường hay không mà không phải thực hiện thêm bất kỳ thao tác nào. Về mặt hành chính, tôi thông báo cho lãnh đạo doanh nghiệp và các đơn vị như Trung Tâm Chăm Sóc Khách hàng, Trung tâm Vận hành Data Center cũng như mở kênh liên lạc với các ISP để nhờ họ trợ giúp nếu như đường truyền bị quá tải. Như quý vị đã thấy trong một slide ở phía trước, chỉ chưa tới 20', vừa ngay sau lần kích hoạt hệ thống phòng thủ đầu tiên, vụ tấn công đã được kiểm soát thành công. Hệ thống giám sát an ninh mạng cũng giúp chúng tôi làm các báo cáo để gửi lãnh đạo cũng như gửi các cơ quan điều tra nhờ hỗ trợ truy tìm thủ phạm.

Toàn bộ phương thức giám sát an ninh mạng chỉ đơn giản như thế. Đến đây là chúng ta xong phần 1 của bài trình bày này. Tiếp theo tôi sẽ chia sẻ một số thông tin về hệ thống cũng như công tác giám sát an ninh mạng.

Về mặt kỹ thuật, chúng tôi không mất quá nhiều thời gian cho việc thiết kế hệ thống và lựa chọn giải pháp, bởi vì ngay từ đầu chúng tôi đã xác định đây là một lĩnh vực tương đối mới mẻ, thành ra một giải pháp hoàn chỉnh sẽ không có trên thị trường. Thay vào đó, giống như phát triển phần mềm theo nguyên lý agile, chúng tôi làm vừa làm vừa điều chỉnh.

Chúng tôi khởi đầu bằng việc xây dựng một hệ thống log tập trung. Như đã nói ở trên, đây là công đoạn thu thập dữ liệu. Trong quá trình làm, chúng tôi nhận thấy hầu hết các ứng dụng chạy trên nền UNIX hay các thiết bị mạng đều hỗ trợ sẵn chuẩn syslog, thành ra chúng tôi quyết định chọn phần mềm mã nguồn mở syslog-ng làm công cụ chính để thu thập log.

Tuy nhiên có hai vấn đề: các máy chủ Windows mặc định không hỗ trợ syslog; và một số ứng dụng do chúng tôi tự phát triển hay mua ngoài cũng không hỗ trợ syslog. Đối với vấn đề thứ nhất, chúng tôi cài đặt thêm một phần mềm cho các máy chủ Windows, để đẩy các sự trên trên đó về hệ thống log của chúng tôi. Đối với vấn đề thứ hai, việc đầu tiên chúng tôi làm là xây dựng một quy định về log của các ứng dụng. Trong quy định này chúng tôi yêu cầu tất cả các ứng dụng muốn được cấp quyền chạy trên hệ thống của chúng tôi thì phải thỏa mãn các tiêu chí về log các sự kiện. Chúng tôi cũng hướng dẫn và cung cấp thư viện phần mềm mẫu để các lập trình viên có thể tích hợp vào phần mềm có sẵn của họ.

Syslog-ng là một phần mềm mã nguồn mở tuyệt vời. Nó hoạt động cực kỳ ổn định, bền vững. Trong suốt hơn 3 năm triển khai hệ thống này, chúng tôi chưa bao giờ gặp sự cố ở phần mềm này. Nhưng syslog-ng cũng chỉ làm tốt nhiệm vụ thu thập dữ liệu, làm sao phân tích dữ liệu đó? Trên thị trường lúc bấy giờ có khá nhiều công cụ giúp giải quyết vấn đề này. Chúng tôi lần lượt thử nghiệm các công cụ này, và rồi chúng tôi phát hiện ra Splunk. Chúng tôi hay gọi phần mềm này là “Splunk toàn năng”. Một công cụ phân tích dữ liệu trên cả tuyệt vời!

Splunk rất hay, nhưng nếu không có các chuyên gia có kỹ năng phân tích dữ liệu để khai thác Splunk thì hệ thống cũng sẽ không đem lại nhiều ích lợi. Cái hay của Splunk là ở chỗ nó đã làm cho công việc phân tích log tưởng như nhàm chán trở nên cực kỳ thú vị. Chỉ trong một thời gian ngắn, nhân viên của tôi đã bị Splunk mê hoặc. Cái tên “Splunk toàn năng” cũng là do anh ấy đặt cho Splunk. Thành ra chúng tôi cũng không mất quá nhiều thời gian để huấn luyện, bởi vì tự bản thân giải pháp nó đã đủ thú vị để cuốn hút con người chủ động tìm hiểu nó.

Điều tối quan trọng nhất đối với một hệ thống giám sát an ninh là khả năng phân tích một lượng dữ liệu lớn một cách nhanh chóng. Splunk làm rất tốt việc này. Tuy vậy trên thị trường vẫn có các giải pháp khác hoàn toàn miễn phí như tôi liệt kê ở trên. Bản thân tôi cho rằng Hadoop + Scribe + Hive là một hướng nghiên cứu nhiều tiềm năng.

Với hệ thống này, bây giờ chúng tôi có thể an tâm rằng tôi có thể biết được chuyện gì đang diễn ra trên hệ thống mạng của các khách hàng của chúng tôi ngay tại thời điểm tôi đang viết những dòng này.

Về phía lãnh đạo doanh nghiệp, họ cũng an tâm khi biết rằng, chúng tôi có thể phát hiện, truy vết và đối phó lại với bất kỳ sự cố ANTT nào diễn ra trên hệ thống của họ. Thực tế là từ khi triển khai giải pháp này, chúng tôi giải quyết được 100% các sự cố an toàn thông tin trên hệ thống của các khách hàng của chúng tôi.

Ngoài ra hệ thống này còn giúp chúng tôi phát hiện và xử lý hơn phân nửa các sự cố an toàn thông tin. Có rất nhiều tình huống, nếu không có sự hỗ trợ của hệ thống này, chúng tôi sẽ không thể giải quyết được vấn đề. Lại quay lại với câu chuyện bị tấn công DDoS ở trên.

Nhắc lại, một khách hàng của chúng tôi từng bị tấn công DDoS trên diện rộng vào hệ thống máy chủ Internet Banking. Ở thời điểm cao trào, có hơn 10000 IP gửi hàng ngàn request/s đến máy chủ của họ. Làm thế nào để nhanh chóng lấy ra được danh sách 10000 IP này, ngăn chặn chúng trên hệ thống firewall, mà không chặn nhầm khách hàng? Làm thế nào để có thể tự động hóa quá trình trên, chẳng hạn như cứ mỗi 15' sẽ lấy ra danh sách các IP đang tấn công, cập nhật bộ lọc của tường lửa?

Với hệ thống này, chúng tôi chỉ cần soạn thảo một đoạn script ngắn để lấy ra danh sách IP đang gửi hơn 100 request/s rồi cài đặt chương trình để tự động cập nhật bộ lọc của firewall mỗi 15'. Một vấn đề tưởng như nan giải có thể giải quyết nhanh gọn lẹ và rất rẻ.

Các giải pháp chống DDoS sẽ có 2 thành phần chính: phát hiện và đánh chặn. Các giải pháp có sẵn trên thị trường như các thiết bị của các hãng lớn hay các giải pháp mở như Iptables + Snort inline thường cố gắng phân tích các packet/request để phân loại chúng theo thời gian thực. Nghĩa là khi có một packet/request đi vào, các giải pháp này sẽ cố gắng xác định xem packet đó có phải là một phần của vụ tấn công hay không, nếu phải thì thực hiện đánh chặn.

Sự khác biệt của giải pháp của chúng tôi so với các giải pháp chống DDoS đang có trên thị trường là chúng tôi không cố gắng phân loại và ngăn chặn các packet/request theo thời gian thực. Thay vào đó, chúng tôi tách phần phát hiện ra khỏi hệ thống phòng thủ, và thực hiện phần phát hiện hoàn toàn offline bằng cách sử dụng thông tin từ hệ thống NSM.

Cụ thể, thông tin từ hệ thống đánh chặn cũng như các nguồn khác như web server, proxy hay firewall sẽ được đưa vào hệ thống phân tích để chạy offline, rồi kết quả phân tích này sẽ được cập nhật ngược trở lại cho hệ thống đánh chặn. Với cách làm này, giải pháp của chúng tôi có thể đáp ứng được lượng tải rất lớn vì chúng tôi không phải tốn quá nhiều resource để phân tích on-the-fly một packet hay request như các giải pháp khác.

Về các hướng phát triển trong thời gian tới, tôi thấy một ứng dụng hay ho khác của hệ thống giám sát an ninh mạng là nó giúp chúng tôi có thể đo lường được mức độ an toàn của hệ thống. Có một nguyên tắc lâu đời của quản lý là: chúng ta không thể quản lý những gì chúng ta không thể đo đạc. Do đó để quản lý được an toàn thông tin, chúng ta phải biến an toàn thông tin thành những thông số có thể đo đạc và so sánh được. Đây là một hướng tiếp cận an toàn thông tin từ góc nhìn của người quản lý mà chúng tôi muốn áp dụng cho các khách hàng trong thời gian sắp tới.

----

Tài liệu tham khảo:

- Ký sự các vụ DDoS vào HVAOnline

- http://taosecurity.blogspot.com

http://tinsang.net

TetCon 2013 http://tetcon.org

Làm an toàn thông tin thì học gì?/hvaonline/posts/list/42133.html

[Discussion] Giám sát an ninh mạng - Bàn về giải pháp chống DDoS	14/12/2009 15:09:28 (+0700) \| #2 \| 200631

LeVuHoang
HVA Friend

Joined: 08/03/2003 16:54:07
Messages: 1155
Offline

Đối với vấn đề thứ nhất, chúng tôi cài đặt thêm một phần mềm cho các máy chủ Windows, để đẩy các sự trên trên đó về hệ thống log của chúng tôi

Thái cho hỏi là syslog/udp, có giải phảp syslog/tcp nào không?

Theo như tui hiểu, điều cốt lõi trong mô hình của mrro là log central và analyzer. Analyzer server sẽ tiến hành kết nối vào log central, phân tích, tổng hợp, đưa ra IPs có hơn 100 request/s rồi đưa ngược trở lại vào iptables để ngăn chặn. Những IP này có thể được unblock theo thời gian định trước.

Bài giới thiệu của mrro có phần hơi chung chung quá, mrro có thể giới thiệu kỹ hơn về server offline analyze kia không?
Cụ thể là, chặn ở tầng network và application như thế nào? Có còn chặn ở tầng nào khác hay không?

Ngoài ra, như ý tui đã nói ở phần trước, nếu 1 net cafe vài trăm users đang sử dụng. 1 user DoS site khách hàng, IP của net cafe đó sẽ được đưa vào blocked IP. Vậy tất cả các người dùng khác đều không thể truy cập được?

Một ý nữa hôm trước tui có nói sơ qua, là chặn theo request. Mô hình như sau:
attacker ===> analyzer ===> webserver

Bước 1: attacker request lần đầu tiên. Analyzer sẽ tiến hành insert 1 giá trị vào cookie của attacker, ví dụ count=1
attacker ===> analyzer [count = 1; requesttime=12:00:00] ===> webserver

Bước 2: attacker request tấn công lần nữa
attacker ===> analyzer [count =2; requesttime=12:00:01] ===> webserver

Trong 1 khoảng thời gian định trước, ví dụ như 1 giây, analyzer thấy số lượng request từ attacker có count quá nhiều, sẽ tiến hành deny request đó.
Như vậy, dù có cùng 1 IP, nhưng khác cookie, cũng vẫn truy cập bình thường

attacker ===> analyzer [count=100; requesttime=12:00:02] [stop]
user ===> analyzer [count=2; requesttime=12:00:02] ===> webserver

Nhiệm vụ duy nhất của analyzer là gán và check giá trị cookie của attacker.

[Discussion] Giám sát an ninh mạng - Bàn về giải pháp chống DDoS	14/12/2009 16:30:14 (+0700) \| #3 \| 200643

Ky0
Moderator

Joined: 16/08/2009 23:09:08
Messages: 532
Offline

LeVuHoang wrote:

Nếu 1 net cafe vài trăm users đang sử dụng. 1 user DoS site khách hàng, IP của net cafe đó sẽ được đưa vào blocked IP. Vậy tất cả các người dùng khác đều không thể truy cập được?

Vấn đề này anh conmale cũng đã đề cập và giải quyết trong loạt bài "Ký sự các vụ DDoS vào HVAOnline" rồi mà anh!

Theo em mô hình như anh đề cập: attacker ===> analyzer ===> webserver
thì trong loạt bài của anh conmale: Analyzer chính là IPtables + Snort, analyzer ở trong bài viết đó anh conmale đã dựa vào sự khác biệt của gói tin hợp lệ và gói tin tấn công để tiến hành lọc chứ không có block. Tuy nhiên giải pháp này cần sự can thiệp của người quản trị đúng như anh Thái đã nói ở trên smilie

mrro wrote:

Tóm lại, để đảm bảo an ninh, chúng ta cần phải theo dõi giám sát hệ thống mạng 24/7, và để làm chuyện đó chúng ta cần có các chuyên gia và các chuyên gia cần dữ liệu để thực hiện công việc của họ. Giám sát an ninh mạng chính là phương thức giúp chúng ta có thể thực hiện việc này một cách tối ưu nhất.

Vài ý kiến!

UITNetwork.com
Let's Connect

[Discussion] Giám sát an ninh mạng - Bàn về giải pháp chống DDoS	15/12/2009 00:09:35 (+0700) \| #4 \| 200669

hizit91
Member

Joined: 04/01/2009 20:29:43
Messages: 133
Offline

Giải pháp anh mrro đưa ra mạnh ở chổ "tải lớn" vì lúc này việc nhận dạng thời gian thực lại chính là nguyên nhân làm cho cuộc DDoS thành công.

Với mức độ tấn công này việc chặn ip là cần thiết (các user cùng ip chắc hẳn có mối quan hệ với nhau, tìm ẩn nguy cơ, trừ việc cùng ip do isp).

Giải pháp cookie không hoàn chỉnh vì cookie ở đầu cuối người dùng, mà đầu cuối lại đã bị chiếm quyền điều khiển, hơn nữa việc DDoS không chỉ riêng web server.

Hết cấp ba, ta lên cấp bố smilie

[Discussion] Giám sát an ninh mạng - Bàn về giải pháp chống DDoS	15/12/2009 02:51:16 (+0700) \| #5 \| 200673

Abe
Researcher

Joined: 29/03/2002 03:19:17
Messages: 145
Offline

Nhắc lại, một khách hàng của chúng tôi từng bị tấn công DDoS trên diện rộng vào hệ thống máy chủ Internet Banking. Ở thời điểm cao trào, có hơn 10000 IP gửi hàng ngàn request/s đến máy chủ của họ. Làm thế nào để nhanh chóng lấy ra được danh sách 10000 IP này, ngăn chặn chúng trên hệ thống firewall, mà không chặn nhầm khách hàng? Làm thế nào để có thể tự động hóa quá trình trên, chẳng hạn như cứ mỗi 15' sẽ lấy ra danh sách các IP đang tấn công, cập nhật bộ lọc của tường lửa?

Với hệ thống này, chúng tôi chỉ cần soạn thảo một đoạn script ngắn để lấy ra danh sách IP đang gửi hơn 100 request/s rồi cài đặt chương trình để tự động cập nhật bộ lọc của firewall mỗi 15'. Một vấn đề tưởng như nan giải có thể giải quyết nhanh gọn lẹ và rất rẻ.

Đoạn này là hơi "tào lao" nha smilie

Jk, có lẽ ở đây bạn mrro nói hơi vắn tắt hoặc có thể chỉ là đưa ra ví dụ là như thế.. thế nên con số về cả attacker IP lẫn "sample signature" cũng đều đẹp và đều có thể...nghĩ ngay ra được như thế

Chứ tình huống thật thì nó khác từ nhiều cho tới rất nhiều nha smilie

[Discussion] Giám sát an ninh mạng - Bàn về giải pháp chống DDoS	15/12/2009 08:55:10 (+0700) \| #6 \| 200701

LeVuHoang
HVA Friend

Joined: 08/03/2003 16:54:07
Messages: 1155
Offline

Vấn đề này anh conmale cũng đã đề cập và giải quyết trong loạt bài "Ký sự các vụ DDoS vào HVAOnline" rồi mà anh!

Giải pháp này theo Hoàng được biết thì Iptables block IP thì phải, mrro confirm nhé.

trong loạt bài của anh conmale: Analyzer chính là IPtables + Snort, analyzer ở trong bài viết đó anh conmale đã dựa vào sự khác biệt của gói tin hợp lệ và gói tin tấn công để tiến hành lọc chứ không có block. Tuy nhiên giải pháp này cần sự can thiệp của người quản trị đúng như anh Thái đã nói ở trên

Đúng rồi, nhưng vấn đề trong chủ đề mrro muốn nêu ra là, "máy học". Tự động active response chứ ít có sự tác động của con người càng tốt.

Giải pháp cookie không hoàn chỉnh vì cookie ở đầu cuối người dùng, mà đầu cuối lại đã bị chiếm quyền điều khiển, hơn nữa việc DDoS không chỉ riêng web server.

Giải pháp cookie chỉ là 1 trong nhiều tần để cản lọc mà thôi.

Chứ tình huống thật thì nó khác từ nhiều cho tới rất nhiều nha

Nên mới chờ mrro nói chi tiết đây, hehe

[Discussion] Giám sát an ninh mạng - Bàn về giải pháp chống DDoS	15/12/2009 10:07:19 (+0700) \| #7 \| 200724

myquartz
Member

Joined: 04/01/2005 04:58:30
Messages: 563
Offline

Tham gia một chút với mrro!
Ko rõ mrro đã hay là dự định áp dụng NSM và một hệ thống cảnh báo/phân tích tương tự cho tổ chức mình đang làm ko? Kết quả ra sao?
Hiện tại, tui cũng làm 1 lãnh vực tương tự, và đang áp dụng là phòng vệ online, vừa áp dụng tổng thể, vừa áp dụng tự bảo vệ (tức là mỗi thành phần, mỗi dịch vụ tự bảo vệ mình, và tất cả có bảo vệ chung). Việc bảo vệ này gồm chống DDoS này dùng biện pháp thống kê đơn lẻ từng dịch vụ, ví dụ ước lượng truy cập trong 1 đơn vị thời gian để tự động chặn/ko chặn nguồn đó. Chặn thì có lớp: lớp network (block IP), và chặn ở mức ứng dụng (ví dụ 10 lần đăng nhập sai sẽ ko đc đăng nhập từ IP/cùng user đó nữa). Việc ước lượng đó do admin từng ứng dụng phân tích tình hình hoạt động bình thường theo kỳ (qua logging, qua các công cụ monitor tập trung hoặc specify cho dịch vụ, tỉ dụ Oracle chẳng hạn) để điều chỉnh giá trị phù hợp.
Việc đó kiểm soát online đó, có vẻ phản ứng nhanh hơn là phân tích offline, ko rõ mrro có ý kiến thế nào?

[Discussion] Giám sát an ninh mạng - Bàn về giải pháp chống DDoS	15/12/2009 10:48:02 (+0700) \| #8 \| 200735

mrro
Administrator

Joined: 27/12/2001 05:07:00
Messages: 745
Offline

Mình sẽ trả lời lần lượt từng bạn. Nhưng trước khi bắt đầu thì mình muốn nhấn mạnh là giải pháp của mình đã chạy tốt và hiệu quả rồi, thì mình mới dám viết như thế này, chứ còn nếu mà chưa làm thử, làm sao mình dám "nói như đúng rồi" được. Các con số mình đưa ra đều lấy ra từ một tình huống có thật, chứ không phải là mình tự bịa ra cho nó đẹp như bạn Abe nghĩ.

@LeVuHoang: về chặn nhiều tầng nhiều lớp thì ký sự của anh conmale đã bàn rất nhiều rồi, mình không bàn lại ở đây làm gì. Mình chỉ tập trung vào cái ý ở đây là giải pháp chặn ở tầng IP, bằng cách dựa vào tầng suất tấn công mà phân biệt được đâu là zombie request, đâu là customer request. Còn những vấn đề nhỏ lẻ khác như nếu có nhiều máy nằm sau một IP thì giải quyết làm sao, hôm ở Barcamp Saigon 2009, mình cũng đã trả lời câu hỏi này. Lúc này nó lại quay lại với cách mà anh conmale đã làm: chặn ở network kô được thì lên application chặn. zoombie request thì thường sẽ khác với customer request, mình sẽ dựa vào đó để chặn trên application.

nhưng nếu zombie request giống y chang customer request thì sao? thì mình sẽ cho nó đi vào luôn chứ sao bây giờ :-D. nếu mà hệ thống thiết kế làm sao mà chỉ có vài IP gửi request liên tục mà cũng chết thì phải coi lại thiết kế hệ thống trước đã, rồi mới bàn đến việc chống DDoS. giống như trước đây, HVAOnline sử dụng LAMP, việc phòng thủ sẽ khó khăn, nhưng sau này khi anh conmale đổi sang J2EE thì mọi thứ đã đỡ vất vả hơn rất nhiều.

về giải pháp của LeVuHoang thì mình thấy giải pháp này sai ở chỗ là zombie kô có chấp nhận cookie. thật ra zombie chỉ gửi cái request rồi nó forget liền cái request đó, chứ nó có thèm đợi response đâu mà mình chèn cookie vào, rồi hi vọng nó sẽ gửi lại cái cookie đó cho mình để mình phân tích. giải pháp của Hoàng có lẽ có thể sử dụng được trong trường hợp X-flash hoặc các dạng DDoS dùng chính browser của zombie để gửi request.

@myquartz: như mình đã nói ở trên, hệ thống này của mình đã được áp dụng cho ít nhất là 02 khách hàng của mình. về giải pháp của bạn thì mình nghĩ về mặt phương thức là giống nhau, nghĩa là cũng theo dõi thông tin log, rồi dựa vào thông tin log này để quyết định sẽ hành xử như thế nào.

sự khác biệt chỉ là mình không muốn mỗi request đi vào mình lại phải tính toán xem request đó có vi phạm policy gì về tần suất request hay không, bởi vì mình cho rằng làm như thế sẽ mất nhiều thời gian khi mà lượng request tăng cao. do đó mình tách phần phân tích ra, làm một lần sau một khoảng thời gian nhất định. thật tế nếu mình giảm cái cronjob xuống còn 1 lần/phút thì mình cũng sẽ có cách làm gần như là real-time. nhưng câu hỏi là có cần thiết phải làm nhanh hay không? cái này cũng chính là cái ý tốc độ phản ứng mà myquartz đưa ra. mình chấp nhận phản ứng chậm một chút, đổi lại mình có khả năng phản ứng vói số lượng request nhiều hơn. mình nghĩ cái này là lựa chọn của mỗi người thôi. sở dĩ mình không làm theo kiểu real time vì mình nghĩ real time sẽ thất bại khi mà số lượng request quá lớn.

-m

http://tinsang.net

TetCon 2013 http://tetcon.org

Làm an toàn thông tin thì học gì?/hvaonline/posts/list/42133.html

[Discussion] Giám sát an ninh mạng - Bàn về giải pháp chống DDoS	15/12/2009 12:35:25 (+0700) \| #9 \| 200749

LeVuHoang
HVA Friend

Joined: 08/03/2003 16:54:07
Messages: 1155
Offline

zoombie request thì thường sẽ khác với customer request, mình sẽ dựa vào đó để chặn trên application.

Trên thực tế thì trong cuộc DoS vừa qua của mrro và x-flash của conmale, thì đều có signature khác với customer request.
Giờ đặt trong trường hợp là ứng dụng gởi request hợp lệ (có thể đơn giản là dùng IE component, hoặc tạo 1 cái request có header y hệt như IE header) thì tầng application chặn như thế nào?
Nếu tinh vi hơn nữa, sau mỗi request tiến hành clear cookie thì sao?
Mình đang quan tâm việc chặn ở tầng application và giải pháp trên sẽ hành xử ra sao nếu các cú request nằm trong cùng 1 isp gateway.

[Discussion] Giám sát an ninh mạng - Bàn về giải pháp chống DDoS	15/12/2009 12:38:37 (+0700) \| #10 \| 200750

lQ
Moderator

Joined: 29/03/2005 17:06:20
Messages: 494
Offline

để mình trả lời một số ý của LVH:

LeVuHoang wrote:

Thái cho hỏi là syslog/udp, có giải phảp syslog/tcp nào không?

Theo như tui hiểu, điều cốt lõi trong mô hình của mrro là log central và analyzer. Analyzer server sẽ tiến hành kết nối vào log central, phân tích, tổng hợp, đưa ra IPs có hơn 100 request/s rồi đưa ngược trở lại vào iptables để ngăn chặn. Những IP này có thể được unblock theo thời gian định trước.

Bài giới thiệu của mrro có phần hơi chung chung quá, mrro có thể giới thiệu kỹ hơn về server offline analyze kia không?
Cụ thể là, chặn ở tầng network và application như thế nào? Có còn chặn ở tầng nào khác hay không?

Ngoài ra, như ý tui đã nói ở phần trước, nếu 1 net cafe vài trăm users đang sử dụng. 1 user DoS site khách hàng, IP của net cafe đó sẽ được đưa vào blocked IP. Vậy tất cả các người dùng khác đều không thể truy cập được?

syslog-ng cũng đã support syslog/tcp, nhưng bản trên Linux thì có free, còn bản trên Windows thì phải trả phí. Có điều, khi nào cần đến tcp thay cho udp, hay thậm chí khi nào cần đến tcp+ssl, thì tuỳ hiện trạng và nhu cầu của mỗi doanh nghiệp. Cũng nên nhớ một số thiết bị cực kỳ quan trọng như firewalls, IDS/IPS, cũng chỉ support syslog/udp.

Nếu đã chọn syslog-ng để thu thập dữ liệu, thì cũng nên chọn agent của nó, đỡ mất công tìm hiểu phần mềm khác cho khoẻ smilie

.

Đã block trên firewall thì hiển nhiên phải có bước unblock. Nguyên tắc unblock thì cũng có nhiều lựa chọn. VD nếu như ip bị block, trong khoảng 1 tiếng, không truy cập (và hiển nhiên sau đó bị block) nữa thì gỡ khỏi danh sách block ip.

Giải pháp nào nếu triển khai, cũng sẽ có hạn chế, thậm chí khi kẻ tấn công biết được nguyên tắc của giải pháp, thì cũng sẽ tận dụng để tránh khỏi bị phát hiện và 'phán xét'. Ngược lại, việc block nhầm vào IP của khách hàng cũng hay là IP chung của khách hàng và của zombies vẫn có thể xảy ra như thường. Đành chịu khó tiếp điện thoại từ Trung tâm dịch vụ khách hàng, để gỡ IP đó khỏi danh sách, hoặc cập nhật vào whitelist. Đơn giản phải ko smilie

[Discussion] Giám sát an ninh mạng - Bàn về giải pháp chống DDoS	15/12/2009 12:50:18 (+0700) \| #11 \| 200751

LeVuHoang
HVA Friend

Joined: 08/03/2003 16:54:07
Messages: 1155
Offline

Đành chịu khó tiếp điện thoại từ Trung tâm dịch vụ khách hàng, để gỡ IP đó khỏi danh sách, hoặc cập nhật vào whitelist. Đơn giản phải ko?

Cái này đáng giá đây smilie

.
Giải pháp cookie bên trên chỉ là 1 suy nghĩ làm sao cố gắng "phân loại" được các request gọi đến. Gán cho nó 1 cái gì đó có đặc tính. Dĩ nhiên là không có giải pháp nào toàn diện cả, và phải cải tiến hoặc suy nghĩ giải pháp mới.

[Discussion] Giám sát an ninh mạng - Bàn về giải pháp chống DDoS	15/12/2009 13:29:15 (+0700) \| #12 \| 200760

gamma95
Researcher

Joined: 20/05/2003 07:15:41
Messages: 1377
Location: aaa">
Offline

LeVuHoang wrote:

zoombie request thì thường sẽ khác với customer request, mình sẽ dựa vào đó để chặn trên application.

Trên thực tế thì trong cuộc DoS vừa qua của mrro và x-flash của conmale, thì đều có signature khác với customer request.
Giờ đặt trong trường hợp là ứng dụng gởi request hợp lệ (có thể đơn giản là dùng IE component, hoặc tạo 1 cái request có header y hệt như IE header) thì tầng application chặn như thế nào?
Nếu tinh vi hơn nữa, sau mỗi request tiến hành clear cookie thì sao?
Mình đang quan tâm việc chặn ở tầng application và giải pháp trên sẽ hành xử ra sao nếu các cú request nằm trong cùng 1 isp gateway.

@HoaVeLu: Khi mà zombie nó giống người wá thì làm sao phân biệt được bây giờ? Chắc có nước mỗi request bắt nhập một cái captcha thôi. Dùng thằng recaptcha chẳng hạn, coi như thằng recaptcha nó hứng chưởng cho mình trước vậy smilie

Cánh chym không mỏi
lol

[Discussion] Giám sát an ninh mạng - Bàn về giải pháp chống DDoS	15/12/2009 13:36:38 (+0700) \| #13 \| 200763

LeVuHoang
HVA Friend

Joined: 08/03/2003 16:54:07
Messages: 1155
Offline

Đây cũng là 1 giải pháp, nếu số request của 1 IP vượt quá giới hạn, web server hiển thị captcha cho người dùng nhập vào. Sau khi nhập xong, sẽ được cấp cookie "tao là người", và có cookie đó sẽ không bị hạn chế truy cập nữa. hehe

[Discussion] Giám sát an ninh mạng - Bàn về giải pháp chống DDoS	15/12/2009 13:58:51 (+0700) \| #14 \| 200771

gamma95
Researcher

Joined: 20/05/2003 07:15:41
Messages: 1377
Location: aaa">
Offline

LeVuHoang wrote:

Đây cũng là 1 giải pháp, nếu số request của 1 IP vượt quá giới hạn, web server hiển thị captcha cho người dùng nhập vào. Sau khi nhập xong, sẽ được cấp cookie "tao là người", và có cookie đó sẽ không bị hạn chế truy cập nữa. hehe

Cũng ko được anh giai, cái cookie "tao là người" đó có thể bị tụi zombie xài chung

Cánh chym không mỏi
lol

[Discussion] Giám sát an ninh mạng - Bàn về giải pháp chống DDoS	15/12/2009 14:00:16 (+0700) \| #15 \| 200772

Abe
Researcher

Joined: 29/03/2002 03:19:17
Messages: 145
Offline

@mrro: Hầy hầy.. mình đâu có ý nói là mrro bịa ra đâu.. Mình có nói là do nói *vắn tắt* hoặc là *ví dụ* (có thể dựa trên thực tế) để trình bày cách giải quyết của mrro mà. Vì mình thấy thế nên các con số nó mới "tròn trịa" như thế, tất nhiên con số ở đây mà để chính xác là mười vạn tám ngàn chín trăm năm mươi mốt IP thì cũng chẳng để làm gì. Mà kể cả *bịa* ra như vậy trong tình huống như thế này cũng đâu có vấn đề gì đâu.

Sorry là trong topic thảo luận mình có chút không nghiêm túc, nhưng ý mình là:

- Từ *đầu vào* là 10.000 IP DDoS, (sau một loạt biện pháp nghiệp vụ), đùng một cái đưa ra ngay chính sách và chạy script để lấy những IP có tần suất là 100 request/s (con số thực sự rất lớn - IMHO - ngay cả trong tâm bão). Nên mình nghĩ là trong quá trình này phải có một loạt các động tác thì mới đạt được kết quả như ý, và con số 100 req/s sẽ phải thay đổi liên tục và liên tục được làm mịn thì mức độ hiệu quả mới thật sự cao.

- Như trên mình đã nói, nếu chỉ giải quyết như vậy thì mình nghĩ biểu đồ nó sẽ tương tự như thế này, vì việc làm của mình là offline chứ không phải online và tần suất chạy cronjob (như mrro nói) cũng không dày.

[i]Note:
1. Mình xin nhấn mạnh lại là mình không có suy nghĩ hay có ý nói là con số hay các thông tin mrro cung cấp là bịa đặt này kia.
2. Tất cả những điều mình nói ở trên dựa theo suy nghĩ của riêng mình với các con số và giả định mình đang ở trong tình huống đấy.
3. (Sẽ điền vào đây khi nhớ ra smilie

)

[Discussion] Giám sát an ninh mạng - Bàn về giải pháp chống DDoS	15/12/2009 14:22:04 (+0700) \| #16 \| 200778

myquartz
Member

Joined: 04/01/2005 04:58:30
Messages: 563
Offline

Giải pháp ở lớp ứng dụng, như là kiểm tra cookie, kiểu gì cũng sẽ tạo nên tải nhất định cho hệ thống (gồm tải mạng và/hoặc tải của máy chủ). Hệ thống chịu tải chính là hệ thống chính đang phục vụ khách hàng thật, hoặc là bạn có hệ thống riêng để chịu cái tải này.
Do đó, phải đầu tư cho nó, 1 giá thành đáng kể để chịu và xử lý nổi dữ liệu giả này không.
Ví dụ: thường thì website của bạn chịu 10K request trong vòng 1 phút chẳng hạn, nhưng đột nhiên nó tăng lên tới 100K, muốn cái cookie này phát huy hiệu quả, ko bị thành trạng thái DoS thì hệ thống kiểm tra cookie và cho phép hay không đó phải gánh được tải 100K này. Nếu không gánh được 100K, thì nghĩa là chính nó bị out of service, và các cookie hợp lệ cũng bị vạ lây.
Đây là giải pháp có tính phân biệt request thật/giả tốt hơn giải pháp chặn ở tầng Network, nhưng cost cho nó cũng cao hơn nhiều. Quan trọng là bạn có khả năng đầu tư nó và nó áp dụng cho ứng dụng nào hay thôi.
Với các hosting nhỏ, 1 server với đường truyền hạn chế chẳng hạn, thì họ không chọn nó, vì tiêu chí giá thành.

[Discussion] Giám sát an ninh mạng - Bàn về giải pháp chống DDoS	15/12/2009 14:52:35 (+0700) \| #17 \| 200783

LeVuHoang
HVA Friend

Joined: 08/03/2003 16:54:07
Messages: 1155
Offline

@gamma: Dãy cookie "tao là người" có thể là 1 dãy random nhưng ở 1 số vị trí là cố định.
Ví dụ:
123ab456
789ab012

Nếu attacker tinh ý thì vẫn có thể đoán được tuy nhiên cũng giảm thiểu được tình trạng hiện tại?

@myquartz: Điều này là yếu điểm của real time response, tương tự như sử dụng mod_security hay snort để phân tích payload của request. Càng giới hạn offset của việc tìm kiếm sẽ giảm tải cho hệ thống.

1 cách khác có thể thay thế cho cookie là random url. Khi người dùng xác thực thành công, có thể được cấp cho value kiểu: /index.php?auth=123ab456
Đây cũng có thể nói là 1 kiểu cấp session. Bạn login rồi thì đi tiếp, chưa được cấp session thì dừng lại nhập captcha.
Cũng nên nhớ rằng, chỉ khi IP nào có request đột biến mới xuất hiện bản thông báo trên.

1 giải pháp khác nữa, là sử dụng .htaccess kết hợp với offline log analyzer của mrro, nếu IP đó vượt quá limit request, script sẽ tự động update IP trên vào .htaccess, yêu cầu nhập 1 user/pass định sẵn để tiếp tục.

Trở lại giải pháp của mrro là chặn ở tầng IP, trong kí sự của conmale thì luôn cật lực phản đối việc chặn như thế. Vậy giải pháp của mrro ngoài việc khách hàng gọi điện unblock IP thì có giải pháp nào khác để dung hoà cả 2?

Ngoài ra, ai có giải pháp hay hơn thì cứ trình bày cho mọi người cùng tìm hiểu.

[Discussion] Giám sát an ninh mạng - Bàn về giải pháp chống DDoS	15/12/2009 15:35:26 (+0700) \| #18 \| 200789

lQ
Moderator

Joined: 29/03/2005 17:06:20
Messages: 494
Offline

Abe wrote:

- Từ *đầu vào* là 10.000 IP DDoS, (sau một loạt biện pháp nghiệp vụ), đùng một cái đưa ra ngay chính sách và chạy script để lấy những IP có tần suất là 100 request/s (con số thực sự rất lớn - IMHO - ngay cả trong tâm bão). Nên mình nghĩ là trong quá trình này phải có một loạt các động tác thì mới đạt được kết quả như ý, và con số 100 req/s sẽ phải thay đổi liên tục và liên tục được làm mịn thì mức độ hiệu quả mới thật sự cao.

- Như trên mình đã nói, nếu chỉ giải quyết như vậy thì mình nghĩ biểu đồ nó sẽ tương tự như thế này, vì việc làm của mình là offline chứ không phải online và tần suất chạy cronjob (như mrro nói) cũng không dày.

Abe đọc chưa kỹ bài đầu tiên của mrro rồi. Trích 1 đoạn:

Về mặt kỹ thuật, chúng tôi đã cài đặt sẵn các biện pháp kiểm soát tự động trên hệ thống giám sát an ninh mạng, nên các chuyên gia của tôi chỉ phải theo dõi vụ tấn công xem có diễn tiến gì bất thường hay không mà không phải thực hiện thêm bất kỳ thao tác nào. ...

Cái hình đó cũng ... đúng, nhưng chỉ khi mình phải phân tích bằng tay, rồi cập nhật danh sách blocked ip dần dần. Nhưng đúng ra cũng không được 'nhọn nhọn' smilie

kiểu đang tăng lập tức giảm đi 1 chút, mà phải là lên cao và giữ nguyên độ cao, cho đến khi các chuyên gia cập nhật danh sách blocked ip lần đầu thì bắt đầu giảm smilie

[Discussion] Giám sát an ninh mạng - Bàn về giải pháp chống DDoS	15/12/2009 16:11:01 (+0700) \| #19 \| 200795

myquartz
Member

Joined: 04/01/2005 04:58:30
Messages: 563
Offline

LeVuHoang wrote:

@myquartz: Điều này là yếu điểm của real time response, tương tự như sử dụng mod_security hay snort để phân tích payload của request. Càng giới hạn offset của việc tìm kiếm sẽ giảm tải cho hệ thống.

1 cách khác có thể thay thế cho cookie là random url. Khi người dùng xác thực thành công, có thể được cấp cho value kiểu: /index.php?auth=123ab456
Đây cũng có thể nói là 1 kiểu cấp session. Bạn login rồi thì đi tiếp, chưa được cấp session thì dừng lại nhập captcha.
Cũng nên nhớ rằng, chỉ khi IP nào có request đột biến mới xuất hiện bản thông báo trên.

1 giải pháp khác nữa, là sử dụng .htaccess kết hợp với offline log analyzer của mrro, nếu IP đó vượt quá limit request, script sẽ tự động update IP trên vào .htaccess, yêu cầu nhập 1 user/pass định sẵn để tiếp tục.

Trở lại giải pháp của mrro là chặn ở tầng IP, trong kí sự của conmale thì luôn cật lực phản đối việc chặn như thế. Vậy giải pháp của mrro ngoài việc khách hàng gọi điện unblock IP thì có giải pháp nào khác để dung hoà cả 2?

Ngoài ra, ai có giải pháp hay hơn thì cứ trình bày cho mọi người cùng tìm hiểu.

Tải của mod_security hay snort, nó chỉ xảy ra khi chưa có action chặn. Nếu chặn ở tầng network (ở cửa vào hoặc 1 chỗ nào đó phù hợp) thì 2 cái này hoàn toàn giải phóng khỏi việc kiểm tra các request từ nguồn IP biết chắc chắn rằng không hợp lệ. Vì ko có kết nối nào được mở cả, không có dữ liệu nào khác ngoài gói syn đến FW.
Còn ở lớp ứng dụng, thì kết nối bất hợp lệ vẫn được tạo ra, request tấn công vẫn được gửi đến, và phải check luôn luôn các dữ liệu đó trước khi chuyển cho web app xử lý => tăng tải cho hệ thống kiểm soát đó.

[Discussion] Giám sát an ninh mạng - Bàn về giải pháp chống DDoS	15/12/2009 16:31:45 (+0700) \| #20 \| 200799

LeVuHoang
HVA Friend

Joined: 08/03/2003 16:54:07
Messages: 1155
Offline

Nếu chặn ở tầng network (ở cửa vào hoặc 1 chỗ nào đó phù hợp) thì 2 cái này hoàn toàn giải phóng khỏi việc kiểm tra các request từ nguồn IP biết chắc chắn rằng không hợp lệ. Vì ko có kết nối nào được mở cả, không có dữ liệu nào khác ngoài gói syn đến FW.

Vì thế phải kết hợp chặn ở nhiều tầng. Trong loạt bài "Ký sự các vụ DDoS vào HVAOnline", ngoại trừ việc cản ở iptables, còn bao gồm cả sử dụng mod_security và snort để phân tích payload và chặn gói tin.

Còn ở lớp ứng dụng, thì kết nối bất hợp lệ vẫn được tạo ra, request tấn công vẫn được gửi đến, và phải check luôn luôn các dữ liệu đó trước khi chuyển cho web app xử lý => tăng tải cho hệ thống kiểm soát đó.

mod_security kiểm tra url (có session) xong mới chuyển qua php, database... nhằm giảm thiểu số lượng connection.

Thiết nghĩ bạn myquartz không nên quá cứng nhắc như vậy vì filter ở network layer không phải là phương thuốc thần kỳ để có thể chặn đứng mọi cuộc tấn công. Trong loạt kí sự của bác conmale, mặc dù đã có filter ở tầng network, nhưng vì gói tin quá "hoàn hảo" nên bắt buộc phải dùng thêm snort/mod_security.
Bạn thử nghĩ nếu không để mod_security xử lý url trước khi đưa xuống php --> database thì liệu apache/mod_security chết trước hay database chết trước.

Trở lại với đề nghị của tui, log từ web server sẽ được đổ về log central, từ đó sẽ có 1 script phân tích, đẩy ngược IP lại vào .htaccess của web server và bắt người dùng nhập info hoặc captcha thay vì block IP.

[Discussion] Giám sát an ninh mạng - Bàn về giải pháp chống DDoS	15/12/2009 17:36:56 (+0700) \| #21 \| 200809

gamma95
Researcher

Joined: 20/05/2003 07:15:41
Messages: 1377
Location: aaa">
Offline

LeVuHoang wrote:

@gamma: Dãy cookie "tao là người" có thể là 1 dãy random nhưng ở 1 số vị trí là cố định.
Ví dụ:
123ab456
789ab012

Nếu attacker tinh ý thì vẫn có thể đoán được tuy nhiên cũng giảm thiểu được tình trạng hiện tại?

@myquartz: Điều này là yếu điểm của real time response, tương tự như sử dụng mod_security hay snort để phân tích payload của request. Càng giới hạn offset của việc tìm kiếm sẽ giảm tải cho hệ thống.

1 cách khác có thể thay thế cho cookie là random url. Khi người dùng xác thực thành công, có thể được cấp cho value kiểu: /index.php?auth=123ab456
Đây cũng có thể nói là 1 kiểu cấp session. Bạn login rồi thì đi tiếp, chưa được cấp session thì dừng lại nhập captcha.
Cũng nên nhớ rằng, chỉ khi IP nào có request đột biến mới xuất hiện bản thông báo trên.

Cái random cookie hay random url hay token đại loại gì đó đâu có giả quyết đc vấn đề đâu anh Hoàng, tại vì mấy cái này tụi Zombie nó share cho nhau được hết.
Trong trường hợp bắt dùng captcha mới cấp session thì cũng ko giải quyết đc vấn đề, lúc này tụi Zombie sẽ nhận lệnh từ mater (thực ra lúc này là nó nhận cái cookie/ session ) hay randome token gì đó do thằng "master" (là người thật và nó submit captcha lấy session/ cookie hợp lệ )rồi cung cấp cho cả đám Zombie.

Cánh chym không mỏi
lol

[Discussion] Giám sát an ninh mạng - Bàn về giải pháp chống DDoS	15/12/2009 17:38:51 (+0700) \| #22 \| 200810

mrro
Administrator

Joined: 27/12/2001 05:07:00
Messages: 745
Offline

Nhiều thảo luận quá, giờ mình sẽ trả lời các thắc mắc của một số bạn, rồi sau đó chắc tổng kết lại, tập trung vào 1 hay 2 ý gì đó để thảo luận thôi, tránh lan man.

@Abe: con số 100 req/s là nhầm lẫn, 200 req/phút thì chính xác hơn. Còn con số 10.000 IP thì nói cho nó chẵn lại, chênh lệch trên hay dưới nó không bao nhiêu cả. Lưu ý cách làm là lấy ra từ NSM những IP gửi lớn hơn 200 req/phút, và chặn chúng nó lại trên firewall. Do đó chọn cái con số này cũng phải tính toán, chọn như 100 req/s thì sẽ không bắt được anh zombie nào, còn chọn thấp quá thì sẽ có nhiều khách hàng chết oan. Việc này tính toán này thường là *trial-and-error*, chọn đại một con số nào đó, rồi thử xem có phù hợp hay không.

Có thể danh sách IP gửi hơn 200 req/phút sẽ ít hơn 10.000 IP kia nhiều, nhưng: 1) khi đã chặn được nhóm đứng đầu, thì nhóm còn lại thường sẽ là không đáng kể (nếu vẫn còn nhiều thì mình hạ cái tiêu chuẩn xuống: 100 req/phút chẳng hạn); 2) dẫu số lượng IP có tăng lên nhiều đi chăng nữa, nếu firewall hỗ trợ tốt, thì việc chặn 10.000 cùng lúc cũng không có vấn đề gì về mặt thiết kế của giải pháp này.

Về hình ảnh thì trong cái slide 4, hình bên dưới thể hiện rõ nhất sự hiệu quả của giải pháp này:

Như anh lQ có nói ở trên, làm tốt như thế là do có chuẩn bị trước. Chứ nếu không có chuẩn bị trước thì sẽ rất lúng túng trong việc triển khai các phương án phòng thủ.

@LeVuHoang: hi hi hi cái ý khách hàng gọi điện kêu unblock là anh lQ nói đùa thôi, chứ trong thực tế triển khai của mình, không có trường hợp đó xảy ra. mình thà bị tấn công chứ không thể chặn nhầm khách hàng được. nói cách khác, mình chỉ tập trung chặn cái nào mà mình chắc chắn hoặc rất ít có khả năng tạo ra false positive.. nói chặn là mình chặn hoàn toàn theo kiểu black-list, chứ không sử dụng captcha hay cookie gì hết. còn những trường hợp rủi ro tạo ra false positive cao hơn, mình sẽ không chặn.

điều quan trọng ở đây là làm sao phân biệt được? thế mới cần con người smilie

. chỗ này thì cho phép mình không chia sẻ, không phải vì là bí mật, mà mình không muốn những kẻ đang oánh mình có thêm thông tin. mình sẽ nói chuyện riêng với bạn nào thắc mắc.

trở ngại còn lại duy nhất ở đây như đã bàn ở trên là nếu có rất nhiều zombie request (y hệt như customer request), cỡ như 1000 req/s đi đến hệ thống chỉ từ một IP duy nhất (do ISP họ triển khai proxy), thì làm sao để ngăn chặn?

quan sát Google thì thấy họ có sử dụng giải pháp captcha. nghĩa là nếu họ phát hiện có quá nhiều request đi đến từ một IP nào đó, thì các request mới sẽ bị dừng lại, và yêu cầu nhập vào một captcha. chi tiết cách làm thì mình chưa rõ, nhưng mình nghĩ cái này cũng là một hướng thú vị.

nhưng bản thân mình thì mình không thích tạo thêm khó khăn cho khách hàng. mình rất ghét cái vụ kiểm tra captcha của Google. ngay từ đầu mình đã nói, nếu mà có vài IP thì mình sẵn sàng cho chúng nó đi vào mà không cản trở gì cả. nên đối với trường hợp này, mình thấy có nhiều cách:

* một con bot thường chỉ gửi một request cố định, chứ nó vẫn chưa đủ thông minh để giả lập quá trình browse web site của một con người. do đó mình sẽ cài đặt các cache header, để cache lại cái response trên phía proxy của ISP, làm giảm công việc xử lý của hệ thống bên mình.

* làm peering với các ISP. mình không rõ là lúc này request đi ra ISP sẽ route trực tiếp qua mình, hay vẫn phải đi qua proxy của họ, nhưng mà trên hệ thống của một khách hàng của mình có làm peering với các ISP thì thấy rất ít xuất hiện các IP proxy của ISP, mặc dù có nhiều IP đến từ ISP đó là một phần của botnet tấn công.

* các proxy đa số đều có đính kèm header cho thấy request này là của IP thật sự nào. một hệ thống NSM tốt sẽ giúp chúng ta query được phần header đó để tìm ra các IP thật sự đang gửi request, chứ không phải là IP proxy.

mình cũng muốn nhấn mạnh là bàn những cái này rất là...lý thuyết, chủ yếu là để dự phòng mà thôi. chứ thật tế các zombie request thường rất khác customer request. cái này là điểm mà mình cần phải lưu ý khi mà nói về việc chống DDoS.

do đó mình nghĩ, một khi đã phát hiện ra sự khác nhau rồi, mình sẽ dùng application proxy vừa chặn, vừa *điểm danh* chúng nó. sau đó thì thằng nào bị điểm danh sẽ bị đưa vào black list, chú ý là mình vẫn giữ nguyên tắc không chặn bừa, chỉ chặn những thằng nào chắc chắn, như đã nói ở trên.

-m

http://tinsang.net

TetCon 2013 http://tetcon.org

Làm an toàn thông tin thì học gì?/hvaonline/posts/list/42133.html

[Discussion] Giám sát an ninh mạng - Bàn về giải pháp chống DDoS	15/12/2009 21:19:12 (+0700) \| #23 \| 200828

mR.Bi
Member

Joined: 22/03/2006 13:17:49
Messages: 812
Offline

@Abe: con số 100 req/s là nhầm lẫn, 200 req/phút thì chính xác hơn. Còn con số 10.000 IP thì nói cho nó chẵn lại, chênh lệch trên hay dưới nó không bao nhiêu cả. Lưu ý cách làm là lấy ra từ NSM những IP gửi lớn hơn 200 req/phút, và chặn chúng nó lại trên firewall. Do đó chọn cái con số này cũng phải tính toán, chọn như 100 req/s thì sẽ không bắt được anh zombie nào, còn chọn thấp quá thì sẽ có nhiều khách hàng chết oan. Việc này tính toán này thường là *trial-and-error*, chọn đại một con số nào đó, rồi thử xem có phù hợp hay không.

Phần màu đỏ khiến em hơi thắc mắc, nếu 200reqs/s là con số chính xác, thì con số 100reqs/s là một sai số (dù lớn) nhưng cũng nằm trong mức độ tóm được và có thể tóm nhầm, sao lại không tóm được anh zombie nào ?
Dù chưa từng đảm trách một hệ thống cỡ bự nào, nhưng đã có lần làm việc với một website chịu tần cống từ khá nhiều IP, mặc dù hệ thống servers chịu tải cho website này là khá lớn và rất chuyên nghiệp nhưng vẫn rụng như thường smilie

. Cách mà em áp dụng lúc đó (nhất thời) : Tính toán số request mà customer thật sự cần thiết tạo ra trong thời gian nhất định, sau đó đặt rule loại trừ. Trong một khoản thời gian đó, một IP request quá con số cho phép, DROP. Nếu IP này tiếp tục thực hiện những request vi phạm rule này trong n lần, dựa theo log, BLOCK. Sau một khoản thời gian nào đó thì UNBLOCK nó.

Thật chất thì cách đó hoàn toàn là nhất thời và không lâu dài, vì dù cho tính toán đến đâu thì vẫn BLOCK nhầm số lượng khách hàng nào đó.
Cách nữa là cho qua tất, cách này thì anh conmale đã có nhắc đến trong kí sự DDOS, bằng cách sử dụng Discard service.

Còn nguyên tắc không chặn bừa mà chặn chắc chắn như mrro thì em chưa có điều kiện, cũng như khả năng để làm. Thật chất là vẫn chưa hình dung được hệ thống "máy học" NSM này hoạt động thế nào mà chặt chẽ như thế.

All of my life I have lived by a code and the code is simple: "honour your parent, love your woman and defend your children"

[Discussion] Giám sát an ninh mạng - Bàn về giải pháp chống DDoS	15/12/2009 22:00:55 (+0700) \| #24 \| 200834

mrro
Administrator

Joined: 27/12/2001 05:07:00
Messages: 745
Offline

@mR.Bi: em coi lại cho kỹ đi em, 200 req/phút chứ không phải 200 req/s smilie

.

-m

http://tinsang.net

TetCon 2013 http://tetcon.org

Làm an toàn thông tin thì học gì?/hvaonline/posts/list/42133.html

[Discussion] Giám sát an ninh mạng - Bàn về giải pháp chống DDoS	15/12/2009 22:09:34 (+0700) \| #25 \| 200835

mR.Bi
Member

Joined: 22/03/2006 13:17:49
Messages: 812
Offline

ha ha, mắt với mũi.
nhưng vẫn thắc mắc sao lại không tóm được zombie nào?

All of my life I have lived by a code and the code is simple: "honour your parent, love your woman and defend your children"

[Discussion] Giám sát an ninh mạng - Bàn về giải pháp chống DDoS	15/12/2009 22:31:52 (+0700) \| #26 \| 200836

mrro
Administrator

Joined: 27/12/2001 05:07:00
Messages: 745
Offline

@mR.Bi: 100 req/s là quá nhiều em ơi. Thông thường mỗi zombie anh thấy bọn nó chỉ gửi khoảng 3-5 req/s, nên nếu em chỉ tìm thằng nào gửi hơn 100 req/s thì em sẽ không thấy thằng nào hêt cả. Lưu ý là cái này là tìm từng thằng.

Hồi trước anh conmale cũng có đề cập đến cái module recent của iptables/netfilter. Về bản chất thì cái phương thức đang làm ở đây cũng giống như cái module recent này, chỉ có điều, như đã nhắc lại nhiều lần, request đi vào mình không cố xử lý nó ngay, mà cứ cho nó vào, rồi mình thống kê offline sau. Nếu kết quả thống kê cho thấy packet/request từ một source IP nhiều hơn 200 req/phút chẳng hạn thì lúc đó mình mới chặn những packet/request mới từ source IP đó lại.

Một khi đã chặn thì chắc chắn nó phải là zombie. Chỉ trừ trường hợp nhiều khách hàng sử dụng chung một IP, thì như đã nói ở trên, mình sẽ chặn zombie bằng các cách khác, chứ không chặn ở tầng network nữa.

-m

PS: mình đã đọc nhiều lần loạt ký sự của anh conmale, nhưng mỗi lần đọc lại vẫn thấy nhiều cái mới. hay quá!

http://tinsang.net

TetCon 2013 http://tetcon.org

Làm an toàn thông tin thì học gì?/hvaonline/posts/list/42133.html

[Discussion] Giám sát an ninh mạng - Bàn về giải pháp chống DDoS	15/12/2009 22:36:34 (+0700) \| #27 \| 200841

myquartz
Member

Joined: 04/01/2005 04:58:30
Messages: 563
Offline

Cách làm của mrro là một ý tưởng mới, mình đánh giá là khá hay, nếu đã thành công sẽ có hiệu quả đáng nể.
Tuy nhiên, hàm lượng chất xám đầu tư cho nó không phải ít, có một số bí quyết hoặc 1 số rào cản phải vượt qua để triển khai được. Ví dụ: bí quyết phân tích lượng dữ liệu log và sensor, measure khổng lồ đó chuyển về, sao cho rút ra 1 kết luận gì đó hoặc có hành động phù hợp. Cái này, có thể phần nhiều dựa trên các lý thuyết về toán học xác suất thống kê, và có thể cần đến 1 cái gọi là Data Warehouse trợ giúp, và như mrro nói, cần cả các "chuyên gia".
Tất nhiên, cost của giải pháp không phải là nhỏ, và chỉ áp dụng cho 1 số customer đủ khả năng đầu tư (có thể vì thế mà mới có 2 khách hàng, chắc rất to).
Dù sao, update cho các bạn biết là có 1 giải pháp thế, biết mà sau cần để mua/thuê. Chứ tự học mà phát triển thì e sẽ ko đuổi kịp đâu. :-D.

[Discussion] Giám sát an ninh mạng - Bàn về giải pháp chống DDoS	15/12/2009 23:25:44 (+0700) \| #28 \| 200845

mrro
Administrator

Joined: 27/12/2001 05:07:00
Messages: 745
Offline

@myquartz: cảm ơn những lời khen ngợi của bạn nhưng mà bọn mình không *hoành tráng* vậy đâu bạn ơi. chủ yếu bọn mình cũng sử dụng công cụ có sẵn, rồi tích hợp chúng lại để làm giải pháp trọn gói mà thôi. cái đóng góp lớn nhất của bọn mình có lẽ chỉ là ở chỗ tách phần phân tích - phân loại packet/request ra làm offline. mà có lẽ người ta cũng đã làm cái này từ lâu rồi mà bọn mình không biết thôi, do mình cũng không có bám sát các nghiên cứu trong lĩnh vực phát hiện và chống DDoS.

mình tin là những gì mình trình bày ở trên cũng là đủ để cho mọi người có thể tìm hiểu và xây dựng một giải pháp tương tự. chỉ cần làm sao trả lời được câu hỏi "ai đang gửi > 200 req/phút trong 15 phút vừa rồi?" một cách nhanh chóng thì coi như đã thành công một nửa rồi.

đương nhiên nếu mà các bạn muốn có giải pháp hay, đã dùng được tốt thì mình rất vui lòng tư vấn. he he he bọn mình không làm miễn phí, chắc chắn là thế rồi :-P.

-m

http://tinsang.net

TetCon 2013 http://tetcon.org

Làm an toàn thông tin thì học gì?/hvaonline/posts/list/42133.html

[Discussion] Giám sát an ninh mạng - Bàn về giải pháp chống DDoS	16/12/2009 00:09:32 (+0700) \| #29 \| 200848

StarGhost
Elite Member

Joined: 29/03/2005 20:34:22
Messages: 662
Location: The Queen
Offline

@mrro: theo mình thì vấn đề không phải là online hay offline gì, mà nên gọi là cách bố trí detection và filtering components. Cách bố trí nối tiếp tức là nhận packet nào thì đối chiếu với statistics luôn xem có hợp lệ hay không. Cách bố trí song song như của mrro thực ra cũng khá là "intuitive". Experiments trong các research về DDoS thì cũng sử dụng mô hình này thôi, ví dụ bừa như http://www.cs.columbia.edu/~smb/papers/pushback-impl.pdf hay http://www.itsec.gov.cn/docs/20090507162132811217.pdf

Sự khác nhau duy nhất là mrro sử dụng "người học", còn họ thì dùng "máy học". smilie

Mind your thought.

[Discussion] Giám sát an ninh mạng - Bàn về giải pháp chống DDoS	16/12/2009 09:16:45 (+0700) \| #30 \| 200870

LeVuHoang
HVA Friend

Joined: 08/03/2003 16:54:07
Messages: 1155
Offline

Sự khác nhau duy nhất là mrro sử dụng "người học", còn họ thì dùng "máy học".

Cũng "máy học" mà StarGhost, nhưng ở mức độ simple chứ chưa có heuristic.

@gamma, mrro: vụ captcha là 1 ví dụ, thay vì đưa ngược IP lại vào iptables để chặn, script tiến hành đưa danh sách IP đó vào .htaccess để hiển thị bảng thông báo yêu cầu nhập user/pass định sẵn thì như thế nào?

Một khi đã chặn thì chắc chắn nó phải là zombie. Chỉ trừ trường hợp nhiều khách hàng sử dụng chung một IP, thì như đã nói ở trên, mình sẽ chặn zombie bằng các cách khác, chứ không chặn ở tầng network nữa.

Nếu mỗi khách hàng 1 IP thì mọi chuyện đơn giản hơn, nên mình đang quan tâm và suy nghĩ về vấn đề chặn ở tầng "khác network" smilie

Go to:

Users currently in here
1 Anonymous