DMZ no MikroTik para load balance PCC por: M4D3

[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

[braw]

Rapaz soh nao vai ganhar uma estrelinha pq a ultima dei justamente pra vc e o sistema nao deixar dar outra antes de dar pra alguem dif...

[m4d3]

Esquenta não braw, seu reconhecimento é o que há de melhor, abraço meu amigo.

[jamerfay]

Luciano.
Achei show de bola estas regras, até pq a na prática fica mto bom....
simplifiquei todos os redirecionamentos do PCC pro concentrador...
passa lisinho.
Agora qdo fui simplificar os NATs....
o redirecionamento de portas parou...
mesmo assim mudei 20 regras pra apenas 4 XD bom pra caramba.
Obrigado...
"Quando eu crescer quero ser igual a vc"

[rps67]

Vai mais uma estrelinha pra coleção do "Samurai" ... Parabéns Luciano.

[m4d3]

Luciano.
Achei show de bola estas regras, até pq a na prática fica mto bom....
simplifiquei todos os redirecionamentos do PCC pro concentrador...
passa lisinho.
Agora qdo fui simplificar os NATs....
o redirecionamento de portas parou...
mesmo assim mudei 20 regras pra apenas 4 XD bom pra caramba.
Obrigado...
"Quando eu crescer quero ser igual a vc"

Poste dois exemplos dos que não deram certo pra gente tentar reduzir juntos e complementar o tópico se possíve.

Obrigado pela participação jamerfay, juntos somos mais fortes.

[maxibelo]

O cara é show mesmo (QUANDO CRESCER QUERO SER IGUAL A ELE).
Estrelinha não!!!! Constelação pra ti... Sucesso...

[ivangalves]

Valeu Luciano, ficou massa aqui, funcionou redondinho....

[jamerfay]

Luciano, nem precisou...
foi baianada minha aqui.
aquela velha história de copiar e colar sem pensar antes.
qdo fui olhar o erro tava tão estampado que fiquei até com vergonha.
Desculpa ai...
mais que ficou bom ficou... (:

[dimensaonet]

Luciano preciso de uma ajudinha sua...
to usando esse balance pcc que vc montou esta perfeito, o probleminha agora que direcionei meu mkauth pra ser acessado direto da internet pela rede externa mas unica forma que encontei foi add uma porta pra acessalo vc sabe uma regra pra colocar no balance pcc pra liberar a porta 80 pro mkauth to acessando assim...
http://www.airlifesf.com.br:8081/ e queria ver se tem como tirar a porta

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

[claudinhohw]

e no meu caso eu tenho pcc com 3 links de 10mb queria fazer um pptp pra acessar todos os radios da minha rede fica como?

[franciscofabion]

Ola Luciano, Talvez possa me dar uma força

tenho aqui na minha empresa um balance pcc, um link dedicado e um adsl comun.

quando estou com o load ativo, não consigo conectar outra empresa que temos uma vpn.

me foi dito para redirecionar o trafego da porta 1723 para esse link dedicado,

mas não estou conseguindo fazer isso, pois as regras que estou colocando estão esbarrando no load.

sera que conseguiria me dar o caminho das pedras

obrigado

[lazaro]

amigo mi tira uma duvida sobre esse balance o EthLB é entra ou saida do link, e essas regras são todas no NAT ou MANGLE pra pra especificar melhor agradeço .