Qual é a maneira mais segura de obter privilégios de root: sudo, su ou login?


120

Gostaria de ter a conta root em segurança, mesmo que meu usuário não privilegiado esteja comprometido.

No Ubuntu, você só pode usar o sudo por "razões de segurança" por padrão. No entanto, não tenho certeza de que seja mais seguro do que usar o login em um console em modo de texto. Há muitas coisas que podem dar errado se um invasor pode executar o código como meu usuário normal. Por exemplo, adicionando aliases, adicionando coisas ao meu PATH, configurando os keyloggers LD_PRELOAD e X11 apenas para mencionar alguns. A única vantagem que vejo é o tempo limite, para que nunca me esqueça de sair.

Eu tenho as mesmas dúvidas sobre su, mas ele nem tem limite de tempo. Algumas operações (especialmente o redirecionamento de E / S) são mais convenientes com su, mas em termos de segurança, isso parece ser pior.

O login em um console em modo de texto parece ser o mais seguro. Como é iniciado pelo init, se um invasor pode controlar PATH ou LD_PRELOAD, ele já é root. Os eventos de pressionamento de tecla não podem ser interceptados por programas em execução no X. Não sei se os programas em execução no X podem interceptar [ctrl] + [alt] + [f1] (e abrir uma janela de tela cheia que se parece com um console) ou é seguro como [ctrl] + [alt] + [del] no Windows. Além disso, o único problema que vejo é a falta de tempo limite.

Então, estou perdendo alguma coisa? Por que os caras do Ubuntu decidiram permitir apenas o sudo? O que posso fazer para melhorar a segurança de qualquer um dos métodos?

E o SSH? Tradicionalmente, o root não pode efetuar login através do SSH. Mas usar a lógica acima não seria a coisa mais segura a fazer:

  • permitir root através do SSH
  • mudar para o modo de texto
  • faça login como root
  • ssh para a outra máquina
  • logar como root?

Na sua solução ssh, você quer dizer que deseja ssh na caixa potencialmente composta de outra caixa? 1 / Se sim, então, para seguir sua linha de pensamento, certifique-se de que sua outra caixa não seja comprometida antes de sair dela. 2 / Se não, então você tem o mesmo problema.
asoundmove

@asoundmove: Existem 4 usuários na minha situação ssh: root @ hosta, root @ hostb, stribika @ hosta, stribika @ hostb. Supondo que um invasor possa executar código arbitrário como ambos stribikas (afinal eles estão executando o flashplugin e outros enfeites), ainda quero acesso seguro à raiz. Portanto, ambas as caixas podem ser parcialmente comprometidas.
stribika

Respostas:


104

Segurança é sempre fazer trocas. Assim como o servidor proverbial que está em um local seguro e desconectado, no fundo do oceano, rootseria mais seguro se não houvesse maneira de acessá-lo.

Os ataques LD_PRELOAD e PATH como os que você descreve assumem que já existe um invasor com acesso à sua conta, ou pelo menos aos seus arquivos de ponto. O Sudo não protege muito bem disso - se eles tiverem sua senha, afinal, não há necessidade de tentar enganá-lo para mais tarde ... eles podem usar sudo agora .

É importante considerar o que o Sudo foi projetado originalmente: delegação de comandos específicos (como aqueles para gerenciar impressoras) a "subadministradores" (talvez alunos de graduação em um laboratório) sem abrir mão da raiz completamente. Usar o sudo para fazer tudo é o uso mais comum que vejo agora, mas não é necessariamente o problema que o programa deveria solucionar (daí a sintaxe ridiculamente complicada do arquivo de configuração).

Mas, sudo-para-irrestrito-raiz faz abordar outro problema de segurança: gerenciamento de senhas de raiz. Em muitas organizações, elas tendem a ser repassadas como doces, escritas em quadros brancos e deixadas iguais para sempre. Isso deixa uma grande vulnerabilidade, pois revogar ou alterar o acesso se torna um grande número de produção. Mesmo controlar qual máquina tem qual senha é um desafio - quanto mais rastrear quem sabe qual.

