Según manual.snort.org, los escaneos de puertos TCP van de una computadora a otra, pero cuando miras una alerta de escaneo de puertos TCP en snort/snorby puedes ver esto:
Por un lado: Fuente: 136.238.4.165 Dest: 10.19.0.5
Por otro lado: Recuento.de.prioridades:.5.Recuento.de.conexiones:.18.Recuento.IP:.1.Rango.IP.del.escáner:.10.10.28.88:136.238.78.44.Recuento.de.puertos/proto:.6.Rango.de.puertos/proto:.199:58891.
Entonces, en un lado tenemos los campos de origen y destino, que dicen que la máquina 10.19.0.5 fue escaneada desde 136.238.4.165. Por otro lado, Scanner IP Range dice que desde 10.10.28.88 a 136.238.78.44 se estaba escaneando a 10.19.0.5
¿Cómo debo entender esta información? ¿Qué dispositivo inició el escaneo?
Respuesta1
Creo que te estás obsesionando demasiado con la terminología de conexión TCP y cómo se relaciona con lo que Snort quiere decir con origen y destino.
Si bien Snort tiene la capacidad de conservar cierta información de estado para una inspección detallada (llamada flowbits), las firmas se procesan en paquetes individuales. Esto significa que el origen y el destino no se asignan al cliente y al servidor, sino que se asignan directamente a los campos de dirección de origen y destino en el encabezado IP. Eso significa que el paquete específico que provocó que se activara esta regla tenía 10.19.0.5 en el campo de dirección de destino y 136.238.4.165 en el campo de dirección de origen. Estamos hablando de un solo paquete aquí, no tiene nada que ver con quién inició la sesión.
También tenga en cuenta cómo funciona el preprocesador sfPortscan. Su algoritmo de detección realmente solo compara 3 patrones:
- Tráfico TCP/UDP donde un host habla con un host y llega a muchos puertos
- Tráfico TCP/UDP donde muchos hosts hablan con un host y llegan a muchos puertos
- Tráfico TCP/UDP/ICMP donde un host habla con muchos hosts en un solo puerto
En gran parte debido al número 3, esta alerta puede ser activada por casi cualquier sistema que realmente esté brindando un servicio. Por alguna razón, los servidores de archivos SMB de Windows parecen ser los peores infractores de falsos positivos. Esto hace que el preprocesador sfPortscan sea excepcionalmente ruidoso. De hecho, es tan ruidoso que, a menos que tenga una red muy restringida y tenga la experiencia para ajustar significativamente la salida, casi ni siquiera vale la pena habilitar este preprocesador.