Raspberry Pi FTP server

I’ve been trying to resurrect my SIP-connected Cisco 7940 as part of a review of our home telephony arrangements. In order to do this, I’ve had to configure the TFTP capabilities on my home infrastructure server (i.e .my Raspberry Pi). Previously, I’d served the phone configuration from a Windows TFTP server (long since gone) and the phone had just kept going with the old settings. Now, with configuration changes required, I’ve started to use dnsmasq for TFTP as well as DNS and DHCP (actually, that had always been configured, but without any files on the Pi to serve from TFTP)!

So, how to easily transfer the files? FTP to the rescue. I followed the Pi My Life UP guide to install vsftpd on my Pi, which meant using the following commands:

  1. Update packages and install vsftpd:
    sudo apt-get update
    sudo apt-get install vsftpd
  2. Edit the vsftpd config with sudo nano /etc/vsftpd.conf, making sure it has the following entries:
  3. Create the folder to use for FTP and set the permissions:
    mkdir /home/pi/ftp
    mkdir /home/pi/ftp/files
    chmod a-w /home/pi/ftp
  4. Restart the FTP service with sudo service vsftpd restart.

After this, I could easily upload the files I needed to the folder that I’m serving TFTP from (/home/pi/ftp/files) – although for some reason the FTP server was listening on port 22 (not 21), and then distribute my new phone configuration…

Failing WordPress updates fixed by enabling FastCGI

For months, although it feels like years, I’ve been struggling with WordPress upgrades and it’s been driving me mad.  Each time I’ve attempted an in-app update of a plugin (or WordPress itself), it’s asked me for FTP credentials and then, usually, failed.  I’ve got used to re-installing WordPress but it shouldn’t be this way.

The problem, it seems was a combination of WordPress file ownership/permissions. I had to set the wp-content/upgrade folder permissions to 777 in order to successfully update plugins and that just didn’t feel right.  Luckily, I’m on good terms with my hosting provider and they started looking into the issue for me.  It seems (I think) that Apache was running as nobody and that was presenting some issues with WordPress. Changing the owner on my /blog folder (to nobody) fixed WordPress, but it meant I couldn’t FTP any content to the folder using my own username, so we went back to the drawing board.

I can’t claim to understand all the technical details but I’m told the fix was to enable FastCGI on the server.  It was originally disabled because it’s memory-hungry (spawning child processes for each user) but wow, FastCGI is a good name. Now my WordPress upgrades take seconds. I updated twice yesterday (to 3.1.4, then later to 3.2) and I was amazed how quickly things happened. That is good.

Keeping an eye on FTP upload progress with hash printing

I spent most of yesterday working on some more How-Do-I? videos for Microsoft. The delivery mechanism for these is via FTP, and the command line FTP client in Windows is pretty basic so it doesn’t show progress on uploads by default. My problem was that, when I’m uploading 50MB .zip files to a server, it’s nice to know that the transfer is still working.

Then I remembered something that Garry Martin had mentioned a few months back – the hash command.

Before starting an upload, I turned on hash printing, so the FTP client prints # characters to the console during the upload, demonstrating progress. I still prefer the BSD version on my Mac, which shows progress updates as a percentage by default, but at least I could see progress as Windows XP pushed the file to the server.

Windows FTP client with hash printing enabled

Internet Explorer displays credentials in status bar when used as an FTP client

A couple of weeks back, one of my clients pointed out that when he opens files from an FTP site using Internet Explorer (IE) as an FTP client his user name and password is displayed in the status bar at the bottom of his browser window.

FTP credentials visible in IE status bar

I seem to have the same problem with various flavours of Windows (2000, XP and 2003), a variety of IE patch levels, and can repeat it against both Unix and Windows-based FTP servers. I’ve not been able to test with older browser versions but as IE6 is the current version, this is my main concern.

One would think that there would be loads of information out on the ‘net about this but I can’t find much at all (except some reference to the issue in an internetfixes.com tip), which seems to suggest IE6 SP1 fixed this strange behaviour. Indeed, I built a PC with Windows XP SP1 (slipstreamed) and the issue was not there; however it reappeared after I upgraded to Windows XP SP2. I know the password will always be passed over the wire in clear text, and that RFC 2396, which defines the generic syntax for URIs (specifically section 3.2.2) recommends against the use of the format “user:password” in the userinfo field of the URL, but that’s just the way that FTP has been implemented! All I want to do is to prevent IE from displaying it in the status bar. As for ISA Server capturing the details in the proxy server logs… well that’s a whole new can of worms.

The strange thing is that a colleague who is using the same Internet Explorer version as me (6.0.2900.2180.xpsp_sp2_gdr.050301.1519 at update version SP2) can not repeat the issue.

It doesn’t help that IE version numbers don’t seem to increment as patches are applied. There is an interesting discussion of the merits of the Microsoft IE version number approach vs. the Mozilla Firefox approach in the comments to the April IE Security Update is available post on the IEBlog, and for anyone searching for information on the various versions of IE, the version numbers and associated Windows operating system version are all listed in Microsoft knowledge base article 164539. What I can’t find is any information on the fixes which update the last portion of the version number (i.e. from 6.0.2900.2180.xpsp_sp2_rtm.040803-2158 to 6.0.2900.2180.xpsp_sp2_gdr.050301.1519), although Microsoft knowledge base article 824994 does describe the significance of release to manufacturing (RTM), general distribution release (GDR), service pack (SPX) and quick fix engineering (QFE) software update packages and there is an article about the package installer (formerly called update.exe) for Microsoft Windows operating systems and Windows components in the Microsoft Windows Server 2003 TechCenter, which describes the multiple-branch-aware structure used for Microsoft patches.