Lembre-se de que a maioria dos "crimes cibernéticos" vem de dentro. Com a situação da senha root descrita, é difícil rastrear quem fez o quê - algo que o sudo com registro remoto lida muito bem.

No seu sistema doméstico, acho que é mais uma questão de conveniência de não ter que lembrar duas senhas. É provável que muitas pessoas simplesmente as definam como iguais - ou pior, as definem como iguais inicialmente e, em seguida, deixando-as fora de sincronia, deixando a senha de root apodrecer.

O uso de senhas em tudo para SSH é perigoso, uma vez por senha sniffing daemons ssh cavalo de Tróia são postas em prática em algo como 90% dos compromissos do sistema do mundo real que eu vi. É muito melhor usar chaves SSH, e esse também pode ser um sistema viável para acesso remoto à raiz.

Mas o problema agora é que você passou do gerenciamento de senhas para o gerenciamento de chaves, e as chaves ssh não são realmente muito gerenciáveis. Não há como restringir cópias, e se alguém fizer uma cópia, ele terá todas as tentativas que deseja para forçar a senha com força bruta. Você pode fazer uma política dizendo que as chaves devem ser armazenadas em dispositivos removíveis e montadas apenas quando necessário, mas não há como impor isso - e agora você introduziu a possibilidade de um dispositivo removível ser perdido ou roubado.

A segurança mais alta será obtida através de chaves únicas ou tokens criptográficos baseados em tempo / contador. Isso pode ser feito em software, mas o hardware resistente a violações é ainda melhor. No mundo do código aberto, há WiKiD , YubiKey ou LinOTP e, claro, também há o RSA SecurID proprietário pesado . Se você estiver em uma organização de médio a grande porte, ou mesmo em uma pequena organização preocupada com a segurança, recomendo analisar uma dessas abordagens para obter acesso administrativo.

Provavelmente, é um exagero em casa, onde você realmente não tem problemas de gerenciamento - desde que siga práticas de segurança sensatas.


Aceito isso como a resposta, pois esclarece muito sobre o que os desenvolvedores do Ubuntu estavam pensando ao fazer do sudo o método padrão. O log remoto também parece ser uma ótima idéia e, como já estou usando o syslog-ng, não deve ser muito difícil de configurar, de modo que todos os meus computadores façam logon com todos os outros. Vou manter minha prática atual de alternar para o modo de texto e efetuar login a partir daí para obter acesso root completo. Delegar um subconjunto de direitos é certamente uma boa maneira de usar o sudo e uma que nunca considerei.
stribika

7
sudoé muito semelhante ao Controle de Conta de Usuário no Windows Vista. Na verdade, ambos foram projetados para não aumentar a segurança, mas para facilitar a redução de maneira controlada. Mas como eles facilitam a elevação temporária de seus privilégios de maneira menos atrativa, você não precisa executar privilégios elevados por longos períodos de tempo, aumentando a segurança. (Esta não foi tão grande de um problema em Unix, mas no Windows Lembro-me de correr como administrador durante dias a fio, só porque a mudança foi tão dolorosa.)
Jörg W Mittag

Senha cheirando daemons ssh trojaned? Se eles podem substituir o daemon ssh, eles já têm root.
Psusi

@ psusi: sim, nesse sistema; em um ambiente em que as senhas são compartilhadas (por um serviço de diretório) entre vários sistemas, é fácil que um compromisso se espalhe dessa maneira. Mesmo quando é um sistema único, é um aborrecimento reprovar a senha de todos após uma reinstalação após a detecção do comprometimento.
mattdm

1
As possíveis dificuldades de alterar todas as rootsenhas da sua empresa também são mencionadas como o item final no Boletim de operações , que vale a pena ler.
Curinga

