Linux Server Security: Hack and Defend by Chris Binnie Make Your Servers Invisible!

I'm delighted to be able to offer the first chapter of my new security book, Linux Server Security: Hack and Defend, for free as a downloadable PDF. Chapter One, entitled Invisibility Cloak, walks you through making your servers invisible online to the extent that not only can you successfully hide your services but even your servers themselves aren't discoverable on the network.


Despite removing the most common attack vectors you might be surprised to discover that you can still access your servers over the Linux® command line remotely and continue to run key production services. The chapter walks you through, step by step, the obfuscation of your servers so that their attack surfaces are significantly reduced and they are less prone to attacks. Click the link below to download the free PDF.



Linux Server Security: Hack and Defend by Chris Binnie

Learn how to attack and defend the world’s most popular web server platform


Linux Server Security: Hack and Defend presents a detailed guide for experienced admins, aspiring hackers and other IT professionals seeking a more advanced understanding of Linux security. Written by a 20-year veteran of Linux server deployment this book provides the insight of experience along with highly practical instruction.


The topics range from the theory of past, current, and future attacks, to the mitigation of a variety of online attacks, all the way to empowering you to perform numerous malicious attacks yourself (in the hope that you will learn how to defend against them). By increasing your understanding of a hacker’s tools and mindset you're less likely to be confronted by the all-too-common reality faced by many admins these days: someone else has control of your systems.

The techniques presented apply to almost all Linux distributions including the many Debian and Red Hat derivatives and some other Unix-type systems. Further your career with this intriguing, deeply insightful, must-have technical book. Diverse, broadly-applicable and hands-on practical, Linux Server Security: Hack and Defend is an essential resource which will sit proudly on any techie's bookshelf.


Download: Linux Server Security: Hack and Defend by Chris Binnie - Chapter One - Invisibility Cloak


©2016 Chris Binnie - please do not copy content without permission.

Linux® is the registered trademark of Linus Torvalds in the U.S. and other countries.

Click for DevSecOps articles and free Linux tutorials on DevSecOps.cc


Trivial Transfers

©2016 Chris Binnie

