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: 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
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
- 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.
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
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
(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.)
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 .xml 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).
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.)