30

Esta é uma pergunta muito complexa. O mattdm já cobriu muitos pontos .

Entre su e sudo, quando você considera um único usuário, su é um pouco mais seguro, pois um invasor que encontrou sua senha não pode obter privilégios de root imediatamente. Mas basta que o invasor encontre um furo raiz local (relativamente incomum) ou instale um trojan e aguarde a execução do su.

O Sudo tem vantagens mesmo em relação ao login no console quando há vários usuários. Por exemplo, se um sistema estiver configurado com logs remotos à prova de violações, você sempre poderá descobrir quem executou o sudo pela última vez (ou cuja conta foi comprometida), mas não sabe quem digitou a senha raiz no console.

Suspeito que a decisão do Ubuntu tenha em parte o interesse pela simplicidade (apenas uma senha para lembrar) e o interesse pela segurança e facilidade de distribuição de credenciais em máquinas compartilhadas (empresa ou família).

O Linux não possui uma chave de atenção segura ou outra interface de usuário segura para autenticação. Até onde eu sei, nem o OpenBSD possui. Se você está preocupado com o acesso root, pode desabilitar completamente o acesso root de um sistema em execução: se você deseja ser root, precisará digitar algo no prompt do gerenciador de inicialização. Obviamente, isso não é adequado para todos os casos de uso. (* O nível de segurança do BSD funciona assim: em um nível de segurança alto, há coisas que você não pode fazer sem reiniciar, como diminuir o nível de segurança ou acessar diretamente os dispositivos brutos montados.)

Restringir as maneiras pelas quais alguém pode se tornar root nem sempre é um ganho de segurança. Lembre-se do terceiro membro da tríade de segurança : confidencialidade , integridade , disponibilidade . O bloqueio do sistema pode impedir que você responda a um incidente.


Se eles puderem encontrar sua senha, eles poderão encontrar a senha root com a mesma facilidade ou facilidade. Além disso, você pode usar o sysrq-k como uma sequência de atenção segura.
Psusi

Linux possui teclas de atenção de segurança, ter um olhar para a documentação do kernel
btshengsheng

O @btshengsheng Linux pode ter uma "chave de atenção segura", mas como pode ser configurado, você não pode ter certeza de que está operando em qualquer máquina em particular. Também depende do layout do teclado, para que possa ser ignorado reatribuindo uma das teclas. É chamado de "chave de atenção segura", mas não se encaixa perfeitamente.
Gilles

9

Os projetistas da distribuição segura OpenWall GNU / * / Linux também expressaram opiniões críticas sobre su(para se tornar root) e sudo. Você pode estar interessado em ler este tópico:

... infelizmente, su e sudo são sutil mas fundamentalmente falhos.

Além de discutir as falhas sue outras coisas, o Solar Designer também visa um motivo específico para o uso su:

Sim, costumava ser comum o administrador de sistemas "su root" em vez de fazer login como root. Os poucos que, quando solicitados, poderiam realmente apresentar um motivo válido para essa preferência, se refeririam à melhor prestação de contas alcançada com essa abordagem. Sim, esse é realmente um bom motivo a favor dessa abordagem. Mas também é o único. ...(consulte Mais informação)

Em sua distribuição, eles "se livraram completamente dos programas raiz SUID na instalação padrão" (ou seja, incluindo su; e não usam recursos para isso):

Para servidores, acho que as pessoas precisam reconsiderar e, na maioria dos casos, proibir a chamada de su e sudo pelos usuários. Não há segurança adicional no antigo "login como não-root, então su ou sudo para o root" sysadmin "sabedoria", em comparação com o login como não-root e como root diretamente (duas sessões separadas). Pelo contrário, a última abordagem é a única correta, do ponto de vista de segurança:

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

(Para responsabilização de vários administradores de sistema, o sistema precisa suportar várias contas com privilégios de root, como o Owl.)

(Para desktops com X, isso fica mais complicado.)

