Campo Snort, Portscans e Scanned IP Range

Question

De acordo com o manual.snort.org, o TCP Portscans vai de um computador para outro, mas quando você olha para um tcp portscan alert no snort / snorby você pode ver isto:

Em uma mão: Fonte: 136.238.4.165 Dest: 10.19.0.5

Por outro lado: Priority.Count: .5.Connection.Count: .18.IP.Count: .1. Scanner.IP.Range: .10.10.28.88: 136.238.78.44 .Port / Proto.Count :. 6. Port / Proto.Range: .199: 58891.

Então, em uma mão nós temos os campos source e dest, que dizem que a máquina 10.19.0.5 foi varrida de 136.238.4.165. Por outro lado, o intervalo de IP do scanner diz que, de 10.10.28.88 a 136.238.78.44, estava sendo varrido para 10.19.0.5

Como devo entender essa informação? Qual dispositivo iniciou a verificação?

    

Answer 1

Acho que você está ficando muito preso à terminologia da conexão TCP e como isso se relaciona com o que o 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 o disparo dessa regra tinha 10.19.0.5 no campo de endereço de destino e 136.238.4.165 no campo de endereço de origem. Estamos falando de um único pacote aqui, não tem nada a ver com quem iniciou a sessão.

Tenha também em mente como o pré-processador sfPortscan funciona. Seu algoritmo de detecção realmente verifica apenas três padrões:

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. Isso torna o pré-processador sfPortscan excepcionalmente barulhento. Na verdade, é tão barulhento que, a menos que você tenha uma rede bem restrita e tenha a experiência necessária para ajustar a saída de maneira significativa, quase nem vale a pena habilitar esse pré-processador.