Hacked by Dr. CruZz


Status
Not open for further replies.
siap siapa aja didatengin terus oleh dr.cruzz sampai sekuriti server mu mengalami perbaikan. Kalau mau diambil positifnya, hack yang dilakukan dr.cruzz tidak parah-parah amat, dengan melakukan upgrade web, masalahnya akan selesai dan dari sini bisa ditarik pelajaran penting mengenai sekuriti server.
 
iya.... baca tulisan br0 @dracoola mesti pelan-pelan.

Tapi jika melihat dari awal tulisan br0 @dracoola..... dan memperhatikan satu-satu, bahwa br0 @dracoola menyenangi keindahan - tersimpan kelembutan yang tinggi - romantis - memiliki skill yang bagus - berbakat sebagai seorang diplomat - tersimpan semangat yang tinggi.
he2x... he... he.... apakabar br0 @dracoola , semoga kabar di baik ya.
 
siap siapa aja didatengin terus oleh dr.cruzz sampai sekuriti server mu mengalami perbaikan. Kalau mau diambil positifnya, hack yang dilakukan dr.cruzz tidak parah-parah amat, dengan melakukan upgrade web, masalahnya akan selesai dan dari sini bisa ditarik pelajaran penting mengenai sekuriti server.

perlu diketahui , yg namanya upgraded web ini ga akan menyelesaikan masalah mengenai hacking its just a temporary maybe , karena software ini seperti elektronik tiap hari semakin berkembang dan berkembang varian2 nya , apa dari sana justru yg no 1 si hacker bisa masuk ? tidak ... justru itu secondary hole dari sisi memanfaatkan kelemahan sisi firewall server dan menjadikan itu sebagai methode yg dipakai buat melumpuhkan server melalui hole scripting , karena jika server nya benar2 secure maka andai si hacker masuk lewat hole scripting pun ga akan bisa mengeksekusi , walau di denied dr mod sec misal untuk path uri , body , atau header dsb , si hacker dengan mudah make prefix lain buat masukin file nya yg penting ga kena mod sec .

saya nda copas tuntas intinya begini config php dalam cpanel dsb ini make lib yg bs diset macem2 buat disabled2 nya , dan itu sangat mudah di bypass php.ini nya ketika sudah dibuat di user acc tersebut maka semua function yg anda set disabled di main server akan terganti dengan internal loader php.ini dan yg lib td sudah ga jalan sama sekali , mod sec / suhosin / disabled function / => ini sudah ga berfungsi :) , jadi sesecure2 nya server anda dan di update ratusan kli sekalipun jika sudah kena bagian ini nah disinilah masalahnya .

entah dr php / cpanel / apache mungkin yg harus patch masalah ini .
 
perlu diketahui , yg namanya upgraded web ini ga akan menyelesaikan masalah mengenai hacking its just a temporary maybe , karena software ini seperti elektronik tiap hari semakin berkembang dan berkembang varian2 nya , apa dari sana justru yg no 1 si hacker bisa masuk ? tidak ... justru itu secondary hole dari sisi memanfaatkan kelemahan sisi firewall server dan menjadikan itu sebagai methode yg dipakai buat melumpuhkan server melalui hole scripting , karena jika server nya benar2 secure maka andai si hacker masuk lewat hole scripting pun ga akan bisa mengeksekusi , walau di denied dr mod sec misal untuk path uri , body , atau header dsb , si hacker dengan mudah make prefix lain buat masukin file nya yg penting ga kena mod sec .

saya nda copas tuntas intinya begini config php dalam cpanel dsb ini make lib yg bs diset macem2 buat disabled2 nya , dan itu sangat mudah di bypass php.ini nya ketika sudah dibuat di user acc tersebut maka semua function yg anda set disabled di main server akan terganti dengan internal loader php.ini dan yg lib td sudah ga jalan sama sekali , mod sec / suhosin / disabled function / => ini sudah ga berfungsi :) , jadi sesecure2 nya server anda dan di update ratusan kli sekalipun jika sudah kena bagian ini nah disinilah masalahnya .

