Rasa sakit menghapus perl rootkit

8

Jadi, kami meng-host hal server web geoservice di kantor.

Seseorang rupanya membobol kotak ini (mungkin melalui ftp atau ssh), dan menaruh semacam rootkit yang dikelola irc.

Sekarang saya mencoba untuk membersihkan semuanya, saya menemukan proses pid yang mencoba untuk terhubung melalui irc, tetapi saya tidak tahu siapa yang memohon proses (sudah terlihat dengan ps, pstree, lsof) Prosesnya adalah perl skrip yang dimiliki oleh pengguna www, tetapi ps aux | grep menampilkan path file palsu pada kolom terakhir.

Apakah ada cara lain untuk melacak pid itu dan menangkap penyerang?

Lupa menyebutkan: kernel 2.6.23, yang dapat dieksploitasi untuk menjadi root, tapi saya tidak bisa menyentuh mesin ini terlalu banyak, jadi saya tidak bisa memutakhirkan kernel

EDIT: lsof mungkin membantu:

lsof-p 9481
PERINTAH PID PENGGUNA FD TYPE PERANGKAT NAMA NODEss PER
9481 www cwd DIR 8,2 608 2 / ss
perl 9481 www rtd DIR 8,2 608 2 / ss
perl 9481 www txt REG 8,2 1168928 38385 / usr / bin / perl5.8.8ss
perl 9481 www mem REG 8,2 135348 23286 /lib64/ld-2.5.soss
perl 9481 www mem REG 8,2 103711 23295 /lib64/libnsl-2.5.soss
perl 9481 www mem REG 8,2 19112 23292 /lib64/libdl-2.5.soss
perl 9481 www mem REG 8,2 586243 23293 /lib64/libm-2.5.soss
perl 9481 www mem REG 8,2 27041 23291 /lib64/libcrypt-2.5.soss
perl 9481 www mem REG 8,2 14262 23307 /lib64/libutil-2.5.soss
perl 9481 www mem REG 8,2 128642 23303 /lib64/libpthread-2.5.soss
perl 9481 www mem REG 8,2 1602809 23289 / lib64 / libc -2.5.soss
perl 9481 www mem REG 8,2 19256 38662 /usr/lib64/perl5/5.8.8/x86_64-linux-threa d-multi / otomatis / IO / IO.soss
perl 9481 www mem REG 8,2 21328 38877 / usr/lib64/perl5/5.8.8/x86_64-linux-threa d-multi / auto / Socket / Socket.soss
perl 9481 www mem REG 8,2 52512 23298 /lib64/libnss_files-2.5.soss
perl 9481 www 0r FIFO 0,5 1068892 pipess
perl 9481 www 1w FIFO 0,5 1071920 pipess
perl 9481 www 2w FIFO 0,5 1068894 pipess
perl 9481 www 3u IPv4 130646198 TCP 192.168.90.7:60321->www.****.net:ircd (SYN_SENT)

paul.ago
sumber
2
Kecuali Anda memutakhirkan kernel, apa yang harus menghentikan peretas mengulangi peretasan segera setelah Anda menghapus rootkit? Mungkin ada modul kernel trojan yang menyembunyikan proses.
pjc50
ini terlihat sangat mirip dengan bot irc ddos ​​yang baru saja saya bersihkan dari vps saya: serverfault.com/questions/639699/…
Hayden Thring

Jawaban:

37

Jika saya bisa memberi Anda saran, itu adalah berhenti membuang-buang waktu Anda membersihkan. Buat gambar OS untuk hal-hal forensik untuk nanti, dan instal ulang server.

Maaf, ini satu-satunya cara aman untuk menyelesaikan masalah rootkit Anda.

Kemudian Anda dapat memeriksa gambar, untuk alasan tertentu, mengapa itu terjadi.

Dari pengalaman pribadi saya, saya melakukan ini, dan kemudian menemukan pengguna internal yang memiliki kunci SSH yang mengandung cacat openssl pada tahun 2008.

Saya harap, ini membersihkan semuanya.

Catatan:
Jika Anda akan ke gambar / backup server sebelum menginstal ulang, menjadi sangat berhati-hati, bagaimana Anda melakukan ini. Seperti yang dikatakan @dfranke, boot dari media tepercaya ke cadangan.

Anda seharusnya tidak terhubung ke komputer lain dari server yang di-root, karena rootkit yang hebat diketahui dapat menyebar melalui sesi tepercaya seperti SSH.

