Pertanyaan Bagaimana cara saya menangani server yang disusupi?


Ini adalah sebuah Pertanyaan Kanonis tentang Keamanan Server - Menanggapi Peristiwa Pelanggaran (Peretasan)
  Lihat juga:

Versi Kanonis
Saya menduga bahwa satu atau lebih server saya dikompromikan oleh peretas, virus, atau mekanisme lain:

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

Versi asli 

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

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


2011.01.03 - Terimakasih untuk semua orang atas bantuannya. Untungnya saya bukan satu-satunya orang yang bertanggung jawab untuk server ini, hanya yang terdekat. Kami mengatur   untuk mengatasi masalah ini, meskipun mungkin tidak berlaku untuk banyak orang lain dalam   situasi yang berbeda. Saya akan detail apa yang kami lakukan.

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

Kami pertama kali mencoba mengidentifikasi darimana asal server ini,   mengingat kami memiliki lebih dari 500 situs di server, kami harapkan   moonlighting untuk beberapa waktu. Namun, dengan akses SSH masih, kami berlari a   perintah untuk menemukan semua file yang diedit atau dibuat pada saat serangan   dimulai. Untungnya, file yang menyinggung itu dibuat selama musim dingin   liburan yang berarti tidak banyak file lain yang dibuat di   server pada saat itu.

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

Setelah istirahat rokok pendek kami menyimpulkan bahwa, karena file   lokasi, itu pasti sudah diunggah melalui fasilitas upload file itu   tidak dijamin aman. Setelah beberapa googling, kami menemukan bahwa ada   kerentanan keamanan yang memungkinkan file untuk diunggah, di dalam   Panel admin ZenCart, untuk gambar untuk perusahaan rekaman. (Bagian ini   yang tidak pernah benar-benar digunakan), posting formulir ini baru saja diunggah   file, itu tidak memeriksa ekstensi file, dan bahkan tidak   periksa untuk melihat apakah pengguna sudah masuk.

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

Pekerjaan sudah selesai, dan aku ada di rumah jam 2 pagi.


The Moral   - Selalu terapkan patch keamanan untuk ZenCart, atau sistem CMS lainnya dalam hal ini. Seperti ketika pembaruan keamanan dilepaskan, keseluruhan   dunia dibuat sadar akan kerentanannya.   - Selalu lakukan backup, dan backup cadangan Anda.   - Mempekerjakan atau mengatur seseorang yang akan ada di saat seperti ini. Untuk mencegah siapa pun mengandalkan pada posting panik di Server   Kesalahan.


578
2018-01-02 21:31




Saya tahu bagaimana perasaan Anda - kami sangat beruntung dengan peretas "membantu" di situs ini, tempat mereka memberi tahu kami apa yang telah mereka lakukan! Saya menantikan jawaban yang bagus untuk pertanyaan ini, untuk berjaga-jaga jika kita mendapatkan tamu yang "tidak terlalu membantu" di masa depan. - Jarrod Dixon♦
Hubungi profesional untuk membantu! - marcog
Saya tidak ingin terdengar cerdas atau tidak simpatik (saya bukan orang yang baik), dan tentu saja saya tidak tahu detail situasi Anda, tetapi jika Anda adalah satu-satunya orang yang bertanggung jawab untuk pengaturan situs 500-600, mungkin ada menjadi kelemahan mendasar dalam bagaimana server ini dijalankan. Beberapa perusahaan menggunakan sysadmin khusus yang tidak melakukan hal lain sepanjang hari tetapi memelihara server - tugas yang mana tidak otomatis dalam lingkup programmer, meskipun mungkin tampak seperti itu. Mungkin itu sesuatu yang layak dipertimbangkan ketika krisis selesai. Bagaimanapun, saat ini, keberuntungan terbaik dalam menyelesaikan situasi di tangan. - Pekka 웃
Jangan selalu menganggap Anda memiliki kit root kernel lengkap dan bahwa kata sandi root Anda dikompromikan. Ini mungkin hanya skrip bash / perl licik, dan mungkin untuk membersihkannya tanpa memformat meskipun apa yang haru paduan suara di sini ... serverfault.com/questions/639699/ ... - Hayden Thring


Jawaban:


Sulit untuk memberikan saran spesifik dari apa yang telah Anda posting di sini, tetapi saya memiliki beberapa saran umum berdasarkan posting yang saya tulis sejak lama lalu ketika saya masih bisa repot-repot ke blog.

Jangan Panik

Pertama-tama, tidak ada "perbaikan cepat" selain memulihkan sistem Anda dari cadangan yang diambil sebelum gangguan, dan ini memiliki setidaknya dua masalah.

  1. Sulit untuk menentukan kapan intrusi terjadi.
  2. Itu tidak membantu Anda menutup "lubang" yang memungkinkan mereka untuk membobol terakhir kali, juga tidak berurusan dengan konsekuensi dari setiap "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-orang terus bertanya. Saya tidak yakin mengapa. Mungkin orang hanya tidak suka jawaban yang mereka lihat ketika mencari bantuan, atau mereka tidak dapat menemukan seseorang yang mereka percayai untuk memberi mereka 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 secara online dan kehilangan 95% pertanyaan dan menjawab di mana kasus mereka hampir sama seperti yang mereka baca online.

