Special Offers

Feature: Security

A keyhole for your system's back door

While a properly set up SSH service can give you secure remote access to a server, you might not like the idea of having an SSH server always running on your machine. Secure Back Door (SBD) can open an encrypted connection to your system, allowing you to remotely execute any operating system commands for example start your SSH or Web server or reboot the server.

SBD can listen on any port you like. If you don't specify a port it will default to port 31415. The transport protocol is SBD, which is based on a one-time pad symmetric key and a keyed-hash message authentication code (HMAC), which verify data integrity and the authenticity of a message. The client and server need to have the same key in order for system to accept remote commands. The keys are nothing but two identical files with randomly generated characters that you need to create only once and keep them secret.

Setup and usage

SBD's latest stable version 0.5 was released in February 2005 and is fully functional. Download the source code tarball, extract the package into /usr/local (for example), become root, and compile the binaries:

You need a C++ compiler and the above development libraries in order to successfully compile the binaries. See the README file inside the extracted folder to learn more about how to compile SBD and use it.

In order for client to successfully execute remote commands on the server machine, you need to create two identical files -- enckey.bits for the client, and deckey.bits for the server. You can create them by typing randomly chosen characters in an empty file and saving it as enckey.bits. Copy that file to deckey.bits and you're done. There are no file characters limits, but the more characters you have, the better.

There is another random character file in the directory named athkey.bits for the server, which is used for authenticating the client against basic IP spoofs. The characters in the files are only for test purposes and you need to change them with your own random generated characters, the same way as for enckey.bits and deckey.bits.

Once the server is all set, install or copy the SBD client binary and enckey.bits file to the client machine. You can try to run the already compiled sbd binary on the client or, if that fails, you can build the binary on the client.

You can now test the SBD server. To start the SBD server on port 12345, run the command ./sbdd 12345.

To start the SSH server from my remote client machine, run the command:

~$ ./sbd server.IP.address 12345 "/etc/init.d/ssh start"

replacing server.IP.address with the server's real address. If you did everything correctly, the client machine will display the notice:

Sent: 41 bytes

That cryptic message is the only indication of success you'll get from SBD, so to make sure the SSH service is really started on the server machine, check /var/log/syslog.

If you don't have identical security keys on client and server, you might see the following error:

If your SBD server is not running or you're trying to access it on a wrong port, you'll receive an error like this:

Error! Could not connect!

Using SBD, you can execute just about any command remotely, just as you would if you were logged on to the SBD server. By running SBD instead of, for instance, SSH, your vulnerable services won't always be exposed on the network. It's good practice to run services that you use rarely only when you really need to. Secure Back Door can help you worry less about your system's security.

I don't get it...

Replacing Eggs With Eggs

Posted by: Anonymous Coward
on May 08, 2007 02:12 AM

What prevents attacks that would be made on the SSH service, which probably would not result in an attacker gaining root access, being made on the SBD service, which grants the attacker root access immediately?

Other good intentioned comments not accurate

Posted by: Anonymous Coward
on May 08, 2007 03:07 AM

SBD was created in order so you wouldn't have to run SSH all the time which has a huge code base, and more prone to bugs.

The source code for SBD is very small and very simple to understand. It has been looked over by a few security experts as well. However, anyone with a general knowledge could see things are kosher in the code.

SBD is based on well known, fundamental algorithms. It is more secure than running ssh all the time.

Re:Other good intentioned comments not accurate

Posted by: Anonymous Coward
on May 08, 2007 03:28 AM

Eh?? It hasn't been updated since 2005. SSH has been thoroughly pounded in real life for years, and it is known who maintains and reviews it. Can't say that about SBD. Please name the security experts who reviewed and approved it.

No, it _was_ accurate. Easily found bugs:

Posted by: Administrator
on May 08, 2007 04:54 AM

