Como você renomeia root?

25

Não que seja uma boa ideia mudá-lo, mas por diversão. De acordo com este post, ainda existem alguns problemas, mesmo depois de alterar as entradas em /etc/passwd , /etc/shadow e /etc/sudoers . Alguma sugestão?

    
por yxkb 02.03.2011 / 06:58

5 respostas

28

Teoricamente, alterá-lo em /etc/passwd e /etc/shadow seria tudo o que você precisa para renomear a raiz. O problema ocorre porque praticamente todas as partes do software Unix existentes presumem que o nome de usuário 'root' existe e que é o superusuário - aliases de e-mail, vários daemons, cron ...

Se você está realmente empenhado em tentar, find /etc -type f -exec grep -l root {} + deve ser um bom começo para encontrar uma lista de cada arquivo de configuração que você provavelmente precisará alterar - mas como você já disse, essa é uma péssima idéia em quase todas as situações imagináveis.

    
por 02.03.2011 / 09:30
21

Todo esse temor de medo, dizendo "Não faça isso!" é ridículo. Uma vez, sim, provavelmente quebrou muitos roteiros mal escritos, mas suspeito que eles não são mais tão comuns; pelo menos não nas distribuições padrão.

Disseram-nos para renomear a conta root em um subconjunto de servidores linux. Então, depois de tentar pesquisar como fazer isso corretamente, eu encontrei muitos posts dizendo "Não faça isso!" com muitos avisos terríveis de "coisas ruins" acontecendo se você optar por fazer isso. Mas ainda não encontrei nenhum com exemplos concretos das "coisas ruins" que poderiam acontecer.

Então, deixe-me voltar e explicar onde estou e como chegamos aqui. Estamos construindo um ambiente compatível com PCI, e uma das ferramentas que nos ajuda a atender a esses "requisitos" está nos dizendo que precisamos renomear as contas root e administrator e guest para outra coisa. Para aqueles sem instrução sobre PCI, você tem a opção de seguir as diretrizes ou documentar por que você não pode ou não seguir essa diretriz e qual estratégia de mitigação você tem para manter os sistemas seguros. Então, eu imagino que a maioria dos lugares documenta porque eles não vão renomear suas contas de root, no entanto, nosso grupo decidiu que, se pudermos renomear as contas de administrador do Windows sem problema, iremos renomear as contas de raiz do Linux também. / p>

Estou bem versado nos argumentos de "segurança através da obscuridade"; Eu sei que apenas mudar o nome da conta raiz não melhora muito a segurança, o root deve ser desativado no SSH, etc. Eu sei, não é esse o ponto, eu não estou interessado em ouvir mais. Eu também não estou interessado em mais "o céu vai cair" avisos. Estou à procura de declarações como esta: "> esta coisa ruim < acontecerá com > este pacote padrão < (a menos que você > faça isso <)".

Até agora eu tenho 3 sistemas CentOS (RHEL) que aparentemente não têm problemas em renomear a conta root. Aqui está o que eu fiz: Eu mudei o nome da conta em / etc / passwd, / etc / shadow, / etc / group e / etc / gshadow. Então grepped para o nome root em / etc / e modifiquei o arquivo aliases do postfix para que root fosse um apelido para o nome da nova conta, chame-o rojotoro. (Algo semelhante deve ser feito para outros sistemas de e-mail). Eu também achei que precisava alterar algumas configurações para logrotate ao descrever quem deveria possuir os arquivos que criaria automaticamente. E isso foi tudo o que mudei até agora.

Eu olhei muitos scripts init.d, mas não mudei nada, e tudo parece começar bem na inicialização. Eu tenho que especificar a nova conta ao usar o sudo: "sudo-u rojotoro vim / etc / passwd" como um exemplo, mas eu realmente não precise alterar nada dentro do arquivo sudoers. Eu esperava talvez alguns problemas com o selinux que nós temos e reforçamos, mas até agora eu não precisei tocar nesse sistema.

Eu também posso ver que os scripts mkdev ou mkfs podem precisar ser ajustados, mas eu não planejo usá-los, então eu não olhei para eles com o escrutínio que merecem.

Se é realmente tão fácil mudar sem efeitos negativos em um sistema que permite o uso do selinux, por que a continuação de todo o temor?

    
por 30.03.2012 / 17:56
7

sugestão: não faça isso.

Algumas ferramentas tentam falar com o root via uid, lá você não deve ter problemas. algumas ferramentas assumem que sua conta root é chamada root e será quebrada. a menos que você esteja preparado para, como, recompilar metade do seu sistema "por diversão", apenas não tente.

    
por 02.03.2011 / 12:01
4

Na minha opinião, o mais fácil é criar um novo usuário (alias), com UID 0 e /root como home.

Por que você não alterna o shell padrão de sua raiz para /bin/false ou /sbin/nologin (para que ninguém possa fazer login, mas o sistema ainda o use) e faça o login no novo alias criado?

razvan@naboo ~ $ head -2 /etc/passwd
root:x:0:0:root:/root:/bin/nologin
root2:x:0:0:root:/root:/bin/bash
razvan@naboo ~ $ su -
Password:
su: Authentication failure
razvan@naboo ~ $ su root2
Password:
naboo razvan # whoami
root

Se você mudar o shell do root para o nologin, o sudo, mail ou ftw não será danificado.

    
por 29.05.2012 / 05:26
2

O Linux não é o Windows e a raiz não pode ser renomeada no momento sem criar problemas futuros desconhecidos.

Desabilitar o login remoto e até mesmo local como root é uma abordagem mais segura porque desabilita ativamente a raiz da conta! O UBUNTU essencialmente faz isso e força o sudo ao invés do acesso root.

Essencialmente, ninguém pode usar a conta root para atacar seu sistema, uma vez que ele não pode mais ser usado para acessar o sistema!

Seria bom se uma maneira padrão fosse criada para modificar facilmente o nome da conta raiz, bem como gerar seu UID aleatoriamente após a instalação e, se possível, a cada inicialização a frio para evitar a segmentação UID, mas que atualmente não existe. / p>

Ajustando o / etc / passwd Modificar root: x: 0: 0: raiz: / root: / bin / nologin

Crie uma única conta de administrador de fallback para USO DE EMERGÊNCIA SOMENTE! fallbackadmin: x: 0: 0: root: / root: / bin / bash

Implemente o sudo para todos os administradores para que a auditoria do log de alterações possa ser implementada para acompanhar com precisão quem faz as alterações para a responsabilidade!

Isso implementa os requisitos do PCI US Gov para desabilitar as contas padrão de administrador / convidado e criar uma única conta de administrador de uso de emergência.

Uma maneira de arquivar logs para auditoria é coletar o histórico de terminal de todos os usuários com acesso à conta sudo se o AAA centralizado não estiver implementado.

Uma solução para implementar contas somente de administrador é criar uma conta somente de usuário e uma conta ativada sudo, forçando o usuário a su para sua conta ativada sudo para acesso administrativo.

Você também pode implementar a autenticação com cartão inteligente se quiser uma melhor segurança, pois existem soluções disponíveis para o GNU / Linux que se comparam às soluções CAC de cartão de acesso comum dos EUA para autenticação de dois fatores.

    
por 19.05.2015 / 21:32

Tags