In previous articles, we introduced TFTP and discussed why you might want to use it, and we looked at various configuration options. Now let’s try and move some files around. You can do this with some comfort now that you know how to secure your server a little better.
Testing 1, 2, 3
To test your server, you obviously need a client to connect with. Thankfully, we can install one very easily:
# apt-get install tftp
Red Hat derivatives should manage a client install as so:
# yum install tftp
If you look up your server’s IP address using a command like the one below, then it’s possible to connect to your TFTP server from anywhere (assuming that your TCP Wrappers configuration or IPtables rules let you, of course).
# ip a
Once you know the IP address, it’s very simple to get going. You can connect like this to the server from the client:
# tftp 10.10.10.10
Now you should be connected. (If it didn’t work, check your firewalling or you might “telnet” to port 69 on your TFTP’s server IP address). Next, you can run a “status” command as follows:
tftp> status
Connected to 192.168.0.9.
Mode: netascii Verbose: off Tracing: off
Rexmt-interval: 5 seconds, Max-timeout: 25 seconds
At this point, I prefer to use verbose output by simply typing this command:
tftp> verbose
You can opt to download binaries or plain text files by typing this for plain text:
tftp> ascii
Or, you can force binaries to download correctly with:
tftp> binary
To give us some content to download, I created a simple text file like this:
# echo hello > HERE_I_AM
This means that the file HERE_I_AM contains the word “hello”. I then moved that file into our default TFTP directory, which we saw in use previously in the main config file, /etc/inetd.conf. That directory — from which our faithful daemon is serving — is called /srv/tftp, as we can see in Listing 3.
Because this is just a plain text file, there’s little need to enable binary mode, and we’ve already written verbose, so now it’s just a case of transferring our file.
If you’re at all familiar with FTP on the command line, then you’ll have no difficulty picking up the parlance. It is simply “get” to receive and “put” to place. My sample file HERE_I_AM can be retrieved as follows.
tftp> get HERE_I_AM
getting from 192.168.0.9:HERE_I_AM to HERE_I_AM [netascii]
Received 7 bytes in 0.1 seconds [560 bits/sec]
The above example offers the verbose output when that mode is enabled. You can glean useful information, such as that we’re not using binary mode but just “netascii” mode. Additionally, you can see how many bytes were transferred and how quickly. In this case, the data was seven bytes in size and took a tenth of a second, at half a kilobyte (or so) a second, to complete.
Compare and contrast that to the non-verbose mode output, and I’m sure you’ll agree it’s worth using:
tftp> get HERE_I_AM
Received 7 bytes in 0.0 seconds
If you feel the need to obfuscate your TFTP server’s port number then, after editing the /etc/services file, you need to connect with your client software, like so:
# tftp 10.10.10.10 11111
Additionally, don’t be too frightened of requesting multiple files on one line. Achieve just that by using this syntax:
# get one.txt two.txt three.txt four.txt five.txt
If you run into problems, there are a couple troubleshooting options to explore. You might for example have a saturated network link due to a broadcast storm or a misbehaving device causing weird network oddities. You will be pleased to learn, however, that you can adjust timeouts. First, from the TFTP client prompt, we can set timeouts on a per-packet basis as so:
tftp> rexmt 10
This shows us setting the retransmission timeouts on a per-packet basis to 10 seconds.
To set the total-transfer timeout, for the entire transaction, adjust the following setting, like this:
tftp> timeout 30
Another useful tool for debugging is the “trace” functionality. It can be enabled as follows:
tftp> trace
Packet tracing on.
Now, each transfer will look very noisy, as below, which should help with your troubleshooting:
tftp> get HERE_I_AM
sent RRQ <file=HERE_I_AM, mode=netascii>
received DATA <block=1, 512 bytes>
sent ACK <block=1>
received DATA <block=2, 512 bytes>
sent ACK <block=2>
received DATA <block=3, 512 bytes>
[..snip..]
From the above information, you should be able to tell at which point a transfer fails and perhaps discern a pattern of behavior.
Incidentally, if you want to quit out of the TFTP client prompt, then hitting the “q” key should suffice.
In this section, we have seen how to configure and receive files from a TFTP Server. As mentioned it’s a good idea to firewall port 69 from the outside world if you experiment with this software and especially if you deploy it in production.
I recommend that you either lock down your server so it can only be accessed by a few machines by using IPtables or TCP Wrappers. Although it’s an older technology, TFTP is undoubtedly still a useful tool to have in your toolbox, and it shouldn’t be dismissed as only being useful for passing configuration to workstations or servers as they boot up.
Systemd
Incidentally, to start and stop the TFTP server (or restart it after making a config change) on modern systemd systems you can run this command, substituting “stop” with “restart” or “start” where needed.
# systemctl stop openbsd-inetd
On older systems, there’s no need to remind you that in most cases one of these commands will suffice.
# /etc/init.d/openbsd-inetd start
# service openbsd-inetd restart
Simply change openbsd-inetd to the name of the appropriate inetd or xinetd scripts for your distribution. Remember that you can find out service names by running a command like this:
# ls /etc/init.d
This even works on modern systemd versions but you need to look closely at the resulting file listing because let’s face it conduits to “inetd” might be considered a throwback in some circles and have strange filenames.
EOF
If you decide to take your life into your own hands and serve TFTP across the Internet, let me offer one word of warning, well, one acronym actually: NAT. If Network Address Translation is involved in remote connections, then you may struggle with TFTP transfers because of the fact that they use UDP. You need the NAT router to act as a slightly more advanced proxy to make this work. You might look at the renowned security software, pfSense, which can apparently assist.
We have looked at a number of of TFTP’s features. Clearly, there are specific circumstances when the excellent TFTP is a useful tool that can be used quickly and effectively with little configuration.
At other times admittedly, TFTP won’t quite cut the mustard. In such cases, sFTP and standard FTP might be more appropriate. Before searching for those packages, however, have a quick look to see if the features you need are present within TFTP’s toolkit. You might be pleasantly surprised at what you find. After all, many of the tools we use today herald from the time from which TFTP came.
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.
Read previous articles:
Trivial Transfers with TFTP, Part 1: Why Use It?
Trivial Transfers with TFTP, Part 2: Configuration
