What is all this Zune comment spam about?

People running popular blogs are often targeted by comment spammers – this blog gets hit with at least 10,000 a year (and very useful for botnet research) – most of it is semi-literate drivel containing a link to some site being “promoted”. Idiots pay other idiots to do this because they believe it will increase their Google ranking. It doesn’t, but a fool and his money are soon parted and the comment spammers, although wasting everyone’s time, are at least receiving payment from the idiots of the second part.

But there’s a weird class of comment spam that’s been going for years which contains lucid, but repeated, “reviews” about something called a “Zune”. It turns out that this is a Microsoft MP3 player available in the USA. The spams contain a load of links, and I assume that the spammers are using proper English (well, American English) in an attempt to get around automated spam filters that can spot the broken language of the third-world spam gangs easily enough. But they do seem to concentrate on the Zune media player rather than other topics. Blocking them is easy: just block any comment with the word “Zune” in, as it doesn’t appear in normal English. Unless, of course, your blog is about media players available in the USA.

This really does beg the question: why are these spammers sicking to one subject with a readily identified filter signature? I’ve often wondered if they’re being paid by a Microsoft rival to ensure that the word “Zune” appears in every spam filter on the planet, thus ensuring that no “social media” exposure exists for the product. Or is this just a paranoid conspiracy theory?

An analysis of the sources shows that nearly all of this stuff is coming from dubious server hosting companies.  A dubious hosting company is one that doesn’t know/care what its customers are doing, as evidenced by continued abuse and lack of response to complaints. There’s one in Melbourne (Telstra!) responsible for quite a bit of it, and very many in South Korea plus a smattering in Europe, all of which are “one-time” so presumably they’re taking complains seriously even if they’re not vetting beforehand. It’s hard to be sure about the Koreans – there are a lot but there’s evidence they might be skipping from one hosting company to the other. Unusually for this kind of abuse there are very few in China and Eastern Europe, and only the odd DSL source. These people don’t seem to be making much use of botnets.

So, one wonders, what’s their game? Could it be they’re buying hosting space and appearing to behave themselves by posting reasonable-looking but irrelevant comments? Well any competent server operators could detect comment posting easily enough, but in the “cheap” end of the market they won’t have the time or even the minimal knowledge to do this.

I did wonder if they were using VPN endpoints for this, but as there’s no reverse-lookup in the vast majority of cases it’s unlikely to be any legitimate server.

Can’t get PuTTY and FreeBSD with OpenSSH to do a Certificate Login – Myths

Following yesterday’s post about issues getting “Server Refused Our Key” errors when trying to use PuTTY to log in to FreeBSD with a certificate, I thought I’d just lay to rest a few myths I’ve seen on various web sites where people have tried to explain how to do this. It’s easy to see how these myths develop – I’ve laboured for years under the misapprehension that I needed to do something or other when it was just a coincidence it had started working the first time the idea came to me. So here goes with a few of the myths. If you’re not getting this to work, it’s not for one of these reasons:

Myth: You need to specify 0600 permissions for the authorized_keys file (or the .ssh directory)

Simply not true. It may be a good idea to stop others from reading your keys, although they are “public” keys and won’t let anyone else in anyway (unless a they have a suitable cracking tool and a lot of processing power – and I mean a lot). Only your private key needs to be a secret. The only stipulation is that they must only writeable by the user – 0644 is okay, 0664 or 0666 isn’t.

But as I mentioned yesterday, you MUST ensure that your home directory is also not world-writable! You mustn’t have 0777 permissions! 0755 is okay, as is 0711. I’ve not seen this documented anyway, but it’s true for FreeBSD 7.0 to 9.0.

Myth: OpenSSH requires the authorized_keys file to be owned by the user trying to log in

Again no – it simply doesn’t. It has to be readable to that user (not just root) – this may be because it’s world readable or group readable for the user in question. It might as well be owned by root:wheel as long as it’s Other read bit is set.

Myth: If you’re using SSH2, you need a file called authorized_keys2

This might be true on some installations, but not current ones! I’ve no reason to believe that this file would even be considered, never mind required. The file used is defined in the /etc/ssh/sshd_config, and on current versions of FreeBSD (7.0-9.0) it’s definitely authorized_keys

Myth: You must generate the keys using the OpenSSH keygen utility on FreeBSD – puttygen doesn’t work

Well, there’s a bit of truth in this, but not much. Put simply, the format is different, but this only extends as far as the header and comment.

OpenSSH keys look like this:

ssh-rsa AAAAB3NzaC1y… very long line … sXi+fF noone@example.com

Please generate and paste your ad code here. If left empty, the ad location will be highlighted on your blog pages with a reminder to enter your code. Mid-Post

PuTTYGen Keys look like this:

---- BEGIN SSH2 PUBLIC KEY ----
Comment: "no one@example.com"
AAAAB3NzaC1y … long line, possibly with breaks … sXi+fF
---- END SSH2 PUBLIC KEY ----

You can convert one to the other using any text editor of your choice, as long as it handles long lines properly (like vi).

I can see there could be all sorts of fun and games if you simply cut/pasted these end ended up with extra line breaks, spaces or truncation – but the key data and its encoding is exactly the same, and that’s the bit that makes it work or not.

If you generate your key using OpenSSH tools you will need to load it into PuTTY Gen and write a Private .ppk key on your Windoze box. Or not. It’s just a text file and you could put the appropriate wrapper on it, but you might as well just use PuTTY Gen.

