Sei que uma das primeiras coisas que você faz para proteger um servidor é proibir o login raiz remoto.
As senhas são muito fracas; o que as pessoas pensam em permitir apenas o login raiz através de chaves ssh ou outros métodos sem senha.
Quais métodos são os melhores? É melhor não arriscar? O ssh-ing com uma conta secundária e o uso su -realmente adicionam alguma segurança?
Como as pessoas no serverfault.com acessam a raiz em um servidor remoto?
Respostas:
Na maioria das vezes, pouco se ganha ao desativar logins raiz remotos. Ajuda marginalmente a impor uma política que os administradores fazem logon por meio de suas próprias contas e sufazer root conforme necessário (ou usar sudopossivelmente com sudosh... dependendo de suas políticas).
A criação de senhas raiz extremamente longas e complicadas (efetiva desde que você ainda não esteja usando o antigo hash DES + 12 bits para suas senhas) é tão eficaz na imposição de tal política.
Um site com o qual eu estou familiarizado tinha um sistema pelo qual as senhas exclusivas eram geradas aleatoriamente para cada host, armazenadas em um banco de dados e enviadas para os sistemas. Os administradores eram obrigados a usar sshcom suas contas normais e sudona maioria das operações. No entanto, a senha raiz era acessível a eles por meio de um serviço da Web interno baseado em SSL (que exigia ainda seu token e PIN RSA SecurID). A busca de uma senha root implicou a inserção de uma justificativa (geralmente um link para um número de ticket do Remedy (TM)) e acessos onde auditados periodicamente. Um dos poucos motivos aceitáveis para o uso direto da senha root foi nos casos em que um sistema foi parado fsckdurante o processo de inicialização ... esuloginestava exigindo uma senha root real para executar manualmente os processos de verificação e reparo do sistema de arquivos. (Houve uma discussão sobre métodos alternativos para isso --- que são relativamente fáceis para o Linux, mas ficam muito mais difíceis ao tentar estender seus procedimentos para explicar os muitos sistemas herdados HP-UX, AIX e SunOS e Solaris mais antigos que ainda estavam em produção naquele ambiente).
Existem casos em que uma senha root é necessária - ou pelo menos é a melhor alternativa disponível. Mantê-lo disponível e torná-lo suficientemente robusto contra os tipos de ameaças que você pode prever geralmente é sua melhor estratégia.
Outro site que conheço tem uma abordagem bastante elegante para o gerenciamento de contas descentralizado. Eles possuem pacotes user- * e sudo- * (pense em RPMs) que são instalados nos sistemas usando os procedimentos normais de gerenciamento de pacotes e a infraestrutura de automação. No caso deles, o pacote sudo- * depende do pacote user- * correspondente. Isso é bom porque permite que você tenha agrupamentos de máquinas com contas localizadas (todas as contas são administradores, desenvolvedores, equipe de suporte ou contas "sem cabeça") e elimina a dependência do LDAP / NIS ou de outros serviços de identidade e autenticação em rede. (Isso reduz o acoplamento entre os sistemas, os torna significativamente mais robustos).
Acho que gosto dessa abordagem: ela oferece flexibilidade. Qualquer pessoa com sudoacesso pode emitir um comando para adicionar um usuário normal ou outra sudoconta de usuário. Portanto, se estou trabalhando em um ticket, qualquer pessoa que já tenha acesso a um sistema pode facilmente me dar acesso. Não há atrasos enquanto um ticket para me adicionar a alguma lista de controle de acesso em alguns bancos de dados centrais passa por algum processo de aprovação centralizado e, por fim, propaga uma mudança de volta para o sistema em questão. Qualquer um dos sudousuários autorizados no sistema pode me dar acesso e depois me remover. (Sim, se eu fosse mau e eles me brincassemsudoEu poderia modificar coisas maliciosamente para manter o acesso ... na verdade, existem algumas coisas que eu poderia fazer como um usuário normal para manter o acesso após essa remoção. No entanto, essa não é a ameaça com a qual eles estão preocupados. Meu acesso ainda está limitado a um número relativamente menor de sistemas em geral; portanto, o impacto de uma conta comprometida ainda é mais limitado do que a maioria dos esquemas semelhantes que já vi.
Se você desabilitar o acesso remoto à raiz, evita que os atacantes remotos obtenham root diretamente - eles precisam quebrar outra conta, obter acesso à máquina e tentar obter acesso à raiz. É um passo extra.
Geralmente, o root está desativado para acesso remoto. SU funciona bem. Se algo realmente quebra, sempre há acesso direto à caixa para corrigi-lo.
Se você quer ser mais rigoroso - basta desativar o root completamente, é para isso que o sudo existe. Novamente, com essa abordagem, você ainda pode obter acesso root passando para o modo de usuário único - no Ubuntu. No entanto, acredito que eles usaram um init corrigido para isso, conforme seus documentos.
Além disso, você pode configurar o modo inativo para iniciar usuários inativos, caso seus terminais permaneçam abertos e os PCs também estejam abertos. Você pode forçar todos os usuários a usar chaves, mas o gerenciamento de chaves pode ser difícil.
Um único host de registro de passagem como um sistema do tipo quebra-vidros também forçou uma camada adicional de proteção e uma trilha de auditoria.
Sugiro que você configure o sistema para permitir acesso root SOMENTE no console.
Caso contrário, usando o sudo com a opção de senha, permita que os usuários selecionados acessem os comandos priv'd. BTW, saiba que o sudo pode ser projetado para restringir uma conta de usuário a certos comandos, se você desejar. Sudo, deixa uma "marca" no log do sistema que foi usado. sudo é melhor que su porque a senha root não é divulgada. Assim, você pode alterar a senha root e o usuário que usa o sudo não seria mais sábio.
O uso permitido do sudo para obter comandos privados deve ser acompanhado por alterações periódicas forçadas da senha com a frequência, dependendo do ambiente.
nunca permitir raiz
configurar o sistema para permitir o acesso via chaves apenas sem senhas
configure o sudo para usuários com permissão para fazer alterações via conta raiz