Itu membawa saya ke nugget informasi penting pertama. Saya sangat menghargai bahwa Anda adalah kepingan salju khusus yang unik. Saya menghargai bahwa situs web Anda juga, karena ini adalah cerminan dari Anda dan bisnis Anda atau setidaknya, kerja keras Anda atas nama perusahaan. Tetapi bagi seseorang di luar yang mencari tahu, apakah seorang petugas keamanan komputer yang melihat masalah untuk mencoba dan membantu Anda atau bahkan penyerang itu sendiri, sangat mungkin bahwa masalah Anda akan setidaknya 95% identik dengan setiap kasus lain yang mereka hadapi. pernah melihat.

Jangan mengambil serangan 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 waktu untuk membiarkan ego Anda menghalangi apa yang Anda butuhkan melakukan.

Anda baru saja mengetahui bahwa server Anda diretas. Sekarang apa?

Jangan panik. Benar-benar tidak bertindak tergesa-gesa, dan benar-benar jangan mencoba dan berpura-pura hal-hal tidak pernah terjadi dan tidak bertindak sama sekali.

Pertama: pahami bahwa bencana telah terjadi. Ini bukan saatnya untuk penolakan; ini adalah waktu untuk menerima apa yang telah terjadi, bersikap realistis tentangnya, dan mengambil langkah untuk mengelola konsekuensi dari dampaknya.

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 mengerikan tetapi kadang-kadang Anda harus mengabaikan bahwa jika Anda benar-benar ingin obatnya bekerja.

Menghentikan masalah agar tidak menjadi lebih buruk daripada yang sudah ada:

  1. Hal pertama yang harus Anda lakukan adalah memutus sambungan sistem yang terpengaruh dari Internet. Apa pun masalah lain yang Anda miliki, membiarkan sistem yang terhubung ke web hanya akan memungkinkan serangan berlanjut. Maksud saya ini secara harfiah; meminta seseorang untuk secara fisik mengunjungi server dan mencabut kabel jaringan jika memang itu yang diperlukan, tetapi putuskan hubungan korban dari peretasnya 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 disusupi. Tidak benar-benar. Semua akun. Semua komputer. Ya, Anda benar, ini mungkin berlebihan; di sisi lain, itu mungkin tidak. Anda tidak tahu cara baik, kan?
  3. Periksa sistem Anda yang lain. Bayar perhatian khusus ke layanan lain yang berhubungan dengan Internet, dan kepada mereka yang memegang data keuangan atau data sensitif komersial lainnya.
  4. Jika sistem menyimpan data pribadi siapa pun, segera beri tahu orang yang bertanggung jawab atas perlindungan data (jika itu bukan Anda) dan URGE pengungkapan penuh. Saya tahu ini sulit. Saya tahu ini akan terasa sakit. Saya tahu bahwa banyak bisnis ingin menyapu masalah semacam ini di bawah karpet tetapi bisnis akan harus menghadapinya - dan perlu melakukannya dengan mengawasi setiap dan semua undang-undang privasi yang relevan.

Betapapun jengkel pelanggan Anda adalah meminta 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 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 letakkan sistem yang terkena kembali online sampai tahap ini selesai sepenuhnya, kecuali jika Anda ingin menjadi orang yang pos tipping point bagi saya benar-benar memutuskan untuk menulis artikel ini. Saya tidak akan link ke posting itu sehingga orang bisa mendapatkan tawa murah, tetapi tragedi yang sebenarnya adalah ketika orang gagal untuk belajar dari kesalahan mereka.
  2. Periksa sistem yang 'diserang' untuk memahami bagaimana serangan berhasil mengorbankan keamanan Anda. Berusahalah untuk mencari tahu dari mana serangan "berasal", sehingga Anda memahami masalah apa yang Anda hadapi dan perlu diatasi untuk membuat sistem Anda aman di masa depan.
  3. Periksa sistem 'menyerang' lagi, kali ini untuk memahami ke mana perginya serangan, sehingga Anda memahami sistem apa yang dikompromikan dalam serangan itu. Pastikan Anda menindaklanjuti setiap petunjuk yang menyarankan sistem yang disusupi bisa menjadi batu loncatan untuk menyerang sistem Anda lebih jauh.
  4. Pastikan "gerbang" yang digunakan dalam setiap dan semua serangan sepenuhnya dipahami, sehingga Anda dapat mulai menutupnya dengan benar. (misalnya jika sistem Anda dikompromikan oleh serangan injeksi SQL, maka Anda tidak hanya perlu menutup baris kode tertentu yang rusak karena mereka melanggar, Anda ingin mengaudit semua kode Anda untuk melihat apakah jenis kesalahan yang sama dibuat di tempat lain).
  5. Memahami bahwa serangan mungkin berhasil karena lebih dari satu kelemahan. Seringkali, serangan berhasil tidak melalui menemukan satu bug utama dalam sistem tetapi dengan merangkai beberapa masalah (kadang-kadang kecil dan sepele sendiri) untuk berkompromi sistem. Misalnya, menggunakan serangan injeksi SQL untuk mengirim perintah ke server basis data, menemukan situs web / aplikasi yang Anda serang sedang berjalan dalam konteks pengguna administratif dan menggunakan hak akun tersebut sebagai batu loncatan untuk berkompromi dengan bagian lain dari sebuah sistem. Atau sebagai hacker suka menyebutnya: "hari lain di kantor mengambil keuntungan dari kesalahan umum orang membuat".

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

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