I’ve spent hours loading patches one by one onto a client to see if the issue is resolved as a side-effect of a posted hotfix but can’t seem to get anywhere on this. The only answers I hear are “use the insert product name here FTP client” (incidentally, my preference is FileZilla) or “use SFTP”. What I’d like to hear is “apply Microsoft update xxxxxx“.

Implementing a secure FTP service using Microsoft IIS

Readers of this blog may recall that, last year, my open FTP server was hacked. That experience taught me a valuable lesson and earlier today, I needed to establish a secure FTP server installation using Microsoft Internet Information Services (IIS) 5.0 (well, as secure as you can with a protocol that passes authentication details in clear text – of course, there are SSL-secured alternatives available).

The first step was to install only the essential components of IIS, using the unattended IIS installation method that I posted last year.

Once installed, I ensured that the server was fully patched with all relevant security updates before working through the advice from the 10 steps to a secure an FTP server article on windowsecurity.com as well as some more advice which was given to me last year by Craig Schofield, a consultant from Microsoft who was working alongside me at the time:

  • Change the default port number for the site from 21 to a non-standard port. This is security through obscurity; however it may not be suitable depending on the clients used to connect to the server.
  • Remove all other protocols, using the IIS Lockdown tool to remove sample sites, other protocol mappings (e.g. WebDAV if installed) and to ensure that only the FTP Publishing Service is available (note that there is no point in installing URLScan for FTP servers, as it only applies to HTTP requests).
  • Use anonymous access, and only anonymous. This ensures that no security credentials details are passed over the wire (remember, FTP uses clear text for authentication). If user authentication is necessary, use a dedicated account that has no access to any other systems, files or components and the recommendation is to create a local or domain local group, assign this group the required permissions (log on locally, NTFS access), and add users to this group (removing them from the Users group).
  • Enable FTP logging, and ideally propagate all logs to a central location. Monitor logs for sign’s of attack/penetration.
  • Use a virtual private network (VPN) connection between machines, to ensure that all traffic is encrypted. Alternatively, create a secure IP (IPSec) tunnel between server and client.
  • Limit the number of FTP site connections to the maximum expected number.
  • Assign NTFS security restrictions to the user/group accounts used to access the FTP site.
  • Ensure any virtual directories are also protected by NTFS permissions, and are directed at secure locations (not C:\ for example).
  • Change the default home folder for the FTP Site from C:\InetPub\ftproot to another folder (preferably not on the C:\ drive so as to avoid a denial of service attack by using all available storage on the system disk)
  • Ensure appropriate steps are taken to secure the other accounts on the machine (disable Guest, rename Administrator, assign complex passwords).

Of course, operational requirements will mean that it is not usually possible to implement every one of the above measures, but each one adds to the principle of defence in depth.

Whilst checking my configuration, I came across Microsoft knowledge base article 318380, which lists IIS status codes for HTTP and FTP as well as providing links to the original World Wide Web Consortium (W3C) definitions and some common status codes and their causes.

Open source FTP client

In my post from a couple of weeks back, where I raved about the new Mozilla Firefox preview release, I admitted to becoming a bit of an open source fan of late. Last night I tried out another open source product – FileZilla.

FileZilla is an FTP client for Windows (there is also a FileZilla Server product). It supports both FTP and SFTP, and includes a well thought-out interface with a local site view, a remote site view and details of currently queued files for upload/download.

Using FileZilla, uploading a new version of my website took seconds, with FileZilla launching as many concurrent FTP sessions as my ISP would allow from a single upload request.

It looks like this tool could be a big time saver.

Allowing files to be replaced as part of an FTP rename operation

Yesterday, one of my clients came across an interesting scenario. They use FTP to poll sales data from their retail outlets back to a central location. As part of this process, the polling file is renamed to filename.bak; but what if filename.bak already exists from an earlier poll? The existing NT 3.51 FTP Server network component allows the rename with no problem, but XP’s FTP Server (part of IIS 5.1) does not, producing an error:

550 filename.bak: Cannot create a file when that file already exists

A quick search on the ‘net unearthed Microsoft knowledge base article 309634 . Once I had extracted the mdutil.exe utility from a Windows 2000 CD (see Microsoft knowledge base article 240225) I was able to run the following command:

mdutil set msftpsvc/1/AllowReplaceOnRename 1

A restart of the IIS Admin service was all that was needed then to allow the rename to take place within the polling process.

The perils of running an unsecured FTP server

Last week I got hacked.

I’d opened up my previously stealthed firewall to:

  • Access my home network when I’m at work;
  • Allow one of my friends to post some large files to my FTP server.

The trouble is that I hadn’t been carrying out the best practices that I would advocate for my enterprise clients. Despite last month’s post on securing IIS, I had just opened up the standard ports to a standard IIS server which wasn’t even in a demilitarized zone (DMZ).

I didn’t think I’d be a target for a hacker but within a few days some guys in Italy and Belgium had started abusing my FTP server to dump their files (this article from ZD Net leads me to believe that it’s a common practice). I don’t know what the contents were. I deleted them quickly to be safe and shut down the firewall until I could implement something more secure.

Thankfully, I got off lightly (this time). I checked the logs last night and my new security measures are keeping the intruders out. If you do need to provide an FTP service, you might like to read the windowsecurity.com article with 10 steps to secure an FTP server.