TCP/UDP ports

From wiki.zmanda.com
Jump to navigation Jump to search
Deprecated
This document only discusses the "bsd" auth; see amanda-auth(7) for a more complete description


Amanda uses both UDP and TCP ports during its operation. The amandad service is listening (via inetd/xinetd) at a well known (fixed) port on each client for UDP connections. The amindexd and amidxtaped services are listening (also via inetd/xinetd) at well known ports on the tape server for TCP connections.

When a process on the tape server wants to talk to a client, it creates a UDP socket and binds it to a port on its side, then sends the packet to the well known amandad service port on the client. Because security information is passed, the port bound on the connecting (tape server) side must be privileged (less than 1024). This "proves" to amandad whoever is connecting is running as root, and therefore is trustworthy (there are all sorts of issues with the validity of this "trust" that are beyond the scope of this document).

A similar sequence of events happens when amrecover on a client wants to contact amindexd or amidxtaped on the tape server. The port that amrecover binds to its TCP socket must be privileged, which is one of the reasons it must be run as root.

Amanda also uses TCP connections for transmitting the backup image, messages and (optionally) the index list from a client back to the dumper process on the tape server. A process called sendbackup is started by amandad on the client. It creates two (or three, if indexing is enabled) TCP sockets and sends their port numbers back to dumper in a UDP message. Then dumper creates and binds TCP sockets on its side and connects to the waiting sendbackup.

Because sendbackup does not run as root on the client, it cannot allocate privileged TCP ports to listen on. The dumper process is setuid root and could bind privileged ports on its side (it currently does not), but because sendbackup does not care what port connects back to it (it assumes the only process that could have knowledge of the port numbers to use is dumper), it does not check the peer (connecting) port number.


TCP port allocation

When Amanda creates a TCP server socket to listen for incoming connections (sendbackup), it goes through the following bind steps:

  • try for the user TCP port range (--with-tcpportrange), if defined. If that fails ...
  • try for a privileged port (512 .. 1023). If that fails ...
  • get any available port.

This sequence is implemented in stream_server().

When Amanda (dumper) creates an unprivileged TCP client socket to connect to a server, it goes through the following bind steps:

  • try for the user TCP port range (--with-tcpportrange), if defined. If that fails ...
  • get any available port.

This sequence is implemented in stream_client().

When Amanda (amrecover(8)) creates a privileged TCP client socket to connect to a server, it goes through the following bind step:

  • try for a privileged port (512 .. 1023). If that fails, the whole request is aborted.

This sequence is implemented in stream_client_privileged().

The stream_server() routine is used in two ways:

  • taper to set up direct to tape communication with dumper on localhost.

If a user TCP port range is defined, it needs to be unprivileged because taper is not running as root.

  • sendbackup to set up a transfer with its dumper.

If a user TCP port range (--with-tcpportrange) is defined, it needs to be unprivileged because sendbackup is not running as root.

A user TCP port range needs to be large enough for three ports (data, message and index) times the number of simultaneous backups the client may be asked to perform ("maxdumps" in amanda.conf).

The stream_client() routine is used in two ways:

  • dumper to connect to taper for a direct to tape operation. Except for making sure what is connecting is not (ftp) port 20 (a common attack entry point), taper does not pay any attention to the source ( dumper) port number.
  • dumper to connect to sendbackup on a client. Again, except for port 20, sendbackup does not care what port the request comes from.

If a user TCP port range (--with-tcpportrange) is defined, it needs to be unprivileged because dumper is not running as root (at this point).

A user TCP port range needs to be large enough for two ports (one to sendbackup on the client, and possibly one to taper) times the number of dumpers ("inparallel" in amanda.conf).

The stream_client_privileged() routine is used in one way:

  • amrecover to connect to amindexd and amidxtaped.

Because security information is passed, amindexd/ amidxtaped (via security_ok() in security.c) insist the other end (amrecover) be bound to a privileged port.

User TCP port range (--with-tcpportrange) summary

Pick the max of (2 * inparallel - for dumper/chunker communication) and (3 * largest maxdumps - for client/server communication). Allocate at least that many ports in the unprivileged (1024 or larger) range. Stay away from other well known ports (e.g. in your /etc/services file) or account for their potential use by making the portrange larger.

UDP port allocation

When Amanda creates a UDP socket, the same order of assignment as above is used by dgram_bind():

  • try for the user UDP port range (--with-udpportrange), if defined. If that fails ...
  • try for a privileged port (512 .. 1023). If that fails ...
  • get any available port.

The dgram_bind() routine is called from three places, amcheck, planner and dumper. In each case, a connection to amandad on a client is being set up. amandad, in turn, calls security_ok(), which insists the other end of the connection be a privileged port, so a user UDP port range (--with-udpportrange) must specify privileged port numbers.

A user UDP port range must allow for one port for each client that might be contacted at a time. planner and amcheck use a single socket to contact all their clients, but there may be multiple dumpers (based on "inparallel" in amanda.conf) and each needs its own port.


User UDP port range (--with-udpportrange) summary

Allocate at least "inparallel" many ports in the privileged (1023 or smaller) range. Stay away from other well known ports (e.g. in your /etc/services file) or account for their potential use by making the portrange larger.