Satu-satunya cara tertentu bahwa Anda mengendalikan sistem adalah dengan 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 setelah penyusup mendapatkan kontrol (memang, ini bukan hal yang tidak pernah terdengar bagi peretas yang merekrut sistem menjadi botnet untuk menambal eksploit yang mereka gunakan sendiri, untuk menjaga "mereka" komputer baru dari peretas lain, serta menginstal rootkit mereka).

Buat rencana untuk pemulihan dan untuk membawa situs web Anda kembali online dan ikuti terus:

Tidak ada yang ingin offline lebih lama dari yang seharusnya. Itu sudah diberikan. Jika situs web ini adalah mekanisme penghasil pendapatan, maka tekanan untuk mengembalikannya ke internet dengan cepat akan sangat kuat. Bahkan jika satu-satunya yang dipertaruhkan adalah reputasi perusahaan Anda, ini masih akan menghasilkan banyak tekanan untuk mengembalikannya dengan cepat.

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

  1. Saya berasumsi Anda telah memahami semua masalah yang menyebabkan intrusi yang sukses di tempat pertama bahkan sebelum Anda memulai bagian ini. Saya tidak ingin melebih-lebihkan kasus tetapi jika Anda belum melakukannya terlebih dahulu maka Anda benar-benar perlu. Maaf.
  2. Jangan pernah membayar uang pemerasan / perlindungan. Ini adalah tanda yang mudah dan Anda tidak ingin ungkapan itu pernah digunakan untuk menggambarkan Anda.
  3. Jangan tergoda untuk menempatkan server yang sama kembali tanpa membangun ulang secara penuh. Akan jauh lebih cepat untuk membangun kotak baru atau "nuke server dari orbit dan melakukan instalasi bersih" pada perangkat keras lama daripada mengaudit setiap sudut sistem lama untuk memastikannya bersih sebelum meletakkannya kembali online lagi. Jika Anda tidak setuju dengan itu maka Anda mungkin tidak tahu apa artinya untuk memastikan sistem sepenuhnya dibersihkan, atau prosedur penyebaran situs web Anda adalah kekacauan yang tidak suci. Anda mungkin memiliki cadangan dan penerapan pengujian situs Anda yang dapat Anda gunakan untuk membangun situs langsung, dan jika Anda tidak diretas, itu bukan masalah terbesar Anda.
  4. Berhati-hatilah dengan menggunakan kembali data yang "hidup" pada sistem pada saat peretasan. Saya tidak akan mengatakan "jangan pernah melakukannya" karena Anda hanya akan mengabaikan saya, tetapi sejujurnya saya pikir Anda perlu mempertimbangkan konsekuensi dari menyimpan data jika Anda tahu Anda tidak dapat menjamin integritasnya. Idealnya, Anda harus mengembalikan ini dari cadangan yang dibuat sebelum intrusi. Jika Anda tidak dapat atau tidak akan melakukannya, Anda harus berhati-hati dengan data tersebut karena itu tercemar. Anda terutama harus menyadari konsekuensi kepada orang lain jika data ini milik pelanggan atau pengunjung situs daripada langsung kepada Anda.
  5. Pantau sistem dengan saksama. Anda harus memutuskan untuk melakukan ini sebagai proses yang berkelanjutan di masa depan (lebih lanjut di bawah) tetapi Anda harus ekstra hati-hati untuk waspada selama periode segera setelah situs Anda kembali online. Para penyusup hampir pasti akan kembali, dan jika Anda dapat melihat mereka mencoba menerobos lagi Anda pasti akan dapat melihat dengan cepat jika Anda benar-benar telah menutup semua lubang yang mereka gunakan sebelumnya ditambah apa pun yang mereka buat untuk diri mereka sendiri, dan Anda mungkin mengumpulkan berguna informasi yang dapat Anda sampaikan kepada penegak hukum setempat Anda.

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, penerapan dan pemeliharaan sistem yang menghadap Internet, bukan sesuatu yang dapat Anda tempelkan beberapa lapisan di atas kode Anda setelah itu seperti murah cat. Agar aman, layanan dan aplikasi harus dirancang dari awal dengan mempertimbangkan hal ini sebagai salah satu tujuan utama proyek. Saya menyadari itu membosankan dan Anda telah mendengar semuanya sebelumnya dan bahwa saya "tidak menyadari tekanan manusia" untuk mendapatkan layanan beta web2.0 (beta) Anda ke dalam status beta di web, tetapi faktanya adalah ini membuat diulangi karena itu benar ketika pertama kali dikatakan dan belum menjadi kebohongan.

