git.gag.com Git - debian/amanda/blob - docs/portusage.txt

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