m4d3

Uma breve explanação sobre o DMZ

Noção de compartimentação

Os sistemas firewall permitem definir regras de acesso entre duas redes. No entanto, na prática, as empresas têm geralmente várias subredes com políticas de segurança diferentes. É a razão pela qual é necessário instalar arquitecturas de sistemas firewall que permitam isolar as diferentes redes da empresa: fala-se assim de “compartimentação das redes” (o termo "isolamento" é igualmente utilizado, às vezes).
Arquitectura DMZ


Quando certas máquinas da rede interna têm de ser acessíveis do exterior (servidor web, um servidor de serviço de mensagens, um servidor FTP público, etc.), é frequentemente necessário criar uma novo interface para uma rede à parte, acessível igualmente da rede interna como do exterior, sem, no entanto, correr o risco de comprometer a segurança da empresa. Fala-se assim de “zona desmilitarizada” (notado DMZ para DeMilitarized Zone) para designar esta zona isolada que aloja aplicações à disposição do público. O DMZ serve assim de “de zona tampão” entre a rede a proteger e a rede hostil.


http://static.commentcamarche.net/pt...images-dmz.gif


Os servidores situados no DMZ chamam-se “bastiões” devido à sua posição antes do posto na rede da empresa.

A política de segurança aplicada no DMZ é geralmente a seguinte:

• Tráfego da rede externa para o DMZ autorizado;
• Tráfego da rede externa para a rede interna proibido;
• Tráfego da rede interna para o DMZ autorizado;
• Tráfego da rede interna para a rede externa autorizado;
• Tráfego do DMZ para a rede interna proibido;
• Tráfego do DMZ para a rede externa recusado.

O DMZ possui por conseguinte um nível de segurança intermédio, mas o seu nível de segurança não é suficiente para armazenar dados críticos para a empresa.

É necessário notar que é possível instalar uma DMZ internamente, para compartimentar a rede interna de acordo com diferentes níveis de protecção e assim evitar as intrusões que vêm do interior.

No MikroTik o conceito de DMZ é pouco ou nada explorado em quase 100% dos load balances, de fato o assunto ainda não foi abordado, como esta cada dia mais comum a utilização de balances entre diversos links escrevi este pequeno tutorial para otimizar as configurações diminuindo sensivelmente o número de regras de redirecionamento NAT.

É bastante comum ao acessar um load balance PCC ou até utilizando outros moldes encontrar o seguinte cenário na tabela NAT:

1. [REDIRECIONAMENTO DE PORTAS SIMÉTRICO 1:1]
add action=dst-nat chain=dstnat dst-port=80 protocol=tcp to-addresses=10.200.200.2 to-ports=80
add action=dst-nat chain=dstnat dst-port=8282 protocol=tcp to-addresses=10.200.200.2 to-ports=8282
add action=dst-nat chain=dstnat dst-port=5060 protocol=tcp to-addresses=10.200.200.2 to-ports=5060

2. [REDIRECIONAMENTO DE TODAS AS ENTRADAS EM CADA LINK PARA O MESMO DESTINO]
add action=dst-nat chain=dstnat in-interface=EthLinkA to-addresses=10.200.200.2
add action=dst-nat chain=dstnat in-interface=EthLinkB to-addresses=10.200.200.2
add action=dst-nat chain=dstnat in-interface=EthLinkC to-addresses=10.200.200.2
add action=dst-nat chain=dstnat in-interface=EthLinkD to-addresses=10.200.200.2
add action=dst-nat chain=dstnat in-interface=EthLinkE to-addresses=10.200.200.2
add action=dst-nat chain=dstnat in-interface=EthLinkF to-addresses=10.200.200.2

3. [REDIRECIONAMENTO DE PORTA ASSIMÉTRICO A:X]
add action=dst-nat chain=dstnat dst-port=8292 protocol=tcp to-addresses=10.200.200.2 to-ports=8291