Sometimes we find ourselves using technologies which we may not realise back almost all the way back to the birth of the Internet. I was using TFTP (Trivial File Transfer Protocol) the other day and looked up it’s RFC (Request For Comments) only to discover that it’s been around for a while longer than I had suspected, to June 1981 (https://tools.ietf.org/html/rfc783). That may not be the 1970s but FTP (File Transfer Protocol) and TFTP are certainly founding protocols of sorts.

In an unusual twist TFTP doesn’t use the now almost-mandatory TCP (Transmission Control Protocol) for moving its data around. TCP offers resilience through error recovery but instead TFTP uses UDP (the User Data Protocol) presumably because of the “trivial” nature of its file transfers.

The feature set included with TFTP is admittedly quite limited but make no mistake it can still be very useful on a Local Area Network. Unlike the well-known FTP service which is commonly used for moving files back and forth across the Internet (and includes successors with encryption, amongst its family members, such as sFTP and FTPS) TFTP doesn’t even allow the listing of directories so you can see which files are available. If you want to use TFTP you need to be aware of the filenames, which are sometimes complex and lengthy to provide a small dose of security through obscurity, before connecting to a server.

Other somewhat surprising limitations, relative to its cousin FTP, include a lack of authentication and the ability to delete or rename files.

There may have been improvements since its original design admittedly but its RFC also states that, in essence (barring incorrect port numbers amongst others), the only errors which it can pick up are complaining if the wrong user is specified, if a file that’s requested doesn’t exist and other access violations.

Now that you’re firmly sold on using this somewhat-deprecated protocol let’s have a think about what it might be used for.

If you’re creating new machines from images then TFTP is perfect for bootstrapping a new server with predefined config and a sprinkling of packages. It might also be used during boot time to pull the latest version of a file from a local server so that all clients are guaranteed to be up-to-date with a certain software package.

There are other reasons to continue to use TFTP, as several vendors do, for firmware updates. Why choose TFTP above FTP or even HTTP you may ask? Simply because even if you don’t have a TFTP Server already up and running it’s relatively easy to quickly get started. Also the number of parameters required to retrieve a file (and therefore the number of things that can go wrong) is very limited. It tends to work or it doesn’t; there’s little middle ground. It’s functional simplicity is a bonus I’m sure you’ll agree.

If you’ve ever maintained switches or routers then you’ll probably have used TFTP to either backup or restore config files or possibly perform a firmware upgrade. Many of the major vendors still prefer this method, possibly because there’s a feeling of comfort (in relation to security) when moving files around inside a LAN relative to doing so across the Internet.

On a network device for example you might encounter a transaction similar to that seen in Listing One:

Router# copy running-config tftp:


Address or name of remote host []? 10.10.10.10


Destination filename [router_config_backup_v1]? router_config_backup_v1
!!!!
3151 bytes copied in 1.21 secs (2,604 bytes/sec)

Router#

Listing One: The type of transaction that you may see when backing up a network device’s config via TFTP

As you can see in Listing One the exclamation marks provide a progress bar of sorts and each one acts as an indicator that a successful transfer of ten packets.

Installation

Let’s look at how to get a TFTP server up and running.

In the olden days “inetd” ruled the roost and was responsible for letting many local services out onto the network so that they could communicate with other users and machines. On the majority of systems which I used, thanks to security limitations, “inetd” then ultimately became “xinetd” which also closed down more unneeded services by default. Thankfully however we can avoid also installing “xinetd” which was the norm until a few years ago but instead solely focus on the package “tftpd”.

On Debian derivatives it’s a simple as running this to install that package:

# apt-get install tftpd

As we can see in Figure One “inetd” is indeed mentioned as a supplementary package but this is of little consequence in terms of the filesystem footprint remaining minuscule.

Linux Server Security

Figure One: Installing the “tftpd” package on Debian systems

Trilbys and Fedoras

On Red Hat derivatives there’s a few other considerations. You can use an alternative package with similar relative ease but opt into using the more advanced “xinetd” by running a command such as this one:

# yum install tftp-server xinetd

This pulls down the more sophisticated replacement for “inetd” and “tftp-server”. Incidentally the “tftpd-hpa” is pulled down on Debian systems if you try and install “tftp-server” and you would edit the file “/etc/default/tftpd-hpa” to config your service. Look for the Debian-specific “README” to allow file uploads too.

Back to Red Hat. The description for the “tftp-server” packages is as follows, echoing what we’ve said until now:

“The Trivial File Transfer Protocol (TFTP) is normally used only for booting diskless workstations. The tftp-server package provides the server for TFTP, which allows users to transfer files to and from a remote machine. TFTP provides very little security, and should not be enabled unless it is expressly needed. The TFTP server is run from /etc/xinetd.d/tftp, and is disabled by default.”

If you haven’t used “xinetd” before it uses individual config files per service. For example inside the file “/etc/xinetd.d/tftp” you need to make a couple of small changes in order to get started. Have a look at Listing Two.

service tftp

{

socket_type  = dgram

protocol                = udp

wait                = yes

user                = root

server                = /usr/sbin/in.tftpd

server_args    = -s /tftp_server_directory

disable                = yes

per_source    = 11

cps                = 100 2

flags                = IPv4

}

Listing Two: A sample “xinetd” config for a TFTP service

As we can see in Listing Two we will need to change the “disable” setting to “no” if we want this service to start. Additionally we might need to alter the “server_args” option away from “-s /tftp_server_directory” if we want to serve files from another directory. If you want to allow file uploads then simply add a “-c” option before the aforementioned “-s” on that line.

Debbie And Ian

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 (you can view it 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.

Unlike above 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) as follows:

# 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 Three:

# 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 Three: Our (abbreviated) main config file for “inetd” under which tftpd runs.

The first entry (on the first line) which we should pay attention to in Listing Three 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 also 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

We can see, repeated again, in Listing Three that, as we’ve mentioned, 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 examples to reflect changes in NTP Servers, or other widely used services.

The eagle-eyed amongst you might have also 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 if you haven’t used them allow us to control the IP Address ranges or Domain Names which can connect to any service which 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 piece of had been configured to use the functionality provided by TCP Wrappers then 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 then 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 file “/etc/hosts.deny” and add the following line:

tftpd: ALL

Then inside the file “/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 we can tell if “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

Low and behold there is a service listening intently already, without any prompting straight after our installation, as we can see. Take that as a warning to secure your access immediately or of course stop the service straight after the installation if you can’t spend time securing the service as soon as it is installed.

Let’s try and move some files around now. You can do this with some comfort now that we know how to secure our 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 as so:

# 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. We connect like this to the server from the client:

# tftp 10.10.10.10

Now we’re connected (if it didn’t work check your firewalling or you might “telnet” to port 69 on your TFTP’s Server IP Address) then we 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 to keep me right 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 in our main config file above “/etc/inetd.conf”. That directory which our faithful daemon is serving from is called “/srv/tftp” as we can see in Listing Three.

Since 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 us the “verbose” output when that mode is enabled. You can glean useful information such as that we’re not using binary mode but instead just “netascii” mode. Additionally we 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 like so with your client software:

# 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 then there’s a couple of 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 I’m sure that we can adjust timeouts. Firstly 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 ten seconds.

In order to set the total-transfer timeout, for the entire transaction, then adjust this setting as so:

tftp> timeout 30

Another useful tool for debugging is the “trace” functionality. It can be enabled as follows:

tftp> trace
Packet tracing on.

Then each transfer that you wish to run will look very noisy, as below, hopefully helping 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 hopefully discern a pattern if it happens repeatedly.

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 would recommend that you either lock down your server so it can only be accessed by a few machines by using IPtables or TCP Wrappers. Whilst it’s an older technology there’s no doubt that TFTP is 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 in order 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 hopefully 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 indeed take your life into your own hands and try and server TFTP across the Internet one word of warning, well one acronym actually, would be “NAT”. If Network Address Translation is involved in remote connections then you may struggle with TFTP transfers thanks to the fact 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 (https://www.pfsense.org) 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 which can be used in a fast and effective manner with little config being required.

At other times admittedly TFTP won’t quite cut the mustard however. 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 in fact present within TFTP’s toolkit. You might be pleasantly surprised at what you might find. After all many of the tools that we use on a daily basis on today’s internet heralded from the time whence TFTP came.

Linux Servers and Security Howtos - Chris Binnie - Linux Server Tutorial

Linux Server Security: Hack and Defend by Chris Binnie Make Your Servers Invisible!

I'm delighted to be able to offer the first chapter of my new security book, Linux Server Security: Hack and Defend, for free as a downloadable PDF. Chapter One, entitled Invisibility Cloak, walks you through making your servers invisible online to the extent that not only can you successfully hide your services but even your servers themselves aren't discoverable on the network.


Despite removing the most common attack vectors you might be surprised to discover that you can still access your servers over the Linux® command line remotely and continue to run key production services. The chapter walks you through, step by step, the obfuscation of your servers so that their attack surfaces are significantly reduced and they are less prone to attacks. Click the link below to download the free PDF.



Linux Server Security: Hack and Defend by Chris Binnie

Learn how to attack and defend the world’s most popular web server platform


Linux Server Security: Hack and Defend presents a detailed guide for experienced admins, aspiring hackers and other IT professionals seeking a more advanced understanding of Linux security. Written by a 20-year veteran of Linux server deployment this book provides the insight of experience along with highly practical instruction.


The topics range from the theory of past, current, and future attacks, to the mitigation of a variety of online attacks, all the way to empowering you to perform numerous malicious attacks yourself (in the hope that you will learn how to defend against them). By increasing your understanding of a hacker’s tools and mindset you're less likely to be confronted by the all-too-common reality faced by many admins these days: someone else has control of your systems.

The techniques presented apply to almost all Linux distributions including the many Debian and Red Hat derivatives and some other Unix-type systems. Further your career with this intriguing, deeply insightful, must-have technical book. Diverse, broadly-applicable and hands-on practical, Linux Server Security: Hack and Defend is an essential resource which will sit proudly on any techie's bookshelf.


Download: Linux Server Security: Hack and Defend by Chris Binnie - Chapter One - Invisibility Cloak


©2016 Chris Binnie - please do not copy content without permission.

Linux® is the registered trademark of Linus Torvalds in the U.S. and other countries.

Click for DevSecOps articles and free Linux tutorials on DevSecOps.cc