Ganti nama / etc / passwd dan / etc / shadow untuk alasan keamanan [ditutup]


8

Saya punya server. Server saya adalah aman, tetapi mari kita bayangkan seorang hacker yang baik yang masuk dalam. Dia sekarang dapat melihat ke dalam /etc/passwddan /etc/shadow. Saya ingin mengubah nama file itu /etc/passwdmenjadi sesuatu seperti /etc/xxanoda.

Saya pikir saya bisa melakukan tautan, tetapi bagi seorang peretas itu akan mudah dilakukan ls -l.

Dimungkinkan untuk mengganti nama file-file tersebut dan masih memiliki OS yang berjalan, tanpa masalah kompatibilitas, atau sama sekali tidak berguna? Hanya untuk mencari ilmu.


1
Saya pikir mungkin untuk menggunakan server otentikasi terpisah, untuk menampung semua kata sandi pengguna. Server utama akan menghubungi server otentikasi, ketika pengguna mencoba masuk. Server otentikasi dijauhkan dari pengguna (tidak ada akses internet langsung).
ctrl-alt-delor

9
Keamanan dengan ketidakjelasan sama sekali bukan keamanan.
Gagang pintu

Ini adalah ide yang mengerikan , mengerikan , mengerikan .
Shadur

Jawaban:


29

The Filesystem Hierarchy Standard untuk unix-seperti sistem termasuk /etc/passwddi lokasi tetap, dan alat-alat yang akibatnya biasanya hardcoded untuk melihat di sana untuk itu. Sementara secara teori Anda dapat mengkompilasi ulang semua utilitas yang relevan untuk mencari di lokasi baru, penyerang apa pun selalu dapat hanya mencari string dalam biner-biner itu untuk menemukan file baru, atau menggunakan ekspresi reguler untuk menemukan file dengan passwdkonten-suka.

The shadowfile harus dibaca hanya untuk root(dan mungkin untuk sebuah kelompok yang disebut shadow). Jika seorang penyerang telah berhasil mendapatkan akses root ke sistem Anda, mereka memiliki kontrol penuh dan apakah mereka dapat membaca file passwd / shadow Anda atau tidak cukup relevan pada saat itu.

Mungkin ada beberapa situasi di mana memiliki file yang tidak di tempat yang diharapkan dapat membantu, misalnya jika Anda memiliki server web yang tidak terkonfigurasi yang memungkinkan seseorang meminta http://myserver/../../etc/passwd, tetapi secara umum tipuan semacam ini akan memerlukan banyak pekerjaan untuk keuntungan keamanan minimal.


8
Dalam skenario kasus terakhir lebih baik untuk memperbaiki server web sebagai gantinya ...
Braiam

Tapi tidak apa-apa karena semua pengguna dengan akun di server itu sendiri tidak memiliki kata sandi, hanya kunci SSH, dan informasi kata sandi tidak disimpan/etc/passwd , toh ?
Blacklight Shining

12

Hal terbaik yang akan terjadi adalah "sama sekali tidak berguna" seperti yang Anda katakan. (Itu tidak memberikan rintangan tambahan untuk penyusup)

/etc/passwd memang mengandung nama akun, tetapi siapa pun yang memiliki akses shell ke sistem akan dapat menemukannya.

/etc/shadowberisi informasi sensitif (hash kata sandi) tetapi hanya dapat dibaca untuk root. Jika seorang penyusup berhasil mendapatkan hak root - baik bagaimana Anda mengeja bencana ?


1
Anda juga harus menganggap penyerang memiliki akses penuh ke setiap file di sistem Anda (dan mungkin mengunduh salinannya sendiri) sampai Anda tahu sebaliknya.
Bert

4
"Bagaimana kamu mengeja bencana?" mungkin bekerja lebih baik dalam konteks di mana Anda tidak perlu mengeja bencana untuk menanyakannya: D

9

Dalam Unices modern (dan Unix-likes, termasuk Ubuntu), /etc/passwdtidak mengandung rahasia apa pun. Mengganti nama itu akan lebih banyak masalah daripada nilainya, mengingat berapa banyak utilitas harus dibangun kembali untuk mencarinya di lokasi baru.

/etc/shadowadalah masalah lain, karena ada rahasia dalam file itu, tetapi mengubah nama itu tidak akan membantu. Itu hanya dapat dibaca oleh root, jadi bahkan jika seorang hacker masuk ke sistem seperti beberapa pengguna lain, itu tidak cukup untuk sampai ke file. Inilah sebabnya mengapa kata sandi dikeluarkan /etc/passwd: setiap orang harus dapat membaca /etc/passwd, tetapi hanya root yang harus bisa mendapatkan kata sandi yang sebenarnya, sehingga kata sandi dipindahkan ke file yang hanya dapat dibaca oleh root.

