Latest posts for the topic "Giám sát an ninh mạng - Bàn về giải pháp chống DDoS"

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

mrro — GMT

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

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

LeVuHoang — GMT

Đố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.

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

Ky0 — GMT

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 :P

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!

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

hizit91 — GMT

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.

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

Abe — GMT

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 ;-) 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 :x

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

LeVuHoang — GMT

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

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

myquartz — GMT

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?

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

mrro — GMT

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

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

LeVuHoang — GMT

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.

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

lQ — GMT

để 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ẻ ;-). Đã 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 :)?

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

LeVuHoang — GMT

Đà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 :D. 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.

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

gamma95 — GMT

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 :D

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

LeVuHoang — GMT

Đâ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

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

gamma95 — GMT

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

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

Abe — GMT

@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 :D)

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

myquartz — GMT

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.

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

LeVuHoang — GMT

@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.

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

lQ — GMT

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' ;-) 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 :D.

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

myquartz — GMT

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 đó.

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

LeVuHoang — GMT

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.

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

gamma95 — GMT

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.

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

mrro — GMT

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 ;-). 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

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

mR.Bi — GMT

@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 :^) . 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ế.

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

mrro — GMT

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

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

mR.Bi — GMT

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?

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

mrro — GMT

@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á!

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

myquartz — GMT

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.

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

mrro — GMT

@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

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

StarGhost — GMT

@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". :P

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

LeVuHoang — GMT

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" :D

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

mrro — GMT

@StarGhost: mình thấy gọi là bố trí song song với nối tiếp cũng không chính xác. ví dụ như Snort với active response chẳng hạn, người ta vẫn làm nó theo dạng song song, nghĩa là một copy của packet/request sẽ được đưa vào Snort, rồi Snort cứ tùy ý phân tích, nếu mà nó thấy packet trùng với signature thì nó sẽ hủy bỏ cái connection bằng cách gửi RST đến cả hai đầu. cách làm này anh conmale cũng có đề cập đến trong loạt bài ký sự. hồi trước nhớ có lần anh prof trình bày về PacketScore, là một hướng nghiên cứu, theo anh prof, nhiều hứa hẹn trong lĩnh vực chống DDoS. Cơ bản thì PacketScore khá giống các hình thức chống spam theo mô hình Bayesian, khi mà mỗi packet đi vào, PacketScore sẽ tính toán xác suất xem packet đó có phải là một phần của đợt tấn công hay không, và nếu xác suất đó cao hơn một cái dynamic threshold (phụ thuộc vào độ tải của hệ thống ở thời điểm đó) thì packet sẽ bị drop. mình thấy cái khác biệt của mình là mỗi khi có packet đi vào, mình không cố gắng phân loại chúng ngay, mà cứ để yên đó, rồi sẽ phân tích và phân loại tất cả một lượt sau mỗi khoảng thời gian nhất định. cách thức phân tích và phân loại có thể sẽ giống nhau, nhưng mình sẽ có lợi thế về thời gian, khả năng tính toán mạnh và khả năng can thiệp của con người do quá trình phân tích này không nằm trong quá trình xử lý packet của toàn hệ thống. điểm yếu của cách làm này, như mình đã có nói, là nó chỉ giải quyết được một số loại tấn công DDoS mà thôi. nó có thể sẽ không có tác dụng với các loại tấn công mà source IP bị giả mạo như TCP SYN flood hay là UDP flood. lý do đơn giản vì, khác với PacketScore hay các scheme tương tự, mình không drop packet theo thời gian thực, mà chỉ phân tích rồi lấy ra danh sách IP nghi ngờ, và block chúng nó lại. @LeVuHoang: lo ngại của Hoàng là có thể hiểu được, nhưng mà thực tế thì số lượng connection như Hoàng mô tả không quá nhiều để mình phải bận tâm. --- đọc loạt bài của anh conmale, rồi kinh nghiệm của mình cho thấy là khó có một silver bullet trong việc chống DDoS. nên việc kết hợp nhiều công cụ và giải pháp khác nhau là gần như bắt buộc. dẫu vậy, trong phạm vi topic này, mình chỉ muốn bàn về việc chống các dạng DDoS mà ở đó zombie không giả mạo source IP. -m

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

hankun — GMT

mrro wrote:

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!

Có ai hiểu anh mrro muốn nói tới ứng dụng nào và cách giải quyết ra sao thì chỉ giúp em với ạ .

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

quanta — GMT

mrro wrote:

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.

Giả sử log của Apache thế này: 127.0.0.1 - anonymous [25/Nov/2010:21:58:36 +0700] "GET / HTTP/1.0" 200 11 "-" "check_http/v1.4.15 (nagios-plugins 1.4.15)" Có bạn nào hứng thú giải quyết câu hỏi trên bằng shell script không nhỉ?

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

xnohat — GMT

quanta wrote:

mrro wrote:

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.
Giả sử log của Apache thế này: 127.0.0.1 - anonymous [25/Nov/2010:21:58:36 +0700] "GET / HTTP/1.0" 200 11 "-" "check_http/v1.4.15 (nagios-plugins 1.4.15)" Có bạn nào hứng thú giải quyết câu hỏi trên bằng shell script không nhỉ?

hà hà một câu đố rất thú vị B-) thiết nghĩ rất có ích giúp anh em dễ phân tích và chọn ra thằng đáng bị "trảm" Câu đố này có 2 hướng giải :D tớ đưa ra hướng giải đơn giản nhất ( cần con người nhất thay vì tự động ) Code:

