Bir giriş kabuğu olarak / usr / sbin / nologin güvenlik amaçlı mıdır?

Benim içinde /etc/passwddosyanın, bunu görebiliyorum www-dataApache tarafından kullanılan kullanıcı, hem de sistem kullanıcıları her türlü durumda bulunacaktır /usr/sbin/nologinya /bin/falseda giriş kabuğu olarak. Örneğin, burada satırların bir seçim:

daemon:x:1:1:daemon:/usr/sbin:/usr/sbin/nologin
bin:x:2:2:bin:/bin:/usr/sbin/nologin
sys:x:3:3:sys:/dev:/usr/sbin/nologin
games:x:5:60:games:/usr/games:/usr/sbin/nologin
www-data:x:33:33:www-data:/var/www:/usr/sbin/nologin
syslog:x:101:104::/home/syslog:/bin/false
whoopsie:x:109:116::/nonexistent:/bin/false
mark:x:1000:1000:mark,,,:/home/mark:/bin/bash

Sonuç olarak, bu kullanıcılardan herhangi biriyle takas etmeye çalışırsam (bazen izinlerini anlamamı kontrol etmek istiyorum ve muhtemelen en azından yarıdan beri aklı başında nedenleri olan başkaları var), başarısız olurum:

mark@lunchbox:~$ sudo su www-data
This account is currently not available.
mark@lunchbox:~$ sudo su syslog
mark@lunchbox:~$ 

Tabii ki, bu pek sıkıntı verici bir durum değil, çünkü bunun gibi bir yöntemle onlar için bir kabuk açabilirim:

mark@lunchbox:~$ sudo -u www-data /bin/bash
www-data@lunchbox:~$ 

Ancak bu sadece bu kullanıcıların bir giriş kabuğu olduğunu inkar ederek hangi amaca hizmet edildiğini merak etmemi sağlıyor . Bir açıklama için internete bakarken, birçok insan bunun güvenlikle ilgisi olduğunu iddia ediyor ve herkes bu kullanıcıların giriş kabukları değiştirmenin bir şekilde kötü bir fikir olacağı konusunda hemfikir gibi görünüyor. İşte bir alıntı koleksiyonu:

Apache kullanıcısının kabuğunu etkileşimli olmayan bir şeye ayarlamak genellikle iyi bir güvenlik uygulamasıdır (gerçekten etkileşimli olarak giriş yapması gerekmeyen tüm servis kullanıcılarının kabukları etkileşimli olmayan bir şeye ayarlanmış olmalıdır).

- https://serverfault.com/a/559315/147556

www-data kullanıcısı için kabuk / usr / sbin / nologin değerine ayarlanır ve çok iyi bir sebepten dolayı ayarlanır .

- https://askubuntu.com/a/486661/119754

[sistem hesapları] , özellikle kabukları etkinleştirilmişse güvenlik delikleri olabilir :

• Kötü

  bin:x:1:1:bin:/bin:/bin/sh

• İyi

  bin:x:1:1:bin:/bin:/sbin/nologin

- https://unix.stackexchange.com/a/78996/29001

Güvenlik nedeniyle Tomcat sunucusunu çalıştırmak için giriş kabuğu olmayan bir kullanıcı hesabı oluşturdum:

# groupadd tomcat
# useradd -g tomcat -s /usr/sbin/nologin -m -d /home/tomcat tomcat

- http://www.puschitz.com/InstallingTomcat.html

Bu mesajlar, sistem kullanıcılarına gerçek giriş kabukları vermeme konusunda oybirliği ile kabul edilmekle birlikte, güvenlik için iyidir, bunlardan biri bu iddiayı haklı çıkarmaz ve bunun hiçbir açıklamasını bulamıyorum.

Bu kullanıcılara gerçek giriş kabukları vermeyerek kendimizi korumak için hangi saldırıya çalışıyoruz?

nologinMan sayfasına bir göz atarsanız aşağıdaki açıklamayı göreceksiniz.

alıntı

nologin, bir hesabın kullanılamadığını ve sıfır olmayan bir mesajdan çıktısını gösterir. Bir hesaba giriş girişini engellemek için yedek bir kabuk alanı olarak tasarlanmıştır.

Dosya /etc/nologin.txtvarsa, nologiniçeriğini varsayılan mesaj yerine kullanıcıya gösterir.

Döndürülen çıkış kodu nologinher zaman 1'dir.

Bu yüzden asıl amacı, nologinbir kullanıcı bir hesapla giriş yapmaya çalıştığında, onu kullanan bir hesapla giriş yapmayı denediği ve kullanmaya /etc/passwdçalışan tüm betikleri / komutları kullanmasıdır. Bu giriş 1 çıkış kodunu alır.

Güvenlik

Güvenlik ile ilgili olarak, genellikle o alandaki diğer şeylerin yanı sıra ya /sbin/nologinda bazen de görürsünüz /bin/false. Her ikisi de aynı amaca hizmet eder, ancak /sbin/nologinmuhtemelen tercih edilen yöntemdir. Her durumda, bu özel kullanıcı hesabı olarak bir kabuğa doğrudan erişimi sınırlandırıyorlar.

