Kök kullanıcıyı devre dışı bırakmalı mıyız?


21

Kök şifresini kaldırmalı mıyız, uzaktan giriş yapmayı devre dışı bırakmalı mıyız ve temel olarak yöneticilerin idari işlemleri gerçekleştirmek için sudo kullanmasını mı istiyoruz?

alt metin

Yanıtlar:


16

Tüm sunucularımda root hesabı devre dışı bırakıldı (olarak sp_pwdpayarlandı *). Bu, sudotüm root erişimi için gereklidir . [1] Bunun amacı, tüm süper kullanıcı faaliyetlerini denetlemektir, böylece insanlar sisteme ne yapıldığını görebilir.

Daha sert bir seçenek için, sudobir günlük dosyasına (aksine syslog) yazma yapabilir ve dosyayı yalnızca append ( chattrLinux veya chflagsBSD kullanarak ) yapabilirsiniz. Bu şekilde daha sonra hiç kimse denetimi düzenleyemez.

[1] Ayrıca, bir kök kabuğunu çalıştırmama ya da bir kök işleminden kaçan kabuk yapma politikam var. (Yine de sudo sh -c '...', boru hatları veya yönlendirmeler yapmak için kullanmak sorun değil .)


3
"Mermilerin akması da yok!" Uhm, kaç tane programda "kabuğa bırak" komutunun olduğunu biliyor musun? Shell iş kontrolüne bakmadan önce bile ...
womble

Politika olarak "kabuksuz" dan bahsediyorum, sudo seçeneği olarak değil. (sudo noexec seçeneğine sahip değildir, ancak bir kullanıcının çalıştırabileceği belirli programları kısıtlamadığınız sürece açıkça su geçirmez değildir.)
Chris Jester-Young

Sudo'yu "sudo -s" kullanılamayacak şekilde yapılandırmak mümkün mü? Tek tek komutları yapılandırmak için sadece sudoer kullandım.

@ Graham: Yapabilirsin. Ancak, yukarıdaki yorumlardan görebileceğiniz gibi, kullanıcılarınız başka bir şeyi çalıştırabilirse bu hiçbir şeyi durdurmaz. Tek su geçirmez çözüm, kullanıcıların çalıştırabileceği belirli bir programı listelediğiniz ve hepsinin dinamik olarak birbirine bağlı olması gereken ("noexec" seçeneğinin işini yapabilmesi için) bir beyaz liste yaklaşımıdır.
Chris Jester-Young,

Yöneticilere güvendiğiniz bir politika olarak bu iyidir. İnsanların hangi komutları çalıştırdığını ve nelerin değiştiğini anlamaya çalışırken gerçekten yararlı olabileceklerini görebilirsiniz.
Hamish Downer

15

Kök kullanıcıyı devre dışı bırakmamaya şiddetle tavsiye ediyorum . Devre Dışı veya kısıtlamak kök giriş bilgileri (securetty aracılığı ile sshd_config aracılığı ile PAM ile ve sistem bunu, sınır root ayrıcalıkları izin ya da (nasıl benzer kök rolünü Eğer ayrılırsak yoluyla size ne) RSBAC edin. Öyle) Ama lütfen , do root hesabını şifresini kaldırarak etkisizleştirmeyin, aksi takdirde sisteme giriş yapmak imkansız hale gelir sulogin. suloginfsck tarafından bildirilen ciddi hatalar durumunda bildiğim tüm initscripts tarafından kullanılır - ve bu, kök dosya sistemi bozulursa sistemden kilitleneceğiniz anlamına gelir.

Netleştirmek için: "Parolayı kaldırarak kök hesabın devre dışı bırakılması" ile, a! veya / etc / shadow veya benzeri bir şifre alanındaki a *. "Kök oturum açma mekanizmasını değiştir, böylece şifreni istemeyeceksin" demek istemiyorum.


Ubuntu gibi sistemlerde hiç bir zaman root şifresi ayarlamayan bir problem mi? "Sudo sulogin" i uygulayabiliyor gibi görünüyorum ama belki de kritik bir yönü anlamadım.
jldugger

Maalesef, Ubuntu'nun kökü yönetme şeklini bilmiyorum. Fakat eğer "sudo sulogin" yapabilir ve bir root şifresi istenmeden bir kök kabuğu alabilirseniz, o zaman hayır, bir problem değildir, çünkü aynı mekanizma önyüklemede uygulanabilir. Ne zaman ve nasıl çağrıldığını kontrol etmek için sulogin için yazı yazarken grepping'i deneyebilirsiniz.
Mihai Limbăşan

1
Ubuntu sulogin kullanmaz. Tek kullanıcı moduna geçerseniz derhal bir kök kabuğu alırsınız. Bununla birlikte, çoğu durumda, bunun neden sorun olmadığını görmek için yorumumu (yazımda) okuyun.
Chris Jester-Young,

