Snort "Protocol mismatch" from SSH preprocessor

Question

TL;DR -- What does "protocol mismatch" even mean, and how is this a threat? Can I just suppress it?

We are busy tuning Snort. The SSH preprocessor section looks like this, which comes directly from the Snort.org default configuration:

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

Currently we are seeing a large number of alerts on "[128:4:1] (spp_ssh) Protocol mismatch"

The alerts seem to happen in "spikes" where there will be 1000+ alert messages indicating this sort of traffic from host A to host B, over a relatively short timeframe. (I guess that's the definition of "spike" but you get my drift). Anyway, here's an example alert message (this is all one line -- the backslashed-newlines were added by me to make this easier to read):

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

Details

• The "10.99.1.44" server

  • Is a jump host
  • Only actual persons will ever use that to SSH to the ".88" host from. i.e. there's no automated SSH sessions ever spawned from the ".44" host

• The "10.99.1.88" server

  • Is running Snort
  • Hosts a web service that is used by persons connected to the VPN (i.e. via a browser), and by services within out build environment (i.e. via automated HTTP requests)
  • Only serves things over 443 to automated services. i.e. There's no SSH-based automation that would hit the ".88" host

Today's example spike happened while I had SSH'ed to the 10.99.1.88 host via the 10.99.1.44 host.

i.e. ssh -> 10.99.1.44 -> ssh -> 10.99.1.88

I needed a shell on the 88 host to do some maintenance.

Around that time Snort freaked out. We had around 1,300 messages identical to the one I posted, above.

• There were no other users SSH'ed to either box at that time
• There was no indication in the syslog of a cron job running that might have been using SSH on either box

Finally, we have this message in great abundance on our puppetmaster. For no apparent reason, since most of the caveats described above -- i.e. SSH isn't being actively used -- apply to that box as well.

I've browsed the Intergoogles and basically come up with two solutions:

• Remove autodetect from the SSH preprocessor config stanza
• OR add suppression rules to threshold.conf

I can do either, but it seems like neither is ideal since they both involve just shutting the thing up without understanding the root cause. I haven't been able to actively reproduce this issue, and I haven't come up with any ideas as to what could be causing it other than maybe a bug in the SSH preprocessor.

Answer 1

The "protocol mismatch" error message happens when something connects to the SSH port on a client version it doesn't support, it can also be generated when something tries to hit SSH port that isn't an SSH client, e.g. a web browser. But that's not the issue you're describing.

I've seen this particular error message come up before, and a quick google search reveals (http://seclists.org/snort/2009/q4/534) that there was a bug in old snort versions causing false positives on the protocol mismatch.

Further to the link above, and also from my own experience -- the "protocol mismatch" snort alert isn't the most informative of a potential intrusion and there aren't many exploits associated with triggering it. So, like many pre-canned snort alerts, this particular one in your environment can be disregarded as "noise" and safely remove it in threshold.conf. This way, other alerts related to the ssh preprocessor will still be generated but that particular one will not generate noise.

Answer 2

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

openssh server yells this error when it is not able to read valid protocol version per specification.

It should happen when:

• SSH1 client connecting to an SSH2 server
• SSH2 client connecting to an SSH1 server
• A non-SSH client connecting to an SSH server.

There should be appropriate messages in syslog describing the source addresses. It might also be related to some recent update of server. Current openssh is strictly disabling protocol 1 version.

Source for the explanation (first link on google)

Can I just suppress it?

You can do that removing this option

enable_protomismatch

Source