Qual a importância da senha do sudo?


25

Eu sei que a senha do sudo protege meu computador de ser hackeado localmente por alguém que tenha acesso físico a ele ( editar: na verdade, não ). Minha senha é forte o suficiente para esse fim, mas sei que não é forte o suficiente se alguém puder forçá-la remotamente.

Alguém pode acessar meu computador no modo raiz usando minha senha sudo sem acesso físico ao computador, em uma instalação padrão da área de trabalho do Ubuntu?

  1. Se você tem acesso à rede, definitivamente sim (resposta curta)
  2. Se você não prestar atenção suficiente à segurança, sim (resposta longa)
  3. Se você tem "ssh" em execução e não 2FA , sim ( comentários e respostas)
  4. Pode-se acessar seu computador como root sem a senha do usuário / sudo

literalmente "qualquer um", incluindo eu, ou por exemplo, algum mantenedor de ppa em que confio, mais alguém.
Mxdsp # 9/15

1
eles podem acessar via SSH e sudo para fazer root.
Aizuddin Zali

1
exatamente. para fortalecer isso, você pode usar 2FA. Siga este guia
Aizuddin Zali

1
então você é salvo do ataque SSH. Existem muitas técnicas possíveis de hackers que as pessoas usam.
Aizuddin Zali

1
Simplesmente não existe uma "senha do sudo".
Hbbs #

Respostas:


34

Eu sei que a senha do sudo protege meu computador de ser invadido localmente por alguém que tenha acesso físico a ele.

Não quero assustá-lo muito, mas se alguém tiver acesso físico, você o entregará, independentemente da força da sua senha. Será necessário 1 reinicialização por alguém para que alguém possa alterar sua senha root (isso pode ser feito no "grub rescue" sem a necessidade de fornecer sua senha atual). A propósito: esse método é considerado válido, um recurso e um risco de segurança aceito (caso contrário, você nunca poderá consertar seu sistema caso a senha seja comprometida).

mas sei que não é forte o suficiente se alguém puder forçá-lo à força remotamente.

Aí vem outra coisa em jogo: um ROUTER deve ser inteligente o suficiente para bloquear o acesso externo, se for uma solicitação repetida que solicita as mesmas informações por um curto período de tempo. Basicamente, o que você tem aqui é um ataque do DOS (ou um DDOS se mais de 2 computadores o atacarem). Um roteador deve interromper essa conexão e impor um período de espera antes de aceitar novas solicitações dessa conexão.

Alguém pode acessar meu computador no modo raiz usando minha senha sudo sem acesso físico ao computador, em uma instalação padrão da área de trabalho do Ubuntu?

Eles primeiro precisam se conectar e fornecer a senha do sudo. O modo "root" está desabilitado e você não pode fazer login diretamente no "#" prompt.

Observe que é possível abusar de um serviço. Se você tiver "ssh" em execução nessa máquina e eles puderem "ssh" para o seu sistema, e obter uma mão do seu nome de usuário e senha para esse usuário (e, como administrador, sua senha do sudo também), eles poderão acessar sua máquina e estrague tudo. A propósito: se o fizerem dessa forma, primeiro deverão ter conhecimento do seu sistema (como sua senha).

Mas há um problema com isso (e qualquer outro método): como eles obtiveram sua senha? Eles NÃO podem obtê-lo do seu próprio sistema. E, em geral, adivinhar não vale a pena. Se foi socialmente projetado ... então o seu problema está aí, não com o modelo de segurança do seu sistema, Ubuntu ou Linux em geral.

Contanto que sua senha do sudo seja sua, você ficará bem. E você ficará ainda melhor se for uma senha forte (talvez fácil de lembrar para você, mas que não possa ser adivinhada por outras pessoas). Um exemplo que eu usei antes ao discutir isso: se o seu cão se chama "Abwegwfkwefkwe", usar "Abwegwfkwefkwe" como senha é RUIM mesmo que pareça bom (já que alguém pode perguntar: 'qual é o nome do seu cão' e eles tentam isso como um palpite livre). Se você não tem relação com "Abwegwfkwefkwe", é uma boa senha.

O melhor conselho que posso dar:

  • não digite sua senha de administrador quando solicitada, a menos que você saiba que se espera que seja solicitada. Se você abrir um navegador e receber um pop-up que se parece com o nosso "pedido de senha da conta de administrador" ... pare ... e pense primeiro.

  • não deixe seu sistema sem vigilância quando o período de cortesia "sudo" estiver ativo. sudo --reset-timestampremove o período de cortesia atual e solicita a senha novamente quando você usar o "sudo". Bloqueie sua tela quando você estiver no AFK.

  • não instale serviços ou software para se divertir. Se você não precisar sshinstalar ssh, se você não usar um servidor da Web, não instale um servidor da Web. E dê uma olhada nos serviços atualmente em execução. Se você não usar o BT em um notebook, desative-o. Se você não usar uma webcam, desative-a (se ativa). Exclua o software que você não usa mais.

  • e para os realmente paranóicos (e sim, Paranoid Panda, eu estou olhando para você): altere a senha de vez em quando. Você pode até instalar caçadores de rootkit para verificar se há acesso inadequado.

  • faça backup de seus dados importantes para algo que você mantenha off-line. Portanto, mesmo que você encontre alguém em seu sistema, você pode formatá-lo e começar de novo com uma nova instalação e seus dados restaurados.


