TL; DR: ¿Qué significa "desajuste de protocolo" incluso, y cómo es una amenaza? ¿Puedo simplemente suprimirlo?
Estamos ocupados sintonizando Snort. La sección del preprocesador SSH tiene este aspecto, que proviene directamente de la configuración predeterminada de Snort.org:
preprocessor ssh: server_ports { 22 } \
autodetect \
max_client_bytes 19600 \
max_encrypted_packets 20 \
max_server_version_len 100 \
enable_respoverflow enable_ssh1crc32 \
enable_srvoverflow enable_protomismatch
Actualmente estamos viendo una gran cantidad de alertas sobre "[128: 4: 1] (spp_ssh) Discrepancia de protocolo"
Las alertas parecen ocurrir en "picos" donde habrá más de 1000 mensajes de alerta que indican este tipo de tráfico desde el host A al host B, en un período de tiempo relativamente corto. (Supongo que esa es la definición de "espiga" pero obtienes mi deriva). De todos modos, aquí hay un ejemplo de mensaje de alerta (esto es todo una línea: las nuevas líneas agregadas por la barra invertida fueron agregadas por mí para que sea más fácil de leer):
02/24-17:21:22.386376 [**] [128:4:1] (spp_ssh) \
Protocol mismatch [**] [Classification: Detection of a Non-Standard \
Protocol or Event] [Priority: 2] {TCP} \
10.99.1.44:58391 -> 10.99.1.88:22
Detalles
-
El servidor "10.99.1.44"
- Es un host de salto
- Solo las personas reales usarán eso para SSH al host ".88" de. es decir, no hay sesiones automáticas de SSH generadas desde el host ".44"
-
El servidor "10.99.1.88"
- está ejecutando Snort
- Aloja un servicio web que utilizan las personas conectadas a la VPN (es decir, a través de un navegador) y los servicios dentro del entorno de compilación (es decir, a través de solicitudes HTTP automáticas)
- Solo sirve las cosas más de 443 para servicios automatizados. es decir, no hay automatización basada en SSH que afecte al host ".88"
El pico de ejemplo de hoy sucedió mientras tenía SSH'ed al host 10.99.1.88 a través del host 10.99.1.44.
es decir, ssh - > 10.99.1.44 - > ssh - > 10.99.1.88
Necesitaba un shell en el host 88 para hacer un poco de mantenimiento.
Alrededor de ese tiempo Snort se asustó. Tuvimos alrededor de 1,300 mensajes idénticos a los que publiqué anteriormente.
- No había otros usuarios con SSH en ninguno de los cuadros en ese momento
- No había ninguna indicación en el registro del sistema de un trabajo cron en ejecución que pudiera haber estado usando SSH en cualquiera de los cuadros
Finalmente, tenemos este mensaje en gran abundancia en nuestro títere. Sin ninguna razón aparente, ya que la mayoría de las advertencias descritas anteriormente, es decir, SSH no se está utilizando activamente, también se aplican a esa casilla.
He explorado los Intergoogles y básicamente he encontrado dos soluciones:
- Elimine
autodetectde la stanza de configuración del preprocesador SSH - O añada reglas de supresión a threshold.conf
Lo puedo hacer cualquiera de las dos cosas, pero parece que ninguna de las dos es ideal, ya que ambas implican simplemente callar la cosa sin entender la causa raíz. No he podido reproducir este problema de forma activa, y no se me ha ocurrido ninguna idea sobre qué podría estar causando más que un error en el preprocesador SSH.