wc path/to/access.log | awk '{print $1}'

output có thể là Code:

18681    ( đây là số dòng trong access.log tương ứng với số request apache đã nhận từ lúc cài đặt tới nay )

sau "một phút" chạy lại lệnh trên Code:

19681    ( đây là số dòng trong access.log sau 1 phút )

trừ 2 thằng ta có được số request nhận được trong 1 phút vừa qua Code:

19681 - 18681 = 1000       ( ví dụ thôi nhá  :-)  )

chạy lệnh sau

tail 'path/to/access.log' -n 1000 | awk '{print $1}' | sort | uniq -c | sort -n | tail -n 1

lệnh tail sẽ lấy từ access.log 1000 dòng "cuối cùng trong file" (là con số ta trừ ở trên ) , truyền qua cho awk để chỉ lọc ra phần IP trong cái đống đó, gom chúng lại bằng lệnh short rồi uniq -c sẽ đếm số lần xuất hiện của từng IP ( các dòng giống nhau sẽ cộng lại ) , chuyền qua cho sort -n để sắp từ nhỏ đến lớn ( lớn nhất cuối cùng ) và sau cùng là tail -n 1 là sẽ lấy 01 dòng cuối trong cái sort -n ở trên ( tức là cái IP truy cập nhiều nhất trong 1 phút qua ) output: Code:

268 67.195.113.243

268 là số lần request chạm server được ghi nhận trong access.log , đằng sau là cái IP gửi request :D xNohat

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

quanta — GMT

Cơ bản là thế. Anh có thể thay `sort -n | tail -n 1` bằng `sort -rn`. Mà cũng chỉ cần tail -1, tail -1000 thôi, không cần -n. Anh có cách nào lấy luôn từ thời điểm hiện tại quay về 1 phút trước (thay vì 1 phút sau chạy lại để trừ đi số dòng) không? Tiếp theo là dùng một dòng lệnh mà ra được kết quả trên thì tốt.

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

louisnguyen27 — GMT

Bữa giờ bị DDoS dữ quá nên hôm nay mới chui vô đọc bài của anh mrro. Em bổ sung thêm một chút về vụ ISO27K, ITIL như thế này:

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?

Về bản chất việc xây dựng 27K hay ITIL đều nhằm mục đích collect data của một hệ thống, tuy nhiên việc xử lý cái gói data đó có thực sự được thực hiện hay không là một chuyện khác. Nếu việc xử lý các raw data đó được thực hiện triệt để thì việc phòng chống DDoS là hoàn toàn kiểm soát được. Mà phần này thì phụ thuộc vào nhận thức của lãnh đạo. Khi anh set up cái hệ thống giám sát thì chính là xây dựng một cái control trong 27K và không đơn giản mà PCI DSS nó tách hẳn ra làm hai phần chính là Assessor và Scanning Vendor. Quan điểm cá nhân em là anh chỉ mới tập trung vào khía cạnh của Scanning Vendor.

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

xnohat — GMT

quanta wrote:

Cơ bản là thế. Anh có thể thay `sort -n | tail -n 1` bằng `sort -rn`. Mà cũng chỉ cần tail -1, tail -1000 thôi, không cần -n. Anh có cách nào lấy luôn từ thời điểm hiện tại quay về 1 phút trước (thay vì 1 phút sau chạy lại để trừ đi số dòng) không? Tiếp theo là dùng một dòng lệnh mà ra được kết quả trên thì tốt.

à há thanks em mấy chỗ bổ sung nhiều lắm :D Cách giải quyết thì đã có rốt ráo rồi nhưng phải để các anh em khác cùng tham gia nữa cho xôm xụ chứ :D câu đố của em là câu đố rất hay mà :D

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

1mp0ss1bl3 — GMT

quanta wrote:

Cơ bản là thế. Anh có thể thay `sort -n | tail -n 1` bằng `sort -rn`. Mà cũng chỉ cần tail -1, tail -1000 thôi, không cần -n. Anh có cách nào lấy luôn từ thời điểm hiện tại quay về 1 phút trước (thay vì 1 phút sau chạy lại để trừ đi số dòng) không? Tiếp theo là dùng một dòng lệnh mà ra được kết quả trên thì tốt.

Mình có 1 lệnh mà hơi dài :P pre_min=`date -d '1 minutes ago' +%d/%b/%Y:%H:%M`; grep -n -m 1 $pre_min /usr/local/apache2/logs/access_log | cut -d":" -f1 | xargs -iline_num tail -n +line_num /usr/local/apache2/logs/access_log | awk '{print $1}' | uniq -c | sort -nr Lệnh này làm việc như sau: - Đầu tiên sẽ gán giá trị thời gian 1 phút trước với định dạng thời gian giống như trong access_log vào biến pre_min. - Sau đó tìm trong access_log dòng đầu tiên match với thời gian trên và xuất ra thứ tự của dòng đó trong access_log. - Kế tiếp sẽ liệt kê tất cả các dòng trong access_log kể từ dòng đã được tìm ra ở bước trên. - Phần còn lại chỉ là đếm và sort. Mọi người thấy sao? :|

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

quanta — GMT

