Kök ayrıcalıklarına sahip olmanın en güvenli yolu nedir: sudo, su veya login?

Ayrıcalıklı kullanıcım tehlikeye girse bile, kök hesabın güvenli olmasını istiyorum.

Ubuntu'da sudo'yu varsayılan olarak "güvenlik nedeniyle" kullanabilirsiniz. Ancak metin modu konsolunda oturum açmaktan daha güvenli olduğundan emin değilim. Bir saldırgan normal kullanıcım olarak kod çalıştırabilirse yanlış gidebilecek çok şey var. Örneğin takma adlar eklemek, PATH'ime bir şeyler eklemek, LD_PRELOAD ve X11 keylogger'larını sadece birkaç tanesini belirtmek için ayarlamak. Görebildiğim tek avantaj zaman aşımı süresidir, bu yüzden çıkış yapmayı asla unutmam.

Su hakkında aynı şüphelerim var ama zaman sınırı bile yok. Bazı işlemler (özellikle IO yönlendirmesi) su ile daha uyumludur ancak güvenlik açısından bu daha kötü görünmektedir.

Metin modu konsolunda oturum açmak en güvenli gibi görünüyor. Bir saldırganın PATH veya LD_PRELOAD'ı kontrol edip edemeyeceği, init tarafından başlatıldığından beri zaten köklüdür. Tuşa basma olayları X üzerinde çalışan programlar tarafından yakalanamaz. X üzerinde çalışan programların [ctrl] + [alt] + [f1] ile etkileşime girip giremeyeceğini bilmiyorum (ve bir konsol gibi görünen tam ekran bir pencere açabilir) veya Windows'ta [ctrl] + [alt] + [del] gibi güvenlidir. Bunun yanında gördüğüm tek problem zaman aşımı eksikliği.

Yani bir şey mi kaçırıyorum? Ubuntu adamları neden yalnızca sudo'ya izin vermeye karar verdi? Yöntemlerden birinin güvenliğini artırmak için ne yapabilirim?

Peki ya SSH? Geleneksel olarak root SSH ile giriş yapamaz. Ancak yukarıdaki mantığı kullanmak, yapılacak en güvenli şey olmaz:

• SSH aracılığıyla root'a izin ver
• metin moduna geçme
• root olarak giriş yapın
• diğer makineye ssh
• root olarak giriş yap?

Güvenlik her zaman değiş tokuş yapmakla ilgilidir. Tıpkı okyanusun dibindeki güvenli, fişsiz bir yerel sunucu gibi, hiç erişme imkânı rootolmasaydı en güvenli olurdu.

LD_PRELOAD ve PATH açıkladığınız gibi saldırılar, hesabınıza zaten veya en azından nokta dosyalarınıza erişimi olan bir saldırgan olduğunu varsayar. Sudo buna karşı çok iyi koruma sağlamaz - eğer şifreniz varsa, sonuçta, sizi daha sonra kandırmaya çalışmanıza gerek yok ... sadece sudo şimdi kullanabilirler .

Sudo'nun aslen neye göre tasarlandığını düşünmek önemlidir: belirli komutların (yazıcıları yönetenler gibi) tamamen kök salmadan, "alt yöneticiler" e (belki de bir laboratuarda mezun olan öğrenciler). Her şeyi yapmak için sudo kullanmak, şimdi gördüğüm en yaygın kullanımdır, ancak programın çözmesi gereken bir sorun değildir (bu yüzden gülünç karmaşık bir yapılandırma dosyası sözdizimi).

Ama, sınırlanmayan sudo-için kök yapar kök şifreleri yönetilebilirlik: Başka bir güvenlik sorunu ele. Pek çok organizasyonda, bunlar yazı tahtası gibi yazılmış, beyaz tahtalara yazılmış ve sonsuza dek aynı şekilde bırakılma eğilimindedir. Erişimi iptal etmek veya değiştirmek büyük bir üretim numarası haline geldiğinden, bu büyük bir güvenlik açığı bırakmaktadır. Hangi makinenin hangi parolaya sahip olduğunun izini sürmek bile bir zorluktur - hangisinin olduğunu bilen tek kişi izlemekten .

Unutmayın, çoğu "siber suç" içeriden geliyor. Açıklanan kök şifre durumu ile, kimin ne yaptığını bulmak zor - uzaktan kayıt işleminde bir sorun yaşanıyor.

