Home page logo
/
Intro Reference Guide Book Install Guide
Download Changelog Zenmap GUI Docs
Bug Reports OS Detection Propaganda Related Projects
In the Movies In the News

Sponsors


Nmap Network Scanning

File Transfer

There is no shortage of ways to transfer a file over a network. Most file transfers are ably handled by email, network file systems, HTTP, SFTP, or other protocols. What do you do, though, when that file is too big to email, the transfer is between two machines not connected to the Internet, or you just need to do one quick file transfer without having to set up and tear down a file server? In these and other situations Ncat can be the right tool for the job. Some tricky file transfer scenarios can really make you appreciate the flexibility of a raw network pipe.

As you know, Ncat by default sends all its traffic without encryption, so it is possible for someone to intercept files in transit. See the section called “SSL” for one method of encrypting traffic.

By default, Ncat doesn't close its connection until it is closed by the remote end, even after it has exhausted its input. That is because (as far as Ncat knows) the remote server may still have data to send back. The --send-only option, when applicable, changes this behavior to close the connection and quit at the end of input. This is normally what you want when doing a one-way file transfer.

A basic file transfer is very simple: Start Ncat in listen mode on one end, start Ncat in connect mode on the other end, and pipe the file over the connection. There are two ways to do this that differ only in which end listens, the sender or the receiver. Sometimes you can't create a listening socket on one end of the transfer because of a lack or permissions, NAT, or filtering. As long as you can listen on at least one end, though, you can use this technique.

These examples show how to transfer inputfile on host1 to outputfile on host2. Here no port number was specified so Ncat will use its default port of 31337. To use a different port just list it on the command line.

Transfer a file, receiver listens


host2$ ncat -l > outputfile
host1$ ncat --send-only host2 < inputfile

Transfer a file, sender listens


host1$ ncat -l --send-only < inputfile
host2$ ncat host1 > outputfile

Note the order of the commands. The listener must be started first, regardless of the direction of transfer, or else the client will not have anything to connect to.

The above technique works fine for sending a single file. One way to send multiple files is to bundle them up with tar or zip and send the archive file. But there's an even easier way. Just pipe the output of tar directly into Ncat on the sending side, and pipe Ncat's output into tar on the receiving side. This is especially useful when the sending computer doesn't have enough free disk space to hold the archive file. Here's how to transfer <files> using the receiver listens method, though of course the sender listens method works just as well.

Transfer a bundle of files


host2$ ncat -l | tar xzv
host1$ tar czv <files> | ncat --send-only host2

Not only tar files but any stream of bytes can be transferred in this way. Here is an example of transferring an entire disk image from host1 to host2. Naturally, the disk should be unmounted or mounted read-only.

Transfer a disk image


host2$ ncat -l > host1-hda.image
host1$ ncat --send-only host2 < /dev/hda

Disk images are typically large files that take a long time to transfer. You can compress the image on the fly while sending and decompress it on the other end. Whether this makes an improvement depends on the speed of the network and the compression program.

Transfer a disk image with compression


host2$ ncat -l | bzip2 -d > host1-hda.image
host1$ cat /dev/hda | bzip2 | ncat --send-only host2

The basic file transmission technique described at the beginning of this section fails if neither participating host is capable of listening, or the two hosts can't communicate directly. This situation has become common with the prevalence of network address translation. A way to work around it is to use a third host as an intermediary. The intermediate host listens in connection brokering mode and the other two hosts connect to it. Recall from the section called “Connection Brokering” that in connection brokering mode any input received on one socket is copied and sent out to all other sockets. With just two hosts connected this is especially simple: anything coming from one host gets forwarded to the other. This example shows host1 sending inputfile to outputfile on host2, using host3 as an intermediary.

Transfer a file through an intermediary


host3$ ncat -l --broker
host2$ ncat host3 > outputfile
host1$ ncat --send-only host3 < inputfile

Note that it's important for host2 (the receiving host) to connect to the broker before host1 (the sending host) does. The broker does not buffer received data to send to hosts that connect later. After the file is transferred, it is necessary to forcibly disconnect the Ncat on host2 with ctrl+C. The broker never disconnects any of its clients.

[ Nmap | Sec Tools | Mailing Lists | Site News | About/Contact | Advertising | Privacy ]
AlienVault