Você também absolutamente tem que lidar com ...

BTW, eles foram substituídos suloginpor msuloginpara permitir a configuração com várias contas raiz: msuloginpermite digitar o nome do usuário também ao entrar no modo de usuário único (e preservar a "responsabilidade") (essa informação vem desta discussão em russo ) .


1
Para um sistema basicamente destinado a ser um firewall e não muito mais, tudo bem, mas se você pretende executar, como exemplo aleatório, mysql / postgresql / bind / powerdns / apache e outros enfeites em um sistema de produção, você inicia enfrentando problemas, como eles descrevem com o X. Essencialmente, eles trocaram muita usabilidade por um certo grau de segurança; cabe ao administrador de sistemas decidir se é uma troca justa. Pessoalmente, vou me ater ao Debian.
Shadur

4

Você parece estar assumindo que o uso sudosempre preserva variáveis ​​de ambiente, mas esse nem sempre é o caso. Aqui está um trecho da página de manual do sudo:

Existem duas maneiras distintas de lidar com variáveis ​​de ambiente. Por padrão, a opção env_reset sudoers está ativada. Isso faz com que os comandos sejam executados com um ambiente mínimo que contém TERM, PATH, HOME, SHELL, LOGNAME, USER e USERNAME, além de variáveis ​​do processo de chamada permitido pelas opções env_check e env_keep sudoers. Existe efetivamente uma lista de permissões para variáveis ​​de ambiente.

Se, no entanto, a opção env_reset estiver desativada em sudoers, quaisquer variáveis ​​não explicitamente negadas pelas opções env_check e env_delete serão herdadas do processo de chamada. Nesse caso, env_check e env_delete se comportam como uma lista negra. Como não é possível colocar na lista negra todas as variáveis ​​de ambiente potencialmente perigosas, é recomendável o uso do comportamento padrão env_reset.

Em todos os casos, as variáveis ​​de ambiente com um valor começando com () são removidas, pois podem ser interpretadas como funções bash. A lista de variáveis ​​de ambiente que o sudo permite ou nega está contida na saída do sudo -V quando executada como raiz.

Portanto, se env_resetestiver ativado (o padrão), um invasor não poderá substituir suas PATHou outras variáveis ​​de ambiente (a menos que você as adicione especificamente a uma lista de permissões de variáveis ​​que devem ser preservadas).


1
Eu quis dizer que se o invasor puder controlar meu caminho, ele poderá me fazer executar qualquer coisa, em vez do real / usr / bin / sudo. Por exemplo, / tmp / sudo, que Password: não exibe nada quando digito, envia o que eu digitei para ele, diz que a senha está errada e depois executa o sudo real.
stribika

Hmm, acho que nesse caso, você pode simplesmente executar / usr / bin / sudo diretamente, em vez de confiar no shell para encontrá-lo. Mas você está certo, é um problema em que não pensei.
Cedric

1
@CedricStaub: Tanto quanto posso dizer, ninguém parece pensar nisso. Eu posso dar o caminho completo, mas tente o seguinte: alias /usr/bin/sudo="echo pwned"Além disso, existem vários programas envolvidos (X, xterm, o shell), qualquer um dos quais pode roubar a senha. Foi por isso que disse que há muitos problemas com a troca com segurança.
stribika

