Quão importante é a senha do sudo?

Question

Eu sei que a senha 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 é strong o suficiente para esse propósito, mas sei que ela não é strong o suficiente se alguém for capaz de forçá-la remotamente.

Pode qualquer pessoa 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ê tiver um acesso à rede, definitivamente sim (Resposta curta)
2. Se você não prestar atenção suficiente à segurança, sim (resposta longa)
3. Se você tiver "ssh" em execução, e não 2FA , sim ( comentários e respostas)
4. Pode-se acessar seu computador como root sem sudo / senha do usuário

Answer 1

I know that the sudo password protects my computer from being locally hacked by someone having physical access to it.

Eu não quero assustá-lo muito, mas se alguém tiver acesso físico, você terá acesso a ele, independentemente de quão strong é sua senha. Será necessário uma reinicialização por alguém para que alguém possa alterar sua senha de root (pode ser feito a partir de "grub rescue" sem a necessidade de fornecer sua senha atual). By the way: este método é considerado válido e um recurso, e um risco de segurança aceito (caso contrário, você nunca seria capaz de consertar seu sistema no caso da senha ter sido comprometida).

but I know that it is not strong enough if someone can brute-force it remotely.

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

Can anybody access my computer in root mode using my sudo password with no physical access to the computer, on a standard Ubuntu desktop installation ?

Primeiro, precisam se conectar e fornecer a senha do sudo. O modo "root" está desativado e você não pode efetuar login diretamente em um prompt "#".

Observe que é possível abusar de um serviço. Se você tem "ssh" rodando naquela máquina e eles podem "ssh" para o seu sistema, e obter uma mão em seu nome de usuário e senha para esse usuário (e como é um usuário admin sua senha sudo também) eles podem acessar sua máquina e estragar tudo. A propósito: se eles fizerem assim, eles devem ter conhecimento de seu sistema primeiro (como sua senha).

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

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

O melhor conselho que posso dar:

• não insira sua senha de administrador quando solicitado, a menos que você saiba que era esperado que ela fosse solicitada. Se você abrir um navegador e receber um pop-up que se parece com a "senha da conta de administrador" ... pare ... e pense primeiro.

• não deixe seu sistema sem supervisão quando o período de tolerância "sudo" estiver ativo. sudo --reset-timestamp remove o período de tolerância atual e solicitará a senha novamente quando você usar o "sudo". Bloqueie sua tela quando você for AFK.

• não instale serviços ou software por diversão. Se você não precisa de ssh não instale ssh , se você não usa um servidor web, não instale um servidor web. E dê uma olhada nos serviços atualmente em execução. Se você não usa o BT em um notebook, desative-o. Se você não usar uma webcam, desabilite-a (se estiver ativa). Exclua o software que você não usa mais.

• e para o realmente paranóico (e sim para o Panda paranóico estou olhando para você): mude a senha de vez em quando. Você pode até mesmo instalar os caçadores de rootkits para verificar o acesso inadequado.

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

Answer 2

Sim, eles podem.

Existem várias maneiras de fazê-lo, e a criação brute da senha sudo provavelmente não é a primeira.

Primeiro, a senha sudo é a senha do seu usuário; então, o que eles precisam é da sua senha.

Segundo, decifrar a senha de um usuário usando bruteforce para acessar um sistema é provavelmente o último recurso.

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

Normalmente, um invasor simplesmente tenta explorar as vulnerabilidades mais comuns (o mais conhecido é, provavelmente, obter um shell de usuário por qualquer meio e explorar um ShellShock para obter um shell raiz) ou fazer um trabalho melhor ao longo das linhas de:

• Verificando as portas abertas no sistema para obter informações como:
  • Versão do sistema operacional
  • Versão dos serviços em execução
• Explorando sistemas operacionais conhecidos ou executando bugs de serviços (buffer overflows, ...) para obter pelo menos um shell de usuário e, em seguida, tentar obter um shell de root (novamente, talvez explorando um ShellShock)

