Ini adalah Pertanyaan Canonical tentang Keamanan Server - Menanggapi Acara Pelanggaran (Peretasan)
Lihat Juga:

• Kiat untuk Mengamankan Server LAMP
• Instal ulang setelah Root Compromise?

Versi Canonical
Saya menduga bahwa satu atau lebih dari server saya disusupi oleh peretas, virus, atau mekanisme lain:

• Apa langkah pertama saya? Ketika saya tiba di situs haruskah saya memutus server, menyimpan "bukti", apakah ada pertimbangan awal lainnya?
• Bagaimana cara saya mendapatkan layanan kembali online?
• Bagaimana saya mencegah hal yang sama terjadi segera lagi?
• Apakah ada praktik atau metodologi terbaik untuk belajar dari kejadian ini?
• Jika saya ingin menggabungkan Rencana Tanggap Insiden, di mana saya akan mulai? Haruskah ini menjadi bagian dari Pemulihan Bencana atau Perencanaan Kesinambungan Bisnis saya?

Versi asli

2011.01.02 - Saya sedang dalam perjalanan ke kantor pada jam 9.30 malam pada hari Minggu karena server kami entah bagaimana telah dikompromikan dan mengakibatkan serangan DOS pada penyedia kami. Akses server ke Internet telah dimatikan yang berarti lebih dari 5-600 situs klien kami sekarang mati. Sekarang ini bisa menjadi hack FTP, atau beberapa kelemahan dalam kode di suatu tempat. Saya tidak yakin sampai saya tiba di sana.

Bagaimana saya bisa melacak ini dengan cepat? Kami dalam banyak litigasi jika saya tidak mendapatkan server cadangan ASAP. Bantuan apa pun dihargai. Kami menjalankan Open SUSE 11.0.

---

2011.01.03 - Terima kasih kepada semua orang atas bantuan Anda. Untungnya saya bukan satu-satunya orang yang bertanggung jawab untuk server ini, hanya yang terdekat. Kami berhasil menyelesaikan masalah ini, meskipun mungkin tidak berlaku untuk banyak orang lain dalam situasi yang berbeda. Saya akan merinci apa yang kami lakukan.

Kami mencabut server dari internet. Itu melakukan (mencoba melakukan) serangan Denial Of Service pada server lain di Indonesia, dan pihak yang bersalah juga berbasis di sana.

Kami pertama-tama mencoba mengidentifikasi dari mana asalnya pada server ini, mengingat kami memiliki lebih dari 500 situs di server, kami memperkirakan akan melakukan moonlighting selama beberapa waktu. Namun, dengan akses SSH masih, kami menjalankan perintah untuk menemukan semua file diedit atau dibuat pada saat serangan dimulai. Untungnya, file yang menyinggung itu dibuat selama liburan musim dingin yang berarti tidak banyak file lain yang dibuat di server pada waktu itu.

Kami kemudian dapat mengidentifikasi file yang melanggar yang ada di dalam folder gambar yang diunggah dalam situs web ZenCart .

Setelah istirahat sebentar, kami menyimpulkan bahwa, karena lokasi file, itu harus diunggah melalui fasilitas unggah file yang tidak aman. Setelah beberapa googling, kami menemukan bahwa ada kerentanan keamanan yang memungkinkan file diunggah, dalam panel admin ZenCart, untuk gambar untuk perusahaan rekaman. (Bagian yang bahkan tidak pernah benar-benar digunakan), memposting formulir ini hanya mengunggah file apa pun, itu tidak memeriksa ekstensi file, dan bahkan tidak memeriksa untuk melihat apakah pengguna login.

Ini berarti bahwa semua file dapat diunggah, termasuk file PHP untuk serangan itu. Kami mengamankan kerentanan dengan ZenCart di situs yang terinfeksi, dan menghapus file yang menyinggung.

Pekerjaan sudah selesai, dan saya sudah di rumah jam 2 pagi

---

Moral - Selalu terapkan tambalan keamanan untuk ZenCart, atau sistem CMS lainnya. Seperti ketika pembaruan keamanan dirilis, seluruh dunia dibuat sadar akan kerentanannya. - Selalu lakukan pencadangan, dan pencadangan pencadangan Anda. - Mempekerjakan atau mengatur seseorang yang akan ada di saat seperti ini. Untuk mencegah siapa pun mengandalkan postingan pada Server Fault.

Sulit untuk memberikan saran khusus dari apa yang Anda posting di sini, tetapi saya memiliki beberapa saran generik berdasarkan posting yang saya tulis beberapa waktu lalu ketika saya masih bisa diganggu blog.

Jangan Panik

Hal pertama yang pertama, tidak ada "perbaikan cepat" selain memulihkan sistem Anda dari cadangan yang diambil sebelum intrusi, dan ini setidaknya memiliki dua masalah.

1. Sulit untuk menentukan kapan intrusi terjadi.
2. Itu tidak membantu Anda menutup "lubang" yang memungkinkan mereka untuk istirahat di terakhir kali, atau menangani konsekuensi dari "pencurian data" yang mungkin juga telah terjadi.

Pertanyaan ini terus ditanyakan berulang kali oleh para korban peretas yang membobol server web mereka. Jawabannya sangat jarang berubah, tetapi orang terus bertanya. Saya tidak yakin mengapa. Mungkin orang hanya tidak menyukai jawaban yang mereka lihat ketika mencari bantuan, atau mereka tidak dapat menemukan seseorang yang mereka percayai untuk memberikan saran. Atau mungkin orang membaca jawaban untuk pertanyaan ini dan terlalu fokus pada 5% mengapa kasus mereka istimewa dan berbeda dari jawaban yang dapat mereka temukan online dan melewatkan 95% pertanyaan dan menjawab di mana kasus mereka cukup dekat sama seperti yang mereka baca online.

Itu membawa saya ke nugget informasi penting pertama. Saya sangat menghargai bahwa Anda adalah kepingan salju yang unik dan istimewa. Saya menghargai situs web Anda juga, karena itu mencerminkan Anda dan bisnis Anda atau paling tidak, kerja keras Anda atas nama pemberi kerja. Tetapi bagi seseorang di luar yang melihat ke dalam, apakah orang keamanan komputer melihat masalah untuk mencoba dan membantu Anda atau bahkan penyerang itu sendiri, sangat mungkin bahwa masalah Anda setidaknya 95% identik dengan setiap kasus lain yang mereka miliki pernah melihat.

