| |
September 2002
Understanding TFTP configuration and use.
About a year ago I started writing my first piece of Open Source software.
The goal was to write a script that would allow me to send and receive
device configurations to and from remote routers and switches using the TFTP
protocol. Since most of the big names in networking hardware seem to prefer TFTP
as the de facto standard for file transfers between their equipment
and management servers, I thought for sure I would have an audience. As the
day approached for the 1.0 release of my software, I tried to think of every
problem or question a user might have upon first use. To my surprise
most of the inquiries coming in didn't concern how to configure the script at
all, instead I found most were asking how to set up their TFTP server. One
year later, my script is nearing version 6.0, yet at least once a week a
question will come in asking how to correctly set up TFTP. In this article,
I hope to give a solid base on how to get TFTP up and running using inetd or
xinetd on your Unix-based system.
Rather than running as a standalone service, TFTP is generally started by using
INETD or XINETD. Each has its own respective syntax that is generally straight
forward. For purposes of this article I'll be including examples from a Red
Hat Linux 7.2 installation. An INETD configuration is composed of a single
line in your /etc/inetd.conf file. The syntax is generally:
tftp dgram udp wait root /usr/sbin/tcpd in.tftpd
While the XINETD configuration is slightly more complex, overall the same
information is included in a basic, unaltered initial install. The
configuration is found in /etc/xinetd.d/tftp and appears as:
service tftp
{
socket_type = dgram
protocol = udp
wait = yes
user = root
server = /usr/sbin/in.tftpd
disable = no
}
Once the preceding configurations are present on your machine, you should be
able to send an HUP signal to your respective INETD or XINETD server to start
up your TFTP daemon. To verify that the service is listening run:
netstat -na | grep 69
You should see a response that looks like:
udp 0 0 0.0.0.0:69 0.0.0.0:*
If you do not see this response, double check your inetd.conf or xinetd tftp
file syntax and then restart the service in question.
After you have confirmed that your server is listening on UDP/69, you'll still
want to look at the TFTP option flags. Most common errors seen when using the
service arise from the assumption that TFTP works in a similar style to FTP.
Quite the opposite is true.
TFTP does not use authentication via usernames for reading and writing files
to the server. By default, TFTP attempts to write data through the user
"nobody". If this user does not exist on your system, you'll either need to
add it, or create another non-privelaged user that will act on behalf of the
daemon when interacting with data on the server. In our scenario, we'll create
the user "tftpd". The user will have a shell of /bin/false and a home
directory of /dev/null:
useradd -d /dev/null -s /bin/nologin tftpd
Now that we have our user created, comes the question of where the data for
TFTP is written and read. The daemon's default action is to expect a full
pathname to the file. Obviously this is not the most secure method of server
interaction. Luckily TFTP provides the option of specifying a directory as the
server root. Once the directory is chosen, the TFTP server will chroot to this
location for each read or write request.
In our scenario, we'll use the directory /usr/local/tftp as our preferred location.
This chroot action will mean that any file being written or read by TFTP must
be located in this directory or one of its subdirectories. As an example, a
file being sent to the server with a path of /router.confg will be written to
/usr/local/tftp/router.confg. Likewise, for subdirectories, a file being read
with a path of /archives/switch.confg will actually be read from
/usr/local/tftp/archives/switch.confg.
The last requirement that needs to be done to our new directory is to set the
appropriate permissions. Since all action on behalf of our TFTP server is done
through the new "tftpd" user, at the very least this account with need read,
write and execute permissions for our chroot location and its subdirectories.
% mkdir /usr/local/tftp
% mkdir /usr/local/tftp/archives
% chown -R tftpd /usr/local/tftp
Probably the biggest misconception made with regards to TFTP is how writing
files to the server is handled. By default, TFTP expects the file to already
exist on the server. This means that in order for our remote device to write a
file to the server called "device.confg", it must exist in our chroot
directory as writeable by our "tftpd" user. At times this causes a great deal
of frustration and inconvenience for administrators needing to write files to
their TFTP server in a spontaneous situation. Once again TFTP allows us to
use a flag option to override this default.
Now that we have covered the majority of options available to the TFTP daemon,
we can see just how they are implemented. Each flag must be specified within
our inetd.conf or xinetd tftp configuration file. In short, they can be
summarized as "-u" to specify our "tftpd" username, "-s" to specify our
chrooted environment and "-c" to allow the server to create files on its own.
In our production INETD file, our configuration would appear as:
tftp dgram udp wait root /usr/sbin/tcpd in.tftpd -c -u tftpd -s
/usr/local/tftp
While in our XINETD config, the same flags can be specified in the following
manner:
service tftp
{
socket_type = dgram
protocol = udp
wait = yes
user = root
server = /usr/sbin/in.tftpd
server_args = -c -u tftpd -s /usr/local/tftp
disable = no
}
Hopefully, this brief discussion on TFTP brings a bit more clarity to the
subject of how to configure and use the service in an effective manner. A
basic review of all the options available to the daemon can be found through
"man tftpd".
If for any reason, you find incorrect information within this documentation,
please let me know immediately!
|
|