In the first article of this series, we looked at some of the, admittedly limited, features of TFTP along with some reasons why you might want to use it. Here, we take a look at the main config file and how to enable and disable services for improved security.
Debian
The following config for our Debian package won’t apply directly to Red Hat, but much of it should make sense at least. It’s important to pay attention to the openbsd-inetd package, which is provided because that’s how systemd interacts with starting and stopping the tftpd daemon via the old-school inetd service.
If you query Debian Jessie’s installation, then the README file offers the following version information: “This is netkit-tftp-0.17 for Linux.”
The server manual (viewed with the command man in.tftpd) also dutifully informs us that tftpd supports the DARPA Trivial File Transfer Protocol and respects which port it operates on by looking up the /etc/services file. In other words, to move it off of port 69, you can simply edit entries found within that file.
The Debian way of getting your TFTP server to start up after a reboot would look like this (assuming you installed the tftpd package of course and not the one offered as an alternative on Red Hat systems):
# systemctl enable openbsd-inetd
Our main config file (I can hear some of those cobwebs being blown away as you read the location of this file) can be found at: /etc/inetd.conf. This controls all things inetd related, but the helpful tftpd has included a line for us luckily.
Indeed an abbreviated version of that file, for the sake of simplicity, might look like that found in Listing 1:
# Packages should modify this file by using update-inetd(8)
#
# <service_name> <sock_type> <proto> <flags> <user> <server_path> <args>
#:BOOT: TFTP service is provided primarily for booting. Most sites
# run this only on machines acting as "boot servers."
tftp dgram udp wait nobody /usr/sbin/tcpd /usr/sbin/in.tftpd /srv/tftp
Listing 1: Our (abbreviated) main config file for “inetd” under which tftpd runs.
The first entry (on the first line) we should pay attention to in Listing 1 refers to update-inetd. This command needs to be run to enable and disable any tftpd services after we make changes to this file.
For example, if you wanted to change something like the directory of where files reside, then edit the last line in our abbreviated config file, altering “/srv/tftp” in this case, and then run the update-inetd command to set that change live.
There’s a nice old-school way of quickly commenting out all of the unencrypted access services with one fell swoop in the /etc/inetd.conf file by using the update-inetd command. It’s described in the manual and looks like this:
# update-inetd --comment-chars '#' --disable login,shell,exec,telnet
As you can see, we’re prepending comments to each line supporting these services to disable them by running this command. There’s are other useful options in the manual if you want to explore:
# man update-inetd
Again, in Listing 1, we can see that these days most people just use the TFTP protocol for boot server scripts. On a LAN, however, tftpd still has its place for other services, too, such as common read-only configs — for example, to reflect changes in NTP servers or other widely used services.
The eagle-eyed among you might have spotted /usr/bin/tcpd being mentioned inside the newly installed, old-timer, config file that is /etc/inetd.conf. This refers to TCP Wrappers, which allow us to control the IP address ranges or domain names that can connect to any service that links in with the library libwrap. It’s an excellent addition to any network-facing service and tftpd is no exception. Incidentally, if you wanted to check if a particular item has been configured to use the functionality provided by TCP Wrappers, you could run a command such as this:
# ldd /usr/sbin/sshd | grep libwrap
libwrap.so.0 => /lib64/libwrap.so.0 (0x00007f07e3066000)
The test above does indeed prove that our OpenSSH Server uses libwrap.so.0. To check another program, such as a mail server, simply replace the /usr/sbin/sshd with the path to the binary file that you wish to query.
To enable TCP Wrappers for your tftpd service you can quickly edit the /etc/hosts.deny file and add the following line:
tftpd: ALL
Then, inside /etc/hosts.allow, you can add a few rules of who can connect to the small file repository being served by your TFTP daemon. An example of an IP address might be:
tftpd: 10.10.10.
Note the trailing dot, which opens up all 254 hosts under the Class C “10.10.10.0” network. Additionally, it’s possible to allow specific hosts by using DNS names such as this example:
tftpd: .workstations.chrisbinnie.tld
Here we allow any workstation host (note the leading dot this time) under our Domain Name to connect without having to put an entry for each. There’s much more information available on the highly recommended TCP Wrappers here:
# man hosts_access
IPtables
If you felt the need to tinker with your existing IPtables scripts (provided courtesy of the excellent kernel-based firewall Netfilter), then you would add a line similar to this one below:
# iptables -I INPUT -p udp --dport 69 -j ACCEPT
This opens up UDP port 69 for inbound traffic as we can see.
Lift Off
If you run the command below to see if anything is listening on UDP port 69, then you can tell whether inetd has fired up tftpd’s daemon already.
# lsof -i :69
COMMAND PID USER FD TYPE DEVICE SIZE/OFF NODE NAME
inetd 9571 root 4u IPv4 139447 0t0 UDP *:tftp
Lo and behold, there is a service listening intently already, without any prompting right after our installation. Take that as a warning to secure your access immediately or stop the service right after the installation if you can’t spend time securing the service as soon as it is installed.
Next time, we’ll wrap up this series with more options to consider along with several examples of moving files around.
Chris Binnie is a Technical Consultant with 20 years of Linux experience and a writer for Linux Magazine and Admin Magazine. His new book Linux Server Security: Hack and Defend teaches you how to launch sophisticated attacks, make your servers invisible and crack complex passwords.
Advance your career in Linux System Administration! Check out the Essentials of System Administration course from The Linux Foundation.