Mình có vài ý kiến: - Bạn bỏ %S trong lệnh date đi là có ý đồ, tuy nhiên xét ở mức nào đó thì chưa chính xác lắm nhỉ. Có lẽ tại thời điểm chạy lệnh, ta nên lấy mốc thời gian là dòng cuối cùng của access_log. - Bạn giải thích thêm về xargs -iline_num tail -n +line_num cho mọi người rõ hơn nhé.

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

1mp0ss1bl3 — GMT

quanta wrote:

Mình có vài ý kiến: - Bạn bỏ %S trong lệnh date đi là có ý đồ, tuy nhiên xét ở mức nào đó thì chưa chính xác lắm nhỉ. Có lẽ tại thời điểm chạy lệnh, ta nên lấy mốc thời gian là dòng cuối cùng của access_log. - Bạn giải thích thêm về xargs -iline_num tail -n +line_num cho mọi người rõ hơn nhé.

Hi quanta, - Chính xác như bạn thấy, mình bỏ %S đi là có ý đồ :D, mình chỉ cần match tới phút chứ không cần tới giây - Câu lệnh trên mình nghĩ là chính xác cho trường hợp "Liệt kê từ access_log tần suất xuất hiện của 1 IP trong khoảng thời gian từ 1 phút trước cho đến thời điểm thực thi câu lệnh". - xargs -iline_num tail -n +line_num có thể hiểu thế này: Tham số của câu lệnh "tail -n +line_num" nếu match với khai báo sau option -i (hoặc -I) của xargs sẽ được thay thế bằng output của câu lệnh trước đó (input của lệnh xargs). Nó gần giống việc gán giá trị vào biến. - Lệnh trên có thể được thay thế bằng xargs -I line_num tail -n +line_num

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

quanta — GMT

1mp0ss1bl3 wrote:

Hi quanta, - Chính xác như bạn thấy, mình bỏ %S đi là có ý đồ :D, mình chỉ cần match tới phút chứ không cần tới giây - Câu lệnh trên mình nghĩ là chính xác cho trường hợp "Liệt kê từ access_log tần suất xuất hiện của 1 IP trong khoảng thời gian từ 1 phút trước cho đến thời điểm thực thi câu lệnh".

Sẽ xảy ra trường hợp bây giờ là 12:57:59 và bạn lấy log từ 12:56:03. Chia sẻ cùng mọi người cách của mình: last_time=`tail -1 access_log | awk '{ print substr($4, 2, length($4)-1) }'`; standard_last_time=`echo $last_time | sed 's/\//-/g' | awk -F":" '{ print $1" "$2":"$3":"$4 }'`; pre_min=`date -d "$standard_last_time 1 minutes ago" +%d/%b/%Y:%k:%M:%S`; awk '$4 <= to && $4 >= from { print $1 }' from="[$pre_min" to="[$last_time" access_log | sort | uniq -c | sort -rn | awk '$1 >=200 { print $0 }'

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

1mp0ss1bl3 — GMT

Hì Hì :D Chôm của quanta 1 chút mình được lệnh sau: pre_min=`date -d '1 minutes ago' +%d/%b/%Y:%H:%M`; grep -n -m 1 $pre_min access_log | cut -d":" -f1 | xargs -iline_num tail -n +line_num access_log | awk ' $4 <= to && $4 >= from { print $1 }' from="[$pre_min:00" to="[$pre_min:59" | sort | uniq -c | sort -rn Lệnh này sẽ liệt kê số lần xuất hiện của 1 IP trong access_log chính xác trong khoảng thời gian 1 phút trước. Có thể linh hoạt thêm 1 chút nếu khai báo thêm 1 biến cur_min. Ví dụ lệnh sau sẽ liệt kê số lấn xuất hiện của 1 IP trong access_log trong 10 phút trước pre_min=`date -d '11 minutes ago' +%d/%b/%Y:%H:%M`; cur_min=`date -d '1 minutes ago' +%d/%b/%Y:%H:%M`; grep -n -m 1 $pre_min access_log | cut -d":" -f1 | xargs -iline_num tail -n +line_num access_log | awk ' $4 <= to && $4 >= from { print $1 }' from="[$pre_min:00" to="[$cur_min:59" | sort | uniq -c | sort -nr quanta thấy sao? PS: Cá nhân mình cảm thấy cách này nhanh hơn cách quanta 1 chút

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

mrro — GMT

he he he hay ;-). anyway, mình phải hỏi là, nó có đủ nhanh khi lượng dữ liệu lớn lên, chẳng hạn như vài chục hay vài trăm G? -m

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

1mp0ss1bl3 — GMT

mrro wrote:

he he he hay ;-). anyway, mình phải hỏi là, nó có đủ nhanh khi lượng dữ liệu lớn lên, chẳng hạn như vài chục hay vài trăm G? -m

Hi mrro, Nếu lệnh này grep -n -m 1 $pre_min access_log đủ nhanh (cái này chưa có điều kiện test :P) thì toàn bộ câu lệnh sẽ vẫn nhanh cho dù log file rất lớn. Vì sau câu lệnh trên mình chỉ tail 1 phần của log file. Thân

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

mrro — GMT

@1imp0ss1bl3: vấn đề là ở chỗ đó. grep có đủ nhanh hay không? mình nhấn mạnh đủ nhanh vì có thể grep chậm hơn các giải pháp khác (như splunk hay lucene-solr), nhưng vẫn đáp ứng được yêu cầu. sở dĩ splunk hay lucene-solr nhanh là vì chúng nó đã index dữ liệu trước rồi. hiểu nôm na là chúng nó đã chuẩn bị dữ liệu cho công việc tìm kiếm, nên khi bắt đầu tìm thì sẽ nhanh hơn. còn grep thì vẫn để dữ liệu dạng thô, do đó thời gian tìm kiếm sẽ lâu hơn. đương nhiên nhanh hơn hay chậm hơn bao nhiêu thì phải kiểm thử mới biết. -m

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

