O / usr / sbin / nologin como um shell de login atende a uma finalidade de segurança?

Question

No meu arquivo /etc/passwd , posso ver que o usuário www-data usado pelo Apache, bem como todos os tipos de usuários do sistema, tem /usr/sbin/nologin ou /bin/false como seu shell de login. Por exemplo, aqui está uma seleção de linhas:

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

Consequentemente, se eu tentar trocar para qualquer um desses usuários (o que eu às vezes gostaria de fazer para verificar minha compreensão de suas permissões, e quais são provavelmente outras razões pelo menos sensatas), eu falho: / p>

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

Claro, não é muito inconveniente, porque ainda posso lançar um shell para eles por meio de um método como este:

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

Mas isso me deixa imaginando o que propósito é servido, negando a esses usuários um shell de login. Procurando por uma explicação na internet, muitas pessoas afirmam que isso tem algo a ver com segurança, e todo mundo parece concordar que seria de alguma forma uma má idéia mudar as camadas de login desses usuários. Aqui está uma coleção de citações:

Setting the Apache user's shell to something non-interactive is generally good security practice (really all service users who don't have to log in interactively should have their shell set to something that's non-interactive).

- link

the shell for the user www-data is set to /usr/sbin/nologin, and it's set for a very good reason.

- link

[system accounts] can be security holes, especially if they have a shell enabled:

• Bad

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

• Good

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

- link

For security reasons I created a user account with no login shell for running the Tomcat server:

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

- link

Embora esses posts sejam unânimes em concordar que não dar aos usuários do sistema um verdadeiro login é bom para a segurança, nenhum deles justifica esta afirmação, e não consigo encontrar uma explicação sobre isso em nenhum lugar.

Qual ataque estamos tentando nos proteger, não dando a esses usuários verdadeiros inventários?

    

Answer 1

Se você der uma olhada na página nologin man, verá a seguinte descrição.

trecho

nologin displays a message that an account is not available and exits non-zero. It is intended as a replacement shell field to deny login access to an account.

If the file /etc/nologin.txt exists, nologin displays its contents to the user instead of the default message.

The exit code returned by nologin is always 1.

Assim, a intenção real de nologin é apenas quando um usuário tenta fazer login com uma conta que faz uso dele no /etc/passwd , para que seja apresentada a uma mensagem amigável e que qualquer scripts / comandos que tentam fazer uso deste login recebem o código de saída de 1.

Segurança

Com relação à segurança, você normalmente verá /sbin/nologin ou às vezes /bin/false , entre outras coisas nesse campo. Ambos servem o mesmo propósito, mas /sbin/nologin é provavelmente o método preferido. Em qualquer caso, eles estão limitando o acesso direto a um shell como essa conta de usuário específica.

Por que isso é considerado valioso em relação à segurança?

O "porquê" é difícil de descrever completamente, mas o valor de limitar a conta de um usuário dessa maneira é que ele impede o acesso direto por meio do aplicativo login quando você tenta obter acesso usando a conta de usuário mencionada.

Usar nologin ou /bin/false faz isso. Limitar a superfície de ataque do seu sistema é uma técnica comum no mundo da segurança, seja desativando serviços em portas específicas ou limitando a natureza dos logins em seus sistemas.

Ainda existem outras racionalizações para usar nologin . Por exemplo, scp não funcionará mais com uma conta de usuário que não designa um shell real, conforme descrito neste ServerFault Q & A intitulado: Qual é a diferença entre / sbin / nologin e / bin / false? .

    

Answer 2

Definitivamente, ele serve a um propósito de segurança. Por exemplo, veja o bug abaixo arquivado para um usuário do sistema que tinha um Concha.

My debian server was compromised due to the daemon account having a valid login shell and having samba open for internet access. The break in was made by setting a password remotly via samba for the daemon account and the logging in through ssh. Some local root exploit was then used to OWN my server.

Recomendamos que você leia esta resposta maravilhosa de Gilles, onde ele forneceu links para alguns dos bugs também.

There are bugs filed over this issue in Debian (274229, 330882, 581899), currently open and classified as “wishlist”. I tend to agree that these are bugs and system users should have /bin/false as their shell unless it appears necessary to do otherwise.

    

Answer 3

Para adicionar as excelentes respostas de @slm e @ramesh:

Sim, como você apontou, ainda é possível alternar para usuários com nologin como o shell padrão executando sudo com um shell definido, mas, nesse caso, você precisou:

1. Faça login como outro usuário que tenha um shell válido
2. As permissões sudo configuradas para esse usuário para executar o comando su e
3. Sua su tentativa foi registrada no log do sudoers (supondo, é claro, que o sudo logging esteja ativado).

Os usuários que possuem o nologin definido como seu shell padrão geralmente têm privilégios mais altos / são capazes de causar mais danos ao sistema do que um usuário comum, portanto, impedi-los de efetuar login diretamente para limitar os danos que uma violação de seu sistema poderia sofrer.

    

Answer 4

Além das excelentes respostas que foram dadas, ele serve a outro propósito.

Se você executar um daemon de FTP em seu servidor, ele verificará o shell de login dos usuários que tentam efetuar login. Se o shell não estiver listado em /etc/shells , ele não permitirá o login. Então, ao dar contas do daemon, um shell especial impede que alguém modifique a conta via FTP.

    

