pitter patter on the keyboard

Plain FTP suffers from a number of problems, foremost is transmission in cleartext. Unless SSL is used (I have come across very few occurrences of its use in the wild) usernames and passwords, as well as the files being transmitted, are sent over the wire unencrypted. This means anyone with a well-placed sniffer or man-in-the-middle setup between the client and server can intercept or mutilate the data without much skill or resource cost. FTP also suffers from NAT issues, in that some users must forward ports or use passive transfer mode – words most of the users who will be using your hosting service have probably never heard, don’t want to hear and have no idea how to implement.

Enter SFTP: file transfer over Secure Shell. Not to be confused with FTPS, or “FTP Secure” (FTP with SSL), SFTP shares nothing in common with FTP other than its purpose: moving files around the network. SFTP uses a single, wholly encrypted tunnel from the client to the server to send and receive files. This avoids the problems associated with NAT and FTP’s dual-connection implementation, provides a relatively secure means of authentication and prevents third-party manipulation of the data in transit. SSH also warns users when a server’s RSA keys change so diligent users can identify and avoid potential man-in-the-middle attacks. SFTP is not, however, a perfect solution. OpenSSH, the implementation which we will be dealing with in this article, can be found on most Linux and BSD servers. Due to its ubiquity it is a prime target for 0-day exploits on one hand, and well hardened against known exploits on the other (you do keep your software patched and up-to-date, right?).

SSH, like any service that uses a username-password authentication scheme – including FTP, is vulnerable to brute-force or dictionary cracking attacks. This problem can be virtually eliminated by disabling user-pass authentication altogether and using on shared keys (please my article Passwordless or Single Password SSH with Key Exchange for instructions on implementing this configuration) however this is probably not an appropriate solution for your public hosting project as the process is difficult for regular users to implement, particularly if they are using a Windows client such as FileZilla. One solution which I highly recommend is fail2ban, it will read your sftpd logs and temporarily block an IP address associated with a specified number of failed attempts over a given period of time. I have provided simple instructions for implementing fail2ban for SSH in my article Stifling Brute Force Attacks with fail2ban. Because we are dealing with a situation where users are prone to forget their password you may wish to use fairly loose criteria in configuring fail2ban, enough failures should be tolerated that a forgetful user won’t be quickly blocked but an automated attack should be picked up. You might also wish to block access to sftpd rather than all ports as affected users might understand sftp disappearing after several failed attempts but could think the server is down if they are unable to access their website (assuming it is hosted from the same server).

The “chroot jail” concept is as old as the hills and has provided a way for us to separate vulnerable services from the filesystem-at-large by faking them into thinking a certain directory is the absolute root (/) of the filesystem. In this article we’re going to apply this concept to regular users using OpenSSH’s built-in functionality available since version 4.9. Before then it was a royal pain to implement whereas most popular FTP daemons had supported the feature out-of-the-box for years, now SFTP can finally be considered a complete and suitable replacement.

One probably does not wish to restrict SSH access for ALL user accounts, since one probably needs remote administrative access to the machine. Therefore one shall create a group to which users who must be chroot jailed will be added. For the purposes of this article we shall call the group hosted but you may call it anything:

# groupadd hosted

Next add users to the group, if you want to make sure these users do not get regular shell access (the ability to log in and run commands etc) be sure to specify a dummy shell, such as /bin/false or /sbin/nologin (Gentoo):

# useradd -G hosted -s /bin/false demo-user
or
# usermod -G hosted -s /bin/false demo-user

Don’t forget to give your test account a password if it is a new account.

# passwd demo-user

Now open your sshd config file (most users: /etc/ssh/sshd_config) and go to the very bottom. If there is a Subsystem sftp line already delete it. Add the following:

Subsystem       sftp    internal-sftp

Match Group hosted
        ChrootDirectory %h
        ForceCommand internal-sftp
	AllowTcpForwarding no

The Match Group directive tells sftpd to use the proceeding settings for any user in the group hosted. Now you must change the owner (and optionally group) of the user’s home directory to root:

# chown root: /home/demo-user

Due to these permissions the user will not be able to create new files at the top level of their directory tree, which to you looks like /home/demo-user and to them /. That’s fine because we’re going to give them a directory for the site they want to host with appropriate ownership, then they can do whatever they want in that. I typically set users up thus:

