A lógica de desabilitar o logon raiz

Question

Usuário do Ubuntu 14.04 VPS aqui.

Meu VPS foi invadido duas vezes. E a terceira versão está em alta. Dedos cruzados.

O erro que cometi nos dois primeiros foi que eu tinha o login root + password ativado. Eu aprendi desde então que existem bots de força bruta que continuam tentando senhas até passarem. Então, estou indo para a rota privada da chave SSH desta vez, sem senha.

O que aprendi no processo: Por padrão, o Ubuntu Linux não limita as tentativas de senha de maneira alguma. Você pode continuar tentando senhas diferentes para sempre. ~ Shiver ~ .

Eu tenho várias perguntas sobre a lógica de desabilitar o login root:

1. Ainda seria possível que o usuário não-root usasse "su" para se tornar root? Se sim, quantas tentativas de senha são permitidas (ou seja, essa também é uma situação em que, por padrão, não há limite para tentativas de senha?).

2. Ainda assim seria necessário acessar o servidor "de vez em quando", por exemplo, para conceder privilégios de "sudo" a novos usuários, etc. Presumivelmente, um usuário teria uma conta de usuário não-root com "sudo". "privilégios para que se possa ter acesso" semelhante a raiz ". Por que essa ameaça de segurança não é tão grande quanto ter o login raiz ativado?

3. Administradores experientes de servidores Linux geralmente configuram um usuário não-root, de modo que seria necessária uma chave SSH privada E uma senha? Esta parece ser a opção mais segura.

Atualização: percebo que o nome de usuário raiz é um problema aqui. Mas, dadas infinitas tentativas gratuitas, forçar qualquer combinação de nome de usuário + senha é apenas uma questão de tempo.

    

Answer 1

Pergunta: Ainda seria possível que o usuário não-root usasse "su" para se tornar root? Se sim, quantas tentativas de senha são permitidas (ou seja, essa também é uma situação em que, por padrão, não há limite para tentativas de senha?).

Resposta: Sim, ainda há tentativas ilimitadas de se conectar usando 'sudo' e 'su' por padrão, mas você pode limitá-lo com pam.d. A razão pela qual esse problema é mitigado é devido aos atrasos necessários para emitir os comandos su e sudo programaticamente. Eles são projetados para DESATIVAR o ataque de forma que "para sempre" seja MUITO longo tempo e bots não podem realmente fazer ataques de dicionário que valham a uma taxa de 1 por X segundos, onde como com o ssh, alguém pode tentar senhas a uma taxa ridiculamente rápida .

PERGUNTA: Um ainda precisaria de acesso "root" ao servidor de vez em quando, por exemplo, para dar privilégios "sudo" a novos usuários, etc. Presumivelmente, um usuário teria uma conta de usuário não-root com "sudo" privilégios para que se possa ter acesso "semelhante a uma raiz". Por que essa ameaça de segurança não é tão grande quanto ter o login root ativado?

RESPOSTA: o sudo permite que os usuários executem comandos SPECIFIC como outro usuário. Você pode bloquear o sudo para que os usuários possam fazer apenas certas atividades. Com acesso root completo, o usuário não é limitado nem rastreado. Com o sudo, todas as atividades também são rastreadas, a menos que você forneça o sudo para o bash (efetivamente fazendo login como root via sudo).

PERGUNTA: Os administradores de servidores Linux experientes normalmente configuram um usuário não-root, de modo que seria necessário uma chave SSH privada E uma senha? Isto parece-me ser a opção mais segura.

RESPOSTA: Geralmente, o root nunca tem permissão para fazer logon diretamente. Não há equivalência de chaves ssh configurada para raiz. Tudo é controlado via sudo para que você possa acompanhar quem logou e fez o que quando. Geralmente, as grandes empresas só podem fazer logon como root por meio do terminal do console físico ou de um console virtual tty.

Embora você não tenha perguntado isso, você pode classificar um pouco o limite ssh assim:

iptables -A INPUT -p tcp --dport 22 -m state --state NEW -m recent --set --name SSH -j ACCEPT
iptables -A INPUT -p tcp --dport 22 -m recent --update --seconds 60 --hitcount 4 --rttl --name SSH -j LOG --log-prefix "SSH_brute_force "
iptables -A INPUT -p tcp --dport 22 -m recent --update --seconds 60 --hitcount 4 --rttl --name SSH -j DROP