☰

Campo Snort, Portscans e intervalo de IP digitalizado

tag-icon • tag-icon log-files snort port-scanning
Campo Snort, Portscans e intervalo de IP digitalizado

De acordo com manual.snort.org, TCP Portscans vai de um computador para outro, mas quando você dá uma olhada em um alerta tcp portscan no snort/snorby você pode ver isto:

Por um lado: Fonte: 136.238.4.165 Dest: 10.19.0.5

Por outro lado: Priority.Count:.5.Connection.Count:.18.IP.Count:.1.Faixa.IP.do scanner:.10.10.28.88:136.238.78.44.Contagem.de.portas/proto.:.6.Intervalo.de.portas/proto.:.199:58891.

Então, por um lado temos os campos origem e destino, que dizem que a máquina 10.19.0.5 foi digitalizada a partir de 136.238.4.165. Por outro lado, o Scanner IP Range diz que de 10.10.28.88 a 136.238.78.44 estava digitalizando para 10.19.0.5

Como devo entender essas informações? Qual dispositivo iniciou a verificação?

Responder1

Acho que você está ficando muito preso à terminologia da conexão TCP e como isso se relaciona com o que o Snort entende por origem e destino.

Embora o Snort tenha a capacidade de manter algumas informações de estado para inspeção de estado (chamadas flowbits), as assinaturas são processadas em pacotes individuais. Isso significa que a origem e o destino não são mapeados para o cliente e o servidor, mas sim 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 desta 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.

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

  1. Tráfego TCP/UDP onde um host se comunica com um host e acessa muitas portas
  2. Tráfego TCP/UDP onde muitos hosts se comunicam com um host e atingem muitas portas
  3. Tráfego TCP/UDP/ICMP onde um host se comunica com muitos hosts em uma única porta

Em grande parte por causa do número 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 SMB do Windows parecem ser os piores infratores para falsos positivos. Isso torna o pré-processador sfPortscan excepcionalmente barulhento. Na verdade, é tão barulhento que, a menos que você tenha uma rede totalmente restrita e tenha experiência para ajustar significativamente a saída, quase nem vale a pena ativar esse pré-processador.

informação relacionada