[Thảo luận] Giám sát an ninh mạng - Bàn về giải pháp chống DDoS

by **Admin** Thu Sep 13, 2018 10:50 am

mrro
Administrator
Joined: 27/12/2001 05:07:00
Bài gởi: 745
Offline
[Profile] [PM]
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

by **Admin** Thu Sep 13, 2018 10:52 am

LeVuHoang
HVA Friend
Joined: 08/03/2003 16:54:07
Bài gởi: 1155
Offline
[Profile] [PM]

Đố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.
[Up] [Print Copy]

[Thảo luận] 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
[Avatar]
Ky0
Moderator
Joined: 16/08/2009 23:09:08
Bài gởi: 532
Offline
[Profile] [PM]
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
[Up] [Print Copy]

[Thảo luận] 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
[Avatar]
hizit91
Member
[Minus] 0 [Plus]
Joined: 04/01/2009 20:29:43
Bài gởi: 133
Offline
[Profile] [PM] [Yahoo!]
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
[Up] [Print Copy]

[Thảo luận] 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
[Avatar]
Abe
Researcher
Joined: 29/03/2002 03:19:17
Bài gởi: 145
Offline
[Profile] [PM]
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
[Up] [Print Copy]

[Thảo luận] 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
Bài gởi: 1155
Offline
[Profile] [PM]

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
[Up] [Print Copy]

[Thảo luận] 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
[Minus] 0 [Plus]
Joined: 04/01/2005 04:58:30
Bài gởi: 563
Offline
[Profile] [PM]
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?
[Up] [Print Copy]

[Thảo luận] 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
Bài gởi: 745
Offline
[Profile] [PM]
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ì?http://www.hvaonline.net/hvaonline/posts/list/42133.hva
[Up] [Print Copy]

[Thảo luận] 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
Bài gởi: 1155
Offline
[Profile] [PM]

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.
[Up] [Print Copy]

[Thảo luận] 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
[Avatar]
lQ
Moderator
Joined: 29/03/2005 17:06:20
Bài gởi: 494
Offline
[Profile] [PM]
để 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?

[Up] [Print Copy]

[Thảo luận] 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
Bài gởi: 1155
Offline
[Profile] [PM]

Đà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.
[Up] [Print Copy]

[Thảo luận] 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
[Avatar]
gamma95
Researcher
Joined: 20/05/2003 07:15:41
Bài gởi: 1376
Đến từ: ░░▒▒▓▓██
Offline
[Profile] [PM] [ICQ]
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
Chờ ngày giác ngộ
[Up] [Print Copy]

[Thảo luận] 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
Bài gởi: 1155
Offline
[Profile] [PM]
Đâ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
[Up] [Print Copy]

[Thảo luận] 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
[Avatar]
gamma95
Researcher
Joined: 20/05/2003 07:15:41
Bài gởi: 1376
Đến từ: ░░▒▒▓▓██
Offline
[Profile] [PM] [ICQ]
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
Chờ ngày giác ngộ
[Up] [Print Copy]

[Thảo luận] 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
[Avatar]
Abe
Researcher
Joined: 29/03/2002 03:19:17
Bài gởi: 145
Offline
[Profile] [PM]
@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)
[Up] [Print Copy]

[Thảo luận] 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
[Minus] 0 [Plus]
Joined: 04/01/2005 04:58:30
Bài gởi: 563
Offline
[Profile] [PM]
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.
[Up] [Print Copy]

[Thảo luận] 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
Bài gởi: 1155
Offline
[Profile] [PM]
@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.
[Up] [Print Copy]

[Thảo luận] 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
[Avatar]
lQ
Moderator
Joined: 29/03/2005 17:06:20
Bài gởi: 494
Offline
[Profile] [PM]
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.

[Up] [Print Copy]

[Thảo luận] 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
[Minus] 0 [Plus]
Joined: 04/01/2005 04:58:30
Bài gởi: 563
Offline
[Profile] [PM]
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 đó.
[Up] [Print Copy]