Anda tidak dapat menghilangkan risiko. Anda seharusnya tidak mencoba melakukan itu. Namun apa yang harus Anda lakukan adalah memahami risiko keamanan mana yang penting bagi Anda, dan memahami cara mengelola dan mengurangi baik dampak risiko dan probabilitas bahwa risiko akan terjadi.

Langkah apa yang bisa Anda ambil untuk mengurangi kemungkinan serangan menjadi sukses?

Sebagai contoh:

  1. Apakah cacat yang memungkinkan orang untuk masuk ke situs Anda dikenal bug dalam kode vendor, yang patch tersedia? Jika demikian, apakah Anda perlu berpikir ulang pendekatan Anda tentang cara Anda menambal aplikasi di server Anda yang berhadapan dengan Internet?
  2. Apakah cacat yang memungkinkan orang untuk masuk ke situs Anda bug yang tidak dikenal dalam kode vendor, yang tambalannya tidak tersedia? Saya tentu saja tidak menganjurkan perubahan pemasok setiap kali sesuatu seperti ini menggigit Anda karena mereka semua memiliki masalah mereka dan Anda akan kehabisan platform dalam setahun paling banyak jika Anda mengambil pendekatan ini. Namun, jika sistem terus-menerus mengecewakan Anda maka Anda harus bermigrasi ke sesuatu yang lebih kuat atau setidaknya, rancang kembali sistem Anda sehingga komponen yang rentan tetap terbungkus dalam kapas dan sejauh mungkin dari mata yang tidak bersahabat.
  3. Apakah cacat bug dalam kode yang dikembangkan oleh Anda (atau kontraktor yang bekerja untuk Anda)? Jika demikian, apakah Anda perlu memikirkan ulang pendekatan Anda tentang bagaimana Anda menyetujui kode untuk penyebaran ke situs langsung Anda? Mungkinkah bug telah tertangkap dengan sistem pengujian yang ditingkatkan, atau dengan perubahan pada "standar" pengkodean Anda (misalnya, sementara teknologi bukan obat mujarab, Anda dapat mengurangi kemungkinan serangan injeksi SQL yang sukses dengan menggunakan teknik pengodean yang terdokumentasi dengan baik ).
  4. Apakah cacat karena masalah dengan bagaimana server atau perangkat lunak aplikasi dikerahkan? Jika demikian, apakah Anda menggunakan prosedur otomatis untuk membangun dan menyebarkan server jika memungkinkan? Ini adalah bantuan besar dalam menjaga kondisi "dasar" yang konsisten di semua server Anda, meminimalkan jumlah pekerjaan khusus yang harus dilakukan pada masing-masing dan karenanya diharapkan meminimalkan peluang untuk kesalahan yang harus dibuat. Sama halnya dengan penggunaan kode - jika Anda memerlukan sesuatu yang "khusus" untuk dilakukan untuk menerapkan versi terbaru aplikasi web Anda, maka cobalah keras untuk mengotomatiskan dan pastikan selalu dilakukan dengan cara yang konsisten.
  5. Mungkinkah intrusi tersebut telah ditangkap sebelumnya dengan pemantauan yang lebih baik terhadap sistem Anda? 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 web Anda untuk Anda dan memperingatkan Anda jika terjadi masalah. Anda mungkin memutuskan Anda tidak mampu membeli ini atau tidak membutuhkannya dan itu baik-baik saja ... hanya mempertimbangkannya.
  6. Gunakan alat seperti tripwire dan nessus jika sesuai - tetapi jangan hanya menggunakannya secara membabi buta karena saya mengatakan demikian. Luangkan waktu untuk mempelajari cara menggunakan beberapa alat keamanan yang baik yang sesuai dengan lingkungan Anda, terus perbarui alat-alat ini dan gunakan secara teratur.
  7. Pertimbangkan menyewa ahli keamanan untuk 'mengaudit' keamanan situs web Anda secara rutin. Sekali lagi, Anda mungkin memutuskan Anda tidak mampu membeli ini atau tidak membutuhkannya dan itu baik-baik saja ... hanya mempertimbangkannya.

