[Anterior: Tradução do Endereço de Rede (NAT)] [Conteúdo] [Próximo: Atalhos na Criação de Conjuntos de Regras]

PF: Redirecionamento ("Port Forwarding")

Conteúdo

• Introdução
• Redirecionamento e Filtragem de Pacotes
• Implicações de Segurança
• Redirecionamento e Reflexão
  • DNS "Split-Horizon"
  • Mover o Servidor Para uma Rede Local Separada
  • Proxy TCP
  • Combinação de RDR-TO e NAT-TO

Introdução

Vejamos um exemplo:

pass in on tl0 proto tcp from any to any port 80 rdr-to 192.168.1.20

Essa linha redireciona o tráfego TCP na porta 80 (servidor Web) para uma máquina na rede com o endereço 192.168.1.20. Portanto, mesmo que 192.168.1.20 esteja atrás do gateway dentro da rede, ela se torna acessível ao mundo externo.

A parte from any to any da linha rdr acima pode ser muito útil. Se você souber quais endereços ou sub-redes devem ter acesso ao servidor na porta 80, pode restringi-los assim:

pass in on tl0 proto tcp from 27.146.49.0/24 to any port 80 \
   rdr-to 192.168.1.20

Isso redireciona somente a sub-rede especificada. Perceba que isso implica que você pode redirecionar diferentes máquinas para máquinas diferentes atrás do gateway. Isso pode ser muito útil. Por exemplo, você pode fazer com que usuários em lugares remotos acessem seus próprios computadores desktop usando a mesma porta e o mesmo endereço IP no gateway desde que você saiba de que endereço IP eles se conectarão:

pass in on tl0 proto tcp from 27.146.49.14 to any port 80 \
   rdr-to 192.168.1.20
pass in on tl0 proto tcp from 16.114.4.89 to any port 80 \
   rdr-to 192.168.1.22
pass in on tl0 proto tcp from 24.2.74.178 to any port 80 \
   rdr-to 192.168.1.23

Uma faixa de portas também pode ser redirecionada dentro da mesma regra:

pass in on tl0 proto tcp from any to any port 5000:5500 \
   rdr-to 192.168.1.20
pass in on tl0 proto tcp from any to any port 5000:5500 \
   rdr-to 192.168.1.20 port 6000
pass in on tl0 proto tcp from any to any port 5000:5500 \
   rdr-to 192.168.1.20 port 7000:*

Esses exemplos mostram portas entre 5000 a 5500 (faixa inclusiva) sendo redirecionadas para 192.168.1.20. Na primeira regra, a porta 5000 é redirecionada para 5000, 5001 para 5001, etc. Na segunda regra, toda a faixa de portas é redirecionada para a porta 6000. E, na última regra, a porta 5000 é redirecionada para 7000, 5001 para 7001, etc.

Implicações de Segurança

Esses riscos podem ser minimizados mantendo-se os sistemas acessados externamente confinados numa rede separada. Essa rede é geralmente chamada de Zona Desmilitarizada (DMZ - "Demilitarized Zone") ou Rede de Serviços Privada (PSN - "Private Service Network"). Dessa forma, caso o servidor Web seja comprometido, os efeitos podem ser limitados à rede DMZ/PSN pela filtragem cuidadosa do tráfego que terá permissão de entrar e sair da rede DMZ/PSN.

Redirecionamento e Reflexão

server = 192.168.1.40

pass in on $ext_if proto tcp from any to $ext_if port 80 \
   rdr-to $server port 80

Mas quando a regra de redirecionamento é testada por um cliente na LAN, ela não funciona. O motivo é que as regras de redirecionamento se aplicam apenas a pacotes que passam pela interface especificada (no exemplo, a interface externa $ext_if). Conectar-se ao endereço externo do firewall a partir de uma máquina na LAN, contudo, não significa que os pacotes passarão por sua interface externa. A pilha TCP/IP no firewall compara o endereço de destino do pacote chegando com seus próprios endereços e apelidos e detecta conexões para ela mesma tão logo que tenham passado pela interface interna. Esses pacotes não passam fisicamente pela interface externa, e a pilha TCP/IP não simula essa passagem de forma alguma. Portanto, o PF nunca vê esses pacotes na interface externa, e a regra de redirecionamento, especificando a interface externa, não se aplica.