Jangan mengambil serangan itu secara pribadi, dan jangan mengambil rekomendasi yang mengikuti di sini atau yang Anda dapatkan dari orang lain secara pribadi. Jika Anda membaca ini setelah menjadi korban peretasan situs web, maka saya benar-benar minta maaf, dan saya sangat berharap Anda dapat menemukan sesuatu yang bermanfaat di sini, tetapi ini bukan saatnya untuk membiarkan ego Anda menghalangi apa yang Anda butuhkan. melakukan.

Anda baru tahu bahwa server Anda diretas. Sekarang apa?

Jangan panik. Sama sekali tidak bertindak dengan tergesa-gesa, dan sama sekali tidak mencoba dan berpura-pura hal-hal tidak pernah terjadi dan tidak bertindak sama sekali.

Pertama: pahami bahwa bencana telah terjadi. Ini bukan saatnya untuk menyangkal; ini adalah waktu untuk menerima apa yang telah terjadi, untuk realistis tentang hal itu, dan untuk mengambil langkah-langkah untuk mengelola konsekuensi dari dampak tersebut.

Beberapa langkah ini akan menyakitkan, dan (kecuali situs web Anda menyimpan salinan detail saya), saya benar-benar tidak peduli jika Anda mengabaikan semua atau beberapa langkah ini, itu terserah Anda. Tetapi mengikuti mereka dengan benar akan membuat segalanya lebih baik pada akhirnya. Obatnya mungkin terasa tidak enak, tetapi kadang-kadang Anda harus mengabaikannya jika Anda benar-benar ingin obatnya bekerja.

Menghentikan masalah menjadi lebih buruk dari yang sudah ada adalah:

1. Hal pertama yang harus Anda lakukan adalah mencabut sistem yang terkena dampak dari Internet. Apa pun masalah lain yang Anda miliki, membiarkan sistem tetap terhubung ke web hanya akan memungkinkan serangan berlanjut. Maksud saya ini secara harfiah; minta seseorang untuk secara fisik mengunjungi server dan mencabut kabel jaringan jika itu yang diperlukan, tetapi lepaskan korban dari para perampok sebelum Anda mencoba melakukan hal lain.
2. Ubah semua kata sandi Anda untuk semua akun di semua komputer yang berada di jaringan yang sama dengan sistem yang dikompromikan. Tidak benar-benar. Semua akun. Semua komputer. Ya, Anda benar, ini mungkin berlebihan; di sisi lain, mungkin tidak. Anda juga tidak tahu, kan?
3. Periksa sistem Anda yang lain. Berikan perhatian khusus pada layanan yang dihadapi Internet lainnya, dan bagi mereka yang memiliki data keuangan atau data sensitif lainnya.
4. Jika sistem menyimpan data pribadi siapa pun, segera beri tahu orang yang bertanggung jawab atas perlindungan data (jika bukan Anda) dan URGE pengungkapan penuh. Saya tahu ini sulit. Saya tahu ini akan menyakitkan. Saya tahu bahwa banyak bisnis ingin menyapu masalah seperti ini di bawah karpet, tetapi bisnis harus menghadapinya - dan perlu melakukannya dengan memperhatikan setiap dan semua undang-undang privasi yang relevan.

Betapapun jengkelnya pelanggan Anda jika Anda memberi tahu mereka tentang suatu masalah, mereka akan jauh lebih jengkel jika Anda tidak memberi tahu mereka, dan mereka hanya mencari tahu sendiri setelah seseorang menagih barang senilai $ 8.000 menggunakan detail kartu kredit yang mereka miliki. mencuri dari situs Anda.

Ingat apa yang saya katakan sebelumnya? Hal buruk sudah terjadi. Satu-satunya pertanyaan sekarang adalah seberapa baik Anda menghadapinya.

Pahami masalah sepenuhnya:

1. JANGAN menempatkan sistem yang terpengaruh kembali online hingga tahap ini sepenuhnya selesai, kecuali jika Anda ingin menjadi orang yang posnya menjadi titik kritis bagi saya benar-benar memutuskan untuk menulis artikel ini. Saya tidak akan menaut ke pos itu sehingga orang bisa mendapatkan tawa murah, tetapi tragedi sebenarnya adalah ketika orang gagal belajar dari kesalahan mereka.
2. Periksa sistem yang 'diserang' untuk memahami bagaimana serangan berhasil membahayakan keamanan Anda. Berusahalah untuk mengetahui dari mana serangan "berasal", sehingga Anda memahami masalah apa yang Anda miliki dan perlu atasi untuk membuat sistem Anda aman di masa depan.
3. Periksa kembali sistem yang 'diserang', kali ini untuk memahami ke mana serangan itu pergi, sehingga Anda memahami sistem apa yang dikompromikan dalam serangan itu. Pastikan Anda menindaklanjuti petunjuk yang menyarankan sistem yang disusupi dapat menjadi batu loncatan untuk menyerang sistem Anda lebih lanjut.
4. Pastikan "gateway" yang digunakan dalam setiap dan semua serangan dipahami sepenuhnya, sehingga Anda dapat mulai menutupnya dengan benar. (mis. jika sistem Anda dikompromikan oleh serangan injeksi SQL, maka Anda tidak hanya perlu menutup jalur cacat kode tertentu yang mereka gunakan, Anda ingin mengaudit semua kode Anda untuk melihat apakah jenis kesalahan yang sama dibuat di tempat lain).
5. Pahami bahwa serangan mungkin berhasil karena lebih dari satu cacat. Seringkali, serangan berhasil bukan dengan menemukan satu bug utama dalam suatu sistem tetapi dengan merangkai beberapa masalah (terkadang kecil dan sepele sendiri) untuk mengkompromikan suatu sistem. Misalnya, menggunakan serangan injeksi SQL untuk mengirim perintah ke server database, menemukan situs web / aplikasi yang sedang Anda serang sedang berjalan dalam konteks pengguna administratif dan menggunakan hak-hak akun itu sebagai batu loncatan untuk berkompromi dengan bagian lain dari sebuah sistem. Atau sebagai peretas suka menyebutnya: "hari lain di kantor mengambil keuntungan dari kesalahan umum yang dilakukan orang".

