Có cách nào search Shell nhanh gọn ngay trên host ko nhỉ ?? 

Có cách nào search Shell nhanh gọn ngay trên host ko nhỉ ?? 

disable_functions=show_source, system, shell_exec, passthru, exec, popen, proc_open, system_exec, escapeshellarg, escapeshellcmd, proc_close, ini_alter, parse_ini_file

onlinehack làm như host nào cũng chạy PHP  

Ừa, thì đúng là tụi nó là php, nhưng cũng nên bàn chung đến việc chống shell. Còn cái link bồ đưa coi bộ còn thô sơ lắm. 

Có cách nào search Shell nhanh gọn ngay trên host ko nhỉ ??  

cần hiểu sâu bản chất vấn đề

rc57 là cái chi và cách thức hoạt động của nó thế nào ?? vì sao nó có thể chu du khắp hệ thống mà không gặp trở ngại nào cả. Tức là làm tốt ở mức tổng quan cao nhất, thì khi đó cho dù upload shell tự viết đi chăng nữa thì cũng không có tác dụng phá hoại


Các đơn giản nhất chống shell là phân vùng ảnh hưởng, mỗi người 1 phòng , độc lập với nhau, khi đó phòng bên đầy sâu với khủng long thì cũng không ảnh hưởng đến hàng xóm bên canh. Cái đò phải đòi hỏi quyền hạn cao nhất root admin chứ member thì không fix được 

BachDuongTM wrote:

cần hiểu sâu bản chất vấn đề

rc57 là cái chi và cách thức hoạt động của nó thế nào ?? vì sao nó có thể chu du khắp hệ thống mà không gặp trở ngại nào cả. Tức là làm tốt ở mức tổng quan cao nhất, thì khi đó cho dù upload shell tự viết đi chăng nữa thì cũng không có tác dụng phá hoại


Các đơn giản nhất chống shell là phân vùng ảnh hưởng, mỗi người 1 phòng , độc lập với nhau, khi đó phòng bên đầy sâu với khủng long thì cũng không ảnh hưởng đến hàng xóm bên canh. Cái đò phải đòi hỏi quyền hạn cao nhất root admin chứ member thì không fix được 

Cậu viết tớ chả hiểu cái gì

Nói chung up được mà không cho quyền execute thì r57 hay r99 cũng thế thôi. Mà tốt nhất như tớ, trình độ không tới, không cho up!
 

mR.Bi wrote:

BachDuongTM wrote:

cần hiểu sâu bản chất vấn đề

rc57 là cái chi và cách thức hoạt động của nó thế nào ?? vì sao nó có thể chu du khắp hệ thống mà không gặp trở ngại nào cả. Tức là làm tốt ở mức tổng quan cao nhất, thì khi đó cho dù upload shell tự viết đi chăng nữa thì cũng không có tác dụng phá hoại


Các đơn giản nhất chống shell là phân vùng ảnh hưởng, mỗi người 1 phòng , độc lập với nhau, khi đó phòng bên đầy sâu với khủng long thì cũng không ảnh hưởng đến hàng xóm bên canh. Cái đò phải đòi hỏi quyền hạn cao nhất root admin chứ member thì không fix được 

Cậu viết tớ chả hiểu cái gì

Nói chung up được mà không cho quyền execute thì r57 hay r99 cũng thế thôi. Mà tốt nhất như tớ, trình độ không tới, không cho up!
 

---> jail apache. 

conmale wrote:

mR.Bi wrote:

BachDuongTM wrote:

cần hiểu sâu bản chất vấn đề

rc57 là cái chi và cách thức hoạt động của nó thế nào ?? vì sao nó có thể chu du khắp hệ thống mà không gặp trở ngại nào cả. Tức là làm tốt ở mức tổng quan cao nhất, thì khi đó cho dù upload shell tự viết đi chăng nữa thì cũng không có tác dụng phá hoại


Các đơn giản nhất chống shell là phân vùng ảnh hưởng, mỗi người 1 phòng , độc lập với nhau, khi đó phòng bên đầy sâu với khủng long thì cũng không ảnh hưởng đến hàng xóm bên canh. Cái đò phải đòi hỏi quyền hạn cao nhất root admin chứ member thì không fix được 

Cậu viết tớ chả hiểu cái gì

Nói chung up được mà không cho quyền execute thì r57 hay r99 cũng thế thôi. Mà tốt nhất như tớ, trình độ không tới, không cho up!
 

---> jail apache. 