Bruteforcing da senha sudo / user pode ser uma tentativa caso um shell root não possa ser obtido de outra forma, mas, por exemplo, a exploração de um serviço executado como root não exigirá que o invasor force o brute sudo / user senha.

    

Answer 3

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

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

E, portanto, para um invasor com ideias suficientes, é possível. Você pode tornar seu sistema o mais seguro possível, mas não conseguirá atingir 100% de segurança.

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

    

Answer 4

I know that the sudo password protects my computer from being locally hacked by someone having physical access to it (edit : actually, it doesn't). My password is strong enough for that purpose, but I know that it is not strong enough if someone can brute-force it remotely. Can anybody access my computer in root mode using my sudo password with no physical access to the computer, on a standard Ubuntu desktop installation ?

A senha sudo não é apenas para proteção local, mas também para adicionar uma camada extra de segurança ao uso de privilégios de root. Uma boa discussão pode ser encontrada aqui link

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

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

sudo nano /etc/ssh/sshd_config

Os MUSTS saem 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 criptografia de chave pública Comece criando uma chave em sua máquina remota (usando puttygen ou qualquer outro sabor que seu sistema operacional tenha disponível). Copie a chave pública para sua máquina Ubuntu sob o usuário que você deseja efetuar login como arquivo authorized_keys (você provavelmente terá que 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 login de 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

Tente o SSHing no seu host Ubuntu a partir do seu computador privado usando criptografia de chave pública. Se tudo correu bem, volte para o host Ubuntu e desabilite a autenticação por senha.

sudo nano /etc/ssh/sshd_config

PasswordAuthentication no

Salve e reinicie o ssh

sudo service ssh restart

Tente novamente o computador com chave privada para confirmar.

Quer adicionar mais? configure uma conta não privilegiada, gere PermitRootLogin no, reinicie o ssh, adicione sua chave pública às novas authorized_keys da conta, efetue login como conta não privilegiada, su em sua conta root ou privilegiada quando precisar fazer root ou privilegiar o caminho das coisas.

    

Answer 5

O objetivo do sudo não é relacionado a senhas, mas dar a certos usuários capacidades root-ish enquanto restringem outros através de uma máquina sem requerer que eles apresentem o login root (password / key / security token / etc). Por exemplo, no meu trabalho, os trabalhadores do dia a dia só podem iniciar / desligar / instalar & atualizar suas estações (de um repositório vetado da empresa) via sudo. Eles não recebem as outras liberações de raiz, como remover propositalmente /, formatar dispositivos, adicionar e remover usuários, decidir quais módulos do kernel devem estar na lista negra ou o que é executado no crontab (etc, etc, etc). Considerando que em sua casa, seu sudo permite acesso total à máquina. Em relação à senha, na realidade, é a senha da sua conta de usuário que o sudo exige (a mesma que você usaria para efetuar login, se o login automático não estiver ativado.) E essa senha tem as mesmas vulnerabilidades que qualquer outra senha lá fora.

Más gorjeta : Se você quer fazer do root uma conta normal em um unix habilitado do sudo (linux / apple osx), execute o seguinte

sudo -s
passwd
Enter your unix password:

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

Em relação à segurança, se um programa (digamos, servidor web, mysql, daemon do php, sshd) for executado como uma conta elevada ... digamos, root e tiver uma exploração conhecida, os invasores talvez não precisem de credenciais de segurança para obter Acesso. Eles podem fazer uso da vulnerabilidade do programa e apenas gerar um novo shell deste programa rodando como root. No entanto, isso é muito raro, já que os gerentes de distribuição estão cientes de problemas semelhantes e fazem um excelente trabalho na criação de um ambiente padrão bem pensado e geralmente seguro.

No outro sistema operacional , uma operação semelhante ao sudo seria clique direito e executado como Administrador do Sistema (ou o privilégio do UAC).