Mengapa tidak "memperbaiki" exploit atau rootkit yang telah Anda deteksi dan mengembalikan sistem ke internet?

Dalam situasi seperti ini masalahnya adalah Anda tidak lagi memiliki kendali atas sistem itu. Ini bukan komputer Anda lagi.

Satu-satunya cara untuk memastikan bahwa Anda memiliki kendali atas sistem adalah membangun kembali sistem. Meskipun ada banyak nilai dalam menemukan dan memperbaiki exploit yang digunakan untuk membobol sistem, Anda tidak bisa yakin tentang apa lagi yang telah dilakukan pada sistem begitu penyusup mendapatkan kendali (memang, bukan hal yang tidak pernah terjadi bagi peretas yang merekrut sistem menjadi botnet untuk menambal eksploit yang mereka gunakan sendiri, untuk melindungi komputer baru "mereka" dari peretas lain, serta menginstal rootkit mereka).

Buatlah rencana untuk pemulihan dan untuk membawa situs web Anda kembali online dan tetap melakukannya:

Tidak ada yang ingin offline lebih lama dari yang seharusnya. Itu diberikan. Jika situs web ini merupakan mekanisme menghasilkan pendapatan, maka tekanan untuk membawanya kembali online dengan cepat akan menjadi intens. Bahkan jika satu-satunya yang dipertaruhkan adalah reputasi Anda / perusahaan Anda, ini masih akan menghasilkan banyak tekanan untuk mengembalikan semuanya dengan cepat.

Namun, jangan menyerah pada godaan untuk kembali online terlalu cepat. Alih-alih bergerak secepat mungkin untuk memahami apa yang menyebabkan masalah dan untuk menyelesaikannya sebelum Anda kembali online atau Anda akan hampir pasti menjadi korban intrusi sekali lagi, dan ingat, "untuk diretas sekali dapat digolongkan sebagai kemalangan; untuk diretas kembali setelah itu terlihat seperti kecerobohan "(dengan permintaan maaf kepada Oscar Wilde).

1. Saya berasumsi Anda sudah memahami semua masalah yang menyebabkan intrusi sukses di tempat pertama bahkan sebelum Anda memulai bagian ini. Saya tidak ingin melebih-lebihkan kasus ini tetapi jika Anda belum melakukannya terlebih dahulu maka Anda benar-benar perlu melakukannya. Maaf.
2. Jangan pernah membayar pemerasan / uang perlindungan. Ini adalah tanda dari tanda yang mudah dan Anda tidak ingin ungkapan itu pernah digunakan untuk menggambarkan Anda.
3. Jangan tergoda untuk mengembalikan server yang sama ke internet tanpa membangun kembali secara penuh. Seharusnya jauh lebih cepat untuk membangun kotak baru atau "nuke server dari orbit dan melakukan instalasi bersih" pada perangkat keras lama daripada mengaudit setiap sudut tunggal dari sistem lama untuk memastikan itu bersih sebelum mengembalikannya online lagi. Jika Anda tidak setuju dengan itu maka Anda mungkin tidak tahu apa artinya sebenarnya untuk memastikan sistem dibersihkan sepenuhnya, atau prosedur penyebaran situs web Anda berantakan. Anda mungkin memiliki cadangan dan menguji penyebaran situs Anda yang hanya dapat Anda gunakan untuk membangun situs langsung, dan jika Anda tidak diretas bukan masalah terbesar Anda.
4. Berhati-hatilah dalam menggunakan kembali data yang "hidup" pada sistem saat peretasan. Saya tidak akan mengatakan "tidak pernah melakukannya" karena Anda hanya akan mengabaikan saya, tetapi terus terang saya pikir Anda perlu mempertimbangkan konsekuensi menjaga data tetap ada ketika Anda tahu Anda tidak dapat menjamin integritasnya. Idealnya, Anda harus mengembalikan ini dari cadangan yang dibuat sebelum intrusi. Jika Anda tidak bisa atau tidak mau melakukannya, Anda harus sangat berhati-hati dengan data itu karena sudah ternoda. Anda terutama harus mengetahui konsekuensi kepada orang lain jika data ini milik pelanggan atau pengunjung situs daripada langsung kepada Anda.
5. Monitor sistem dengan hati-hati. Anda harus memutuskan untuk melakukan ini sebagai proses yang berkelanjutan di masa depan (lebih banyak di bawah) tetapi Anda bersusah payah untuk waspada selama periode segera setelah situs Anda kembali online. Para penyusup hampir pasti akan kembali, dan jika Anda dapat melihat mereka mencoba masuk lagi Anda pasti akan dapat melihat dengan cepat jika Anda benar-benar telah menutup semua lubang yang mereka gunakan sebelumnya ditambah dengan lubang yang mereka buat sendiri, dan Anda mungkin mengumpulkan yang berguna informasi yang dapat Anda sampaikan kepada penegak hukum setempat.

Mengurangi risiko di masa depan.

Hal pertama yang perlu Anda pahami adalah bahwa keamanan adalah proses yang harus Anda terapkan di seluruh siklus hidup perancangan, penyebaran, dan pemeliharaan sistem yang menghadapi Internet, bukan sesuatu yang dapat Anda hantam beberapa lapis pada kode Anda setelahnya seperti murah cat. Agar benar-benar aman, layanan dan aplikasi harus dirancang sejak awal dengan pertimbangan ini sebagai salah satu tujuan utama proyek. Saya menyadari itu membosankan dan Anda telah mendengar semuanya sebelumnya dan bahwa saya "hanya tidak menyadari orang yang menekan" untuk mendapatkan layanan beta web2.0 (beta) Anda menjadi status beta di web, tetapi kenyataannya adalah ini membuat diulang karena itu benar pertama kali dikatakan dan itu belum menjadi kebohongan.

Anda tidak dapat menghilangkan risiko. Anda seharusnya tidak mencoba melakukan itu. Apa yang harus Anda lakukan adalah memahami risiko keamanan mana yang penting bagi Anda, dan memahami cara mengelola dan mengurangi dampak risiko dan kemungkinan risiko itu akan terjadi.

Langkah apa yang dapat Anda ambil untuk mengurangi kemungkinan serangan berhasil?

Sebagai contoh:

