git.gag.com Git - debian/amanda/blob - docs/PORT.USAGE

   1 =================================
   2 How Amanda uses UDP and TCP ports
   3
   4 John R. Jackson (jrj@purdue.edu)
   5 8-Aug-2001
   6 =================================
   7
   8 Amanda uses both UDP and TCP ports during its operation.  The amandad
   9 service is listening (via inetd/xinetd) at a well known (fixed) port on
  10 each client for UDP connections.  The amindexd and amidxtaped services
  11 are listening (also via inetd/xinetd) at well known ports on the tape
  12 server for TCP connections.
  13
  14 When a process on the tape server wants to talk to a client, it creates
  15 a UDP socket and binds it to a port on its side, then sends the packet
  16 to the well known amandad service port on the client.  Because security
  17 information is passed, the port bound on the connecting (tape server)
  18 side must be privileged (less than 1024).  This "proves" to amandad
  19 whoever is connecting is running as root, and therefor is trustworthy
  20 (there are all sorts of issues with the validity of this "trust" that
  21 are beyond the scope of this document).
  22
  23 A similar sequence of events happens when amrecover on a client wants
  24 to contact amindexd or amidxtaped on the tape server.  The port that
  25 amrecover binds to its TCP socket must be privileged, which is one of
  26 the reasons it must be run as root.
  27
  28 Amanda also uses TCP connections for transmitting the backup image,
  29 messages and (optionally) the index list from a client back to the dumper
  30 process on the tape server.  A process called sendbackup is started by
  31 amandad on the client.  It creates two (or three, if indexing is enabled)
  32 TCP sockets and sends their port numbers back to dumper in a UDP message.
  33 Then dumper creates and binds TCP sockets on its side and connects to
  34 the waiting sendbackup.
  35
  36 Because sendbackup does not run as root on the client, it cannot allocate
  37 privileged TCP ports to listen on.  The dumper process is setuid root
  38 and could bind privileged ports on its side (it currently does not),
  39 but because sendbackup does not care what port connects back to it (it
  40 assumes the only process that could have knowledge of the port numbers
  41 to use is dumper), it does not check the peer (connecting) port number.
  42
  43 ===================
  44 TCP port allocation
  45 ===================
  46
  47 When Amanda creates a TCP server socket to listen for incoming connections
  48 (sendbackup), it goes through the following bind steps:
  49
  50   * try for the user TCP port range (--with-tcpportrange), if defined.
  51     If that fails ...
  52
  53   * try for a privileged port (512 .. 1023).  If that fails ...
  54
  55   * get any available port.
  56
  57 This sequence is implemented in stream_server().
  58
  59 When Amanda (dumper) creates an unprivileged TCP client socket to connect
  60 to a server, it goes through the following bind steps:
  61
  62   * try for the user TCP port range (--with-tcpportrange), if defined.
  63     If that fails ...
  64
  65   * get any available port.
  66
  67 This sequence is implemented in stream_client().
  68
  69 When Amanda (amrecover) creates a privileged TCP client socket to connect
  70 to a server, it goes through the following bind step:
  71
  72   * try for a privileged port (512 .. 1023).  If that fails, the whole
  73     request is aborted.
  74
  75 This sequence is implemented in stream_client_privileged().
  76
  77 The stream_server() routine is used in two ways:
  78
  79   * taper to set up direct to tape communication with dumper on localhost.
  80
  81     If a user TCP port range is defined, it needs to be unprivileged
  82     because taper is not running as root.
  83
  84   * sendbackup to set up a transfer with its dumper.
  85
  86     If a user TCP port range (--with-tcpportrange) is defined, it needs
  87     to be unprivileged because sendbackup is not running as root.
  88
  89     A user TCP port range needs to be large enough for three ports
  90     (data, message and index) times the number of simultaneous backups
  91     the client may be asked to perform ("maxdumps" in amanda.conf).
  92
  93 The stream_client() routine is used in two ways:
  94
  95   * dumper to connect to taper for a direct to tape operation.  Except
  96     for making sure what is connecting is not (ftp) port 20 (a common
  97     attack entry point), taper does not pay any attention to the source
  98     (dumper) port number.
  99
 100   * dumper to connect to sendbackup on a client.  Again, except for
 101     port 20, sendbackup does not care what port the request comes from.
 102
 103     If a user TCP port range (--with-tcpportrange) is defined, it needs to
 104     be unprivileged because dumper is not running as root (at this point).
 105
 106     A user TCP port range needs to be large enough for two ports (one
 107     to sendbackup on the client, and possibly one to taper) times the
 108     number of dumpers ("inparallel" in amanda.conf).
 109
 110 The stream_client_privileged() routine is used in one way:
 111
 112   * amrecover to connect to amindexd and amidxtaped.
 113
 114     Because security information is passed, amindexd/amidxtaped (via
 115     security_ok() in security.c) insist the other end (amrecover) be
 116     bound to a privileged port.
 117
 118 =================================================
 119 User TCP port range (--with-tcpportrange) summary
 120 =================================================
 121
 122 Pick the max of (2 * inparallel) and (3 * largest maxdumps).  Allocate
 123 at least that many ports in the unprivileged (1024 or larger) range.
 124 Stay away from other well known ports (e.g. in your /etc/services file)
 125 or account for their potential use by making the portrange larger.
 126
 127 ===================
 128 UDP port allocation
 129 ===================
 130
 131 When Amanda creates a UDP socket, the same order of assignment as above
 132 is used by dgram_bind():
 133
 134   * try for the user UDP port range (--with-udpportrange), if defined.
 135     If that fails ...
 136
 137   * try for a privileged port (512 .. 1023).  If that fails ...
 138
 139   * get any available port.
 140
 141 The dgram_bind() routine is called from three places, amcheck, planner
 142 and dumper.  In each case, a connection to amandad on a client is being
 143 set up.  Amandad, in turn, calls security_ok(), which insists the other
 144 end of the connection be a privileged port, so a user UDP port range
 145 (--with-udpportrange) must specify privileged port numbers.
 146
 147 A user UDP port range must allow for one port for each client that
 148 might be contacted at a time.  Planner and amcheck use a single socket
 149 to contact all their clients, but there may be multiple dumpers (based
 150 on "inparallel" in amanda.conf) and each needs its own port.
 151
 152 =================================================
 153 User UDP port range (--with-udpportrange) summary
 154 =================================================
 155
 156 Allocate at least "inparallel" many ports in the privileged (1023 or
 157 smaller) range.  Stay away from other well known ports (e.g. in your
 158 /etc/services file) or account for their potential use by making the
 159 portrange larger.
 160
 161 =================
 162 Firewalls and NAT
 163 =================
 164
 165 I'm not familiar with firewalls or NAT -- one of the benefits of working
 166 in a University environment :-).  So the following is likely to be
 167 completely wrong, but I have tried to get the advice of folks who do
 168 really understand this stuff.
 169
 170 Firewalls and Amanda should be pretty easy to set up.  Just pick user
 171 UDP and TCP port ranges, build Amanda with them (--with-udpportrange and
 172 --with-tcpportrange) and let them through the firewall.  You also need to
 173 let the well known Amanda ports through, just as you would ftp or telnet.
 174
 175 NAT has other issues.  If the Amanda client is "outside" NAT, there
 176 should not be a problem for backups.  Sendbackup will set up the ports
 177 and tell dumper what they are.  Then dumper will connect to them from
 178 "inside" and NAT should leave that alone, although it doesn't really
 179 matter since sendbackup does not care who connects to it (other than it
 180 not be ftp port 20).
 181
 182 If the Amanda tape server is outside, NAT will have to be told how to
 183 translate the incoming connections from dumper to the client.  To do
 184 that, the UDP and TCP port ranges will have to be known and only one
 185 client can be inside.
 186
 187 The reverse is true for amrecover.  If amrecover is run from inside NAT,
 188 there should not be a problem -- it's just like running ftp or telnet.
 189 But from the outside, NAT will have to know where the amindexd/amidxtaped
 190 services are and allow them through (much like ftp or telnet daemons).
 191 Since they are on known port numbers, the user TCP port range is not
 192 an issue.
 193
 194 A user TCP port range is probably not important in the case of dumper
 195 and taper talking to each other since only the one machine (localhost)
 196 is involved and so it does not go through a firewall.  But I could be
 197 wrong, especially if NAT is involved.
 198
 199 The details of how you configure a specific firewall or NAT are beyond the
 200 scope of this document (although examples would be welcome).  You need
 201 to read up on the documentation that comes with them.