[Thảo luận] 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
Bài gởi: 1155
Offline
[Profile] [PM]

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.
[Up] [Print Copy]

[Thảo luận] 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
[Avatar]
gamma95
Researcher
Joined: 20/05/2003 07:15:41
Bài gởi: 1376
Đến từ: ░░▒▒▓▓██
Offline
[Profile] [PM] [ICQ]
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
Chờ ngày giác ngộ
[Up] [Print Copy]

[Thảo luận] 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
Bài gởi: 745
Offline
[Profile] [PM]
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ì?http://www.hvaonline.net/hvaonline/posts/list/42133.hva
[Up] [Print Copy]

[Thảo luận] 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
[Minus] 0 [Plus]
Joined: 22/03/2006 13:17:49
Bài gởi: 812
Offline
[Profile] [PM] [WWW]
@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"
[Up] [Print Copy]

[Thảo luận] 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
Bài gởi: 745
Offline
[Profile] [PM]
@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ì?http://www.hvaonline.net/hvaonline/posts/list/42133.hva
[Up] [Print Copy]

[Thảo luận] 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
[Minus] 0 [Plus]
Joined: 22/03/2006 13:17:49
Bài gởi: 812
Offline
[Profile] [PM] [WWW]
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"
[Up] [Print Copy]

[Thảo luận] 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
Bài gởi: 745
Offline
[Profile] [PM]
@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ì?http://www.hvaonline.net/hvaonline/posts/list/42133.hva
[Up] [Print Copy]

[Thảo luận] 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
[Minus] 0 [Plus]
Joined: 04/01/2005 04:58:30
Bài gởi: 563
Offline
[Profile] [PM]
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.
[Up] [Print Copy]

[Thảo luận] 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
Bài gởi: 745
Offline
[Profile] [PM]
@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ì?http://www.hvaonline.net/hvaonline/posts/list/42133.hva
[Up] [Print Copy]

[Thảo luận] 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
[Minus] 0 [Plus]
Joined: 29/03/2005 20:34:22
Bài gởi: 662
Đến từ: The Queen
Offline
[Profile] [PM]
@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.
[Up] [Print Copy]

[Thảo luận] 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
Bài gởi: 1155
Offline
[Profile] [PM]

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

by **Admin** Thu Sep 13, 2018 10:54 am

mrro
Administrator
Joined: 27/12/2001 05:07:00
Bài gởi: 745
Offline
[Profile] [PM]
@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
http://tinsang.net

TetCon 2013 http://tetcon.org

Làm an toàn thông tin thì học gì?http://www.hvaonline.net/hvaonline/posts/list/42133.hva
[Up] [Print Copy]

[Thảo luận] Giám sát an ninh mạng - Bàn về giải pháp chống DDoS 03/05/2010 13:43:37 (+0700) | #32 | 210227
hankun
Member
[Minus] 0 [Plus]
Joined: 14/01/2010 07:13:21
Bài gởi: 2
Offline
[Profile] [PM]
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 ạ .
[Up] [Print Copy]

[Thảo luận] Giám sát an ninh mạng - Bàn về giải pháp chống DDoS 25/11/2010 21:07:47 (+0700) | #33 | 225484
[Avatar]
quanta
Moderator
Joined: 28/07/2006 14:44:21
Bài gởi: 7265
Đến từ: $ locate `whoami`
Offline
[Profile] [PM]
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ỉ?
Let's build on a great foundation!
[Up] [Print Copy]

[Thảo luận] Giám sát an ninh mạng - Bàn về giải pháp chống DDoS 26/11/2010 13:21:46 (+0700) | #34 | 225577
[Avatar]
xnohat
Moderator
Joined: 30/01/2005 13:59:19
Bài gởi: 1210
Đến từ: /dev/null
Offline
[Profile] [PM] [Email] [WWW] [Yahoo!] [MSN]
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ị smilie 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 smilie 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 smilie

xNohat

