Abrir a porta 1022 no PfSense com 2links/interfaces em balanceamento

[sparknex]

Gente,

 

Eu estou aqui já sem ideia e sem saber onde estou errando.

 

Contexto:

Uma empresa terceira dispara todo dia uma rotina de backup de dois 2 IPs externos a rede da empresa de onde trabalho pela porta 1022, com destino a um servidor dentro da minha rede. No servidor interno que é feito o backup, configuraram um DDNS.

 

A rotina estava funcionando normalmente com a seguinte infraestrutura da rede: Servidor externo do backup nuvem >> load balance (onde recebemos 2 links de internet de 2 provedores) >> appliance pfsense >> LAN

 

Mas para implementar um servico de VPN no pfsense e permitir acesso remoto a nossa rede, mudei a infra e retirei o LoadBalance da borda e agora o PFsense que está na borda recebendo os 2 links de internet. O servico de VPN está ok, a LAN está acessando a internet normalmente mas o que não esta estabelecendo conexão é a rotina de backup nuvem.

 

Já criei várias regras de NAT (Encaminhamento de portas e de Saída) e regras nas interfaces e usando o site https://www.invertexto.com/teste-de-portas, estou testando para ver se 1º- a porta está aberta para qualquer IP e dps 2º- liberar a porta somente para os 2 IPs que disparam o backup.

 

Vou mandar abaixo os prints das regras que criei e sem sucesso:

 

1- Roteamento/Gateways

Os 2 links que recebo dos provedores são PPPoE. Configurei um grupo de gateway para fazer o balanceamento entre os 2 links.

Estou usando a interface WAN_SOFTBAHIA como primaria.

 

2-NAT/Encaminhamento de portas

Fiz um encaminhamento de porta somente através da interface WAN_SOFBAHIA (enquanto escrevia esse tópico criei a mesma regra pra interface WAN_JUNIORNET para testar e tb sem êxito) para qualquer IP pela porta 1022 encaminhar pro meu servidor interno pela mesma porta (IP NAT e Porta NAT no anexo)

 

3-Firewall/Regras/ WAN_Provedor1 e WAN_Provedor2

Nas 2 interfaces criei uma regra para liberar qualquer comunicação IPv4 TCP/UPD pela porta 1022 de qualquer IP para qualquer IP pela porta 1022

 

4-NAT/Saída

Alterei o NAT de Saída para híbrido e criei regras conforme imagens.

 

Mesmo com essas regras não estou conseguindo habilitar a porta. Agradeço se puderem me dar uma luz, pois ja estou sem ideia  

[Linio Alan]

Excelente documentação e detalhamento do cenário mas para mitigar o problema de falha na conexão do servidor na rotina de backup é preciso realizar a captura de pacotes tanto lá no servidor quanto após o seu pFsense que está realizando o balanceamento dos links, o teste de captura de pacotes ou famoso tcpdump serve pra confirmar como o tráfego está ocorrendo, se por fora ou por dentro da VPN, qual IP que chega no cabeçalho do pacote , tanto na ida quanto na volta do mesmo pacote, isso é um troubleshooting relativamente complexo e que demanda 100% de hands-on, o teste de tcpdump é apenas uma das etapas de troubleshooting, para enfim saber quais ajustes na sua rede interna deverão ocorrer, se a supressão ou mudança de alguma regra NAT ou rota IP ou o que for necessário.

 

Ferramentas: tcpdump ou Wireshark ou o outra ferramenta que for mais familiar para você.

[sparknex]

Pessoal, eu consegui resolver ! O problema estava 1- Nas regras LAN havia 1 regra que já liberava qualquer comunicação mas eu criei uma regra especifica na LAN para o caso em questão e essas regras estavam entrando em conflito. Deixei somente a regra que liberava qualquer comunicação dentro da LAN. 2- No site https://www.invertexto.com/teste-de-portas, a porta de origem é aleatória e não exatamente a porta de destino que desejamos ver se esta aberta. E como as regras que eu estava criando estavam especificando a porta de origem estava dando errado..

 

Identificado o problema e resolvido a questão eu fui fazendo uma limpa/excluindo as regras que eu havia criado e não estavam ajudando. Como por exemplo as regras NAT de Saída do modo hibrido que eu havia criado.

[Linio Alan]

A vantagem de especificar portas na origem da conexão e não deixar aberto estilo UPnP é a segurança, em caso de comprometimento de algum dos hosts na sua rede LAN, não vai necessariamente barrar o scan malicioso mas vai atrasá-lo e, eventualmente até te permite estabelecer regras mais rígidas de conexão com autenticação na origem, porém a aplicação que abre a sessão com o servidor destino precisa ter especificada a porta que o seu firewall está permitindo a saída.

 

Em segurança porém, o "custo-benefício" sempre será a melhor métrica de sucesso, não se trata de frouxidão nas regras mas na aplicabilidade das melhores práticas que permita o negócio existir dentro de um framework de segurança para a realidade em questão.

[sparknex]

37 minutos atrás, Linio Alan disse:

A vantagem de especificar portas na origem da conexão e não deixar aberto estilo UPnP é a segurança, em caso de comprometimento de algum dos hosts na sua rede LAN, não vai necessariamente barrar o scan malicioso mas vai atrasá-lo e, eventualmente até te permite estabelecer regras mais rígidas de conexão com autenticação na origem, porém a aplicação que abre a sessão com o servidor destino precisa ter especificada a porta que o seu firewall está permitindo a saída.

 

Em segurança porém, o "custo-benefício" sempre será a melhor métrica de sucesso, não se trata de frouxidão nas regras mas na aplicabilidade das melhores práticas que permita o negócio existir dentro de um framework de segurança para a realidade em questão.

 

Isso, no caso só pra esclarecer: 1- no teste de porta pelo site invertexto, a porta de origem deles é aleatória. Depois que entendi isso e vi que estava aberta a porta, 2- eu ajustei a regra para aceitar somente conexão do servidor do backup nuvem pela porta 1022 em vez de deixar qualquer porta e de qualquer ip vindo de fora. 

 

Sobre a regra na LAN permitindo todas as conexões e sobre o UPnP agradeço o feedback, vou dar atenção/revisar isso. Agora que já entendi a raiz do problema, consigo criar regras mais especificas de segurança sem perder a conexão com o servidor externo do backup nuvem.

[Linio Alan]

Essa configuração permitindo conexões externas estar alinhada especificamente para o IP do servidor é mandatório, você fez bem!

 

A proteção também se complementa fazendo o servidor aceitar conexões apenas da sua rede, no caso dos IPs da sua LAN/WAN, provavelmente está ocorrendo por fora da sua VPN certo pela sua menção ao DDNS, então os IPs dos provedor também são IPs públicos mas dinâmicos, então seria interessante fechar a VPN para transmitir também o backup, deixaria o servidor, a transmissão em si dos backups e a sua rede LAN mais seguros de ataques externos.

 

Claro que o WAF e firewall da VM na cloud já mitigam bastante essa questão, porém como o backup muitas das vezes É o bem mais valioso em termos gerais, será muito bem-vinda esse "hardening" com mais essa camada de proteção: transmissão do backup pela VPN.