SSH: su raiz ou sudo? [duplicado]

Question

Qual é a melhor opção: Usando o su para mudar para o sudo root ou enabeling? Sem o uso de sudo, um intruso precisaria saber a senha (ou chave) de um usuário permitido para ssh e, em seguida, também a senha raiz. Com o sudo, a senha do usuário não privilegiado seria suficiente.

Eu configurei um novo servidor da Web (Debian 8.2) e estou querendo saber qual é a melhor prática para fazer a conexão a ele via SSH segura e ainda fácil para mim trabalhar com ela.

Até agora, desativei PermitRootLogin no SSH e mudei a porta. Também iptables está no lugar bloqueando tudo que eu não preciso. Agora eu tenho que entrar com um usuário sem privilégios e, em seguida, alternar com

su root

Mas trabalhar como root não é a melhor coisa que eu já ouvi ... Então, pensei em apenas conceder direitos de sudo ao usuário sem privilégios.

Então, novamente, um intruso só precisaria saber uma senha, já que o sudo está solicitando a senha atual dos usuários e não a senha raiz. Então, meu plano para tornar mais difícil para um invasor desabilitar o PermitRootLogin no SSH não está funcionando mais.

Então: su root ou sudo?

    

Answer 1

So far I have disabled PermitRootLogin on SSH and switched the port.

Não sou muito fã de executar serviços em portas não padrão; você torna a interoperabilidade mais difícil para você e para os outros, sem nenhum ganho real. Com uma senha decente (ou melhor: chave), as verificações SSH aleatórias não têm chance de sucesso de qualquer maneira, e os ataques direcionados não são desativados por uma porta diferente.

But working as root isn't the best thing to do I've heard... So I thought about just granting my unprivileged user sudo rights.

Esta é uma preferência pessoal; existem razões válidas para escolher uma das abordagens.

Pessoalmente, prefiro evitar o sudo, principalmente porque é muito mais complexo que o su. E essa complexidade carrega um risco de segurança maior, tanto na configuração do sudo, quanto no próprio sudo (tem havido vários avisos de segurança ). O sudo pode ser muito útil para permitir que um usuário sem privilégios execute comandos muito específicos sem senha.

Dito isto, mudar para o root e usar o sudo da maneira que você descreve é praticamente intercambiável, exceto por algumas coisas:

• O Sudo pode registrar cada comando executado através dele. Ao usar o su, você precisa confiar no histórico do shell do root para registrar. (No entanto, um invasor pode contornar isso, por exemplo, simplesmente fazendo sudo su )

• Com o sudo, você normalmente precisa da senha do seu usuário, com su você precisa do root.

• Com o sudo, é mais fácil intercalar comandos privilegiados e não privilegiados.

  No entanto, eu geralmente me encontro fazendo tarefas administrativas para as quais preciso de muito root, ou algo não administrativo para o qual não preciso de root. E, para evitar confusão, colore meus prompts do shell para distinguir entre raiz (vermelho) e usuário (azul).

• Por padrão, o sudo é limitado a determinadas contas.

  Para su, uma coisa semelhante pode ser obtida usando pam_wheel.so para limitar su-to-root a membros de um determinado grupo. ( addgroup --system wheel , adduser YOU wheel , descomente a linha pam_wheel em /etc/pam.d/su )

Should I disable SSH Authentication via password and just use keys? Then it would be difficult for me to access the server if I'm not on my own laptop.

Sim, esse é provavelmente um dos maiores ganhos em segurança.

Você pode conceder acesso para as chaves SSH de suas contas em várias máquinas (confiáveis).

Se as máquinas não forem confiáveis, você deve considerar não fazer login a partir delas; eles poderiam injetar comandos ou ter um keylogger farejando suas senhas.

Algumas dicas adicionais:

• Considere limitar o acesso SSH às contas de usuários que precisam de acesso SSH.

  Eu gosto de fazer isso por addgroup --system allowssh e, em seguida, em /etc/ssh/sshd_config setting PubkeyAuthentication no e adicionando uma sub-rotina Match Group allowssh\n PubkeyAuthentication yes .

  Tenho certeza de que isso também pode ser feito por meio do PAM, usando algo como auth required pam_succeed_if.so quiet_success user ingroup allowssh in /etc/pam.d/sshd .

• Considere a instalação de um logchecker que relate anomalias. Para reduzir o volume de e-mails, você pode considerar ter as tentativas de login bem-sucedidas enviadas, em vez das tentativas mal-sucedidas.

Answer 2

Meus pensamentos:

• Defina PasswordAuthentication e PermitRootLogin para no
• Opcionalmente, passe a senha em suas chaves SSH (embora não seja possível impor isso)
• Use o MFA como a resposta de Tim sugere para restringir ainda mais o acesso SSH (pessoalmente, eu faria isso via Plugin do Google Authenticator do PAM )
• Não ative o sudo sem senha e garanta que senhas strongs sejam definidas para seus usuários.
• Alterar a porta para SSH não é realmente necessário, qualquer scanner de porta dedicado acabará encontrando sua porta aberta.
• Use Fail2Ban para proteger contra ataques SSH de força bruta
• Desative o encaminhamento de porta configurando AllowTcpForwarding no
• Com relação ao iptables, use uma regra de "negação padrão" para descartar sistematicamente qualquer coisa que não esteja na sua lista de permissões de portas.
• Se você for super-paranóico, use iptables para restringir o acesso SSH a um endereço IP válido (observe que isso não é uma boa ideia se você estiver acessando de casa ou de um endereço IP que possa mudar).

Answer 3

O que fazemos (empresa ops) é desabilitar logins de senha e permitir somente chaves. Use um criptograma (novo nome, NitroKey ) ou apenas um cartão inteligente , mas isso significa que você também precisará um leitor junto. Desta forma você tem autenticação de dois fatores, algo que você tem (o stick ou cartão) e algo que você conhece (a senha para o sudo).

Nunca mude para o root, a menos que realmente seja necessário, considere isso uma prática ruim e sempre reserve um tempo para considerar se realmente precisa mudar.