Alcs são o primeiro jogo. Se você excluir os endereços desejados, poderá rejeitar todos os endereços não correspondentes usando qualquer um; em seguida, verifique se a chave corresponde.
allow-update { !{ !allowed; any; }; key keyname; };
Eu configurei um servidor BIND 9 e configurei chaves criptográficas para permitir atualizações de um cliente. Agora no meu named.conf
, defini o seguinte:
allow-update { key dns1.example.org.; };
Isso funciona e eu posso executar atualizações (adicionar, excluir registros de zona) do meu cliente (comando nsupdate
).
Eu estou querendo saber se posso combiná-lo com uma ACL. Basicamente eu quero que o cliente precisa da chave correta, mas também deve vir de uma certa sub-rede ou endereço IP. Posso fazer isso de alguma forma? Não consegui encontrar nada sobre esse cenário nos documentos.
Alcs são o primeiro jogo. Se você excluir os endereços desejados, poderá rejeitar todos os endereços não correspondentes usando qualquer um; em seguida, verifique se a chave corresponde.
allow-update { !{ !allowed; any; }; key keyname; };
Resposta feia # 1
Você pode fazer isso apenas se estiver disposto a ser criativo, feio e totalmente bruto.
Para permitir atualizações apenas a partir de 1.2.3.0/24 com a chave dns1.example.com.
acl “mix-match” {
! 128.0.0.0/1;
! 64.0.0.0/2
! 32.0.0.0/3
! 16.0.0.0/4
! 8.0.0.0/5
! 4.0.0.0/6
! 2.0.0.0/7
! 0.0.0.0/8 //0 instead of 1 since bit is set in the desired network
! 1.128.0.0/9
! 1.64.0.0/10
! 1.32.0.0/11
! 1.16.0.0/12
! 1.8.0.0/13
! 1.4.0.0/14
! 1.0.0.0/15 //0 instead of 2 since bit is set in the desired network
! 1.3.0.0/16 //1-st bit = 1: we DENY hosts with 1.3.0.0/16 but allow 1.2.0.0/16
! 1.2.128.0/17
! 1.2.64.0/18
! 1.2.32.0/19
! 1.2.16.0/20
! 1.2.8.0/21
! 1.2.4.0/22
! 1.2.0.0/23 //0 instead of 2 since bit is set in the desired network
! 1.2.2.0/24 //1-st bit = 9: we DENY hosts with 1.2.2.0/24 but allow 1.2.3.0/24
key dns1.example.com.;
};
Como fazer essa matemática bit a bit:
Eu realmente não tentei, mas deveria funcionar.
Se você tem várias sub-redes permitidas, desejo-lhe boa sorte.
Para o propósito desta resposta, fico feliz que o IPv6 ainda não esteja amplamente implementado. :)
Resposta feia # 2
Configurar o principal servidor de nomes principal furtivo (isto é, não listado como NS), nele as regras de firewall permitem apenas pacotes da sub-rede "permitida" e dos seus servidores de nomes escravos. Neste stealth, permitir atualizações com a chave sozinho. Configure os escravos para obter os dados da zona via AXFR / IXFR e NOTIFY. E não se esqueça de desativar o encaminhamento de atualizações nos escravos.
Uma vez que você fez isso de maneira feia , tenha em mente que qualquer de qualquer lugar pode falsificar o endereço de origem naquele pacote de atualização do DNS UDP, o que torna todos esses esforços completamente inúteis. (Embora você possa desativar o UDP para tornar os esforços um pouco menos inúteis).
Eu sei que você pode definir um match_list, mas não tenho certeza se você pode combinar a chave e a lista de correspondência.
allow-update { address_match_list };
por exemplo:
options {
allow-update { !192.168.2.7;192.168.2/24;};
};
Eu não tentei isso, mas de acordo com o meu entendimento, as definições são:
address_match_list = element ; [ element; ... ]
element = [!] (ip [/prefix] | key key-name | "acl_name" | { address_match_list } )
e, portanto, você pode fazer coisas como
acl “mix-match” {
“two-subnets”;
! 10.10.30.101;
10.10.30.0/24;
key dns1-dns2.example.com;
};
zone "abc.def.example.com" in {
type master;
file "named.abc.data";
allow-update{ mix-match };
};
e, portanto, as transferências de zonas agora estão restritas àquelas que possuem uma chave (além da lista de correspondências).