Jika hacker tidak mendapatkan root, kemudian mengubah nama tidak akan menyelamatkan Anda. Rekursif sederhana grepdapat memberi hacker daftar file dalam /etc/shadowformat seperti, dan kemudian peretas hanya perlu melihat melalui mereka untuk menemukan data yang dia inginkan. Anda telah menunda dia paling lama beberapa jam, dan mungkin lebih sedikit: sekali lagi, tidak sepadan dengan jumlah waktu yang diperlukan untuk memodifikasi dan mengkompilasi ulang semua utilitas yang bergantung pada /etc/shadowlokasi.


Selain itu, jika dia punya akses root, dia tidak / butuh / kata sandi orang lain. Ia dapat sumasuk ke akun apa pun yang diinginkannya, atau ia dapat mengubah kata sandi setiap pengguna di sistem. Dan jika ia benar-benar ingin memiliki kata sandi (kalau-kalau pengguna menggunakan kembali kata sandi mereka di tempat lain) ia dapat mengunggah loginbiner yang dimodifikasi atau menambahkan pammodul yang memotong upaya otentikasi dan menyampaikan kombinasi nama pengguna / kata sandi kepadanya.
Shadur

2

Anda tidak bisa hanya mengganti nama file-file ini. Banyak proses dan program akan mencarinya, karena ini adalah standar dalam sistem Linux. Yang dapat Anda lakukan adalah mengamankan server Anda dengan cara yang benar.


saya hanya ingin menambahkan lebih banyak keamanan, saya memiliki lebih dari satu situs web di server saya.
Marco Caggiano

2

Meskipun mungkin tidak ada gunanya untuk mengubah nama /etc/passwddan /etc/shadowfile, jika Anda ingin menambahkan keamanan, Anda mungkin ingin melihat PAM (modul otentikasi pluggable) dan NSS (Name Service Switch). Seperti di sini.

PAM dapat digunakan untuk menambahkan modul otentikasi itu, sebagai gantinya membaca informasi otentikasi mereka dari file standar, membacanya dari sumber lain, seperti dari ldap atau database. Menggunakannya akan berarti /etc/shadowhampir bisa dihilangkan.

NSS melengkapi PAM dengan membuat beberapa resolusi nama (seperti grup mana yang dimiliki oleh pengguna ini) independen dari file standar ( /etc/passwd, /etc/groups). Menggunakannya berarti file passwd Anda berpotensi hanya berisi opsi fallback untuk root, dan tidak lebih. Menggunakan kunci SSH untuk memvalidasi login root juga akan menghilangkan kebutuhan untuk memiliki kata sandi root di dalam file shadow (meskipun mungkin diinginkan jika koneksi SSH rusak).

Atau jika Anda tidak ingin mengautentikasi pengguna Anda melalui database atau host ldap yang terpisah, Anda juga dapat membuat modul PAM dan NSS Anda sendiri, yang membaca data mereka dari file yang tidak standar, walaupun saya tidak akan merekomendasikan opsi ini.

Ketika Anda ingin mencoba menggunakannya jangan pernah lupa untuk menyimpan semacam fallback ke lapisan otentikasi yang dikenal, jika tidak, Anda dapat mengunci diri dari sistem, bahkan dengan root.

Perhatikan bahwa tidak semua aplikasi mendukung PAM (banyak yang melakukannya). Namun NSS dapat digunakan untuk mengimplementasikan otentikasi untuk aplikasi yang tidak mendukung PAM, dan beberapa situs yang saya baca tentang NSS sebenarnya menyarankan pendekatan ini. Namun ini berarti bahwa modul NSS akan menyediakan kata sandi (yang berpotensi) di-hash kepada siapa saja yang dapat mengakses lapisan otentikasi NSS, yang hampir selalu merupakan sesuatu yang ingin Anda hindari (pada dasarnya sama dengan memberikan akses baca non-root ke file shadow )! Jadi, jika Anda menggunakan pendekatan ini, pastikan NSS hanya digunakan untuk menyediakan data dasar (seperti konten /etc/passwd) kepada pengguna, dan PAM digunakan sebagai lapisan otentikasi.

Dengan menggunakan situs kami, Anda mengakui telah membaca dan memahami Kebijakan Cookie dan Kebijakan Privasi kami.
Licensed under cc by-sa 3.0 with attribution required.