Các nhà cung cấp bảo mật vừa cảnh báo người dùng về một phần mềm độc hại có thể lây nhiễm vào máy tính thông qua một lỗi nổi tiếng AutoRun của Windows được sử dụng để tự động khởi động chương trình trên một thiết bị DVD hoặc USB.
Sự trở lại của mã độc tấn công trong AutoRun là điều rất được quan tâm, đặc biệt khi Windows 7 và Windows 8 không có tính năng tự động khởi động tập tin autorun.inf, và Microsoft cũng đã phát hành 2 bản vá lỗi cho hệ điều hành cũ. Chính vì vậy, các chuyên gia bảo mật tin rằng hoạt động tấn công này chỉ xảy ra thông qua một máy tính chưa được cập nhật bản vá lỗi, hoạt động chia sẻ các thư mục/tập tin và các phương tiện truyền thông mạng xã hội.
Một người nào đó chèn ổ flash USB hoặc thẻ nhớ mang theo phần mềm độc hại có thể lây nhiễm vào các máy tính chưa được vá lỗi. Trên hệ thống khác, một mã độc có thể tấn công thông qua các hoạt động chia sẻ trên một mạng và có ai đó nhấp chuột vào một tập tin hoặc thư mục bị nhiễm độc. Trend Micro cũng thông báo rằng phần mềm độc hại cũng có thể lan truyền trên Facebook.
Các nhà cung cấp khác đang theo dõi phần mềm độc hại này, bao gồm McAfee, Symantec, và Sophos. Trong khi hầu hết cho rằng mã độc khai thác thông qua lỗi AutoRun truyền thống thì Sophos lại cho biết hầu hết các máy tính cá nhân của các công ty đang nhiễm bệnh thông qua mạng chia sẻ.
Sophos: Chia sẻ tập tin có khả năng là thủ phạm
Chiến thuật mới nhất
Các phần mềm độc hại mới nhất có khả năng cải trang bản thân như là các tập tin và thư mục trong mạng chia sẻ để lưu trữ trên các thiết bị di động. Chúng cũng sẽ tạo ra các file exe với tên liên quan đến các hoạt động khiêu dâm hoặc một thư mục có tên gọi là password để lôi kéo người dùng bấm vào chúng, theo Sophos.
Phần mềm độc hại sẽ thêm một khóa registry, do đó nó có thể chạy ngay khi máy tính được khởi động. Các biến thể của ứng dụng sẽ vô hiệu hóa tính năng Windows Update để ngăn chặn nạn nhân tải về các bản vá lỗi để vô hiệu hóa các phần mềm độc hại.
Khi một máy tính bị nhiễm độc, ứng dụng sẽ thực hiện theo một quy trình do phần mềm độc hại đặt ra. Nó có khả năng liên lạc với một máy chủ lệnh và kiểm soát các chỉ dẫn. Sophos cảnh báo, chúng cũng có thể tải về các trojan trong gia đình sâu Zeus/Zbot, đánh cắp thông tin ngân hàng trực tuyến,...
Để chống lại các phần mềm độc hại, các chuyên gia bảo mật khuyên người dùng nên vô hiệu hóa tính năng AutoRun trên tất cả các hệ điều hành Windows và hạn chế quyền ghi chèn các tập tin. Tùy thuộc vào nhà cung cấp AV, phần mềm độc hại mới có nhiều tên khác, bao gồm cả W32/VBNA-X, W32/Autorun.worm.aaeb, W32.ChangeUp và WORM_VOBFUS.
Ổ dịch mới nhất được phát hiện chỉ 1,5 năm sau khi Microsoft báo cáo sự sụt giảm lớn trong tỷ lệ lây nhiễm mã độc AutoRun. Cũng theo Microsoft, so với năm 2010 thì trong 5 tháng đầu năm 2011, số lượng phần mềm độc hại liên quan đến AutoRun được phát hiện bởi Microsoft đã giảm 59% trên máy tính Windows XP và 74% trên máy tính Vista.
Theo NLD
Cảnh báo mã độc tấn công Windows AutoRun trở lại
Forum hacker ngầm: Có nên tham gia hay không?
Trong giới hacker, security
trước nay vẫn được phân chia thành mũ trắng và mũ đen. Một phía chuyên
lợi dụng lỗi hổng đến tấn công, trục lợi mang mục đích xấu. Một bên là
các chuyên gia tìm và khắc phục lỗ hổng.
Tuy vậy, ranh giới đen trắng thường rất mỏng manh. Trong thế giới mạng của các hacker cũng vậy. Nhiều diễn đàn được mở ra để trao đổi, học hỏi về kỹ thuật và bảo mật, nhưng cũng không ít diễn đàn đang tồn tại như một thế giới ngầm, hay còn gọi là Underground Hacker Forum, gọi tắt là UG.
Những diễn đàn UG rất đa dạng và phong phú về hình thức, quy mô. Tuy
nhiên hầu hết đều có một điểm đồng nhất là hoạt động rất khép kín, thành
viên tham gia được tuyển chọn kỹ càng qua từng đợt. Đào thải thường
xuyên nếu bạn không hoạt động tốt.
Giống như nếu có người yêu cầu bạn ở chung nhà với những tên trộm cướp, chắc chắn bạn sẽ không đồng ý. Vì đương nhiên không ai muốn dính vào những chuyện không đâu cả. Trong lĩnh vực bảo mật cũng có nhiều ý kiến như thế.
Tuy vậy, không thể phủ nhận rằng đây là nơi chứa đựng rất nhiều kiến thức, thảo luận đáng để học hỏi. Có thể là về kiến thức chuyên ngành, cũng có thể là những lối suy nghĩ, nhìn nhận vấn đề vô cùng độc đáo.
Bỏ qua chuyện lừa lọc ở UG, bạn có biết rằng rất nhiều lỗ hổng dạng Zero Day được tìm thấy tại các diễn đàn này, và hàng ngày còn rất nhiều lỗi khác đang được rao bán ở các chợ đen ? Vì vậy, không thể không công nhận khả năng của những thành viên hoạt động trong diễn đàn UG.
Hacker mũ trắng, những chuyên gia bảo mật, thông thường ngoài các lỗi phổ biến trên thế giới có thể tính trước được, thì luôn phải đi sau các hacker mũ đen này. Đây không phải là bàn về trình độ, mà là về tiến trình, thì việc khai thác luôn đi trước, khắc phục vẫn phải theo sau. Vậy, sẽ tốt hơn nếu 1 hacker mũ trắng cũng tham gia vào diễn đàn UG, để cập nhật đc nhanh chóng các thông tin lỗi bảo mật mới nhất phải không ?
Muốn đánh bại kẻ thù, bạn phải hiểu rõ về họ trước. Có cách nào tốt hơn là việc cùng hoạt đột với họ không ?
Bạn nên chuẩn bị hành trang cho mình trước khi muốn tham gia vào UG, đó là một số quy tắc cần nhớ như sau:
Bài viết này không đề cập đến các diễn đàn UG của Việt Nam, vì ở Việt Nam, các diễn đàn này rất, rất ít, ngoài ra các diễn đàn UG như mọi người thường quen gọi không có giá trị nhiều về kiến thức trong lĩnh vực bảo mật, hầu như nó chỉ là các chợ đen.
Theo: http://techblog.vn/
Tuy vậy, ranh giới đen trắng thường rất mỏng manh. Trong thế giới mạng của các hacker cũng vậy. Nhiều diễn đàn được mở ra để trao đổi, học hỏi về kỹ thuật và bảo mật, nhưng cũng không ít diễn đàn đang tồn tại như một thế giới ngầm, hay còn gọi là Underground Hacker Forum, gọi tắt là UG.
Giống như nếu có người yêu cầu bạn ở chung nhà với những tên trộm cướp, chắc chắn bạn sẽ không đồng ý. Vì đương nhiên không ai muốn dính vào những chuyện không đâu cả. Trong lĩnh vực bảo mật cũng có nhiều ý kiến như thế.
Tuy vậy, không thể phủ nhận rằng đây là nơi chứa đựng rất nhiều kiến thức, thảo luận đáng để học hỏi. Có thể là về kiến thức chuyên ngành, cũng có thể là những lối suy nghĩ, nhìn nhận vấn đề vô cùng độc đáo.
Bỏ qua chuyện lừa lọc ở UG, bạn có biết rằng rất nhiều lỗ hổng dạng Zero Day được tìm thấy tại các diễn đàn này, và hàng ngày còn rất nhiều lỗi khác đang được rao bán ở các chợ đen ? Vì vậy, không thể không công nhận khả năng của những thành viên hoạt động trong diễn đàn UG.
Hacker mũ trắng, những chuyên gia bảo mật, thông thường ngoài các lỗi phổ biến trên thế giới có thể tính trước được, thì luôn phải đi sau các hacker mũ đen này. Đây không phải là bàn về trình độ, mà là về tiến trình, thì việc khai thác luôn đi trước, khắc phục vẫn phải theo sau. Vậy, sẽ tốt hơn nếu 1 hacker mũ trắng cũng tham gia vào diễn đàn UG, để cập nhật đc nhanh chóng các thông tin lỗi bảo mật mới nhất phải không ?
Muốn đánh bại kẻ thù, bạn phải hiểu rõ về họ trước. Có cách nào tốt hơn là việc cùng hoạt đột với họ không ?
Bạn nên chuẩn bị hành trang cho mình trước khi muốn tham gia vào UG, đó là một số quy tắc cần nhớ như sau:
- Không tham gia vào các hoạt động phi pháp, mang tính hội nhóm do các diễn đàn này tổ chức.
- Không dùng các tài khoản email chính, mật khẩu thường dùng để tạo tài khoản tham gia UG.
- Hạn chế mua bán, giao dịch với các thành viên, vì nguy cơ lừa đảo rất cao.
Bài viết này không đề cập đến các diễn đàn UG của Việt Nam, vì ở Việt Nam, các diễn đàn này rất, rất ít, ngoài ra các diễn đàn UG như mọi người thường quen gọi không có giá trị nhiều về kiến thức trong lĩnh vực bảo mật, hầu như nó chỉ là các chợ đen.
Theo: http://techblog.vn/
Xem Thêm
Bug Bounty – Paypal có chơi đẹp?
Bug Bounty là chương trình tìm kiếm lỗ hổng bảo mật và thông báo cho
đơn vị tổ chức và nhận giải thưởng. Các lỗ hổng tìm được sẽ được cung
cấp duy nhất cho nhà tổ chức.
Nhiều trang web nổi tiếng như Facebook, Google, Paypal, Mozilla, Barracuda Networks chi hàng nghìn USD để trao giải thưởng cho các hacker tìm ra lỗi.
Paypal Bug Bounty là cuộc thi được giới bảo mật quan tâm đánh giá cao. Tuy nhiên đã có những khúc mắc quanh cuộc thi này và người tham gia đang đặt câu hỏi liệu Paypal có chơi đẹp ?
Hầu hết các lỗ hổng được thông báo là XSS, Cross Site Scripting. Như vậy sẽ có trường hợp thông báo trùng lỗi đã có người báo. Tuy nhiên nếu bạn là người đầu tiên, nhà tổ chức vẫn trả lời như vậy liệu bạn có thể làm gì được không ? Câu trả lời là không.
Tương tự như thế, trong năm nay, hacker Mohit Kumar đã thông báo cho Facebook và Google 17 lần, và nhận được thông báo là họ đã biết lỗi này rồi, bạn không đủ tiêu chuẩn nhận tiền thưởng. Lạ là ở chỗ nếu họ đã biết rồi thì tại sao lỗi vẫn xảy ra?
Paypal là trang web cung cấp dịch vụ thanh toán thương mại điện tử lớn trên thế giới. Họ cũng vừa tổ chức Bug Bounty và rất nhiều hacker đã tham gia. Hacker Christy và hacker Philip Mathew đã phát hiện ra 8 lỗ hổng trong hệ thống Paypal, và nhận được thông báo 6 trong số các lỗi đó đã được thông báo trước đây không nằm trong chương trình.
Kèm theo đó là câu trả lời rằng họ không được nhận tiền thưởng, vì phần thưởng chỉ dành cho người đầu tiên tìm ra lỗi. Tuy nhiên khi muốn có thông tin để trao đổi với người tìm ra lỗi thì Paypal lại không cung cấp.
Lỗi XSS này được báo cáo ngày 12/10/2012, tuy nhiên mãi đến 16/10/2012 Paypal mới phản hồi với nội dung như trên. Có thể họ dùng thời gian đó để suy nghĩ có nên trao thưởng cho những người này hay không.
Tương tự lỗi Iframe được báo ngày 10/10/2012 và nhận được phản hồi ngày 07/11/2012. Khoảng thời gian gần một tháng đó đủ để Paypal cân đối ngân sách và đưa ra quyết định không trao thưởng.
Các trang web, cộng đồng hacker đang thảo luận rất xôn xao về vụ việc này. Liệu đây có phải là cách để Paypal tiết kiệm tốt hay lại gây thù chuốc oán với các hacker?
Nhiều trang web nổi tiếng như Facebook, Google, Paypal, Mozilla, Barracuda Networks chi hàng nghìn USD để trao giải thưởng cho các hacker tìm ra lỗi.
Paypal Bug Bounty là cuộc thi được giới bảo mật quan tâm đánh giá cao. Tuy nhiên đã có những khúc mắc quanh cuộc thi này và người tham gia đang đặt câu hỏi liệu Paypal có chơi đẹp ?
Hầu hết các lỗ hổng được thông báo là XSS, Cross Site Scripting. Như vậy sẽ có trường hợp thông báo trùng lỗi đã có người báo. Tuy nhiên nếu bạn là người đầu tiên, nhà tổ chức vẫn trả lời như vậy liệu bạn có thể làm gì được không ? Câu trả lời là không.
Tương tự như thế, trong năm nay, hacker Mohit Kumar đã thông báo cho Facebook và Google 17 lần, và nhận được thông báo là họ đã biết lỗi này rồi, bạn không đủ tiêu chuẩn nhận tiền thưởng. Lạ là ở chỗ nếu họ đã biết rồi thì tại sao lỗi vẫn xảy ra?
Paypal là trang web cung cấp dịch vụ thanh toán thương mại điện tử lớn trên thế giới. Họ cũng vừa tổ chức Bug Bounty và rất nhiều hacker đã tham gia. Hacker Christy và hacker Philip Mathew đã phát hiện ra 8 lỗ hổng trong hệ thống Paypal, và nhận được thông báo 6 trong số các lỗi đó đã được thông báo trước đây không nằm trong chương trình.
Kèm theo đó là câu trả lời rằng họ không được nhận tiền thưởng, vì phần thưởng chỉ dành cho người đầu tiên tìm ra lỗi. Tuy nhiên khi muốn có thông tin để trao đổi với người tìm ra lỗi thì Paypal lại không cung cấp.
Lỗi XSS này được báo cáo ngày 12/10/2012, tuy nhiên mãi đến 16/10/2012 Paypal mới phản hồi với nội dung như trên. Có thể họ dùng thời gian đó để suy nghĩ có nên trao thưởng cho những người này hay không.
Tương tự lỗi Iframe được báo ngày 10/10/2012 và nhận được phản hồi ngày 07/11/2012. Khoảng thời gian gần một tháng đó đủ để Paypal cân đối ngân sách và đưa ra quyết định không trao thưởng.
Các trang web, cộng đồng hacker đang thảo luận rất xôn xao về vụ việc này. Liệu đây có phải là cách để Paypal tiết kiệm tốt hay lại gây thù chuốc oán với các hacker?
Xem Thêm
Kho tài liệu IT của Nhất Nghệ
http://tailieu.nhatnghe.com/index.php?dir=
Xem Thêm
Tut Local Server Cai Modsecurity
Công cụ: shell + cái gì đó.
Victim : http://ccncmaster.com/index.php
Tìm Path trc ná, mình hướng dẫn cho ai chưa biết luôn, cách tìm path đơn giản nhất qua error_log
Trước hết tạo ra 1 error_log cái đã
Thứ 2 tìm cái error_log đó, sử dụng lệnh đơn giản
SV cài đặt mod_security thì thường nó không cho các lệnh cơ bản để chạy đâu
406 Not accept table.
Vì không thể sử dụng lệnh trực tiếp ta hãy sử dụng nó 1 cách gián tiếp.
tạo 1 file chứa command bên trong nó và lưu với tên gì cũng đc.
Mình save thành file ku.to
trong đó ln -s (Tạo 1 symlink), /home/thangnq/puclic_html/ --> đường dẫn đến website victim, index.php --> file cần symlink, trym.txt file symlink
sau đó up file ku.to lên sv
Sau đó chúng ta sử dụng lệnh : sh ku.to
và thưởng thức kết quả:
Victim : http://ccncmaster.com/index.php
Tìm Path trc ná, mình hướng dẫn cho ai chưa biết luôn, cách tìm path đơn giản nhất qua error_log
Trước hết tạo ra 1 error_log cái đã
Thứ 2 tìm cái error_log đó, sử dụng lệnh đơn giản
tail -n 10000 /usr/local/apache/logs/error_log|grep trymtoTrong đó 10000 là số dòng, cái này tùy biến, /usr/local/apache/logs/error_log --> Đường dẫn đến nơi chứa logs file --> có thể khác (tùy biến nếu nó thay đổi, mặc định là thế), grep trymto lọc ra error với nội dung lúc nãy mình tạo ra.
SV cài đặt mod_security thì thường nó không cho các lệnh cơ bản để chạy đâu
406 Not accept table.
Vì không thể sử dụng lệnh trực tiếp ta hãy sử dụng nó 1 cách gián tiếp.
tạo 1 file chứa command bên trong nó và lưu với tên gì cũng đc.
Mình save thành file ku.to
trong đó ln -s (Tạo 1 symlink), /home/thangnq/puclic_html/ --> đường dẫn đến website victim, index.php --> file cần symlink, trym.txt file symlink
sau đó up file ku.to lên sv
Sau đó chúng ta sử dụng lệnh : sh ku.to
và thưởng thức kết quả:
Xem Thêm
[TUT] Anti DDoS - WebHunter - Phần 4
Phần 4: Phần này mình có hứng nên viết thêm. Thực ra phần này các bạn
không cần đọc cũng được, nhưng mình khuyến khích các bạn nên đọc, bởi vì
đây là kinh nghiêm thực tế của mình.
Khi nói đến việc anti-ddos, rất nhiều bạn và có thể nói là hầu hết mọi người đều nghĩ đến một công việc duy nhất cần làm, chính xác hơn thì nghĩ đến quy trình là :
Capture -> Phân tích -> Nhận ra đặt điểm -> Block nguồn nào có đặt điểm như vậy.
Tuy nhiên quy trình trên cũng có tồn tại những hạn chế của nó, đó là đối với botnet hay các loại attack tương tự. Với các hình thức tấn công bằng sức trâu bò thì việc nhận ra đặt điểm là không khó, thường chỉ cần "bắn tốc độ" là được. Tuy nhiên với những hình thức tấn công khác tinh vi hơn, các zombie không đánh một cách mạnh mẽ, ồ ạt mà chỉ lếch từ từ đến mục tiêu xong đồng loạt hit một cái, điều gì sẽ xảy ra ?? Dĩ nhiên việc mô phỏng người dùng hợp lệ giờ không còn khó, dù là trap gì chúng ta cũng có thể phân tích và đưa ra phương pháp bypass qua được. Lúc này thì việc limit resource là cần thiết vô cùng, và có thể nói đó là một cách hạn chế hữu hiệu (dĩ nhiên là phải kết hợp với các phương pháp khác để chống các hình thức khác).
Limit resource giống như là khái niệm chroot trên linux system, mỗi client có được một lượng resource nhất định và trong phạm vi đó thích làm gì thì làm. Và muốn làm được việc này thì buộc lòng các bạn phải nghiên cứu nhiều hơn về performance tuning system, chỉ có khi nào chúng ta hiểu thật sâu về system chúng ta mới có thể áp dụng phương pháp này hiệu quả.
Khi nói đến việc anti-ddos, rất nhiều bạn và có thể nói là hầu hết mọi người đều nghĩ đến một công việc duy nhất cần làm, chính xác hơn thì nghĩ đến quy trình là :
Capture -> Phân tích -> Nhận ra đặt điểm -> Block nguồn nào có đặt điểm như vậy.
Tuy nhiên quy trình trên cũng có tồn tại những hạn chế của nó, đó là đối với botnet hay các loại attack tương tự. Với các hình thức tấn công bằng sức trâu bò thì việc nhận ra đặt điểm là không khó, thường chỉ cần "bắn tốc độ" là được. Tuy nhiên với những hình thức tấn công khác tinh vi hơn, các zombie không đánh một cách mạnh mẽ, ồ ạt mà chỉ lếch từ từ đến mục tiêu xong đồng loạt hit một cái, điều gì sẽ xảy ra ?? Dĩ nhiên việc mô phỏng người dùng hợp lệ giờ không còn khó, dù là trap gì chúng ta cũng có thể phân tích và đưa ra phương pháp bypass qua được. Lúc này thì việc limit resource là cần thiết vô cùng, và có thể nói đó là một cách hạn chế hữu hiệu (dĩ nhiên là phải kết hợp với các phương pháp khác để chống các hình thức khác).
Limit resource giống như là khái niệm chroot trên linux system, mỗi client có được một lượng resource nhất định và trong phạm vi đó thích làm gì thì làm. Và muốn làm được việc này thì buộc lòng các bạn phải nghiên cứu nhiều hơn về performance tuning system, chỉ có khi nào chúng ta hiểu thật sâu về system chúng ta mới có thể áp dụng phương pháp này hiệu quả.
Xem Thêm
[TUT] Anti DDoS - WebHunter - Phần 3
3. Phương pháp hạn chế.
Nhìn chung với DDoS chúng ta có 2 action cơ bản trong việc hạn chế (sau khi nhận ra được hình thức)
- Thứ nhất là block IP
- Thứ 2 là limit resource.
Block IP có được ưu điểm lớn đó là chặn luôn nguồn tấn công vào, điều này sẽ hạn chế được sự thất thoát tài nguyên, dĩ nhiên rồi vì mục tiêu của anti DDoS là hạn chế sự thất thoát tài nguyên, tuy nhiên bên cạnh đó chúng ta phải đối phó với bài toán khác đó chính là làm sao để lọc một cách cụ thể và chi tiết để không block lộn người dùng hợp lệ. Đây là vấn đề rất quan trọng đấy, nhưng không thảo luận ở đây.
Với cách thứ 2 là limit resource có ưu điểm chính là không block lộn người dùng, bởi vì chúng ta không áp dụng việc block. Thay vào đó chúng ta cần phải tính toán resource phù hợp cho các client, và phân bố cho hợp lý, vì vậy không sợ block nhầm người dùng. Tuy nhiên chúng ta phải đối phó với bài toàn lớn hơn là performance tuning system. Phải cấu hình làm sao cho hợp lý bởi vì lúc này chúng ta cũng đã công nhận rằng nguồn tấn công cũng là người dùng bình thường. Cho nên cũng cần phục vụ như người dùng bình thường.
Và biện pháp cuối cùng đó chính là kết hợp cả hai cái trên lại. Và nó dĩ nhiên là hiệu quả hơn.
Với việc Anti WebHunter, mình chọn biện pháp thứ 2, đó chính là giới hạn resource. Thực ra đây không phải là biện pháp tốt nhất, tuy nhiên bởi vì system của mình thường xuyên bị tấn công với nhiều loại phương pháp khác nhau cho nên buộc mình phải chọn hình thức nào ngăn chặn không chỉ một mà phải có hiệu quả với nhiều phương pháp.
Cụ thể là sau khi tính toán xong số liệu hợp lý, mình điều chỉnh lại firewall và performance tuning system của mình. Theo đó những rules sau đây đang được áp dụng :
- Mỗi IP chi có thể mở một kết nối đến system trong một thời điểm, thực ra sau khi tính toán thì mình nhận ra 1 là đủ, lúc đầu mình giới hạn ở mức 4 nhưng sau đó chuyển xuống 1 và tiếp tục theo dõi, kết quả rằng điều đó không làm ảnh hưởn người dùng, người dùng load vẫn nhanh và ổn định. => không cần nhiều hơn 1.
- Gia tăng thời gian keepalive lên, bởi vì một khi dùng ít kết nối thì cần gia tăng keepalive để việc truyền tải được trơn tru hơn.
- Áp dụng việc cache hợp lý, cache lại những thứ có thể cache, system của mình chủ yếu là trang tin, nội dung dữ liệu chỉ đọc cho nên có thể nói cache là một biện pháp performance tuning rất hiệu quả.
- Không giới hạn thời gian mở connection, bởi vì chỉ mở một kết nối thì có nghĩa là dù nhận được nhiều gói tin nữa thì cũng sẽ bị drop bởi kernel chứ không có kết nối nào được mở.
- Cuối cùng là một khi đã áp dụng những hình thức bên trên thì không cần block IP làm gì nữa, cứ để thoải mái. Dĩ nhiên là mình cũng có áp dụng việc block với syn flood, nhưng trong topic này chỉ nói về WebHunter cho nên mình không đề cập các hình thức khác.
Nói tóm lại, trong bài viết trên của mình chỉ là cách nhìn nhận và giải quyết ván đề của mình, cũng với cách nhìn nhận đó có thể có bạn khác đưa ra hình thức tốt hơn.
- XHACKER -
Nhìn chung với DDoS chúng ta có 2 action cơ bản trong việc hạn chế (sau khi nhận ra được hình thức)
- Thứ nhất là block IP
- Thứ 2 là limit resource.
Block IP có được ưu điểm lớn đó là chặn luôn nguồn tấn công vào, điều này sẽ hạn chế được sự thất thoát tài nguyên, dĩ nhiên rồi vì mục tiêu của anti DDoS là hạn chế sự thất thoát tài nguyên, tuy nhiên bên cạnh đó chúng ta phải đối phó với bài toán khác đó chính là làm sao để lọc một cách cụ thể và chi tiết để không block lộn người dùng hợp lệ. Đây là vấn đề rất quan trọng đấy, nhưng không thảo luận ở đây.
Với cách thứ 2 là limit resource có ưu điểm chính là không block lộn người dùng, bởi vì chúng ta không áp dụng việc block. Thay vào đó chúng ta cần phải tính toán resource phù hợp cho các client, và phân bố cho hợp lý, vì vậy không sợ block nhầm người dùng. Tuy nhiên chúng ta phải đối phó với bài toàn lớn hơn là performance tuning system. Phải cấu hình làm sao cho hợp lý bởi vì lúc này chúng ta cũng đã công nhận rằng nguồn tấn công cũng là người dùng bình thường. Cho nên cũng cần phục vụ như người dùng bình thường.
Và biện pháp cuối cùng đó chính là kết hợp cả hai cái trên lại. Và nó dĩ nhiên là hiệu quả hơn.
Với việc Anti WebHunter, mình chọn biện pháp thứ 2, đó chính là giới hạn resource. Thực ra đây không phải là biện pháp tốt nhất, tuy nhiên bởi vì system của mình thường xuyên bị tấn công với nhiều loại phương pháp khác nhau cho nên buộc mình phải chọn hình thức nào ngăn chặn không chỉ một mà phải có hiệu quả với nhiều phương pháp.
Cụ thể là sau khi tính toán xong số liệu hợp lý, mình điều chỉnh lại firewall và performance tuning system của mình. Theo đó những rules sau đây đang được áp dụng :
- Mỗi IP chi có thể mở một kết nối đến system trong một thời điểm, thực ra sau khi tính toán thì mình nhận ra 1 là đủ, lúc đầu mình giới hạn ở mức 4 nhưng sau đó chuyển xuống 1 và tiếp tục theo dõi, kết quả rằng điều đó không làm ảnh hưởn người dùng, người dùng load vẫn nhanh và ổn định. => không cần nhiều hơn 1.
- Gia tăng thời gian keepalive lên, bởi vì một khi dùng ít kết nối thì cần gia tăng keepalive để việc truyền tải được trơn tru hơn.
- Áp dụng việc cache hợp lý, cache lại những thứ có thể cache, system của mình chủ yếu là trang tin, nội dung dữ liệu chỉ đọc cho nên có thể nói cache là một biện pháp performance tuning rất hiệu quả.
- Không giới hạn thời gian mở connection, bởi vì chỉ mở một kết nối thì có nghĩa là dù nhận được nhiều gói tin nữa thì cũng sẽ bị drop bởi kernel chứ không có kết nối nào được mở.
- Cuối cùng là một khi đã áp dụng những hình thức bên trên thì không cần block IP làm gì nữa, cứ để thoải mái. Dĩ nhiên là mình cũng có áp dụng việc block với syn flood, nhưng trong topic này chỉ nói về WebHunter cho nên mình không đề cập các hình thức khác.
Nói tóm lại, trong bài viết trên của mình chỉ là cách nhìn nhận và giải quyết ván đề của mình, cũng với cách nhìn nhận đó có thể có bạn khác đưa ra hình thức tốt hơn.
- XHACKER -
Xem Thêm
[TUT] Anti DDoS - WebHunter - Phần 2
2. WebHunter
Với WebHunter, mình từng bị WebHunter tấn công, lúc bị tấn công system của mình đang sử dụng Litespeed Free, với limit connection ở mức 2000 (quá ít đúng không :">), và thực sự lúc đó mình cũng không sử dụng firewall vì đang trong quá trình config mà thôi. Vài nhận xét mà mình thu thập được về hìn thức tấn công của WebHunter
- WebHunter tấn công không làm full bandwidth của system của mình, điều này được chứng minh thông qua việc mình không thể kết nối port 80 lúc đó nhưng những port khác mình vào bình thườg, và quan trọng hơn là bw mình đo trong system thông qua công cụ bwm-ng không cao, khoảng tầm 3MByte/s, dưới rất nhiều so với mức giới hạn bandwidth.
- Từ đây chúng ta có thể suy ra rằng, mục tiêu của WebHunter không phải là Bw của system mà là giới hạn connection của webserver và sự đứt gãy liên kết giữa Web server và back-end. Một kiểu tấn công điển hình vào trong CPU/RAM.
Với WebHunter, mình từng bị WebHunter tấn công, lúc bị tấn công system của mình đang sử dụng Litespeed Free, với limit connection ở mức 2000 (quá ít đúng không :">), và thực sự lúc đó mình cũng không sử dụng firewall vì đang trong quá trình config mà thôi. Vài nhận xét mà mình thu thập được về hìn thức tấn công của WebHunter
- WebHunter tấn công không làm full bandwidth của system của mình, điều này được chứng minh thông qua việc mình không thể kết nối port 80 lúc đó nhưng những port khác mình vào bình thườg, và quan trọng hơn là bw mình đo trong system thông qua công cụ bwm-ng không cao, khoảng tầm 3MByte/s, dưới rất nhiều so với mức giới hạn bandwidth.
- Từ đây chúng ta có thể suy ra rằng, mục tiêu của WebHunter không phải là Bw của system mà là giới hạn connection của webserver và sự đứt gãy liên kết giữa Web server và back-end. Một kiểu tấn công điển hình vào trong CPU/RAM.
Xem Thêm
[TUT] Anti DDoS - WebHunter - Phần 1
1. Mọi thứ bắt đầu từ những việc đơn giản.
Chúng ta cùng xem lại định nghĩ DoS/DDoS là gì và phân tích bản chất của nó. Thực ra DoS/DDoS đều có một mục tiêu chung là làm cho victim phải mất khả năng phục vụ. Mà muốn victim không còn khả năng phục vụ thì có nghĩa rằng sẽ phải làm cho victim cạn kiệt tài nguyên (resource). Vậy resource ở đây bao gồm gì ?? Chúng ta có thể thấy resource ở đây là :
- CPU/RAM/HDD
- Bandwidth
Trong hai dạng resource trên thì dạng quan trọng hơn chính là Bandwidth, bởi vì với phương pháp tấn công vào trong CPU/RAM/HDD chúng ta có thể dễ dàng anti được, bởi lúc này vấn đề sẽ quay lại với việc làm sao performance tuning cho system. Bởi nếu giả sử như việc attack không diễn ra, nhưng tăng lượng người xem binh thường lên thì chúng ta cũng buộc phải performance tuning cho hệ thống. Có lẽ vì điểm này cho nên người ta thường nói với DDoS, việc đầu tư vào trong cơ sỡ hạ tầng là việc quan trọng hàng đầu.
Ngược lại với những hình thức tấn công vào trong Bandwidth thì không đơn giản, bởi vì hiện nay Bandwidth vẫn là một resource đắt đỏ và quan trọng, không rộng rãi và thoải mái như các resource kia. Cho nên theo ý kiến cá nhân thì việc attack vào trong bandwidth vẫn nguy hiểm hơn, giả sủa các bạn có thể có những rules hợp lý, có thể xử lý tốt, các bạn nhận ra được hình thức tấn công nhưng nếu như bandwidth không đủ thì việc người dùng truy cập cũng không thực hiện được.
- XHACKER-
Chúng ta cùng xem lại định nghĩ DoS/DDoS là gì và phân tích bản chất của nó. Thực ra DoS/DDoS đều có một mục tiêu chung là làm cho victim phải mất khả năng phục vụ. Mà muốn victim không còn khả năng phục vụ thì có nghĩa rằng sẽ phải làm cho victim cạn kiệt tài nguyên (resource). Vậy resource ở đây bao gồm gì ?? Chúng ta có thể thấy resource ở đây là :
- CPU/RAM/HDD
- Bandwidth
Trong hai dạng resource trên thì dạng quan trọng hơn chính là Bandwidth, bởi vì với phương pháp tấn công vào trong CPU/RAM/HDD chúng ta có thể dễ dàng anti được, bởi lúc này vấn đề sẽ quay lại với việc làm sao performance tuning cho system. Bởi nếu giả sử như việc attack không diễn ra, nhưng tăng lượng người xem binh thường lên thì chúng ta cũng buộc phải performance tuning cho hệ thống. Có lẽ vì điểm này cho nên người ta thường nói với DDoS, việc đầu tư vào trong cơ sỡ hạ tầng là việc quan trọng hàng đầu.
Ngược lại với những hình thức tấn công vào trong Bandwidth thì không đơn giản, bởi vì hiện nay Bandwidth vẫn là một resource đắt đỏ và quan trọng, không rộng rãi và thoải mái như các resource kia. Cho nên theo ý kiến cá nhân thì việc attack vào trong bandwidth vẫn nguy hiểm hơn, giả sủa các bạn có thể có những rules hợp lý, có thể xử lý tốt, các bạn nhận ra được hình thức tấn công nhưng nếu như bandwidth không đủ thì việc người dùng truy cập cũng không thực hiện được.
- XHACKER-