The software has bugs (examples below) and I'm pretty sure it hasn't been reviewed a lot up to now. You, dear reader, should probably not use it. I.e. except for testing and demonstration in CS classes.

<tt>angryreader:~$ echo 'die!' | nc sbdrunninghost 31415</tt>

And you, poor reader and follower of this article, will have to phone your server hoster, since your only connection to your server is gone. (Segmentation fault. And if you're in testing mood, compile w/ "-g" and turn on that good ol' gdb, and if you're in hacking mood, go even further. No doubt there will be more holes...)

Also, it will run out of athkey.bits data after unsuccessful attempts to connect. Then, it would die right away, too.

I think this should warrant a mention in the article, so beginners don't make the mistake to run this software.

Lesson learned: Security by obscurity won't pay in the long run. And since I'm a nice guy, I just even wrote to sbd's author. But I wouldn't blame him, the guy who explicitly declared his experiment as experimental. I would instead blame the guy who suggested it for production use.

Re:A keyhole for your system's back door

Posted by: Anonymous Coward
on May 08, 2007 03:48 AM

Well, in order to use this in the way this article means, you would have to open your webmin interface to the world. It is password protected of course, but if you are paranoid enough not to allow SSH to run all the time, I would guess this would be unacceptable to you too.

Re:A keyhole for your system's back door

Posted by: Administrator
on May 08, 2007 04:08 AM

Yes, you are right BUT:
webmin is the ONLY service I run on my machine.
SSH, even my webserver is NOT running.
So, when I want to start SSH for a short time I log in onto my webmin page and start SSH manually for the period a need to do a SSH session (this is possible within webmin).
After that I shut down my SSH session immediately.
This is all possible with webmin.

I'm The Author

Posted by: Anonymous Coward
on May 08, 2007 07:24 AM

Wow, a storm! It is good though, you are all doing what you should be, when it comes to security, question every assumption, over and over again.

It is true, SBD should not be used for production use. My intention with SBD is to be able to run arbitrary commands, securely, without SSH. I think it is an appropriate application to have. Having only a very small program running that lets you do emergency commands is nice. Especially if said program is small enough to be analyzed completely.

SBD is an attempt at this. I am pretty sure the security methods it is based on are valid. However, the point made about running out of the athkey bits is a valid point. I still need to figure a good method for doing this.

I am also thankful for the person that found the bug in the code.

I will also take the advice of making SBD much more thoroughly documented in respect to it's security considerations.

In the end SBD is a work in progress. I hope someday it might be well tested and analyzed enough to really be useful, but until that time it should not be used in production use. For me there still are some good uses for it for private things, but it is definitely not meant to be widely used yet.

There is a program out there called Ostiary, which accomplishes mostly the same thing as SBD, but uses fixed messages/commands instead of allowing arbitrary commands.

I invite more criticism and comments on how to make SBD better though. Thanks for all those who have offered advice so far.

Your suggestion?

Re:I'm The Author

Posted by: Administrator
on May 08, 2007 12:59 PM

"I invite more criticism and comments on how to make SBD better though."

Here's some advice<nobr> <wbr></nobr>...1) Change the name to something that doesn't share an acronym with a certain smelly body odor left discreetly by your co-worker/assassin who had cabbage for lunch.2) Trash this piece of junk. Don't get me wrong, it is a good project for academic/learning reasons<nobr> <wbr></nobr>... but it will never/should never be used in real world.

Re:I'm not the author, but ...

Posted by: Anonymous Coward
on May 08, 2007 06:52 PM

Hey calm down guys, the man just said, its for personal use not production.If every hobbyists personal code need to be scrapped we would never get nowhere.Its obvious that this is not a competitor at all for OpenSSH, now i dont even know if the code authour is the same person which posted this which no doubt will make it a bit less naive and cute.

Btw a earlier article showed one of the easy ways to restict brute force attacks on SSH.I trust OpenSSH just about more than any other daemon but i still wont have it listening on my systems unless its needed.