iJust clear, "What I need to do and how to do it"/i
br
brBox tán gẫu dời về: https://www.facebook.com/hvaonline
[Up] [Print Copy]

[Thảo luận] Giám sát an ninh mạng - Bàn về giải pháp chống DDoS 26/11/2010 14:08:07 (+0700) | #35 | 225584
[Avatar]
quanta
Moderator
Joined: 28/07/2006 14:44:21
Bài gởi: 7265
Đến từ: $ locate `whoami`
Offline
[Profile] [PM]
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.
Let's build on a great foundation!
[Up] [Print Copy]

[Thảo luận] Giám sát an ninh mạng - Bàn về giải pháp chống DDoS 26/11/2010 19:53:12 (+0700) | #36 | 225598
[Avatar]
louisnguyen27
Member
[Minus] 0 [Plus]
Joined: 12/08/2008 18:04:41
Bài gởi: 321
Offline
[Profile] [PM]
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.

Q+SBtZW1iZXIgb2YgSFZ+B
Back to Linux soon!!!
[Up] [Print Copy]

[Thảo luận] Giám sát an ninh mạng - Bàn về giải pháp chống DDoS 26/11/2010 21:25:54 (+0700) | #37 | 225615
[Avatar]
xnohat
Moderator
Joined: 30/01/2005 13:59:19
Bài gởi: 1210
Đến từ: /dev/null
Offline
[Profile] [PM] [Email] [WWW] [Yahoo!] [MSN]
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 smilie

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ứ smilie câu đố của em là câu đố rất hay mà smilie
iJust clear, "What I need to do and how to do it"/i
br
brBox tán gẫu dời về: https://www.facebook.com/hvaonline
[Up] [Print Copy]

[Thảo luận] Giám sát an ninh mạng - Bàn về giải pháp chống DDoS 29/11/2010 10:14:48 (+0700) | #38 | 225790
[Avatar]
1mp0ss1bl3
Member
[Minus] 0 [Plus]
Joined: 14/02/2008 21:32:58
Bài gởi: 41
Đến từ: ...
Offline
[Profile] [PM]
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 smilie

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? smilie
To achieve the impossible, one must thing the absurd - to look where everyone else has looked, but to see what no else has seen.
[Up] [Print Copy]

[Thảo luận] Giám sát an ninh mạng - Bàn về giải pháp chống DDoS 29/11/2010 10:47:51 (+0700) | #39 | 225796
[Avatar]
quanta
Moderator
Joined: 28/07/2006 14:44:21
Bài gởi: 7265
Đến từ: $ locate `whoami`
Offline
[Profile] [PM]
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é.
Let's build on a great foundation!
[Up] [Print Copy]

[Thảo luận] Giám sát an ninh mạng - Bàn về giải pháp chống DDoS 29/11/2010 11:44:37 (+0700) | #40 | 225804
[Avatar]
1mp0ss1bl3
Member
[Minus] 0 [Plus]
Joined: 14/02/2008 21:32:58
Bài gởi: 41
Đến từ: ...
Offline
[Profile] [PM]
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ó ý đồ smilie, 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

To achieve the impossible, one must thing the absurd - to look where everyone else has looked, but to see what no else has seen.
[Up] [Print Copy]

[Thảo luận] Giám sát an ninh mạng - Bàn về giải pháp chống DDoS 29/11/2010 12:33:37 (+0700) | #41 | 225810
[Avatar]
quanta
Moderator
Joined: 28/07/2006 14:44:21
Bài gởi: 7265
Đến từ: $ locate `whoami`
Offline
[Profile] [PM]
1mp0ss1bl3 wrote:

Hi quanta,

- Chính xác như bạn thấy, mình bỏ %S đi là có ý đồ smilie, 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 }'
Let's build on a great foundation!
[Up] [Print Copy]