quanta — GMT

mrro wrote:

he he he hay ;-). anyway, mình phải hỏi là, nó có đủ nhanh khi lượng dữ liệu lớn lên, chẳng hạn như vài chục hay vài trăm G? -m

Rất tiếc, mình không có Splunk ở đây để test, bạn nào có Splunk bên cạnh thì thử rồi cho mọi người biết kết quả được không. Hơn nữa, làm gì mà để log file lớn vậy mrro, không rotate à. Mình cũng chỉ muốn thảo luận thêm về một giải pháp đơn giản, dùng shell script rồi có thể đẩy vào cron job hoặc Nagios thôi. PS: mrro dùng Splunk có bị tình trạng ngốn cpu không?

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

xnohat — GMT

mrro wrote:

he he he hay ;-). anyway, mình phải hỏi là, nó có đủ nhanh khi lượng dữ liệu lớn lên, chẳng hạn như vài chục hay vài trăm G? -m

he he câu hỏi của lão mrro làm tớ lóe lên 1 vấn đề :D Nếu tớ chuyển các Log vào trong một hệ quản trị CSDL như MySQL chẳng hạn thì việc index, truy lục ( bằng SQL Query ) sẽ cực nhanh, cực tối ưu và việc maintain cái đống log sao cho tối ưu nhất đã có thằng DBMS nó lo cho :D Search google phát được ku này: http://logtomysql.sourceforge.net/install.html

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

quanta — GMT

xnohat wrote:

he he câu hỏi của lão mrro làm tớ lóe lên 1 vấn đề :D Nếu tớ chuyển các Log vào trong một hệ quản trị CSDL như MySQL chẳng hạn thì việc index, truy lục ( bằng SQL Query ) sẽ cực nhanh, cực tối ưu và việc maintain cái đống log sao cho tối ưu nhất đã có thằng DBMS nó lo cho :D Search google phát được ku này: http://logtomysql.sourceforge.net/install.html

/hvaonline/posts/list/0/14855.html#163334

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

xnohat — GMT

quanta wrote:

xnohat wrote:

he he câu hỏi của lão mrro làm tớ lóe lên 1 vấn đề :D Nếu tớ chuyển các Log vào trong một hệ quản trị CSDL như MySQL chẳng hạn thì việc index, truy lục ( bằng SQL Query ) sẽ cực nhanh, cực tối ưu và việc maintain cái đống log sao cho tối ưu nhất đã có thằng DBMS nó lo cho :D Search google phát được ku này: http://logtomysql.sourceforge.net/install.html
/hvaonline/posts/list/0/14855.html#163334

ây da :D 2 năm trước nó đã được thảo luận rồi sao :D Theo ý kiến của tớ ( riêng tớ ) việc 1 log ko có schema , không cấu trúc là vì ta INSERT nó vào DBMS không có cấu trúc, việc chỉnh sửa đôi chút trong source của công cụ ghi log vào DBMS là chuyện dễ dàng ( công cụ opensource ) , mỗi dòng log có cấu trúc riêng của nó, việc phân tách các thành phần thông tin của một dòng log thành các fields rồi INSERT nó vào Database cũng không khó , một khi đã phân tách thành các fields thì tính RELATIONSHIP trong DBMS hoàn toàn có thể xây dựng dựa trên mối quan hệ logic giữa các fields. Ta cũng có thể kết hợp nhiều log của nhiều hệ thống logging khác nhau thông qua các RELATIONSHIP giữa chúng, giúp ta nhanh chóng có cái nhìn toàn cảnh từ một loạt các log khác nhau DBMS được thiết kế tối ưu cho công tác Storing , Indexing , Quering , liệu có thứ hiệu quả hơn một DBMS cho công tác này ? Việc chúng ra thực hiện grep , tail ... ở trên trong DBMS có thể giải quyết trực tiếp trên câu lệnh query thậm chí có thể analyzing dữ liệu on-the-fly của quá trình truy lục - xNohat -

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

vikjava — GMT

Hi all ! Cho mình hỏi ngoài splunk hay lucene-solr thì có những sản phẩm nào tương tự ? Bao gồm phần mềm thương mại và cả mã nguồn mở

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

quanta — GMT

vikjava wrote:

Hi all ! Cho mình hỏi ngoài splunk hay lucene-solr thì có những sản phẩm nào tương tự ? Bao gồm phần mềm thương mại và cả mã nguồn mở

http://serverfault.com/questions/62687/alternatives-to-splunk http://stackoverflow.com/questions/183977/what-commercial-and-open-source-competitors-are-there-to-splunk

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

mrro — GMT

quanta wrote:

Rất tiếc, mình không có Splunk ở đây để test, bạn nào có Splunk bên cạnh thì thử rồi cho mọi người biết kết quả được không. Hơn nữa, làm gì mà để log file lớn vậy mrro, không rotate à. Mình cũng chỉ muốn thảo luận thêm về một giải pháp đơn giản, dùng shell script rồi có thể đẩy vào cron job hoặc Nagios thôi. PS: mrro dùng Splunk có bị tình trạng ngốn cpu không?

