Há algum problema em configurar 'sudo' sem senha em um servidor de nuvem?

Question

Adoro a ideia de acessar servidores por meio de chaves, para que eu não precise digitar minha senha toda vez que eu ssh em uma caixa, eu até bloqueio a senha do usuário (não root ) ( passwd -l username ) então é impossível fazer login sem uma chave.

Mas tudo isso quebra se eu precisar inserir a senha para os comandos sudo . Então, estou tentado a configurar sem senha sudo para fazer coisas alinhadas com o login sem senha.

No entanto, eu tenho a impressão de que pode sair pela culatra de alguma forma inesperada, parece insegura. Há alguma advertência com tal configuração? Você recomendaria / não recomendaria fazer isso para uma conta de usuário em um servidor?

Esclarecimentos

1. Estou falando sobre o uso de sudo em uma sessão de usuário interativa aqui, não para serviços ou scripts administrativos
2. Estou falando de usar um servidor de nuvem (por isso não tenho acesso local físico a uma máquina e só posso fazer login remotamente)
3. Eu sei que sudo tem um tempo limite durante o qual não preciso digitar minha senha novamente. Mas meu show não é realmente sobre perder o tempo extra para digitar fisicamente uma senha. Minha ideia, porém, era não ter que lidar com uma senha, porque eu suponho que:
   • Se eu tiver que memorizá-lo, provavelmente é muito curto para ser seguro ou reutilizado
   • Se eu gerar uma senha longa e exclusiva para minha conta remota, terei que armazená-la em algum lugar (um programa gerenciador de senhas local ou um serviço de nuvem) e buscá-la sempre que quiser usar sudo . Eu esperava poder evitar isso.

Então, com essa pergunta, eu queria entender melhor os riscos, ressalvas e compensações de uma possível configuração em relação aos outros.

Acompanhamento 1

Todas as respostas dizem que passwordless sudo é inseguro, pois permite o escalonamento "fácil" de privilégios se minha conta de usuário pessoal for comprometida. Eu entendi aquilo. Mas, por outro lado, se eu usar uma senha, incorremos em todos os riscos clássicos com senhas (cadeia muito curta ou comum, repetida em diferentes serviços, etc.). Mas eu acho que se eu desabilitar a autenticação de senha em /etc/ssh/sshd_config para que você ainda tenha que ter uma chave para efetuar login, eu posso usar uma senha mais simples apenas para sudo que é mais fácil de digitar? Essa é uma estratégia válida?

Acompanhamento 2

Se eu também tiver uma chave para logar como root via ssh, se alguém conseguir acessar meu computador e roubar minhas chaves (elas ainda estão protegidas pela senha de chave do sistema operacional!), elas também podem obter um acesso direto à conta root , ignorando o caminho sudo . Qual deve ser a política para acessar a conta root ?

    

Answer 1

I love the idea of accessing servers via keys, so that I don't have to type in my password every time I ssh into a box, I even lock my user's (not root) password (passwd -l username) so it's impossible to log in without a key...Would you recommend/not recommend doing this for a user account on a server?

Você está desabilitando os logins baseados em senha da maneira errada. Em vez de bloquear a conta de um usuário, defina PasswordAuthentication no no seu /etc/ssh/sshd_config .

Com esse conjunto, a autenticação por senha é desativada para o ssh, mas você ainda pode usar uma senha para o sudo.

O tempo somente que recomendo definir NOPASSWD no sudo é para contas de serviço, em que os processos precisam executar comandos via sudo programaticamente. Nessas circunstâncias, certifique-se de colocar explicitamente na lista de permissões apenas os comandos específicos que a conta precisa executar. Para contas interativas, você deve sempre deixar as senhas ativadas.

Respostas às suas perguntas subsequentes:

But I guess that if I disable password authentication in /etc/ssh/sshd_config so that you still have to have a key to log in, I can use a simpler password just for sudo that's easier to type in? Is that a valid strategy?