1
Você tentou? Eu fiz:bash: alias: `/usr/bin/sudo': invalid alias name
maaartinus

@maaartinus: Interessante. Funciona em ZSH.
stribika

4

A abordagem mais segura é o login ssh usando (pelo menos) chave longa 2048 (com o login com senha desativado) usando um dispositivo físico para armazenar a chave.


1
Claro, mas raiz para raiz ou sem privilégios para sem privilégios e depois mudar para raiz? (Na verdade, estou usando 4096 chaves bit apenas para estar no lado seguro teclas maiores não são suportados em todos os lugares..)
stribika

@ stribika Bem, ambos. Se a máquina estiver comprometida, você ainda não perde a chave. Isso evita a propagação (maior problema com senhas).
Let_Me_Be

3

Eu só quero adicionar algo um pouco fora do tópico. (para o tópico, marque '/ bin / su -' aqui depois)

Eu acho que a "segurança" acima também deve estar vinculada aos dados reais que queremos proteger.

Será e deve ser diferente se quisermos proteger: meus_dados, minha_dadosempresa, minha_empresa.

Normalmente, se eu falo de segurança, também falo de "segurança de dados" e backup. Também podemos adicionar sistemas tolerantes a falhas e similares.

Diante disso, acho que a segurança como um todo é um equilíbrio entre a usabilidade, a "segurança de dados" e o esforço necessário para implementar um sistema seguro.

O alvo do Ubuntu era, e ainda é, o usuário final: Sudo é o padrão.

O Fedora é a versão gratuita do RedHat, que por sua vez é mais orientada a servidores: o Sudo costumava ser desativado.

Para as outras distribuições, não tenho informações diretas.

Estou usando agora, principalmente, o fedora. E como um usuário de estilo antigo, nunca digitei 'su'. Mas posso digitar "/ bin / su -" em muito pouco tempo, mesmo que eu não seja exatamente um datilógrafo. A variável PATH .. não deve ser um problema (eu digito o caminho). Além disso, o "-" (menos) em princípio deve remover minhas variáveis ​​de ambiente do usuário e carregar apenas as raiz. isto é, evitando alguns problemas extras possíveis. Provavelmente também o LS_PRELOAD.

De resto, acho que o @mattdm foi bastante preciso.

Mas vamos colocá-lo na caixa correta. Suponha que um kit inteligente de script tenha acesso aos meus dados. O que diabos você acha que ele vai fazer com isso? - Publicar minhas fotos? meu? - Tentando descobrir o nome da minha namorada e dizer a ela que eu visito sites pornográficos?

Na imagem de usuário único, as duas piores situações são: - O garoto exclui todos os meus dados: por diversão ou por engano - O garoto usa minha máquina para criar um novo ataque a alguma outra entidade. Ou alvos semelhantes.

Para o primeiro caso, mencionei acima, colocando mais esforços em um backup do que na segurança da rede. Sim, você está salvo. Quero dizer, uma falha de hardware não é tão diferente.

O segundo caso é mais sutil. Mas há sinais sobre essas atividades. De qualquer forma, você pode fazer o possível, mas eu não configuraria meu PC doméstico para ser protegido contra ataques terroristas!

Vou pular os outros cenários.

Saúde F


2

Se a preocupação for que uma conta de usuário comprometida possa ser usada para detectar a senha usada para sudoou su, use uma senha única para sudoe su.

Você pode forçar o uso de chaves para usuários remotos, mas isso pode não ser aprovado para fins de conformidade. Pode ser mais eficaz configurar uma caixa de gateway SSH que exija autenticação de dois fatores e permitir o uso de chaves a partir daí. Aqui está o documento sobre essa configuração: Proteja sua implantação SSH com a autenticação de dois fatores do WiKID .


0

Você também pode dar uma olhada no privacyIDEA , que não apenas fornece a possibilidade de usar o OTP para fazer login na máquina (ou para executar o su / sudo), mas também pode fazer o OTP offline.

Além disso, é capaz de gerenciar suas chaves SSH. Ou seja, se você tem muitas máquinas e vários usuários root, todas as chaves SSH são armazenadas centralmente. Portanto, é fácil "revogar" / excluir uma chave SSH, se a chave não puder mais ser confiável.

Obviamente, existem tarefas e fluxos de trabalho organizacionais para proteger o sistema.

Ao utilizar nosso site, você reconhece que leu e compreendeu nossa Política de Cookies e nossa Política de Privacidade.
Licensed under cc by-sa 3.0 with attribution required.