ipv6 vários endereços e firewall na máquina remota

4

Eu tenho um servidor Ubuntu (serverA) que tem um par de endereços IPv6. Um deles é baseado no seu endereço MAC, e é conhecido pela rede, o outro eu presumo que o Ubuntu criou como um endereço 'privado' que esconde o endereço MAC.

Eu tenho outro servidor (serverB) que hospeda um banco de dados e requer uma conexão de entrada do serverA. O servidorB tem um firewall, permitindo apenas conexões de entrada do servidorA. Eu especifiquei o endereço IP baseado em MAC do servidorA nas exceções de firewall do servidorB, mas sem saber o endereço privado, não incluímos isso. No entanto, os empacotadores do serverA parecem estar voltando do endereço privado.

O endereço privado é determinista? Como posso desativá-lo? Devo desativá-lo?

    
por askvictor 18.07.2013 / 08:13

2 respostas

3

O endereço de privacidade deve ser aleatório e mudar frequentemente. Não deveria ser determinista; isso seria antitético ao conceito. Deve ser usado para conexões de saída.

Eu não recomendo desabilitá-lo, porque é útil para não divulgar seu MAC como o SLAAC (o termo apropriado para o endereço derivado de MAC) faz. No entanto, algumas pessoas que valorizam a capacidade de determinar qual host fez uma conexão posteriormente preferem desabilitá-lo.

Se você precisar usar ACLs baseadas em IP, terá que desativá-lo. Você pode fazer isso adicionando ip6-privacy=0 à seção ipv6 de /etc/NetworkManager/system/connections/ . Você também pode querer inspecionar /etc/sysctl.d/10-ipv6-privacy.conf se isso não colocar um fim nisso.

    
por 18.07.2013 / 08:22
1

Vou me concentrar na sua última pergunta: Você deve desativar endereços particulares?

Concordo com @Falcon que as extensões de privacidade definidas em RFC 4941 são úteis. Eu sempre os habilitaria em clientes / estações de trabalho que podem se conectar a serviços na Internet, e espero que os fabricantes de telefones móveis em breve os habilitem por padrão em todos os seus dispositivos.

Mas em sua configuração, você está falando sobre dois servidores, em que um deles é (não apenas, suponho) agir como um cliente para o outro servidor. As primeiras perguntas seriam: Qual é a sua configuração? Esses servidores estão na rede da sua empresa? Qual acesso externo eles terão? serverA nunca se conectará à Internet (sem um proxy)? Se todo o tráfego é interno e você não vê uma ameaça por um adversário que mapeia seus padrões de tráfego de rede interna, basta desativar as Extensões de Privacidade nos servidores. Um servidor deve, por definição, ter pelo menos um endereço que seja bem conhecido de seus clientes, principalmente via DNS, para que um invasor possa usar esse endereço para atacar o servidor. Ocultar seu endereço não é uma estratégia de mitigação de ataque válida para um servidor. (Colocar balanceadores de carga na frente com seu endereço é, claro.)

Os Perfis padrão do DoD IPv6 dos EUA para produtos com capacidade para IPv6 " (desculpe, não consegui encontrar um link para uma versão mais recente que 5.0) também exijo Extensões de privacidade para hosts / estações de trabalho "que operarão em redes que exigem extensões de endereços de privacidade ou precisam manter o anonimato" e recomende-as outros hosts / estações de trabalho. Esse requisito vai para servidores somente se eles também atuarem como clientes (como em sua configuração) e precisam manter o anonimato (que você deve decidir). Portanto, o servidor geral não precisa de extensões de privacidade ativadas.

Com relação às ACLs: Se endereços IPv6 embutidos em código devem ser usados em vários locais, eu consideraria a definição de endereços IPv6 fixos em seus servidores. Você pode configurá-los nos servidores e no DNS ou distribuí-los via DHCPv6, mas você terá menos trabalho, em comparação com os endereços SLAAC, se precisar substituir uma NIC ou um servidor.

Portanto, em resumo: Se os seus servidores só se comunicarem internamente e não tiverem requisitos de segurança avançados contra a análise de tráfego, desative as Extensões de privacidade. Em qualquer outro caso, você deve equilibrar seus prós e contras.

HTH.

    
por 18.07.2013 / 10:39