1.(Nguồn cuasotinhoc)
Sau đây là phương pháp CuaSoTinHoc sử dụng hạn chế DDOS:
Trước tiên cần xác định rằng các phương pháp chống DDOS bằng các loại ngôn ngữ trên server như PHP, ASP, Java, C#... đều mang lại hiệu xuất không cao lắm, bởi vì hầu hết các ngôn ngữ cài trên server nêu trên đều đòi hỏi lượng tài nguyên (resource) server khá lớn để xử lý các câu lệnh.
CuaSoTinHoc sử dụng phương pháp hạn chế DDOS khá đơn giản không sử dụng ngôn ngữ PHP và không cần yêu cầu các website phải sở hữu server với quyền root. Cách mà chúng ta dùng chỉ đơn thuần là kết hợp cách cấu hình file .htaccess trên hosting và một đọan javascipt nhỏ.
-------------------------
- Cấu hình file .htaccess -
-------------------------
Code:
Options +FollowSymlinks RewriteEngine on RewriteCond %{HTTP_REFERER} !^http(s)?://(www\.)?cuasotinhoc.com [NC] RewriteRule ^(.*).(php|html|asp|htm) antiddos.htm [NC]
-------------------------
Đọan code trên giúp hệ thống chỉ xử lý những links được giới thiệu (referer) từ cuasotinhoc.com, có nghĩa là khi có một link được gõ trực tiếp vào từ browser hoặc từ một chương trình DDOS hoặc từ một domain khác, thì hệ thống sẽ không xử lý theo cách thông thường nữa mà sẽ đưa về một trang xử lý chuyên biệt, ở đây đó là trang antiddos.htm.
Dòng 1: có nghĩa là nối tiếp đường dẫn.
Dòng 2: bật động cơ ghi lại để phục vụ việc xác định referer.
Dòng 3: qui định referer từ cuasotinhoc.com.
Dòng 4: luật đưa về file antiddos.htm.
----------------------------
- Cấu hình file antiddos.htm -
----------------------------
Trong file antiddos.htm chúng ta sẽ dùng một đọan Javascript nhỏ để xuất dòng:
[Click vao day de xem noi dung]
(Neu khong duoc thi nhan Shift + Click vao link)
File antiddos.js được code như sau:
Code:
var currUrl = this.document.URL; var newUrl = currUrl.replace('#','?'); var re=/CODE/ var chk=re.test(currUrl); if (chk==1) { this.document.write(""); } else { this.document.write(""); }
Trong lúc thử nghiệm phương pháp chóng DDOS này BQT phát hiện rằng khả năng xác nhận referer của hosting chưa được hiệu quả lắm (chưa xác định được nguyên nhân), nến nếu ta cho xuất dòng link y chang link gốc thì có khi server không hiểu là referer, dẫn đến trường hợp cứ "click vào đây..." mãi
Do đó BQT CuaSoTinHoc nảy sinh một sáng kiến nhỏ là thêm các ký tự vô hại đằng sau các link như '?', '&" để đánh dấu cho server biết có sự đổi mới ở các link trên. Và kết quả họat động của cách này khá tốt.
--------------------------------------
Như vậy với cách cấu hình .htaccess và javascript như trên chúng ta hạn chế được phần lớn các chương trình Flash DDOS thông thường tấn công vào MySQL, và với cách này tài nguyên hệ thống được sử dụng rất ít, bởi ngôn ngữ trong .htaccess là ngôn ngữ trên server và đọan javacript trên là không lớn.
===============================================
Vẫn cần phải khẳng định rằng phương pháp này vẫn chỉ là tạm thời, và còn có lỗi, bằng chứng là khả năng quick edit trên Firefox không sử dụng được bỡi "tác dụng" của referer. CuaSoTinHoc share phương pháp hạn chế DDOS này để cùng các bạn trao đổi và phát triển nó tốt hơn.
Trước mắt có 2 vấn đề cần phát triển:
1. Làm sao cho server họat động thực sự hiệu quả chức năng referer. Để chúng ta khỏi phải thêm các ký tự vô bổ như "?","&" để làm mới link.
2. Cần phải nghiên cứu một phương pháp chống DDOS khác mà không cần phải đưa ra một trang antiddos.htm đầy phản cảm.
Mong các bạn đóng góp ý kiến!
Share code chống DDos của a2toiyeu.com
Bác đã có lòng share thì em cũng share luôn cái nì cho nó tiện.
Phương pháp sử dụng của em cũng khá giống với bác có khác một tí:
File .htaccess:
Code:
RewriteEngine on RewriteCond %{HTTP_REFERER} !^http(s)?://(www\.)?domain.com [NC] RewriteRule \.(php|htm|html|asp)$ http://domain.com/firewall.phtml?%{REQUEST_URI} [QSA]
Tạo ở thư mục đầu tiên file firewall.phtml:
Code:
[Click vao day]
de den noi dung ban can xem'); ?>
File firewall.phtml họat động giống như firewal.htm của cuasotinhoc nhưng nó có vẻ xử lý chậm hơn một chút, bù lại nó không bao giờ bị "dính" lỗi lặp đi lặp lại link. Có điều file phtml vẫn tốn một tí tài nguyên, chỉ có lẽ là không lớn lắm để không đáng lo ngại.
Chỉ có một vấn đề nhỏ là khi truy cập vào file index.php?module=xxx thì file phtml xuất ra index.php&module=xxx gây lỗi, buộc lòng phải xài preg_replace để xử lý.
2. Dưới đây là một số phương pháp, phòng chống và hạn chế những tác hại do DDoS từ xFlash gây nên.
- Nếu bạn dùng Server Linux có sử dụng CPanel khi phát hiện ra có DDoS nếu bạn có quyền root ngay lập tức bạn hãy Suppend Site đang bị tấn công và cài Password tạm thời lên sau khi thao tác xong phần cài password cho folder hoặc site bị tấn công thì bạn có thể Unsuppend để tiếp tục theo dõi.
Tạo một file .htaccess đặt vào thư mục hoặc site đang bị Flood như sau:
.htaccess|
****************************
AuthUserFile /forum/.htpasswd
AuthGroupFile /dev/null
AuthName "Password Protected Area"
AuthType Basic
****************************
và tạo một file .htpasswd
****************************
@domain::@dGdK8ZQg/FjU
****************************
user và pass ở trên là : @domain:
Trên đây chỉ là ví dụ bạn có thể vào http://google.com và Search với từ khóa .htaccess Generator để tự tạo password theo ý muốn.
Bạn nên để password có ký tự @ phía trước và dấu : phía sau vì WinXP đã fix lổi cho nhập Password dạng URL http://userass@domain.com/, nếu có @ và : thì Attacker sẽ không thể vượt qua bằng cách nhập trực tiếp User và Pass bằng URL.
Sau đó công việc của bạn phải làm là lên một cấu hình Firewall phù hợp cho site của bạn.
.htaccess
************************************************** ******
RewriteEngine on
RewriteCond %{HTTP_REFERER} !^http(s)?://(www\.)?tenmienbitancong.com [NC]
RewriteRule \.(php|html|asp)$ http://sitefirewall.com [NC,R,L]
************************************************** ******
Với dòng Mod Rewrite trên bạn có thể chống tới 95% tác hại của DDoS gây nên từ xFlash. Nó giúp bạn ngăn cản sự nguy hại từ việc truy cập tự động của xFlash đến site của bạn.
Giải thích về cơ chế hoạt động: Máy chủ của bạn chạy mã lập trình của PHP, ASP, HTML khi một Attacker tấn công vào site bạn, cụ thể ví dụ như tấn công vào http://tenmienbitancong.com/ nó sẽ đọc file index.php lúc này Mod Rewrite sẽ hoạt động và Foward về http://sitefirewall.com sau đó từ http://sitefirewall.com bạn đặt một đoạn mã như sau:
Vao Web SIte
Nếu là khách truy cập thật thì họ sẽ Click vào "Vao Web SIte" để được truy cập vào site. Còn nếu vào "hiden xFlash" và nó sẽ không vào được. Bạn có thể nghiên cứu 1 số kiểu ModRewrite kết hợp với mã nguốn trên site của bạn để config site của bạn chống xFlash tốt hơn.
Với 2 cách trên bạn có thể yên tâm là site của bạn sẽ vượt qua được xFlash.
Còn về phương pháp phòng thì duy nhất chỉ có 1 phương pháp : truy cập vào địa chỉ http://macromedia.com/shockwave/down...h&promoid=BIOW và nâng cấp lên phiên bản "FLASH PLAYER" mới nhất bạn sẽ hoàn toàn yên tâm là bạn sẽ không còn bị là một Client hidden cho DDoS của xFlash. Và việc nâng cấp này là hoàn toàn miễn phí.
Nguyễn Thành Công
Nhận xét thêm:
DDOS việc chống thực tế không thể ? Chúng ta chỉ hạn chế nó đến mức thấp nhất có thể thôi, các phương pháp trên David điều đã thử điều không hiệu quả, nếu người DDOS là một tay cao thủ (DDOS Pro và mạnh).
.htaccess là cách đặt password cho Site phương pháp này khá hữu hiệu nếu pass và user đó không đến tay "người DDOS", DDOS hiện nay khá thông mình không như ngày xưa. Thường có kèm các Script auto v.v...
+ Nếu trong chờ vào IIS hay APACHE sử lý DDOS là điều không tưởng.
+ Nếu ở vị trí người sử dụng Host, Chúng ta chỉ có thể dùng các script để hạn chể DDOS đến mực thấp nhất có thể, dựa trên Mod Rewrite của APACHE.
+ Còn về XFLASH theo thông tin thì các bản Flash Player hiện nay điều là 9.0 nên hầu như phương pháp này không còn nữa.
================================================== ========
Còn về việc chống DDOS trên thực tế chỉ cầu mong vào các nhà quản lý Hosting. Nếu server mạnh, Line lớn thì ok cả. (nhưng cũng hiếm MS còn bị DDOS mém chết)
Hiện nay có nhiều dự án chống DDOS trên IIS (WINODWS) và APACHE (LINUX), trển windows thì chưa rõ thế nào nhưng David có tham gia phân tích hệ thông cho một dự án trên Linux và hướng phát triển là biên dịch là KERNEL của Linux cách thức sử lý các Request.
"Cách thức đơn giản là: Dự vào các Request gởi đến và số lượng Request giới hạn từ 1 IP, giới hạn Request trong một thời gian v.v...nếu nhiều quá số lượng quy định thì Drop hết và đóng các kết nối, sau đó mở lại kết nối v.v..."
Nói chung là cũng không đơn giản như lý thuyết, khi triển khai cũng gặp nhiều khó khăn !
Bài viết gộp từ nhiều nguồn.