Bu neden güvenlik açısından değerli olarak kabul edilir?

“Neden” in tam olarak tanımlanması zordur, ancak bir kullanıcının hesabını bu şekilde sınırlandırmanın değeri, loginsöz konusu kullanıcı hesabını kullanarak erişim kazanmaya çalıştığınızda , uygulama üzerinden doğrudan erişimi engellemesidir.

nologinVeya ikisini kullanarak /bin/falsebunu başarır. Sisteminizin saldırı yüzeyini sınırlandırmak, belirli bağlantı noktalarında hizmetleri devre dışı bırakmak veya sistemlerinde oturum açma yapısını sınırlamak için güvenlik dünyasında yaygın bir tekniktir.

Yine de kullanmak için başka rasyonalizasyonlar vardır nologin. Örneğin, scpartık bu ServerFault Soru-Cevap bölümünde açıklandığı gibi gerçek bir kabuk belirtmeyen bir kullanıcı hesabıyla çalışmayacak: / sbin / nologin ve / bin / false arasındaki fark nedir? .

Kesinlikle bir güvenlik amacına hizmet ediyor. Örneğin, kabuğu olan bir sistem kullanıcısı için sunulan aşağıdaki hatayı inceleyin .

Debian sunucum, geçerli bir giriş kabuğuna ve samba'nın internet erişimine açık olması nedeniyle, daemon hesabının güvenliği altında kaldı. Giriş, daemon hesabı için samba üzerinden uzaktan bir şifre belirleyerek ve ssh aracılığıyla giriş yaparak gerçekleştirildi. Bazı yerel kök kullanımları daha sonra sunucumu KENDİ için kullandı.

Bu harika cevabı Gilles tarafından bazı hatalara bağlantı sağladığı için okumanızı tavsiye ederim .

Şu anda açık olan ve “dilek listesi” olarak sınıflandırılan Debian'da (274229, 330882, 581899) bu konuda dosyalanmış hatalar var. Bunların böcekler olduğu ve sistem kullanıcılarının, aksi takdirde yapılması gerekmedikçe kabukları olarak / bin / false kullanmaları gerektiği konusunda hemfikiriz.

@Slm ve @ramesh'ın mükemmel cevaplarına eklemek için:

Evet, belirttiğiniz gibi, hala sudotanımlanmış bir kabukla çalışarak varsayılan kabuk olarak nologin kullanan kullanıcılara geçebilirsiniz , ancak bu durumda yapmanız gereken:

1. Geçerli bir kabuğu olan başka bir kullanıcı olarak giriş yapın
2. Bu kullanıcının sukomutu çalıştırması için yapılandırılmış sudo izinlerinin olması
3. Su denemeniz sudoers günlüğüne kaydedilmişse (tabii ki sudo günlüğünün etkin olduğunu varsayarak).

Nologini varsayılan kabuğu olarak tanımlayan kullanıcılar genellikle daha yüksek ayrıcalıklara sahiptir / sisteme normal bir kullanıcıdan daha fazla zarar verebilir, bu nedenle sisteme giriş yapamayanların zarar verebileceği zararı sınırlama girişimlerini doğrudan girememelerini sağlamak .

Verilen mükemmel cevaplara ek olarak, başka bir amaca hizmet eder.

Sunucunuzda bir FTP arka plan programı çalıştırırsanız, giriş yapmaya çalışan kullanıcıların giriş kabuğunu kontrol eder. Kabuk listede /etc/shellsyoksa, giriş yapmalarına izin vermez. Bu nedenle, daemon hesaplarına özel bir kabuk vermek, birinin FTP üzerinden hesabı değiştirmesini önler.

Zaten verilen büyük cevapların yanında, aşağıdaki senaryoyu düşünebilirim.

Sınırlı bir kullanıcı olarak çalışan bir servisteki bir güvenlik hatası, o kullanıcı olarak bir dosya yazmaya izin verir. Bu dosya ~ / .ssh / yetkili_keys olabilir.

Bu, saldırganın doğrudan bir kabukta oturum açmasına izin verir ve bu da ayrıcalık yükselmesi gerçekleştirmeyi çok daha kolay hale getirir.

Giriş kabuğuna izin vermemek bu seçeneği çok daha zor hale getirir.

Genelde / bin / false ve / sbin / nologin’in aynı olduğunu söyleyebilirim - ama sanırım hangi SSH sunucusunu kullandığınıza bağlı.

OpenSSH’deki bu son istismarın / bin / false girişlerini etkilediğini fakat NOT / sbin / nologin’i etkilediği görülüyor. Bununla birlikte, Dropbear'ın bu şekilde farklı olduğunu belirtir (ayrıca istismar OpenSSH için de geçerlidir).

Exploit çoğu sürümü etkiler:

7.2p1 ve daha düşük (tüm sürümler; ~ 20 yıl öncesine kadar) X11 iletme etkin

https://www.exploit-db.com/exploits/39569/

