Zaf’s Blog

So I’ve been playing with FreeNX, which is a free version of NoMachine‘s NX server. NoMachine’s NX Server is like VNC, RDP, and X11 all rolled into one. Essentially I can run an application on my home PC from anywhere in the world (just like VNC/Remote desktop, yes), but the bandwidth requirements are supposedly a lot lower. It also integrates into Linux a bit better than some distributions manage with VNC.

I’ve been trying it out tonight, and made a few observations.

• Its not as low bandwidth as we’d like to believe. Yes you can use it on Dialup, yes it is faster than RDP or VNC on dialup, but no, its not really usable on dialup unless you’ve just taken a downer.
• Security (at least of FreeNX) is interesting, I’ll note about it below.
• You can run it in two modes, traditional desktop mode where you get a whole desktop, (just like VNC), or in application mode where you run a single application, and the application displays on the client PC just like a native local program. This is the most promising mode for me, as you can obviously deploy linux applications to a Windows desktop, and the user wouldn’t even realise its a Linux app (except that of course, when you go to open/save a document, its on the remote server filesystem).
• There is no server process per se, nothing runs in the background. The clients use SSH to start the nxserver process which then starts their session.

Security

The protocol is implemented over SSH, this is, in my opinion, good. It means the encryption side of things is should be good. The problem is they distribute a fixed known private/public key with the setup. This means that a man-in-the-middle attack can see the initial part of the protocol exchange. This may not be too bad a thing, because the nxserver application then initiates a second SSH session, this time logging in as the desired user.

Now here is where I’m hoping they haven’t screwed up. I’m hoping the nxserver application running on the server sets up a tunnel between the client and the server, and lets the client initiate the SSH session to the server. If this is how its implemented, a man-in-the-middle can’t actually affect the VNC/X11/RDP session directly. However they may still be able to affect the control protocol. In order to figure out how dangerous this is, I’ll have to look carefully through the source.

Of course, if they have screwed up, the entire protocol is very vulnerable to man-in-the-middle. Fortunately from what I’ve established so far, this isn’t the case.

Installing

In my next post, I’ll have my instructions on setting up FreeNX on Ubuntu Feisty.

Well, I had a rather interesting experience recently. This wordpress install was compromised due to a security bug in the previous version I was using. This was the latest version that comes out with Ubuntu, but because this version comes from the Universe repository, the Ubuntu security team refused to release a patch to fix the bug, and the Ubuntu WordPress maintainer obviously wasn’t interested in releasing a new version.

So to all you Ubuntu users out there, be aware, Universe can and probably DOES contain remote exploitable software that can lead to root compromises.

I have upgraded this system to the latest from WordPress, and reminded myself to subscribe to the announcement list in hopes of getting info about possible new security problems. If it gets compromised again, I’ll have to uninstall it completely and find something else.

Addendum: Please note that the failure here was in me in not checking on each and every piece of software available for Ubuntu, and the Ubuntu WordPress maintainer for showing indifference to a known in-the-wild remote exploit for the software. I don’t blame WordPress for the compromise, because as a software developer, its difficult to write secure software (note: difficult, not impossible).

I’ve been playing with a VMWare image of Open-Xchange today. VMWare is a neat way to play with systems, especially ones as invasive as Open-Xchange.

But on to Open-Xchange, it’s a promising alternative to Microsoft Exchange. I’ve only had a chance to play with it a little bit, but it certainly feels nice to use.

My only concerns so far are:

• No LDAP integration. I feel this is a must these days. Very little of our systems do not authenticate back to the LDAP.
• No themes. It would be nice if we could theme the interface, but thats not a must by any means
• No Windows clients except web-based. Ok, there is the Outlook plugin, but thats not GPL. By now I would have hoped to see a real GPL/Open Source plugin for Outlook that actually worked.

Its certainly worth looking further into.

Apache2 + SSL + Client Cerificate Authenticate + Directory level + Uploading Large Files = Problem.

Ok, so I’ll explain… We have a company portal, which is secured using SSL Client Side Certificate authentication. This works very well. The portal is primarily a Wiki (MediaWiki actually), allowing a CMS of sorts. I tried to upload a PDF to the wiki, and got a strange error. Thinking it was a MediaWiki problem, I spent quite awhile looking through various forums.

In the end I found an error message in the apache logs for the portal:
request body exceeds maximum size for SSL buffer

This lead to the following bug report statement:

This does not work on directory level with large files, because we currently do
not buffer the request body on disk but only 128k at max in memory. Moving
SSLVerifyClient require to virtual host level will make it work (see also
PR12355)

So in the end, the problem was because I was using

• Apache
• With SSL
• With Client-Side Certificate Authentication
• With Directory based SSL rules

And I tried to upload a file bigger than 128kWhat an obscure bug.

The fix was to simply move the Authentication from the Location directive to the Virtual Server directive

So I’ve just finished Quarter Share, by Nathan Lowell. Its a rather happy tale of a young man, set in a universe where ships travel between systems hauling freight. I won’t do a full review of it, as I think the first book doesn’t really stand by itself well. I’m hoping the second book continues the great tale, and leads to the meat of the story.

Now I’m listening to the second part, Half Share.

The whole tale is worth a listen. Its very free.

So I tried upgrading two of our servers tonight from Ubuntu edgy to feisty.

I’m a seat-of-the-pants kinda guy, so I upgraded in-place, over a SSH connection. The only thing I did that was slightly sane was I firewalled off our webservices and email servers during the upgrade, that way if I broke anything, the big wide interweb wouldn’t see it broken (they’d just not be able to access the site at all).

Both upgrades were a partial failure. The firewall ran into major problems, I suspect with the init upgrade, init seemed to have run into a problem. The process was there (showing init –restart as its process name), but it didn’t reap any zombies. I had to hard restart the system (reboot -f) to get it to restart, but I’ll admit it came up cleanly. Well, Ubuntu’s side of things came up cleanly.

I found that I’ve modified the firewall quite a bit when it comes to routing an IPv6 stuff, and I was naughty and hadn’t saved all those settings into config files, boot scripts, etc.

This is actually a good thing, as I am planning to blog my entire IPv6 setup, which I feel is rather unique. So now I have a pretty good idea of what needs to be done to bring it up. I’m still tidying some loose ends, and may have found a kernel bug in the process (Dead loop on virtual device tun6to4, fix it urgently was logged by the kernel repeatedly for awhile).

The second server didn’t fair as well, but that was probably because I was logged in remotely. Maybe due to the v6 annoyances, I lost my SSH connection to the server, so I couldn’t continue the upgrade as it was. I was forced to use apt-get -f install, etc to get it back into a running state. There was also some funkyness with /tmp that I couldn’t explain, but after the reboot things were sane again.

I’m really not happy about having to reboot to fix things. Its not how its done in Linux. I’ll acknowledge that it could well be due to things like libc and kernel upgrades, but Debian does it much better. I can’t think of a single case where an upgrade has required a reboot before things are sane again. Yes, you have to restart processes, but not reboot. Oh, and yes, you have to reboot to install a new running kernel…. For now..

Hopefully I’ll get around to blogging the rest of my setup soonish.