Re: Still no TFTP client?

Bill Gunshannon wrote:
In article <462c852a@xxxxxxxxxxxx>,
Mark Berryman <mark@xxxxxxxxxxxxxxxx> writes:
Bill Gunshannon wrote:
[some text deleted]
Other than through security by obscurity (ie. if I don't tell you
I am running a tftp server you probably won't find it) how would
you secure tftp? There's a reason why they call it "trivial". :-)
Using the Multinet TFTP server:

1. It only serves out the directory tree you specifically define for it (a major issue with most Unix implementations).
How so? I have never seen any tftp server on any Unix system that served
up anything but the directory tree you set.
Then you are somewhat limited in your experience. I have definitely seen this many times and I expect you could find examples with a simple web search. Granted, sometimes the issue was caused by a simple typo in the configuration file (a typo that simple shouldn't open up your whole system but that is a different issue).

"A typo in a configuration file" is not a Unix problem. Or are you
saying that if someone makes a typo in a VMS configuration file it
could not cause a similar problem?

Actually, in this case, I am. There is absolutely no way to grant access to the entire file system in VMS to the TFTP server without explicitly and deliberately doing so. Making a simple typo in the template configuration file wouldn't come close to doing it.

However, there are other times that this is caused by this being the default configuration.

The oldest version of tftpd that I have handy at the moment is Ultrix-11.
There is no default directory. So somehow I think this was not really
the problem. Sounds a lot more like another case of "incompetent sysadmin
syndrome" which would affect any OS.

You are making guesses. I am speaking from experience. You are, of course, free to simply disbelieve me.

2. It can only read those files with World Read access.
Probably because with no authentication there is no user or group. Duh...
Hardly. NOTHING runs on VMS without an associated UIC. The server simply enforces this documented restriction. Without world read access, the TFTP server will not touch the file.

Well, of course it does. As does the Unix equivalent. But in neither case
does that UIC/uid identify the person on the other end of the client. Thus
the reason for WORLD access. At least they try to add some security to it,
even if not much.

3. It will only write to a file that already exists and has World Write access.
Which means either you can't write the files either or anyone can. One
way is non-functional and the other a security hole.
Again, hardly. You are assuming that the file must always be there and always be world writable. Such is not the case. In one application I have it works as follows:

1. Application creates necessary file.
2. Application sends SNMP command to network device telling it to write its config to this file name.
3. Application waits for the TFTP operation to complete (via SNMP query) then copies configuration to config directory.

But that's not TFTP. That's some application that just happens to use
TFTP to move files. Obviously trying to get create security where even
they admit it doesn't exist. Of course, you could use real FTP and not
have to Rube Goldberg a system. Seems like a strange use for SNMP as
well. Would have made much more sense to just write your own client/
server application to do the job right.

You are obviously unfamiliar with network management where almost everything is done via SNMP. You also seem to think that TFTP is mainly used for static files. Quite obviously I am using TFTP and, equally obviously, doing so is not the absolute security failure you claim that it is. Also, simply because you do not understand something does not make that something a Rube Goldberg implementation.

As for using FTP, can you name any commonly used router or switch to which you can initiate an FTP session? I can't. If fact, no router or switch fit for the enterprise environment will allow you to initiate *any* sort of session other than an interactive mangement console (which is sometimes HTTP based). The transfer of firmware, configuration, etc. from the router must be initiated by the router. How do you tell the router to do that? You can log in interactively or you can send an SNMP command. Guess which is more secure and less error-prone?

Think of having to know the name of the file being used here as being the same as having to know the password to write to this account.

Not a security model I would subscribe to, thank you.


4. Limit the server to respond only to a defined set of hosts or subnets (functionality built into the Multinet equivalent of inetd).
Well, that's one plus, but what about spoofing?

Can't be done. All of our routers are properly configured to prevent spoofing and our network devices use addresses that are not legitimate for a host (and, thus, are blocked by the anti-spoofing settings).

So, again, you are using something else to make up for the security
shortcomings of TFTP. A much better idea is don't use TFTP. :-)
But then, if you have a machine on your network that can comunicate
with the TFTP server another machine on your network can spoof that
address. Oh, I see, you trust everybody on "the secure side" of the
firewall. :-)

Again you show you do not comprehend the description. Unfortunately, I am not sure I can explain any clearer. To illustrate, your statement "if you have a machine on your network that can comunicate with the TFTP server another machine on your network can spoof that address" is just plain flat out wrong. Let me try a specific example:

I have a network device that communicates with the TFTP server using the address 192.168.101.5 (it is the address of its loopback interface). There is no LAN anywhere on the network using the 192.168.101.x/24 address space. Any host trying to emit an IP packet with a source address of 192.168.101.anything would find that the packet never left the LAN. It would be dropped by the first layer 3 device it encountered. It would also be dropped by every other layer 3 device it passed through on its way to the TFTP server. This is not a "secure side of the firewall". This is a network of routers properly configured for anti-spoofing.

In some situations, due to the nature of the environment, the relationship between MAC address and IP address is statically entered into the local router and switches and ARP packets cannot overwrite these entries. Hosts on such LANs can't even spoof an address within the LAN, much less one across the network.

This is just a long-winded way of saying that, yes, there are environments where the limitations of TFTP are not an issue.

All the additional security measures you can add will never equal up
to just not using known, published, unsecure methods.

You mentioned FTP. It is no more secure than TFTP is (i.e. the work involved in hacking an FTP server is no more difficult than that involved in hacking a TFTP server). Encrypted protocols are more secure. Sadly, not everything supports them yet and we still have to manage the network.

5. Log all connections, both successful and rejected.
Trying to lock the barndoor after the horse has run away.
Hmm, are you trying to claim that security audits are useless? The log files prove the fact that only legitimate TFTP requests are being honored and we know when bogus TFTP transactions are being attempted and we know where they are coming from and we know that they have been successfully deterred.

No, not worthless, but as I said in another post, reactive. It's much
better to not give them a door to come in than to read the sign in ***
after tha fact and know that someone did get in.

Do you have systems that you allow people to log onto? Better close that door. Really. I can protect the files available to the TFTP server at least as well as the files you have on systems that people can log onto and they are probably less sensitive than the files you'd be worried about as well.

We have hundreds of network infrastructure devices on our network that share only TFTP as the common download/upload protocol
See above. If you can upload, so can anybody. How do you guarantee
the integritry of the files? Do you use this for your configs? Might
as well put them up on the local bulletinboard at the mall.
See above. I can upload, but "anybody" can't. I gave one example of why this is so. There are others.

Well, yes, but as I said, your example isn't TFTP.

Well, it is (no it isn't, yes it is, no it isn't, yes it is, ...)

It is an application
that tries to wrap security around a broken protocol. If someone had to
write the application in the first place they should have done it right
and not used TFTP (or SNMP) at all. CLient/Server IP apps are not all
that hard to write. Our students do it all the time.

So do I. Too bad neither routers nor switches support them. SNMP *is* the right protocol to communicate with network devices and TFTP is still the only common transfer protocol.

(although newer devices do add support other protocols we cannot swap the older one out just for that reason). We have supported out network devices with TFTP servers configured as above for many years without issue.
And many Unix systems ran happily for years without even passwords. But
I wouldn't try it today.
The two situations are not even close to corresponding. Among other things, a system without a password grants access to absolutely everything on that system or to what that system has access to. My TFTP server grants access to exactly what I have authorized it to and nothing else.

I only used that example as a sign of how social norms, especially in
the computing industry, have changed. There was a time, not all that
long ago, when we logged on in the morning and left our terminals run
all day long.

There was never a time when I did that and I've been doing this since 1975.

We didn't worry about someone getting into oufr stuff
while we were at lunch.

Please be careful about that "we" stuff. Protecting my account is something I was taught from day one.

But society changed. Back then I could count
on people not trying to hack into my machine via TFTP. But society changed.
Just like there being a time, not so long ago when people didn't even lock
their doors. But society changed.

Just to be pedantic it wasn't society that changed. It was commercializing the Internet that made the difference. Attempts to hack into computes have been around as long as computers have been able to talk to each other but the scope changed when the Internet went commercial.

Multinet also includes a TFTP client which I have used on occasion, mainly to test a newly configured TFTP server.

I'm gald things are working for you, but I wouldn't even consider
running a tftp server again.
Then I guess it is a good thing you are not in charge of a large network with a wide variety of network devices.

Well, knowing that any place other than this would likely have a real
budget, I would hope they would be able to understand the money spent
on better network devices was money well spent. But then, if security
isn't one of my bosses concerns, I do would do what he wants after
suitably warning him of the dangers.

*snort* I'm sorry, that one is a little hard to swallow. Companies the size of the one I work for typically have IT budgets that run into multiple millions of dollars, the line items of which must be identified a year or more in advance. Wholesale replacement of network gear simply does not happen in the real world, especially on this scale.

Face it, secure copy protocols are relatively new to the network world. It will take some time for them to become ubiquitous. Until they do, the existing protocols must continue to be used. In the case of TFTP, that means running it on a VMS server.

Mark Berryman
.

Loading