[Thảo luận] Giám sát an ninh mạng - Bàn về giải pháp chống DDoS 29/11/2010 15:30:11 (+0700) | #42 | 225819
[Avatar]
1mp0ss1bl3
Member
[Minus] 0 [Plus]
Joined: 14/02/2008 21:32:58
Bài gởi: 41
Đến từ: ...
Offline
[Profile] [PM]
Hì Hì smilie

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
To achieve the impossible, one must thing the absurd - to look where everyone else has looked, but to see what no else has seen.
[Up] [Print Copy]

[Thảo luận] Giám sát an ninh mạng - Bàn về giải pháp chống DDoS 30/11/2010 11:57:59 (+0700) | #43 | 225897
mrro
Administrator
Joined: 27/12/2001 05:07:00
Bài gởi: 745
Offline
[Profile] [PM]
he he he hay smilie. 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
http://tinsang.net

TetCon 2013 http://tetcon.org

Làm an toàn thông tin thì học gì?http://www.hvaonline.net/hvaonline/posts/list/42133.hva
[Up] [Print Copy]

[Thảo luận] Giám sát an ninh mạng - Bàn về giải pháp chống DDoS 30/11/2010 13:01:58 (+0700) | #44 | 225902
[Avatar]
1mp0ss1bl3
Member
[Minus] 0 [Plus]
Joined: 14/02/2008 21:32:58
Bài gởi: 41
Đến từ: ...
Offline
[Profile] [PM]
mrro wrote:
he he he hay smilie. 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 smilie) 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
To achieve the impossible, one must thing the absurd - to look where everyone else has looked, but to see what no else has seen.
[Up] [Print Copy]

[Thảo luận] Giám sát an ninh mạng - Bàn về giải pháp chống DDoS 30/11/2010 13:49:28 (+0700) | #45 | 225906
mrro
Administrator
Joined: 27/12/2001 05:07:00
Bài gởi: 745
Offline
[Profile] [PM]
@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
http://tinsang.net

TetCon 2013 http://tetcon.org

Làm an toàn thông tin thì học gì?http://www.hvaonline.net/hvaonline/posts/list/42133.hva
[Up] [Print Copy]

[Thảo luận] Giám sát an ninh mạng - Bàn về giải pháp chống DDoS 30/11/2010 18:32:47 (+0700) | #46 | 225923
[Avatar]
quanta
Moderator
Joined: 28/07/2006 14:44:21
Bài gởi: 7265
Đến từ: $ locate `whoami`
Offline
[Profile] [PM]
mrro wrote:
he he he hay smilie. 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?
Let's build on a great foundation!
[Up] [Print Copy]

[Thảo luận] Giám sát an ninh mạng - Bàn về giải pháp chống DDoS 30/11/2010 23:37:58 (+0700) | #47 | 225967
[Avatar]
xnohat
Moderator
Joined: 30/01/2005 13:59:19
Bài gởi: 1210
Đến từ: /dev/null
Offline
[Profile] [PM] [Email] [WWW] [Yahoo!] [MSN]
mrro wrote:
he he he hay smilie. 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 đề smilie

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 smilie

Search google phát được ku này: http://logtomysql.sourceforge.net/install.html
iJust clear, "What I need to do and how to do it"/i
br
brBox tán gẫu dời về: https://www.facebook.com/hvaonline
[Up] [Print Copy]

[Thảo luận] Giám sát an ninh mạng - Bàn về giải pháp chống DDoS 30/11/2010 23:58:11 (+0700) | #48 | 225970
[Avatar]
quanta
Moderator
Joined: 28/07/2006 14:44:21
Bài gởi: 7265
Đến từ: $ locate `whoami`
Offline
[Profile] [PM]
xnohat wrote:

he he câu hỏi của lão mrro làm tớ lóe lên 1 vấn đề smilie

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 smilie

Search google phát được ku này: http://logtomysql.sourceforge.net/install.html

http://www.hvaonline.net/hvaonline/posts/list/0/14855.hva#163334
Let's build on a great foundation!
[Up] [Print Copy]

