Mohon tunggu...
Mboi Coy
Mboi Coy Mohon Tunggu... -

:)

Selanjutnya

Tutup

Inovasi

Investigasi Sistem Linux yang Terinfeksi Trojan

15 Januari 2010   08:00 Diperbarui: 26 Juni 2015   18:27 421
+
Laporkan Konten
Laporkan Akun
Kompasiana adalah platform blog. Konten ini menjadi tanggung jawab bloger dan tidak mewakili pandangan redaksi Kompas.
Lihat foto
Bagikan ide kreativitasmu dalam bentuk konten di Kompasiana | Sumber gambar: Freepik

Berawal dari telepon tak terangkat di tengah malam oleh bos, meskipun dipagi hari baru mengetahuinya dari history call-nya tetapi belum diketahui juga error yang terjadi semalam. Sesampainya dikantor saya mendapatkan laporan bahwa telah terjadi error di server-server kantor, dan dugaan awal yaitu masalah di router. Menurut laporan orang yang piket semalam bahwa error terjadi di tengah malam dan error tersebut benar dengan sendirinya walaupun belum ada aksi apapun dari mereka. Dari pagi sampai sore server-server terlihat normal dan kami menduga ini hanya anomali biasa saja, sehingga saya tidak melakukan investigasi lebih dalam terhadap masalah tersebut, melainkan teman saya yang sebagai network engineer yang melakukan review terhadap log-log di tools monitoringnya. Sekitar jam 8an ternyata masalah tadi terjadi lagi. langkah pertama yang saya lakukan adalah mencari tahu sejauh mana efek anomali ini terhadap server-server yang lain. Saya coba ping dan ada beberapa server yang merespon dan sebagian lagi timeout. Setengah jam berlalu dan kita masih belum mengetahui penyebab dari error ini, dan web tetap down. Teman saya yang orang network memberitahu kalau masalah terletak di firewall yang disebabkan oleh adanya transaksi paket yang sangat besar. dari clue yang pertama ini saya dan teman sesama sysadmin mulai menyisir semua server yang mengalami lonjakan dari sisi networknya. [caption id="attachment_53333" align="alignnone" width="300" caption="Network Server Load "][/caption] Dan ketemu. Terjadi lonjakan tertinggi di server repositori. Dugaan awal kita yaitu ada yang mengakses file-file repositori kami secara massal. Dan yang saya lakukan adalah menghapus folder-folder repositori dari httpd.conf, tanpa mematikan service httpd itu sendiri. Ternyata masalah tidak terselesaikan. Saya coba perintah # top untuk melihat proses apa yang paling banyak memakan resource, dan ternyata ada aplikasi std yang menggunakan lebih dari 90% penggunaan cpu. Akhirnya saya matikan proses tersebut dengan perintah # kill -9 *PID*, tak lama kemudian load network server kembali normal berikut juga dengan server-server yang lainnya. Tetapi tak lama kemudian masalahnya terjadi kembali. Kali ini saya coba mencari tahu lebih detail mengenai aplikasi std tadi. Saya lakukan dengan perintah # ps axjf untuk melihat detail dari setiap proses yang sedang berjalan pada saat itu. Hasilnya seperti berikut: [caption id="attachment_53320" align="aligncenter" width="500" caption="# ps axjf"][/caption] Dari outputnya tersebut terlihat ada ip publik yang pada mulanya kita mengira bahwa ip tersebut adalah ip penyerang, sehingga kita melakukan bloking ip tersebut di rule firewall. Tetapi ternyata langkah tersebut tidak berpengaruh sama sekali. Lalu kita mulai melakukan investigasi dari sisi lainnya, yaitu kita mulai dengan mencari lokasi aplikasi std tersebut. Pada awalnya saya sempat terkecoh dengan perintah ./std tersebut, saya pikir lokasi aplikasi std ada pada direktori '/'. Dan ternyata aplikasinya tidak ada disana, saya coba dengan perintah # whereis std dengan harapan file ini ada di direktori default untuk penyimpanan file-file binary dan file-file pendukungnya. Dan perintah # whereis tidak menghasilkan apapun. Akhirnya saya coba dengan perintah # locate std | less. Dan ketemu!. bersambung ke bagian kedua

Mohon tunggu...

Lihat Inovasi Selengkapnya
Beri Komentar
Berkomentarlah secara bijaksana dan bertanggung jawab. Komentar sepenuhnya menjadi tanggung jawab komentator seperti diatur dalam UU ITE

Belum ada komentar. Jadilah yang pertama untuk memberikan komentar!
LAPORKAN KONTEN
Alasan
Laporkan Konten
Laporkan Akun