
Chapter 21. How AMANDA uses UDP and TCP ports
Prev  Part V. Technical Background       Next

-------------------------------------------------------------------------------

Chapter 21. How AMANDA uses UDP and TCP ports


John R. Jackson

Original text
AMANDA Core Team
<jrj@purdue.edu>

Stefan G. Weichinger

XML-conversion;Updates
AMANDA Core Team
<sgw@amanda.org>
Table of Contents


  TCP_port_allocation

  User_TCP_port_range_(--with-tcpportrange)_summary

  UDP_port_allocation

  User_UDP_port_range_(--with-udpportrange)_summary

  Firewalls_and_NAT


Note

Refer to http://www.amanda.org/docs/portusage.html for the current version of
this document.
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) 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) and (3 * largest maxdumps). 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.

 Firewalls and NAT

I'm not familiar with firewalls or NAT -- one of the benefits of working in a
University environment :-). So the following is likely to be completely wrong,
but I have tried to get the advice of folks who do really understand this
stuff.
Firewalls and AMANDA should be pretty easy to set up. Just pick user UDP and
TCP port ranges, build AMANDA with them (--with-udpportrange and --with-
tcpportrange) and let them through the firewall. You also need to let the well
known AMANDA ports through, just as you would ftp or telnet.
NAT has other issues. If the AMANDA client is "outside" NAT, there should not
be a problem for backups. Sendbackup will set up the ports and tell dumper what
they are. Then dumper will connect to them from "inside" and NAT should leave
that alone, although it doesn't really matter since sendbackup does not care
who connects to it (other than it not be ftp port 20).
If the AMANDA tape server is outside, NAT will have to be told how to translate
the incoming connections from dumper to the client. To do that, the UDP and TCP
port ranges will have to be known and only one client can be inside.
The reverse is true for amrecover. If amrecover is run from inside NAT, there
should not be a problem -- it's just like running ftp or telnet. But from the
outside, NAT will have to know where the amindexd/amidxtaped services are and
allow them through (much like ftp or telnet daemons). Since they are on known
port numbers, the user TCP port range is not an issue.
A user TCP port range is probably not important in the case of dumper and taper
talking to each other since only the one machine (localhost) is involved and so
it does not go through a firewall. But I could be wrong, especially if NAT is
involved.
The details of how you configure a specific firewall or NAT are beyond the
scope of this document (although examples would be welcome). You need to read
up on the documentation that comes with them.
-------------------------------------------------------------------------------

Prev                           Up                            Next
Part V. Technical Background  Home  Chapter 22. AMANDA dumper API

