Snort "Mancata corrispondenza del protocollo" dal preprocessore SSH

3

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.

    
posta JDS 24.02.2016 - 19:58
fonte

2 risposte

4

Il messaggio di errore "mancata corrispondenza del protocollo" si verifica quando qualcosa si connette alla porta SSH su una versione client che non supporta, può anche essere generato quando qualcosa tenta di colpire la porta SSH che non è un client SSH, ad es. un browser web. Ma non è questo il problema che stai descrivendo.

Ho visto questo particolare messaggio di errore comparire prima e una veloce ricerca su google rivela ( link ) che c'era un bug nelle vecchie versioni di snort che causava falsi positivi sulla mancata corrispondenza del protocollo.

Oltre al link qui sopra, e anche dalla mia esperienza personale, l'avviso di snort "non allineamento del protocollo" non è la più informativa di una potenziale intrusione e non ci sono molti exploit associati all'attivazione. Quindi, come molti avvisi di snort preconfezionati, questo particolare nel tuo ambiente può essere ignorato come "rumore" e rimuoverlo in sicurezza in threshold.conf. In questo modo, verranno comunque generati altri avvisi relativi al preprocessore ssh, ma quel particolare non genererà rumore.

    
risposta data 24.02.2016 - 20:49
fonte
2

What does "protocol mismatch" even mean, and how is this a threat?

Il server openssh urla questo errore quando non è in grado di leggere la versione del protocollo valida per specifica.

Dovrebbe accadere quando:

  • Il client SSH1 si connette a un server SSH2
  • Il client SSH2 si connette a un server SSH1
  • Un client non SSH che si connette a un server SSH.

Ci dovrebbero essere messaggi appropriati in syslog che descrivono gli indirizzi sorgente. Potrebbe anche essere correlato ad alcuni recenti aggiornamenti del server. Current openssh disabilita rigorosamente la versione 1 del protocollo.

Fonte per la spiegazione (primo collegamento su google)

Can I just suppress it?

Puoi farlo rimuovendo questa opzione

enable_protomismatch

Source

    
risposta data 24.02.2016 - 20:22
fonte

Leggi altre domande sui tag