3

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.

  • 1
    Digging further I find that most of the enabled ssh preprocessor rules -- such as the "protocol mismatch" one -- are for old, old, ancient CVEs (i.e. ca 2000, 2001, 2002) that affect SSH v1 and/or Cisco routers that are I'm sure all patched by now, and if they aren't, I'm pretty sure you are well aware of this problem and have taken other steps to mitigate. At this point I have a big WTF about Snort -- why does the default config come so noisy, with processor rules that sniff for super old exploits? <cynicism>Is it really just to make money off configuration</cynicism>? – JDS Feb 25 '16 at 2:26
  • Also, I apologize for a "ranty" post, but it has indeed been a frustrating past 2 weeks tuning Snort. – JDS Feb 25 '16 at 2:26
4

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.

  • @JDS I think you meant to reply to my answer but replied to Jakuje's... one SSH session might spawn 1300 alerts because during the session, many many packets are generated....even during the key exchange, so it alerts on each. – Herringbone Cat Feb 24 '16 at 19:52
  • Thanks. This is basically what I was leaning towards. However, it leaves a very bad taste in my mouth, as I am just basically buying a louder radio to drown out the noise from my engine. Seems like I should find out what's actually causing that noise, and then buy the louder radio. Any ideas how I can tell what's actually causing that noise? Why would Snort alert on SSH-y events when SSH isn't even being used during that time? i.e. What am I missing? – JDS Feb 24 '16 at 19:56
  • 2
    @JDS In this case I'll digress from a purely technical answer and give you a real-world one: Snort is noisy. Snort, when deployed with default rules on most networks with decent traffic, creates an awful lot of false positives like this one. It generally requires a lot of work to configure to get meaningful information. This is why SourceFire (now owned by Cisco) exists..they charged $20K+ to implement Snort with their nice GUI and filtering custom for your network to remove these false positives. – Herringbone Cat Feb 24 '16 at 20:00
  • unrelated: Sourcefire is actually located just a few miles from me; in 2005 I was offered a job there (as a web dev, not a security guru) but declined (commute was too far). too bad, i probly couldda made good on the IPO – JDS Feb 24 '16 at 20:53
1

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

  • Thanks for replying! I read that seclist link before I posted here. The link doesn't make any sense with respect to our Snort reporting this error, because every box in our env is an Ubuntu 14.04 box with SSH updated to the same version. I looked in syslog and there is nothing; however in auth.log there is one indicator which is a line stating that I successfully SSH'ed in at that time. But why would one SSH session spawn 1300 Snort alerts? – JDS Feb 24 '16 at 19:50
  • If you don't have any logs, then it is more like fortune telling. If it yells about every packet, then it does not make much sense. BTW how do you implement the jumpbox? It might be the issue? – Jakuje Feb 24 '16 at 20:02
  • I DO have logs, it is just that there was no correlating event in the syslog. Ubuntu doesn't put SSH auth events in syslog anyway, it puts them in auth.log, which I mentioned. Is there something I should change in my syslog config that captures SSH events? – JDS Feb 24 '16 at 20:52
  • I don't mean your successful authentication log (auth.log is also handled by syslog). I mean the real reason why your Snort yells. Openssh should log these bads regardless configuration. Last thing would be catching packets in tcpdump or something. – Jakuje Feb 24 '16 at 21:02
  • 1
    Nope, there are zero "Bad protocol" errors in any logs anywhere, except the Snort "Protocol mismatch" errors. But that seems legit -- the version of OpenSSH is the same everywhere in our env. The only thing that seems bogus here is Snort's noisiness. Thanks – JDS Feb 24 '16 at 21:27

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.