VanDyke Software

Tips

Index

How to Use SecureCRT's Built-In TFTP Server

SecureCRT includes a built-in TFTP server that can be used as a file transfer target/source for a TFTP client on another device. The device where the TFTP client is running must have a network path to the machine where SecureCRT is running (UDP, port 69).

Starting and Stopping the TFTP Server

To manually start or stop the TFTP server in SecureCRT, open the Transfer menu and select the Start TFTP Server menu item. If the TFTP server is already running, the label of the menu item will display Stop TFTP Server.

Screenshot showing the Transfer menu with Start TFTP Server selected

Additionally, SecureCRT's TFTP server can be configured to start automatically in SecureCRT's Global Options / Terminal / TFTP Server category.

To automatically start the TFTP server when the SecureCRT application is launched, enable the Start TFTP server when option and then select the SecureCRT starts option.

To automatically start the TFTP server whenever any session is used to make a connection, enable Start TFTP server when option and then select Any session connects.

Screenshot showing the Global Options/TFTP Server/Start TFTP Server When dialog

Note: Regardless of the mechanism used to start the TFTP server, the TFTP server will remain running until either:

  • The Stop TFTP Server menu item is selected from SecureCRT's Transfer menu, or
  • The instance of SecureCRT.exe that started the TFTP server is terminated.

Note for SecureCRT on macOS
SecureCRT on the macOS platform installs a binding helper to allow the TFTP server to bind to port 69, which is "privileged" in macOS. If SecureCRT is not installed properly, SecureCRT's TFTP binding helper may not be able to successfully bind to port 69. To correctly install SecureCRT, open the DMG and drag the SecureCRT application from the DMG to the Applications folder in the Finder app on your Mac. Always launch the SecureCRT app directly from the Applications folder, rather than launching SecureCRT directly from the mounted DMG.

Note for SecureCRT on Ubuntu
On Ubuntu platforms, SecureCRT won't be able to bind to port 69 by default. This is because Ubuntu considers all ports below 1024 to be "privileged", and individuals won't typically be running SecureCRT as the root user. Because of this, if you try to start the TFTP server in SecureCRT on Ubuntu, you'll see the following error message:

Screenshot of error message, The TFTP server coud not bind to port 69 for the following reason: Permission denied

To configure Ubuntu to allow SecureCRT to listen on a privileged port (such as the TFTP port, 69):

  1. Open a Local Shell connection in SecureCRT or use the native terminal app on your Ubuntu machine to run the following command:
    sudo setcap 'cap_net_bind_service=+ep' `which SecureCRT`
  2. Close and restart the SecureCRT application.


Which Network Interface Does SecureCRT's TFTP Server Use?

When the TFTP server is started, SecureCRT's status bar will report, "TFTP server is ready," and will include in parenthesis the first non-loopback network interface provided by the operating system on which SecureCRT is running.

Note: Because of limited space available in the status bar, only the first non-loopback network interface is displayed. However, the TFTP server will listen on all available network interfaces on the machine where SecureCRT is running. This can be verified by opening a local shell console and running the command appropriate for the operating system on which SecureCRT is running. For example:

Windows

Powershell:

gps -ID (Get-NetUDPEndpoint -LocalPort 69).OwningProcess | ft -Property ProcessName,Id,Path

CMD:

netstat -an | findstr ":69"

macOS

lsof -i UDP | grep -E ":69|tftp"

Ubuntu

sudo lsof -i UDP | grep -E ":69|tftp"

If you don't know the IP addresses of the network interfaces available on your machine where you're running SecureCRT, the following commands may be helpful when run in a Local Shell connection in SecureCRT:

Windows

Powershell:

gip | ? {$_.NetAdapter.Status -ne "Disconnected"} | ft -Property IPv4Address,InterfaceAlias

CMD:

ipconfig /all | findstr "IPv4"

macOS

ifconfig | grep -o -E "inet \S+"

Ubuntu

ip a | grep -o -E "inet\s+[^/]+"

Security Considerations

TFTP stands for the "Trivial File Transfer Protocol" and it is trivial, indeed. The TFTP protocol does not provide any user authentication, access control, or encryption between the TFTP client and the TFTP server.