apache là vì anh quen với *nix hoặc *BSD . Với IIS thì sao anh

có cách nào nhốt mức user thôi để tránh lãng phí ram anh 

apache là vì anh quen với *nix hoặc *BSD . Với IIS thì sao anh

có cách nào nhốt mức user thôi để tránh lãng phí ram anh 

BachDuongTM wrote:

apache là vì anh quen với *nix hoặc *BSD . Với IIS thì sao anh -:-) -:-)

có cách nào nhốt mức user thôi để tránh lãng phí ram anh 

Trên WINDOWS có NTFS, hãy dùng cái này để lock user vào riêng folder của nó.. không cho chui sang thằng khác.

IIS ( ver 6 trở lên) hoạt động theo worker process, mỗi WEBSITE được cung cấp 1 pool, và 1 user thuộc nhóm IIS_WPG, user này sẽ run pool được cung cấp. Nếu mỗi thư mục của 1 website được set đặc quyền chỉ do user đấy FULL Control thì nó chỉ quanh quẩn trong thư mục ấy. " cái này có tác dụng cho cả PHP và các ngôn ngữ khác run trên IIS.

Nếu học kỹ NTFS và IIS bạn sẽ thấy nó dễ protect SHELL hơn APACHE ( vì APACHE chạy toàn run với 1 user duy nhất là APACHE, giống như việc config IIS run chung 1 WP, chung 1 user là NETWORK SERVICE ( mặc định khi cài IIS).

//Đã nghiên cứu thằng này khá lâu, vì trước đây các SHARED Server, SHARED HOSTING bị dính ( 3 năm trước ) nó xóa sạch các index file của tất cả các site trong SERVER,.. làm mình phải mất công 1 ngày để restore lại gần 1000 sites.

Hiện tại mình kiểm tra hầu hết các cong ty HOSTING ở VIỆT NAM đều đang dính lỗi này mà chưa biết cách giải quyết ra sao.. cụ thể 99,99% SHARED WINDOWS SERVER của NHÂN HÒA bị dính.. , DIGI, MẮT BÃO, PA, GLTEC v..v.v.v

Cứ HP nào dùng CONTROL PANEL mà sử dụng WINDOWS FPT SERVER thì không cần kiểm tra cũng biết 100% là không fix được cái này... 

xevathethao wrote:

BachDuongTM wrote:

Việc fix website dạng này, mỗi site 1 user thay thế Network Service mặc định mình đã thử nghiệm, nhưng trường hợp Server có nhiều website thì trong trường hợp nào đó khi truy xuất website sẽ sinh lỗi pool ngay (stop pool website), có thể do quá tải bộ nhớ (cấp cho work process website này).
Về mặt logic thực chất vấn đề này là thay thế user riêng mỗi website có chức năng, quyền hạn gần như user Network service mặc định. Thế nhưng gặp trường hợp lỗi này khi đặt pool hoạt động ở user Network service lại thì website đó hoàn toàn bình thường.
Như vậy việc fix user này vẫn không hoàn toàn thay thế được User Network Service.

to: xevathethao
Không rõ bạn xevathethao có gặp trường hợp này và có cách xử lý không?

Thanks. 

Việc cấp phát pool cho mỗi website cũng chính là việc để bảo vệ tài nguyên cho website.. nếu cứ để chugn pool thì 1 site bị lỗi sẽ dẫn đến tất cả các site khác bị stop theo. nhất là việc ghi session kiểu InProc của ASP.NET.. sẽ bị destroy khi process bị kill.

Muốn hosting chất lượng cao.. thì với 8CPU 4GB MEM tốt nhất không nên quá 100 sites ( với trường hợp private pool). nếu chạy chung pool thi sẽ được nhiều hơn nhưng chất lượng không bảo đảm.

ps// mình chạy cơ chế này trên tất cả các Server của mình đều hoạt động tốt hầu như ít xảy ra lỗi về FULL memory.. vì các pool được thiết kế với kernel request cố định.. nên nếu site nào có lượng truy cập lớn ( DOS chẳng hạn ) sẽ tự động bị Stop pool, và giải phóng memory, cpu sau 1 khoảng thời gian nhất định nó sẽ tự động start lại. ( nếu chạy chung pool thì dám STOP vì STOP là chết hết.. )
Các HP ở việt nam cứ đua nhau cạnh tranh với package khủng.. nhưng thực tế thì không thể chạy nổi trên 1 con server 4 lõi được.