1. Apakah cacat yang memungkinkan orang untuk membobol situs Anda adalah bug yang dikenal dalam kode vendor, yang tambalannya tersedia? Jika demikian, apakah Anda perlu memikirkan kembali pendekatan Anda tentang cara Anda menambal aplikasi di server yang menghadapi Internet?
2. Apakah cacat yang memungkinkan orang masuk ke situs Anda adalah bug yang tidak dikenal dalam kode vendor, yang tambalannya tidak tersedia? Saya tentu saja tidak menganjurkan penggantian pemasok setiap kali sesuatu seperti ini menggigit Anda karena mereka semua memiliki masalah dan paling banyak Anda akan kehabisan platform dalam setahun jika Anda mengambil pendekatan ini. Namun, jika suatu sistem terus-menerus menurunkan Anda, maka Anda harus bermigrasi ke sesuatu yang lebih kuat atau paling tidak, merancang ulang sistem Anda sehingga komponen yang rentan tetap terbungkus wol kapas dan sejauh mungkin dari mata yang bermusuhan.
3. Apakah cacat bug dalam kode dikembangkan oleh Anda (atau kontraktor bekerja untuk Anda)? Jika demikian, apakah Anda perlu memikirkan kembali pendekatan Anda tentang cara Anda menyetujui kode untuk penyebaran ke situs langsung Anda? Mungkinkah bug telah ditangkap dengan sistem pengujian yang ditingkatkan, atau dengan perubahan pada "standar" pengkodean Anda (misalnya, sementara teknologi bukanlah obat mujarab, Anda dapat mengurangi kemungkinan serangan injeksi SQL yang berhasil dengan menggunakan teknik pengkodean yang terdokumentasi dengan baik ).
4. Apakah cacatnya karena masalah dengan cara server atau perangkat lunak aplikasi digunakan? Jika demikian, apakah Anda menggunakan prosedur otomatis untuk membangun dan menggunakan server jika memungkinkan? Ini adalah bantuan besar dalam mempertahankan status "dasar" yang konsisten di semua server Anda, meminimalkan jumlah pekerjaan kustom yang harus dilakukan pada masing-masing server dan karenanya semoga meminimalkan peluang kesalahan yang akan dibuat. Hal yang sama berlaku dengan penyebaran kode - jika Anda memerlukan sesuatu "khusus" untuk dilakukan untuk menggunakan versi terbaru aplikasi web Anda, maka cobalah keras untuk mengotomatisasi dan memastikan selalu dilakukan secara konsisten.
5. Mungkinkah gangguan telah diketahui sebelumnya dengan pemantauan sistem Anda yang lebih baik? Tentu saja, pemantauan 24 jam atau sistem "on call" untuk staf Anda mungkin tidak hemat biaya, tetapi ada perusahaan di luar sana yang dapat memantau layanan yang Anda hadapi di web untuk Anda dan memberi tahu Anda jika ada masalah. Anda mungkin memutuskan Anda tidak mampu membeli ini atau tidak membutuhkannya dan itu baik-baik saja ... pertimbangkan saja.
6. Gunakan alat-alat seperti tripwire dan nessus yang sesuai - tetapi jangan hanya menggunakannya secara membabi buta karena saya bilang begitu. Luangkan waktu untuk mempelajari cara menggunakan beberapa alat keamanan yang baik yang sesuai dengan lingkungan Anda, perbarui alat-alat ini dan gunakan secara teratur.
7. Pertimbangkan untuk mempekerjakan pakar keamanan untuk 'mengaudit' keamanan situs web Anda secara teratur. Sekali lagi, Anda mungkin memutuskan Anda tidak mampu membeli ini atau tidak membutuhkannya dan itu baik-baik saja ... pertimbangkan saja.

Langkah apa yang dapat Anda ambil untuk mengurangi konsekuensi dari serangan yang berhasil?

Jika Anda memutuskan bahwa "risiko" lantai bawah dari banjir rumah Anda tinggi, tetapi tidak cukup tinggi untuk menjamin pemindahan, Anda setidaknya harus memindahkan pusaka keluarga yang tak tergantikan ke atas. Baik?

1. Bisakah Anda mengurangi jumlah layanan yang langsung terpapar ke Internet? Bisakah Anda menjaga semacam kesenjangan antara layanan internal Anda dan layanan yang Anda hadapi di internet? Ini memastikan bahwa bahkan jika sistem eksternal Anda dikompromikan, peluang untuk menggunakan ini sebagai batu loncatan untuk menyerang sistem internal Anda terbatas.
2. Apakah Anda menyimpan informasi yang tidak perlu Anda simpan? Apakah Anda menyimpan informasi "online" ketika itu dapat diarsipkan di tempat lain. Ada dua poin untuk bagian ini; yang jelas adalah bahwa orang tidak dapat mencuri informasi dari Anda yang tidak Anda miliki, dan poin kedua adalah semakin sedikit Anda menyimpan, semakin sedikit yang perlu Anda pertahankan dan kodekan, sehingga ada sedikit peluang bagi bug untuk masuk kode atau desain sistem Anda.
3. Apakah Anda menggunakan prinsip "akses terendah" untuk aplikasi web Anda? Jika pengguna hanya perlu membaca dari database, maka pastikan akun yang digunakan aplikasi web untuk melayani ini hanya memiliki akses baca, jangan biarkan itu menulis akses dan tentu saja bukan akses tingkat sistem.
4. Jika Anda tidak terlalu berpengalaman dalam sesuatu dan itu bukan pusat bisnis Anda, pertimbangkan untuk melakukan outsourcing. Dengan kata lain, jika Anda menjalankan situs web kecil yang berbicara tentang menulis kode aplikasi desktop dan memutuskan untuk mulai menjual aplikasi desktop kecil dari situs tersebut, maka pertimbangkan untuk melakukan "outsourcing" sistem pesanan kartu kredit Anda kepada seseorang seperti Paypal.
5. Jika memungkinkan, jadikan berlatih pemulihan dari sistem yang dikompromikan sebagai bagian dari rencana Disaster Recovery Anda. Ini bisa dibilang hanyalah "skenario bencana" lain yang bisa Anda temui, hanya satu dengan serangkaian masalah dan masalah yang berbeda dari 'ruang server yang biasa terbakar' / 'diserbu oleh server raksasa yang memakan barang semacam furbies.

... Dan akhirnya

Saya mungkin tidak meninggalkan akhir dari hal-hal yang dianggap penting oleh orang lain, tetapi langkah-langkah di atas setidaknya akan membantu Anda mulai memilah-milah jika Anda cukup beruntung menjadi korban peretas.

