Cisco TFTP port security question

Soldato
Joined
18 May 2010
Posts
23,563
Location
London
Initially posted this in the Lionux forum, but it's probably more suited here as it's related to the Cisco ASA.

Just thought I'd post this to see if anyone else has encountered what must be a very common issue when using TFTP.

I've been configuring a new Satellite 6 server at work and getting close to the end.

But I have hit a snag (another one of many).

In our testing environment just to get things moving we opened up all the ports on the Cisco firewall for testing.

In our production environment we obviously cant do this. I've looked at the RHEL Satellite documentation as to what ports should be open and am fairly confident that is fine.

However when we come to TFTP boot a bare metal host it is timing out. It is picking up a DHCP lease I can see the connection arriving on the Satellite but the return connection is being dropped presumably by the firewall.

But the crux of the issue is as far as I read on the internet TFTP as part of it's protocol opens up random ports to communicate over.

The issue is when I try to PXE boot, it gets it's IP information then moves on to TFTP....... and just times out. What we are seeing in the logs is the TFTP connection is opening up random ports each time we initiate a connection. Usually in the 5000 port range.

These random ports will not be open on our firewall.

According to what I read on the internet this is normal in the TFTP protocol. We have TFTP working in our test subnet as we opened up the firewall, but in our production subnet we cant open up all UDP ports just to get TFTP to work.

Articles I have consulted on this issue which confirm TFTP uses random ports as part of it's protocol: http://www.winagents.com/en/solutions/tftp-over-firewall.php
https://supportforums.cisco.com/t5/lan-switching-and-routing/acl-for-tftp-traffic/td-p/1471189
https://community.sophos.com/produc...nat-qos-ips/36481/need-a-tftp-rule-that-works

Any one know what the common way to enable and keep secure TFTP? Cant just blanket open all UDP ports.
 
It's opening up the random ports on the inside interface? Or are you seeing them on the outside interface being blocked on the way in?

Which ASA and IOS version?
 
Sorry guys. I think the firewalling rules are dependant on what the Linuxing is doing.

Issue I have is Red Hat are being very slow in telling me what ports the TFTP protocol they have specified in the Satellite is using.

The TFTP protocol uses what is called ephemeral ports.

cat /proc/sys/net/ipv4/ip_local_port_range

32768 60999

On our older exiting cobbler server with TFTP installed in the xinetd configuration for tftp the port range has been specified with a flag -R 5000:5020

I tried to add this flag on the Satellites tftp config but it doesn't seem to have much affect.

So really until I know the port range there isn't much I can do.

---

I've just found this. But I need a way of making the port range much smaller than opening up 65k UDP ports.

Additionally tho ^ is incorrect. As our existing TFTP server has a range flag set so it's possible.

---

I don't think this is a networking question any more should probably go in the Linux section again.
 
Last edited:
Either I'm confused, or you are.

Forgive me if I am teaching you to suck eggs here.

A client makes a TFTP request to a TFTP server on UDP port 69. The outgoing connection from the client won't be on 69, it will be on a random port in the ephemeral range. You can test this by opening a web browser session and going to a website. The source port on your client will be 49782 for example.

