Paranoid Penguin - Secure Anonymous FTP with vsftpd
Can you believe that in nearly four years of Paranoid Penguin columns, I've never talked about how to configure FTP services? This month I fix that, using my new favorite FTP server, Chris Evans' excellent vsftpd (Very Secure FTP Dæmon). Because my space here is limited and the best use of FTP is anonymous FTP, we focus on anonymous FTP. The FTP protocol's use of clear-text authentication makes it a terrible choice for anything but anonymous file transfer. But anonymous FTP is still plenty useful.
vsftpd is increasingly popular and is included with recent versions of Debian, SuSE, Fedora, Red Hat and other Linux distributions. This inclusion probably is because vsftpd provides a unique combination of security and convenience. It is easy to get up and running in a hurry, without having to make ugly security-vs.-expedience trade-offs.
Chris Evans created vsftpd with security as a central design goal, and its track record so far is impressive. In the nearly four years it's been available, as of this writing, vsftpd has had zero significant security vulnerabilities. Regardless of whether that's still true by the time you read this article, it speaks to vsftpd's excellent design philosophy, which borrows from OpenBSD's “secure by default, extra features disabled by default, minimal complexity overall” motto.
How minimalist is vsftpd? Its entire source tree is just over 1MB in size, fully uncompressed. The vsftpd executable itself is 80K.
As I mentioned, vsftpd now is a standard package on many Linux distributions. The usual advantages of binary packages apply: convenience, easy patching and minimal impact on other system software. In Debian, SuSE, Fedora and Red Hat, the package you need predictably is named vsftpd. It has no particularly exotic dependencies. Most users probably will be perfectly happy with their distribution's stock vsftpd package.
If your distribution of choice doesn't provide a binary package for vsftpd, or if you need a later version than the one your distribution provides, compile vsftpd from its source code tarball, which is available at vsftpd.beasts.org. The build process is decidedly old school. If you aren't already, become root. Then, unpack the tarball and change your working directory to its root, like this:
# tar -xf vsftpd-1.2.1.tar.gz; cd vsftpd-1.2.1
Next, enter the command make without arguments. If it succeeds, there should be a vsftp executable in the current directory. Make sure the user nobody exists; if it doesn't, create it. vsftpd runs on this account.
Create the directory /usr/share/empty if it doesn't exist already. It should be owned by root and be neither group- nor world-writable—it will be used as the default vsftpd chroot jail.
Create a home directory for the anonymous FTP user. SuSE conventionally uses /srv/ftp, and other distributions use /var/ftp, but it can be whatever you like. Again, this directory should be owned by root and should not be writable by anyone else.
Create an anonymous FTP user account, such as ftp, and make sure its home directory is set to the one you created in the previous step. Your system already may have such an account. The anonymous ftp user should not be able to write in its home directory, and it should never own any files or directories.
Now you're ready to copy vsftpd and the vsftpd(8) and vsftpd.conf(5) man pages into more useful locations, so enter the command make install. Manually copy the sample vsftpd.conf file into /etc.
If you want to run vsftpd as a standalone dæmon, create a startup script for vsftpd in /etc/init.d. Otherwise, configure either inetd or xinetd to start it up as needed (see the Standalone Dæmon vs. inetd/xinetd section).
If you're running vsftpd as a standalone dæmon, enable the startup script with chkconfig if you use an RPM-based Linux distribution or with update-rc.d if you run Debian GNU/Linux. Alternatively, if you install vsftpd from an RPM or deb package, all these steps are executed automatically, with the probable exception of the last one. Did I mention that binary packages are much more convenient? Some distributions require manual intervention to enable newly installed packages. For example, on my SuSE 9.0 system, although the SuSE vsftpd RPM automatically installed /etc/init.d/vsftpd, I had to issue the commands chkconfig --add vsftpd and chkconfig --level 35 vsftpd on to enable the script.
Before I begin a discussion of vsftpd that focuses narrowly on running it as a standalone dæmon serving up only anonymous FTP, I should point out some valuable, much more complete, sources of vsftpd documentation. First, vsftpd comes with an EXAMPLE/ directory containing sample configurations for a variety of FTP scenarios, including running standalone, running with xinetd, serving anonymous users only and serving local users. If you installed vsftpd from source code, EXAMPLE is a subdirectory of your vsftpd source code tarball. If you installed vsftpd from a binary package, it's probably been copied to your system somewhere under /user/share/doc. It is /usr/share/doc/packages/vsftpd/EXAMPLE on SuSE systems.
As I mentioned in the previous section, vsftpd has man pages, vsftpd(8) and vsftpd.conf(5). Finally, the default (sample) vsftpd.conf file itself is well commented. It doesn't contain all vsftpd options, but it does illustrate the most commonly used ones. I've successfully gotten vstpd to work several times with only minimal tweaking to the sample vsftpd.conf file.
Practical Task Scheduling Deployment
July 20, 2016 12:00 pm CDT
One of the best things about the UNIX environment (aside from being stable and efficient) is the vast array of software tools available to help you do your job. Traditionally, a UNIX tool does only one thing, but does that one thing very well. For example, grep is very easy to use and can search vast amounts of data quickly. The find tool can find a particular file or files based on all kinds of criteria. It's pretty easy to string these tools together to build even more powerful tools, such as a tool that finds all of the .log files in the /home directory and searches each one for a particular entry. This erector-set mentality allows UNIX system administrators to seem to always have the right tool for the job.
Cron traditionally has been considered another such a tool for job scheduling, but is it enough? This webinar considers that very question. The first part builds on a previous Geek Guide, Beyond Cron, and briefly describes how to know when it might be time to consider upgrading your job scheduling infrastructure. The second part presents an actual planning and implementation framework.
Join Linux Journal's Mike Diehl and Pat Cameron of Help Systems.
Free to Linux Journal readers.Register Now!
- Stunnel Security for Oracle
- SourceClear Open
- SUSE LLC's SUSE Manager
- Murat Yener and Onur Dundar's Expert Android Studio (Wrox)
- My +1 Sword of Productivity
- Managing Linux Using Puppet
- Tech Tip: Really Simple HTTP Server with Python
- Non-Linux FOSS: Caffeine!
- Google's SwiftShader Released
- Doing for User Space What We Did for Kernel Space