pfSense e Snort: tráfego de portscan inesperado na interface

Question

Eu tenho uma caixa pfSense atuando como meu roteador voltado para o público e firewall com monitor de estado.

Há uma interface WAN e várias interfaces LAN usando IPs privados por trás do NAT.

ESPERO ver os scans de portas ou todos os tipos de coisas com o Snort na interface WAN.

Eu não espero ver este alerta SNORT em uma das interfaces LAN.

Attempted Information Leak
PSNG_UDP_PORTSCAN
SRC: 165.98.148.2  (some Nicaraguan IP)
DST: 192.168.5.15  (a linux file sever on the LAN)

Não tenho encaminhamento de porta para 192.168.5.15. Na verdade, nada na caixa pfSense deve ser encaminhamento / roteamento / NATing / PATing para esse endereço interno.

Eu poderia entender se minha máquina interna estava se comunicando com o ip da Nicarágua, mas como no mundo os datagramas UDP fazem isso da interface WAN para a interface LAN sem encaminhamento?

    

Answer 1

Então, há algumas coisas acontecendo aqui, o que, na minha opinião, está causando confusão.

Primeiro, o que Snort quer dizer por origem e destino. Embora o Snort tenha a capacidade de manter alguma informação de estado para inspeção stateful (chamada flowbits), as assinaturas são processadas contra pacotes individuais. Isso significa que a origem e o destino não são mapeados para o cliente e o servidor, eles são mapeados diretamente para os campos de endereço de origem e destino no cabeçalho IP. Isso significa que o pacote específico que causou essa regra foi disparado 192.168.5.15 no endereço de destino e 165.98.148.2 no endereço de origem. Estamos falando de um único pacote aqui, não tem nada a ver com quem iniciou a sessão.

Em segundo lugar, o seu dispositivo NAT está fazendo mais com o UDP do que você pensa. TCP é fácil. É um protocolo orientado por conexão. Todo o design é que você negocia uma sessão de comunicação, conversa por um tempo e depois se despede. Todo o processo é muito bem definido e os dispositivos NAT seguem esses padrões. Eles vêem seu SYN sair e adicionar uma entrada à tabela xlate, então a entrada xlate é deletada quando o FIN + ACK volta, ou um FIN + RST apaga, ou o tempo suficiente passa.

O UDP, sendo sem conexão, é apenas fogo e esquece. A ideia é que o aplicativo implemente seu próprio handshake e / ou sistema de retransmissão ou não precise deles. Então, você assumiria que o firewall permitiria que seu pacote UDP fosse excluído, mas qualquer resposta seria bloqueada. Exceto que isso não acontece. Seu dispositivo NAT sabe que até mesmo um protocolo sem conexão como o UDP frequentemente tem comunicação bidirecional. Como tal, irá inserir entradas xlate para o tráfego UDP de saída, da mesma forma que o TCP. As regras são um pouco diferentes, por exemplo, eu esperaria que as entradas dessem tempo em um intervalo diferente e fossem excluídas somente quando elas terminassem.

Em terceiro lugar, esse alerta é provavelmente acionado pelo pré-processador sfPortscan do Snort. Em um ambiente rigidamente restrito, posso ver que é bastante útil. Caso contrário, pode ser bastante barulhento. O problema está nos tipos de detecções que ele executa

1. Tráfego TCP / UDP em que um host fala com um host e atinge vários portes
2. Tráfego TCP / UDP em que muitos hosts conversam com um host e atingem muitas portas
3. Tráfego TCP / UDP / ICMP em que um host fala com muitos hosts em uma única porta

Em grande parte devido ao # 3, esse alerta pode ser acionado por praticamente qualquer sistema que esteja realmente fornecendo um serviço. Por alguma razão, os servidores de arquivos do Windows SMB parecem ser os piores transgressores de falsos positivos.

Agora aqui é onde as coisas se divertem. Vamos supor que as configurações (servidor, rede e firewall) sejam boas. Nesse caso, as chances são de que o servidor de arquivos iniciou as comunicações com o IP externo. Em seguida, a comunicação de retorno acionou o pré-processador sfPortscan, que fez com que o pfSense exibisse um alerta. Isso é provavelmente uma coisa ruim. Se eu fosse você eu iria começar uma captura de pacotes para qualquer coisa para / do seu servidor de arquivos e um endereço externo. Então você pode começar a rever as capturas de pacotes e tentar descobrir o que está acontecendo.

    

Answer 2

O UDP src / dest pode ser facilmente confundido com o Snort. Sem saber mais sobre o que é o tráfego, é difícil dizer. Essa regra de portas UDP pode falhar o tempo todo em tráfego VoIP, solicitações de DNS e outras coisas. Se você não tem nenhum encaminhamento de porta ou NAT 1: 1 para esse IP interno, então não é proveniente de tráfego do IP remoto, é do IP local.