Di atas segalanya: Jangan panik. Berpikirlah sebelum bertindak. Bertindak tegas setelah Anda membuat keputusan, dan tinggalkan komentar di bawah jika Anda memiliki sesuatu untuk ditambahkan ke daftar langkah saya.

Sepertinya ada sedikit di atas kepala Anda; tidak apa-apa. Hubungi bos Anda dan mulailah bernegosiasi untuk anggaran respons keamanan darurat. $ 10.000 mungkin merupakan tempat yang baik untuk memulai. Maka Anda perlu meminta seseorang (PFY, rekan kerja, manajer) untuk mulai memanggil perusahaan yang berspesialisasi dalam respons insiden keamanan. Banyak yang dapat merespons dalam 24 jam, dan kadang-kadang bahkan lebih cepat jika mereka memiliki kantor di kota Anda.

Anda juga membutuhkan seseorang untuk membuat triase pelanggan; Tidak diragukan lagi, seseorang sudah ada. Seseorang harus berbicara di telepon dengan mereka untuk menjelaskan apa yang sedang terjadi, apa yang sedang dilakukan untuk menangani situasi, dan untuk menjawab pertanyaan mereka.

Maka, Anda harus ...

1. Tetap tenang. Jika Anda bertanggung jawab atas respons insiden, apa yang Anda lakukan sekarang perlu menunjukkan profesionalisme dan kepemimpinan sepenuhnya. Dokumentasikan semua yang Anda lakukan, dan beri tahu manajer dan tim eksekutif Anda tindakan-tindakan besar yang Anda ambil; ini termasuk bekerja dengan tim respons, menonaktifkan server, mencadangkan data, dan membawa hal-hal online lagi. Mereka tidak membutuhkan detail mengerikan, tetapi mereka harus mendengar dari Anda setiap 30 menit atau lebih.

2. Jadilah realistik. Anda bukan profesional keamanan, dan ada hal-hal yang tidak Anda ketahui. Tidak apa-apa. Saat masuk ke server dan melihat data, Anda perlu memahami batasan Anda. Tapak dengan lembut. Dalam penyelidikan Anda, pastikan Anda tidak menginjak informasi penting atau mengubah sesuatu yang mungkin diperlukan nanti. Jika Anda merasa tidak nyaman atau bahwa Anda menebak, itu adalah tempat yang baik untuk berhenti dan meminta seorang profesional yang berpengalaman untuk mengambil alih.

3. Dapatkan stik USB yang bersih dan simpan hard drive. Anda akan mengumpulkan bukti di sini. Buat cadangan untuk semua yang Anda rasa mungkin relevan; komunikasi dengan ISP Anda, dump jaringan, dll. Bahkan jika penegakan hukum tidak terlibat, dalam kasus gugatan Anda akan ingin bukti ini membuktikan bahwa perusahaan Anda menangani insiden keamanan secara profesional dan sesuai.

4. Yang terpenting adalah menghentikan kerugian. Identifikasi dan putuskan akses ke layanan, data, dan mesin yang dikompromikan. Lebih disukai, Anda harus menarik kabel jaringan mereka; jika Anda tidak bisa, maka tarik daya.

5. Selanjutnya, Anda perlu menghapus penyerang dan menutup lubang. Agaknya, penyerang tidak lagi memiliki akses interaktif karena Anda menarik jaringan. Anda sekarang perlu mengidentifikasi, mendokumentasikan (dengan cadangan, tangkapan layar, dan catatan pengamatan pribadi Anda sendiri; atau lebih disukai bahkan dengan menghapus drive dari server yang terkena dampak dan membuat salinan gambar disk penuh), dan kemudian menghapus kode dan proses apa pun yang ditinggalkannya . Bagian selanjutnya ini akan menyedot jika Anda tidak memiliki cadangan; Anda dapat mencoba mengurai penyerang dari sistem dengan tangan, tetapi Anda tidak akan pernah yakin bahwa Anda mendapatkan semua yang dia tinggalkan. Rootkit jahat, dan tidak semua terdeteksi. Respons terbaik adalah mengidentifikasi kerentanan yang digunakannya untuk masuk, membuat salinan gambar dari disk yang terpengaruh, dan kemudian menghapus sistem yang terkena dampak dan memuat ulang dari cadangan yang dikenal baik. Mengenakan' t mempercayai cadangan Anda secara membabi buta; verifikasi itu! Perbaiki atau tutup kerentanan sebelum host baru masuk lagi ke jaringan, lalu bawa online.

6. Atur semua data Anda ke dalam laporan. Pada titik ini kerentanan ditutup dan Anda punya waktu untuk bernafas. Jangan tergoda untuk melewati langkah ini; itu bahkan lebih penting daripada sisa proses. Dalam laporan tersebut, Anda perlu mengidentifikasi apa yang salah, bagaimana tim Anda merespons, dan langkah-langkah yang Anda ambil untuk mencegah insiden ini terjadi lagi. Sedetail mungkin; ini bukan hanya untuk Anda, tetapi untuk manajemen Anda dan sebagai pembelaan dalam gugatan potensial.

Itu adalah tinjauan yang sangat tinggi tentang apa yang harus dilakukan; sebagian besar pekerjaan hanyalah dokumentasi dan penanganan cadangan. Jangan panik, Anda bisa melakukan itu. Saya sangat menyarankan Anda mendapatkan bantuan keamanan profesional. Bahkan jika Anda dapat menangani apa yang sedang terjadi, bantuan mereka akan sangat berharga dan mereka biasanya dilengkapi dengan peralatan untuk membuat proses lebih mudah dan lebih cepat. Jika bos Anda menolak keras, ingatkan dia bahwa itu sangat kecil jika dibandingkan dengan menangani gugatan.

Anda memiliki penghiburan saya untuk situasi Anda. Semoga berhasil.

CERT memiliki dokumen Langkah-langkah untuk Memulihkan dari Sistem UNIX atau NT Compromise yang bagus. Rincian teknis spesifik dokumen ini agak ketinggalan zaman, tetapi banyak saran umum masih berlaku secara langsung.

Ringkasan singkat dari langkah-langkah dasar adalah ini.

