Instal ulang setelah Root Compromise?

Setelah membaca pertanyaan ini tentang kompromi server , saya mulai bertanya-tanya mengapa orang tampaknya terus percaya bahwa mereka dapat memulihkan sistem yang dikompromikan menggunakan alat deteksi / pembersihan, atau dengan hanya memperbaiki lubang yang digunakan untuk kompromi sistem.

Mengingat semua berbagai teknologi root kit dan hal-hal lain yang dapat dilakukan peretas, sebagian besar ahli menyarankan Anda untuk menginstal ulang sistem operasi .

Saya berharap untuk mendapatkan ide yang lebih baik mengapa banyak orang tidak hanya lepas landas dan nuke sistem dari orbit.

Berikut adalah beberapa poin, yang ingin saya sampaikan.

• Apakah ada kondisi di mana format / instal ulang tidak akan membersihkan sistem?
• Menurut jenis kondisi apa menurut Anda suatu sistem dapat dibersihkan, dan kapan Anda harus menginstal ulang sepenuhnya?
• Alasan apa yang Anda miliki untuk tidak melakukan instal ulang penuh?
• Jika Anda memilih untuk tidak menginstal ulang, maka metode apa yang Anda gunakan untuk cukup yakin Anda telah membersihkan dan mencegah kerusakan lebih lanjut dari terjadi lagi.

Keputusan keamanan pada akhirnya adalah keputusan bisnis tentang risiko, seperti halnya keputusan tentang produk apa yang akan dibawa ke pasar. Ketika Anda membingkainya dalam konteks itu, keputusan untuk tidak naik level dan menginstal ulang masuk akal. Ketika Anda menganggapnya hanya dari sudut pandang teknis, itu tidak benar.

Inilah yang biasanya masuk ke dalam keputusan bisnis itu:

• Berapa lama waktu henti kami bagi kami dalam jumlah yang terukur?
• Berapa besar kemungkinan biaya bagi kita ketika kita harus mengungkapkan kepada pelanggan sedikit tentang mengapa kita jatuh?
• Kegiatan apa lagi yang harus saya lakukan untuk menarik orang agar tidak menginstal ulang? Berapa biayanya?
• Apakah kita memiliki orang yang tepat yang tahu cara membuka sistem tanpa kesalahan? Jika tidak, berapa biayanya bagi saya karena mereka memecahkan bug?

Dan karena itu, ketika Anda menjumlahkan biaya seperti itu, mungkin dianggap bahwa melanjutkan dengan sistem yang "berpotensi" masih dikompromikan lebih baik daripada menginstal ulang sistem.

Berdasarkan posting yang saya tulis beberapa waktu lalu ketika saya masih bisa diganggu blog.

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 tidak menyukai jawaban yang mereka lihat ketika mencari bantuan, atau mereka tidak dapat menemukan seseorang yang mereka percayai untuk memberi 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 hanya 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 tetapi melakukan hal itu 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; suruh seseorang untuk secara fisik mengunjungi server dan mencabut kabel jaringan jika itu yang diperlukan, tetapi lepaskan korban dari para perampoknya 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, buat pengungkapan penuh dan jujur ​​kepada siapa pun yang berpotensi terkena dampak sekaligus. Saya tahu ini sulit. Saya tahu ini akan menyakitkan. Saya tahu bahwa banyak bisnis ingin menyapu masalah seperti ini di bawah karpet, tetapi saya khawatir Anda hanya harus menghadapinya.

Masih ragu untuk mengambil langkah terakhir ini? Saya mengerti, saya mengerti. Tapi lihat seperti ini:

Di beberapa tempat Anda mungkin memiliki persyaratan hukum untuk memberi tahu pihak berwenang dan / atau korban pelanggaran privasi semacam ini. 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 menghubungkan ke pos sehingga orang bisa mendapatkan tawa murah; Saya menghubungkan untuk memperingatkan Anda tentang konsekuensi dari kegagalan untuk mengikuti langkah pertama ini.
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".

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

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 bisa melihat mereka mencoba masuk lagi, Anda pasti akan dapat melihat dengan cepat jika Anda benar-benar telah menutup semua lubang yang mereka gunakan sebelumnya plus 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 efektif 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 Pemulihan Bencana 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'. (edit, per XTZ)

... 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.

Selalu nuke dari orbit. Itu satu-satunya cara untuk memastikan.

_{(sumber: flickr.com )}

Sebagian besar sistem adalah entitas holistik yang memiliki kepercayaan batin yang implisit. Memercayai sistem yang dikompromikan adalah pernyataan implisit yang Anda percayai siapa pun yang telah melakukan pelanggaran sistem Anda. Dengan kata lain:

Anda tidak bisa mempercayainya. Jangan repot-repot membersihkan. Putuskan sambungan dan segera isolasi mesin. Pahami sifat pelanggaran sebelum Anda melanjutkan, jika tidak Anda mengundang hal yang sama lagi. Coba, jika mungkin, untuk mendapatkan tanggal dan waktu pelanggaran, sehingga Anda memiliki kerangka acuan. Anda memerlukan ini karena jika Anda memulihkan dari cadangan, Anda perlu memastikan bahwa cadangan itu sendiri tidak memiliki salinan kompromi di dalamnya. Bersihkan sebelum Anda memulihkan - jangan mengambil jalan pintas.

Secara praktis, kebanyakan orang tidak melakukannya karena mereka pikir itu akan terlalu lama atau terlalu mengganggu. Saya telah memberi saran kepada banyak klien tentang kemungkinan masalah yang berkelanjutan, tetapi instal ulang sering kali gagal oleh pembuat keputusan karena salah satu alasan itu.

Yang sedang berkata, pada sistem di mana saya yakin bahwa saya tahu metode entri dan tingkat kerusakan penuh (log off-mesin padat, biasanya dengan IDS, mungkin SELinux atau sesuatu serupa yang membatasi ruang lingkup intrusi), saya telah melakukan pembersihan tanpa menginstal ulang tanpa merasa terlalu bersalah.

Kemungkinan besar mereka tidak memiliki rutinitas pemulihan bencana yang cukup teruji sehingga mereka merasa percaya diri dalam melakukan pembangunan kembali, atau tidak jelas berapa lama waktu yang dibutuhkan atau apa dampaknya ... atau cadangan tidak dapat diandalkan atau analis risikonya tidak memahami ruang lingkup sistem yang dikompromikan. Saya bisa memikirkan banyak alasan.

Saya akan mengatakan itu sebagian besar tidak beres dalam rutinitas dasar dan kebijakan dan itu bukan sesuatu yang ingin Anda akui secara terbuka - dan sebaliknya Anda mengambil sikap defensif. Setidaknya saya tidak bisa melihat atau bertahan tidak menghapus sistem yang dikompromikan tidak peduli apa sudut pandang Anda.

Saya sebelumnya tidak pernah nuked sistem sehingga saya dapat melakukan beberapa analisis dari vektor yang mereka masuk dan analisis selanjutnya dari penggunaan dan untuk melihat di mana mereka sampai di dalam.

Setelah Anda di-root - Anda memiliki honeypot hidup dan dapat menawarkan lebih dari sekadar peretasan. - Khusus untuk polisi.

• yang mengatakan saya telah dicegah untuk bisa mendapatkan sistem yang bersih pada siaga panas dan untuk dapat menawarkan keamanan jaringan yang ditingkatkan cepat untuk mengisolasi kotak root.