Ayrıca iddialar sahip olduğunu vardır suya sudokullanıcıların araçlarına mevcut sisteminizde daha fazla güvenlik, yalnızca özel kök kullanıcıları varsa önleyebilirsiniz riske atar. Bu, Owl'un güvenli dağıtımının (ve aralarındaki Güneş Tasarımcısı) yazarlarının savunduğu bir pozisyon - unix.stackexchange.com/questions/8581/… konumlarını referanslarla sunmaya çalışıyor.
imz - Ivan Zakharyaschev

Ben sadece bu çok sorun vardı: Ben kök kullanıcımı kilitledim ve zor bir sıfırlama nedeniyle bir fsck zorlandı. Neyse ki hatalı Linux'umu bu fastbootseçenekle başlatabilir, kök hesabın kilidini açabilir ve sonunda fsckmanuel olarak çalışmaya başlayabilirim .
tommyd

3

Tüm sunucularımda root hesabım etkin. Tüm yöneticilerin kendi kullanıcıları var ve bu sayede oturum açmak zorundalar. Oradan köke geçer. (root ssh devre dışı bırakıldı)

Yönetici sayısını düşük tutun. Yalnızca bu sunucuda kök erişime gerçekten ihtiyacı olan kişiler şifreye sahiptir.

Ben bir sudo hayranı değilim. Kök kabuğu için sadece 'sudo bash' yapmak çok kolay. Bunun devre dışı bırakılabileceğini biliyorum ama neden rahatsız ediyorsun? Yönetici görevlerini yerine getirebilecek kullanıcıları sınırlayın ve birbirleriyle konuşun. Kök uçbirimlerinin katılımsız olarak açılmasına izin vermeyecek bir politikamız var. Yani giriş yap, su, işi yap, çıkış yap.

Not: Oldukça küçük bir şirkette (50 kişilik bir çalışan) çalışıyorum ve sadece 2 yarı zamanlı yönetici (1 pencere / 1 linux) ile uğraşıyoruz. Bu tür şeyler yapmanın yolu daha büyük kullanıcı siparişleriniz olduğunda en iyi olmayabilir. Şahsen ben hala sudo kullanmazdım. Kök aktivitesini kaydetmenin başka yolları da var.


Bir konsoldan kök kabuğu istiyorsanız, sudo bash'dan açmak yerine 'sudo -i' komutunu kullanabilirsiniz. Şahsen ben doğrudan kötüye kullanıcı olarak giriş yapma fikrinden hoşlanmıyorum, çünkü kötüye gitmemesi için çok risklidir (yani, yanlışlıkla bilgisayarı kök kabuğunu açık bırakarak açık bırakarak).
Spoike

Bununla birlikte, günlük kaydını / denetimini kaybedersiniz. Herkesin sudo kullanmasını sağlayın ve kişilerin şirket politikası ile sudo bash veya sudo -i veya sudo-s yapmalarını yasaklayın. Bu size bir denetim izi sağlar ve tüm günlüklerinizi merkezi bir loghost'a itiyorsanız, insanların politikaları takip ettiğini doğrulamak kolaydır.
Christopher Cashell

Owl güvenli dağıtımının yazarları (ve aralarındaki Solar tasarımcı) tarafından alınan ve savunulan yaklaşım budur - unix.stackexchange.com/questions/8581/… konumlarını referanslarla sunmaya çalışır.
imz - Ivan Zakharyaschev

2

Kök şifresini devre dışı bırakmak yanlış bir "iyi fikir" dır. İhtiyacın olacak gün, gerçekten ihtiyacın olacak. (yapılandırmanıza göre, örnek olarak tek kullanıcı modunda oturum açmanız gerekebilir)

Kök uzaktan girişini devre dışı bırakmak alakalı olabilir, ancak yalnızca yerel olarak oturum açabiliyorsanız.

Ve evet, sudo sunucularınızın her birine kurulmalıdır. Kullanışlı ve yapılandırması kolaydır. Neden kullanmak istemiyorsun?


Tek kullanıcı moduna geçmek bir grub seçeneği ise ne olur?
jldugger

Kök hesabın devre dışı bırakılmasının amacı nedir? Fren sudo ikili sisteminizi veya konfigürasyonunuzu (veya hangi aracı kullanıyorsanız) frenlerseniz ne yapacaksınız?
Benoit

Disabling root remote login might be relevant but only if you are able to log on locally.Bu sadece açıkça yanlış. Herhangi bir hesapla uzaktan giriş yapabilirsiniz ; root uzaktan girişini devre dışı bırakmak sizi yerel erişim ile sınırlandırmaz.
Dan

2

