Setelah berbulan-bulan lalai, kobaran api email dan pertempuran manajemen sysadmin kami saat ini dipecat dan menyerahkan "kredensial server" kepada saya. Kredensial tersebut terdiri dari kata sandi root dan tidak ada yang lain: tidak ada prosedur, tidak ada dokumentasi, tidak ada tips, tidak ada.
Pertanyaan saya adalah: dengan asumsi dia meninggalkan boobytraps, bagaimana cara saya mengambil alih server dengan downtime sesedikit mungkin?
Berikut detailnya:
- satu server produksi yang terletak di server farm di ruang bawah tanah; server ubuntu 9.x mungkin, dengan patch grsec (rumor yang saya dengar terakhir kali saya bertanya kepada admin)
- satu server internal yang berisi semua dokumentasi internal, repositori file, wiki, dll. Sekali lagi, server ubuntu, berumur beberapa tahun.
Anggap kedua server telah ditambal dan mutakhir, jadi saya lebih suka tidak mencoba meretas jalan saya kecuali ada alasan yang bagus (yaitu yang dapat dijelaskan kepada manajemen tingkat atas).
Server produksi memiliki beberapa situs web yang di-host (standar apache-php-mysql), server LDAP, suite / server email ZIMBRA, dan sejauh yang saya tahu beberapa workstation vmware berjalan. Tidak tahu apa yang terjadi di sana. Mungkin satu adalah master LDAP, tapi itu dugaan liar.
Server internal memiliki wiki / cms internal, budak LDAP yang mereplikasi kredensial dari server produksi, beberapa workstation vmware lagi, dan backup berjalan.
Saya hanya bisa pergi ke admin farm server, menunjuk ke server, memberi tahu mereka ' sudo
matikan server itu', masuk dalam mode pengguna tunggal dan dapatkan cara saya dengannya. Sama untuk server internal. Namun, itu berarti downtime, manajemen atas kesal, sysadmin tua membalas saya dengan berkata 'lihat? Anda tidak dapat melakukan pekerjaan saya 'dan gangguan lainnya, dan yang paling penting saya harus kehilangan potensi beberapa minggu waktu yang belum dibayar.
Di ujung lain dari spektrum saya hanya bisa login sebagai root dan inci melalui server untuk mencoba membuat pemahaman tentang apa yang terjadi. Dengan semua risiko memicu kejutan yang tertinggal.
Saya mencari solusi di tengah: cobalah untuk menjaga semuanya berjalan seperti apa adanya, sambil memahami apa yang terjadi dan bagaimana, dan yang paling penting adalah menghindari memicu jebakan yang tertinggal .
Apa saran Anda?
Sejauh ini saya berpikir tentang 'berlatih' dengan server internal, memutus jaringan, me-reboot dengan live cd, membuang sistem file root ke drive USB, dan memuatnya pada mesin virtual yang terputus dan terisolasi untuk memahami cara sysadmin sebelumnya. berpikir (a-la 'kenal musuhmu'). Bisa menarik prestasi yang sama dengan server produksi, tetapi dump penuh akan membuat seseorang memperhatikan. Mungkin saya bisa login sebagai root, periksa crontab, periksa. Profil untuk semua perintah yang diluncurkan, buang lastlog, dan apa pun yang terlintas dalam pikiran.
Dan itu sebabnya saya di sini. Petunjuk apa pun, sekecil apa pun, akan sangat dihargai.
Waktu juga menjadi masalah: mungkin ada pemicu yang terjadi dalam beberapa jam, atau beberapa minggu. Terasa seperti salah satu film Hollywood yang buruk, bukan?
sumber
Jawaban:
Seperti yang orang lain katakan itu terlihat seperti situasi longgar-longgar.
(Mulai dari akhir)
Tentu saja Anda tidak bisa begitu saja menurunkan server dan membiarkan installer melakukan keajaiban.
Proses Umum
rm -rf $service
(kedengarannya harsch tetapi yang saya maksud adalah menonaktifkan layanan)Apa yang kamu dapat?
Telah ada yang melakukannya, itu tidak menyenangkan sama sekali :(
Mengapa Anda perlu membuatnya ditandatangani oleh manajemen ?
Oh, dan sampaikan rencana keseluruhan kepada mereka sebelum Anda mulai , dengan beberapa perkiraan tentang apa yang akan terjadi dalam kasus terburuk dan terbaik.
Ini akan biaya banyak waktu terlepas dari pemindahan jika Anda tidak memiliki dokumentasi. Tidak perlu memikirkan backdoors, IMHO jika Anda tidak memiliki dokumentasi migrasi bergulir adalah satu-satunya cara untuk mencapai keadaan waras yang akan memberikan nilai bagi perusahaan.
sumber
Apakah Anda punya alasan untuk percaya bahwa admin sebelumnya meninggalkan sesuatu yang buruk, atau apakah Anda hanya menonton banyak film?
Saya tidak meminta untuk bercanda, saya mencoba untuk mendapatkan ide ancaman seperti apa yang Anda pikirkan dan seberapa besar kemungkinannya. Jika Anda berpikir peluangnya sangat tinggi sehingga mungkin ada masalah yang benar-benar mengganggu, saya sarankan memperlakukannya seolah-olah itu adalah intrusi jaringan yang sukses .
Dalam kasus apa pun, atasan Anda tidak ingin gangguan waktu henti saat Anda menangani hal ini - apa sikap mereka terhadap waktu henti yang direncanakan untuk merapikan sistem vs waktu henti yang tidak direncanakan jika ada kesalahan dalam sistem (apakah kesalahan nyata atau kesalahan). admin nakal) dan jika sikap mereka realistis vs penilaian Anda tentang kemungkinan Anda benar-benar akan memiliki masalah di sini.
Apa pun yang Anda lakukan, pertimbangkan hal berikut:
Ambil gambar dari sistem sekarang . Sebelum Anda melakukan hal lain. Bahkan, ambil dua dan sisihkan satu dan jangan menyentuhnya lagi sampai Anda tahu apa, jika ada, apa yang terjadi dengan sistem Anda, ini adalah catatan Anda tentang bagaimana sistem itu ketika Anda mengambil alih.
Kembalikan set gambar ke-2 ke beberapa mesin virtual dan gunakan ini untuk menyelidiki apa yang sedang terjadi. Jika Anda khawatir tentang hal-hal yang dipicu setelah tanggal tertentu kemudian tetapkan tanggal satu tahun atau lebih di mesin virtual.
sumber
Pertama-tama, jika Anda akan menginvestasikan waktu ekstra dalam hal ini saya akan menyarankan Anda untuk benar-benar dibayar untuk itu. Tampaknya Anda menerima lembur yang tidak dibayar sebagai fakta, menilai dari kata-kata Anda - seharusnya tidak seperti itu, menurut saya, dan khususnya tidak ketika Anda berada dalam keadaan darurat karena kesalahan orang lain (baik itu manajemen, sysadmin lama atau mungkin kombinasi keduanya).
Turunkan server dan boot ke mode pengguna tunggal (init = / bin / sh atau 1 at grub) untuk memeriksa perintah yang berjalan pada login root. Downtime diperlukan di sini, jelaskan kepada manajemen bahwa tidak ada pilihan selain downtime jika mereka ingin memastikan mereka akan menyimpan data mereka.
Setelah itu lihat semua cronjobs, bahkan jika mereka terlihat sah. Juga lakukan pencadangan penuh sesegera mungkin - bahkan jika ini berarti downtime. Anda dapat mengubah cadangan lengkap Anda menjadi menjalankan VM jika Anda mau.
Kemudian jika Anda bisa mendapatkan server baru atau VM yang mampu, saya sebenarnya akan memigrasi layanan ke lingkungan baru yang bersih satu per satu. Anda dapat melakukan ini dalam beberapa tahap untuk meminimalkan persepsi downtime. Anda akan mendapatkan pengetahuan mendalam yang sangat dibutuhkan tentang layanan sambil memulihkan kepercayaan Anda pada sistem basis.
Sementara itu Anda dapat memeriksa rootkit menggunakan alat sebagai chkrootkit . Jalankan nessus di server untuk mencari celah keamanan yang mungkin digunakan admin lama.
Sunting: Saya kira saya tidak membahas bagian "anggun" dari pertanyaan Anda sebaik yang saya bisa. Langkah pertama (masuk ke mode pengguna tunggal untuk memeriksa jebakan masuk) mungkin bisa dilompati - sysadmin lama memberi Anda kata sandi root dan mengatur login untuk melakukan
rm -rf /
hampir sama dengan menghapus semua file sendiri, jadi ada mungkin tidak ada gunanya melakukan itu. Sesuai bagian cadangan: coba gunakanrsync
solusi berbasis sehingga Anda dapat melakukan sebagian besar cadangan awal online dan meminimalkan waktu henti.sumber
Saya akan menginvestasikan waktu untuk mempelajari aplikasi apa yang berjalan di server tersebut. Setelah Anda tahu apa itu apa saja Anda dapat menginstal server baru. Jika Anda merasa bahwa mungkin ada beberapa pintu belakang itu akan menjadi ide yang baik untuk Hanya mem-boot dalam mode tunggal atau memiliki beberapa firewall di antara server dan Net eksternal.
sumber
Anda menjadi paranoid tentang keamanan. Tidak perlu paranoid. (karena Anda berbicara tentang jebakan). Buka daftar perangkat lunak yang diinstal. Lihat apa layanan berjalan (netstat, ps, dll), lihat pekerjaan cron. Nonaktifkan akun pengguna admin sistem sebelumnya tanpa menghapus akun (mudah dilakukan dengan mengarahkan shell ke nologin). Lihat melalui file log. Saya pikir dengan langkah-langkah ini dan dari pengetahuan Anda tentang kebutuhan perusahaan dari mana Anda dapat menebak penggunaan server, saya pikir Anda harus dapat mempertahankannya tanpa ada kesalahan besar.
sumber