Adicionar uma segunda regra de redirecionamento para a interface interna também não produz o efeito desejado. Quando um cliente local conecta-se ao endereço externo do firewall, o pacote inicial do handshake TCP atinge o firewall pela interface interna. A regra de redirecionamento é aplicada e o endereço de destino é substituído pelo do servidor interno. O pacote é transferido de volta pela interface interna e chega ao servidor interno. Mas o endereço de origem no pacote não foi traduzido, e ainda contém o endereço do cliente local, portanto o servidor envia suas respostas diretamente ao cliente. O firewall nunca vê as respostas, ficando sem chance de reverter a tradução apropriadamente. O cliente então recebe respostas de um endereço IP de onde ele nunca esperava, e por isso descarta os pacotes. O handshake TCP falha e nenhuma conexão pode ser estabelecida.

Mas ainda assim, geralmente é necessário que os clientes na LAN se conectem ao servidor interno da mesma forma que os clientes externos, e que o façam de maneira transparente. Existem várias soluções para esse problema:

DNS "Split-Horizon"

É possível configurar servidores DNS para responder às pesquisas de clientes locais de maneira diferente das pesquisas externas, de forma que clientes locais receberão o endereço interno do servidor durante a resolução de nomes. Eles, portanto, se conectam diretamente ao servidor local, e o firewall não tem envolvimento. Isso reduz o tráfego local, já que os pacotes não precisam passar pelo firewall.

Mover o Servidor Para uma Rede Local Separada

Acrescentar mais uma interface de rede ao firewall e mover o servidor local da rede cliente para uma rede dedicada (DMZ) permite o redirecionamento de conexões dos clientes locais da mesma maneira que o redirecionamento de conexões externas. O uso de redes separadas traz diversas vantagens, incluindo melhora na segurança devido ao isolamento do servidor das máquinas locais restantes. Caso o servidor (que em nosso caso é acessível pela Internet) seja comprometido, ele não terá acesso direto às máquinas locais porque todas as conexões devem agora passar pelo firewall.

Proxy TCP

Um proxy TCP genérico pode ser configurado no firewall, escutando na porta a ser redirecionada ou recebendo conexões redirecionadas na interface interna para a porta onde ele esteja escutando. Quando um cliente local se conecta ao firewall, o proxy aceita a conexão, estabelece uma segunda conexão com o servidor interno e transfere dados entre as duas conexões.

Proxies simples podem ser criados usando-se inetd(8) e nc(1). A entrada no /etc/inetd.conf a seguir cria um soquete que escuta no endereço de loopback (127.0.0.1) na porta 5000. As conexões são encaminhadas ao servidor 192.168.1.10 na porta 80. O redirecionamento é feito pelo usuário "proxy".

127.0.0.1:5000 stream tcp nowait proxy /usr/bin/nc nc -w \
   20 192.168.1.10 80

A regra de redirecionamento a seguir transfere conexões na porta 80, na interface interna, para o proxy:

pass in on $int_if proto tcp from $int_net to $ext_if port 80 \
   rdr-to 127.0.0.1 port 5000

Combinação de RDR-TO e NAT-TO

Com uma regra NAT adicional na interface interna, a tradução de endereço que estava faltando no cenário acima pode ser remediada.

pass in on $int_if proto tcp from $int_net to $ext_if port 80 \
   rdr-to $server
pass out on $int_if proto tcp to $server port 80 \
   received-on $int_if nat-to $int_if

Isso faz com que o pacote inicial do cliente seja traduzido novamente quando retornar através da interface interna, substituindo o endereço de origem do cliente pelo endereço interno do firewall. O servidor interno responde para o firewall, que pode então reverter ambas as regras de tradução NAT e RDR ao transferir o pacote para o cliente. Essa construção é um tanto complexa, pois cria dois estados separados para cada conexão refletida. Deve-se tomar muito cuidado para evitar que a regra NAT atinja outro tráfego; por exemplo, conexões originadas de máquinas externas (através de outros redirecionamentos) ou do próprio firewall. Perceba que a regra rdr-to acima faz com que a pilha TCP/IP receba pacotes na interface interna com um endereço de destino dentro da rede interna.

[Anterior: Tradução do Endereço de Rede (NAT)] [Conteúdo] [Próximo: Atalhos na Criação de Conjuntos de Regras]