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

   1
   2 Chapter 20. How AMANDA uses UDP and TCP ports
   3 Prev  Part V. Technical Background       Next
   4
   5 -------------------------------------------------------------------------------
   6
   7 Chapter 20. 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 This sequence is implemented in stream_server().
  82 When AMANDA ( dumper) creates an unprivileged TCP client socket to connect to a
  83 server, it goes through the following bind steps:
  84
  85 * try for the user TCP port range (--with-tcpportrange), if defined. If that
  86   fails ...
  87
  88
  89 * get any available port.
  90
  91 This sequence is implemented in stream_client().
  92 When AMANDA ( amrecover) creates a privileged TCP client socket to connect to a
  93 server, it goes through the following bind step:
  94
  95 * try for a privileged port (512 .. 1023). If that fails, the whole request is
  96   aborted.
  97
  98 This sequence is implemented in stream_client_privileged().
  99 The stream_server() routine is used in two ways:
 100
 101 * taper to set up direct to tape communication with dumper on localhost.
 102
 103 If a user TCP port range is defined, it needs to be unprivileged because taper
 104 is not running as root.
 105
 106 * sendbackup to set up a transfer with its dumper.
 107
 108 If a user TCP port range (--with-tcpportrange) is defined, it needs to be
 109 unprivileged because sendbackup is not running as root.
 110 A user TCP port range needs to be large enough for three ports (data, message
 111 and index) times the number of simultaneous backups the client may be asked to
 112 perform ("maxdumps" in amanda.conf).
 113 The stream_client() routine is used in two ways:
 114
 115 * dumper to connect to taper for a direct to tape operation. Except for making
 116   sure what is connecting is not (ftp) port 20 (a common attack entry point),
 117   taper does not pay any attention to the source ( dumper) port number.
 118
 119
 120 * dumper to connect to sendbackup on a client. Again, except for port 20,
 121   sendbackup does not care what port the request comes from.
 122
 123 If a user TCP port range (--with-tcpportrange) is defined, it needs to be
 124 unprivileged because dumper is not running as root (at this point).
 125 A user TCP port range needs to be large enough for two ports (one to sendbackup
 126 on the client, and possibly one to taper) times the number of dumpers
 127 ("inparallel" in amanda.conf).
 128 The stream_client_privileged() routine is used in one way:
 129
 130 * amrecover to connect to amindexd and amidxtaped.
 131
 132 Because security information is passed, amindexd/ amidxtaped (via security_ok()
 133 in security.c) insist the other end ( amrecover) be bound to a privileged port.
 134
 135  User TCP port range (--with-tcpportrange) summary
 136
 137 Pick the max of (2 * inparallel) and (3 * largest maxdumps). Allocate at least
 138 that many ports in the unprivileged (1024 or larger) range. Stay away from
 139 other well known ports (e.g. in your /etc/services file) or account for their
 140 potential use by making the portrange larger.
 141
 142  UDP port allocation
 143
 144 When AMANDA creates a UDP socket, the same order of assignment as above is used
 145 by dgram_bind():
 146
 147 * try for the user UDP port range (--with-udpportrange), if defined. If that
 148   fails ...
 149
 150
 151 * try for a privileged port (512 .. 1023). If that fails ...
 152
 153
 154 * get any available port.
 155
 156 The dgram_bind() routine is called from three places, amcheck, planner and
 157 dumper. In each case, a connection to amandad on a client is being set up.
 158 amandad, in turn, calls security_ok(), which insists the other end of the
 159 connection be a privileged port, so a user UDP port range (--with-udpportrange)
 160 must specify privileged port numbers.
 161 A user UDP port range must allow for one port for each client that might be
 162 contacted at a time. planner and amcheck use a single socket to contact all
 163 their clients, but there may be multiple dumpers (based on "inparallel" in
 164 amanda.conf) and each needs its own port.
 165
 166  User UDP port range (--with-udpportrange) summary
 167
 168 Allocate at least "inparallel" many ports in the privileged (1023 or smaller)
 169 range. Stay away from other well known ports (e.g. in your /etc/services file)
 170 or account for their potential use by making the portrange larger.
 171
 172  Firewalls and NAT
 173
 174 I'm not familiar with firewalls or NAT -- one of the benefits of working in a
 175 University environment :-). So the following is likely to be completely wrong,
 176 but I have tried to get the advice of folks who do really understand this
 177 stuff.
 178 Firewalls and AMANDA should be pretty easy to set up. Just pick user UDP and
 179 TCP port ranges, build AMANDA with them (--with-udpportrange and --with-
 180 tcpportrange) and let them through the firewall. You also need to let the well
 181 known AMANDA ports through, just as you would ftp or telnet.
 182 NAT has other issues. If the AMANDA client is "outside" NAT, there should not
 183 be a problem for backups. Sendbackup will set up the ports and tell dumper what
 184 they are. Then dumper will connect to them from "inside" and NAT should leave
 185 that alone, although it doesn't really matter since sendbackup does not care
 186 who connects to it (other than it not be ftp port 20).
 187 If the AMANDA tape server is outside, NAT will have to be told how to translate
 188 the incoming connections from dumper to the client. To do that, the UDP and TCP
 189 port ranges will have to be known and only one client can be inside.
 190 The reverse is true for amrecover. If amrecover is run from inside NAT, there
 191 should not be a problem -- it's just like running ftp or telnet. But from the
 192 outside, NAT will have to know where the amindexd/amidxtaped services are and
 193 allow them through (much like ftp or telnet daemons). Since they are on known
 194 port numbers, the user TCP port range is not an issue.
 195 A user TCP port range is probably not important in the case of dumper and taper
 196 talking to each other since only the one machine (localhost) is involved and so
 197 it does not go through a firewall. But I could be wrong, especially if NAT is
 198 involved.
 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 to read
 201 up on the documentation that comes with them.
 202 -------------------------------------------------------------------------------
 203
 204 Prev                           Up                            Next
 205 Part V. Technical Background  Home  Chapter 21. AMANDA dumper API
 206