[Thảo luận] Giám sát an ninh mạng - Bàn về giải pháp chống DDoS 01/12/2010 00:23:09 (+0700) | #49 | 225973
[Avatar]
xnohat
Moderator
Joined: 30/01/2005 13:59:19
Bài gởi: 1210
Đến từ: /dev/null
Offline
[Profile] [PM] [Email] [WWW] [Yahoo!] [MSN]
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 đề smilie

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 smilie

Search google phát được ku này: http://logtomysql.sourceforge.net/install.html

http://www.hvaonline.net/hvaonline/posts/list/0/14855.hva#163334

ây da smilie 2 năm trước nó đã được thảo luận rồi sao smilie

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 -
iJust clear, "What I need to do and how to do it"/i
br
brBox tán gẫu dời về: https://www.facebook.com/hvaonline
[Up] [Print Copy]

[Thảo luận] Giám sát an ninh mạng - Bàn về giải pháp chống DDoS 01/12/2010 07:48:47 (+0700) | #50 | 225991
[Avatar]
vikjava
Elite Member
[Minus] 0 [Plus]
Joined: 28/06/2004 02:32:38
Bài gởi: 926
Đến từ: NQN
Offline
[Profile] [PM]
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ở
[Up] [Print Copy]

[Thảo luận] Giám sát an ninh mạng - Bàn về giải pháp chống DDoS 01/12/2010 08:32:05 (+0700) | #51 | 225995
[Avatar]
quanta
Moderator
Joined: 28/07/2006 14:44:21
Bài gởi: 7265
Đến từ: $ locate `whoami`
Offline
[Profile] [PM]
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
Let's build on a great foundation!
[Up] [Print Copy]

[Thảo luận] Giám sát an ninh mạng - Bàn về giải pháp chống DDoS 01/12/2010 08:48:29 (+0700) | #52 | 226000
mrro
Administrator
Joined: 27/12/2001 05:07:00
Bài gởi: 745
Offline
[Profile] [PM]
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 smilie.

-m

http://tinsang.net

TetCon 2013 http://tetcon.org

Làm an toàn thông tin thì học gì?http://www.hvaonline.net/hvaonline/posts/list/42133.hva
[Up] [Print Copy]

[Thảo luận] Giám sát an ninh mạng - Bàn về giải pháp chống DDoS 01/12/2010 09:04:57 (+0700) | #53 | 226004
[Avatar]
quanta
Moderator
Joined: 28/07/2006 14:44:21
Bài gởi: 7265
Đến từ: $ locate `whoami`
Offline
[Profile] [PM]
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.
Let's build on a great foundation!
[Up] [Print Copy]

[Thảo luận] Giám sát an ninh mạng - Bàn về giải pháp chống DDoS 01/12/2010 09:25:32 (+0700) | #54 | 226013
[Avatar]
conmale
Administrator
Joined: 07/05/2004 23:43:15
Bài gởi: 9353
Đến từ: down under
Offline
[Profile] [PM]
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 smilie.
What bringing us together is stronger than what pulling us apart.
[Up] [Print Copy]

[Thảo luận] Giám sát an ninh mạng - Bàn về giải pháp chống DDoS 01/12/2010 09:31:49 (+0700) | #55 | 226017
mrro
Administrator
Joined: 27/12/2001 05:07:00
Bài gởi: 745
Offline
[Profile] [PM]
@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

http://tinsang.net

TetCon 2013 http://tetcon.org

Làm an toàn thông tin thì học gì?http://www.hvaonline.net/hvaonline/posts/list/42133.hva
[Up] [Print Copy]

[Thảo luận] Giám sát an ninh mạng - Bàn về giải pháp chống DDoS 01/12/2010 14:00:53 (+0700) | #56 | 226046
[Avatar]
lQ
Moderator
Joined: 29/03/2005 17:06:20
Bài gởi: 494
Offline
[Profile] [PM]
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ẻ.

[Up] [Print Copy]