4. [MASCARAMENTO POR LINK DE SAIDA]
add action=masquerade chain=srcnat out-interface=EthLinkA src-address=0.0.0.0/0
add action=masquerade chain=srcnat out-interface=EthLinkB src-address=0.0.0.0/0
add action=masquerade chain=srcnat out-interface=EthLinkC src-address=0.0.0.0/0
add action=masquerade chain=srcnat out-interface=EthLinkD src-address=0.0.0.0/0
add action=masquerade chain=srcnat out-interface=EthLinkE src-address=0.0.0.0/0
add action=masquerade chain=srcnat out-interface=EthLinkF src-address=0.0.0.0/0


O cenário acima proposto não esta incorreto do ponto de vista prático porém podemos resumir muito as regras utilizando DMZ e um pouco de criatividade, vamos aos exemplos práticos:

1 - [REDIRECIONAMENTO DE PORTAS SIMÉTRICO X:X - PARA TODAS AS PORTAS E PROTOCOLOS, EXCETO PARA PORTAS 8291 E 888 DO PROTOCOLO TCP]
add action=dst-nat chain=dstnat comment="PC.DMZ" protocol=tcp dst-port=!8291,888 in-interface=!EthLB to-addresses=10.200.200.2

2 - [REDIRECIONAMENTO DE TODAS AS ENTRADAS EM CADA LINK PARA O MESMO DESTINO]
add action=dst-nat chain=dstnat in-interface=!EthLB to-addresses=10.200.200.2

4 - [MASCARAMENTO DE TODOS OS LINKS EM APENAS UMA REGRA]
add action=masquerade chain=srcnat out-interface=!EthLB src-address=0.0.0.0/0

Alguma explicação extra:
1. Na primeira regra estaremos direcionando todas as portas exceto o próprio acesso do winbox (8291) e uma porta pro serviço web (888) para a saida do balance (EthLB) normalmente onde teremos um servidor de autenticação dos clientes (10.200.200.2).

2. Da forma que criamos a regra 1 esta segunda nem mesmo é necessária eliminando o bloco 2.

3. O redirecionamento de portas assimétrico continua existindo devendo ser posicionado no inicio da tabela NAT antes mesmo do PC.DMZ.

4. O mascaramento antes feito para cada interface de saída (sim o correto é informar sempre a out-interface) agora é feito apenas uma vez para todas as interfaces menos para a interface que se comunica com o servidor interno utilizando a flag de negação (!) e deve ser a ultima das regras.

Resumo das regras:
add action=dst-nat chain=dstnat dst-port=8292 comment="PC.WBX" protocol=tcp to-addresses=10.200.200.2 to-ports=8291
add action=dst-nat chain=dstnat comment="PC.DMZ" protocol=tcp dst-port=!8291,888 in-interface=!EthLB to-addresses=10.200.200.2
add action=masquerade chain=srcnat comment="PC.MSQ" out-interface=!EthLB src-address=0.0.0.0/0

Conclusão:
Mais limpo e organizado com muito mais funcionalidades e necessitando manutenção praticamente zero pois todas as portas externas já estão redirecionadas para o servidor interno.

Quem já tiver um load balance PCC pode melhorar muito a eficiência do sistema e diminuir a necessidade constante de ficar adicionando novos redirecionamentos pode estar agora utlizar este método. Com isso transferimos as funções de firewall diretamente para o MikroTik autenticador conectado a porta EthLB, podemos trabalhar com o mascaramento das classes utilizadas diretamente no PCC com o envio de rotas para o MikroTik permitindo controles ainda mais precisos sobre o trafego da rede.


Grande abraço.

Luciano Rampanelli / M4D3

Tópico para discussão no fórum MikroTik/balanceamento:
http://under-linux.org/f227/dmz-no-mikrotik-para-load-balance-pcc-por-m4d3-151300/

Artigos:
DMZ (Zona desmilitarizada) | Kioskea.net
DMZ (computação) – Wikipédia, a enciclopédia livre