• Konsultasikan dengan kebijakan atau manajemen keamanan Anda.
• Dapatkan kontrol (matikan komputer)
• Analisis intrusi, dapatkan log, cari tahu kesalahannya
• Memperbaiki barang
  • Instal versi bersih dari sistem operasi Anda !!! Jika sistem telah dikompromikan Anda tidak dapat mempercayainya, titik.
• Perbarui sistem sehingga ini tidak dapat terjadi lagi
• Lanjutkan operasi
• Perbarui kebijakan Anda untuk masa depan dan dokumen

Saya ingin secara khusus mengarahkan Anda ke bagian E.1.

E.1. Ingatlah bahwa jika mesin dikompromikan, apa pun pada sistem itu dapat dimodifikasi, termasuk kernel, binari, file data, proses yang berjalan, dan memori. Secara umum, satu-satunya cara untuk mempercayai bahwa mesin bebas dari backdoor dan modifikasi penyusup adalah menginstal ulang operasi

Jika Anda belum memiliki sistem seperti tripwire, tidak mungkin Anda yakin 100% telah membersihkan sistem.

1. Identifikasi masalahnya. Baca log.
2. Berisi . Anda telah memutus server, jadi itu selesai.
3. Memberantas . Instal ulang sistem yang terpengaruh, kemungkinan besar. Jangan menghapus hard drive yang diretas, gunakan yang baru. Ini lebih aman, dan Anda mungkin perlu yang lama untuk memulihkan retas buruk yang tidak didukung, dan untuk melakukan forensik untuk mengetahui apa yang terjadi.
4. Pulihkan . Instal apa pun yang diperlukan dan pulihkan cadangan untuk membuat klien Anda online.
5. Tindak lanjut . Cari tahu apa masalahnya, dan cegah agar tidak terjadi lagi.

Jawaban "pil pahit" Robert tepat tetapi benar-benar generik (yah, seperti pertanyaan Anda). Memang terdengar seperti Anda memiliki masalah manajemen dan sangat membutuhkan sysadmin penuh waktu jika Anda memiliki satu server dan 600 klien tetapi itu tidak membantu Anda sekarang.

Saya menjalankan perusahaan hosting yang menyediakan sedikit pegangan dalam situasi ini, jadi saya berurusan dengan banyak mesin yang dikompromikan, tetapi juga berurusan dengan praktik terbaik untuk kita sendiri. Kami selalu memberi tahu klien kami yang berkompromi untuk membangun kembali kecuali mereka tidak sepenuhnya yakin tentang sifat kompromi. Tidak ada rute lain yang bertanggung jawab dalam jangka panjang.

Namun, Anda hampir pasti hanya korban skrip kiddy yang menginginkan landasan peluncuran untuk serangan DoS, atau penjaga IRC, atau sesuatu yang sama sekali tidak terkait dengan situs dan data pelanggan Anda. Karena itu sebagai tindakan sementara saat Anda membangun kembali, Anda mungkin mempertimbangkan untuk memunculkan firewall keluar yang berat di komputer Anda. Jika Anda dapat memblokir semua koneksi UDP dan TCP keluar yang tidak benar-benar diperlukan untuk fungsi situs Anda, Anda dapat dengan mudah membuat kotak yang dikompromikan tidak berguna bagi siapa pun yang meminjamnya dari Anda, dan mengurangi efek pada jaringan penyedia Anda menjadi nol.

Proses ini mungkin memakan waktu beberapa jam jika Anda belum pernah melakukannya sebelumnya, dan tidak pernah mempertimbangkan firewall, tetapi mungkin membantu Anda memulihkan layanan klien Anda dengan risiko terus memberikan penyerang akses ke data klien Anda . Karena Anda mengatakan bahwa Anda memiliki ratusan klien di satu mesin, saya menduga Anda meng-hosting situs web brosur kecil untuk bisnis kecil, dan bukan 600 sistem e-commerce yang penuh dengan nomor kartu kredit. Jika demikian, ini mungkin risiko yang dapat diterima untuk Anda, dan dapatkan sistem Anda kembali online lebih cepat daripada mengaudit 600 situs untuk bug keamanan sebelum Anda mengembalikan apa pun. Tetapi Anda akan tahu data apa yang ada di sana, dan seberapa nyaman Anda mengambil keputusan itu.

Ini sama sekali bukan praktik terbaik, tetapi jika bukan itu yang terjadi pada majikan Anda sejauh ini, mengibas-ngibaskan jari Anda pada mereka dan meminta puluhan ribu pound untuk tim SWAT untuk sesuatu yang mungkin mereka rasakan adalah kesalahan Anda (betapapun tidak bisa dibenarkan! ) tidak terdengar seperti opsi praktis.

Bantuan ISP Anda di sini akan menjadi sangat penting - beberapa ISP menyediakan server konsol dan lingkungan boot jaringan (colok, tetapi setidaknya Anda tahu jenis fasilitas apa yang harus dicari) yang akan memungkinkan Anda mengelola server saat terputus dari jaringan. Jika ini merupakan opsi, minta dan gunakanlah.

Tetapi dalam jangka panjang Anda harus merencanakan sistem yang dibangun kembali berdasarkan pos Robert dan audit dari setiap situs dan pengaturannya. Jika Anda tidak bisa mendapatkan sysadmin ditambahkan ke tim Anda, cari kesepakatan hosting yang dikelola di mana Anda membayar ISP Anda untuk bantuan sysadminning dan respons 24 jam untuk hal semacam ini. Semoga berhasil :)

Anda perlu menginstal ulang. Simpan apa yang benar-benar Anda butuhkan. Namun perlu diingat bahwa semua file yang bisa Anda jalankan mungkin terinfeksi dan dirusak. Saya menulis yang berikut ini dengan python: http://frw.se/monty.py yang membuat MD5-sumbs dari semua file Anda di direktori yang diberikan dan saat berikutnya Anda menjalankannya, ia memeriksa apakah ada yang berubah dan kemudian menampilkan apa file berubah dan apa yang berubah dalam file.

Ini bisa berguna bagi Anda, untuk melihat apakah file aneh diubah secara teratur.

Tetapi satu-satunya hal yang harus Anda lakukan sekarang, adalah menghapus komputer Anda dari internet.

CATATAN: Ini bukan rekomendasi. Protokol Respon Insiden spesifik saya mungkin tidak akan berlaku tidak dimodifikasi untuk kasus Grant unin.

