Wandering Thoughts archives

2017-08-28

OpenSSH has an annoyingly misleading sshd error log message

Suppose that you are trying to get some form of SSH server authentication going that uses hostnames. This might be straightforward host-based authentication to enable root on a master machine to have access to subordinate machines, or it might be hostname-based Match statements to enable or disable some restrictions (as one other example where you can use hostnames). However, it's not working; when you try host-based authentication, for example, you get a log message on the target machine saying something like:

sshd[2540]: userauth_hostbased mismatch: client sends HOSTNAME, but we resolve 128.100.X.Y to 128.100.X.Y

This certainly looks like a straightforward problem where the target machine can't do reverse lookups to turn 128.100.X.Y into a hostname (or perhaps it can't do forward lookups to verify that hostname, although we might expect a slightly different error there). And in fact you can get this message logged when, for example, there is no DNS PTR record for 128.100.X.Y.

But there is another important case where you will get this message, and that is this message is also logged when OpenSSH sshd is not even trying to turn IPs into hostnames. To quote straight from sshd_config(5):

UseDNS
Specifies whether sshd(8) should look up the remote host name, and to check that the resolved host name for the remote IP address maps back to the very same IP address.

If this option is set to no (the default) then only addresses and not host names may be used in ~/.ssh/authorized_keys from and sshd_config Match Host directives.

The name UseDNS is somewhat misleading, because as the manual page correctly describes having this off turns off all forms of looking up the remote host name, not just DNS. For example, if you have backup entries in /etc/hosts, they're not checked either.

There's a bit of history that may catch you out here, which is that the OpenSSH default for UseDNS changed in the relatively recent past. According to the OpenSSH release notes, UseDNS defaulted to yes before OpenSSH 6.8; 6.8 changed the default to no when it was released in early 2015. March 2015 might seem like a long time ago, but Ubuntu 14.04, CentOS 7 (and CentOS 6), and Debian Jessie (the current 'oldstable') are all old enough that they have a pre-6.8 version of OpenSSH. This means that if, say, you moved from Ubuntu 14.04 to Ubuntu 16.04 and you use the stock sshd_config on both systems, you've had UseDNS's value change on you such that your 16.04 systems won't accept hostname-based authentication when your 14.04 systems do.

(FreeBSD 9.3 also has a pre 6.8 OpenSSH, in case you're running a machine that old.)

I can guess how this error message came about; I suspect that when UseDNS is off, the code simply skips trying to resolve the IP and basically acts as if the IP to name resolution failed. However the net effect of not differentiating the two cases is that sshd emits a misleading error message that can lead you on a significant wild goose chase as you try to figure out why OpenSSH is failing to turn your IP addresses into names. Life would probably be a lot simpler if OpenSSH logged a separate message to the effect of 'ignoring client-sent hostname and using only IP address X because UseDNS is off'.

(There's some question about when sshd should log this message. The ideal case would be that it would get logged as an error if UseDNS was off and sshd detected that you were trying to use hostname-based authentication or matching operators. This is definitely a real error that's worth reporting, because sshd knows that you're trying to do something that can never succeed.)

sysadmin/OpenSSHUseDNSErrorAnnoyance written at 22:49:44; Add Comment

The types of attachments we see for malware-laden email

These days we block some attachment types, but of course not all of them. We also use our commercial anti-spam package to detect and reject malware that isn't already rejected outright as a bad attachment type. This raises the obvious interesting question of what attachment types that malware comes in. Unfortunately I can't answer exactly that question from our logs, but I can see what attachment types we see in email that is rejected because it contains malware.

(This difference matters only if a malware email contains multiple attachments, possibly with multiple pieces of malware. When this happens, our commercial anti-spam system doesn't log information that would let us identify which particular attachment has the detected malware.)

In the past 19 days of logs, we rejected 440 messages because they were identified as containing malware. A few of these messages had attachments without MIME filenames; all of the attachments were detected as either Microsoft Word files or images (mostly PNGs with a couple of GIFs). The vast majority had MIME filenames, and the (claimed) extensions on these are as follows:

 241  .doc
  95  .jar
  52  .zip
  24  .html
   6  .htm
   6  .gz
   3  .7z .rar
   1  .z .xls .rev .psx .pdf

Most of the .zip files contained .doc files (26) or .jar files (12). Ten of the .zip files were actually given the MIME type application/msword (despite the .zip extension in their MIME filename) and contain the file extensions '.bin .png .rels[2] .xml[12] none'. Some Internet searches suggest that the .bin file extension here is the giveaway marker of Word macros being embedded in the file, and we certainly saw a bunch of .doc files that had .bin files inside them (it looks like 69 out of the 241 .doc files, so by no means all or even a majority but certainly a significant portion).

Out of the .doc files, the vast majority had some strain of what Sophos identifies as 'CXmail/OleDl'. A handful were Troj/DocDl or Troj/DocDrop. Out of the .jar files, almost all were identified by Sophos as CXmail/JarAd strains, some with 'Mal/DrodZp-A' added in; the remainder were basically all Java/Adwind (there was one that Sophos just labeled as 'Mal/Generic-S'). The .zip malware identifications were all over the map. The ZIPs that contained a .doc or a .jar unsurprisingly look like plain .docs or .jars; the remainder features Troj/DocDl, CXmail/JSDl, and a CXmail/PDFDoc. The HTML files appear to be a split between phish spam in attachments and 'CXmail/JSDl', which I suspect involves JavaScript embedded in that HTML.

Having gone through this stats gathering exercise, my overall view is that there's nothing terribly surprising here. Microsoft Word and Java/JARs are a big attack vector and HTML files appear to be a side door to sneak some attacks and phishing through where they might be blocked as an actual HTML email message.

(The obvious question to ask next is if our users get very many legitimate email messages that have Word files with embedded macros.)

spam/MalwareAttachmentTypes written at 01:27:33; Add Comment


Page tools: See As Normal.
Search:
Login: Password:
Atom Syndication: Recent Pages, Recent Comments.

This dinky wiki is brought to you by the Insane Hackers Guild, Python sub-branch.