2 Chapter 20. How AMANDA uses UDP and TCP ports
3 Prev Part V. Technical Background Next
5 -------------------------------------------------------------------------------
7 Chapter 20. How AMANDA uses UDP and TCP ports
18 XML-conversion;Updates
26 User_TCP_port_range_(--with-tcpportrange)_summary
30 User_UDP_port_range_(--with-udpportrange)_summary
37 Refer to http://www.amanda.org/docs/portusage.html for the current version of
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
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.
69 When AMANDA creates a TCP server socket to listen for incoming connections
70 ( sendbackup), it goes through the following bind steps:
72 * try for the user TCP port range (--with-tcpportrange), if defined. If that
76 * try for a privileged port (512 .. 1023). If that fails ...
79 * get any available port.
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:
85 * try for the user TCP port range (--with-tcpportrange), if defined. If that
89 * get any available port.
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:
95 * try for a privileged port (512 .. 1023). If that fails, the whole request is
98 This sequence is implemented in stream_client_privileged().
99 The stream_server() routine is used in two ways:
101 * taper to set up direct to tape communication with dumper on localhost.
103 If a user TCP port range is defined, it needs to be unprivileged because taper
104 is not running as root.
106 * sendbackup to set up a transfer with its dumper.
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:
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.
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.
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:
130 * amrecover to connect to amindexd and amidxtaped.
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.
135 User TCP port range (--with-tcpportrange) summary
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.
144 When AMANDA creates a UDP socket, the same order of assignment as above is used
147 * try for the user UDP port range (--with-udpportrange), if defined. If that
151 * try for a privileged port (512 .. 1023). If that fails ...
154 * get any available port.
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.
166 User UDP port range (--with-udpportrange) summary
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.
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
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
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 -------------------------------------------------------------------------------
205 Part V. Technical Background Home Chapter 21. AMANDA dumper API