[Thảo luận] Giám sát an ninh mạng - Bàn về giải pháp chống DDoS 03/04/2011 01:26:33 (+0700) | #57 | 234497
IamN
Member
[Minus] 0 [Plus]
Joined: 10/03/2010 07:25:47
Bài gởi: 11
Offline
[Profile] [PM]
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?
[Up] [Print Copy]

[Thảo luận] Giám sát an ninh mạng - Bàn về giải pháp chống DDoS 30/04/2011 21:29:05 (+0700) | #58 | 236466
hnaod
Member
[Minus] 0 [Plus]
Joined: 10/04/2011 11:32:07
Bài gởi: 1
Offline
[Profile] [PM]
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
[Up] [Print Copy]

[Thảo luận] Giám sát an ninh mạng - Bàn về giải pháp chống DDoS 08/06/2011 08:41:39 (+0700) | #59 | 239672
[Avatar]
quanta
Moderator
Joined: 28/07/2006 14:44:21
Bài gởi: 7265
Đến từ: $ locate `whoami`
Offline
[Profile] [PM]
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é.
Let's build on a great foundation!
[Up] [Print Copy]

[Thảo luận] Giám sát an ninh mạng - Bàn về giải pháp chống DDoS 08/06/2011 08:58:38 (+0700) | #60 | 239674
[Avatar]
secmask
Elite Member
[Minus] 0 [Plus]
Joined: 29/10/2004 13:52:24
Bài gởi: 553
Đến từ: graveyard
Offline
[Profile] [PM] [WWW]
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).

by **Admin** Thu Sep 13, 2018 10:55 am

quybeo83
Member
[Minus] 0 [Plus]
Joined: 15/07/2010 21:12:11
Bài gởi: 35
Offline
[Profile] [PM] [Yahoo!]
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 đỡ.
[Up] [Print Copy]

[Thảo luận] Giám sát an ninh mạng - Bàn về giải pháp chống DDoS 16/06/2011 15:03:07 (+0700) | #62 | 241067
anti-ddos
Member
[Minus] 0 [Plus]
Joined: 27/02/2011 11:44:00
Bài gởi: 4
Offline
[Profile] [PM]
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.
[Up] [Print Copy]

[Thảo luận] Giám sát an ninh mạng - Bàn về giải pháp chống DDoS 16/06/2011 17:01:10 (+0700) | #63 | 241088
Tony_nguyen19
Member
[Minus] 0 [Plus]
Joined: 25/01/2008 11:21:17
Bài gởi: 7
Offline
[Profile] [PM]
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
[Up] [Print Copy]

[Thảo luận] Giám sát an ninh mạng - Bàn về giải pháp chống DDoS 17/06/2011 11:26:49 (+0700) | #64 | 241161
anti-ddos
Member
[Minus] 0 [Plus]
Joined: 27/02/2011 11:44:00
Bài gởi: 4
Offline
[Profile] [PM]
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).

[Up] [Print Copy]

[Thảo luận] Giám sát an ninh mạng - Bàn về giải pháp chống DDoS 20/06/2011 18:45:36 (+0700) | #65 | 241503
quybeo83
Member
[Minus] 0 [Plus]
Joined: 15/07/2010 21:12:11
Bài gởi: 35
Offline
[Profile] [PM] [Yahoo!]
đ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.
[Up] [Print Copy]

[Thảo luận] Giám sát an ninh mạng - Bàn về giải pháp chống DDoS 06/08/2011 20:29:59 (+0700) | #66 | 244663
trycatch
Member
[Minus] 0 [Plus]
Joined: 07/12/2010 20:00:36
Bài gởi: 15
Offline
[Profile] [PM]
Bài viết này được chỉnh thành dạng "ẩn" vì đã vi phạm nội quy của diễn đàn hoặc đang được điều chỉnh để thích hợp với nội quy của diễn đàn.
[Up] [Print Copy]

[Thảo luận] Giám sát an ninh mạng - Bàn về giải pháp chống DDoS 31/03/2012 01:22:36 (+0700) | #67 | 260436
soi_hoang84
Member
[Minus] 0 [Plus]
Joined: 19/04/2005 06:16:29
Bài gởi: 4
Offline
[Profile] [PM]
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
[Up] [Print Copy]

