Como permito que o usuário recarregue o arquivo de zona?

3

Eu tenho um pool de servidores DNS autoritativos que precisam hospedar zonas para 5 usuários, cada um com entre 2 e 10 zonas.

Cada usuário pode ssh para os servidores usando a autenticação de chave pública. Os requisitos que estou enfrentando dizem que desde que o usuário possa se conectar à porta ssh no servidor, eles também devem poder atualizar suas próprias zonas sem depender de qualquer outra comunicação de rede .

O que eu fiz até agora é configurar cada zona a ser carregada a partir do diretório inicial do usuário que possui a zona, como neste exemplo:

zone "example.com" {
     type master;
     file "/home/example/zones/example.com";
};

Não sei se existe alguma recomendação sobre o carregamento de arquivos de zona diretamente do diretório pessoal de um usuário. Tentei algumas pesquisas e não encontrei recomendações a favor ou contra essa prática.

Parece funcionar, mas as alterações só entram em vigor depois que eu reiniciei ou recarreguei o bind, que atualmente tenho que fazer como root.

A distribuição que estou usando fornece BIND 9.8 com patches de segurança. Então baixei a versão 9.8 do "BIND 9 Administrator Reference Manual" para procurar maneiras de um usuário instruir a ligação para recarregar uma zona.

Eu encontrei o comando rndc , no entanto, parece que os controles de acesso no BIND não são refinados o suficiente para permitir que um segredo seja usado apenas para recarregar uma zona específica. Eu posso especificar combinações de endereços IP e acesso secreto aos segredos HMAC-MD5, mas qualquer combinação permitida de acesso será permitida para invocar todos os comandos através de rndc .

Como posso permitir que um usuário recarregue seus arquivos de zona sem conceder a eles outros direitos administrativos?

Neste ponto, estou pensando que eu poderia usar sudo ou a opção command em .ssh/authorized_keys para conceder ao usuário acesso para invocar um comando rndc específico.

Esta é uma abordagem aconselhável ou devo estar fazendo outra coisa?

Eu também considerei o uso de transferências de zona. Mas minha compreensão de como as transferências de zona funcionam é que o servidor DNS de recebimento atua como cliente na transferência de zona e o servidor DNS de envio age como servidor. Se meu entendimento estiver correto, significa que ter um cliente fornecendo uma nova versão da zona para o servidor não é possível. Então, parece que se eu fosse usar essa abordagem, eu teria que usar uma configuração de mestre oculto com esse mestre oculto rodando em um cliente VPN, o que, por razões que não posso formular, parece errado.

    
por kasperd 22.01.2016 / 10:04

3 respostas

12

eu faria isso via sudo

user1    ALL=(root)    /usr/sbin/rndc reload user1.domain1.com, /usr/sbin/rndc reload user1.domain2.com
user2    ALL=(root)    /usr/sbin/rndc reload user2.domain1.com, /usr/sbin/rndc reload user2.domain2.com
    
por 22.01.2016 / 12:27
1

Você pode pedir a seus clientes que usem uma ferramenta rcs, como o git, para atualizar seus arquivos de zona e enviá-los para os respectivos homedirs. Lá, crie um repositório git com um hook de recebimento de post que executa esses comandos usando as regras de sudo que o user1700494 indica (eu adicionaria named-checkzone e named-checkconf também).

Por questões de integridade, aqui estão as regras do sudo user1700494 sugeridas

user1    ALL=(root)    /usr/sbin/rndc reload user1.domain1.com, /usr/sbin/rndc reload user1.domain2.com
user2    ALL=(root)    /usr/sbin/rndc reload user2.domain1.com, /usr/sbin/rndc reload user2.domain2.com

Dessa forma, você mantém tudo no controle de versão para que possa voltar facilmente, se necessário, e seus usuários não precisam efetuar login e modificar arquivos no servidor, tudo pode ser feito em seu próprio ambiente. Além disso, você só recarrega o servidor depois de verificar se os arquivos estão corretos.

    
por 27.01.2016 / 19:40
0

Eu aconselharia cada instância de ligação a ser executada em um LXC. Cada usuário possui sua própria instância de vinculação. Forneça-lhes as credenciais de suas respectivas instâncias.

    
por 27.01.2016 / 14:13

Tags