Di fasilitas akademik kami, kami memiliki sekitar 300 peneliti yang hanya melakukan perhitungan. Anda memiliki 600 klien dengan situs web sehingga protokol Anda mungkin akan berbeda.

Langkah pertama dalam When When Server Gets Protocol yang dikompromikan adalah:

1. Identifikasi bahwa penyerang dapat memperoleh root (peningkatan hak istimewa)
2. Cabut server yang terpengaruh. Jaringan atau kekuatan? Silakan lihat diskusi terpisah .
3. Periksa semua sistem lain
4. Boot server yang terpengaruh dari live cd
5. (opsional) Ambil gambar dari semua drive sistem dengandd

6. Mulailah melakukan forensik post-mortem. Lihat log, cari tahu waktu serangan, cari file yang dimodifikasi pada waktu itu. Coba jawab Bagaimana? pertanyaan.

   • Secara paralel, rencanakan dan jalankan pemulihan Anda.
   • Setel ulang semua kata sandi root dan pengguna sebelum melanjutkan layanan

Bahkan jika "semua backdoor dan rootkit sudah dibersihkan", jangan percaya sistem itu - instal ulang dari awal.

Dalam pengalaman saya yang terbatas, kompromi sistem pada Linux cenderung lebih 'komprehensif' daripada di Windows. Kit root jauh lebih mungkin menyertakan penggantian binari sistem dengan kode khusus untuk menyembunyikan malware, dan penghalang untuk menambal-panas kernel sedikit lebih rendah. Plus, ini adalah OS rumah bagi banyak pembuat malware. Pedoman umum selalu untuk membangun kembali server yang terpengaruh dari awal, dan itu adalah panduan umum karena suatu alasan.

Format anak anjing itu.

Tetapi, jika Anda tidak dapat membangun kembali (atau kekuatan yang tidak akan membiarkan Anda membangunnya kembali melawan desakan keras Anda bahwa ia membutuhkannya), apa yang Anda cari?

Karena kedengarannya seperti sudah lama sejak intrusi ditemukan, dan pemulihan sistem telah dilakukan, sangat mungkin bahwa jejak bagaimana mereka masuk telah diinjak-injak dalam penyerbuan untuk memulihkan layanan. Disayangkan

Lalu lintas jaringan yang tidak biasa mungkin paling mudah ditemukan, karena itu tidak melibatkan menjalankan apa pun di kotak dan dapat dilakukan saat server aktif dan melakukan apa pun. Menganggap, tentu saja, peralatan jaringan Anda memungkinkan spanning port. Apa yang Anda temukan mungkin diagnostik atau tidak, tetapi setidaknya itu adalah informasi. Mendapatkan lalu lintas yang tidak biasa akan menjadi bukti kuat bahwa sistem masih dikompromikan dan perlu diratakan. Mungkin cukup baik untuk meyakinkan TPTB bahwa format ulang benar-benar layak untuk downtime.

Jika gagal, ambil dd-copy dari partisi sistem Anda dan pasang mereka di kotak lain. Mulai membandingkan konten dengan server pada tingkat tambalan yang sama dengan yang dikompromikan. Ini akan membantu Anda mengidentifikasi apa yang tampak berbeda (md5sums lagi) dan mungkin menunjuk ke area yang diabaikan pada server yang dikompromikan. Ini BANYAK menyaring melalui direktori dan binari, dan akan agak padat karya. Bahkan mungkin lebih padat karya daripada reformat / pembangunan kembali, dan mungkin hal lain untuk memukul TPTB tentang benar-benar melakukan reformat yang benar-benar dibutuhkan.

Saya akan mengatakan @Robert Moir, @Alexandr Levchuk, @blueben dan @Matthew Bloch semuanya cukup tepat dalam tanggapan mereka.

Namun, jawaban dari berbagai poster berbeda - beberapa lebih pada tingkat tinggi dan berbicara tentang prosedur apa yang harus Anda miliki (secara umum).

Saya lebih suka memisahkan ini menjadi beberapa bagian terpisah 1) Triage, AKA Bagaimana menangani pelanggan dan implikasi hukum, dan mengidentifikasi ke mana harus pergi dari sana (Terdaftar dengan sangat baik oleh Robert dan @blueben 2) Mitigasi dampak 3 ) Respon insiden 4) Forensik post-mortem 5) Item remediasi dan perubahan arsitektur

(Masukkan boilerplate SANS GSC pernyataan tanggapan tersertifikasi di sini) Berdasarkan pengalaman sebelumnya, saya akan mengatakan yang berikut:

Terlepas dari bagaimana Anda menangani respons pelanggan, pemberitahuan, hukum, dan rencana masa depan, saya lebih suka fokus pada masalah utama yang ada. Pertanyaan asli OP benar-benar hanya berkaitan langsung dengan # 2 dan # 3, pada dasarnya, bagaimana cara menghentikan serangan, membuat pelanggan kembali online ASAP dalam keadaan asli mereka, yang telah diliput dengan baik dalam tanggapan.

Sisa tanggapannya bagus dan mencakup banyak praktik terbaik yang teridentifikasi dan cara-cara baik untuk mencegahnya terjadi di masa depan maupun meresponsnya dengan lebih baik.

Itu benar-benar tergantung pada anggaran OP dan sektor industri mana mereka, apa solusi yang mereka inginkan dll.

Mungkin mereka perlu menyewa SA di tempat khusus. Mungkin mereka membutuhkan orang keamanan. Atau mungkin mereka membutuhkan solusi yang dikelola sepenuhnya seperti Firehost atau Rackspace Managed, Softlayer, ServePath dll.

Itu sangat tergantung pada apa yang bekerja untuk bisnis mereka. Mungkin kompetensi inti mereka tidak dalam manajemen server dan tidak masuk akal bagi mereka untuk mencoba mengembangkannya. Atau, mungkin mereka adalah organisasi yang cukup teknis dan dapat membuat keputusan perekrutan yang tepat dan membawa tim yang berdedikasi penuh waktu.

Setelah mulai bekerja dan melihat server kami berhasil mencari tahu masalahnya. Untungnya, file yang melanggar diunggah ke sistem pada hari Minggu, ketika kantor ditutup dan tidak ada file yang harus dibuat, selain dari file log dan cache. Dengan perintah shell sederhana untuk mengetahui file mana yang telah dibuat pada hari itu kami menemukannya.