If the client is on the inside interface of the firewall, then no rules need to be put in place, providing the ASA has been set up correctly (I'm specifically thinking the security levels in this case). See here for an overview:
https://www.shilpasys.com/articles/what-are-cisco-asa-firewall-security-levels/

If the TFTP server is on the inside interface of the firewall and has a lower security level than the outside (which it should), then you need to allow an incoming rule on UDP port 69. The response from the server will be on some random port such as 32768, but this doesn't matter, because it's on the inside.

As above, maybe I'm missing something obvious here?
 
Last edited:
Either I'm confused, or you are.

Forgive me if I am teaching you to suck eggs here.

A client makes a TFTP request to a TFTP server on UDP port 69. The outgoing connection from the client won't be on 69, it will be on a random port in the ephemeral range. You can test this by opening a web browser session and going to a website. The source port on your client will be 49782 for example.

If the client is on the inside interface of the firewall, then no rules need to be put in place, providing the ASA has been set up correctly (I'm specifically thinking the security levels in this case). See here for an overview:
https://www.shilpasys.com/articles/what-are-cisco-asa-firewall-security-levels/

If the TFTP server is on the inside interface of the firewall and has a lower security level than the outside (which it should), then you need to allow an incoming rule on UDP port 69. The response from the server will be on some random port such as 32768, but this doesn't matter, because it's on the inside.

As above, maybe I'm missing something obvious here?

I think I'm the one whose confused. :D

The Cisco isn't my forte and the other engineer who knows these stuff has been away all week.

I'll show him this and see what he has to say.

The thing that confuses us both is the existing system (using an old soon to be retired tftp server) in the /etc/xinetd.d/tftp file there is a switch that is clearly specifying a port range -R 5000 5020.

We can clearly see this range is open on the Cisco. But... On the satellite server there is no such switch in the /etc/xinetd.d/tftp file and the ports seem random some in the 4000 range others in the 5000 range.

I tried adding the -R 5000 5020 switch to match the old tftp but it didn't seem to have an effect.

What we need is a clever way of dealing with this where we don't have to explicitly specify the ports. the big issue we have is this is meant to be a secure network so we cannot open up more ports than we really need to.

Like I said I'll show him what you posted above.
 
Last edited:
I think I'm the one whose confused. :D

The Cisco isn't my forte and the other engineer who knows these stuff has been away all week.

I'll show him this and see what he has to say.

The thing that confuses us both is the existing system (using an old soon to be retired tftp server) in the /etc/xinetd.d/tftp file there is a switch that is clearly specifying a port range -R 5000 5020.

We can clearly see this range is open on the Cisco. But... On the satellite server there is no such switch in the /etc/xinetd.d/tftp file and the ports seem random some in the 4000 range others in the 5000 range.

I tried adding the -R 5000 5020 switch to match the old tftp but it didn't seem to have an effect.

What we need is a clever way of dealing with this where we don't have to explicitly specify the ports. the big issue we have is this is meant to be a secure network so we cannot open up more ports than we really need to.

Like I said I'll show him what you posted above.

I do a bit of Linux, but it isn't my strong point. I would have thought whatever specified in the /etc/xinetd.d/tftp file is the port the server listens on? What's the specific content of the file that refers to those posts? You can change the port services listen on, for example you could change SSH to 5222 if you wanted, that may be the case with the specific TFTP software you're running.

I assume your setup is as follows:

Client > Public Internet > ASA > TFTP Server?

If so, the ASA should have security level 0 on its outside (internet facing) interface and level 100 on inside (depending on configuration, it could be any number, as long as it is higher than the outside interface.

There are numerous guides online about setting up basic configuration both in ASDM and command line for various common uses.

A final thought is that if you are running a secure network, and connecting to a TFTP server from the internet, I would put the server in a DMZ.
 
Last edited:
I do a bit of Linux, but it isn't my strong point. I would have thought whatever specified in the /etc/xinetd.d/tftp file is the port the server listens on? What's the specific content of the file that refers to those posts? You can change the port services listen on, for example you could change SSH to 5222 if you wanted, that may be the case with the specific TFTP software you're running.

I assume your setup is as follows:

Client > Public Internet > ASA > TFTP Server?

If so, the ASA should have security level 0 on its outside (internet facing) interface and level 100 on inside (depending on configuration, it could be any number, as long as it is higher than the outside interface.

There are numerous guides online about setting up basic configuration both in ASDM and command line for various common uses.

A final thought is that if you are running a secure network, and connecting to a TFTP server from the internet, I would put the server in a DMZ.

It's not internet facing. This is for the local LAN. The Satellite 6 server is for provision new hosts using DHCP/TFTP/DNS.

Changing the ports that TFTP uses wouldn't do anything as the protocol uses random ports during it's negotiation.

Lifted from here:

Here is what TFTP does:



The client selects a random source port, A, and sends the request as:

req (A,69)

The server then selects a random destination port, B, and sends the reply as:

rep(B,A)

To this the client then sends to:

(A,B)

Our existing TFTP server has this in it's config file (port 69 is a given):

server_args = -B 1380 -v -s /var/lib/tftpboot -R 55735:55744

And we have clearly verified there are ports 55735:55744 already open in our fw.

The new TFTP doesn't have any port range specified (other than port 69)

A PXE request is going from our client to the satellite the satellite is then initiating a TFTP connection, we can see the Read Request on the server but the return packets never reaches the client.

I tried adding the same -R 55735:55744 flags to the new server but it didn't have any affect.
 
Back
Top Bottom