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 . 

Vấn đề mà anh comale nói có đề cập đến rồi ! nhưng chưa được chi tiết và tỉ mĩ như anh conmale trình bày. Tiện đây cho em hỏi nếu người xâm nhập sử dụng socket stream để lẫy mã nguồn backdoor được mã hoá từ nơi khác chứ không chỉ gói gọn giao thức HTTP hay giao thức TCP/IP (có thể là UDP). 

Không phải em muốn xoáy người khác đâu, nhưng khi tranh luận một vấn đề thú vị như thế này khó mà ngừng lại được. Còn một vấn đề anh chưa đề cập tới là các kết nối UDP với kết nối UDP thì không có các flag như TCP. Và việc phân biệt ai kết nối tới ai cũng không được vì đây là kết nổi kiểu P-2-P. Vậy em xin hỏi một socket stream sử dụng UDP để lấy backdoor thì ngăn chặn thế nào. Việc ngăn chặn đó có ảnh hưởng tới các service được các server khác cung cấp như DNS và DHCP... hay không .

@conmale: Em cảm ơn phần giải đáp thoả đáng của anh trước đó. 

iptables -A OUTPUT -s <myip> -p tcp --SYN -d any/0 -j DROP
 

Site mình (sử dụng joomla) vừa bị một con back-door kid.php, vì nó đặt tên lạ và đặt ở ngoài root nên nhìn là biết ngay. Lỡ như nó đổi tên giống với các file trong hệ thống (như: error.php hay log_nt.php) và đặt trong một góc nào đó thì cũng khó mà tìm ra.

Nó sử dụng base64_decode(), vậy nếu chúng ta dùng cách search chuỗi "base64_decode" thì cũng có thể lọc được một số back-door dạng này, cách này thì ở trên đã có rồi, ngoài ra nó còn dùng gzinflate().

Vậy các bạn có thể search thêm chuỗi "gzinflate" trong source code để tìm kiếm back-door được hiệu quả hơn.

PS: có ai từng gặp backdoor kid.php này chưa vậy ? Trong source code có dòng chữ "Developed by [K]id" đó 

Tớ theo dõi chủ đề này và đã gần 30 bài thảo luận nhưng vẫn chưa thấy có ai đề cập đến khía cạnh nền tảng để ngăn chặn "back door".

Bất cứ một "back door" nào cũng cần có cơ chế truy cập đến nó và truy cập từ nó. Nói cụ thể hơn, một php dùng làm back door chẳng hạn có hai phía connections:
1. Từ trình duyệt của tin tặc đến php đó (client đến cổng 80/443 của dịch vụ web):
Trình duyệt:12345 ---> web server:80

2. Từ php đó (sau khi đã biến thành con php shell) ra ngoài để download, upload hoặc include một thứ gì khác (từ máy chủ của dịch vụ web đến một trang web hoặc một máy chủ khác).
web server:23456 ---> web server khác:80


Trong trường hợp thứ nhất, việc ngăn cản truy cập đến abc.php nào đó nếu biết trước thì không khó nhưng nếu đó là một file do tin tặc upload lên có một tên ngẫu nhiên hoặc thậm chí ẩn trong một file khác thì cực kỳ khó cản lọc. Đây là việc làm đòi hỏi sắp xếp và phòng chống trước khi xảy ra tình trạng bị upload "shell".

Trong trường hợp thứ nhì, việc ngăn cản máy chủ cung cấp dịch vụ web truy cập đến một trang web nào khác là việc cực kỳ đơn giản (nếu máy chủ có hệ thống tường lửa). Ví dụ, nếu dùng Linux và iptables thì 1 luật:
iptables -A OUTPUT -s <myip> -p tcp --SYN -d any/0 -j DROP
là xong. Máy chủ cung cấp dịch vụ web này không có cách nào tạo ra SYN để truy cập đến một trang khác. Bởi vậy, các phương pháp "INCLUDE" một file nào đó nằm ở một host khác là chuyện không thể xảy ra. Nếu như đụng đến việc "INCLUDE" một file nào khác trên cùng máy chủ và cũng "bị" upload cùng với "shell" thì biện pháp hoàn toàn khác (và hoàn toàn phụ thuộc vào việc sắp xếp và phòng chống ngay từ đầu).
 