Re:A keyhole for your system's back door

Re:A keyhole for your system's back door

Posted by: Anonymous Coward
on May 09, 2007 04:00 AM

open-ssh is small, simple and incredibly well-tested at this point. Lock out root and only allow the user you need to log in and it is about as secure as you are going to get. It is written, maintained and poured over constantly by OpenBSD security nazis.

Webmin is a great piece of code, and I use it all the time and love it deeply, but I turn it off between uses and go through ssh to manually enable it when I need it.

If you are going to trust one of these two things, openssh, properly configured, is the one to trust.

Re:A keyhole for your system's back door

Posted by: Administrator
on May 09, 2007 04:22 AM

Thanks for your explanation.
Till now I have no solution for the brute force attacks on my SSH port. Yes, I know you can choose an alternative port, but still.
A hacker can very easy write a script which brute force tries all the login possibilities on the SSH service. Even if it does not find your password, then the cpu usage on the server is trashed badly by this hack attempt. What I am missing in ssh is an authentication method like webmin, which can BLOCK the ipadres of the attacker after a adjustable number of faulty login tries... Maybe this is also possible with ssh, but really I do not know how.
Anyone does?
Thanks in advance

Re:A keyhole for your system's back door

Posted by: Anonymous Coward
on May 09, 2007 04:52 AM

fail2ban and daemonshield both help you by monitoring login attempts and using iptables to ban IP's that are trying to brute force your ssh. There are quite a few scripts and programs that do this out there. Putting something like 'stopping ssh brute force attacks' into google will show you a lot of different discussions and programs dealing with this. Good luck.

Again, in addition to this, only enable a single user to log in to ssh and disable root logins. Won't help with your cpu usage, but will help with your security. You wanna get froggie, disable passwords entirely, but for a lot of us that isn't feasible.

Re:A keyhole for your system's back door

Dumb

Posted by: Anonymous Coward
on May 09, 2007 09:33 AM

Wow, the articles about ssh replacements/addons are getting dumber and dumber here. It's good to see that the readers aren't taking it seriously but this leads me to wonder the people who think this is good stuff are given the podium.

Re:Dumb

Posted by: Anonymous Coward
on May 09, 2007 02:50 PM

I couldn't agree more. People can obviously write whatever software they want, but it is equally obvious that the SSH refinements published here on a regular basis are at best redundant reinventions, at worst worthless pieces of software from people presumably trying to cut off a bit from the fame pie.

Re:A keyhole for your system's back door

Posted by: Anonymous Coward
on May 13, 2007 06:52 PM

You might want to google for 'iptables recent ssh'. Basically you can use the recent-module of netfilter and limit the number of times someone opens a connection to a port (ie 22). Thus problem of brute-force solved.

also webmin is known to be one of the more insecure applications out there it was (or was considered) removed from GLSA (Gentoo Linux Security Advisory) due to the large number of flaws reported for it in one year.

This article is not good advice

Posted by: Administrator
on May 08, 2007 03:03 AM

It mentions by no means that according to the code's documentation, it is a test release only. The code has sometimes funny spelling and wasn't obviously touched for a long time. In fact, this article might create incentive for the first external code review. I've not found any indication that the code was ever carefully reviewed.

It doesn't even explain the OTP mechanism in use (your {enc,dec}key.bits file will shrink by 20 bytes plus length of the command line you're passing it.

It doesn't even make security considerations despite being categorized as being "security" related.

It doesn't explain how this does improve security by any means.

It doesn't discuss pam_opie, which should be way more tested and integrates well with OpenSSH (using PAM).

i dont like this

Posted by: Administrator
on May 08, 2007 02:23 AM

you're replacing the tried-and-true security of SSH with just something else, which is most likely less secure. the only added security i see is the kinda-randomized port number. might as well just put SSH on a different port.

and plus, now you have to guard that enckey.bits file on the client as much as you would guard the root password of the server.