Langkah apa yang bisa Anda ambil untuk mengurangi konsekuensi dari serangan yang sukses?

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

  1. Bisakah Anda mengurangi jumlah layanan yang langsung terpapar ke Internet? Dapatkah Anda mempertahankan semacam celah antara layanan internal Anda dan layanan internet Anda? Ini memastikan bahwa bahkan jika sistem eksternal Anda dikompromikan, kemungkinan menggunakan ini sebagai batu loncatan untuk menyerang sistem internal Anda terbatas.
  2. Apakah Anda menyimpan informasi yang tidak perlu disimpan? Apakah Anda menyimpan informasi semacam itu "online" saat 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 bahwa semakin sedikit Anda menyimpan, semakin sedikit Anda perlu mempertahankan dan kode untuk, dan jadi ada kemungkinan lebih sedikit untuk bug masuk ke kode atau desain sistem Anda.
  3. Apakah Anda menggunakan prinsip "setidaknya akses" untuk aplikasi web Anda? Jika pengguna hanya perlu membaca dari database, maka pastikan akun yang digunakan aplikasi web untuk layanan ini hanya memiliki akses baca, jangan ijinkannya 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 mengalihdayanya. Dengan kata lain, jika Anda menjalankan situs web kecil berbicara tentang menulis kode aplikasi desktop dan memutuskan untuk mulai menjual aplikasi desktop kecil dari situs kemudian mempertimbangkan "outsourcing" sistem pesanan kartu kredit Anda kepada seseorang seperti Paypal.
  5. Jika memungkinkan, lakukan 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 masalahnya sendiri yang berbeda dari "ruang server yang terbakar" / 'diserbu oleh server raksasa yang memakan hal-hal semacam furbies'.

... Dan akhirnya

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

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


988
2018-01-02 21:46



Memberi +1 untuk pos yang sangat baik agar ada di tangan untuk membuat orang mulai ke suatu arah. Saya tahu betapa umum bagi admin server amatir untuk masuk ke mode panik ini saat pertama kali mereka mengalami 'peretasan' terjadi pada mereka. Itu a besar sekali kesalahan berada di tempat itu, tetapi itu terjadi. Harapannya adalah ini tidak akan terjadi pada orang yang sama, dua kali. - Andrew Barber
+1 "... tapi ini bukan saatnya membiarkan ego Anda menghalangi apa yang harus Anda lakukan." Ini penting untuk Sys Admin untuk memahami kadang-kadang. Tidak peduli seberapa luas pengetahuan Anda, selalu ada orang-orang (kadang-kadang jahat) yang lebih berpengetahuan atau pintar dari Anda. - Grahamux
Jawaban yang bagus. Saya tidak yakin mengapa setiap orang memperlakukan "panggilan penegakan hukum" sebagai langkah opsional. Jika Anda bertanggung jawab atas data orang lain (dan mengkhawatirkan litigasi), ini harus menjadi salah satu hal pertama dalam daftar hal-hal yang harus Anda lakukan. - wds
Sangat baik menulis, hanya satu gotcha - "membuat pengungkapan penuh dan jujur ​​kepada siapa saja yang berpotensi terpengaruh sekaligus." Terhormat, tetapi tidak selalu benar. Dalam menanggapi kompromi, Anda mungkin perlu memotong beberapa sudut pemerintahan, dan perusahaan Anda biasanya akan memotong Anda beberapa kelonggaran, namun ... pengungkapan atau tidak, khususnya ketika ada implikasi Perlindungan Data mungkin masalah di atas tingkat gaji Anda dan bisa memiliki implikasi hukum. Mungkin lebih baik menyarankan Anda segera memberi tahu orang yang bertanggung jawab atas perlindungan data (jika bukan Anda) dan MENDAPAT pengungkapan penuh. - TheoJones
@GilesRoberts virtual mesin host biasanya memiliki panel kontrol yang memungkinkan Anda memanipulasi pengaturan tamu mereka, dan bahkan remote control mereka tanpa menggunakan RDP atau SSH untuk benar-benar masuk ke tamu. Anda harus dapat mengisolasi tamu menggunakan kontrol host untuk melakukannya kemudian menggunakan alat penglihat jarak jauh untuk menyelidiki tamu di waktu luang Anda. - Rob Moir


Kedengarannya seperti berada sedikit di atas kepala Anda; tidak apa-apa. Hubungi atasan Anda dan mulailah bernegosiasi untuk mendapatkan anggaran tanggap darurat darurat. $ 10.000 mungkin menjadi tempat yang baik untuk memulai. Maka Anda perlu mendapatkan seseorang (PFY, rekan kerja, manajer) untuk mulai menelepon perusahaan yang mengkhususkan diri dalam respons insiden keamanan. Banyak yang dapat merespon dalam 24 jam, dan terkadang lebih cepat jika mereka memiliki kantor di kota Anda.