Sim, está correto. Eu ainda recomendo usar senhas de contas locais relativamente strongs, mas não ridiculamente strongs. ~ 8 caracteres gerados aleatoriamente são suficientes.

If I also have a key to log in as root via ssh, if somebody gets access to my computer and steal my keys (they're still protected by OS' keyring password though!), they might as well get a direct access to the root account, bypassing the sudo path.

O acesso root via ssh deve ser desativado. Período. Defina PermitRootLogin no no seu sshd_config .

What should be the policy for accessing the root account then?

Você deve sempre ter um meio de obter acesso fora de banda ao console do seu servidor. Vários fornecedores de VPS fornecem isso, assim como fornecedores de hardware dedicado. Se o seu provedor não conceder acesso real ao console (digamos, EC2, por exemplo), normalmente você ainda poderá restaurar o acesso usando um processo como o descrito em esta resposta .

    

Answer 2

Eu geralmente restringi o uso de NOPASSWORD para comandos que são executados por um processo automatizado. É preferível ter uma conta de serviço para esses comandos e restringir o uso de sudo aos comandos necessários.

Permitir NOPASSWORD para comandos gerais permite que qualquer pessoa que acesse seu ID de usuário execute qualquer comando. Isso pode resultar de um comprometimento de suas credenciais, mas pode ser tão simples quanto alguém sentado em sua mesa quando você se afasta por um segundo.

Acho que não preciso digitar minha senha com frequência. Depois de digitar sua senha, você poderá executar vários comandos se não esperar muito tempo entre eles. O tempo limite é configurável.

    

Answer 3

Eu só usaria isso em duas circunstâncias:

• Quando é absolutamente necessário para um script automatizado em execução como um usuário específico
• Para tarefas administrativas específicas (leia somente tarefas administrativas, não aquelas que executam ações para alterar o sistema) e somente para usuários específicos, é claro

Por padrão, a maioria das configurações sudo não perguntará novamente por um tempo na mesma sessão (se você abrir um novo shell que não tenha nenhum efeito). Você pode controlar esse comportamento até certo ponto com a configuração timestamp_timeout .

O sudo sem senha não é tão perigoso quanto as chaves ssh sem senha, pois um invasor remoto precisa de suas credenciais para entrar, mas se elas entrarem de alguma forma comprometendo sua chave privada (ou se eles são fisicamente locais para você e você se deixou logado e desbloqueado enquanto estava longe da máquina), então a solicitação de senha é uma defesa extra valiosa entre eles e acesso privilegiado.

Em relação ao seguimento 2:

If I also have a key to log in as root via ssh

Isto é melhor evitar também, exatamente pela razão que você descreve. Se uma conexão remota tiver acesso privilegiado, faça o login por meio de uma conta de serviço e forneça um controle suficiente para fazer seu trabalho via sudo. Isso é mais faf para configurar, claro, muitos não se incomodam (o que funciona a seu favor, se você o fizer, já que há muitas frutas penduradas mais baixas do que você para os invasores passarem tempo lá!), Então isso se resume ao compromisso antigo entre segurança e conveniência (dica profissional: escolha segurança!).

    

Answer 4

Você pode ter o melhor dos dois mundos: autenticação SSH para login e para sudo. Se você integrar o módulo pam_ssh_agent_auth , você pode usar as chaves SSH para autenticar sem dar uma senha quando você sudo.

Eu tenho usado isso em produção há mais de cinco anos.

Para configurá-lo, instale o módulo PAM e adicione uma linha a /etc/pam.d/sudo ou equivalente ao seu sistema:

auth    sufficient     pam_ssh_agent_auth.so file=~/.ssh/authorized_keys

Se você fizer isso, proteja suas chaves no computador com uma frase secreta. Dessa forma, alguém teria que invadir seu computador e roubar as chaves para entrar. Eles poderiam fazer isso retirando-os da memória enquanto estavam desbloqueados se tivessem acesso à sua conta, decifrando sua senha ou roubando sua frase-senha. um keylogger ou ombro surfando enquanto você digita (olhe para trás!).