[Thảo luận] Giám sát an ninh mạng - Bàn về giải pháp chống DDoS 31/03/2012 16:22:54 (+0700) | #68 | 260463
[Avatar]
chiro8x
Member
[Minus] 0 [Plus]
Joined: 26/09/2010 00:38:37
Bài gởi: 661
Đến từ: /home/chiro8x
Offline
[Profile] [PM] [Yahoo!]
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.
while(1){}
[Up] [Print Copy]

[Thảo luận] Giám sát an ninh mạng - Bàn về giải pháp chống DDoS 21/10/2012 09:17:23 (+0700) | #69 | 270329
boyfriends
Member
[Minus] 0 [Plus]
Joined: 13/10/2012 02:43:16
Bài gởi: 1
Offline
[Profile] [PM]
Bài viết này được chỉnh thành dạng "ẩn" vì đã vi phạm nội quy của diễn đàn hoặc đang được điều chỉnh để thích hợp với nội quy của diễn đàn.
[Up] [Print Copy]

[Thảo luận] Giám sát an ninh mạng - Bàn về giải pháp chống DDoS 10/11/2012 22:34:51 (+0700) | #70 | 270884
tuandoi1
Member
[Minus] 0 [Plus]
Joined: 10/07/2009 13:49:17
Bài gởi: 1
Offline
[Profile] [PM]
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.
[Up] [Print Copy]

[Thảo luận] Giám sát an ninh mạng - Bàn về giải pháp chống DDoS 11/11/2012 00:07:31 (+0700) | #71 | 270888
[Avatar]
Ky0
Moderator
Joined: 16/08/2009 23:09:08
Bài gởi: 532
Offline
[Profile] [PM]
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 -
UITNetwork.com
Let's Connect
[Up] [Print Copy]

[Thảo luận] Giám sát an ninh mạng - Bàn về giải pháp chống DDoS 06/04/2013 23:03:00 (+0700) | #72 | 274743
tieutukho92
Member
[Minus] 0 [Plus]
Joined: 06/04/2009 10:22:12
Bài gởi: 1
Offline
[Profile] [PM]
Bài viết này được chỉnh thành dạng "ẩn" vì đã vi phạm nội quy của diễn đàn hoặc đang được điều chỉnh để thích hợp với nội quy của diễn đàn.
[Up] [Print Copy]

[Thảo luận] Giám sát an ninh mạng - Bàn về giải pháp chống DDoS 21/04/2013 11:54:10 (+0700) | #73 | 275116
trjeunguyen
Member
[Minus] 0 [Plus]
Joined: 01/04/2013 13:40:22
Bài gởi: 10
Offline
[Profile] [PM]
Bài viết này được chỉnh thành dạng "ẩn" vì đã vi phạm nội quy của diễn đàn hoặc đang được điều chỉnh để thích hợp với nội quy của diễn đàn.
[Up] [Print Copy]

[Thảo luận] Giám sát an ninh mạng - Bàn về giải pháp chống DDoS 17/07/2013 01:07:12 (+0700) | #74 | 277502
tuan_delete
Member
[Minus] 0 [Plus]
Joined: 26/06/2006 17:18:53
Bài gởi: 2
Offline
[Profile] [PM]
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).

by Sponsored content

[Thảo luận] Giám sát an ninh mạng - Bàn về giải pháp chống DDoS

[Thảo luận] Giám sát an ninh mạng - Bàn về giải pháp chống DDoS

Re: [Thảo luận] Giám sát an ninh mạng - Bàn về giải pháp chống DDoS

Re: [Thảo luận] Giám sát an ninh mạng - Bàn về giải pháp chống DDoS

Re: [Thảo luận] Giám sát an ninh mạng - Bàn về giải pháp chống DDoS

Re: [Thảo luận] Giám sát an ninh mạng - Bàn về giải pháp chống DDoS