Em đang gặp vấn đề về Flood SQL mong các anh giúp đỡ.
Cụ thể site em bị tấn công liên tục vào các file php & đã anti đc rồi
Tiếp theo lại bị flood vào SQL với connection lên đến 437 / s.
Hiện tại thì tình hình đã khả quan hơn.Nhưng như vậy ko có nghĩa là mình sẽ không bị attack nữa.Vậy nay em mong mọi người có thể đưa ra một giải pháp cho vấn đề attack flood vào SQL dạng này để em và các newbie cùng học hỏi.
Chúc mọi người vui vẻ ! 

Làm sao có thể flood vào SQL trực tiếp được?

Họ flood thế nào? SQL chạy bằng software gì? server chạy hệ điều hành nào?

PS: tôi dời bài này vào "Thảo luận bảo mật" vì nó không phải là chủ đề thâm nhập. 

Đó là điều em muốn hỏi .
Server : Unix
SQL : Apache version 1.3.39 

Em thấy nó có hiện tượng flood ,& chỉ những thứ liên quan tới database nhiều là bị chậm lại(Đứng luôn) trong khi hình ảnh & những thứ khác chạy bình thường(nhanh).
Sau khi kiểm tra log thấy : connection có cái tới 437/s =>ddos
Em kiểm tra tiếp thì thấy còn nhiều IP với mức độ connection rất lớn(không bình thường).
Theo em họ đã dùng tool nào đó để flood vào database,hoặc tạo các connection có thể hợp lệ hoặc ko tạo nhiều request tới server.
Với lại mấy ngày hôm nay bên server của em có một vài lỗi connfig em cũng chưa dám chắc rẳng mình bị ddos mà die.Vì thực sự những lần tưoớc bị ddos vào file php hoặc eating BW thì cũng ko tới nỗi nào.
Em đưa ra câu hỏi này để mong anh giải thích giùm nguyên tắc ,cách phòng chống cho tất cả mọi người.Vì trước giờ hầu như em để ý mọi người chỉ quan tâm tới ddos một cách chung chung,hoặc cũng chỉ là "em muốn học ddos...". 

Em mong anh có thể bỏ chút thởi gian để nói rõ cho mọi người về vấn đề flood vào SQL (Theo em nghĩ) chứ không phải mong anh dạy em đi ddos hay xin tool. 

SQL : Apache version 1.3.39  

P/S :Các câu hỏi của anh thường là để đánh giá lại kiến thức của người hỏi .Đôi khi nghĩ nó phiền phức nhưng thật ra thì nó lại có ích nhiều cho mọi người lắm.Cảm ơn anh.

 

Xin lỗi vì em nói không rõ ràng.
Thế này nhé :
Site của em nằm trên host thuộc hostvn.net
Chạy 1 forum vbb & 1 site nhạc xtremedia.
cPanel Version 11.15.0-RELEASE
cPanel Build 17802
Theme x3
Apache version 1.3.39 (Unix)
PHP version 4.4.7
MySQL version 4.1.22-standard
Architecture i686
Operating system Linux
Em muốn hỏi là có hay không flood vào mySQL.
Nếu có thì anti như thế nào. 

Em đc server reply all.Chứ em làm gì có quyền root trên server mà xem ? 

Có. Nếu cổng 3306 mặc định của mySQL mở toang thì có thể bị flood thẳng vào đó.

Anti: chỉnh trong my.conf để nó listen trên 127.0.0.1 hoặc dùng firewall để cản access đến cổng 3306 từ bên ngoài vào.  

Dạ em thưa anh là Hostvn.net thuê trực tiếp server tại theplanet.com , còn bên đó có 2 người control server trực tiếp và em chat suốt ngày chứ có thấy đi suốt đâu nhỉ ^^ , em chơi khá thân với 2 anh ý nên gần như vấn đề gì em cũng hỏi được . 

InV-Firewall nó như thế nào thế cậu ? 

InV-Firewall Script là một firewall của tác giả Nguyen Tuan Dung, lập trình dành riêng cho hệ thống forum Invision Power Board [cũng có thể tích hợp và forum khác dễ dàng]. Tính năng của hệ thống tường lửa cho website này tập trung chính ở việc cản trở một phần các gói dữ liệu được gửi liên tục hay yêu cầu truy cập đến diễn đàn với số lượng lớn trong thời gian ngắn. 

http://www.mediafire.com/?mtlz2zmjz1y

canh_nguyen wrote:

InV-Firewall nó như thế nào thế cậu ? 

