March 24, 2011, 4:07 p.m.
posted by jack
As we said above, FTP is probably the most common method of file transfer. However, it's also one of the most dangerous. Many new administrators enable anonymous FTP access and full-write access, to make it easy to load files onto their server. Then they wonder why their hard drives have filled up with illicit files.
Anonymous FTP isn't the problem-poor system administration is. Even though FTP is one of the oldest protocols on the books, a lot of people don't bother to learn how to run it safely and publicly. Those who don't want to take the time to implement FTP securely should switch to an inherently safer option, like the SSH-based methods or WebDAV/SSL.
For many years, the Red Hat Linux FTP default daemon was wu-ftpd, a notoriously insecure daemon. With Red Hat Linux 8, the default changed to vsftpd, the version that ships with Fedora Core. Of course, vsftpd is still based on the FTP with all its security problems, but the daemon does give the FTP administrator some extra control over worst-case scenarios.
Those who administer file transfer services should pay particular attention to the major security sites. Vulnerabilities, exploits, and patches make the news here first, before CNNfn picks them up and your boss starts asking questions. We rely on www.cert.org, www.securityfocus.com, and www.cve.mitre.org.
In the past, Linux FTP daemons actually ran as subdaemons to either inetd or xinetd. This meant that actually the inetd or xinetd service was listening on the FTP control port (21) for incoming FTP requests, not the FTP daemon itself. However, vsftpd now runs as a stand-alone daemon on most Red-Hat-based systems. If you turn on the stand-alone service, you will be able to see it running by itself in the output of netstat:
# /etc/init.d/vsftpd start Starting vsftpd for vsftpd: [OK] // netstat -natp Active Internet connections (servers and established) Proto Recv-Q Send-Q Local Address Foreign Address State PID/Program name tcp 0 0 0.0 .0.0:32770 0.0.0.0:* LISTEN 3428/rpc.statd tcp 0 0 127 .0.0.1:32771 0.0.0.0:* LISTEN 3639/xinetd tcp 0 0 127. 0.0.1:783 0.0.0.0:* LISTEN 3732/spamd -d -c -a tcp 0 0 0.0 .0.0:111 0.0.0.0:* LISTEN 3408/portmap tcp 0 0 0.0 .0.0:80 0.0.0.0:* LISTEN 3754/httpd tcp 0 0 0.0 .0.0:21 0.0.0.0:* LISTEN 4675/vsftpd tcp 0 0 0.0 .0.0:22 0.0.0.0:* LISTEN 3623/sshd tcp 0 0 127 .0.0.1:631 0.0.0.0:* LISTEN 3585/cupsd tcp 0 0 127.0.0.1:25 0.0.0.0:* LISTEN 3693/master tcp 0 0 0.0.0.0:443 0.0.0.0:* LISTEN 3754/httpd tcp 1 0 192.168.128.25:32778 184.108.40.206:80 CLOSE_WAIT 4587/esd tcp 1 0 192.168.128.25:32777 220.127.116.11:80 CLOSE_WAIT 4587/esd tcp 0 0 192.168.128.25:32936 18.104.22.168:22 TIME_WAIT -
The vsftpd daemon is shown listening on port 21.
FTP actually runs on two ports: 20 and 21. Port 20 carries FTP data, while port 21 manages FTP control information. Since an incoming request is control information, vsftpd listens on port 21. The actual data is sent over port 20.
If you've configured other network services on your Fedora Core system, you may think that you're good to go with vsftpd once the installation is finished. This is not quite the case. Even if you set up an FTP server by selecting the ftp-server package at installation and the vsftpd packages were installed properly, you can't start using the service right away. Fedora Core actually installs vsftpd differently than it does other daemons. For example, here's what happens when you install Sendmail and set up the SysV initialization scripts for the mail server:
# chkconfig --list sendmail sendmail 0:off 1:off 2:on 3:on 4:on 5:on 6:off
As expected, when the system installs the boot-time (or init) scripts for the Sendmail daemon, they are configured to come on in the main runlevels. When you boot this machine, the mail transfer agent (Sendmail) will come online. Now, what happened when you installed vsftpd?
Hmm. Even though the commands were the same for Sendmail and vsftpd, vsftpd's default install configuration is off. This is a simple default security measure that's relatively new, but appreciated, under Red Hat Linux products. In order to use FTP, you must first install the daemon and then intentionally configure the init scripts to turn the service on at boot time, as seen in the following command sequence:
# chkconfig --list vsftpd vsftpd 0:off 1:off 2:off 3:off 4:off 5:off 6:off # chkconfig vsftpd on # chkconfig --list vsftpd vsftpd 0:off 1:off 2:on 3:on 4:on 5:on 6:off
Now the daemon will come up after a reboot. To turn on the service without rebooting, issue the following command (in many Linux distributions):
#/etc/init.d/vsftpd start Starting vsftpd for vsftpd: [ OK ] #
On Red Hat or Fedora systems, you might opt for the following method:
#service vsftpd start Starting vsftpd for vsftpd: [ OK ]
Issue the netstat command to check whether the service is running on port 21:
#netstat -antp | grep 21 tcp 0 0 0.0.0.0:21 0.0.0.0:* LISTEN 4675/vsftpd
Once you've gotten vsftpd up and running, any known users (that is, not anonymous) who are not in the vsftpd blacklist file will be able to log in. If you have users who should not have access to FTP resources, open /etc/vsftpd.ftpusers and put their usernames in this file. You can also add system or new service accounts to this file to restrict FTP access for system accounts. In this sample/etc/vsftpd.ftpusers file, we have blocked FTP access for the user mike:
Your various system service related accounts should be listed in /etc/vsftpd .ftpusers by default. Normally, if you take root out of this file, you allow root to log into FTP on your server-you might as well hand out invitations to the hacker/cracker sniffers out there who are looking for root passwords via the PASS string. Luckily, vsftpd is compiled to deny access to root regardless of its setting in this file, but it's a good practice to keep all your service related system accounts, as well as problem users, in your /etc/vsftpd.ftpusers file.
Another useful security-related vsftpd file is the /etc/vsftpd.user_list user password prompt file. If a user is listed in this file, he will not even be offered a password prompt if he attempts to FTP into the machine. As with /etc/vsftpd.ftpusers, /etc/vsftpd.user_list is filled with system accounts and root. It's a good way to protect passwords for accounts that have no business logging into FTP from even being queried for a password. If there is no password prompt given, there's no way to sniff the password string as it's sent. For some environments, simple login denial is not secure enough.
Unlike most other daemons' config files, you do not need to restart vsftpd for the userbased changes to take effect after you edit /etc/vsftpd.user and /etc/vsftpd.ftpusers They are adopted instantly, unlike changes to the main daemon config file, /etc/vsftpd/vsftpd.conf.
Once you've defined your user blacklist file, you can begin to configure vsftpd for your particular environment. Note that these settings create user-based restrictions only. In order to define restrictions for entire networks or hosts, see Chapter 11 to learn more about working with TCP-Wrappers and iptables.
The main vsftpd configuration file is /etc/vsftpd/vsftpd.conf. The first lines you should look for areas follows:
anonymous_enable=YES local_enable=YES write_enable=YES local_umask=022 #anon_upload_enable=YES #anon_mkdir_write_enable=YES
Note that anonymous FTP is turned on by default. Though it may seem unwise to have write access also turned on, note that anonymous upload, mkdir, and write are all commented out. This indicates that only valid system users will be able to write to the local file system(s).
Anonymous FTP logins are directed to /var/ftp. If you want anonymous users to write to your drive, you must enable anonymous login, write, and create as well as change the permissions of /var/ftp to enable access. More frequently, administrators create an "incoming" directory with specific permissions for anonymous users. If you do so, consider setting it up as a symbolic link to removable media or a drive with quota control, and run regular cron jobs to purge the directory. Don't set up a quiet haven for illegal material.
As you continue to read through the configuration file, you'll notice entries for timeouts and other connection management details:
dirmessage_enable=YES xferlog_enable=YES connect_from_port-20=YES #chown_uploads=YES #chown_username=whoever #xferlog_file=/var/log/vsftpd.log xferlog_std_format=YES #idle_session_timeout=600 #data_connection_timeout=120 #nopriv_user=ftpsecure #async_abor_enable=YES #ascii_upload_enable=YES #ascii_download_enable=YES #ftpd_banner=Welcome to blah FTP service. #deny_email_enable=YES #banned_email_file=/etc/vsftpd.banned_emails
Look for the following lines in the file:
chroot_local_user=YES #chroot_list_enable=YES #chroot_list_file=/etc/vsftpd.chroot_list
This is a useful trick that allows you to chroot users into their own home directories when they FTP in. When you have this turned on, users can't get out of their home directories and go browsing around your file system. In the old days, setting this up was a bit complex, but vsftpd does it automatically.
Next, find this section in /etc/vsftpd/vsftpd.conf:
#ls_recurse_enable=YES pam_service_name=vsftpd userlist_enable=YES #enable for standalone mode listen=YES tcp_wrappers=YES
If you want to use TCP-Wrappers with your FTP service, this final line must be turned on. For those who dislike iptables for securing system services against certain hosts, TCP-Wrappers is a more simple user space form of service/host blocking. We cover TCP-Wrappers in Chapter 11.
Traditionally, most FTP problems have come from server firewall settings, client settings, or passwords. Over the past few years, however, there has been a rise in the number of problems related to passive versus nonpassive FTP. These problems appear when someone inside a local LAN or behind a firewall attempts to use a nonpassive (or just plain old) FTP server elsewhere on the Internet. The authentication goes smoothly on port 21, but when the FTP server attempts to open port 20 back to the client, the client's local firewall often blocks the connection. While this is logical, since an attempt from the outside to open an incoming port is indicative of cracker activity from the client's perspective, it's irritating to someone who just wants to get a file. More modern, intelligent, stateful, and protocol-savvy firewalls are aware of things like FTP session tracking (such as iptables or netfilter on Linux). However, many firewalls out there still do not have such awareness.
The best solution is to have the user try making the connection in passive FTP mode. In passive mode, the FTP client sets up both the authentication connection and the data connection, rather than having the remote FTP service open the data port back to them. Most modern FTP servers support passive-mode sessions, including the vsftpd daemon found on Fedora Core.
Learn more about the differences between active and passive IP at www.linuxchix.org/content/courses/security/connection_tracking.
In order to use passive-mode FTP, the user will need to change settings in the user FTP client. Most modern user clients, whether GUI or command-line, have this option. (If your user's client does not, encourage an upgrade.) GUI users should check their configuration or preferences menu for the correct option, while those using command-line clients will need to invoke the proper command or set a variable. Those using the ncftp FTP client should log in and then use this command sequence to enable passive mode:
ncftp / > passive passive on
while those using the lftp client should issue the command
lftp [email protected]:~ > set ftp:passive-mode on
after logging in to the remote server.
Many users have started to use Internet Explorer (IE) as an FTP client. While it works most of the time, IE will not handle passive FTP by default. Check Microsoft's configuration suggestions at http://support.Microsoft.com/?kbid=323446. In addition, make sure they're using the latest version of IE. There are documented problems with passive FTP on IE version 5.x.