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