2
Você pode abreviar sudo --reset-timestamppara sudo -k, ou sudo -Kpara o verdadeiramente paranóico (necessário apenas se o invasor puder definir a hora do sistema para valores arbitrários, momento em que você provavelmente já perdeu).
Kevin

Jups. Eu usei a versão longa, para que fique claro o que faz. "-k" faz o mesmo de fato.
Rinzwind

1
@mxdsp: A criptografia pode impedir que as pessoas leiam o conteúdo das partições criptografadas, se a senha é forte o suficiente, mas pode ser possível obter a chave de criptografia de um computador em execução ou encerrado recentemente. A criptografia também é um campo muito veloz, e você precisará acompanhar os novos desenvolvimentos, para que sua criptografia não se torne obsoleta e quebre facilmente.
Kevin

1
@mxdsp yes. Por um lado: você pode formatar um disco e, quando os dados acabarem ... é você quem está com os problemas.
Rinzwind 9/10/2015

1
A primeira parte implicitamente não assume criptografia de disco completa.
Otus 10/10

6

Sim eles podem.

Existem várias maneiras de fazê-lo, e forçar brutalmente a sudo senha provavelmente não é a primeira.

Primeiro, a sudosenha é a senha do seu usuário; então realmente o que eles precisariam é sua senha.

Segundo, quebrar a senha de um usuário usando força bruta para acessar um sistema é provavelmente o último recurso.

Existem maneiras muito mais elegantes (mas principalmente mais eficazes) de invadir outro sistema.

Normalmente, um invasor simplesmente tenta explorar as vulnerabilidades mais comuns (as mais conhecidas provavelmente estão obtendo um shell de usuário por qualquer meio e explora um ShellShock para obter um shell raiz) ou faz um trabalho melhor nas seguintes linhas:

  • Verificando as portas abertas no sistema para obter informações como:
    • Versão do sistema operacional
    • Versão de serviços em execução
  • Explorar o sistema operacional conhecido ou executar os bugs dos serviços (estouros de buffer, ...) para obter pelo menos um shell de usuário e tentar obter um shell raiz (novamente, talvez explorando um ShellShock)

Forçar brutalmente a sudosenha do usuário / pode ser uma tentativa caso um shell raiz não possa ser obtido, mas, por exemplo, explorar um serviço em execução como root não exigirá que o invasor force a sudosenha do usuário / brutalmente.


1
Obrigado. resumidamente, significa que um invasor não precisa da senha do sudo para obter acesso root?
Mxdsp # 9/15

2
@mxdsp Exatamente. Coloque da seguinte maneira: se um invasor conseguir obter um shell de usuário do sudoer de qualquer forma (por exemplo, explorar o programa em execução de um usuário do sudoer), ele poderá usar explorações conhecidas (na minha resposta, mencionei as mais infames) para obter um shell raiz, ignorando a necessidade do usuário / sudosenha. Melhor ainda, se ele conseguir explorar um serviço em execução como root, ele será diretamente root.
kos

1
@mxdsp Agora estamos generalizando, mas veja este vídeo para entender, por exemplo, como um usuário sem sudodireitos (= ~ um usuário com o qual um invasor está logado, mas cujo invasor não sabe a senha) pode obter uma raiz shell apenas explorando bugs conhecidos (neste caso, o infame ShellShock).
kos

1
@mxdsp De um lado não, eu não quis dizer usuário de sudoers, apenas usuário. Isso não é necessário, eu estava pensando em muitas coisas ao mesmo tempo.
kos

3
  1. Se eu aprendi alguma coisa nos últimos anos sobre segurança, então uma coisa: nada é impossível .

  2. Contanto que você tenha acesso a uma rede, definitivamente. Cada serviço em execução no seu sistema que pode ser acessado pela rede é teoricamente vulnerável e, portanto, uma fraqueza potencial.

E, portanto, para um invasor com idéias suficientes, é possível. Você pode tornar seu sistema o mais seguro possível, mas nunca pode alcançar 100% de segurança.

Portanto, é importante avaliar o que é possível com um esforço técnico justificável e o que o protege tão bem que você não consegue mais trabalhar.


Eu tenho acesso à rede. Pode ser mais específico sobre a probabilidade desse tipo de ataque?
Mxdsp # 9/15

1
use autenticação de dois fatores. Você precisa editar o PAM.D e assim por diante.
Aizuddin Zali

@ Arronical, o link é deste fórum e também um guia muito bom.
Aizuddin Zali

@ Arronical eu coloquei no comentário da pergunta. Este guia
Aizuddin Zali

Desculpe @AizuddinZali, eu não havia atualizado a página!
Arronical

2