Anda juga membutuhkan seseorang untuk memilah pelanggan; Tidak diragukan, sudah ada seseorang. Seseorang perlu 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 tertinggi. Dokumentasikan semua yang Anda lakukan, dan biarkan manajer dan tim eksekutif Anda mengetahui tindakan utama yang Anda ambil; ini termasuk bekerja dengan tim respons, menonaktifkan server, mencadangkan data, dan menghidupkan kembali semuanya. Mereka tidak membutuhkan detail yang mengerikan, tetapi mereka harus mendengar dari Anda setiap 30 menit atau lebih.

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

  3. Dapatkan USB stick yang bersih dan simpan hard drive. Anda akan mengumpulkan bukti di sini. Buat backup dari semua yang Anda rasa mungkin relevan; komunikasi dengan ISP Anda, jaringan pembuangan, dll. Bahkan jika penegak hukum tidak terlibat, dalam kasus gugatan Anda akan menginginkan bukti ini untuk membuktikan bahwa perusahaan Anda menangani insiden keamanan secara profesional dan tepat.

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

  5. Selanjutnya, Anda perlu menghapus penyerang dan menutup lubang (s). 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 baik lagi dengan menghapus drive dari server yang terpengaruh dan membuat salinan gambar disk lengkap), dan kemudian menghapus kode dan proses yang ditinggalkannya . Bagian selanjutnya ini akan menyedot jika Anda tidak memiliki backup; Anda dapat mencoba menguraikan penyerang dari sistem dengan tangan, tetapi Anda tidak akan pernah yakin bahwa Anda mendapatkan semua yang ia tinggalkan. Rootkit jahat, dan tidak semuanya dapat dideteksi. Respons terbaik adalah mengidentifikasi kerentanan yang ia gunakan untuk masuk, membuat salinan gambar dari disk yang terpengaruh, lalu menghapus sistem yang terpengaruh dan memuat ulang dari cadangan yang dikenal baik. Jangan membabi buta memercayai cadangan Anda; verifikasi itu! Perbaiki atau tutup kerentanan sebelum host baru masuk lagi ke jaringan, dan kemudian membawanya online.

  6. Atur semua data Anda ke dalam laporan. Pada titik ini, kerentanan tertutup dan Anda punya waktu untuk bernapas. Jangan tergoda untuk melewati langkah ini; bahkan lebih penting daripada proses lainnya. Dalam laporan, Anda perlu mengidentifikasi apa yang salah, bagaimana tanggapan tim Anda, dan langkah-langkah yang Anda ambil untuk mencegah kejadian ini terjadi lagi. Jadilah sedetail mungkin; ini bukan hanya untuk Anda, tetapi untuk manajemen Anda dan sebagai pembelaan dalam gugatan potensial.

Itu adalah ulasan setinggi langit tentang apa yang harus dilakukan; sebagian besar pekerjaan hanyalah dokumentasi dan penanganan cadangan. Jangan panik, kamu bisa melakukan itu. saya dengan kuat merekomendasikan Anda mendapatkan bantuan keamanan profesional. Bahkan jika Anda dapat menangani apa yang terjadi, bantuan mereka akan sangat berharga dan mereka biasanya datang 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 untuk situasi Anda. Semoga berhasil.


199
2018-01-02 22:16



+1 Jawaban bagus. Kedengarannya seperti OP tidak memiliki "tanggap darurat" yang ditentukan sebelumnya dan pos Anda, di antara hal-hal baik lainnya, harus mengarahkan mereka ke arah persiapan itu. - Rob Moir


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

Ringkasan singkat dari langkah-langkah dasar adalah ini.

  • Konsultasikan kebijakan keamanan atau manajemen Anda.
  • Dapatkan kontrol (ambil komputer offline)
  • Analisis intrusi, dapatkan log, bayangkan apa yang salah
  • Memperbaiki barang
    • Instal versi bersih dari sistem operasi Anda !!! Jika sistem telah dikompromikan, Anda tidak dapat mempercayainya, titik.
  • Perbarui sistem agar 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.   Perlu diingat bahwa jika mesin itu   dikompromikan, apa pun pada sistem itu   dapat dimodifikasi, termasuk   kernel, binari, datafiles,   proses yang berjalan, dan memori. Di   umum, satu-satunya cara untuk mempercayai itu   mesin bebas dari backdoors dan   modifikasi penyusup adalah menginstal ulang   operasi

Jika Anda tidak memiliki sistem yang sudah ada seperti tripwire tidak ada cara yang mungkin bagi Anda untuk 100% yakin bahwa Anda telah membersihkan sistem.


105
2018-05-08 09:02



