it-swarm-tr.com

Kök ayrıcalıklarını almanın en güvenli yolu hangisidir: Sudo, su veya login?

Ayrıcalıklı kullanıcım tehlikeye girmiş olsa bile root hesabının güvenli olmasını istiyorum.

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

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

Bir metin modu konsolunda oturum açmak en güvenli gibi görünüyor. Bir saldırganın PATH veya LD_PRELOAD'u kontrol edip edemeyeceği init tarafından başlatıldığından zaten köktür. Tuşa basma olayları X üzerinde çalışan programlar tarafından engellenemez. X üzerinde çalışan programların [ctrl] + [alt] + [f1] tuşlarına müdahale edip edemeyeceğini bilmiyorum (ve konsol gibi görünen bir tam ekran penceresi açıp açamayacağımı) veya Windows'ta [ctrl] + [alt] + [del] gibi güvenlidir. Bunun yanında gördüğüm tek sorun zaman aşımı eksikliğidir.

Yani bir şey mi kaçırıyorum? Ubuntu adamları neden sadece sudo'ya izin vermeye karar verdiler? Herhangi bir yöntemin güvenliğini artırmak için ne yapabilirim?

SSH ne olacak? Geleneksel olarak kök SSH üzerinden oturum açamaz. Ancak yukarıdaki mantığı kullanmak, yapılacak en güvenli şey değildir:

  • sSH üzerinden köke izin ver
  • metin moduna geç
  • root olarak giriş yap
  • ssh diğer makineye
  • root olarak giriş yap?
124
stribika

Güvenlik her zaman takas yapmakla ilgilidir. Tıpkı okyanusun dibindeki güvenli, takılı olmayan bir atasözü sunucusu gibi, root varsa en güvenli hiçbir şekilde erişemedi.

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

Sudo'nun başlangıçta ne için tasarlandığını düşünmek önemlidir: özel komutların (yazıcıları yönetenler gibi) "alt yöneticilere" (belki de lisans öğrencileri) laboratuvarda) tamamen kök vermeden. Her şeyi yapmak için Sudo'yu kullanmak şu anda gördüğüm en yaygın kullanımdır, ancak programın çözmek istediği sorun olması gerekmez (bu nedenle gülünç derecede karmaşık yapılandırma dosya sözdizimi).

Ancak, kısıtlanmamış kök için Sudo başka bir güvenlik sorununu ele alıyor: root şifrelerinin yönetilebilirliği. Birçok organizasyonda, bunlar şeker gibi etrafa aktarılır, beyaz tahtalara yazılır ve sonsuza dek aynı kalır. 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ırakır. Hangi makinenin hangi parolaya sahip olduğunu anlamak bile zor - kimin hangisini bildiğini izlemeniz yeterli.

Çoğu "siber suçun" içeriden geldiğini unutmayın. Açıklanan kök parola durumu ile, kimin ne yaptığını izlemek zordur - uzaktan günlüğe kaydetme ile bir şey oldukça iyi olan Sudo.

Ev sisteminizde, bence bu daha çok iki şifreyi hatırlamak zorunda kalmamanın kolaylığı meselesi. Birçok kişinin basitçe aynı olmalarını veya daha kötü olmalarını, başlangıçta aynı olmalarını sağlamaları ve ardından senkronizasyondan çıkmalarını sağlayarak kök şifresini çürümeleri olasıdır.

SSH için parolalar kullanmak tehlikelidir, çünkü parola koklayan truva atlı ssh cinleri gerçek dünyadaki sistemin güvenliğinin% 90'ı gibi bir şeye yerleştirilir. Gördüm. SSH anahtarlarını kullanmak çok daha iyidir ve bu, uzaktan kök erişimi için de uygulanabilir bir sistem olabilir.

Ancak sorun şu ki, şifre yönetiminden anahtar yönetimine geçtiniz ve ssh anahtarları gerçekten çok yönetilebilir değil. Kopyaları kısıtlamanın bir yolu yoktur ve birisi kopya çıkarsa, parolayı kaba kuvvetle zorlamak istedikleri tüm girişimleri yaparlar. Anahtarların çıkarılabilir aygıtlarda depolanması ve yalnızca gerektiğinde monte edilmesi gerektiğini belirten bir ilke oluşturabilirsiniz, ancak bunu zorlamanın bir yolu yoktur - ve şimdi çıkarılabilir bir aygıtın kaybolması veya çalınması olasılığını tanıttınız.

En yüksek güvenlik, bir kerelik anahtarlar veya zaman/sayaç tabanlı kriptografik belirteçlerden gelecektir. Bunlar yazılımda yapılabilir, ancak kurcalamaya dayanıklı donanım daha da iyidir. Açık kaynak dünyasında WiKiD , YubiKey veya LinOTP ve elbette tescilli ağır siklet RSA SecurID . Orta ila büyük ölçekli bir kuruluşta, hatta güvenlik bilincine sahip küçük bir kuruluştaysanız, idari erişim için bu yaklaşımlardan birine bakmanızı kesinlikle öneririm.