Myth: You need to edit /etc/ssh/sshd_conf to enable certificate login

No you don’t. The default values as shipped work just fine. Because the file consists of commented out lines of parameters with their default values, I suspect people though that some have been confused about whether the ‘#’ needed to be removed before the parameter came in to effect. They don’t – you only need to remove the comment if you want to change the default value. If you do remove the comment, but don’t edit the value, it’ll make no difference to anything.

What’s Real

In my experience, problems are almost always down to either directory permissions (see above) or errors transcribing public keys from one machine to another – and chaos and confusion caused by the abovementioned myths!

 

PuTTY, FreeBSD and SSH certificate logins

I’ve just gone crazy trying to figure out why PuTTY kept getting a “Server Refused Our Key” error when I tried to log in to a host using a certificate for the first time. Looking around the web, there are a lot of interesting theories about how to generate the certificates, and out of desperation I tried them all – nothing worked. So, for what it’s worth, here’s what does.

Generate your certificate on FreeBSD using the OpenSSH utility:

ssh-keygen -t rsa

With the default options this will create a couple of files in the .ssh directory within your home directory, and by default they’ll be called “id_rsa” and “id_rsa.pub”. In other words, if you’re user ID is fred the files will be in /usr/home/fred/.ssh/ with the above names. One’s private, the other is public.

You need to add the public key to the list of authorised keys in the .ssh directory:

cat id_rsa.pub >> ~/.ssh/authorized_keys

(The name authorized_keys with the American spelling is set in /etc/ssh/sshd_config)

Next you need to get the private key back to the machine running PuTTY. It’s just text – you can cut/paste it into a text editor and save it. For PuTTY to use it, however, it needs to be converted in to PuTTY’s own format, which you do using the PuTTY Key Generator, puttygen.exe. Run this, click on the Load button and read in your text file, then use the Save Private button to put write the .ppk file somewhere safe. You may wish to set a passphrase on it if there’s any chance someone else can get hold of it!

You may now get rid of the id_rsa.* files on the FreeBSD host, although you might want to add the public key to more than one user on more than one host – it’s a “public” key so there’s no harm in using it all over the place.

It is possible to use PuttyGen to make the keys and copy them to the FreeBSD host instead. A lot of people seem to have had trouble with this in the past (myself included), and it’s probably easier not to, especially if you’re going to use the keys in OpenSSH format for other purposes on the FreeBSD host anyway.

You’ll see a lot about setting the files in .ssh in some very restricted ways – basically all you need to do is ensure that they’re only writable by you. You can make your .ssh directory only readable by you if you wish but it won’t stop it from working. Also, the default /etc/ssh/sshd_config files is fine, and you don’t need to uncomment anything (in spite of what you might read). The default settings are all good, and all commented out, as it says on the top of the file.

Now, here’s the trick! What will cause a problem, as I eventually figured out, is if your home directory is writable by others. Don’t ask me how or why this should be true, but I tried this after I’d tried eliminating everything else on comparing working and non-working boxes. I know this for sure with FreeBSD 8.1 – ensure your home directory is drwxr-xr-x (or possibly less).

The final stage is to set up a session profile in PuTTY. This isn’t a tutorial for PuTTY, so I’ll be brief. In the options category open to Connection/Data and set the auto-login username you wish to use (if you haven’t already). Then under Connection/SSH/Auth select the private (.ppk) file you want to use. Remember, you can use this file with as many hosts and user accounts as you’ve added the public key to the .ssh/authorized_keys file. Save the session, and that’s it done. If it doesn’t do it for you, take a look in /var/log/auth.log.

Government’s red-herring email law

The government (UK) launched a red herring at the Internet today, and the news media has lapped it up. “We’re brining in a new law to allow security services to monitor email and other Internet traffic.” This is actually referring to the fact of the communication; not its content.

The TV news has subsequently been filled with earnest spokespersons from civil liberties groups decrying the worst Big Bother laws since New Labour got the boot – anything to get their silly mugs in front of a camera. Great news drama – the Conservatives moving over to the dark side.

Wake up people! What they’re proposing is just not possible. Blair already tried it in a fanfare of announcements and publicity, but anyone who knows anything about how email and the Internet function can tell you that it’s not even technically possible on so many levels.

1) Email does not necessarily use an ISP’s mail server or web mail service. Home users probably do; any company or organisation will most likely use their own. If anyone wanted to avoid snooping, they would too.

2) Users of commercial mail services are anonymous if they want to be. With a few minutes effort it’s possible to hide your IP address, or use an untraceable random one, and there’s no other trail leading back to an individual. The international criminals being targeted will know the tricks, for sure.

3) The security services already have the powers to do this, and do use them.

4) If the ISP is outside the UK, then what?

When the Blair government announced something similar I had to write to the government department concerned asking for the details. I heard about it from the general news. Apparently I, as an ISP, needed to keep records for a year – but records of what, exactly? They didn’t contact me to warn me it was happening; they can’t as there is no register of ISPs. There’s no definition of what counts as an ISP either. And needless to say, the government department concerned didn’t write back with the details.

So why is the current government making this announcement about an announcement now? Could they be wanting to change the news agenda? As usual they can rely on the media types to completely miss the fact it’s nonsense. Eventually the BBC got Andrew Mars on to comment, but I suspect his interview snippet was severely edited to suit their agenda.