Ev sisteminizde, iki şifreyi hatırlamak zorunda olmamanın kolaylığının meselesi olduğunu düşünüyorum. Pek çok insanın aynı olmalarını veya daha kötüsünü yapmalarını, başlangıçta aynı olmalarını ayarlamalarını ve ardından senkronizasyondan çıkmalarını ve kök şifresini çürümeye bırakma olasılıkları yüksek.

Parola kullanılması hiç şifre koklama trojansız ssh cinleri gördüğüm gerçek dünya sistemi uzlaşmalar% 90 gibi bir şey yerinde konur beri SSH için, tehlikelidir. SSH anahtarlarını kullanmak çok daha iyidir ve bu, uzaktan root erişimi için de uygulanabilir bir sistem olabilir.

Ancak, şu anki sorun, parola yönetiminden anahtar yönetime geçtiniz ve ssh anahtarları gerçekten çok kolay yönetilemiyor. Kopyaları kısıtlamanın bir yolu yoktur ve eğer birisi bir kopya çıkarırsa, parolayı kaba bir şekilde zorlamak için tüm girişimlerini yaparlar. Anahtarların çıkarılabilir cihazlarda depolanması ve yalnızca gerektiğinde monte edilmesi gerektiğini söyleyerek politika oluşturabilirsiniz, ancak bunu zorlamanın bir yolu yoktur - ve şimdi çıkarılabilir bir cihazın kaybolması veya çalınması olasılığını ortaya koydunuz.

En yüksek güvenlik tek seferlik anahtarlar veya zaman / sayaç tabanlı şifreleme belirteçlerinden geçiyor. Bunlar yazılımda yapılabilir, ancak kurcalamaya dayanıklı donanım daha da iyidir. Açık kaynaklı dünyada, WiKiD , YubiKey veya LinOTP var ve tabii ki özel ağır RSA SecurID de var . Orta ila büyük ölçekli bir kuruluşta veya güvenlik konusunda bilinçli bir küçük kuruluştaysanız, idari erişim için bu yaklaşımlardan birine bakmanızı şiddetle tavsiye ederim.

Olumlu güvenlik uygulamalarını takip ettiğiniz sürece, muhtemelen yönetim güçlüklerine sahip olmadığınız, muhtemelen ev için çok üzücü.

Bu çok karmaşık bir soru. mattdm zaten birçok noktayı kapsıyor .

Su ve sudo arasında, tek bir kullanıcı olduğunu düşündüğünüzde, su, şifrenizi bulmuş bir saldırganın hemen kök ayrıcalık kazanamayacağı konusunda biraz daha güvenlidir. Ancak tek gereken, saldırganın yerel bir kök deliği (nispeten nadir) bulması veya bir trojan kurması ve su çalıştırmanı beklemesidir.

Sudo, birden fazla kullanıcı olduğunda konsol oturum açma konusunda bile avantajlara sahiptir. Örneğin, bir sistem uzaktan kurcalamaya karşı korumalı günlüklerle yapılandırılmışsa, en son kimin sudo yaptığını (veya kimin hesabını riske attığını) her zaman bulabilirsiniz, ancak konsolda root şifresini kimin yazdığını bilmiyorsunuz.

Ubuntu'nun kararının kısmen basitliğin (hatırlanması gereken sadece bir parola) ve kısmen de paylaşılan makinelerde (işletme veya aile) güvenlik ve kimlik bilgisi dağıtımının kolaylığı ile ilgili olduğunu düşünüyorum.