Hosting Provider yêu cầu mình cài đặt thêm trình tường lửa vào, mình search thử thì http://sinhvienit.net/@forum/anti-ddos/7207-cai-dat-tuong-lua-inv-firewall-script-cho-dien-dan-ban-ipb-phpbb-vbulletin.html, có vấn đề gì sao bạn?

InV-Firewall Script là một firewall của tác giả Nguyen Tuan Dung, lập trình dành riêng cho hệ thống forum Invision Power Board [cũng có thể tích hợp và forum khác dễ dàng]. Tính năng của hệ thống tường lửa cho website này tập trung chính ở việc cản trở một phần các gói dữ liệu được gửi liên tục hay yêu cầu truy cập đến diễn đàn với số lượng lớn trong thời gian ngắn. 

Mình upload nó lên cho các bạn tham khảo đây
Code:

http://www.mediafire.com/?mtlz2zmjz1y

 

Add below:
$firewall = ROOT_PATH.'firewall/firewall.php';
if( file_exists($firewall) ){ require_once($firewall); }

if( file_exists(ROOT_PATH.'firewall/firewall.php') ){ require_once(ROOT_PATH.'firewall/firewall.php'); }

Thế nào là flood SQL?

Flood SQL có 2 dạng:
 

b.1 Dạng caching bên ngoài: Caching bên ngoài là caching không ở biên độ web application mà ở biên độ một dịch vụ bên ngoài web application. Loại caching này thường trông cậy vào một dạng reverse proxy (apache, squid, application content filtering system.... ). Loại này đứng giữa trình duyệt và web application:

Trình duyệt <---> forward proxy (nếu có - như VNPT của VN) <----> reverse proxy <----> web server <----> web app <----> CSDL.

Hệ thống wiki nổi tiếng là một điển hình cho dạng này. Dùng reverse proxy để cache thông tin, đặc biệt là thông tin cho dymamic html dễ mà khó. Dễ ở chỗ nó có thể cache bất cứ thứ gì nhưng khó ở chỗ nếu dynamic html được tạo ra cho nhiều session khác nhau mà không kiểm soát kỹ thì bị lỗ hổng bảo mật. 

conmale wrote:

Thế nào là flood SQL?

Flood SQL có 2 dạng:
 

Hì, hình như anh chưa định nghĩa "flood SQL" là gì đã đi vào phân dạng nó rồi! Theo em hiểu, flood SQL là hình thức tấn công bằng cách gửi thật nhiều yêu cầu truy vấn SQL đến database server đến nỗi database server không thể response được các yêu cầu hợp lệ khác.
 

conmale wrote:

b.1 Dạng caching bên ngoài: Caching bên ngoài là caching không ở biên độ web application mà ở biên độ một dịch vụ bên ngoài web application. Loại caching này thường trông cậy vào một dạng reverse proxy (apache, squid, application content filtering system.... ). Loại này đứng giữa trình duyệt và web application:

Trình duyệt <---> forward proxy (nếu có - như VNPT của VN) <----> reverse proxy <----> web server <----> web app <----> CSDL.

Hệ thống wiki nổi tiếng là một điển hình cho dạng này. Dùng reverse proxy để cache thông tin, đặc biệt là thông tin cho dymamic html dễ mà khó. Dễ ở chỗ nó có thể cache bất cứ thứ gì nhưng khó ở chỗ nếu dynamic html được tạo ra cho nhiều session khác nhau mà không kiểm soát kỹ thì bị lỗ hổng bảo mật. 

Anh giải thích giúp em thuật ngữ "dynamic html" với.
 

Flood SQL có hai dạng thì phải tách ra 2 dạng và định nghĩa 2 dạng đó chớ sao em? Sao em lại tách 1 dòng đó ra rồi cho rằng anh chưa định nghĩa mà lại phân loại? Không biết nó là loại gì thì làm sao định nghĩa? .
 

b.1 Dạng caching bên ngoài: Caching bên ngoài là caching không ở biên độ web application mà ở biên độ một dịch vụ bên ngoài web application. Loại caching này thường trông cậy vào một dạng reverse proxy (apache, squid, application content filtering system.... ). Loại này đứng giữa trình duyệt và web application:

Trình duyệt <---> forward proxy (nếu có - như VNPT của VN) <----> reverse proxy <----> web server <----> web app <----> CSDL.