Answer 5

Além das ótimas respostas já fornecidas, posso pensar no seguinte cenário.

Um bug de segurança em um serviço executado como um usuário restrito permite gravar um arquivo como esse usuário. Este arquivo pode ser ~ / .ssh / authorized_keys.

Isso permite que o atacante faça login diretamente em um shell, o que tornaria muito mais fácil executar um escalonamento de privilégios.

Não permitir um shell de login tornaria essa opção muito mais difícil.

    

Answer 6

Geralmente eu diria que / bin / false e / sbin / nologin são os mesmos - mas eu suponho que isso depende de qual servidor SSH você está usando.

Seria prudente apontar que essa recente exploração no OpenSSH parece afetar / bin / logins falsos, mas NÃO / sbin / nologin. No entanto, afirma que Dropbear é diferente desta maneira (também a exploração se aplica especificamente ao OpenSSH).

A exploração afeta a maioria das versões:

7,2p1 e menor (todas as versões; remonta ~ 20 anos) Com o encaminhamento do X11 ativado

link

Portanto, com base nisso - eu pessoalmente faria / sbin / nologin, no entanto, não tenho certeza se isso pode afetar os serviços que criam a entrada / bin / false em / etc / passwd. Você pode experimentar e ver seus resultados, mas faça por sua conta e risco! Suponho que, na pior das hipóteses, você pode simplesmente alterá-lo e reiniciar qualquer serviço afetado. Eu pessoalmente tenho algumas entradas usando / bin / false - Não tenho certeza se quero me incomodar com isso, pois o redirecionamento do X11 não é algo que eu tenha ativado;)

Se você usa o OpenSSH (muitas pessoas pensam ...) E tem o encaminhamento do X11 habilitado - você pode querer considerar o / sbin / nologin (ou talvez mudar para o Dropbear).

    

Answer 7

Geralmente, é uma boa prática de segurança definir contas de aplicativo e serviço para um login não interativo. Um usuário autorizado ainda pode ter acesso a essas contas usando SU ou SUDO, mas todas as suas ações são rastreadas nos arquivos de log do Sudoers e podem ser rastreadas até o usuário que executou comandos nos privilégios da conta de serviço. É por isso que é importante armazenar arquivos de log em um sistema centralizado de gerenciamento de logs para que os administradores do sistema não tenham acesso para alterar os arquivos de log. O usuário que executa comandos sob SU ou SUDO já está autorizado a acessar o sistema.

Por outro lado, um usuário externo ou não autorizado ao sistema não terá acesso ao login usando essas contas, e essa é uma medida de segurança.

    

Answer 8

Sim, serve para fins de segurança. É uma medida de defesa em profundidade.

O principal motivo pelo qual ele serve a um propósito é que existem vários fragmentos de software que validam alguma forma de credenciais de login para um usuário especificado e, em seguida, usam o shell de login desse usuário para executar um comando. Talvez o exemplo mais notável seja o SSH. Se você autenticar com êxito como usuário através de SSH, o SSH então inicia o shell de login do usuário (ou o utiliza para executar o comando fornecido, se você usar a sintaxe ssh [email protected] 'command to run' ).

É claro que, idealmente, um invasor não conseguirá se autenticar como usuário. Mas suponha que a seguinte situação aconteça:

• Um servidor que você controla está executando um serviço da web como um usuário que possui um diretório inicial e um shell de login
• Um invasor descobre uma vulnerabilidade nesse serviço que permite que o invasor grave arquivos no diretório inicial do usuário

Agora, o invasor pode gravar uma chave pública SSH em ~/.ssh/authorized_keys , depois em SSH in e - boom! - eles têm acesso ao seu servidor.

Se o usuário tiver /usr/sbin/nologin como seu shell de login, mesmo depois que o invasor gravar com êxito a chave pública em authorized_keys , isso não será útil para eles. Tudo o que eles permitem é executar remotamente nologin , o que não é muito útil. Eles não podem obter shell, e seu ataque foi mitigado.

Caso esse cenário pareça muito hipotético, eu gostaria de observar que fui alvo precisamente deste ataque em algum momento de 2015, cerca de um ano depois de fazer essa pergunta. Como um idiota maldito, eu deixei uma instância Redis sem senha aberta para o mundo. Ele foi alvo do ataque Redis crackit , no qual o invasor insere uma chave pública SSH no seu banco de dados Redis, em seguida, envia um comando informando ao Redis para gravar o conteúdo do banco de dados em .ssh/authorized_keys , depois tenta o SSH. Eu fui salvo das conseqüências de minha própria incompetência apenas pelo fato de os mantenedores do pacote redis-server Apt (que eu usei para instalar o Redis) tive a sabedoria de fazê-lo executar o Redis como um usuário redis que não possui um diretório home ou shell de login; se não fosse por eles, meu servidor provavelmente teria sido resgatado ou acabado fazendo parte do botnet de algum hacker.

Essa experiência me deu algum grau de humildade e me fez apreciar a importância da defesa em profundidade , e , em particular, de não conceder shells de login para contas que executam servidores da Web, bancos de dados e outros serviços de segundo plano.