# mkdir ~demo-user/demo-site.com
# mkdir ~demo-user/demo-site.com/htdocs
# mkdir ~demo-user/demo-site.com/log
# mkdir ~demo-user/demo-site.com/cgi-bin
# chown demo-user: ~demo-user/demo-site.com/ -R

Restart your sshd (/etc/init.d/ssh(d) restart) and try logging in as your jailed user via sftp. If it works, congratulations. If you chose to restrict regular SSH access you may need to include /bin/false (or /sbin/nologin etc) to your /etc/shells valid shells list or the user may not be able to log in at all. Try logging in via SSH to ensure access has been blocked.

ClearOS is the latest incarnation of ClarkConnect, a linux-based router/network appliance distribution produced by the similarly re-branded Clear Foundation.

This post will show you how to gently abuse Gateway Mode to set up a single PPTP tunnel for use with multiple private subnets if you need to use a standalone VPN server. This does not apply if your VPN server is the gateway for your private subnets.

If you run a large network chances are you don’t want to bugger up your clients’ ability to pptp out. That means, for all practical “supported” purposes, you can’t use your ClearOS/CC gateway(s) as PPTP servers. The answer of course is to set up a “standalone” VPN server. If you’re working with a $0 budget or you pay for your rack space this might not be an attractive solution. You can always turn an existing physical server into a VPN gateway but for the purposes of this guide we’re going to assume you have a dedicated server or virtual machine.

In both cases the machine needs to have no less than two ethernet interfaces. If you’re using a VM I find that Clear fits nicely into 96 megs of ram with 20 megs room to breathe once you’ve trimmed off all the crap you don’t need (hald, messagebus, iscsid, etc – anything you won’t use on a VM unless you’re an X nut). Use

then

for every excess service that loads in runlevel3. If you use physical hardware you will need to ensure both NICs are plugged into a switch otherwise they won’t come up on boot (or, naturally, you can alter the networking init script).

For this example, you have three private networks at headquarters:

10.0.0.0/8
172.16.0.0/12
192.168.0.0/24

And your client will be on a local NATted subnet of say

192.168.1.0/24

Log into the webconfig of your new VPN server. Make sure Gateway Mode is selected. Set eth0 to external mode and assign a routed public address and gateway to it, this is the IP you’re going to come in on. Now for each of the private networks add an IP to a virtual interface ON ETH0. Add an IP somewhere that will never be used to eth1 thus:

By now you’re wondering why we have this dummy eth1 that does nothing. It’s very simple – we’re tricking CC into routing these subnets over the vpn by using the built in Gateway Mode. I can’t stress this enough: what we’re doing is not ideologically correct. It is, however, clean and simple.

Enable the PPTP server if you have not already done so and set the IP pools to some unobstructed address space on one of your private subnets. Make sure the ClearOS firewall is happy passing GRE (it will tell you if it’s not on the PPTP webconfig page).

Now on the client end you’re going to create a PPTP connection just like you always would except for one twist: once the connection is established add the private subnets to the client’s routing table on the ppp interface thus:

And presto! You can talk to any host on any of those networks with one IP and one tunnel thanks to a gentle abuse of Gateway Mode. I like to speed this up by adding those lines to a short shell script.

If you’re a windows user, leaving Use Remote Gateway checked in the connection preferences will get you the same effect with one small hitch – all of your traffic (web browsing, chat etc) will be routed through your VPN and any time you connect or disconnect whatever open connections you have will be reset.

Without getting too much into details you want to (at a CLI) type:

route print

remember the hex number for your PPP connection. Type:

route add 10.0.0.0 mask 255.0.0.0 192.168.0.66 metric 2 if (hex number)

You probably don’t need the metric bit but some of the people connecting to my particular vpn server will sometimes be connecting to their own subnets and that’s bad for routing. Substitute 192.168.0.66 with the private IP your VPN server sits on in the same subnet as the PPTP IP pool.

Naturally, replace 10.0.0.0/8 with whatever private subnet you’re trying to add (you don’t need to do the subnet you’re actually put on by the PPTPd, that’s automagic). For additional subnets: Lather. Rinse. Repeat.

Everything I’ve read so far says windows will automagically detect what interface to use based on the gateway you specified but that hasn’t worked for me. If it works for you, great! Use the -p flag to save the routes to your registry. You will find however that there is nothing static about windows interface numbers particularly when dealing with on-again-off-again VPN connections.