Buna dayanarak - Ben şahsen / sbin / nologin yaparım, ancak bunun / etc / passwd içindeki / bin / false girdisini oluşturan hizmetleri etkileyebileceğinden emin değilim. Sonuçları deneyebilir ve görebilirsiniz, ancak lütfen bunu kendi sorumluluğunuzda yapın! Sanırım en kötü durumda, onu geri değiştirebilir ve herhangi bir etkileme hizmetini yeniden başlatabilirsiniz. Şahsen / bin / false kullanarak çok az sayıda girişim var - X11 iletmeyi etkinleştirdiğim bir şey olmadığı için bununla uğraşmak isteyip istemediğimden emin değilim;)

OpenSSH kullanıyorsanız (birçok kişi sanırım ...) VE X11 iletmeyi etkinleştirmişseniz - / sbin / nologin'i (veya belki de Dropbear'a geçebilirsiniz) düşünebilirsiniz.

Hizmet ve uygulama hesaplarını etkileşimli olmayan oturum açmaya ayarlamak genellikle iyi bir güvenlik uygulamasıdır. Yetkili bir kullanıcı SU veya SUDO kullanan bu hesaplara hala erişebilir, ancak işlemlerinin tümü Sudoers günlük dosyalarında izlenir ve hizmet hesabı ayrıcalıkları altında komutları yürüten kullanıcıya geri izlenebilir. Bu nedenle, günlük dosyalarını merkezi bir günlük yönetim sisteminde depolamak önemlidir, böylece sistem yöneticileri günlük dosyalarını değiştirmek için erişemez. SU veya SUDO altındaki komutları uygulayan kullanıcı zaten sisteme erişmeye yetkilidir.

Öte yandan, sisteme harici veya yetkisiz bir kullanıcı bu hesapları kullanarak giriş yapmak için tamamen erişemez ve bu bir güvenlik önlemidir.

Evet, bir güvenlik amacına hizmet ediyor. Bu derinlemesine savunma önlemi.

Bir amaca hizmet etmesinin temel nedeni, belirli bir kullanıcı için bazı giriş kimlik bilgilerini doğrulayacak ve daha sonra bir komutu çalıştırmak için o kullanıcının giriş kabuğunu kullanacak çeşitli yazılım parçalarının olmasıdır. Belki de en dikkate değer örnek SSH'dir. SSH üzerinden bir kullanıcı olarak başarılı bir şekilde kimlik doğrulaması yaparsanız, SSH kullanıcının oturum açma kabuğunu başlatır (veya ssh someuser@example.com 'command to run'sözdizimini kullanıyorsanız verdiğiniz komutu çalıştırmak için kullanır ).

Elbette, ideal olarak bir saldırgan bir kullanıcı olarak hiçbir şekilde kimliğini doğrulayamaz. Ancak aşağıdaki durumun gerçekleştiğini varsayalım:

• Kontrol ettiğiniz bir sunucu, bir web dizinini giriş dizini ve giriş kabuğu olan bir kullanıcı olarak çalıştırıyor
• Saldırgan, söz konusu hizmette saldırganın kullanıcının giriş dizinine dosya yazmasına izin veren bir güvenlik açığı keşfeder.

Artık saldırganınız bir SSH açık anahtarı ~/.ssh/authorized_keys, ardından SSH'ye ve - boom! - sunucunuza kabuk erişimi var.

Kullanıcı bunun yerine /usr/sbin/nologingiriş kabuğunu kullanıyorsa, saldırgan genel anahtarı başarıyla yazdıktan sonra bile authorized_keys, onlar için yararlı değildir. Yapmalarına olanak sağlayan tek şey, uzaktan kullanmanız nologin, ki bu pek kullanışlı değil. Kabuk alamıyorlar ve saldırıları hafifletildi.

Bu senaryonun varsayımsal görünmesi durumunda, bu soruyu sorduktan yaklaşık bir yıl sonra, tam da bu saldırı ile 2015'in bir noktasında hedef aldığımı belirtmek isterim . Lanet olası bir aptal gibi, dünyaya açık şifresiz bir Redis örneği bıraktım. Saldırganın Redis veritabanınıza bir SSH ortak anahtarı eklediği Redis crackit saldırısı ile hedeflendi, ardından Redis'e veritabanının içeriğini yazmasını söyleyen bir komut gönderir, ardından SSH'ye girmeye.ssh/authorized_keys çalışır. Sonuçlardan kurtarıldım. redis-serverApt paketinin (Redis'i kurardım) bakımcılarının Redis'i çalıştırmak için kullanma bilgisine sahip olmasından dolayı kendi beceriksizliğiminredisgiriş dizini veya giriş kabuğu olmayan kullanıcı; onlar için olmasaydı, sunucum fidye tehlikesiyle karşı karşıya kaldı ya da bazı bilgisayar korsanlarının botnetlerinin bir parçası haline geldi.

Bu deneyim bana biraz alçak gönüllülük verdi ve savunmanın derinlemesine ve özellikle de web sunucuları, veritabanları ve diğer arka plan servislerini çalıştıran hesaplara giriş kabukları vermemenin önemini takdir etmemi sağladı .