Bununla birlikte, mantıklı güvenlik uygulamalarını takip ettiğiniz sürece, yönetim sorunlarına gerçekten sahip olmadığınız ev için muhtemelen aşırı derecede ağır.

105
mattdm

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

Su ve Sudo arasında, tek bir kullanıcı olduğunu düşündüğünüzde, su parolanızı bulan bir saldırganın hemen kök ayrıcalıkları elde edememesi açısından biraz daha güvenlidir. Ancak tek gereken, saldırganın yerel bir kök deliği bulması (nispeten nadir) veya bir truva atı kurması ve su çalıştırmanızı beklemesidir.

Sudo, birden fazla kullanıcı olduğunda konsol girişinde bile avantajlara sahiptir. Örneğin, bir sistem uzak kurcalamaya dayanıklı günlüklerle yapılandırılmışsa, her zaman en son Sudo'yu kimin çalıştırdığını (veya hesabının güvenliği ihlal edildiğini) öğrenebilirsiniz, ancak konsolda kök parolayı kimin yazdığını bilmezsiniz.

Ubuntu'nun kararının kısmen basitlik (hatırlanması gereken tek bir şifre) ve kısmen de paylaşılan makinelerde (iş veya aile) güvenlik ve kimlik bilgisi dağıtımı kolaylığıyla ilgili olduğundan şüpheleniyorum.

Linux'un kimlik doğrulama için güvenli bir dikkat anahtarı veya başka bir güvenli kullanıcı arabirimi yoktur. Bildiğim kadarıyla OpenBSD'de bile yok. Kök erişimi konusunda endişeleriniz varsa, çalışan bir sistemden kök erişimini tamamen devre dışı bırakabilirsiniz: kök olmak istiyorsanız, bootloader İstemi'ne bir şeyler yazmanız gerekir. Bu açıkça tüm kullanım durumları için uygun değildir. (* BSD'ler securelevel şu şekilde çalışır: yüksek güvenlik düzeyinde, yeniden başlatmadan yapamayacağınız şeyler vardır, örneğin güvenlik seviyesini düşürmek veya monte edilen ham cihazlara doğrudan erişmek gibi.)

Birinin kök haline gelme yollarını sınırlamak her zaman güvenlik için bir kazanç değildir. güvenlik üçlüsü : gizlilik , bütünlük , kullanılabilirliğinin . Kendinizi sisteminizden çıkarmak, bir olaya yanıt vermenizi engelleyebilir.