1 --> không phải là log file lớn, mà lượng dữ liệu nhận được trong X phút (ở đây là 15') là lớn. 2 --> cái này thì mình không biết. có lẽ là không. @vikjava: còn khá nhiều, từ khoá nè: arcsight, cloudera flume, apache scribe, elasticsearch. dịch vụ thì có www.loggly.com. dẫu vậy ngoại trừ splunk (và có lẽ là arcsight) ra thì những cái này đều khá rời rạc, muốn ra một sản phẩm hay giải pháp thì cần phải tích hợp. có nhu cầu thiệt sự thì liên hệ, mình có thể tích hợp mấy cái này lại ;-). -m

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

quanta — GMT

mrro wrote:

quanta wrote:

Hơn nữa, làm gì mà để log file lớn vậy mrro, không rotate à.
không phải là log file lớn, mà lượng dữ liệu nhận được trong X phút (ở đây là 15') là lớn.

15' mà lên đến mấy chục GB thì mình chưa gặp.

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

conmale — GMT

quanta wrote:

mrro wrote:

quanta wrote:

Hơn nữa, làm gì mà để log file lớn vậy mrro, không rotate à.
không phải là log file lớn, mà lượng dữ liệu nhận được trong X phút (ở đây là 15') là lớn.
15' mà lên đến mấy chục GB thì mình chưa gặp.

Có đó em. HVA lúc trước bị DDoS, 15 phút log lên mấy chục Gb, làm hết disk space nên bị khùng luôn :).

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

mrro — GMT

@quanta: ờ thì có thể do bạn chưa bị DDoS, khi đó 10G/s là chuyện bình thường. ở đây đang nói đến tình huống là làm sao tìm kiếm nhanh chóng trên một khối lượng dữ liệu lớn mà. @xnohat: tự dưng lỡ bài của bạn. RDBMS đúng là được thiết kế để làm nhiều thứ, thành ra cái gì cũng làm được, nhưng không thể tốt bằng những giải pháp được thiết kế chỉ để làm một việc duy nhất. lucene được thiết kế chỉ để làm một việc: tìm kiếm dữ liệu (nó cũng có lưu trữ dữ liệu, nhưng đó cũng chỉ là phụ và khâu này có thể dùng một DBMS, nhưng không nhất thiết phải là RDBMS). bạn thử tìm với từ khoá "lucene vs mysql fulltext search" sẽ thấy benchmark và kinh nghiệm của những người đã từng sử dụng lucene và mysql để tìm kiếm. bây giờ thử nhìn một vấn đề đơn giản, trích xuất field từ dữ liệu log. đúng như bạn nói, cái này không phải là không làm được với RDBMS, vấn đề là làm thế nào cho nó hiệu quả. ví dụ như log của firewall khác với log của apache httpd, nghĩa là số lượng field, ý nghĩa của các field của tụi nó sẽ khác nhau rất xa. lúc này bạn thiết kế mô hình quan hệ ra sao? sau khi thiết kế được rồi, đưa vào sử dụng, bạn phát hiện ra, hệ thống không chỉ có 2 loại log, mà có cả trăm loại log khác nhau như thế. thế là phải ngồi thiết kế lại. tìm kiếm và trích xuất thông tin (information retrieval) là một ngành học độc lập hoàn toàn với cơ sở dữ liệu, và đặc biệt là cơ sở dữ liệu quan hệ. -m

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

lQ — GMT

vikjava wrote:

Hi all ! Cho mình hỏi ngoài splunk hay lucene-solr thì có những sản phẩm nào tương tự ? Bao gồm phần mềm thương mại và cả mã nguồn mở

Anh cũng thử tìm giải pháp mã mở thay thế, ngoài licene-solr mà mrro đề cập thì anh thấy có OSSIM và php-syslog-ng. OSSIM thì anh chưa thử nhưng thấy cũng có người đang dùng. php-syslog-ng thì khá yếu, chỉ để search log mà thôi, ko đủ tính năng để thay thế Splunk. Về các bản thương mai thì anh thấy có ArcSight, LogLogic, RSA enVision, Sawmill... cùng 1 số bản thương mại khác cũng có bản giới hạn miễn phí. Nhưng nếu dữ liệu < 500 MB thì có lẽ dùng Splunk Free Version cho khoẻ.

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

IamN — GMT

Mình thấy captcha và cookie cũng là một ý hay. Nhưng cho mình hỏi có cách nào để giảm tải cho hệ thống khi dùng cookie ko? hoặc có thể chuyển việc xử lý cookie sang một host phụ,sau đo report về cho sv chính chủ để tiến hành các thao tác ko?

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

hnaod — GMT

Anh em chỉ giáo giúp, tình hình là Server của em bị DOS đã 4 ngày từ một địa chỉ 157.55.193.180 trung bình khoảng 150 request/s. Em đã block IP trong .htacess và chặn bằng chức năng firewall filter của Router (DrayTek Vigor 2950). Vì chặn ngay Router nên Server vẫn hoạt động tốt. Truy cập vào trang web địa chỉ 157.55.193.180 thì hiện lên trang web bình thường. Tuy giờ Server vẫn hoạt động nhưng rất khó chịu vẫn bị DOS đều đều. Mong anh em có nhiều kinh nghiệm chỉ giáo giúp (Cho biết thêm thông tin liên quan với địa chỉ này, cách đối phó tiếp theo). Thanks all ! PS. Tất cả log về IP này đều dạng như sau: 157.55.193.180 - - [27/Apr/2011:09:20:40 +0700] "GET /tnb_sv/ HTTP/1.1" 403 209 157.55.193.180 - - [27/Apr/2011:09:20:40 +0700] "GET /tnb_sv/ HTTP/1.1" 403 209 157.55.193.180 - - [27/Apr/2011:09:20:40 +0700] "GET /tnb_sv/ HTTP/1.1" 403 209 157.55.193.180 - - [27/Apr/2011:09:20:40 +0700] "GET /tnb_sv/ HTTP/1.1" 403 209 157.55.193.180 - - [27/Apr/2011:09:20:40 +0700] "GET /tnb_sv/ HTTP/1.1" 403 209 157.55.193.180 - - [27/Apr/2011:09:20:40 +0700] "GET /tnb_sv/ HTTP/1.1" 403 209 157.55.193.180 - - [27/Apr/2011:09:20:40 +0700] "GET /tnb_sv/ HTTP/1.1" 403 209 157.55.193.180 - - [27/Apr/2011:09:20:40 +0700] "GET /tnb_sv/ HTTP/1.1" 403 209 157.55.193.180 - - [27/Apr/2011:09:20:40 +0700] "GET /tnb_sv/ HTTP/1.1" 403 209 157.55.193.180 - - [27/Apr/2011:09:20:40 +0700] "GET /tnb_sv/ HTTP/1.1" 403 209 157.55.193.180 - - [27/Apr/2011:09:20:40 +0700] "GET /tnb_sv/ HTTP/1.1" 403 209 157.55.193.180 - - [27/Apr/2011:09:20:40 +0700] "GET /tnb_sv/ HTTP/1.1" 403 209 157.55.193.180 - - [27/Apr/2011:09:20:40 +0700] "GET /tnb_sv/ HTTP/1.1" 403 209 157.55.193.180 - - [27/Apr/2011:09:20:40 +0700] "GET /tnb_sv/ HTTP/1.1" 403 209 157.55.193.180 - - [27/Apr/2011:09:20:40 +0700] "GET /tnb_sv/ HTTP/1.1" 403 209 157.55.193.180 - - [27/Apr/2011:09:20:40 +0700] "GET /tnb_sv/ HTTP/1.1" 403 209 157.55.193.180 - - [27/Apr/2011:09:20:40 +0700] "GET /tnb_sv/ HTTP/1.1" 403 209 157.55.193.180 - - [27/Apr/2011:09:20:40 +0700] "GET /tnb_sv/ HTTP/1.1" 403 209 157.55.193.180 - - [27/Apr/2011:09:20:40 +0700] "GET /tnb_sv/ HTTP/1.1" 403 209 157.55.193.180 - - [27/Apr/2011:09:20:40 +0700] "GET /tnb_sv/ HTTP/1.1" 403 209 157.55.193.180 - - [27/Apr/2011:09:20:40 +0700] "GET /tnb_sv/ HTTP/1.1" 403 209 157.55.193.180 - - [27/Apr/2011:09:20:40 +0700] "GET /tnb_sv/ HTTP/1.1" 403 209 157.55.193.180 - - [27/Apr/2011:09:20:40 +0700] "GET /tnb_sv/ HTTP/1.1" 403 209 157.55.193.180 - - [27/Apr/2011:09:20:40 +0700] "GET /tnb_sv/ HTTP/1.1" 403 209

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

quanta — GMT

lQ wrote:

vikjava wrote:

Hi all ! Cho mình hỏi ngoài splunk hay lucene-solr thì có những sản phẩm nào tương tự ? Bao gồm phần mềm thương mại và cả mã nguồn mở
Anh cũng thử tìm giải pháp mã mở thay thế, ngoài licene-solr mà mrro đề cập thì anh thấy có OSSIM và php-syslog-ng. OSSIM thì anh chưa thử nhưng thấy cũng có người đang dùng. php-syslog-ng thì khá yếu, chỉ để search log mà thôi, ko đủ tính năng để thay thế Splunk. Về các bản thương mai thì anh thấy có ArcSight, LogLogic, RSA enVision, Sawmill... cùng 1 số bản thương mại khác cũng có bản giới hạn miễn phí. Nhưng nếu dữ liệu < 500 MB thì có lẽ dùng Splunk Free Version cho khoẻ.

Nổi bật trong làng open source thì mình thấy có Octopussy và logstash. Đọc thêm: http://serverfault.com/questions/239401/splunk-is-fantastically-expensive-what-are-the-alternatives http://serverfault.com/questions/62687/alternatives-to-splunk vikjava có thử thì làm bài review cho mọi người biết nhé.

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

secmask — GMT

Mình giới thiệu thêm cái Infobright.org, có thể sẽ áp dụng được, Infobright được tối ưu để lưu trữ và truy vấn(Dataware house).

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

quybeo83 — GMT

bên em mới mượn được con Arbor chống ddos khá hiệu quả mỗi tội giá của nó mắc quá cỡ vài chục nghan là bé nhất. Tiện thể xin hỏi mọi người luôn cách chặn TCP SYN bởi vì bên mình mấy hôm nay bị ddos không sập nên bọn nó chuyển hướng sang TCP SYN. Mới nghiên cứu bảo mật thời gian ngắn nên mong mọi người giúp đỡ.

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

anti-ddos — GMT

Hi, 1.Về Giao thức TCP: * Trong hoạt động truyền dữ liệu của bộ giao thức TCP/IP, TCP sẽ đảm nhiệm tính chất có kết nối và truyền không lỗi. * Để làm được điều này (có kết nối và truyền không lỗi) hoạt động của TCP chia làm 3 bước: @ Thiết lập kết nối Để thiết lập một kết nối, TCP sử dụng một quy trình bắt tay 3 bước (3-way handshake) Trước khi client thử kết nối với một server, server phải đăng ký một cổng và mở cổng đó cho các kết nối: đây được gọi là mở bị động. Một khi mở bị động đã được thiết lập thì một client có thể bắt đầu mở chủ động. Để thiết lập một kết nối, quy trình bắt tay 3 bước xảy ra như sau: > Client yêu cầu mở cổng dịch vụ bằng cách gửi gói tin SYN (gói tin TCP) tới server, trong gói tin này, tham số sequence number được gán cho một giá trị ngẫu nhiên X. > Server hồi đáp bằng cách gửi lại phía client bản tin SYN-ACK, trong gói tin này, tham số acknowledgment number được gán giá trị bằng X + 1, tham số sequence number được gán ngẫu nhiên một giá trị Y > Để hoàn tất quá trình bắt tay ba bước, client tiếp tục gửi tới server bản tin ACK, trong bản tin này, tham số sequence number được gán cho giá trị bằng X + 1 còn tham số acknowledgment number được gán giá trị bằng Y + 1. Tại thời điểm này, cả client và server đều được xác nhận rằng, một kết nối đã được thiết lập. @ Truyền dữ liệu: Đảm bảo truyền: > Truyền dữ liệu không lỗi (do có cơ chế sửa lỗi/truyền lại) > Truyền các gói dữ liệu theo đúng thứ tự > Truyền lại các gói dữ liệu mất trên đường truyền > Loại bỏ các gói dữ liệu trùng lặp > Cơ chế hạn chế tắc nghẽn đường truyền @ Kết thúc kết nối Để kết thúc kết nối hai bên sử dụng quá trình bắt tay 4 bước và chiều của kết nối kết thúc độc lập với nhau. Khi một bên muốn kết thúc, nó gửi đi một gói tin FIN và bên kia gửi lại tin báo nhận ACK. Vì vậy, một quá trình kết thúc tiêu biểu sẽ có 2 cặp gói tin trao đổi. Một kết nối có thể tồn tại ở dạng : một bên đã kết thúc gửi dữ liệu nên chỉ nhận thông tin, bên kia vẫn tiếp tục gửi. 2.Tấn công tấn công theo TCP SYN, SYN-ACK (hay còn gọi là tấn công ngập lụt SYN, SYN-ACK): > Bây giờ giả sử có N x Client gửi gói tin SYN tới Server. > Vì cơ chế hoạt động của TCP nên Server sẽ trả lời với N gói SYN-ACK. > Sau đó Server sẽ chờ N gói ACK xác nhận từ N x Client . > Do chủ đích tấn công nên Nx Client này không trả lời ACK hoặc IP không tồn tại dẫn đến Server rơi vào trạng thái chờ đợi. > Và NxClient lại tiếp tục gửi các N gói tin SYN tới Server, Server lại gửi lại N gói SYN-ACK và chờ, đến một lúc toàn bộ tài nguyên của Server sẽ phải sử dụng để nhận SYN, gửi SYN-ACK, chờ --> dẫn đến cạn kiệt --> treo máy. 3. Phòng chống tấn công TCP SYN, SYN-ACK cho Sever - Phải có cơ chế xác thực sự bất thường trong kết nối TCP SYN, SYN-ACK giữa Client với Server. - Một hệ thống ngăn chặn tấn công TCP SYN tốt có các cơ chế xác thực sau: > TCP SYN Authentication with reset to Sever. > TCP SYN Authentication with refresh sent to Sever. > TCP SYN Authentication with Aplication(http, ftp…) Authentication. > TCP SYN Authentication with safe reset to Sever. > TCP SYN ACK Authentication > Hệ thống phải đảm bảo các thông số cho các xác thực này có thể tự điều chỉnh hoặc tự động. - Còn thuật toán để đưa ra các xác thực này thì tùy hệ thống sẽ khác nhau, nhưng cơ bản sẽ dựa vào: * Thời gian trạng thái của socket: LISTEN, SYN-SENT, SYN-RECEIVED, ESTABLISHED, TIME-WAIT... * Dựa vào thông số sequencing. * Dựa vào baseline kết nối TCP giữa Client và Server. * …. và nhiều thứ khác nữa, mình đang tìm hiểu, sẽ share lên tiếp.... Thân.

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

Tony_nguyen19 — GMT

bạn test thử con Arbor của bạn xong đi nếu mà ko OK thì chuyển wa dùng con Defense Pro của Radware, mình thấy nó cũng OK lắm. mấy cái TCP SYN .... block ngon lành cành đào

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

anti-ddos — GMT

Nói thêm về Anti-DDOS: Cơ bản nhất của các loại tấn công DDOS là làm cạn kiệt tài nguyên: - Băng thông mạng. - Năng lực xử lý của thiết bị. Nếu chỉ bàn bề vấn đề kỹ thuật, thì hệ thống chống DDOS, tốt nhất: - Chuyên dụng: Vì các thiết bị IPS, Firewall phải dành tài nguyên để tối ưu bảo mật cho rất nhiều hoạt động. - Hệ thống phải có khả năng chặn được các cuộc tấn công phân tán, state-exhausting. - Trong môi trường Cloud đang phát triển hiện nay thì hệ thống này cũng phải làm được. - Hệ thống phải có cơ chế thông báo tự động hoặc thủ công cho các ISP, Tổ chức trên toàn thế giới kiểm tra các IP, Source bất thường (tấn công DoS, hoặc có khả năng tham gia tấn công DoS).

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

quybeo83 — GMT

đa phần nếu bị DDos thì vấn đề sập mạng chỉ là thời gian nếu không có một hệ thống phân tích log tốt và có 1 người quản trị có kinh nghiệm. ở nước mình thì băng thông internet là vấn đề lớn đối với các công ty bởi vấn đề kinh phí bởi vậy nếu không có 1 thiết bị chuyên dụng để lọc và ngăn chặn thì nhiều nhất là vài tiếng thì full đường truyền. đã đến lúc các nhà cung cấp dịch vụ internet cần có các thiết bị lọc từ trên để bảo vệ người dùng về các vấn đề tương tự như DDos. có lẽ phải đến khi nào một nhà cung cấp dịch vụ bị tấn công ddos thì lúc đấy vấn đề mới được giải quyết.

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

soi_hoang84 — GMT

Hic , Bác nào Rành về DDos Giúp em vụ này với ! Site bên em Bị DDos mấy ngày hôm nay. mà không có cách nào chặn được Cũng chẳng biêt xuất phát từ đâu để. Mà mình làm gì sai để ngừoi ta đánh nữa. Hic. t Bác nào có giải pháp gì giúp em không , Em chỉ có lưu được mỗi log của host thôi , Site: http://cuumaytinh.com .( em vừa chuyển sang server khác nhưng không biết cầm cự đến bao giờ nữa) Thanks các bác

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

chiro8x — GMT

Bạn chỉ năn nĩ như vậy có ích gì ? Nếu bạn đề cập đến một vấn đề kỹ thuật thì phải có dẫn chững và hiện tượng cụ thể, nói chung chu thì nhận được mấy lời an ủi thôi. Điều đầu tiên bạn cần làm là : 1. Phân tích hệ thống của bạn, tìm hiểu nguyên nhân dẫn tới quá tải cho hệ thống của bạn. 2. Bắt các gói tin phân tích chúng. 3. Suy nghĩ về giải pháp. Bạn cần cung cấp các file log, hoặc các bằng chứng cần thiết chứng minh bạn bị D.o.S.

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

tuandoi1 — GMT

Em chào cả nhà. Em thì là người không chuyên về quản trị mạng, lại nhất là mấy vụ DDOS này. Nhưng độ này website của nhóm em bị BOTNET đánh. 1 Lần trước đã bị đánh gần 1 tuần. Sau khoảng hơn nửa tháng thì lại bị đánh tiếp. Thực sự là anh em trong nhóm không biết là tại sao bị đánh. Nhóm em có nhờ bên cung cấp dịch vụ máy chủ hỗ trợ. Thì họ bảo là các ip đánh theo kiểu "bắt tay 3 bước" nếu em không nhớ nhầm hay đại khái nó là thế. Vậy có bác nào làm ơn chỉ dùm em cách "đỡ" hoặc tài liệu(tiếng việt) để em nghiên cứu được không ạ. Em học lập trình nên mù về quản trị mạng. Mong các anh chỉ chi tiết 1 chút. Em xin cảm ơn.

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

Ky0 — GMT

tuandoi1 wrote:

Em chào cả nhà. Em thì là người không chuyên về quản trị mạng, lại nhất là mấy vụ DDOS này. Nhưng độ này website của nhóm em bị BOTNET đánh. 1 Lần trước đã bị đánh gần 1 tuần. Sau khoảng hơn nửa tháng thì lại bị đánh tiếp. Thực sự là anh em trong nhóm không biết là tại sao bị đánh. Nhóm em có nhờ bên cung cấp dịch vụ máy chủ hỗ trợ. Thì họ bảo là các ip đánh theo kiểu "bắt tay 3 bước" nếu em không nhớ nhầm hay đại khái nó là thế. Vậy có bác nào làm ơn chỉ dùm em cách "đỡ" hoặc tài liệu(tiếng việt) để em nghiên cứu được không ạ. Em học lập trình nên mù về quản trị mạng. Mong các anh chỉ chi tiết 1 chút. Em xin cảm ơn.

Nếu bạn không có kiến thức gì về mạng thì tốt nhất nên để cho người nào đó có khả năng. Chống đỡ DDOS không phải là việc của những người không nắm rõ hệ thống! Và nên nhớ trong kỹ thuật các thứ step by step không bao giờ áp dụng được vào thực tế! - Ky0 -

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

tuan_delete — GMT

Hiện nay mình thấy các thiết bị phòng chống tấn công IPS ở việt nam rất nhiều hãng , thông số IPS đưa trên catalog rất cao có hãng lên tới 10Gbps nhưng khi bật full IPS còn có 850 Mbps -1,5Gbps. Mình thấy ở Nga , Pháp người ta sử dụng thiết bị IPS thực của hãng NETASQ theo mình biết NETASQ cũng là nhà sản xuất duy nhất đạt chứng chỉ EAL4+ cho cả phần Firewall/IPS và VPN ( Hiện NETASQ VPN được NATO, EU chứng nhận để sử dụng trong các cơ quan chính quyền EU, NATO).