Arenstar
sumber
11
Saya sangat menyarankan saran ini. Anda telah menemukan satu rootkit, tetapi Anda sama sekali tidak tahu apa lagi yang telah dirusak oleh penyerang. Setelah di-root, selalu di-root. Boot dari media tepercaya, zero out the drive. Fdisk, format, instal ulang, doo dah, doo dah.
dfranke
Yah ... Paket root yang bagus berjalan di bawah kernel Anda .. Tidak ada kesempatan untuk menghapusnya, tanpa banyak upaya
Arenstar
4
+1 Untuk sistem produksi apa pun (sungguh, sistem apa pun) tidak ada alasan untuk dibersihkan. Bunuh dengan api dan bangun kembali.
phoebus
1
+1 untuk menginstal ulang. Rootkit mungkin kacau dengan binari atau kernel Anda dan segala sesuatu yang Anda lihat (jalur palsu, dll ...) mungkin asap keluar dari rootkit untuk menyembunyikan dirinya.
coredump
1
Oblig kutipan : "Saya katakan kita lepas landas dan nuke seluruh situs dari orbit. Ini satu-satunya cara untuk memastikan."
Charles Stewart
1

Baris perintah dapat diubah jika proses mengubah argv [0]. Mencobals -l /proc/[pid]/exe

Dari man 5 proc

file ini adalah tautan simbolis yang berisi pathname aktual dari perintah yang dieksekusi. Tautan simbolis ini dapat ditinjau secara normal; mencoba membukanya akan membuka executable. Anda bahkan dapat mengetik / proc / [angka] / exe untuk menjalankan salinan lain dari executable yang sama seperti yang sedang dijalankan oleh proses [angka]. Dalam proses multithreaded, isi tautan simbolik ini tidak tersedia jika utas utama telah berakhir

ps auxwf | less memberi Anda "tampilan hutan" dari proses yang dapat menunjukkan kepada Anda proses apa yang meluncurkan proses ini (kecuali rootkit menyembunyikannya, atau orang tua aplikasi telah keluar dan telah diperbaiki untuk init).

Ini sebagian besar bersifat akademis dan mungkin hanya waktu, tetapi strings -n 10 /proc/[pid]/memmungkin menyenangkan untuk menonton masa lalu gulir. Anda juga bisa echo 0x7 > /proc/[pid]/coredump_filterdan menggunakan gdb gcoreuntuk memaksa coredump dengan segala kemungkinan di dalamnya, tetapi kemudian proses itu mati, yang dapat menghalangi analisis lebih lanjut.

Tapi pasti terima saran Arenstar. Hanya mencadangkan data, memulihkan semua yang dapat dieksekusi dari cadangan, dan memulai kembali. Anda mungkin harus mengembalikan situs web dari cadangan juga, mungkin ada javascript berbahaya ditambahkan ke setiap file html atau php. Jika Anda mempertimbangkan tindakan hukum, Anda harus menyingkirkan mesin, mencabutnya dari internet, dan menghentikan apa pun yang Anda lakukan sampai ahli forensik melakukan tugasnya.

DerfK
sumber
Jawaban yang sangat bagus.
paul.ago
sayangnya ls-l / proc / [pid] / exe mengembalikan jalur bin perl5.8.8, dan ps / pstree mengatakan ayah proses init, hal ini terlihat sangat tersembunyi. Saya pasti akan memulai dengan instalasi baru, tetapi pengembang asli aplikasi yang menjalankannya berada di luar negeri untuk sementara waktu, jadi saya mencari solusi sementara.
Omong
0

Coba "cat / proc / [process id] / cmdline" Meskipun jika itu adalah rootkit yang benar, ia dapat memodifikasi kernel untuk menyembunyikan dirinya lebih baik.

mfarver
sumber
itu memberi saya sama dengan ps aux "/ usr / sbin / apache / log" yang palsu. Direktori / usr / sbin / apache tidak ada
paul.ago
0

Anda harus menginstal ulang, saya setuju. Sudahkah Anda mencoba keluar dari karakter di jalur? Mungkin salah satu dari slash tersebut sebenarnya adalah bagian dari nama file dan bukan direktori. Paling tidak Anda harus menggunakan iptables untuk memblokir lalu lintas keluar ke host itu atau IRC umum sampai diperbaiki. Periksa netstat juga.

berdosa
sumber
tidak, jalannya tampak "nyata". Sayangnya iptables tampaknya terinstal tetapi modul kernel tidak ada, jadi saya harus mengkompilasi ulang kernel. Saya mungkin akan memperbaiki cara itu selama beberapa hari sampai saya menghubungi orang yang memiliki kode sumber aplikasi, sehingga saya dapat menginstal ulang server
paul.ago
0

Saya pikir sekarang Anda telah menginstal ulang. Waktu pemborosan Anda mencoba melacak proses dan melakukan forensik karena kemungkinan apa pun yang berkembang secara hukum dari itu akan sangat kecil dan peluang menemukan peretas akan sia-sia. Kecuali itu hanya menarik minat Anda untuk meneliti dan membalik rootkit yang bisa menyenangkan :)

batal
sumber