Eu sei que a senha do sudo protege meu computador de ser hackeado localmente por alguém que tenha acesso físico a ele (editar: na verdade, não). Minha senha é forte o suficiente para esse fim, mas sei que não é forte o suficiente se alguém puder forçá-la remotamente. Alguém pode acessar meu computador no modo raiz usando minha senha sudo sem acesso físico ao computador, em uma instalação padrão da área de trabalho do Ubuntu?

A senha do sudo não é apenas para proteção local, seu objetivo é adicionar uma camada extra de segurança ao uso de privilégios de root. Uma boa discussão pode ser encontrada aqui /superuser//a/771523/467316

Sua senha pode não ser tão forte quanto você pensa. No momento, estou decifrando de 20 a 40% dos hashes do Active Directory do meu cliente para aqueles que eu já vi antes, aqueles que têm regras de senha ruins estão ficando 70% decifrados. Eu recomendo senhas complexas de 16 caracteres. As placas gráficas oclHashcat e Radeon podem causar muitos danos. Adicione todos os arquivos de senhas de todas as violações nos últimos 5 anos e você terá um bom dicionário para trabalhar.

Se você estiver usando SSH, faça alguns ajustes no sshd_config

sudo nano /etc/ssh/sshd_config

Os MUSTS saindo do portão (o último a desativar o servidor ftp, se você não estiver usando).

Protocol 2
X11Forwarding no
PermitEmptyPasswords no
MaxAuthTries 5
#Subsystem sftp /usr/lib/openssh/sftp-server

Salve, reinicie o ssh

sudo service ssh restart

Use a criptografia de chave pública Comece criando uma chave na sua máquina remota (usando puttygen ou qualquer outro sabor que seu sistema operacional tenha disponível). Copie a chave pública para a sua máquina Ubuntu sob o usuário que você deseja fazer login como arquivo allowed_keys (você provavelmente precisará criá-la)

sudo nano /home/yourdumbusername/.ssh/authorized_keys

copie a chave pública neste formato

ssh-rsa 23r0jfjlawjf342rffjfa89pwfj8ewfew98pfrfj8428pfwa9fupfwfcajwfpawf8rfapfj9pf892jpfjpwafj8a where-ever-you-have-your-private-key-for-your-own-notes

salve-o e configure seu sshd_config para permitir o login da chave pública

sudo nano /etc/ssh/sshd_config

RSAAuthentication yes
PubkeyAuthentication yes
AuthorizedKeysFile      %h/.ssh/authorized_keys

salve e reinicie o ssh

sudo service ssh restart

Experimente o SSHing no host do ubuntu a partir do seu computador com chave privada usando a criptografia de chave pública. Se tudo correu bem, volte ao host do ubuntu e desative a autenticação de senha.

sudo nano /etc/ssh/sshd_config

PasswordAuthentication no

Salvar e reiniciar o ssh

sudo service ssh restart

Tente sshing do computador com chave privada novamente para confirmar.

Deseja adicionar mais? configure uma conta não privilegiada, ative PermitRootLogin no, reinicie o ssh, adicione sua chave pública às chaves_inicializadas da nova conta, efetue login como conta não privilegiada, su à sua conta raiz ou privilegiada quando precisar fazer o root ou privilegiar o seu caminho.


2

O objetivo do sudo não é relacionado à senha, mas, ao invés disso, fornecer a certos usuários recursos de root-ish enquanto restringe outros a uma máquina sem exigir que eles apresentem o login raiz (senha / chave / token de segurança / etc). Por exemplo, no meu trabalho, os funcionários do dia-a-dia só podem iniciar / desligar / instalar e atualizar suas estações (de um repositório vetado pela empresa) via sudo. Eles não recebem outras liberdades de root, como remover / / formatar dispositivos propositadamente, adicionar e remover usuários, decidir quais módulos do kernel devem ser colocados na lista negra ou o que é executado no crontab (etc, etc, etc). Enquanto em sua casa, seu sudo permite acesso total à máquina. No que diz respeito à senha, na realidade é a senha da sua conta de usuário que o sudo exige (a mesma que você usaria para fazer login, se o login automático não estiver ativado.

Dica ruim : Se você deseja tornar o root uma conta comum em um unix habilitado para sudo (linux / apple osx), execute o seguinte

sudo -s
passwd
Enter your unix password:

Nesse ponto, o root tem uma senha regular e você pode simplesmente sair e fazer login como root com a senha mencionada da "maneira antiga".

Em relação à segurança, se um programa (como servidor web, mysql, daemon php, sshd) for executado como uma conta elevada. Eles podem fazer uso da vulnerabilidade do programa e gerar um novo shell a partir deste programa, executando como root. No entanto, isso é muito raro, pois os gerentes de distribuição estão cientes de problemas semelhantes e fazem um excelente trabalho na construção de um ambiente padrão bem pensado e geralmente seguro.

No outro sistema operacional, uma operação semelhante ao sudo seria clicada com o botão direito do mouse e executada como Administrador do Sistema (ou o incômodo do privilégio do UAC).

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.