To help mitigate the inherent lack of security associated with the TFTP protocol, SecureCRT provides the following features:

  • Separate "Upload to" and "Download from" folders
    Separate Upload to and Download from folders "sandbox" where TFTP clients can write versus read. The Upload to folder is the folder location to which TFTP clients may upload (write) files. The Download from folder is the folder location from which a TFTP client may download (read) a specified file.


    Best Practices:
    • Use separate directory locations for the Upload to and Download from options.
    • Specify a folder which you create specifically for the purpose of TFTP transfers. This narrows the scope of access available to any would-be attackers seeking to leverage the TFTP protocol as their attack vector.
    • Do not store any files in the Download from folder that are not intended to be made available for download by TFTP clients. In other words, don't use your personal Documents folder as the Download from location. Instead, consider specifying a subfolder you create specifically for the purpose of storing files you want to make available for TFTP clients to download.
    • Intentionally treat all files in the Upload to folder as suspect. Since there is no authentication or access control with the TFTP server, this best practice helps guard against an attacker secretly uploading a nefarious payload, hoping some day you'll activate it somehow.
  • Option to only allow connections from IP addresses of open terminal sessions
    When enabled, this option rejects all TFTP client connections which do not originate from the same IP address to which SecureCRT currently has an open terminal connection.


    Best Practice:

    Enable the Only allow connections from IP addresses of open terminal sessions. Disable this option only if you're unable to control which network interface your TFTP client uses to attempt to establish the TFTP connection, and the TFTP client attempt times out.

    Note: If a TFTP client connection is attempted from an IP address which does not match the IP addresses of any open terminal sessions in SecureCRT, the TFTP log file (if enabled) will display an error message. For example, "Request received from invalid IP address: nnn.nnn.nnn.nnn."
  • Option to allow overwrite of existing files
    When enabled, this option allows a TFTP upload operation to overwrite existing files in the Upload to folder location. This option is disabled by default for security reasons (since any TFTP client could upload a file and end up overwriting a valid file with invalid/nefarious data).


    Best Practice:

    Enable the Allow overwrite of existing files option only if (a) you have enabled the Only allow connections from IP addresses of open terminal sessions option, or (b) you are operating SecureCRT within a secured network environment where you are certain that no TFTP attacks are possible.

Troubleshooting the TFTP Server

  1. First, determine if the TFTP server is listening on the specified port. The command examples listed above in the Which network interface does SecureCRT's TFTP server use? section should be sufficient in most cases to determine if the TFTP server is actually listening. Additionally, you can enable the Log File setting in the TFTP Server category of SecureCRT's Global Options.


    If the Log File path is configured, the specified log file will reveal when SecureCRT's TFTP server stops/starts. For example:
  2. Make sure that the device where the TFTP client is operating has a network path to the machine where SecureCRT is running. If SecureCRT's TFTP server has been started, you've initiated a TFTP client operation, and there aren't any additional lines logged in SecureCRT's TFTP server log file before the TFTP client times out, it means that you likely have a network connectivity problem to resolve.
    • Make sure the device on which you're running the TFTP client is connected to a network which can reach the machine on which SecureCRT is running.
    • Make sure you have configured the TFTP client to connect to the correct network interface of the machine on which SecureCRT is running. See the "Which network interface does SecureCRT's TFTP server use?" section earlier in this tip for additional information.
    • Make sure that you don't have any hardware firewall configurations blocking UDP port 69 from reaching the machine on which SecureCRT is running.
    • Make sure that the machine on which SecureCRT is running does not have any software firewall configurations blocking UDP port 69 from reaching SecureCRT's TFTP server.
  3. Inspect the TFTP server log (if a Log File path is configured in SecureCRT's Global Options / Terminal / TFTP Server category, as mentioned earlier in this section).
  4. Another step in troubleshooting would be to employ network sniffing tools like Wireshark to inspect traffic between the TFTP client and the machine on which you're running SecureCRT. If you see an incoming UDP packet from the TFTP client machine, but you don't see a corresponding line in the TFTP server log file with the pattern of, "A request with an opcode of n was received by server", then it could mean:
    • a firewall may be blocking connectivity.
    • SecureCRT's TFTP sever may not have been started;
    • SecureCRT's TFTP server port may not be configured to the same port the TFTP client is trying to connect to.

VanDyke Software uses cookies to give you the best online experience. Before continuing to use this site, please confirm that you agree to our use of cookies. Please see our Cookie Usage for details.