Bahkan kemudian tripwire dapat tertipu dengan modul kernel dan semacamnya. Pasang kembali. - reconbot
Pertanyaan terkait tentang bagaimana menanggapi dalam krisis mungkin juga berguna di sini. - Zoredache


  1. Mengenali masalah. Baca log.
  2. Berisi. Anda telah memutus sambungan server, jadi itu sudah selesai.
  3. Membasmi. Instal ulang sistem yang terpengaruh, kemungkinan besar. Jangan hapus hard drive dari yang diretas, gunakan yang baru. Ini lebih aman, dan Anda mungkin perlu yang lama untuk memulihkan peretasan buruk yang tidak didukung, dan melakukan forensik untuk mencari tahu apa yang terjadi.
  4. Memulihkan. Instal apa pun yang dibutuhkan dan pulihkan cadangan untuk membuat klien Anda online.
  5. Mengikuti. Cari tahu apa masalahnya, dan mencegahnya terjadi lagi.

64
2018-01-02 21:49





Jawaban Robert "pil pahit" sangat tepat tetapi sangat generik (baik, seperti pertanyaan Anda). Kedengarannya 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 disusupi, tetapi juga menangani praktik terbaik untuk kami sendiri. Kami selalu memberi tahu klien kami yang disusupi untuk membangun kembali kecuali mereka tidak benar-benar yakin akan sifat kompromi. Tidak ada rute lain yang bertanggung jawab dalam jangka panjang.

Namun, Anda hampir pasti hanya korban dari script kiddy yang menginginkan pad peluncuran untuk serangan DoS, atau bouncer IRC, atau sesuatu yang sama sekali tidak terkait dengan situs dan data pelanggan Anda. Oleh karena itu sebagai tindakan sementara saat Anda membangun kembali, Anda dapat mempertimbangkan untuk memunculkan firewall keluar yang besar di kotak 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 disusupi 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 memberi penyerang akses ke data klien Anda. Karena Anda mengatakan bahwa Anda memiliki ratusan klien di satu komputer, saya kira Anda akan menjadi situs web brosur kecil untuk bisnis kecil, dan tidak ada 600 sistem e-niaga yang penuh dengan nomor kartu kredit. Jika itu terjadi, ini mungkin merupakan risiko yang dapat diterima untuk Anda, dan membuat sistem Anda kembali online lebih cepat daripada mengaudit 600 situs untuk bug keamanan sebelum Anda membawa apa pun kembali. Tetapi Anda akan tahu data apa yang ada di sana, dan seberapa nyaman Anda akan mengambil keputusan itu.

Ini benar-benar bukan praktik terbaik, tetapi jika bukan itu yang telah terjadi di perusahaan Anda sejauh ini, menggoyangkan jari Anda pada mereka dan meminta puluhan ribu poundsterling untuk tim SWAT karena sesuatu yang mungkin mereka rasakan adalah kesalahan Anda (betapapun tidak adil! ) tidak terdengar seperti opsi praktis.

Bantuan ISP Anda di sini akan sangat penting - beberapa ISP menyediakan server konsol dan lingkungan boot jaringan (pasang, tapi setidaknya Anda tahu apa jenis fasilitas yang harus dicari) yang akan membiarkan Anda mengelola server saat terputus dari jaringan. Jika ini sama sekali pilihan, mintalah dan gunakan.

Namun dalam jangka panjang Anda harus merencanakan membangun kembali sistem berdasarkan posting Robert dan audit setiap situs dan pengaturannya. Jika Anda tidak bisa mendapatkan sysadmin ditambahkan ke tim Anda, carilah a hosting terkelola Berurusan di mana Anda membayar ISP Anda untuk bantuan sysadminning dan respon 24 jam untuk hal semacam ini. Semoga berhasil :)


49
2018-01-03 13:48





Anda perlu menginstal ulang. Simpan apa yang benar-benar Anda butuhkan. Namun perlu diingat bahwa semua file runnable Anda mungkin terinfeksi dan dirusak. Saya menulis yang berikut ini dengan python: http://frw.se/monty.py yang menciptakan MD5-sumbs dari semua file Anda di direktori yang diberikan dan waktu berikutnya Anda menjalankannya, ia memeriksa apakah ada yang telah diubah dan kemudian menampilkan file apa yang 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.


38
2018-05-08 08:02



Jadi ... Anda telah menerapkan tripwire. - womble♦
Ya, ada yang salah dengan itu? - Filip Ekberg
+1 untuk mencabut, menganalisis (meminta seseorang untuk melakukan forensik nyata) dan menghapusnya - Oskar Duveborn
Mengingat pilihan antara skrip Python anonim dan solusi standar yang terdokumentasi, (agak) didukung, dipahami dengan baik, Anda berharap mereka akan memilih yang pertama? - tripleee


CATATAN: Ini bukan rekomendasi. Spesifik saya Respons Insiden protokol mungkin tidak tidak berlaku unmodified untuk memberikan kasus yang tidak sah.

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