entah dr php / cpanel / apache mungkin yg harus patch masalah ini .

om vishual dari kasus tersebut, jika php.ini kita paksa dan user tidak diberi ijin untuk merubah variable php.ini sendiri apakah tersebut dapat mengatasi masalah ?
 
siap siapa aja didatengin terus oleh dr.cruzz sampai sekuriti server mu mengalami perbaikan. Kalau mau diambil positifnya, hack yang dilakukan dr.cruzz tidak parah-parah amat, dengan melakukan upgrade web, masalahnya akan selesai dan dari sini bisa ditarik pelajaran penting mengenai sekuriti server.

bagaimana jika si hacker sudah terlanjur menanam backdoor ?
 
om vishual dari kasus tersebut, jika php.ini kita paksa dan user tidak diberi ijin untuk merubah variable php.ini sendiri apakah tersebut dapat mengatasi masalah ?

90% bisa dengan melakukan forcing php.ini dan locking , 10% ini kemungkinan hole masih ada

tapi masalah yg akan timbul di kemudian hari adalah banyak script yg error misal butuh require function yg ternyata sudah di lock dr php server dan jika ada user yg butuh misal untuk enabled / disabledkan fungsi tersebut .
 
90% bisa dengan melakukan forcing php.ini dan locking , 10% ini kemungkinan hole masih ada

tapi masalah yg akan timbul di kemudian hari adalah banyak script yg error misal butuh require function yg ternyata sudah di lock dr php server dan jika ada user yg butuh misal untuk enabled / disabledkan fungsi tersebut .

untuk suPHP saya pernah mencoba user tertentu dikecualikan php.ini nya mas, hanya saja php.ini tersebut bukan di public_html yang dapat dijangkau oleh user, meski php.ini tersebut pengecualian tetapi tetap hoster sendiri yang mengesetnya.
Kami pernah menggunakan methode seperti ini dan tetap bisa mengisolasi client.
http://arunramabalan.blog.com/2011/...-suphp-restricting-who-can-use-php-ini-files/
dikasus tersebut misal php.ini berada di /usr/local/lib/php.ini << untuk umum, sedang untuk user "khusus" dibuatkan /usr/local/lib/php-user1.ini

di suphp_config.conf user tertentu tersebut dipaksa dengan konfigurasi :
suPHP_ConfigPath /usr/local/lib/php-user1.php

CMIIW
 
untuk suPHP saya pernah mencoba user tertentu dikecualikan php.ini nya mas, hanya saja php.ini tersebut bukan di public_html yang dapat dijangkau oleh user, meski php.ini tersebut pengecualian tetapi tetap hoster sendiri yang mengesetnya.
Kami pernah menggunakan methode seperti ini dan tetap bisa mengisolasi client.
http://arunramabalan.blog.com/2011/...-suphp-restricting-who-can-use-php-ini-files/
dikasus tersebut misal php.ini berada di /usr/local/lib/php.ini << untuk umum, sedang untuk user "khusus" dibuatkan /usr/local/lib/php-user1.ini

di suphp_config.conf user tertentu tersebut dipaksa dengan konfigurasi :
suPHP_ConfigPath /usr/local/lib/php-user1.php

CMIIW

berarti ini harus manual editing ya via dari kita , dan bukan dr klien yg setting kan mas . jika misal ada 50 user yg minta buat php.ini berarti harus buat manual 50 config td benar begitu ya
 
berarti ini harus manual editing ya via dari kita , dan bukan dr klien yg setting kan mas . jika misal ada 50 user yg minta buat php.ini berarti harus buat manual 50 config td benar begitu ya

iya pastinya mas, tapi kan diantara 50 tersebut bisa jadi minta konfigurasi php nya sama mas, jadi bisa digabungkan saja php-user.ini nya,
 
trus solusi pencegahannya gimana? mungkin alangkah bagusnya jika para hoster berpengalaman ikut membagikan tips keamanan server mereka. jadi diskusinya bisa menambah wawasan baru. meski memang tidak pernah ada yang namanya aman 100%
 
Status
Not open for further replies.
Back
Top