Paranoid Penguin - Secure Anonymous FTP with vsftpd
If you want to have multiple virtual FTP servers residing on the same physical host, one with multiple IP addresses, vsftpd can do this easily. All you need to do is run multiple instances of the vsftpd dæmon, each with its own vsftpd.conf file specifying on which IP address to listen and which directory to use as its anonymous root.
For example, suppose I've got two IP addresses assigned to my machine, 126.96.36.199 and 188.8.131.52, registered in DNS to the names knusper and rover, respectively. In that case, I could have two configuration files for vsftpd, say, /etc/vsftpd.knusper and /etc/vsftpd.rover. Listings 2 and 3 show these files.
Listing 2. Virtual FTP Server Configuration File /etc/vsftpd.knusper
listen=YES listen_on=184.108.40.206 connect_from_port_20=YES anonymous_enable=YES anon_root=/srv/ftp/knusper ftpd_banner=Welcome to FTP at knusper.wiremonkeys.org. Behave!
Listing 3. Virtual FTP Server Configuration File /etc/vsftpd.rover
listen=YES listen_on=220.127.116.11 connect_from_port_20=YES anonymous_enable=NO ftpd_banner=Private FTP at rover.wiremonkeys.org. Strangers-B-gone. # DANGER: don't use the following unless you know what you're doing! local_enable=YES
Notice my possibly foolish use of the local_enable parameter in Listing 3. It's dangerous to set this to YES, because FTP logon credentials are sent in clear text. You never want to expose real system credentials to eavesdropping, especially if your server is Internet-connected. The real reason I show it here is to illustrate that because each virtual server uses its own configuration file, you can specify completely different behaviors for each. One virtual server may have a public uploads directory that anonymous users write to, whereas another may be a strictly read-only FTP site. Conversely, you need to take care that settings you consider to be important in preserving overall system security are set consistently between different virtual servers running on the same machine.
Besides creating different configuration files for each virtual FTP server you want vsftpd to serve up, you also need to alter your startup script accordingly. The startup script on my sample server, represented by Listings 2 and 3, would need something equivalent to these two lines:
vsftpd /etc/vsftpd.knusper vsftpd /etc/vsftpd.rover
If you run Red Hat or Fedora, this already has been taken care of for you. The /etc/init.d/vsftpd script included with those distributions' vsftpd RPM packages automatically parses the directory /etc/vsftpd for as many configuration files as you care to put there, so long as the filename of each ends with .conf. This strikes me as an excellent bit of foresight on the part of the Red Hat team.
That's all you need to know about setting up a simple and secure anonymous FTP server with vsftpd. As I mentioned, I've only covered a subset of what vsftpd is capable of doing. Despite its minimalist design philosophy, this is a powerful FTP server indeed. Fortunately, it's also well documented, so it's really no cop-out for me to refer you to the vsftpd.conf(5) man page and the EXAMPLE/ directory for information on the many other uses of vsftpd.
Mick Bauer, CISSP, is Linux Journal's security editor and an IS security consultant in Minneapolis, Minnesota. He's the author of Building Secure Servers With Linux (O'Reilly & Associates, 2002).
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!
- SUSE LLC's SUSE Manager
- Murat Yener and Onur Dundar's Expert Android Studio (Wrox)
- My +1 Sword of Productivity
- Tech Tip: Really Simple HTTP Server with Python
- Non-Linux FOSS: Caffeine!
- Returning Values from Bash Functions
- Managing Linux Using Puppet
- Doing for User Space What We Did for Kernel Space
- Rogue Wave Software's Zend Server
- Parsing an RSS News Feed with a Bash Script