Você pode usar a mesma chave SSH para fazer o login, ou pode configurar uma chave separada que você só adiciona ao seu agente quando você sudo. Então, se você quiser ser extremamente cuidadoso, você pode manter um arquivo authorized_keys separado que tenha uma chave SSH separada que você só adiciona ao seu agente quando precisar sudo:

auth    sufficient     pam_ssh_agent_auth.so file=~/.ssh/authorized_keys_sudo

    

Answer 5

Desde que você perguntou, aqui estão meus conselhos gerais sobre como abordar o problema sudo .

O Sudo não foi projetado para fornecer mais segurança (embora possa ser de alguma forma) ... mas sim fornecer uma boa trilha de auditoria de quem está fazendo o que, no seu sistema, com quais privilégios.

Um Sudo configurado corretamente não usará a configuração ALL=(ALL) ALL , mas sim algo mais limitado ao que é especificamente que o usuário precisa. Por exemplo, se você precisar que um usuário possa fazer o login e reiniciar um serviço emperrado, provavelmente ele não precisará instalar um novo software ou encerrar o servidor, alterar as regras do firewall, etc.

Às vezes, é comum as pessoas usarem o sudo para se elevarem para a conta root, ou seja, %código%. Depois de fazer isso, você para de ver quem está fazendo o quê a partir da conta raiz (a raiz pode ser conectada várias vezes ao mesmo tempo). Então, às vezes, as pessoas também querem desabilitar o comando sudo su - . Mas, por razões práticas, se você precisa de uma conta totalmente privilegiada para a administração, no mínimo ter alguém emitindo o comando sudo su - registraria quem passava a raiz e quando.

Como posso proteger minhas caixas:

Altere a porta SSH para algo diferente do padrão. Isso é para evitar os dumb-bots que procuram por números de porta e então liberam até entrarem (ou não).

Proibir o login raiz através do SSH usando a configuração sudo su - no seu sshd_config. Isso impede que alguém faça brute na sua conta root. Em geral, é recomendável nunca permitir que alguém faça login diretamente na conta raiz / administrador por motivos de auditoria e segurança. Se você permitir login root diretamente, você não sabe quem está logado, de quem ele tirou a senha, etc. Mas, se alguém entrar na conta de Jimmy, então eleva suas permissões para root, você tem uma idéia melhor de onde começar pesquisa de auditoria (e quem é a conta para redefinir).

Permitir somente usuários que precisam de SSH Use a configuração AllowRootLogin no e especifique explicitamente quais contas precisam de acesso SSH. Por padrão, isso bloqueará todas as outras contas do SSH.

Edite Sudoers via visudo e permita somente os comandos que o usuário precisa. Há muitos guias detalhados sobre como fazer isso, então não detalharei aqui. Aqui está uma entrada: link

A essência disso é evitar que uma conta comprometida coloque em risco sua máquina. ie. se a conta de Sally for invadida, e Sally só puder usar sudo para reiniciar o servidor web, o invasor pode se divertir reiniciando seu servidor web em um loop, mas pelo menos eles não podem AllowUsers ou abrir todas as suas portas de firewall, etc.

Configure boas regras de firewall que permitam apenas as portas necessárias para o funcionamento da sua caixa. Geralmente, você quer largar tudo e permitir explicitamente o que precisa. Há uma abundância de iptables decentes e outros firewalls são iniciados online, aqui está um que eu uso (é um bom começo):