Giải pháp của anh conmale rất hữu ích nếu mình làm chủ được máy chủ web, nhưng nếu trong trường hợp dùng shared host có lẽ không khả thi.

Theo mình có 2 trường hợp cho backdoor hoạt động:
1. (Tạm gọi là) Active:
- Client truy cập vào website, giúp đoạn code backdoor hoạt động, gửi thông tin về một máy chủ khác.

2. (Tạm gọi là) Passive:
- Hacker ghé thăm 2 website, kiểm tra xem website đó có bị "dính" backdoor của anh ta hay không? Sau đó thao tác gọi backdoor.

Với trường hợp 1, việc kiểm tra những request xuất phát từ webserver ra ngoài là việc cần thiết và hiệu quả.

Với trường hợp 2, kiểm tra mã nguồn khó khăn hơn rất nhiều. Có thể quét bằng antivirus nhưng bản thân Fal cũng chưa tìm hiểu xem các antivirus sẽ quét những gì trong mã nguồn để phát hiện backdoor, mức độ tin tưởng đến đâu?
 

về nguyên tắc thì quét bằng phần mềm diệt virut hoặc phần mềm phân tích mã nguồn sẽ không thể nào nhận biết được tất cả các loại backdoor. bạn nào tìm hiểu về lý thuyết tính toán sẽ thấy bài toán này tương tự như bài toán dừng (halting problem), là một bài toán không máy tính nào giải được.
 

PS: đây là một chủ đề mình nghĩ rất thích hợp cho http://tetcon.org. bạn nào có hứng thú muốn trình bày về đề tài này thì liên hệ với mình. mình sẵn sàng hỗ trợ về mặt định hướng, như đang làm ở đây. 

mrro wrote:

PS: đây là một chủ đề mình nghĩ rất thích hợp cho http://tetcon.org. bạn nào có hứng thú muốn trình bày về đề tài này thì liên hệ với mình. mình sẵn sàng hỗ trợ về mặt định hướng, như đang làm ở đây. 

Tớ rất có hứng thú tìm hiểu đến nơi đến chốn về vấn đề này. Có gì mrro và anh conmale giúp đỡ hỗ trợ thêm giúp em nhé! 

theo mình thì đơn giản là xem file log của server để xem từ client execute request ở đâu rồi lần ra. chứ 1 site có cả ngìn file thì việc tìm ra rất khó, đó là chưa tíh đến AVT có quét ra không nữa.  

Chỉ cần nắm khái niệm tổng quát nhất: backdoor là một phương pháp, cơ chế, phương tiện, ứng dụng nhằm qua mặt cơ chế xác thực để nắm lấy quyền điều khiển.

Backdoor trải dài từ tầng kernel đến những cái script đơn giản trên tầng ứng dụng.

Đó, sự "nhận biết" xoay quanh khái niệm trên . 

bạn ơi mình đang có cái đê tài như thế này :Hệ thống máy chủ lưu trữ dữ liệu của công ty đang hoạt động bình
thường, tuy nhiên có nghi vấn là hệ thống máy chủ đã bị tấn công, và
kẻ tấn công đã cài backdoor lại, đồng thời có thể đã lấy đi nhiều dữ
liệu. Công ty muốn xây dựng một giải pháp để hạn chế và tránh được
tối đa các hiểm hoạ tương tự trong tương lai. Hãy giải quyết vấn đề
hiện tại và đồng thời phân tích và thiết kế một giải pháp tổng thể để
đáp ứng được các yêu cầu kể trên.

bạn có tl nào gửi cho mình vs