'Bin' kullanıcısı neden bir giriş kabuğuna ihtiyaç duyuyor?

/var/log/auth.logHerkese açık web sunucularımdan birinin denetimi sırasında , şunu buldum:

Jan 10 03:38:11 Bucksnort sshd[3571]: pam_unix(sshd:auth): authentication failure; 
    logname= uid=0 euid=0 tty=ssh ruser= rhost=61.19.255.53  user=bin
Jan 10 03:38:13 Bucksnort sshd[3571]: Failed password for bin from 61.19.255.53 
    port 50647 ssh2

İlk bakışta, bu sshrasgele korsanlardan gelen tipik giriş spam gibi görünüyor ; Ancak, daha yakından baktığımda başka bir şey fark ettim. Çoğu başarısız /var/log/auth.loggiriş invalid user, onlarda şöyle yazıyor :

Jan  9 10:45:23 Bucksnort sshd[3006]: Failed password for invalid user sales 
    from 123.212.43.5 port 10552 ssh2

Söz konusu başarısız giriş mesajla ilgili huzursuzluk şey binbir olduğudur geçerli kullanıcı içinde /etc/passwdbile olan bir giriş kabuğu:

[mpenning@Bucksnort ~]$ grep ^bin /etc/passwd
bin:x:2:2:bin:/bin:/bin/sh

Ben devre dışı olduğunda uzaktan oturum olabilir tüm varsayılan kullanıcı adlarını kaplamıştı düşünce PermitRootLoginiçinde /etc/ssh/sshd_config; Bu girişi keşfetmek paranoyak aklımda yeni olanaklar açtı. Eğer bir şekilde servisler altına girdiyse bin, o zaman birinin uzaktan kumandadan binçalışan bir servisten kullanıcının dizinine bir ssh anahtarını bir şekilde ssh anahtarını ekleyebilmesi mümkün olabilir , bu yüzden binmümkünse kullanıcı için giriş yapmayı tamamen devre dışı bırakmak istiyorum.

Sorular

• Bu sunucu uzak ve düzeltilmesi pahalı (yani uzak ellere KVM bağlaması ve KVM kiralama ücreti ödeyeceğim). Bu şekilde görünmek için /etc/passwdgirişi değiştirirsem neyi kırabileceğimi anlamaya çalışıyorum bin:

  bin:x:2:2:bin:/bin:/bin/false

• Neyin bingerekli olduğunu bulmaya çalışırken aşağıdaki komutları koştum ... Ancak, bu komutlar dosyasız geldi ve sahip olduğum hiçbir işlem bulamadım bin. binKullanıcı yine de ne yapar ?

  $ sudo find / -group bin

  $ sudo find / -user bin

• Giriş kabukları ayarlanmış olması gereken başka kullanıcılar var /bin/falsemı? Bilginize, ben zaten var /bin/falseüzerinde www-data.

• Çok fazla paranoyak mı oluyorum?

Eğer önemliyse Debian'ı çalıştırıyorum.

Geçerli bir kabuğu olan ve parolası olmayan bir kullanıcı, en yaygın olanı ssh anahtarı olan parola tabanlı olmayan yöntemlerle giriş yapabilir. Cron işlerini çalıştırmak için geçerli bir kabuk gereklidir. Geçerli bir kabuk su bin -c 'wibble'çalışması için de gereklidir (en azından Linux'ta su bin -s /bin/sh -c 'wibble'da çalışacaktır).

Böyle bir durumda bin, çoğu sistem binnormal işletimde olduğu gibi hiçbir zaman bir komut çalıştırmaz, bu nedenle kabuğu ayarlamak /bin/falseiyi olur.

binSSH üzerinden oturum açmaya izin veren doğrudan saldırı riski yoktur , çünkü bu /bin/.ssh/authorized_keyskullanıcı binveya root olarak oluşturulmayı gerektirir . Başka bir deyişle, içeri girmenin tek yolu içeri girmektir. Ancak geçerli bir kabuğa sahip olmak yanlış yapılandırma riskini artırır. Ayrıca SSH dışındaki servislerle yapılan bazı uzak saldırılara da izin verebilir; örneğin, bir kullanıcı bir saldırganın Samba üzerinden uzaktan bir şifre belirleyebileceğini bildiriyor ve daemonardından SSH üzerinden oturum açmak için bu şifreyi kullanıyor.

SSH deliğini, sistem kullanıcılarının adlarını bir DenyUsersyönerge içinde listeleyerek bağlayabilirsiniz /etc/ssh/sshd_config(ne yazık ki, sayısal bir aralık kullanamazsınız). Veya bunun yerine, bir AllowGroupsyönerge koyabilir ve yalnızca fiziksel kullanıcıları içeren gruplara izin verebilirsiniz (örneğin users, tüm fiziksel kullanıcılarınıza grup üyeliğini verirseniz).

Ş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öcek olduğu ve /bin/falseaksi takdirde yapılması gerekmediği sürece sistem kullanıcılarının kabukları kadar olması gerektiği konusunda hemfikiriz .

Kullanıcılar olarak endişelenmenize gerek yok. Güvenlik grupları anlamında "kullanıcılar" dırlar, "giriş yapın ve kullanın" anlamındaki kullanıcılar değillerdir. Eğer "/ etc / shadow" 'a bakarsanız, tüm bu "kullanıcıların" şifrelerinin (uzun bir tuzlu karık yerine "x" veya "!") Olmadığını göreceksiniz. Bu, ne olursa olsun, bu kullanıcıların giriş yapamayacağı anlamına gelir.

Bu, tüm bu kullanıcılar için "/ bin / sh" yi "/ bin / false" olarak değiştirmenin iyi bir fikir olup olmadığını bilmiyorum. Programlar bu gruplar altında çalıştığından, ihtiyaç duydukları komutları uygulamalarına izin vermeyebilir. Onları "/ bin / sh" olarak bırakırdım.

Bu kullanıcılar için endişelenmenize gerek yok. Yalnızca kendi oluşturduğunuz kullanıcılar için endişelenin (ve "/ etc / shadow" öğesinde karma olanlar var)

Bunun bir sorun olmadığına inanıyorum, çünkü SSH'nin genel anahtarını binev dizininde ( /bin) kurmak için saldırganın dosya sistemine kök erişimi olması gerekiyor, bu da yine de berbat olduğunuz anlamına geliyor.

İsterseniz bin, MatchUserbloğu kullanarak sshd'nin config dosyasındaki tüm kimlik doğrulama yöntemlerini devre dışı bırakabilirsiniz .

Bununla birlikte, çöp kutusu kullanıcısı modern Debian'dan türetilmiş sistemlerde kullanılmamış gibi görünüyor ve tamamen bir geleneğe bayılıyor ya da bazı standartlara uyum için orada bulunuyor.