TL; DR - Che cosa significa "mismatch del protocollo", anche, e in che modo si tratta di una minaccia? Posso semplicemente sopprimerlo?
Siamo impegnati a mettere a punto Snort. La sezione del preprocessore SSH assomiglia a questa, che proviene direttamente dalla configurazione predefinita di 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
Attualmente stiamo visualizzando un numero elevato di avvisi su "[128: 4: 1] (spp_ssh) Protocollo non corrispondente"
Gli avvisi sembrano accadere in "picchi" dove ci saranno più di 1000 messaggi di allarme che indicano questo tipo di traffico dall'host A all'host B, in un intervallo di tempo relativamente breve. (Immagino che sia la definizione di "spike" ma tu trovi la mia deriva). Ad ogni modo, ecco un messaggio di avviso di esempio (questa è tutta una riga - le righe new-backs sono state aggiunte da me per rendere più facile la lettura):
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
Dettagli
-
Il server "10.99.1.44"
- È un host di salto
- Solo le persone reali lo useranno mai su SSH dall'host ".88" di. non ci sono mai sessioni SSH automatiche mai generate dall'host ".44"
-
Il server "10.99.1.88"
- È in esecuzione Snort
- Ospita un servizio Web che viene utilizzato da persone connesse alla VPN (ad esempio tramite un browser) e dai servizi all'interno di un ambiente di generazione esterno (ad esempio tramite richieste HTTP automatizzate)
- Serve solo cose oltre 443 ai servizi automatizzati. Non esiste un'automazione basata su SSH che colpisca l'host ".88"
Il picco di esempio di oggi è successo mentre avevo SSH'ed sull'host 10.99.1.88 tramite l'host 10.99.1.44.
vale a dire. ssh - > 10.99.1.44 - > ssh - > 10.99.1.88
Avevo bisogno di una shell sull'88 host per fare manutenzione.
In quel periodo Snort era fuori di testa. Abbiamo circa 1300 messaggi identici a quello che ho postato sopra.
- Non c'erano altri utenti SSH in entrambi i casi
- Non c'era alcuna indicazione nel syslog di un cron job in esecuzione che avrebbe potuto utilizzare SSH su entrambe le caselle
Infine, abbiamo questo messaggio in grande abbondanza sul nostro burattinaio. Per nessuna ragione apparente, dal momento che la maggior parte delle avvertenze sopra descritte - cioè SSH non viene utilizzata attivamente - si applica anche a quella casella.
Ho sfogliato gli Intergoogles e fondamentalmente ho trovato due soluzioni:
- Rimuovi
autodetect
dalla stanza di configurazione del preprocessore SSH - OPPURE aggiungi regole di soppressione a threshold.conf
Posso fare entrambi, ma sembra che nessuno dei due sia l'ideale dal momento che entrambi implicano semplicemente chiudere la cosa senza capire la causa alla radice. Non sono stato in grado di riprodurre attivamente questo problema e non mi è venuta in mente alcuna idea su cosa potrebbe causarlo se non un errore nel preprocessore SSH.