Semua file yang menyinggung tampaknya berada di dalam folder / images / di beberapa situs zencart lama kami. Tampaknya ada kerentanan keamanan yang memungkinkan (menggunakan curl) orang idiot untuk mengunggah non-gambar ke bagian unggahan gambar di bagian admin. Kami menghapus file .php yang menyinggung, dan memperbaiki skrip pengunggahan untuk melarang segala pengunggahan file yang bukan gambar.

Dalam retrospeksi, itu cukup sederhana dan saya mengajukan pertanyaan ini di iPhone saya saat akan mulai bekerja. Terima kasih atas semua bantuan kalian semuanya.

Untuk referensi siapa pun yang mengunjungi pos ini di masa mendatang. Saya tidak akan merekomendasikan mencabut steker listrik.

Saya tidak banyak berkontribusi pada jawaban teknis yang luas, tetapi harap perhatikan juga beberapa di antaranya:

Tindakan non-teknis:

• Laporkan kejadian tersebut secara internal.
  Jika Anda belum memiliki rencana respons insiden yang mungkin muncul teknik CYA, tetapi departemen TI bukan satu-satunya dan sering kali bahkan bukan tempat terbaik untuk menentukan dampak bisnis dari server yang disusupi.
  Persyaratan bisnis dapat mengalahkan kekhawatiran teknis Anda. Jangan katakan "Saya sudah bilang begitu" dan bahwa prioritas masalah bisnis adalah alasan Anda memiliki server yang dikompromikan ini sejak awal. (" Biarkan itu untuk laporan setelah tindakan. ")

• Menutupi insiden keamanan bukanlah pilihan.

• Pelaporan ke otoritas lokal.
  ServerFault BUKAN tempat untuk penasihat hukum, tetapi ini adalah sesuatu yang harus dimasukkan dalam rencana respons insiden.
  Di beberapa daerah dan / atau industri yang diatur, wajib melaporkan insiden keamanan (tertentu) kepada penegak hukum setempat, badan pengatur, atau untuk menginformasikan pelanggan / pengguna yang terkena dampak.
  Apapun, keputusan untuk melaporkan atau laporan yang sebenarnya dibuat semata-mata di departemen TI. Harapkan keterlibatan dari manajemen dan departemen komunikasi (pemasaran) hukum dan perusahaan.
  Anda mungkin seharusnya tidak berharap terlalu banyak, internet adalah tempat yang besar di mana perbatasan memiliki sedikit makna, tetapi departemen kejahatan dunia maya yang ada di banyak departemen kepolisian benar-benar menyelesaikan kejahatan digital dan dapat membawa orang yang bersalah ke pengadilan.

Saya pikir semuanya bermuara pada ini:

Jika Anda menghargai pekerjaan Anda, Anda sebaiknya punya rencana, dan merevisinya secara teratur.

Gagal merencanakan berarti gagal, dan tidak ada yang lebih benar daripada keamanan sistem. Saat <redacted> mengenai kipas, Anda sebaiknya siap menghadapinya.

Ada pepatah lain (agak klise) yang berlaku di sini: Pencegahan lebih baik daripada mengobati .

Ada sejumlah rekomendasi di sini untuk meminta para ahli memeriksa sistem yang ada. Saya pikir ini mengajukan pertanyaan pada waktu yang salah. Pertanyaan ini seharusnya ditanyakan ketika sistem diberlakukan, dan jawabannya didokumentasikan. Juga, pertanyaannya seharusnya bukan "Bagaimana kita bisa menghentikan orang agar tidak menerobos masuk?" Itu harus "Mengapa orang harus bisa masuk sama sekali?" Mengaudit sekelompok lubang di jaringan Anda hanya akan berfungsi sampai lubang baru ditemukan dan dieksploitasi. Di sisi lain, jaringan yang dirancang dari bawah ke atas hanya merespons dengan cara tertentu ke sistem tertentu dalam tarian koreografi yang hati-hati tidak akan mendapat manfaat dari audit sama sekali dan dana akan sia-sia.

Sebelum meletakkan sistem di internet, tanyakan pada diri Anda - apakah ini harus 100% menghadap ke internet? Jika tidak, jangan. Pertimbangkan untuk meletakkannya di belakang firewall di mana Anda dapat memutuskan apa yang dilihat internet. Lebih baik lagi, jika kata firewall memungkinkan Anda untuk mencegat transmisi (melalui proxy terbalik atau semacam pass-through filter), lihat menggunakannya untuk memungkinkan hanya tindakan yang sah terjadi.

Ini telah dilakukan - ada (atau pernah) pengaturan internet banking di suatu tempat yang memiliki proxy load-balancing menghadap internet yang akan mereka gunakan untuk serangan vektor jauh dari kumpulan server mereka. Pakar keamanan Marcus Ranum meyakinkan mereka untuk mengambil pendekatan yang berlawanan, dengan menggunakan proxy terbalik untuk memungkinkan hanya URL valid yang diketahui melalui dan mengirim semua yang lain ke server 404 . Mengejutkan waktu dengan sangat baik.

Suatu sistem atau jaringan yang didasarkan pada izin default akan gagal setelah serangan yang tidak Anda sadari terjadi. Default deny memberi Anda kendali jauh lebih besar atas apa yang masuk dan apa yang tidak, karena Anda tidak akan membiarkan apa pun di dalam dilihat dari luar kecuali benar-benar perlu .

Yang mengatakan, semua ini bukan alasan untuk berpuas diri. Anda harus tetap memiliki rencana untuk beberapa jam pertama setelah pelanggaran. Tidak ada sistem yang sempurna dan manusia membuat kesalahan.

Seorang onliner yang baik membantu saya baru-baru ini untuk mengetahui bagaimana seorang penyerang dapat membahayakan sistem. Beberapa cracker berusaha menyembunyikan jejak mereka dengan memalsukan waktu modifikasi pada file. Dengan mengubah waktu modifikasi, waktu perubahan diperbarui (ctime). Anda dapat melihat waktu dengan stat.

Liner satu ini mencantumkan semua file yang diurutkan berdasarkan waktu:

find / -type f -print0 | xargs -0 stat --format '%Z :%z %n' | sort -nr > /root/all_files.txt

Jadi, jika Anda secara kasar mengetahui waktu kompromi, Anda dapat melihat file mana yang diubah atau dibuat.