Sadece root için SSH erişimini devre dışı bırakıyorum ve kullanıcıların (genellikle sadece geliştiricilerin) ssh anahtarlarını kullanmasını istiyorum. Çok fazla sözlük saldırısı var ve SSH portunu değiştirmek bizim için bir seçenek değil.

Bu şekilde kimsenin iyi bir şifre yazma yeteneğine güvenmek zorunda değilsiniz. Bir keresinde sadece yöneticilerin sudo için izinleri var.


SSH portunu değiştirmek yine de anlamsız. Basit bir portscan onu kolayca veriyor. Makinemdeki 22 numaralı bağlantı noktasına telnet yaptığımda, SSH-2.0-OpenSSH_4.7p1 Debian-8ubuntu1.2
Matt Simmons

@MattSimmons Evet, ancak çoğu sözlük saldırısı otomatik ve çok basit. Port taraması ile uğraşmazlar; 22 numaralı bağlantı noktasındaki rastgele IP adreslerine bağlanmaya çalışırlar ve zaman aşımına uğrarlarsa listesindeki bir sonraki IP'ye geçer. Bu bir güvenlik önlemi değil, sadece otomatik 22 numaralı liman saldırısından kurtulmaya yardımcı oluyor. Açıkçası, hedefli bir saldırı tamamen farklı bir ballgame.
Dan

2

Bu iş parçacığının gerçekten eski olduğunu biliyorum ama bağlantılı makaleler mantığında bazı önemli kusurlar var ve "rant'ie" hissediyorum - sudo hem beyaz listeye hem de kara listeye izin veriyor. Bağlantılı makalede belirtildiği gibi yalnızca siyah değildir - Bu, AAA (Kimlik Doğrulama, Yetkilendirme ve Denetim) fikrini atlar - su & sudo hem dereceli kimlik doğrulama hem de hesap verebilirlik için izin verir.

Senaryo 1 Bir yönetici yanlışlıkla bir sisteme bazı kodlar girer, kodun erişimi tamamen kökü olarak oturum açmışsa ve yönetici ne olduğunu asla bilemeyebilir. En azından derecelendirilmiş girişlerde (örn. Su / sudo) yöneticiden, sahte kodun yükseltilmiş haklar kullanmaya çalışıp çalışmadığını doğrulaması istenir ... Yükseltilmezse, minimum zararla sonuçlanması gereken kullanıcı haklarıyla sınırlandırılır.

Senaryo 2 Bir sahte yönetici bilgi almak / değişiklik yapmak ister. Konsola bağlanırlar (fiziksel konsol erişimi, HP iLo / Similar veya vGuest konsol erişimi), root olarak giriş yapın ve ne isterlerse yapın. Konsol erişimini elde etmek için kullanılan bir hesap / erişim kartı olmadıkça, büyük olasılıkla bir denetim izi kalmaz.

  1. Gerçekten söyledikleri kişi olduklarından emin olun. Kimlik hırsızlığı sorun değil, kimlik doğrulama.
  2. Yetkilerini kontrol edin, yalnızca o zaman onlara ihtiyaç duydukları şeyi verin. Kademeli yetkilendirme, ihtiyaç duyduklarında yükselmelerini sağlar.
  3. Hepsini denetleyin, kayıt olun böylece kim, ne, ne zaman ve nerede yaptığını bilirsiniz. Tercihen neden de

1

Politika olarak herkesin her root komutu için sudo kullanmasını istemelisin. Hiçbir zaman "sudo bash" veya benzeri bir şey çalıştırmak için bir sebep yoktur, bu yalnızca cehalet nedeniyle veya kişinin izlerini örtmek için kolaylık sağlamak içindir.

Doğrudan kök hesaba girişleri devre dışı bırakırsanız, ciddi sorunlar olduğunda sistemi tamir etme kabiliyetini kaybedersiniz.

Yöneticilerinizi kendileri gibi giriş yapmaları ve kök olarak çalıştırılan her komut için sudo çalıştırmaları ve bir kabuğun içine girmemeleri için ikna edemiyorsanız, teknik bir çözümü olmayan ciddi sorunlarınız vardır.


1

Owl güvenli dağıtımının (ve Solar tasarımcısının) yazarları, dikkatlice gerekçelendirilmiş bir bakış açısına sahiptir; Örneğin yanıtı görmek /unix/8581/which-is-the-safest-way-to-get-root-privileges-sudo-su-or-login/8660#8660 için iddialarının bir sunum. Süper kullanıcı eylemlerini denetleme sorunu (hangi kişinin ne yaptığını) de kendi bakış açılarıyla ele alınır (temelde çözüm, farklı isimlerle birkaç kök kullanıcısı olmaktır).

Sitemizi kullandığınızda şunları okuyup anladığınızı kabul etmiş olursunuz: Çerez Politikası ve Gizlilik Politikası.
Licensed under cc by-sa 3.0 with attribution required.