Linux, kimlik doğrulama için güvenli bir dikkat anahtarına veya başka bir güvenli kullanıcı arayüzüne sahip değildir. Bildiğim kadarıyla OpenBSD bile yok. Kök erişimi konusunda endişeliyseniz, çalışan bir sistemden kök erişimini tamamen devre dışı bırakabilirsiniz: kök olmak istiyorsanız, bootloader komut isteminde bir şeyler yazmanız gerekir. Bu kesinlikle tüm kullanım durumları için uygun değildir. (* BSD'nin güvenlik seviyesi şu şekilde çalışır: yüksek güvenlik seviyesinde, güvenlik seviyesini düşürmek veya doğrudan monte edilmiş çiğ cihazlara erişmek gibi, yeniden başlatmadan yapamayacağınız şeyler vardır.)

Kök olma yollarını kısıtlamak her zaman güvenlik için bir kazanç değildir. Güvenlik triadının üçüncü üyesini hatırlayın : gizlilik , bütünlük , kullanılabilirlik . Kendinizi sisteminizden çıkarmak, bir olaya müdahale etmenizi engelleyebilir.

Güvenli OpenWall GNU / * / Linux dağıtımının tasarımcıları ( sukök olmak için) ve hakkındaki önemli görüşleri de dile getirdiler sudo. Bu konuyu okumak ilginizi çekebilir:

... maalesef hem su hem de sudo ustaca ama temelde kusurlu.

Hataları suve diğer şeyleri tartışmaktan başka, Solar Designer da kullanmak için belirli bir neden hedefliyor su:

Evet, root olarak giriş yapmak yerine "su root" una ortak sysadmin bilgeliği kullanılırdı. Sorulduğunda, aslında bu tercih için geçerli bir neden bulabilenler bu yaklaşımla elde edilen daha iyi hesap verebilirlik anlamına gelecektir. Evet, bu gerçekten bu yaklaşım lehine iyi bir sebep. Ama aynı zamanda tek olanı. ...(daha fazla oku)

Dağıtımlarında "varsayılan kurulumda tamamen SUID kök programlarından kurtuldu" (ör. Dahil su; ve bunun için yetenek kullanmıyorlar):

Sunucular için, insanların yeniden düşünmesi ve çoğu durumda, kullanıcıların su ve sudo kullanımına izin vermemeleri gerektiğini düşünüyorum. Kök olmayan ve doğrudan root olarak (iki ayrı oturum) giriş yapmak yerine eski "giriş yapma" ve sonra "sysadmin" bilgelik "köküne su veya sudo eklenmiş güvenlik yoktur. Aksine, ikinci yaklaşım, güvenlik açısından tek doğru yaklaşımdır:

http://www.openwall.com/lists/owl-users/2004/10/20/6

(Birden fazla sistem yöneticisinin hesap verebilirliği için, sistemin Owl'un yaptığı gibi root ayrıcalıklı hesaplarını desteklemesi gerekir.)

(X'li masaüstü bilgisayarlar için bu daha zor olur.)

Ayrıca kesinlikle uğraşmak zorundasın ...

Btw, onlar yerini almaya başladı suloginile msuloginbirden çok kök hesapları ile kurulum izin vermek: msuloginbir (bu bilgiler geliyor tek kullanıcı moduna geçerken aynı zamanda kullanıcı adı yazabilir (ve "hesap" koru) sağlayan Rusça bu tartışmanın ) .

Kullanmanın sudoher zaman çevre değişkenlerini koruduğunu varsayıyor gibi görünüyorsunuz , ancak bu her zaman böyle değildir. İşte sudo manpage'den bir alıntı:

Çevre değişkenleriyle baş etmenin iki farklı yolu vardır. Varsayılan olarak, env_reset sudoers seçeneği etkindir. Bu, env_check ve env_keep sudoers seçeneklerinin izin verdiği çağıran işlem değişkenlerine ek olarak, TERM, PATH, HOME, SHELL, LOGNAME, USER ve USERNAME içeren minimum bir ortamda komutların yürütülmesine neden olur. Ortam değişkenleri için etkili bir beyaz liste var.

Bununla birlikte, env_reset seçeneği sudoerlarda devre dışı bırakılmışsa, env_check tarafından açıkça reddedilmeyen tüm değişkenler ve env_delete seçenekleri, çağıran işlemden devralınır. Bu durumda, env_check ve env_delete bir kara liste gibi davranır. Tüm potansiyel olarak tehlikeli ortam değişkenlerini kara listeye almak mümkün olmadığından, varsayılan env_reset davranışının kullanılması teşvik edilir.

Her durumda, bash işlevi olarak yorumlanabildiği için () ile başlayan bir değere sahip ortam değişkenleri kaldırılır. Sudo'nun izin verdiği veya reddettiği ortam değişkenleri listesi, root olarak çalıştırıldığında sudo -V çıktısında bulunur.

Bu nedenle env_reset, etkinse (varsayılan), saldırgan sizin PATHveya diğer ortam değişkenlerinizi geçersiz kılamaz (özellikle korunmaları gereken değişkenlerin bir beyaz listesine eklemediğiniz sürece).

En güvenli yaklaşım, anahtarı saklamak için fiziksel bir cihaz kullanarak (en az) 2048 uzun tuşu (şifre girişi devre dışı bırakılmış) kullanarak ssh ile giriş yapmaktır.

Sadece biraz konu dışı bir şey eklemek istiyorum. (burada bir onay işareti '/ bin / su -' sonra)

Yukarıdaki "güvenlik" in güvence altına almak istediğimiz verilere de bağlanması gerektiğini düşünüyorum.

Güvence altına almak istersek farklı olacaktır ve olması gerekir: my_data, my_company_data, my_company_network.

Genellikle, güvenlik hakkında konuşursam, "veri güvenliği" ve yedekleme hakkında da konuşurum. Ayrıca hataya dayanıklı sistemler ve benzerleri de ekleyebiliriz.

Bu göz önüne alındığında, bir bütün olarak güvenliğin kullanılabilirlik, "veri güvenliği" ve güvenli bir sistemin uygulanması için gereken çaba arasındaki bir denge olduğunu düşünüyorum.

Ubuntu’nun hedefi nihai kullanıcıydı ve nihai kullanıcı: Sudo varsayılandır.

Fedora, daha çok sunucu odaklı olan RedHat'ın ücretsiz sürümüdür: Sudo, devre dışı bırakılmıştı.

Diğer dağıtımlar için doğrudan bilgim yok.

Şu anda, çoğunlukla fedora kullanıyorum. Ve eski tarz bir kullanıcı olarak asla 'su' yazmamıştım. Fakat tam olarak daktilo olmasam bile çok kısa bir süre içinde "/ bin / su -" yazabilirim. PATH değişkeni .. bir sorun olmamalıdır (yolu yazın). Ayrıca prensip olarak "-" (eksi) kullanıcı ortam değişkenlerimi silmeli ve sadece kök olanları yüklemelidir. yani bazı ekstra sorunlardan kaçınmak. Muhtemelen ayrıca LS_PRELOAD.

Geri kalanı için sanırım @ mattdm oldukça kesindi.

Ama doğru kutuya koyalım. Bir komut dosyası akıllı setinin verilerime erişebildiğini varsayın. Sence onunla ne yapacak? - Fotoğraflarımı yayınlamak? benim? - Kız arkadaşımın adını bulmaya ve porno sitelerini ziyaret ettiğimi söylemeye çalışıyorum?

Tek kullanıcı resminde en kötü iki durum: - Çocuk tüm verilerimi siliyor: eğlence ya da yanlışlıkla - Çocuk makinemi başka bir varlığa daha fazla saldırmak için kullanıyor. Veya benzer hedefler.

İlk olarak, yukarıda bahsettiğim gibi, yedekleme konusunda ağ güvenliğinden daha iyi çaba sarf etmek daha iyi. Evet, kurtardın. Demek istediğim bir donanım kazası o kadar da farklı değil.

İkinci vaka daha incedir. Ancak bu faaliyetlerle ilgili sinyaller var. Her durumda, mümkün olanı yapabilirsiniz, ancak ev bilgisayarımı terörist saldırılara karşı korunacak şekilde yapılandırmazdım!

Diğer senaryoları atlayacağım.

şerefe F

Endişe bir tehlikeye kullanıcı hesabı için kullanılan parolayı hissetmenize kullanılabileceğini ise sudoveya su, daha sonra da bir kerelik parolayı kullanması sudove su.

Uzak kullanıcılar için anahtar kullanmaya zorlayabilirsiniz, ancak bu uyumluluk açısından önemli olmayabilir. İki faktörlü kimlik doğrulama gerektiren bir SSH ağ geçidi kutusu ayarlamak ve ardından oradan anahtar kullanımına izin vermek daha etkili olabilir. İşte böyle bir kurulum ile ilgili dokümanlar : SSH dağıtımınızı WiKID iki faktörlü kimlik doğrulama ile güvenceye alın .

Ayrıca bir göz sürebilir privacyIDEA size sadece makineye giriş için OTP kullanma imkanı sağlamaz, (ya Herhangi yüzeylerin / sudo yapmak için) ama aynı zamanda OTP çevrimdışı yapabilirsiniz.

Ayrıca, SSH anahtarlarınızı yönetme yeteneğine de sahiptir. Yani, çok sayıda makineniz ve çok sayıda kök kullanıcınız varsa, tüm SSH anahtarları merkezi olarak depolanır. Bu nedenle, bir tuşa artık güvenilemiyorsa, bir SSH anahtarını "iptal etmek" / silmek kolaydır.

Tabii ki sistemi güvence altına almak için organizasyonel görevler ve iş akışları var.