Güvenli OpenWall GNU/*/Linux dağıtımının tasarımcıları da su (kök olmak için) ve Sudo hakkında kritik görüşler dile getirdiler. Bu konuyu okumak ilginizi çekebilir:

... ne yazık ki hem su hem de Sudo ustaca ama temelde kusurlu.

su ve diğer şeylerin kusurlarını tartışmanın yanı sıra, Solar Designer da su kullanmak için belirli bir nedeni hedefliyor:

Evet, eskiden root olarak giriş yapmak yerine "su root" için yaygın bir sistem bilgeliğiydi. Sorulduğunda, aslında bu tercih için geçerli bir neden bulabilecek olanlar, bu yaklaşımla elde edilen daha iyi hesap verebilirliğe atıfta bulunacaktır. Evet, bu gerçekten bu yaklaşım lehine iyi bir neden. Ama aynı zamanda tek. ...(daha fazla oku)

Dağıtımlarında "varsayılan kurulumda tamamen SUID kök programlarından kurtuldular" (yani, su dahil; ve bunun için yetenek kullanmıyorlar):

Sunucular için, insanların su ve Sudo'nun kullanıcılar tarafından çağrılmasını yeniden düşünmeleri ve çoğu durumda reddetmeleri gerektiğini düşünüyorum. Kök olmayan ve doğrudan kök olarak (iki ayrı oturum) oturumla karşılaştırıldığında, eski "root olmayan, sonra su veya Sudo" root "sysadmin" bilgelik "için ek 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 çok sistem yöneticisinin hesap verebilirliği için, sistemin Baykuş gibi birden çok kök ayrıcalıklı hesaba sahip olmasını desteklemesi gerekir.)

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

Ayrıca kesinlikle uğraşmak zorunda ...

BTW, çoklu kök hesaplarla kuruluma izin vermek için sulogin ile msulogin değiştireceklerdi: msulogin kullanıcı adına da yazabilir tek kullanıcı moduna girerken (ve "hesap verebilirliği" korurken) (bu bilgi Rusça'daki bu tartışma ).

Sudo kullanmanın her zaman ortam değişkenlerini koruduğunu varsayıyorsunuz, ancak durum her zaman böyle değildir. Sudo man sayfasından bir alıntı:

Ortam değişkenleriyle başa çıkmanın 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ğırma işlemindeki değişkenlere ek olarak, komutların TERM, PATH, HOME, Shell, LOGNAME, USERNAME ve USERNAME içeren en az bir ortamla yürütülmesine neden olur. Ortam değişkenleri için etkili bir beyaz liste var.

Bununla birlikte, env_reset seçeneği sudo kullanıcılarında devre dışı bırakılırsa, env_check ve env_delete seçenekleri tarafından açıkça reddedilmeyen değişkenler çağırma işleminden devralınır. Bu durumda, env_check ve env_delete bir kara liste gibi davranır. Potansiyel olarak tehlikeli ortam değişkenlerinin tümünü kara listeye almak mümkün olmadığından, varsayılan env_reset davranışının kullanılması teşvik edilir.

Her durumda, değeri () ile başlayan ortam değişkenleri bash işlevleri olarak yorumlanabildikleri için kaldırılır. Sudo'nun izin verdiği veya reddettiği ortam değişkenleri listesi, kök olarak çalıştırıldığında Sudo -V çıktısında bulunur.

Eğer env_reset etkinleştirilir (varsayılan), saldırgan PATH veya diğer ortam değişkenlerinizi geçersiz kılamaz (özellikle korunması gereken değişkenlerin bir beyaz listesine eklemezseniz).

4
Cedric

En güvenli yaklaşım, anahtarı saklamak için fiziksel bir cihaz kullanarak (en az) 2048 uzun anahtar (parola oturum açma devre dışı) kullanılarak ssh oturum açmadır.

4
Šimon Tóth

Biraz konu dışı bir şey eklemek istiyorum. (bir konu için buraya '/ bin/su -' işaretini okuyun)

Yukarıdaki "güvenlik" in güvenliğini istediğimiz gerçek verilere de bağlanması gerektiğini düşünüyorum.

Güvenceye almak istiyorsak farklı olacak ve farklı olmalı: verilerim, şirketim_ verilerim, şirketim_netim.

Genellikle güvenlik hakkında konuşursam, "veri güvenliği" ve yedekleme hakkında da konuşurum. 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 sistem uygulamak için gereken çaba arasında bir denge olduğunu düşünüyorum.

Ubuntu'nun hedefi son kullanıcıydı ve çoğunlukla da son kullanıcıydı: Varsayılan Sudo.

Fedora, RedHat'ın daha fazla sunucu odaklı olan ücretsiz versiyonudur: Sudo eskiden devre dışı bırakıldı.

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

Şu anda çoğunlukla Fedora kullanıyorum. Ve eski stil kullanıcısı olarak asla 'su' yazmadım. Ama tam olarak daktilo olmasam bile çok kısa sürede "/ bin/su -" yazabilirim. PATH değişkeni .. bir sorun olmamalı (yolu yazıyorum). Ayrıca prensipte "-" (eksi) kullanıcı ortam değişkenlerimi kaldırmalı ve sadece kök değişkenleri yüklemelidir. yani ekstra olası sorunlardan kaçınmak. Muhtemelen LS_PRELOAD da.

Geri kalanı için @mattdm oldukça hassas olduğunu düşünüyorum.

Ama doğru kutuya koyalım. Bir komut dosyası akıllı kitinin verilerime eriştiğini varsayın. Onunla ne yapacağını düşünüyorsun? - Resimlerimi yayınla? benim? - Kız arkadaşımın adını bulmaya ve ona porno sitelerini ziyaret ettiğimi söylemeye mi çalışıyorsun?

Tek kullanıcılı resimde en kötü iki durum şunlardır: - Çocuk tüm verilerimi siler: eğlence için veya yanlışlıkla - Çocuk, makinemi başka bir varlığa daha fazla saldırı oluşturmak için kullanır. Veya benzer hedefler.

İlk durumda, yukarıda bahsetmiştim, ağ güvenliği yerine bir yedekleme için daha iyi çaba sarf ettim. Evet, kurtarıyorsun. Yani bir donanım çökmesi o kadar da farklı değil.

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

Diğer senaryoları atlayacağım.

şerefe F

3
user5520

Endişe, Sudo veya su için kullanılan şifreyi koklamak için güvenliği ihlal edilmiş bir kullanıcı hesabı kullanılabiliyorsa, Sudo ve su.

Uzak kullanıcılar için anahtar kullanımını zorlayabilirsiniz, ancak bu uyumluluk amacıyla toplanmayabilir. İki faktörlü kimlik doğrulaması gerektiren bir SSH ağ geçidi kutusu kurmak daha etkili olabilir, ardından oradan anahtar kullanımına izin verebilir. İşte böyle bir kurulumla ilgili doküman: SSH dağıtımınızı WiKID iki faktörlü kimlik doğrulaması ile güvenli hale getirin .

2
nowen

Ayrıca privacyIDEA 'a da göz atabilirsiniz, bu da size makinede oturum açmak için OTP kullanma (veya su/Sudo yapmak için) değil, aynı zamanda OTP'yi çevrimdışı olarak da yapabilirsiniz.

Ayrıca SSH anahtarlarınızı yönetebilir. Yani çok sayıda makineniz ve birkaç kök kullanıcınız varsa, tüm SSH anahtarları merkezi olarak depolanır. Bu nedenle, anahtara artık güvenilemiyorsa, bir SSH anahtarını "iptal etmek"/silmek kolaydır.

Elbette sistemi güvence altına almak için kurumsal görevler ve iş akışları vardır.

0
cornelinux