For some reason I tend to forget something in my home office that I just need now. The information I need is sitting somewhere on the server, which is idling away at home, being of not much use to me at the moment. But once there is a network connection to the server there is a cure for this calamity, called sshfs, the secure shell file system.

Using the secure shell file system to lay your hands on data that is stored remotely has one distinct advantage that sets it apart from many other methods, it restricts access to the person that knows the key while the data is mounted on the local computer.

Normally any remote data source is mounted on the local computer as part of the universal file system, and while file permissions may restrict access for certain users, the superuser (root) is always able to access the data mounted somewhere, no matter which access method is used to transfer the data to the local system. Well yes, unless the data is encrypted with a user's public key and mounted on a sshfs. Now even the superuser cannot read the data mounted, making this method particularly interesting for all situations in which private data is used on a system heavily in use by many other people as well. Unlike normal network filesystems like NFS or CIFS that are mounted by a system process during bootup the sshfs is mounted by ordinary users, thanks to the FUSE kernel module.

FUSE is just another userspace program used to provide files under a certain directory that serves as a mount point. This in fact gives any user the opportunity to mount and unmount whole filesystems into his or her home directory at leisure, and whats most important, it provides a means to bring a secure tunnel to another network-enabled computer (at home or in the office) into play which radically changes the picture.

Preparations

Of course you have to prepare the server you intend to access for this scenario, but the necessary steps are pretty much straightforward. Naturally, using sshfs would require to create a cryptographic key pair (public key and secret key) and to store the public key on the server in the appropriate place:



Joe's new key pair has now been created. Make sure that you have your secret key (/home/joe/.ssh/id_rsa) at hand when you need to access your server's data.

cp /home/joe/.ssh/id_rsa.pub /home/joe/.ssh/authorized_keys

Of course, this has to be done on the server in order to permit the use of Joe's secret key.

Once Joe knows his server's IP address he is ready to mount his home directory on the server onto a directory "secure" at his local computer. But bear in mind that Joe's secret key also has to be there.

sshfs joe@62.156.44.13: $HOME/secure

Once the remote data is being mounted, Joe is happy to see his data but every other user including root will only see the following when looking at Joe's home directory.

[root@localhost]# ls -l /home/joe

drwxr-xr-x 2 joe users 4096 Aug 6 2008 Videos
drwx------ 3 joe users 4096 Sep 1 2008 mail
drwxr-xr-x 2 joe users 4096 Sep 6 2007 proposals
d????????? ? ? ? ? ? secure

[root@localhost]# ls /home/joe/secure

ls: cannot access /home/joe/secure: Permission denied

And that's exactly how things should be.

Have you ever listened to someone who had been fallen victim to a burglary, someone whose home had been broken into by a criminal, entirely ignoring his privacy, snooping around in his personal belongings and making a total mess of everything coming across his way? It is nearly impossible not to feel the pain yourself this person has been through.

And in the online world things are not that different. After all the effort you've put in to getting a Virtual Private (!) Server going, and after furnishing it with something you think is valuable and worth protecting, you can easily get into a similar rage about people starting to break into your VPS the minute you have finished to make it a venerable target for those careless and often thoughtless digital scumbags on the Internet.

A brief look at the file "/var/log/security" shows how your virtual home is under attack right at the moment.



I sincerely welcome any and all attempts possible to counter the disgusting actions of those, who in most cases are not even remotely aware of or capable to understand, what the software does they are (ab)using.

Statistics of a Break-In Attack

Let's have a look at such an attempt to abuse the ssh service at my VPS. It is recorded in the very first hours this machine became visible on the Internet.

During the best part of an hour the attacker had tried 583 passwords to break into my digital home, nearly every 4 seconds a failed ssh connection was recorded in my logfiles, not unsurprisingly targeting the root account. As it turned out, the IP address was not bound to a registered domain name, so it could even be a innocent user's PC taken-over by the attacker.

Counter-Measures

Some people have suggested trying to play "hide and seek" with the culprits by switching the native port 22 which is used by SSH to something like 51679. Even though that may reduce the rate of attacks, it surely won't deter those who use port scanners to find the port used for SSH.

Others rely on periodically updating their "/etc/hosts.deny" file blocking access from IP-addresses that have proven to be suspicious. This may solve the problem for those attacks that always start at the same hosts, but attackers changing their base frequently will still enjoy an open door, once they are using a freshly taken-over host machine.

I have been taking a different approach, namely to change the response of my firewall to incoming ssh requests. I changed the rules so that only 3 attempts per 2 minute period are being served. This reduced my server's susceptibility greatly, as the automated attacks tend to break off after very few tries and don't return.

The following lines added to my firewall script did the job: