☰

Por que ter um usuário sem senha seria uma má ideia (neste cenário)?

tag-icon • tag-icon security users password non-root-user privileges
Por que ter um usuário sem senha seria uma má ideia (neste cenário)?

Pensei em postar isso aqui ou no SE de segurança... mas decidi ir com o Unix SE, já que não se trata realmente de uma questão sobre criptografia, mas mais sobre usuários/privilégios do Linux. Talvez meu google-fu esteja fraco hoje, mas as únicas coisas que encontrei até agora

  1. têm respostas muito genéricas sobre ser uma "má prática" ou "desaprovada" sem quaisquer exemplos concretos, ou
  2. têm respostas que assumem que o usuário sem senha tem acesso root ou está descartando todas as proteções possíveis.

Para ser claro: não estou defendendo isso e, na verdade, estou procurando razões válidasnãopara fazer isso, mas gostaria de encontrar razões concretas para isso, em vez de apenas "é ruim". :-)

Então, com isso resolvido, deixe-me dar o exemplo que realmente me fez pensar sobre isso em primeiro lugar:

Digamos que estou pensando em configurar um sistema doméstico onde tenho uma senha forte na rootconta. Além disso, terei umconta não root chamada fredaquilo éNÃOno grupo admin wheel(ou sudoersno Debian/Ubuntu). Neste sistema, também terei /homeuma partição separada criptografada por LUKS que é desbloqueada durante o processo de inicialização. Em outras palavras, uma senhafazainda será inserido entre o GRUB e o gerenciador de login - mas o gerenciador de login está configurado para login automático. Além disso, digamos que eu também configurei (do root): password -f -u fredparaforçar desbloqueioa senha para fred(efetivamente fazendo com que fredtenha uma senha vazia).

Que tipos de problemas de segurança eu poderia esperar encontrar nesta situação? Parece que deveria haver algum bom motivo para você não querer fazer isso.Mas oapenascoisa que vem à mente até agora é:

  • As partições LUKS não são fechadas quando o bloqueio do protetor de tela é acionado (pelo menos, não no Cinnamon e assumindo umédefinido para acionar). Portanto, se alguém invadisse minha casa e fredjá estivesse logado, ele poderia simplesmente sentar e ligar o monitor e depois procurar qualquer coisa fredque tivesse acesso - desde que não desconectasse/reiniciasse/desligue o PC primeiro ( e assim bloquear novamente o LUKS). E eu suspeito que se eu tentasse o suficiente, talvez eu pudesse encontrar uma maneira de chamar um script quando o protetor de tela for acionado e então bloquear o LUKS desse script, fechando assim esse buraco (ou talvez o kde/xfce/gnome/etc já tenha alguma maneira cuidar disso?).

Mesmo se fredtivesse uma senha forte e bonita, ele não poderia instalar software/mexer nas configurações do sistema sem ser um administrador. E não tenho certeza, mas acho que o acesso do navegador/Wine aos arquivos não seria alterado de qualquer maneira. Existe algo mais em risco aqui do que sefred feztem uma senha?

Editar: não acho que isso importe, mas a distribuição é o Fedora (com SELinux ativado), mas se você se sentir mais confortável respondendo em relação a outra distribuição (ou sem SELinux), tudo bem.

Edição nº 2: Em relação a ssh/ samba. Eu geralmente configuro algo como uma /media/sdb1/sharedpasta em vez de usar $HOMEos compartilhamentos do samba ou como eles são chamados. Acho isso bastante fácil de configurar em um ambiente de usuário pequeno, como em casa (obviamente, não faria isso em um ambiente de trabalho ou em um ambiente onde nem todos os usuários confiam uns nos outros). Mas eu sempre uso contas de usuário samba separadas e protegidas por senha (não os mesmos usuários com os quais faz login) e sigo vários guias para fortalecer minha smb.confconfiguração. Se você encontrar falhas nesta configuração, irei considerá-las válidas para atacar o cenário/configuração hipotético com uma senha em branco na conta de login fred(lembre-se que a senha da conta samba énãoembora em branco).

