Renomeie / etc / passwd e / etc / shadow por motivos de segurança [fechado]

Eu tenho um servidor Meu servidor está seguro, mas vamos imaginar um bom hacker que entre nele. Ele agora pode investigar /etc/passwde /etc/shadow. Eu gostaria de renomear esses arquivos /etc/passwdpara algo como /etc/xxanoda.

Eu pensei que podia fazer um link, mas para um hacker será fácil ls -l.

É possível renomear esses arquivos e ainda ter um sistema operacional em execução, sem problemas de compatibilidade ou é completamente inútil? Apenas pela busca do conhecimento.

O padrão de hierarquia de sistema de arquivos para sistemas do tipo unix inclui /etc/passwdem um local fixo e, consequentemente, as ferramentas geralmente são codificadas para procurá-lo. Embora em teoria você possa recompilar todos os utilitários relevantes para procurar em um novo local, qualquer invasor sempre pode procurar por seqüências de caracteres nesses binários para localizar o novo arquivo ou usar expressões regulares para encontrar arquivos com passwdconteúdo semelhante.

O shadowarquivo deve ser legível apenas para root(e possivelmente para um grupo chamado shadow). Se um invasor conseguiu obter acesso root ao seu sistema, ele tem controle total e se é ou não capaz de ler seus arquivos de senhas / sombras é bastante irrelevante nesse ponto.

É possível imaginar algumas situações em que ter arquivos que não estão nos locais esperados pode ajudar, por exemplo, se você tiver um servidor da Web mal configurado que permita que alguém solicite http://myserver/../../etc/passwd, mas, em geral, esse tipo de indireção exigirá muito trabalho para um benefício mínimo de segurança.

A melhor coisa que seria seria "completamente inútil", como você diz. (Ele não fornece um obstáculo adicional para um invasor)

/etc/passwd contém nomes de contas, mas qualquer pessoa que tenha acesso shell ao sistema poderá encontrá-los.

/etc/shadowcontém informações confidenciais (os hashes da senha), mas são legíveis apenas para raiz. Se um invasor conseguiu obter privilégios de root - bem, como se escreve desastre ?

Nos Unices modernos (e similares ao Unix, incluindo o Ubuntu), /etc/passwdnão contém nenhum segredo. Renomeá-lo seria mais problemático do que vale, considerando quantos utilitários precisariam ser reconstruídos para procurá-lo em seu novo local.

/etc/shadowé outra questão, pois há segredos nesse arquivo, mas renomeá-lo não ajudará. É legível apenas pela raiz; portanto, mesmo que um hacker entre no sistema como outro usuário, isso não é suficiente para acessar o arquivo. É por isso que as senhas foram retiradas: /etc/passwdem primeiro lugar, todos precisam ser capazes de ler /etc/passwd, mas apenas o root precisa acessar as senhas reais; portanto, as senhas foram movidas para um arquivo que somente o root pode ler.

Se o hacker faz obter raiz, em seguida, uma mudança de nome não vai te salvar. Uma simples recursiva greppode fornecer ao hacker uma lista de arquivos em um /etc/shadowformato semelhante, e então o hacker só precisa procurá-los para encontrar os dados que deseja. Você o atrasou por algumas horas, no máximo, e provavelmente menos: novamente, não vale o tempo necessário para modificar e recompilar todos os utilitários que dependem /etc/shadowda localização do mesmo.

Você não pode simplesmente renomear esses arquivos. Muitos processos e programas os procurarão, pois esse é um padrão nos sistemas Linux. O que você pode fazer é proteger seu servidor da maneira correta.

Embora provavelmente não seja possível renomear os arquivos /etc/passwde /etc/shadow, se você quiser segurança adicional, consulte o PAM (módulos de autenticação conectáveis) e o NSS (Name Service Switch). Como aqui.

O PAM pode ser usado para adicionar módulos de autenticação que, em vez de ler suas informações de autenticação nos arquivos padrão, os leem de outra fonte, como do ldap ou de um banco de dados. Usá-lo significaria que a /etc/shadowquase totalidade pode ser eliminada.

O NSS complementa o PAM, tornando parte da resolução de nomes (como em quais grupos esse usuário pertence) independente dos arquivos padrão ( /etc/passwd, /etc/groups). Usá-lo significaria que seu arquivo passwd conterá potencialmente apenas uma opção de fallback para raiz e nada mais. O uso de chaves SSH para validar o login raiz também eliminaria a necessidade de ter uma senha raiz dentro do arquivo shadow (embora isso possa ser desejado se a conexão SSH for interrompida).

Como alternativa, se você não deseja autenticar seus usuários por meio de um banco de dados ou host ldap separado, também pode criar seus próprios módulos PAM e NSS, que lêem os dados de um arquivo não padrão, embora eu não recomende esta opção.

Quando você quiser usá-los, nunca se esqueça de manter algum tipo de fallback para uma camada de autenticação conhecida e funcional, caso contrário, você poderá se bloquear do sistema, mesmo com o root.

Observe que nem todos os aplicativos suportam o PAM (muitos deles, no entanto). No entanto, o NSS pode ser usado para implementar a autenticação de aplicativos que não oferecem suporte ao PAM, e alguns sites que li sobre o NSS sugerem essa abordagem. No entanto, isso significa que o módulo NSS fornecerá a senha (potencialmente) para qualquer pessoa que possa acessar a camada de autenticação NSS, quase sempre algo que você deseja evitar (é basicamente o mesmo que fornecer acesso de leitura não raiz ao arquivo shadow )! Portanto, se você seguir essa abordagem, verifique sempre se o NSS é usado apenas para fornecer ao usuário os dados básicos (como o conteúdo de /etc/passwd) e se o PAM é usado como a camada de autenticação.