# Generated by iptables-save v1.4.7 on Mon Mar  3 17:55:02 2014
*filter
:INPUT DROP [4528:192078]
:FORWARD DROP [0:0]
:OUTPUT ACCEPT [39845:27914520]
-A INPUT -i lo -j ACCEPT
-A INPUT -p tcp -m tcp ! --tcp-flags FIN,SYN,RST,ACK SYN -m state --state NEW -j DROP
-A INPUT -m state --state RELATED,ESTABLISHED -j ACCEPT
-A INPUT -p tcp -m tcp --dport 4254 -m state --state NEW -j ACCEPT
-A INPUT -p tcp -m tcp --dport 8080 -m state --state NEW -j ACCEPT
-A INPUT -p tcp -m tcp --dport 8443 -m state --state NEW -j ACCEPT
-A INPUT -p icmp -m icmp --icmp-type 8 -j ACCEPT
-A INPUT -p icmp -m icmp --icmp-type 11 -j ACCEPT
-A OUTPUT -o lo -j ACCEPT
COMMIT
# Completed on Mon Mar  3 17:55:02 2014

Também é uma senha strong. Mesmo se você usar as chaves SSH para o seu acesso remoto, você ainda deve exigir uma senha para o uso do Sudo. Este é um caso em que o sudo pode oferecer mais segurança. Se alguém roubasse suas chaves ssh, elas ainda seriam impedidas de fazer algo significativo em sua caixa se ainda tivessem que usar a senha da sua conta para usar o sudo. As senhas não devem ser uma palavra, mas sim uma frase secreta. Pense em uma frase e use isso. Isso geralmente lhe dará algo com mais de 8 caracteres, fornecendo muita entropia, mas também é mais fácil de lembrar do que uma senha aleatória. É claro que boas práticas de senha dizem usar uma senha aleatória gerada por uma máquina para enganar ferramentas como o John the Ripper, que vai passar pela maioria das senhas e senhas. Não, mudar E com 3 não funciona, John recebe essas permutações também.

    

Answer 6

Em alguns casos, é necessário fazer isso. por exemplo. algumas APIs do hipervisor precisam de login sem senha e sem senha sudo . Mas você ainda pode restringir isso sem quebrar.

Para o que você está tentando alcançar. Eu diria, acostume-se a digitar uma senha. A segurança é mais conveniente que a conveniência aqui. Além disso, se você realmente precisar de acesso root, poderá usar sudo e armazenará em cache as credenciais por algum tempo, de modo que, se você executar vários comandos sudo em fila, ele só solicitará a senha pela primeira vez. Portanto, não é um grande inconveniente como você supõe.

Além disso, se você digitar muitos comandos com privilégios de root e não quiser colocar o sudo na frente deles o tempo todo, você pode su ou sudo -s para obter um shell de root. Você vai digitar sua senha uma vez e então é isso.

    

Answer 7

Eu fui mordido por sudo sem senha uma vez. Era um script de shell, algum instalador que chamava sudo em meu nome ao invés de, você sabe, apenas requerendo sudo ou errando.

Imaging digitando 'make' e o script fazendo a parte 'sudo make install' para você, sem definir ou exibir o caminho base, e o script é tão confiável que, em primeiro lugar, você não tem certeza de que sabe / usr / local e então você começa a verificar / usr para modificações ...

Eu prometi nunca usar o NOPASSWD novamente e também mudei o tempo limite para 0.

    

Answer 8

Embora não responda estritamente a sua pergunta, outra opção pode ser definir um timestamp_timeout maior, para que você não precise digitar sua senha com muita frequência. Isso evitará que qualquer um tenha privilégios de administrador, mas reduzirá seu incômodo.

Na página de manual dos sudoers :

timestamp_timeout

Number of minutes that can elapse before sudo will ask for a passwd again. The timeout may include a fractional component if minute granularity is insufficient, for example 2.5. The default is 5. Set this to 0 to always prompt for a password. If set to a value less than 0 the user’s time stamp will never expire. This can be used to allow users to create or delete their own time stamps via "sudo -v" and "sudo -k" respectively.

Esta postagem do blog mostra alguns exemplos usando visudo para definir o tempo limite em minutos, como:

Defaults timestamp_timeout=60

Talvez este seja um meio-termo feliz entre segurança e facilidade de uso?