Peter's Blog

I had to rebuild the company ftp server since the power supply in the old box failed and made the motherboard unreliable: I couldn't seem to reinstall linux on it without many disk errors. Eventually we bought a new ftp box and I put the server version of ubuntu 7.10 on it.

This ftp box is used to exchange files with clients and so is set up with two network cards and firewalled such that folk could only ftp into it and not do anything else. I tried to do some simplistic firewalling using iptables directly but it proved unreliable: sometimes there were mysterious long delays when trying to connect to the ftp server.

I decided to try using Shorewall to implement a proper firewall. This is essentially a set of macros that convert a set of rules from text files into a load of iptables definitions. I installed it with

sudo aptitude install shorewall

copied the two interface card example files from /usr/share/doc/shorewall/examples/two-interfaces to /etc/shorewall, tweeked a couple of lines in the 'rules' file and was away. It was surprisingly easy and it is easy enough to allow access to new servers on the box. For example, allowing everyone to access the ftp server was as simple as:

FTP/ACCEPT      net             $FW
FTP/ACCEPT      loc             $FW

where 'net' means 'anyone on the internet', 'loc' means 'anyone on the intranet' and $FW means 'let them into the firewall'.

Shorewall works by programming up 240 lines worth of clever iptables rules. These rules contain things to prevent attacks by smurfs, martians etc. After doing this, connecting to the ftp server was incredibly fast, it seemed to be up before I'd let got of the mouse button, even using Internet Explorer (as most non techies do). I always thought that IE was just poor at ftp but it seems that not enough people are firewalling their ftp sites nicely.

I had a need to put an ftp server on my slicehost slice so someone could upload stuff to a site I was hosting. I'd rather avoid ftp as a potential security hole but the alternative is to try to convert them to sftp and also the E editor only supports ftp.

I settled for vsftpd as the ftp server but it took ages to get this person's login to work. I had him set up chrooted to the directory he needed to be in and with his shell set to /bin/false to prevent him logging into a shell. When testing I couldn't log in as him without getting a generic error 530, login denied according to the log file (which didn't feel the need to say why login was denied). Of course my own login was fine.

The answer was in the vsftpd faq, it seems that vsftpd looks through a file called /etc/shells to see if the person connecting has a legitimate login shell and /bin/false wasn't in there. It says this check can be disabled but the incantation didn't work so I had to add /bin/false to the shells file.

I don't quite understand the logic of this design. Isn't it fairly standard to have users who can ftp in but not login? The /bin/false trick was following a precedent from the noble ubuntu/debian distributions.

I'm getting into the habit now of adding any file I edit in /etc to subversion (as noted here), if only as a way to keep track of which ones I have fiddled with. The 95% that I don't need to touch are not in subversion. I like this, I can recall what I did and why (through subversion comments) which will help me restore the system or replicate it. That way, next time I need to install vsftpd I can recall what other obscure system files need tweeking.