Langkah pertama di kami Ketika Server Mendapat Protokol Terganggu aku s:

  1. Identifikasi bahwa penyerang dapat memperoleh root (hak istimewa tinggi)
  2. Lepaskan server yang terpengaruh. Jaringan atau kekuasaan? Tolong lihat diskusi terpisah.
  3. Periksa semua sistem lain
  4. Boot server yang terpengaruh (s) dari live cd
  5. (pilihan) Ambil gambar dari semua drive sistem dengan dd
  6. Mulailah melakukan forensik post-mortem. Lihatlah log, cari tahu waktu serangan, temukan file yang dimodifikasi pada waktu itu. Coba jawab Bagaimana? pertanyaan.

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

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


34
2018-05-18 22:36



-1 Cabut server dari power? Anda baru saja kehilangan setengah dari data forensik Anda! - Josh Brower
@Yosh, saya menyesuaikan jawaban saya - sekarang netral pada pertanyaan Apa yang Harus Dicabut. - Aleksandr Levchuk
Forensik RAM (mis. / Dev / shm) dapat membantu. Saya lebih suka mencabut kabel listrik (tetapi cobalah masuk dan rsync / proc right before). Kami juga dapat memperkenalkan snap snap VM sering sehingga forensik RAM akan mungkin. Alasan untuk pergi untuk kabel listrik adalah (1) Ketika Anda melakukan forensik dalam sistem diretas, Anda "melangkah di seluruh TKP"; (2) Kit root terus berjalan - tidak begitu sulit bagi yang jahat untuk melakukan sesuatu (misalnya penghapusan sistem) di Network Link Down peristiwa. Kyle Rankin dalam pengantar yang bagus untuk Forensik berbicara (goo.gl/g21Ok) disarankan menarik kabel daya. - Aleksandr Levchuk
Tidak ada satu ukuran yang cocok untuk semua protokol IR - Beberapa organisasi mungkin perlu menjaga sistem yang dikompromikan secara online untuk sementara waktu lebih lama, untuk alasan apa pun. (RAM & log temp forensik, berinteraksi dengan penyusup, dll) Maksud saya adalah bahwa akan lebih baik untuk merekomendasikan protokol IR umum (seperti Jakob Borgs di atas) daripada yang dimulai dengan "Tarik steker listrik dari server yang dikompromikan. " - Josh Brower


Dalam pengalaman saya yang terbatas, kompromi sistem di Linux cenderung lebih 'komprehensif' daripada di Windows. Root kit jauh lebih mungkin untuk memasukkan mengganti binari sistem dengan kode yang disesuaikan untuk menyembunyikan malware, dan penghalang untuk menambal panas kernel sedikit lebih rendah. Plus, ini adalah OS rumah untuk banyak pembuat malware. Panduan umum selalu untuk membangun kembali server yang terpengaruh dari awal, dan itu adalah pedoman umum karena suatu alasan.

Format anak anjing itu.

Tapi, jika Anda tidak dapat membangun kembali (atau kekuatan-yang-itu-tidak akan membiarkan Anda membangunnya kembali terhadap desakan Anda yang kuat yang dibutuhkannya), apa yang Anda cari?

Karena kedengarannya seperti itu sudah lama sejak intrusi itu ditemukan, dan pemulihan sistem telah dilakukan, sangat mungkin bahwa jejak bagaimana mereka masuk telah menginjak di injak untuk memulihkan layanan. Sangat disayangkan.

Lalu lintas jaringan yang tidak biasa mungkin yang paling mudah untuk ditemukan, karena itu tidak melibatkan menjalankan apa pun di kotak dan dapat dilakukan saat server dan melakukan apa pun. Dengan asumsi, tentu saja, perlengkapan jaringan Anda memungkinkan port-spanning. Apa yang Anda temukan mungkin atau mungkin tidak diagnostik, tetapi setidaknya itu adalah informasi. Mendapatkan lalu lintas yang tidak biasa akan menjadi bukti kuat bahwa sistem masih dikompromikan dan membutuhkan perataan. Mungkin cukup bagus untuk meyakinkan TPTB bahwa sebuah reformat benar-benar, sangat berharga untuk waktu henti.

Jika gagal, ambil dd-copy partisi sistem Anda dan mount 'em di kotak lain. Mulai membandingkan konten dengan server pada tingkat patch yang sama dengan yang dikompromikan. Ini akan membantu Anda mengidentifikasi apa yang tampak berbeda (yang md5sums lagi) dan mungkin menunjuk ke area yang diabaikan di server yang disusupi. Ini adalah BANYAK memilah-milah direktori dan binari, dan akan agak padat karya. Bahkan mungkin lebih padat karya daripada reformat / membangun kembali, dan mungkin hal lain untuk mencapai TPTB tentang benar-benar melakukan reformat yang benar-benar dibutuhkan.


28
2018-01-03 14:31



'Format anak anjing itu.' - +1, saran bijak. Lihat juga: "Nuke itu dari orbit, itu satu-satunya cara untuk memastikan." - Avery Payne