Hệ thống wiki nổi tiếng là một điển hình cho dạng này. Dùng reverse proxy để cache thông tin, đặc biệt là thông tin cho dymamic html dễ mà khó. Dễ ở chỗ nó có thể cache bất cứ thứ gì nhưng khó ở chỗ nếu dynamic html được tạo ra cho nhiều session khác nhau mà không kiểm soát kỹ thì bị lỗ hổng bảo mật.
 

conmale wrote:

Flood SQL có hai dạng thì phải tách ra 2 dạng và định nghĩa 2 dạng đó chớ sao em? Sao em lại tách 1 dòng đó ra rồi cho rằng anh chưa định nghĩa mà lại phân loại? Không biết nó là loại gì thì làm sao định nghĩa? .
 

Thì ra anh phân dạng flood SQL rồi mới định nghĩa từng dạng của nó. Sao anh không đưa ra một định nghĩa chung cho tất cả các dạng flood SQL? Theo em, flood SQL là hình thức tấn công bằng cách gửi thật nhiều yêu cầu truy vấn SQL đến database server đến nỗi database server không thể response được các yêu cầu hợp lệ khác. Anh thấy định nghĩa của em về flood SQL như thế nào?
 

conmale wrote:

b.1 Dạng caching bên ngoài: Caching bên ngoài là caching không ở biên độ web application mà ở biên độ một dịch vụ bên ngoài web application. Loại caching này thường trông cậy vào một dạng reverse proxy (apache, squid, application content filtering system.... ). Loại này đứng giữa trình duyệt và web application:

Trình duyệt <---> forward proxy (nếu có - như VNPT của VN) <----> reverse proxy <----> web server <----> web app <----> CSDL.

Hệ thống wiki nổi tiếng là một điển hình cho dạng này. Dùng reverse proxy để cache thông tin, đặc biệt là thông tin cho dymamic html dễ mà khó. Dễ ở chỗ nó có thể cache bất cứ thứ gì nhưng khó ở chỗ nếu dynamic html được tạo ra cho nhiều session khác nhau mà không kiểm soát kỹ thì bị lỗ hổng bảo mật.
 

Cám ơn anh, em đã hiểu thuật ngữ "dynamic html" rồi. Như vậy, dù là dynamic html hay static html, cái mà người dùng nhận được cũng đều là html, hiểu theo nghĩa là chỉ có thể đọc thông tin nhận được mà không thể thay đổi. Người dùng không thể thay đổi tức là không tác động ngược lại server nhằm làm thay đổi "thái độ làm việc" của hệ thống thì sao gọi là "lỗ hổng bảo mật" được? Anh có thể đơn cử một vài lỗ hổng có thể có của việc "không kiểm soát kỹ việc tạo ra dynamic html cho từng session khác nhau"? 

Định nghĩa này tốt đó.
 

Hi!
Theo tớ Comale sử dụng thuật ngữ "dynamic html" và "static html" .. .chưa hợp lắm. Dynamic HTML dễ nhầm với DHTML (viết tắt), là 1 khái niệm với ý nghĩa khác: http://en.wikipedia.org/wiki/DHTML
Cái này ngược với Static HTML, cũng như thế.
Với 2 cái ý nghĩa tương tự như là Comale nói, thì nên được gọi là Dynamic Web Page, và Static Web Page. Xem http://en.wikipedia.org/wiki/Dynamic_web_page
Bài này nói về khái niệm, vì thế nên có ý kiến vậy. 

Đối với caching, nếu squid (hoặc bất cứ một ứng dụng caching nào khác) cache luôn cả thông tin liên quan đến việc "nhận diện" và "gán quyền" (đã nói ở trên) thì kẻ thứ nhì có thể truy cập vào tài nguyên của service y hệt như kẻ thứ nhất. Đây chính là lỗ hổng. Khía cạnh bảo mật này có thể khai triển ra nhiều điểm lý thú và đó là lý do tại sao cho đến ngày nay, XSS vẫn được ưa chuộng và vẫn lan tràn trên các ứng dụng web. 

conmale wrote:

Đối với caching, nếu squid (hoặc bất cứ một ứng dụng caching nào khác) cache luôn cả thông tin liên quan đến việc "nhận diện" và "gán quyền" (đã nói ở trên) thì kẻ thứ nhì có thể truy cập vào tài nguyên của service y hệt như kẻ thứ nhất. Đây chính là lỗ hổng. Khía cạnh bảo mật này có thể khai triển ra nhiều điểm lý thú và đó là lý do tại sao cho đến ngày nay, XSS vẫn được ưa chuộng và vẫn lan tràn trên các ứng dụng web. 

Anh có thể khai mở một ít để em có cơ sở khai triển tiếp?