Para isso ssh, quero confirmar que o padrão é que as senhas em branco sejam rejeitadas emtodoscontas (não apenas em root). Caso contrário, considerarei a resposta de FelixJN válida. Caso contrário, eu provavelmente usaria - semelhante a samba- a mesma configuração que normalmente faço, que é uma versão reforçada da configuração padrão. Não me lembro de ter alterado muitas configurações para isso, então tentarei ver se consigo encontrar exatamente quais configurações costumo modificar e incluí-las aqui. Na minha cabeça, sei que mudei o número da porta, mas isso não importa muito.

Ao confirmar a sshrejeição, fiquei surpreso ao ver que no LM19 passwdnão parece suportar o -fsinalizador (forçar) tão estranhamente que só consegui criar uma senha em branco para usuário não root no Fedora. Quando tentei passar sshda caixa LM19 para o fedora, foi recusado:

    $ ssh -p 2468 fred@fedora-testbox
    fred@fedora-testbox's password: 
    Permission denied, please try again.
    fred@fedora-testbox's password: 
    Permission denied, please try again.

Além da porta , parece que também aumentei as cifras/MACs/KexAlgorithms mínimos aceitáveis, reduzi // LoginGraceTime, configurei // . Para :MaxAuthTriesMaxSessionsPermitRootLogin noUsePAM yesChallengeResponseAuthentication noPermitEmptyPasswordsnão parecia ser o padrãomas eu deixei meu explícito.

Responder1

A maior razão prática que consigo imaginar é que alguns softwares de rede podem permitir que alguém faça login remotamente em sua máquina sem uma senha. O risco não é tanto o software que você conhece, mas sim o software em que você não pensou. Talvez o software que acompanha sua distribuição.

Com usuários sem senha, é sua função verificar todos os serviços conectados à rede em sua máquina para ver se eles permitirão login remoto sem senha.

Um princípio geral de segurança é que você deseja que as coisas "falhem", bloqueando todos do lado de fora, em vez de permitir que alguém entre. Se você tiver usuários sem senha, erros e simples descuidos serão mais propensos a desbloquear algum backdoor em algum lugar.

Um exemplo podem ser os servidores de e-mail. Se você tiver uma máquina com endereço IPv4 público, então, com certeza, haverávaiser tentativas semanais ou mesmo diárias de login no SMTP. Os hackers simplesmente percorrem cada endereço IPv4 em busca de uma máquina vulnerável (há apenas 4 bilhões de endereços).

Da mesma forma SSH. O OpenSSH está configurado para rejeitar tentativas de login sem senha (sem autenticação), então isso provavelmente é seguro. Mas vejo algumas tentativas todos os dias de hackers tentando encontrar um nome de usuário com uma senha em branco. Eles simplesmente percorrem milhares de nomes de usuários comuns na esperança de ter sorte.

Responder2

Eu geralmente consideraria estes aspectos:

  1. Acesso remoto:

Se você tiver alguma opção de acesso remoto, como sshativo, esta é uma porta aberta por motivos óbvios. Nesse caso, os pontos 2 e 3 aplicam-se especialmente.

  1. Privacidade e segurança de dados:

Seu usuário expõe informações que talvez não deveriam estar disponíveis para usuários sem privilégios e, claro, sua data pode ser excluída por qualquer pessoa. Algumas pessoas são simplesmente destrutivas.

  1. Sistema de segurança:

É claro que oficialmente o usuário não tem direitos de administrador, mas nenhum sistema é inviolável. Uma vez que alguém tenha acesso como usuário, ninguém o impedirá de enviar malware, explorar falhas de segurança, compilar programas localmente e então violar o sistema....

É uma questão de quantas pedras você gostaria de colocar no caminho de alguém.

Então a questão é por que ter um usuário sem senha, quando você também poderia ter um login automático e evitar pelo menos alguns desses riscos, aumentando ao máximo a necessidade de acesso físico?

informação relacionada